How Agile Changes Testing, Part 1

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.

general-agile-picture-copyright-1024x645This 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 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 complete, the team demonstrates the features and retrospects 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 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.

6 Replies to “How Agile Changes Testing, Part 1”

  1. Where I’m currently building a brand new test team in an agile-ish shop, we don’t have documented tests. When a feature is big or hairy, we brainstorm test ideas and write them down as a checklist so we don’t forget them, but if we keep them, it’s accidental.

    Oh my goodness, it’s so freeing. Figure out the risk (code, customer, business) inherent in a change, ask questions of the software through testing that surfaces those risks, move on.

    1. Jim, it is great! You have the tests you need when you need them. You have the documentation you need when you need it. No big hairy docs (that no one reads). Just in time information. And, the devs and testers work together to brainstorm, I bet. A much more robust list. Less chance of multiple tests testing the same thing. (That’s an issue of coverage.)

Leave a Reply