How Traditional Testers can move to Agile

When software testers first encounter agile, they can be intimidated by all the terminology and technology. A better way to understand testing is to answer a few fundamental questions. It’s a good idea to not accept any answers, even when they are widely adopted, at face value. You should try to find the answers for yourself and keep checking if there are alternative explanations.

Any discussion on testing in agile teams is dominated by test automation. The rationale for test automation is that it allows you to release software often, often many times a day. If you parse that sentence, what automation does is to make sure that what was working before continues to work. I don’t want to disparage automation. However, I think it should be considered separately from the other philosophical issues that are presented here.

There is a common idea in agile to not have test managers. I won’t address that in this discussion.

What is agile (mini version)

There is a lot in agile that testers can benefit from. However, I’d like to focus on the most challenging (and relevant) part for testing. Agile consists of a series of iterations. Within each iteration, the team completes multiple small slices of software, called user stories, which provide end user functionality. This is different from breaking up a large task into smaller tasks or a traditional project management task break down. An example of breaking up a large task into smaller tasks might result in creating a text editor, like Notepad, with a menu system which doesn’t really work. Another task would be to add the functionality to the menu system. A (agile) user story on the other hand, would implement a specific function, say cutting text, in it’s entirety. Creating a user story in this manner requires a change in mindset and a combination of strong technical/development and design skills. Another important aspect of agile is that the (in)ability to make changes in the software should not be a barrier, i.e., the software should use design principles that will make the challenge of changes a non-issue.

Questions for testers

  1. Before agile, you would spend 3 months testing a feature with multiple rounds of testing/fixing. Now you may need to test a mini-feature (story) in 3 days. You many not be able to do multiple rounds. How will you handle this? Can you break up any feature into one tenth of it’s original size? Can testing be similarly scaled down?
  2. How do you know you are done? Does ‘done’ have a deeper meaning?
  3. How do you make sure that the software is of good quality? What is the meaning of quality?
  4. What if you aren’t done? If the development of a story is not done, it rolls over to the next sprint. What if the testing is not done? Can you roll over the testing? Does it become a testing story?

Questions for managers

  1. Can testers really tell developers that testing is not done? Is it a binary done/not done?
  2. Can a test manager tell his manager that development is done, but testing is not?

Summary

  1. How do you test in a short/compressed time frame?
  2. How do you know you are done?
  3. What is the quality of the software you have tested?
  4. How do you test without a requirements document?
  5. How do you deal with the situation when you think you aren’t done and the team doesn’t like it? (Tester/Manager)

Remember to question everything and keep looking for alternative answers. Most good testers have answers for these questions.