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.
This inexorably includes:
- Tests to validate the new functionality
- The unit tests of the developers
- All documentation deemed necessary
- Regression tests related to the new functionality
- The software in its new version…
Therefore, it is inconceivable to consider the product finished if it has not been tested. The test sprints outside of development are therefore totally anti-agile… This is perfectly understandable when the development team is working in Agile, when it has done a certain amount of work and when it cannot absorb any more workload (nor a workload that cannot be anticipated). This situation necessarily occurs when a test campaign is carried out on the product.
Similarly, sprints cannot be V-cycles. This mode of operation creates a huge risk: that of not delivering anything. We must also not forget the difficulty in identifying the reason for regressions if they appear when the product has undergone numerous modifications (several US instead of one).
Examples of testing practices in an agile team
In order to adapt to agile methods, testing has adapted! There is obviously the implementation of automation and the emancipation of exploratory tests but not only!
Among these good practices there are in particular :
Contrary to the V cycle where it was possible to review specifications upstream of developments, Agile does not propose exhaustive and precise documents upstream of sprints. Nevertheless, there are requirements identified, described and prioritized by the business or its representative (the PO or Product Owner in Scrum). These requirements are generally in the form of User Stories and can be the subject of reviews with the aim of synchronizing on the requirement and having a common understanding. This is the whole purpose of the BDD! The different actors (the PO, a tester and a developer for the 3 amigos) get together and illustrate the User Story with examples to describe the expected behavior.
I’m talking about “DevOps” here, but in general we could talk about “continuous testing”, “ shift right” or simply interactions between different actors. The idea here is to know the whole chain of our product from the identification of the need to the use in production through development and testing. In order to ensure this communication and tests fluidity, a continuous integration chain including tests of different types is generally set up.
Peer testing is an interesting practice where a tester assists the developer while the latter develops. This allows for exchanges and the identification of potential anomalies at a very early stage.
Peer programming is not necessarily an Agile practice (like peer testing) but is mainly found in these environments. The principle is to have a duo (or more for the “mob”) of developers with one person writing the code and the others serving as reviewers. This allows newcomers to gain skills but also to propose code with fewer defects.
Software craftsmanship is an approach to development where the quality of the design is paramount. Software must be well designed and developed. For this, many development practices to ensure good quality are put forward. I am thinking in particular of TDD ( Test Driven Development)
There are obviously many other practices related to software quality in Agile that can be particularly effective depending on the context.
Testing in an agile team, in summary
Agile testing and product quality are not only the prerogative of testers! A quality product is the result of the investment of all the actors working on it. There are many good practices and you have to know how to select the most relevant ones in your context. It is important to note that “automation” is not part of the “good practices” proposed, because beyond a practice, automation is above all a step that is very quickly necessary in the construction of any software with agile methods. There are obviously good practices related to automation but this could be the subject of one or more dedicated articles!
No strings attached. Only good tests.
BONUS: the tests scenarios you create during your trial period can be replayed with ATS, our Open-Source backbone, for free and forever.