Software testing during the transition to Agile, particularly if you’re moving from a classic waterfall system, is not easy. This part discusses how to perform software testing when you don’t have the classical workflow of documented test cases and bug requests than in a traditional approach.
Author: Elizabeth Bagwell, Stainless Software
From a tester’s perspective, a classic waterfall development model runs something like this:
(click on image to view it full size)
In Agile, all those steps tend to happen on the same day, and this is not a bad thing. However, it does mean that you’ll have less time to plan ahead, analyze or write test cases. Particularly during the transition phase, the test teams are likely to feel under pressure to perform rapidly and adrift without their usual planning sessions.
Fortunately, Agile user stories and bite-size feature tickets do a lot of the testing preparation work for you. It is usually much more effective to insist that sales teams, project managers and developers take this phase seriously than to try to gather the information and do it all yourself. User stories and features requirements should be a group effort, and should include at least one tester in the mix. Agile encourages development with the end view in mind, and testers, by the nature of their work, should have a clear idea of what an acceptable end result is – these acceptance criteria should be included in the user story or requirement.
Testing without test cases
Ideally, when you are given a code drop, it should come with a number of ‘tickets’ for each of the small features and bug fixes in drop. These should have a title or description that is clear, such as:
* Feature request: There is a ‘buy now’ button on each product page
It should be simple to prove that the issue is not fixed or the feature doesn’t appear. Testing that the feature appears correctly may require more preparation, and you may wish to write detailed test cases. Resist that urge unless you either have a lot of time on your hands or expect to use the test cases for regression testing. Instead, write a higher-level list of your areas and methods of attack, and add detailed notes during testing only when necessary.
* User story: As an end user, I can set the application to be password protected
User stories can often be implemented in several different ways, and you may wonder which is best or acceptable. Any solution is acceptable, as long as it works and does not break other features. If it does, you can fail a user story as you would a bug and/or create a defect ticket.
* Bug: Receipt page does not appear after sale
Ideally, bug reports should be usable as test cases. Ensuring that testers include full steps to reproduce a bug is relatively simple, but ensuring that other stakeholders comply with the bug tracking process will be harder. Make the process as simple as possible and accept that as a tester, you may have to talk to the original reporter to get more information. An advantage of Agile is that, unlike in waterfall systems, bugs should be reviewed regularly and dealt with promptly, thus reducing the chance that the reporter will have forgotten the issue by the time it comes round to test.
* Bug: Array size checked every time inside for loop
Just as developers should be encouraged to write bugs, they should be encouraged to test any defects which are issues with the code base rather than problems with the features or user stories of an application.
Changing the process
In a classic waterfall development model, it’s possible to have entirely separate processes and tools for tracking requirements, work done and defects. These will have to change to accommodate the flexibility of Agile, and that’s the new process – what you can keep and what you should let go – is the topic for my next article.
Other parts
* Transition to Agile Testing – Part 1 Getting Started
* Transition to Agile Testing – Part 3 The New Processes
* 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