How Agile Changes Testing, Part 1
How Agile Changes Testing, Part 1
Hear Johanna Rothman's perspective on how agile methodologies affect testing and check out her templates for what you might need in a project, including the system test plan.
Join the DZone community and get the full member experience.Join For Free
See why over 50,000 companies trust Jira Software to plan, track, release, and report great software faster than ever before. Try the #1 software development tool used by agile teams.
Last week, I attempted to have a Twitter conversation about agile and testing. I became frustrated because I need more than 140 characters to explain.
This is my general agile picture. For those of you can’t see what I’m thinking, the idea is that a responsible person (often called a Product Owner) gathers the requirements for the project. The cross-functional product development team works on some of those features (which I like as small stories) and outputs small chunks of a working product that have value to the customer. You might or might not have a customer with you. The Product Owner either is the customer or takes the customer role.
After some number of features are completed, the team demonstrates the features and reflects on the project and the team’s process. They get more features from the PO.
Now, let’s contrast agile with more traditional planning and testing.
If you used a phase-gate or a waterfall life cycle, you were accustomed to planning the entire project—including system test plans—at the beginning. You predicted what you needed to do.
If you were a tester, you often discovered that what you planned at the beginning was not what you needed by the time it was time for you to test. You might have been interrupted by the need to test current projects, with the promise you would return to this one. Testers were often at the end and possibly delayed by not-quite-finished work in flight.
If you could work on this project, you wrote a system test plan. In addition, you might have written system test specifications, designed test cases, and maybe even documented test cases. Why? So you wouldn’t forget what to do. And, your customer (management, maybe a real customer) would want to know what you had been doing all along and what they could expect. You planned for the future.
In agile, we don’t do a ton of upfront planning. I like to plan for no more than a couple of days, including generating the initial backlog for a cross-functional team to work on. Yes, two days. More planning might easily be a waste. What might you do in those two days?
- Write a project charter as a team, which includes the project vision and release criteria.
- Generate a story map or product backlog for the first release’s worth of stories. (If you read my roadmap posts, you know I like internal releases at least as often as every month. I prefer releasing every day. I’ll take visual working software at least once a month.)
- If you are a new team, you might develop working agreements and a definition of done.
Do you need a system test plan? Maybe. I often discover that when we discuss the project charter, we might say something like, “We want to focus our testing in these areas,” or “These are the areas of high risk that we can see now.” My system test plan is still only one page. (See the Manage It templates for all my templates of what you might need in a project, including the system test plan.)
Now, you start the project. What happened to all that test planning and test plans and test cases? They go with the stories—if you need that level of planning. See Part 2.
Published at DZone with permission of Johanna Rothman , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.