Agile Testing - a domain of high performing teams

Little waterfalls and their impact on performance

The testers, developers, Scrum Masters, Product Owners among you reading this article know the problem: the developers are developing for two or even three weeks, the sprint is nearing its end. QA (“Quality Assurance”) still has to stamp the increment as “done” before it becomes official. And then it happens again: A bug was found in the increment, it comes back, and the search for bugs begins. At this moment, everyone’s nerves are already on edge. The sprint goal is at risk. Nobody knows how long it will take, and the customer is impatiently waiting for the new features they were promised multiple times. Will people work nights again to achieve the sprint goal? Will QA have enough time to execute all tests? Or does the team decide to extend the sprint? Sounds like a choice between the plague and cholera. It corresponds in no way to the agile manifesto. And unfortunately, we have seen such scenarios countless times with clients.

The often sequential process of software development with consecutive phases brings many challenges. Incorporating quality assurance at the end of this process is one of them. At Pragtics, we know that this quickly results in a medium-sized waterfall within the actually agile development process. However, quality can be better built into the development and reconciled with the Agile Manifesto. “But how?” The answer is amazingly simple: with Agile Testing.

What Agile Testing means for a company

The reason why many teams and companies exclude Agile Testing is quite simple: the change and the challenges that come with it require courage and openness. Agile Testing redefines the role of QA and developers, requires closer collaboration, and virtually an obsession with quality from the entire team.

Nice, but what exactly do these explanations mean? We are not saying that the changes described here are easy. In the long term, however, they mean:

• happier employees
• higher speed

How are the problems solved? Agile Testing in practice

Software developers build quality control into ongoing development. Every change to the code is tested promptly. No more batches containing many features that have to be tested a few days before the end of the sprint. In the best case, no night shifts for QA and development shortly before the review. Bugs are discovered early in development. The response time is dramatically reduced. The quality of the code and readiness to be delivered increase much earlier. Test Driven Development (TDD) or Pair Programming known from eXtreme Programming (XP) are good starting points in this case. For example, developers and QA write tests together (or their specifications), giving the code to be produced a solid framework. Avoiding long days, lots of collaboration, earlier better results will certainly lead to happier employees. Fail fast faster!

Higher speed is truly a buzzword. Regardless of whether you hear it as a developer, QA engineer, or Scrum Master. Looking at it solely from a skeptical perspective, Agile Testing might even cost more time than the previously practiced waterfall model. Suddenly, you have to sit down together to develop tests, you have many coordination rounds, you might even have conflicts that need to be resolved first. However, if you look at it from the perspective of a feature’s lifecycle, it quickly becomes clear that it is much cheaper to find bugs as early as possible (e.g., during coding) rather than having the customer discover them. Testing at the right time pays off. Literally.

However, the fact that developers and QA engineers write tests together does not mean that QA has nothing left to do. For example, they evaluate features with a focus on quality assurance or are available to developers as consultants for appropriate test strategies. QA also plays a major role in formulating the DoD or acceptance criteria, thereby supporting long-term quality. They view the emerging product through the lens of end-users and often (not always) know much better than developers how the software is used and what can break.

In the end, however, it is the people where one should start, just like with any change. Courage to familiarize oneself with new activities, to experiment and make mistakes in order to learn from them are certainly not the only, but definitely very important prerequisites for Agile Testing. It’s the people who will be the first to ask the most important question: “Why?”. The answer to that should now be easy for you.

‍

Images and other credits!

• Cover image: Photo by David Travis on Unsplash