Mastering Agile Testing
There is general acceptance that adopting agile development practices enables the speeding up of the delivery of software. Without incorporating quality assurance practices directly into the development process, product quality inevitably suffers. In order to consistently achieve high quality, both work practices and team roles need to change to build quality in rather than testing at the end.
The agile software development life cycle was designed primarily by and for developers; it was not created to optimize quality assurance (QA). Software testing remains an integral part overall development life cycle and the last 15 years have been spent finding ways to incorporate it based on this new shift to agile in the industry. While the proliferation of automated testing techniques has helped this transition, shifting roles are a key reason highperforming teams have succeeded.
He maintains that having separate testing roles within a team is counter-productive, encouraging "mini-waterfall" thinking. He says:
There is a need for the fullstack QA engineer, an individual with a technical language set along with subject matter expertise, who can be the champion for quality across the entire squad.
Quality becomes everyone's responsibility, and the testing focus for each individual is directed to their core skillset. He talks about developers taking responsibility for fuctional and unit testing, product owners bookending the testing with usability and acceptance to ensure the product increment is fit for purpose.
Quality assurance professionals will take control of their destiny and establish an agile culture of quality by shifting to a more technical focus, demonstrating an ownership mentality and strong voice within their organization, and driving a system of quality throughout their crossfunctional teams.
Instead of leaving testing to the end of the process, you should be thinking about quality within the Agile process. If you do this, your testing at the end will be much more effective and efficient.
- Work closely with customers to understand them
- Keep teams small
- Promote a shared understanding
- Collaborate, collaborate, then collaborate some more
- Measure your progress
- Make roles and responsibilities clear
- Facilitate a team culture
Like habits for a productive and meaningful life, where you learn as you go, adapt and improve with experience; there are habits that lead to highly effective Agile. For any project, whether converting from a Waterfall process to Agile or trying to fine-tune the Agile process, we've found that these good habits lead to a particularly successful Agile implementation.
I think this is wrong
On projects where I’ve been lucky enough to work with a good, specialist test manager they are worth their weight in gold. We’ve ended up with happier customers, better quality software, and a higher overall velocity.
My recommendation: have developers write unit tests. Have a separate Q&A team that breaks the software before it gets to the business. For every bug that’s found have a unit test that tests it to avoid regressions.
What are other peoples experience of this?
Re: I think this is wrong
Thanks for taking the time to comment.
I don't see anything in the recommendations about not having dedicated testing skills in the team - the "full stack QA engineer" is someone focused on the quality of the product who needs to have a solid understanding of the important testing principles as well as technical knowledge.
I certainly see a strong push for testing skills to include technical skills today - I feel the era of the dedicated manual tester who followed a test script to exercise a product is probably gone. The skills needed to design good test scripts are absolutely necessary, along with the ability to automate those scripts and to do exploratory testing across the product.
I prefer cross-functional teams with all the skills needed to design, build, test and deploy a product rather than hand-off to a separate QA team. The earlier we can engage the testing mindset the better; "shifting left" all the way to testing the requirements (be they user stories or any other format).
A final personal peeve - testing doesn't break the product, it exposes where other people have left it broken.
Success of QA depends how well they know Agile Methodology