How Agile Changes Testing, Part 3

In Part 1, I discussed how an agile approach changes testing. In Part 2, I discussed how the testers' job changes. In this part, I'll talk about expectations.

Since the developers and testers partner in agile, the testers describe their approach to testing as they work with developers on the code. (This is the same way as the developers describe their approach to development.) You might not need any test planning documents. At all.

If you have acceptance criteria on stories, the developers know what unit tests to write. The testers know what kind of system tests to write. All from acceptance criteria. You don't need test case definition—the acceptance criteria define what the tests need to do.

What if your customer wants test documents? Show them working software.

What if your customer wants to see traceability? (If you are in a regulated environment, you might have this requirement.) Show them how the user stories encapsulate the unit tests and system tests.

What if your customer wants to know you are testing what the developers write? Well, I want to know the answer to this question: What else would you test?

If the developers have moved onto a new feature and you are not done, you need a kanban board to show the workflow. Your team might have too much work in progress queued for the testers. I see this in teams with six developers and one lonely tester. (That lonely tester is often time-space removed from the developers.)

Separating developers from testers and having developers run fast on coding provides the illusion of progress. In fact, in agile, you want to measure throughput, not what any given person has completed. (See my posts on resource vs. flow efficiency.)

Maybe you found a bunch of problems in a feature the developers thought was already done. If so, the developers should stop working on anything new, and work with you to fix this feature. If they don't, they will context-switch and make more mistakes. Review your team's definition of done.

If there is some other circumstance you encounter, let me know in the comments and I'll update the post.

Remember, in agile, developers and testers work together to create finished features. Go back to Part 1 and look at the agile picture. You might need writers, DBAs, UX people, whatever. The team works together.

If you look for surrogate measures, such as test designs or test cases written, you will get surrogate measures. You will not get working software. That's because people deliver the surrogate measures, not working software.

If you want working software, ask for working software. The team's responsibility is to provide working software. What else would a customer need to see and why?

The closer the developers and testers work together, the faster the feedback to each other. The faster the customer can see working product. Isn't that what we want?

In part 4, I'll discuss how measurements about testers change.

Update: The entire series:

1 thought on “How Agile Changes Testing, Part 3”

  1. Pingback: Five Blogs – 15 March 2016 – 5blogs

Leave a Comment

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: