Transition to Agile Testing – Part 3 The New Processes
By: Elizabeth Bagwell
Software testing during the transition to Agile is not easy. This third part explains how your software quality assurance processes should change. It discusses how to cope with rapid development cycle and frequent code changes that are at the heart of the Agile approaches.
Author: Elizabeth Bagwell,
Shifting to Agile often involves implementing new processes throughout the development workflow. Assessing existing systems is a good place to start, but resist the temptation to hang on to legacy systems simply because they’re already in place. Advances in technologies and practices mean that a 10-year-old system will probably be making outdated assumptions about what work is done and how, and will often be impossible to integrate with newer tools.
Assess your bug tracking system
You now need one which integrates with or ideally is part of the requirement tracking system.
Assess your bug tracking process
If it’s complex or arcane or requires a tester to do it, let it go. Everyone needs to be able to list a defect (or a feature request) quickly and easily, even the sales team, customers or the receptionist.
Add a bug assessment process
Each defect should be assessed and triaged quickly, either sent back to the author for more information, assigned a fix priority or marked ‘will not fix’. This is usually handled by developers, but you may want to have a tester involved.
Let go of a strict definition of roles
Be ready to step out of your role in order to pitch in, and accept that others may to tasks which were previously your exclusive territory.
Let go of long planning periods and rigid testing schedules
Rapid responses to new code or features are key to becoming more Agile.
Encourage exploratory software testing
Instead of focusing on strictly planned and guided tests, allow testers to use and stretch their expertise by trying to break the software in new ways, using the resultant test and bug reports as the basis for both further systematic testing and regression testing.
Get involved early
Testers should aim to be involved in every stage of the process, from scoping the requirements and developing user stories onwards. Agile highlights quality-led development and this often starts by defining the acceptance criteria, something the test team often have to do otherwise, so tester involvement is key. If you’re explicitly doing TDD or BDD, you will need to write very specific acceptance criteria for development units concurrently or before development takes place.
Mix developers and testers in the seating plan, keep the IRC channel always open, keep the group Skype chat on, keep or start an engineering department monthly pub lunch – whatever gets your team talking to each other. Agile requires good communications, and these are encouraged by camaraderie
... to read more articles, visit http://sqa.fyicenter.com/art/