Living Software Quality as an Attitude

“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.