Agile Testing in Scrum

Last week, we provided an overview of what makes agile testing unique. Now, let look at the different ways testing can be adapted to complement the various agile development processes we see today. Depending on the method of agile employed some companies employ waterfall-like methods, which make the transition easier for more legacy-oriented organizations, and some prefer methods that are more nimble and adaptive to make the most of what agile has to offer.

One of the most popular agile development methodologies is scrum, as it makes for one of the more painless transitions from waterfall. Waterfall and scrum are similar in that both are driven by a requirement or user story defining how features perform and should be tested. But there is a very significant difference: scrum testing is a very iterative process, designed to deliver value in the shorter term.

In scrum, you will answer many more questions up-front compared to waterfall, due to this iterative process. You avoid the trap of building a product with many features requested in advance, only to realize later that the priorities or requirements may have shifted.

Here’s the difference:

  • Waterfall: Feature is requested, feature is written, with little collaboration between the team members. These features are often written without considering potential corner or negative testing scenarios, requiring many cycles of testing and bug fixing to release the product.
  • Scrum testing in agile: Feature is requested, a plan is developed to confirm how it will be tested, feature is then built with foresight and should need to spend less time testing and fixing bugs.

The scrum method is also much more collaborative than waterfall testing. Scrum teams work as a unit, including product owner, scrum master, and a range of developers, automation engineers, and testers. The effort is clearly defined before the beginning of a sprint, and each sprint occurs in smaller, faster iterations (typically 2-3 weeks) compared to waterfall. Daily meetings keep the project on track, followed by a review at project completion to discuss what was learned.

One key element to consider when forming a scrum team is to clearly define the product owner and scrum master. The scrum master is focused on removing barriers to the timely and successful delivery of the product. But it’s the product owner’s job to make sure that the focus of what is developed and tested is closely aligned with the needs of the customer. Since a potential for conflict exists between these two goals, separate team members should be assigned to each task.

But just like agile development, if you follow this approach you can maintain the flexibility to hit the moving targets of evolving customer demands and a complex marketplace.

1 comment on Agile Testing in Scrum

  1. I hadn’t thought of using containers but that’s a great idea. Thanks so much for sharing!

Leave a Reply

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

More Great Content

Get Started with qTest