Pages

Tuesday, April 09, 2013

Building quality in – Do we need testers ?

Following article got published on  Zephyr recently.

image During the waterfall era, at the end of development, the completed code was thrown at testers who in turn would identify defects. These defects would get registered onto a tracking tool. In response to these defects, the developers would swarm around them and fix all of them for the next  one week. This process used to continue until the QA team signs of on all the defects.   

Now with the popularity of the Agile, Lean and Continuous Deployment, the developers are required to be more vigilant while coding. They are recommended to follow practices like TDD, ATDD to improve the code quality, reduce defects among other benefits. Since these practices are supposed to reduce the burden on testers, a lot of people are questioning the need for dedicated testers in the software development.  

In this article, I will address questions around the need for testers, the value they bring in, and their role in the context of Lean and Agile.

Why do we need to build the quality in?
Let me begin with the Lean Principle #2, Building Quality In. Before jumping to solution mode, let us understand the ways the quality issues crop up and the cost associated with it.  Quality issues originate at the beginning of the project and the top 3 reasons could be grouped into:

  1. Customer giving a wrong requirement and realizing it at a later stage
  2. The developer writing wrong code due to misunderstanding of requirement
  3. Developer understood requirement but coded a wrong logic

Irrespective of whether the mistake is by the customer or the developer, there is an effort involved in testing and rewriting the code. As per the 1:10:100 rule, the failure to identify the defect upfront could cost a fortune to the company.

Solving the quality issues:
First issue mentioned above could be solved by the development teams building the prototype and showcasing to the customer even before touching the code. Second and third issues could be solved by practices like TDD and ATDD.

If developers and customers work closely, ensure to fill the gaps and write quality code, can we still delivery a quality product without testers ?

In recent days, some of the lean startup companies have tried customer testing and crowdsourcing the testing without involving the testers. However, it is still not proven if this is the right model. A lot of people also agree that even the most experienced developers make mistake. The developers come with a specialized technical background and they won’t have the same eye as a tester. They are good at unit level testing, and they cannot effectively do the integration/system level testing. This is not something which could be improved by automating the tests.

Role of tester in Agile, Lean environment:
Many teams have tried building products just with developer testing and have got bitten badly as well. As one could see from this discussion, people have reverted back to include testers.

There is no doubt now that dedicated testers are needed in all projects. We still need testers to provide a neutral eye and their specialized skills to improve the quality. In fact, testers have now more empowering role to play than before.

To conclude:

  • Testers look at preventing defects and not just identifying them in the end
  • They get involved in the beginning of the project working closely with the product owners(PO) and developers.  They ask right questions about requirements and in turn making every get clarity on the requirements
  • They write acceptance tests, they do smoke tests and exploratory testing
  • They work as a support structure for the development team in ensuring smooth delivery of the project.
  • They think beyond just testing and embrace tasks that help the team in smooth deployment to production

Image courtesy of ponsulak / FreeDigitalPhotos.net

No comments: