“The problem is not the problem. The problem is your attitude about the problem.” - Captain Jack Sparrow
Whether in traditional software development projects or agile ones. The quality of the software is an essential factor for success. However, 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 poorly than well.
If you want to create excellent software today, you need to take a holistic approach to the development process: people, methods, tools and mindset - only when everything works together in a flow can potential unfold 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 last few years, there have always been development teams that have delivered top software quality per se. The secret? The whole team lives and breathes software quality. It is anchored as a culture. The individual team members are often no longer able to name all quality activities specifically - quality and software testing have become a mindset. A mindset like this does not just fall from the sky. It is a path, a transformation, to get there. This path is very individual for each team. Nevertheless, certain milestones can be identified over time that will take quality to the next level.
Basics - Using the basics of software testing
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 specialist literature:
- Definition of a test strategy (test objectives, test levels, test types)
- Use of structured test case methods such as equivalence class formation or decision tables through to model-based approaches
- Use of static analysis tools for code, data and documents
- Ongoing reviews of code, architecture, etc.
- Stable test automation at various levels
This all makes sense, and the benefits of these activities have been a no-brainer for many years. But the reality is often different. No time, no resources or “why do we need this at all?”. 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?
Once the basics have been established at the latest, and usually even earlier, the next stage begins. Reflection within the team. Whether as a regular retrospective or as an occasional workshop. When the team starts to evaluate, manage 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 your own.
I keep observing the power that arises from this. But also friction. And conflicts. That’s part of it at this point. The trick as a manager, test manager or quality coach is to channel this into a constructive process. This phase usually arises from problems. Reasons include, for example, a lack of test infrastructure, miserable test data, poor performance during test runs. Inevitably, project boundaries are also overcome here, and support from outside (operations, specialist department, etc.) is often needed to make progress. Once these issues have been resolved, 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 achieve more as a team, courage also grows. And this allows a further level of quality to be achieved. Mostly as a result of reflection, completely new approaches 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 benefits. It is therefore tried out and “tested” as a prototype. 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. Does the tool not bring the desired success? The architecture change does not improve testability? The new generator does not provide better test data? Experiments involve failures. Successful teams accept this, adjust the tester hat and move on.
Mindset - when you no longer talk about it
Over time, a new culture emerges from reflecting on, trying out and re-reflecting on test methods, tools, new ideas and process changes. Quality now becomes an attitude. Phrases like:
- “I’m done, I just need to test more” or
- “Time is running out, we’re saving on software testing”.
The focus is on the success of the project: delivering a high-quality product. And testing is part of this. Just like development. Or documenting the essentials. And it no longer needs to be explicitly planned, estimated or mentioned. It’s simply part of it.
One example of this is the story of a young start-up for which I was asked to carry out a quality assessment. They wanted to know how well they were doing 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, the “truth” came to light. I have rarely seen so many tests, reviews and quality assurance measures in other projects. The team wasn’t even aware of how much they were already doing in this direction. Yes, and “extra unit tests” were not written, i.e. nothing extra beyond what is simply part of software development. I also noticed this mindset during my time at tech companies in Silicon Valley. Quality is an integral part of life there. From the initial 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 instruction
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 there is any longer any question of whether this path is being followed. The current and future challenges make it essential to continue developing as a team and as individuals. Change is coming one way or another, the question is whether we ignore it in fear or actively shape it. And we have so many resources in our companies to shape quality, inspection and testing in particular. And to establish quality as a consistent attitude.
Frequently Asked Questions
Why isn’t it enough to simply hand off the finished software from the development team to a testing team?
Strict silo separation usually works more poorly than well. If you want excellent software, you need to take a holistic view of the development process: people, methods, tools, and mindset must all work together. Quality then becomes the team’s mindset rather than the responsibility of a downstream department. The path to this is a process of change that requires understanding and empathy for developers, testers, managers, and stakeholders.
Does an agile team need a fully formulated test plan?
A 100-page document isn’t necessary. However, it does help to sketch out on a whiteboard what should be tested, where, and how. The proven fundamentals remain the same: test objectives, test levels, and test types; structured test case methods such as equivalence partitioning or decision tables; static analysis of code, data, and documents; ongoing reviews; and robust test automation at multiple levels.
What changes when a team evaluates its own quality activities?
A unique approach emerges instead of simply adopting others’ best practices. As soon as a team takes control of and optimizes its own testing activities during retrospectives or occasional workshops, self-organization and accountability grow. Existing practices are questioned, group dynamics shift, and motivation often increases: “We have to test” turns into “We want to test.”
Are conflicts a bad sign when a team questions its test processes?
No, friction and conflict are part of this phase. It usually stems from specific problems: a lack of test infrastructure, poor-quality test data, or poor performance during test runs. The role of a leader, test manager, or quality coach is to guide this into a constructive process. This often requires support from beyond the project’s boundaries—for example, from operations or the business unit.
How do teams deal effectively with failed experiments in the testing environment?
They factor in failures and keep moving forward. Anyone breaking new ground in test automation, test techniques, or process steps has no proof of the benefits—that’s why we have prototypes. If the tool doesn’t deliver the hoped-for success or a new generator doesn’t produce better test data, that’s accepted. Experiments evaluate such ideas more quickly than grand plans and special projects.
How can you tell if a team has made quality a way of life?
By the fact that it’s hardly ever discussed anymore. Team members often can’t even list all their quality activities because testing is a natural part of development and is no longer specifically planned, estimated, or mentioned. Phrases like “I’m done; I just need to test it” or “Time is running out; let’s cut back on software testing” disappear.
Does quality suffer when there’s pressure to get to market quickly?
Not necessarily. During a quality assessment at a young startup, the initial feedback in the interviews was that testing wasn’t really done that way. In fact, there were more tests, reviews, and quality assurance measures there than in many other projects. Even at tech companies in Silicon Valley, quality was an integral part of the process from the initial project idea all the way to launch.
