In an Ideal software development world there would be no QA team or a testing team, but we all know all the processes including software development are prone to human error. With an increasing demand for better software there is a rise in Quality Assurance jobs.
But most of the business or stake holders consider the QA team as an overhead and whenever their is a slump period the axe falls first on the testers. The development team as well often finds it difficult to fit in the testing team into their development phase and the teams usually end up on two poles of the process. And I can imagine the poor Project manager at the centre somehow managing and trying to get work done to get his billing correct. Facebook doesn't have any software testing team but they do as well test their software through beta testers before launching a feature to the world.
How and where exactly does the testing team fits and can they really improve the software industry
Well the answer is difficult but certainly not impossible. Its not the business or the developers who need to change as they are not necessarily wrong. Mostly its the test engineers who can change this attitude, what's needed is some retrospection into the QA role.
Given that we are still not into the 100% agile mode most of the testing teams in traditional waterfall model work in post development phase. Where the opportunity of change is almost zero and even the defects fixes turns out to be long process. Testing teams are often divided into manual and automation teams.
- Manual team who consider there job limited to writing manual tests and executing those tests. These tests often run into thousands and updating them is again a huge effort. At times these tests are written years ago and the person executing them hardly understands the business goal behind a given step. More the number of bugs they find is a metric of how well the job was done.
Our client once said why does your team total bug found was always less, the QA team doesn't seems to be working well? The team was working way better as we had zero bugs in production, isn't that the ultimate target?
- Automation teams on the other hand don't care at all about what's in the test cases they simply automate them line by line. Their performance is measured on the number of test cases automated (you can leave the test script "to do" to improve your performance, your manager is never going to open the test case and verify it? Yeah many people actually do that !!)
What's the problem with above structure which is pretty much followed by more than 50% of the software teams?
Wiki defines Software Testing as "Software testing is an investigation conducted to provide stakeholders with information about the quality of the product or service under test"
The ultimate aim of testing is to provide feedback on the software to the stakeholders before its being released to the end user. The problem with above stated structure is the missing feedback, both the teams are trying to get their job done but no one is focussed on providing quality feedback.
Let's see how we as QAs can get this whole cycle right. Testing team is the representative of business to the development team and vice a versa as they get their hands dirty on the software before anyone else and continue to do that through the life of the project. They often know more about the functionality then anyone else if not then they are probably not doing their job right. With my experience below are the certain points that seemed to be working and can help anyone who wants to improve upon:
- I haven't seen the concept of different manual and automation teams working but given the limited availability of required skill set this model is the only choice in certain cases. But even with this model both the team should work more closely to get the automation priorities right and manual team should use the feedback from automation results in manual verifications. A testeer who has understanding of business can definitely test extensively and write better automation tests.
- Testing team should work with Product team to understand the business goals and be more flexible in their manual testing to incorporate the business aspect.
- The projects where testing teams work closely with development team are more successful as the feedback loop for any defect/ bug is shorter. Even for offshore models the development and testing team for a given module should work next to each other.
- There is no way the performance is proportional to the number of bugs found, seriously? This is the biggest myth of testing world. The job of QA is to uncover issues in a software but higher the number of bugs higher is the cost. QA should discuss the edge cases with developers before building the functionality or raise the risky area ahead of time to the product managers so that the bugs can be avoided as early as possible.
The above points are very much useful and applicable to agile projects as well. Given agile testers are not born they are the same testers who have worked in the waterfall model at some point of there life as a tester like me.
