Archive for June, 2010
The second part of the post Waterfall Vs Agile, has just been published in DZone, follow the link to read it…
Historically QA is been considered the last stage of software development, and QA testers have been seen as not necessarily qualified people, that all they need to do is to run manual or some automated UI tests over applications handed over by development.
This classic approach is somehow still used even in several agile projects, and it has many inconveniences:
- QA becomes a certification/cop department that adds very little value to Development.
- It only assures the quality of the final product, but not the quality of the code.
- It creates the illusion that software can be created without bugs.
- It’s not synchronized with the business needs, but with the requirements contract.
QA should switch to a new paradigm, QDD – QA Driven Development. In QDD the main role of QA should be to engage with development and the customer.
In order to achieve this new paradigm, QA should:
- Review not only the final product, but also the code. The code is the big gap in classic QA. It is never itself checked for quality. Low quality code will make the maintenance of the application a nightmare.
- Be involved in the day to day of development. QA should be present in every single important decision taken during development. They should also be aware of what the code looks like through daily code reviews or pair programming.
- Have qualified and skilled employees. QA should drive the development, and that requires QA personnel to be very skilled and qualified.
- Keep continuously updating the customer. QA should make sure that the application as it’s developed is fulfilling the customer’s expectations. It should also be their duty to guarantee that new requirements are identified, and also to identify previous requirements that are not necessary anymore.
- Decide when a feature is completed. As the top part of the pyramid of software development, QA is the most qualified member to decide when a feature is completed.
- Create a comprehensive suite of automated tests. QA should aim to cover as much as possible with automated tests, this will guarantee that regression testing should be easy to perform for each new feature.
- Handover requirements to development. QA should have the best understanding of both, technical and non technical aspects of the application. That is what will make them the perfect candidates to handover new requirements.
- Have formal authority over development. None of the previous points would be possible is QA is not given formal authority over development.
Based on these characteristics, QA personnel will have to be well trained in computer science, actually, QA should be an specialization of software development, and not a completely different branch. An ideal candidate for QA then should be a seasoned developer, with coach and lead abilities.
Of course to move to QDD there are very big challenges, being the three most importants:
- Companies that have QA infraestrucutres and personnel not fitted for this new paradigm, and not wishing to lose their investment.
- Developers not willing to become QA.
- Companies are afraid of the over cost of switching non-qualified QA people for skilled developers.
While these are important factors to overcome, in my opinion switching to this new QA paradigm will bring benefits in the mid/long run as the quality of the applications delivered will grow exponentially.
To all my readers.
I’ve been honoured to author an article for dZone, “Waterfall vs Agile: Can they be friends?” If you follow the link you should be able to read it.