Quality is everybody's business!

Autor: Richard Seidl

Yes, you can still find them: projects in which the sole responsibility for quality lies with the tester or the test manager, and sometimes, to a lesser extent, with the developer. However, this approach has evolved. Developers are now expected to write productive code, and the agile awakening of the early 2000s has brought positive changes. Yet, many teams still struggle to establish a common understanding of quality ownership. The motto is often, "Behind me comes the deluge," which can sometimes manifest during the release phase.

This used to work well in the past. The projects were manageable, and the systems were relatively simple. Cause and effect were clearly recognizable. In the end, a few tests were enough to instill a sense of security and create the installer on disk. But the world has changed. High-level languages, abstractions, cloud computing, networking, infrastructure, business, and technical requirements – everything has become more powerful and complex over time. All of this places massive demands on quality at all levels.

Faster release cycles, short customer deadlines, and time-to-market are also fuelling projects.  In the end, nothing can be done with a little "testing around".

From Testing to Agile Testing to Agile Quality 

Looking back, it's actually a nice process. First, the testing activities took off: early testing, new methods, getting closer to requirements, and more test automation by developers. Testing became agile testing. But it went further because it takes more than testing to increase and maintain quality. Analysis, reviews, collaboration, and all artifacts in the software development process were involved. Here, too, there is already a lot to show. Everything is also a process of change.

And it becomes more rounded when not only more testers or quality engineers and developers live quality but everyone in the cross-functional DevOps team, including business analysts, UX designers, architects, product owners, Scrum masters, and more.

Living Quality as a Team

And how do you get there? Well, there are several roads to Rome: self-initiative, guidance by an Agile (Quality) Coach, retrospectives, and workshops. However, it's essential to remember that, like many things, this is a change process. It takes time, requires energy, and the right guidance to address and transform reservations, fears, and blockades.

A good start is to bring all participants to a common understanding. Explain what holistic quality means, what it entails to implement quality in DevOps, and create a shared language and understanding that extends beyond quality professionals and developers to encompass everyone in the team.

iSQI suggests:  TMAP®: Quality for Cross-Functional Teams

Establishing this foundation is facilitated, for example, by a seminar or the certification "TMAP^®: Quality for Cross-Functional Teams." The goal here is to onboard everyone, cultivate a unified perspective on quality, and illuminate quality throughout the entire DevOps process, from models and methods to metrics and the integrated CI/CD pipeline. This isn't just theoretical; it involves a substantial amount of practical application as well.

And then the real fun begins: implementing the knowledge gained gradually in day-to-day business.

Until everyone in the team proudly champions quality throughout the entire project! :-)

About our Guest Author

Richard Seidl: Richard Seidl is a software testing expert, Agile Quality Coach, and author. He has seen a lot of software in his professional career: good and bad, big and small, new and old. Software so beautiful that you could cry and also software that makes your toenails curl. For him, it's clear that anyone who wants to create excellent software today has to think holistically about the development process: people, context, methods, and tools - only when everything works together does a mindset for potential development and innovation emerge.

.