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, Stainless Software
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.
- Communicate
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.
Handling rapid code drops
Frequent updates to the code base are a challenging aspect of Agile testing, and while the processes outlined above will help you deal with them, it’s worth going into a little more detail.
It’s not uncommon for a test environment to be updated daily, which can mean that a tester stops testing a process at day’s end only to find the code has changed when they come to complete the testing next morning. This can lead to careless or release-happy developers, who become so confident that the testers will pick up any problems that they don’t test their code, instead moving on to the next task. There are several ways to handle this. Three fairly simple ones are:
1. Multiple test environments
It may seem odd to create a staging environment for your test server, but this can allow developers and testers who are working together in a quick, back-and-forth way to have endless code updates while keeping the main environment more stable for in-depth testing.
2. Schedule drops to the main test area
It’s easier to deal with if you know it’s coming. Monday and Thursday are a good choice.
3. Encourage developers to write automated tests
Unit tests or higher-level automated tests can be run immediately after deployment and should pick up most major issues. These can be run in conjunction with or as part of an automated regression test suite. Most languages have a xUnit unit testing framework available. Higher level tests might be accomplished with tools such as Selenium.
Rapid code drops can be brilliant, providing with-the-hour bug fixes and allowing close collaboration between developers and testers – but they’re only acceptable if they’re working for both parties, and they’re not an excuse to do away with all release protocols. Rapid drops are a stressful issue for many transitioning teams, and are a good place to stand your ground and make sure the Agile process works for you. In the final article in this series, I’ll leave you with 7 practical tips to make the transition smoother overall.
Other parts
* Transition to Agile Testing – Part 1 Getting Started
* Transition to Agile Testing – Part 2 The New System
* Transition to Agile Testing – Part 4: 7 Practical Tips
About the Author
Elizabeth Bagwell is a professional writer and a qualified software tester. Having spent much of her working life doing one or both for large companies, she is now working as a freelancer. Co-founder of Stainless Software online consultancy, she blogs about things other than writing or testing at www.elizabethbagwell.me.uk