Make sure to read the first part of this series: “Agile Transformation, how you can organize your QA teams accordingly”
Transitioning into an agile practice can be a challenge for testers. It’s understandable, given the fundamental differences in testing mindsets. As such, many testers and QA engineers find themselves helpless when they join an agile team or Feature Team. This results in common objections expressed by testers and QA engineers like:
“We have to re-test everything at each iteration…”
“Developers work for 10 days and then everything is thrown to the tester 2 days before the demo!”
“How to properly test with such short iterations? Impossible.”
“There is no specification… How to define the test plan?”
These difficulties to adapt mainly stem from the fact that QA engineers maintain the same role as before, but in a completely different environment. Some key differences include:
- Rather than work alongside other QA engineers, they are the only QA engineer on the agile team.
- Development timelines are short, typically between one and four weeks, testing activities included.
- There is no longer a formal or exhaustive specification.
Without a change in mindset, QA engineers are likely to feel powerless and discouraged by the agile transformation taking place. So what can they do to leverage the potential of agile and maximize their positive impact in their role? It can be as simple as this two-step process:
- Ensuring that quality is everybody’s duty on the team.
- Promoting prevention rather than correction.
In addition, the whole QA department must adapt to the model of Feature Teams. This will be the subject of the next article.
1. Ensuring that quality is everybody’s duty on the team
Quality is a permanent, global concern for all team members of an agile organization. However, getting everyone to buy into this idea and hold themselves accountable is not easy. One way to get moving in the right direction is to leverage the Scrum methodology.
By far the most widely used framework for scoping agile teams, Scrum provides all of the necessary elements to make this transition. These elements include:
- Sprint Goal
- Definition of Done
- Collective estimations
- Technical tasks
-
Defining a sprint goal
A Sprint Goal means formulating a single, collective goal to be accomplished by the team during the Sprint. This goal helps to bring focus to the team and serves as a self-organization tool to help formulate the best decisions.
To ensure a mutual understanding of quality, the Sprint Goal shifts the focus from the individual to the team. In other words, it doesn’t matter who has tested the product as long as it is tested. The team will be judged collectively on whether or not the goal has been achieved, rather than the means deployed to achieve it. Thus, the Sprint Goal is an extremely powerful lever to create an agile team dynamic in which everyone carries quality.
-
Defining and respecting the Definition of Done
The Definition of Done aims to clarify the meaning of the word “done” and share it collectively with the rest of the organization. The goal is to add a layer of transparency across the organization and avoid individuals taking shortcuts along the way.
Key to the Definition of Done is the way it is enforced. An element can only be marked as “done” if it meets all the criteria for it. The criteria can include quality benchmarks like the level of code coverage of unit tests or functional aspects like which environments the software is being tested on, to what extent, and the types of tests that have been completed.
Thus, the Definition of Done is critical for testers and QA engineers in fulfilling their primary roles (e.g. setting the level of quality expectations for the team) while introducing quality as a team value. Like the Sprint Goal, the Definition of Done is a global and collective responsibility of the whole team.
At the end of the Sprint, only what is “done” within the Definition of Done counts. Either it’s done or it’s not and there is no in between. Completely finishing some elements is more valuable than starting work on new ones.
-
All team members taking part in the collective estimation sessions
Feature teams are comprised of people with diverse skill sets and areas of expertise. While this is an intended benefit, it often takes time for team members to grow comfortable addressing subject matters outside of their own specialty during estimation sessions and regular team exchanges.
This kind of behavior is typical of a feature team that has not yet fully switched to an agile mindset. Successful agile teams are not just built through diversity in backgrounds, but in how they integrate with one another and complement each other’s strengths and weaknesses. The point is that the whole is greater than the sum of its parts.
Under this mindset, QA engineers and testers should be participating in exchanges that do not directly address test or quality issues, just as the rest of the team should be actively involved in exchanges on test and quality. The estimation is the best time to formalize this collective participation and get all team members in sync with each other and their respective backgrounds.
-
Division into technical tasks
Scrum teams are required to maintain a detailed implementation plan of the Sprint. One way to do this is e.g. through a breakdown of all the tasks to be completed for each element of the Sprint. This method comes with many advantages if done properly.
First of all, the division into technical tasks also makes it possible to keep the entire team involved in the planning and creates a whole-team ownership of the tasks to be executed. This also helps visualizing the progress. Of course, this applies equally to tasks related to testing and quality.
Moreover, this breakdown makes it possible to visualize the different skills required to complete a task. For example, a development cycle usually involves testing, while a testing cycle often involves technical configuration and development. By detailing technical tasks, teams give everyone an opportunity to help each other without dictating individual assignments.
2. Promoting prevention rather than correction
The traditional approach to testing and quality doesn’t involve testers or the QA engineer until the end of the development process. As a result, there is minimal time in which to test and deliver feedback, meaning less time to make adjustments or fixes. Whether you follow an agile or traditional approach, an early review of the specifications makes it possible to identify problems early and at a lesser cost.
While analysis and planning early in the process does not necessarily require test execution, testing-related skills and expertise remain an essential asset for the team (e.g. to ensure the testability of each new element from the design stage). Often enough, the main frustration when testing a feature is the lack of consideration for testability at an earlier stage. By integrating the concept of testability earlier into the development process, testing gets easier.
“Building quality ‘into’ the product rather than checking it afterwards”
In the end, it is a matter of shifting mindsets from thinking only about quality at the very end to integrating it into every stage of the SDLC. This can be done through two simple actions:
a) Containing regressions by implementing Test Driven Development
b) Empowering developers by automating acceptance testing
a) Containing regressions by executing Test Driven Development
Some specific engineering practices aim to contain regressions and help implement a mindset of building a high-quality product from day one. This is important to TDD (Test Driven Development), in which developers literally start from the tests to write the code.
Though TDD is a developer’s field of expertise, testers and QA engineers must be aware of this practice, in addition to both unit testing and code coverage. Without an approach to development that directly integrates testing, it is difficult for testers or QA engineers to focus on elements where they can provide the most value.
On a team where developers have not yet adopted such development practices, it is also the role of the tester or QA engineer to lead the way and raise awareness of them by helping the team to understand why they are experiencing regressions.
b) Empowering developers by automating acceptance testing
There are other engineering practices through which testers and QA engineers can add even more value, like structuring acceptance tests or even automating them. In this sense, these practices encourage an even earlier intervention of the tester or QA engineer in the development process.
This approach is known by multiple names including ATDD (Acceptance Test Driven Development), BDD (Behavior Driven Development) or Specification by Example. Many tools exist to automate these acceptance tests including the well-known Cucumber and its language, Gherkin.
With these approaches, the implementation of acceptance tests is integrated into the development flow as a preliminary step. Continuous integration, responsible for performing automated non-regression tests, is also completed to perform these automated acceptance tests, reinforcing this way of working. The role of the tester or QA engineer is therefore integrated as being upstream of the developer’s work rather than downstream.
Beyond the impact on the role of the tester or QA engineer, this approach empowers developers to perform acceptance tests alone and automatically without losing quality. This results in an increase in both the team’s productivity and the quality of its deliverables.
Adapting the QA department to the feature teams model
Read my third article to fully understand the concept of feature teams and learn how companies can work on adapting their QA department to this approach in order to drive a successful agile transformation.
9 min