OK, it is 2022 and we have had the agile manifesto for more than 20 years now. It may seem like a long time. In 2001 there was Java 1.3 and .NET in version 2.
But somehow companies are still struggling with implementing the Agile approach to get quality software done right.
You can even find articles on the Internet that suggest that agile and quality are opposites and you always have to choose one, or at least settle for a tradeoff of sorts. This GitLab report reveals that as many as 56% of developers still perceive testing and quality departments as the main reason for slowing down the dev cycle. Another thing we can learn from the GitLab report is that in many projects, even though development as such is done “the agile way”, testing is still thumb-tacked to the tail end of the process, like an afterthought. Does this match your observations? It does mine.
In this article, I want to share my observations on agility in testing processes.
1. Quality is everyone’s responsibility
First of all, we need to understand and acknowledge that the quality of software is everyone’s responsibility. Everyone who participates in developing an application has an impact on the end product’s quality. And it doesn’t mean that there is actually no single responsible person ,or that the responsibility is diffused. It just means that to get quality software, we need to have good input from all parties involved. Good requirements, good design, good development, and good testing. We also need a well-established approach that promotes built-in quality. We need to know that quality starts at the conceptual stage.
Traditionally, testers or QA engineers are perceived as those responsible for quality. But this is a gross misperception. Testers can only verify if the final product is acceptable to end users, and if it has bugs — raise tickets for dev teams to remove these defects. In fact, we should perceive quality as something built into the process from the very beginning. Keeping high quality of all deliverables: from requirements analysis, through UX design, code quality, to the final product is what will bring the expected results in the end.
2. Test early and test often
In the agile approach to software development, it is crucial to test software as soon as possible and as quickly as possible. To keep this article short, I will not cover any aspects of testing other than testing working code (so I will not say anything about testing requirements, design, etc.).
In general, there are two facets of testing software. One is the code perspective, and the other is the user perspective.
- The code perspective
Testing code is basically connected with building unit, integration, or component tests. There are all kinds of unit/integration/module tests that run in memory and test one or more parts of the application (method, class, component). Tests of this kind usually use additional infrastructure as mocks, test doubles, stubs etc. With such tests we can build a safety net for developers. Also, they are best suited to check the implementation of algorithms or business rules.
- The user perspective
Traditionally, testing from the end user perspective was the main phase for the entire testing effort in waterfall projects. It was glued at the very end of the development process. However, in the agile testing approach, testing is built into the whole development effort. It should start at the same time as the development of new functionalities. For the user perspective, testers should start developing automated end-2-end tests. If the architecture of the application allows for that, a good idea is to consider putting most of the testing on the API level, and then create end-2-end tests just for happy paths.
3. Automate, automate, automate
This will not be a surprise: in agile software development, automation is the key to success. For an application that is developed in iterations and a new version is deployed to the end users every sprint, after each sprint the number of regression tests grows. Those tests need to be executed for each following sprint to verify and prove that the application is still working properly in areas that were not under development in the current sprint. This creates a situation in which regression testing becomes longer and longer from release to release.
A similar situation arises when a developer works with existing code. If there is no easy way to test changes during the development process with unit tests, the only choice is regression testing after all code has been developed.
To cope with such situations, automated tests are needed. And all kinds of tests should be automated. We need to remember that a in well-structured testing suite, most of the testing is done on the unit level. We then have a slew of integration/module tests. Then we have a smaller, but still quite big set of tests at the API level. On top of this pyramid, there is a set of end-to-end tests that are executed through the user interface, testing all layers of the application. The more tests are automated the better. But remember not to repeat yourself. In the best case scenario, developers would use Test Driven Development and user-facing tests would be developed according to Behavior Driven Development scenarios (acceptance criteria).
4. Put human intelligence to work
All right, automation is key, but does that mean we don’t need manual testers anymore? Of course not. We still need manual testers, but they have to do more meaningful work. Instead of constantly executing the same test scenarios, testers in agile need to focus on less structured aspects of testing or those aspects that are not likely to be automated.
- The main area of focus for manual testers in agile should be exploratory testing. Exploratory testing helps to find new defects of the application by allowing testers to explore this application outside strict testing scenarios. With time-boxed and focused exploratory testing, testers can find some rare corner cases that otherwise would not be found.
- Another aspect of intelligent testing in agile is usability testing. This is not a type of functional testing, but still a very important aspect of each application. There is in fact no other way to test usability than just make the assessment manually by a human, and incorporate human intelligence into the process. Usability testers should take a good look at and verify any aesthetics defects that may become apparent, e.g. at different screen resolutions .
5. Continuous improvement
The last, but by no means least aspect of agile testing is continuous improvements. This is something that we always need to remember. While technically part of Scrum approach, this is present in all agile approaches — the [sprint] retrospective.
The role of the retrospective is to assess the process of software development as a whole. The assessment provides feedback information from the team about what went well and what was challenging to them. In cases of good practices, we know that we need to keep following those practices, and more closely.
However, in the case of something that was problematic in the process, we need to find ways to amend practices related to the encountered challenges. When a new approach has been discussed and agreed on, the whole product team should focus on making the transition to the new practice. While following the new way, the team observes how the new process works. During the next retrospective, the team makes another assessment. Rinse and repeat.
Continuous improvement is also implemented through the introduction of new and better technology that may loosen some existing limitations or enhance something that may have been working fine thus far, but will be pushed further going forward.
Agile testing is the new normal. There is no coming back to the waterfall approach in development or in testing. And while the five aspects of agile testing presented above seem to me to be the most important ones, they don’t constitute a complete list of good practices.
Still, to implement agile development right and to deliver quality software on time in an agile environment, these five are crucial. They lay the foundation for smaller and more local enhancements in testing processes. They are also some of the hardest to implement, because many of them are related to people’s mindsets. And the tester’s mindset is an enabler for truly agile testing.