Testing during the transition to Agile, particularly if you’re moving from a classic waterfall system, often means throwing out every expectation you have about how a project will be run, how long you’ll have to prep or test a drop, and when new code will arrive.
Author: Elizabeth Bagwell, Stainless Software
Over the course of this four-part series, we’ll discuss ways of making the transition smoother and more pleasant for your test team.
While the change can be an unexpected and unpleasant disruption to your established processes, in my opinion it’s worth embracing the new system as wholeheartedly as you can manage for the following reasons:
* The transition will hurt less if you don’t fight it
* You’re going to need every spare minute you’ve got
* Agile testing can be a lot of fun
What is Agile?
Agile is a popular software development process. It’s an evolving process and is implemented in a number of different ways using different tools, so no two Agile teams will be exactly alike. The key features, particularly for testers, are:
* A focus on working code and modular development
* Rapid code drops: new versions of the application to be tested may arrive multiple times per day.
* Requirements and features may shift and change and this is OK
* Requirements, features and modules should be defined as user stories, i.e. end user actions or needs
* Self-organizing teams
* Regular, short meetings (stand ups)
* Input from a wider range of stakeholders (including testers, sales teams and project managers)
This is a very brief and simplistic view of the system. You can find out more about Agile in Software Testing Magazine’s Agile section or you may wish to read the Agile Manifesto which provides a short but more complete introduction.
An Agile Testing Approach. Source: http://pathfindersoftware.com/2011/05/functional-test-vs-technical-testing/
What this means for the test team
In many cases, the push to move to Agile comes from a team leader or senior developer, and the test team has to run with it. It rarely comes from the test team, and as a result testers – who are usually busy enough already – may struggle to see the benefits of the new system. Key changes for the test team are:
- Less writing, more testing: Rapid response testing means less planning and report writing and more exploratory and manual testing.
- Greater input at all levels: Agile allows greater flexibility and encourages input from all stakeholders. Testers can and should be involved at every step, from scoping features to reporting to customers.
- Hard work: It’s common for different groups of programmers within an organization to adopt Agile with different levels of enthusiasm and at different rates. Test teams typically work with multiple groups and have to be even more flexible and tolerant during the transition.
- A chance to make changes: As processes and roles shift, it’s an excellent opportunity to make changes that benefit the test team, from lobbying for a single combined requirement, work and defect tracking tool to drawing developers into automation testing.
Over the following three articles, we’ll discuss the nitty-gritty of transitioning to Agile, including implementing new processes, handling rapid code drops and preparation and test case writing.
Next parts
* Transition to Agile Testing – Part 2 The New System
* Transition to Agile Testing – Part 3 The New Processes
* Transition to Agile Testing – Part 4: 7 Practical Tips
Further reading
1. Software Testing Magazine’s Agile section
2. Agile Testing: A Practical Guide for Testers and Agile Teams, Lisa Crispin and Janet Gregory, Addison Wesley, 533 pages, ISBN 978-0-321-53446-0
3. The Agile Manifesto provides a short but more complete introduction to Agile.
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