Living software quality as an attitude 

 24 February 2021

Like it?
Share!

"The problem is not the problem. The problem is your attitude about the problem."

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 whole team lives the topic of software quality. It is anchored as a culture. Often, the individual team members can no longer name all 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 a very individual one. 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 is all plausible, the benefits of these activities have been a no-brainer for many years. But the reality tends to be 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 sketching out what you want to test where and how on a whiteboard can't hurt.

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 starts to evaluate, control and optimize the quality activities itself, it gets exciting. Because now, with self-organization and responsibility, a path begins to unfold from the best practices of others to your own.

I observe again and again what kind of force arises from it. But also friction. And conflict. That is part of it at this point. The art as a leader, test manager or quality coach is now to guide this into a constructive process. Mostly 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 (business, specialist department, etc.) is often needed to move forward. Once these have been solved, the focus is on optimizing and further developing the test activities. Reflecting on one's own processes and topics also changes the group dynamics. Existing things are questioned and often the motivation increases and the "we have to test" becomes a "we want to test".

Experiments - trying out new things

With the self-confidence to be able to move more as a team, the courage also increases. And with that, 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. E.g. 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". Also new test procedures or process steps can be evaluated faster by experimenting than by big plans and extra projects. Teams that live this level can often be recognized by how they deal with failures and setbacks from these experiments. The tool not producing the desired results? The architecture change not adding 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

From reflection and trying out and reflecting on the test methods, tools, new ideas, process changes, a new culture emerges over time. Quality now becomes an attitude. Sentences 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 the most necessary documentation. And it doesn't even have to be explicitly planned, estimated or mentioned. It is simply part of it.

An 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 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 out. I have rarely seen so many tests, reviews and quality assurance measures in other projects. The team didn't even realize how much they were already doing in that direction. Yes and "extra unittests" were not written, so not extra beyond that, which is just 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 believe that it is no longer a question of whether this path is being taken. The current and future challenges make it inevitable to evolve as a team and as individuals. Change is coming one way or another, the question is whether we ignore it in fearful rigidity or actively shape it. And especially in the area of quality, inspection and testing, we have so many resources in our companies to shape it. And to establish quality as an attitude throughout.

Do you like this post? Share it: