Talking about testing seems easy, but talking about quality assurance is a little more problematic — especially in the context of agile and lean software development.
There is sometimes doubt about what quality assurance is, how it differs from testing, and whether it should depend on the context of software development methods.
Therefore, I would like to share the experience our team had when we attempted moving from testing to quality assurance in an agile environment while following lean principles.
Fast, quality, or both?
We all strive for efficiency.
Agile and lean methodologies have been widely promoted as delivering software fast and often.
But what about quality?
We all want quality to be high, but can high quality be assured when delivering software fast?
Yes, it can!
To do this, we need to realize that QA activities must also be agile and lean. Otherwise, we may end up having a fast development team with slow quality assurance. After all, we want to deliver a product that is developed and high-grade, not just developed.
To achieve this, we need to realize that it’s a team of individuals who deliver projects, not the individuals themselves. This means that any problems an individual has also affects (and delays) the whole team.
At the end of the day, we would not be able to deliver the results unless all team members deal with their individual challenges.
The task review phase
At some point our team realized that we have a problem.
Despite thorough code reviews, the code often turned out to be failing because nobody actually ran it.
We discovered the problems only after some time, when the code underwent the testing phase. This meant reopening tasks, fixing the problem, and doing additional code reviews. This also meant another round of testing.
We felt that this process wasn’t right and we should run the code as soon as possible. However, having all reviewers doing that could be a waste of time. This is why we introduced a phase called task review.
Once enough team members have approved the code review, we move the task to the task review phase where we select a task reviewer from the team and let the person do some early verification and testing of the implementation.
The goal is to verify the task’s acceptance criteria and any other requirements.
Yet, whenever reviewers feel it’s necessary, they can follow their intuition and dig deeper into important issues. The point is to start testing as early as possible so any defects we didn’t manage to avoid can be found and fixed. It allows us to reduce any unnecessary overhead, rework, and delays.
The whole-team approach
Although task review doesn’t seem to differ that much from regular testing, it introduces something we weren’t aware of at the beginning — the whole-team approach.
It means all team members are engaged in all project activities, including testing.
The results
So what did we achieve exactly?
First and foremost, we decreased the occurrence of testing bottlenecks.
It’s a common problem that one person is overwhelmed with the amount of testing activities and may not perform them in a timely manner nor do them effectively.
When this happens, tasks start queueing, a bottleneck is created and problems are detected late. Then we start exchanging bugs and fixes, doing more code reviews, and retests.
This situation leads to defects becoming undetected and reduces transparency, which then delays the team and makes everyone rush.
Additionally, after getting a new task, we need to come back and fix the older ones at the same time. And then context-switching and rework knocks at our doors. This is not lean; it’s wasteful.
Now, we test early and often.
The earlier bugs are detected, the easier it is to fix them without unnecessary overhead. The sooner testing takes place, the sooner the team can move towards deployment.
Another key element is scalability. Anyone in the team can take up testing tasks as everyone knows the system and what to do. In case of a heavy workload, any team member can effectively keep the stream of work flowing, instead of being stuck on testing.
Sure, there are still things that should be improved, this is what lean is all about after all.
We had some hurdles along the way, but we tried to resolve them consistently.
We found that it’s important to deal with problems straight away, otherwise they will slow you down as long as they exist. It’s very easy to blame the process for a lack of efficiency while not seeing that there are unsolved obstacles delaying it.
If you want to introduce a process of shared testing activities, it needs to be quick and efficient.
Also, make sure you use proper communication channels to pinpoint any important issues and spread knowledge, such as retrospectives and even day-to-day Slack conversations.
Testing enhances team learning
When working on tasks in isolation, there’s a natural tendency to deprive ourselves of knowledge about other parts of our system.
Now imagine a team where all members know the system’s complexities, dependencies, and risks. Imagine how well they can design their code to avoid related problems. Compare that to a team without such knowledge.
Testing enhances individual learning
Testing not only helps the team learn but also helps you learn as an individual.
Every time a developer detects someone’s problem, there’s a big chance they will not repeat this in their code.
Additionally, as each team member has their own unique skills and points of view, they are able to look at problems differently.
It takes a lot of time for one person (e.g. a tester) to gain those same perspectives and skills, which is why it’s more effective if multiple people with different backgrounds look at the system, compared to just one tester with limited knowledge and skills.
But don’t expect developers to deliver testing expertise just like that. It’s all about contributing to testing, not taking care of all of it yourself.
Checking vs testing
It’s also important that all team members know the difference between checking and testing.
Checking — i.e. verifying that the thing we implemented works as it’s supposed according to Acceptance Criteria or any other form of requirements — can be done by anyone.
Testing is a whole different story.
Since it’s mainly about discovering problems the team was not able to predict, it requires training and knowledge to be fast and accurate in investigations. For clarity, it’s not a matter of a role, but a matter of training.
A culture of quality
Lastly, we started building a culture of quality by making the whole team take responsibility for quality.
This equipped us with multiple individuals, compared to just one person, who ensure quality is high at every stage of project development. People become responsible for the quality of the product, not separate tasks.
To achieve an efficient process of whole-team quality assurance there are some key points that need to be fulfilled:
- Everyone needs to understand why they are testing and what they are looking for. They need to know the process and the purpose. Having people confused may translate to poor efficiency of their testing.
- The testability of the system needs to be good. This relates to how easily we are able to test whatever we want. Each time we struggle to set up an environment, testing data or a system’s desired state to execute tests, we waste the team’s time. We get stuck instead of pushing the delivery forward.
- The system needs to be transparent. When we approach problems, we need to know what is happening exactly. And we need to know it fast. Wasting investigation time on guessing or creating custom configurations to get insights into the system will not do any good.
Fortunately, the problems of testability and transparency may get addressed more quickly once the team members have encountered them first hand.
As quality specialists, we use our overall knowledge about quality to facilitate the development and make sure quality is assured with the highest ROI possible.
Also, as trained and experienced testing specialists, we oversee testing activities while also taking care of accurate exploration of the system to look for the remaining intricacies.
We plan testing, identify testing needs, and provide the team with any required support. The concept of the whole-team approach is not about delegating testing, it’s about the fact that quality cannot be assured alone — at least not in an effective way.
The holy grail of quality
So, did we find the holy grail of quality?
Definitely not.
The task review phase is just our idea of how to introduce the concept into our team. There are still plenty of things to improve. There may also be more efficient and better suited ways.
Nonetheless, the concept proves to be working. We simply need to make the best of it.
