Testing in an agile team

In a few years, agile methods have become the majority in software development cycles. And their progression is not over yet! These rapid changes create many difficulties, especially in terms of testing, where many companies or teams in charge of development do not know how to implement them.

These problems often stem from a lack of understanding of Agile. When this understanding and the right state of mind are integrated, it is then easier to efficiently implement the approaches and good practices related to testing and more particularly to quality in Agile.

The particularities of Agile

Agile developments have 2 particularities that strongly distinguish them from the traditional V-cycle:

• Agile methods are iterative development methods
• Agile methods propose to deliver only usable and finished versions

Agile methods are iterative development methods

This point is particularly important and is a consequence of a part of the Agile manifesto:

operational software rather than exhaustive documentation.

This is in immediate contrast to the V-cycle, where specifications are completely written upstream before starting development.

In the case of agile methods, the product is delivered and developed by small bricks. The product is in constant evolution. It can be compared to a Kapla tower. The product exists in a version N and then is modified with the addition of a brick, which makes it a version N+1. These frequent and successive small modifications make it necessary to ensure each time that the new version of the product always corresponds to what is expected incremented by its new functionality (the new brick).

It is particularly important to keep this in mind! When agile methods are used, the product, which is frequently delivered, grows and evolves. On the other hand, in the case of the V-cycle, a complete tower is directly proposed. It is therefore not intended to evolve quickly. This difference in paradigm has a strong impact on testing, which must:

• Verify in depth and quickly the behavior of each small modification
• Ensure through a regression campaign that the new functionality has not broken the product
• Update the regression with new (or modified) product features

The first point explains the democratization of exploratory tests, which make it possible to multiply tests in a limited time. In addition, it is worth noting that exploratory tests also make it possible to identify certain regressions or anomalies not yet detected.

The second point shows the importance of automating tests! In fact, regression campaign tests are regularly executed (ideally at least once per new feature (User Story)) and to ensure a sufficient number of tests without jeopardizing the team's ability to deliver. For the morale of the testers it is also essential to automate as much as possible regression campaign tests.

The third point is there to remind us that a regression campaign must be alive and this is especially true for a product that is also alive.

Agile methods offer to deliver only usable and finished versions

This is a particularly important point. The product delivered by the development team is a product composed of finished features.

One of the recurring problems in Agile transformations is the place of testing. Some people see sprints as mini V-cycles, others do development sprints followed by testing sprints This is not Agile! It is neither more nor less than V-cycles of shorter duration.

In Agile, the notion of finished is essential! Even if it differs according to the teams (each team has its own Definition of Done (DoD)) and the evolution of the product (the DoD can evolve between each sprint), it is essential to remember one thing: when a feature is finished, we don't touch it anymore!

Therefore, you must be sure that all the elements necessary for the product are provided at each delivery to be used and continue to evolve.

Read full article here, an article by Marc Hage Chahine.