Agile Testing

When we develop with an Agile approach, we will find ourselves needing to test our software as well. Unfortunately, too often Agile developers find themselves developing with Agile but testing with Waterfall. This hybrid mixture creates technical debt, an untrue picture of the project, and a disconnect between the testers and the rest of the development team. To help, this blog details approaches and methods of Agile testing within an Agile methodology.

Agile testing differs from traditional approaches by:

• Involving testers in the entire release
• Continual testing throughout a sprint
• Collaboration and pair working
• Flexibility to change

Minimise technical debt

You need to focus on reducing technical debt. You must aim to Analyse, Design, Develop, and Test a feature within one sprint. Try to not let a feature leak over to other sprints. For example; instead of working on 5 features a sprint and not finishing them or fully testing them, work on 2 features and sign those off.

Involve the testers early as part of the team

Testers are developers, they are not a separate entity. And as such, they should feel part of the development team.  They should have access to the board, the source control, and be involved in any planning or scrum meetings. This is important because you need to reduce the feedback loops.  Lengthy feedback loops create confusion, delays problems, and are inefficient. However, short feedback loops help with clarity, you find problems sooner, and will help boost morale.

Acceptance test-driven development

Acceptance tests must be written before the development of a feature. The testers in the team should write acceptance tests for the developers to test the product as they’re developing it. This will reduce the number of issues, and the test-driven approach will help create a quality and test-driven mindset. These acceptance tests should be written during a refinement session and placed within the user stories.

Have a critical mind-set

You could be the greatest developer in the world, but unfortunately, we all make mistakes with our development. It’s important therein to have a critical mindset. The developers and testers should try to find issues with the product. The discovery of issues during the development will help increase quality and reduce technical debt.

Team code ownership

As an agile team, the whole development (including testers) need to take responsibility for the entire code base. Segmenting responsibility will lead to a disparate solution, with potential problems.  To do this, team members need to peer-review work, test the solution, and when it goes wrong; take responsibility, then rectify it. A blame culture will hurt the development and testing of the product. Try to make time each sprint so other developers and testers understand pieces of code that they’re not specifically working on.

Evaluate and report test results and test progress

First, make sure you are logging the test results and the test progress. And make sure that this is available to the entire development team. By doing this, the whole team should take responsibility for the progress of testing and understand issues.

Communication

Communication is vitally important, as I mentioned earlier, reducing the feedback loops is critical to the development and testing of the solution.  When you can, co-locate, work in the same room, and work together. Key to this is using practices from extreme programming development such as Pair-Programming and Test-Driven development.

Define the definition of done and ready

It is important, as a team to define when a feature is ready (ready for testing) and done (e.g. Signed off). Testers and developers can have different definitions of what is done and ready. Agreeing is important so that issues found in work marked as ‘done’ is agreed as done, and work marked as ‘ready’ is understood as ready. Unfortunately, in agile projects, this miscommunication and confusion can lead to a different perspective of the project performance.

Further References

A lot of this blog was derived from my own experience, but the book Agile Testing Foundations by Rex Black helped formalise and improve this blog.