“The problem is not the problem. The problem is your attitude about the problem.”
(Captain Jack Sparrow)
Traditional project or agile, it makes no difference: software quality is a key factor in success. But a bit of methodical software testing no longer does the job. The days when the development team simply pushed the application over the wall to the test team are long gone. Hard silo separation usually doesn’t work very well anyway.
If you want to build excellent software today, you think about the development process as a whole: people, methods, tools and mindset. Only when all of that plays together in a flow can people unfold their potential and can innovation happen. In a development process like that, quality becomes the team’s attitude. Getting there is a process of change, and it needs understanding and empathy for everyone involved: developers, testers, managers and stakeholders.
When I look back at my projects over the last few years, there were always development teams that simply delivered top software quality. The secret? The whole team lives software quality. It is anchored in the culture. Often the individual team members can’t even name all of their quality activities anymore, because quality and software testing have become a mindset. Of course a mindset like that doesn’t fall from the sky. Getting there is a path, a transformation, and that path looks different for every team. Still, you can pin down certain milestones along the way that take quality to the next level. I describe four of them here: basics, reflection, experiments and mindset.
Basics: Put the Fundamentals of Software Testing to Work
The first boost on the way to a quality-conscious attitude looks quite simple at first glance: using proven test methods and approaches, as described for example in the ISTQB Certified Tester scheme, comparable standards and the literature:
- Defining a test strategy (test objectives, test levels, test types)
- Using structured test techniques such as equivalence partitioning or decision tables, all the way to model-based approaches
- Using static analysis tools for code, data and documents
- Ongoing reviews of code, architecture, etc.
- Stable test automation at several levels
All of this makes sense, and the value of these activities has been a no-brainer for years. Reality, though, tends to look different. No time, no resources, or “why do we even need this?”. Agile projects in particular sometimes just leave it out. It doesn’t have to be a 100-page test plan. But sketching on a whiteboard what you want to test, where and how, can’t hurt.
Reflection: What Are We Actually Doing Here?
Once the basics are in place, and usually even earlier, the next stage kicks in: reflection within the team, whether in regular retrospectives or the occasional workshop. Things get exciting when the team starts to evaluate, steer and improve its quality activities itself. With self-organization and ownership, a path opens up that leads away from other people’s best practices toward the team’s own.
I keep seeing how much energy this releases. But also friction. And conflict. That comes with this stage. The art for a manager, test manager or quality coach is to channel it into a constructive process. This phase usually grows out of problems: missing test infrastructure, lousy test data, poor performance in test runs. Inevitably, it crosses project boundaries, and moving forward often takes support from outside (operations, the business side, etc.). Once those issues are solved, the focus shifts to optimizing and developing the test activities further. Reflecting on its own processes and topics also changes the group dynamics. The status quo gets questioned, motivation often rises, and “we have to test” turns into “we want to test”.
Experiments: Trying New Things
With the confidence that the team can achieve more together, courage grows too. And that opens up a further level of quality. Usually as a result of reflection, the team tries completely new approaches that have hardly any references yet, in test automation for example. The team has an idea but no proof yet that it works and pays off. So it gets tried as a prototype and “tested”. New test procedures or process steps can also be evaluated faster through experiments than through big plans and separate projects. You can often recognize teams at this level by how they handle failures and setbacks from these experiments. The tool didn’t bring the hoped-for success? The architecture change didn’t improve testability? The new generator doesn’t produce better test data? Experiments include failures. Successful teams accept that, straighten their tester hats and carry on.
Mindset: When Software Quality Goes Without Saying
Reflecting, trying things out and reflecting again on test methods, tools, new ideas and process changes gradually creates a new culture. Now quality becomes an attitude. Sentences like these disappear:
- “I’m done, I just need to test it” or
- “Time is running out, let’s cut back on software testing”.
The focus is on the success of the project: delivering a high-quality product. Testing is part of that. Just like development. Or documenting what really matters. And none of it needs to be explicitly planned, estimated or mentioned anymore. It’s simply part of the job.
A good example is a young startup that asked me to run a quality assessment. They wanted to know how well they were doing on testing and quality. In the 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”. When I looked closer, the “truth” came out. I have rarely seen that many tests, reviews and quality assurance measures in any project. The team wasn’t even aware of how much it was already doing. And yes, no “extra unit tests” were written, meaning nothing on top of what is simply part of developing software. I saw the same mindset during my time with tech companies in Silicon Valley. Quality is built into everything there, from the first project idea to the launch. Despite, or perhaps because of, the pressure to get to market fast, the necessary quality has a high priority.
Transformation: A Path, Not a Work Instruction
The parallels to agile ways of working are no coincidence. When it comes to attitude, all the values that make up quality and agility come together. I don’t think the question anymore is whether this path will be taken. Today’s and tomorrow’s challenges make it unavoidable to keep developing as a team and as individuals. Change is coming either way; the question is whether we freeze in fear and ignore it or shape it actively. And especially in quality, reviewing and testing, we have so many resources in our companies to shape things here. And to establish quality as an attitude, all the way through.
