"The problem is not the problem. The problem is your attitude about the problem."
Captain Jack Sparrow
Whether in classic software development projects or in agile ones. The quality of the software is an essential factor for success. Today, a little methodical software testing is no longer enough. The days when the development team simply pushed the application over to the test team are long gone. The hard-core silo separation usually works more badly than well.
If you want to create excellent software today, you have to think of the development process holistically: people, methods, tools and mindset - only when everything works together in a flow, potential development and innovation emerge. In such a development process, quality becomes the attitude of the team. Achieving this is a change process that requires understanding and empathy for everyone involved: Developers, testers, managers or stakeholders.
When I look back at my projects over the past few years, there have always been development teams that have delivered top software quality per se. The secret? The entire team lives the topic of software quality. It is anchored as a culture. Often, the individual team members can no longer name all the quality activities in concrete terms - quality and software testing have become a mindset. Now, such a mindset does not fall from the sky. It is a path, a transformation, to get there. For each team, this path is very individual. Nevertheless, certain milestones can be identified over time that take quality to the next level.
Basics - Using Software Testing Fundamentals
The first boost on the way to a quality-conscious attitude seems quite simple at first glance: The use of proven test methods and approaches. As described, for example, in the ISTQB Certified Tester or comparable standards and in the technical literature:
- Defining a test strategy (test objectives, test levels, test types)
- Use of structured test case methods such as equivalence class formation or decision tables up to model-based approaches
- Use of static analysis tools for code, data and documents
- Ongoing reviews of code, architecture, etc.
- Stable test automation on different levels
This all makes sense, and the benefits of these activities have been a no-brainer for many years. But reality tends to look different. No time, no resources or "what do we need this for anyway?". Especially in agile projects this is sometimes ignored. It doesn't have to be a 100-page test concept. But it can't hurt to sketch out on a whiteboard what you want to test, where and how.
Reflection - what are we actually doing here?
At the latest when the basics are established, usually even earlier, the next stage begins. Reflection in the team. Whether as a regular retrospective or as an occasional workshop. When the team begins to evaluate, control and optimize quality activities itself, things get exciting. Because now, with self-organization and responsibility, a path begins to unfold from the best practices of others to the team's own.
I observe again and again what kind of force arises from this. But also friction. And conflict. That is part of it at this point. The art as a manager, test manager or quality coach is to guide this into a constructive process. Most of the time, this phase arises from problems. Reasons are e.g. missing test infrastructure, miserable test data, bad performance during test runs. Inevitably, project boundaries are also overcome here, and support from outside (operations, specialist department, etc.) is often required to move forward. Once these have been solved, the next step is to optimize and further develop the test activities. Reflecting on one's own processes and topics also changes the group dynamics. Existing issues are questioned and motivation often increases, turning "we have to test" into "we want to test".
Experiments - trying out new things
With the self-confidence of being able to move more as a team, courage also grows. And with it, a further level of quality can be achieved. Mostly out of reflection, completely new ways are tried out for which there are hardly any references. For example, in the area of test automation. The team has an idea, but no proof yet that the idea works and brings a benefit. Therefore, it is tried out as a prototype and "tested". New test procedures or process steps can also be evaluated more quickly through experimentation than through large plans and extra projects. Teams that live this level can often be recognized by how they deal with failures and setbacks from these experiments. Is the tool not delivering the desired results? The architecture change not delivering more testability? The new generator not producing better test data? Experiments involve failure. Successful teams accept that, adjust the tester's hat, and move on.
Mindset - when you no longer talk about it
Over time, a new culture emerges from reflecting and trying out and reflecting again on the test methods, tools, new ideas and process changes. Quality now becomes an attitude. Here, phrases like:
- "I'm done, I just need to test more" or.
- "Time is running out we are saving on software testing".
The focus is on the success of the project: delivering a high-quality product. And testing is part of that. Just like development. Or documenting the most necessary things. And it no longer needs to be explicitly planned, estimated or mentioned. It is simply part of it.
As an example, here is the story of a young startup for which I was asked to conduct a quality assessment. They wanted to know how good they were in the area of testing/quality. During on-site interviews, I kept hearing "No, testing...we don't really do that". One developer said "Um...I don't write extra unit tests". Looking deeper into it, the "truth" came to light. I have rarely seen so many tests, reviews and quality assurance measures in other projects. The team was not even aware of how much they were already doing in this direction. Yes, and "extra unit tests" were not written, so not extra beyond that, which is simply part of software development. I also noticed this mindset during my time at tech companies in Silicon Valley. Quality is integrally lived there. From the first project idea to the launch. Despite or perhaps because of the pressure to get to market quickly, the necessary quality has a high priority.
Transformation - a path, not a work order
Parallels to agile procedures are not coincidental. When it comes to attitude, all the values that make up quality and agility come together. I don't think it's even a question anymore whether this path is being taken. The current and future challenges make it inevitable to evolve as a team and as an individual. Change is coming one way or the other, the question is whether we ignore it in fearful rigidity or actively shape it. And it is precisely in the area of quality, inspection and testing that we have so many resources in our companies to shape. And to establish quality as an attitude throughout.