Quality as an attitude means that software quality is not the task of a single test department, but the shared responsibility of the entire development team. Three factors characterize successful teams: the consistent use of test principles, the targeted use of test automation and a collective quality mindset that permeates every step of development.
Key Takeaways
- Quality is not the task of a test department, but the overall responsibility of the entire team, from development to UX to the product owner.
- Missing unit tests are not a technical detail, but a warning signal for architectural problems that block later refactorings and hide errors.
- Configuring static code analysis as a hard pipeline barrier instead of ignoring its results prevents the creeping build-up of technical debt.
- Test automation without quality test cases only quickly produces worthless tests: 30,000 automated cases can completely overlook deliberately introduced bugs.
Quality as an attitude: why good software starts in the mindset
Quality is not a work step at the end, but an attitude that a team adopts from the very beginning. Over twenty years of testing projects show a recurring pattern: when development and testing teams really work well together and deliver resilient quality, three factors can be recognized. Solid foundations, serious automation and quality as a shared responsibility. Whether the approach is agile or classic hardly matters.
What is part of the test foundations?
The basics of testing have been described for decades, but are often skipped over or not even considered in everyday life. They form the foundation on which everything else is built. Ignoring them means building quality on sand.
The first building block is clean test levels. Unit tests check each unit separately, remain small-scale and provide developers with quick feedback when refactoring. Integration testing shows how components interact and whether the interfaces in the system work. System testing looks at business processes, interfaces and performance from the outside. Acceptance and acceptance tests clarify whether what has been implemented corresponds to what the specialist department actually wanted.
This separation is not an end in itself, but a question of cleanliness. In practice, many integration tests are often included in the unit tests, which then run for half an hour. A feedback mechanism that you wait half an hour for is not one. And the sentence “We can’t do unit testing here, it’s just not possible” is usually a warning signal: is there something wrong with the architecture or the design?
You don’t have to run every test level. But you should think about which quality aspects you really need at which level for your product.
Functionality alone is not enough
Test types answer the question of which quality characteristics you are testing at all. Functionality is almost always a given: What should the system do? There are plenty of requirements for this. The non-functional areas are where it gets thin on the ground.
Usability, performance, reliability, maintainability, portability: these criteria fall by the wayside in many projects because the focus is purely on the function. This comes back to haunt them later. Performance problems are often architectural weaknesses, and it is better to uncover them early on than shortly before the release.
For this to work, non-functional requirements must be defined. “Fast and beautiful” is not a testable requirement. You need something resilient that you can test against.
How do you write a good test case?
A good test case has a purpose, it’s not there just to be there. Structured methods have existed for decades that work at all test levels, from unit testing to acceptance testing.
Equivalence partitioning, boundary value analysis, decision tables and state-based testing are such methods. They follow an idea of how to systematically arrive at effective test cases instead of writing as many as you like.
High code coverage alone is useless if the quality of the test cases suffers as a result. Aiming for 80, 90 or 100 percent is of little help if the tests are weak. Every requirement offers countless test possibilities. Finding the really good ones spans the net with which you catch real errors.
Static analysis is the underestimated quick win
Static analysis finds defects before executable software even exists. It checks source code or documents from the very first moment and is therefore one of the fastest levers for more robustness.
Linting tools or SonarQube check code for vulnerabilities and pattern violations. Integrated into a build pipeline, you can immediately see the quality of your code. Not every finding is a real error, but each one indicates a potential flaw. Corrected early, this results in a solid block of robustness.
The typical mistake in companies: The tools run along, producing hundreds or thousands of issues, and in the end they are ignored. This is the wrong approach. Look at which rules have been violated, fix them selectively and work your way through successively. Otherwise, you will take all these technical debts with you into further development.
Reviews spread knowledge and find errors
Manual analysis is just as much a part of the basics as automated analysis. Code reviews, architecture reviews and pairing find errors and distribute knowledge within the team.
This is one of the most important factors in agile development in particular. When several people look at the code together, everyone is familiar with the parts and the team finds a common basis for how it actually wants to develop.
Automate what can be automated, but not blindly
Test automation is a prerequisite for releasing software frequently. If you want to deliver several times a week or a day, you need a robust test suite that checks enough to keep errors out of production.
The progress is noticeable. Automation at higher test levels used to be a fiddle, and buyers would sit in test rooms for hours clicking through test cases. Today’s tools bring significantly more efficiency here, especially in acceptance tests.
Precisely because automation is so tempting, it is worth taking a look at what can be reasonably automated. If you automate crap, you just get crap faster.
One project had around 30,000 to 40,000 automated test cases. When trying to find out whether the tests were starting by deliberately introducing errors, not a single test case noticed the error that had been introduced. A large number of tests says nothing about their effectiveness.
Quality is a team responsibility, not a tester obligation
Quality is not the job of a single person or a test department to whom finished software is thrown over the fence. The classic model, where errors are returned after three weeks and nobody knows what they were about, no longer works.
Instead, testers, developers, architects, UX designers, requirements engineers and product owners come together as a team and think about quality from start to finish. Everyone takes it on as their own responsibility. In teams that live this, a high level of personal responsibility is created. Nobody says “I’m not interested in testing, let someone else do it”.
Good software today is simply also tested and full of quality.
Richard Seidl
Hard barriers separate good teams from good intentions
Discipline in the pipeline is what characterizes high-performing teams. Static analysis can be built into the build pipeline and evaluated. The difference lies in what happens next.
Optional results that you look at “later” fall flat. There is no hard barrier: if a new defect occurs, a test fails or code coverage drops, the build process does not continue. The red lights go on, the team comes together and fixes the error.
An ignored error rarely remains alone. “I’ll do it tomorrow, after the release” becomes the second, third, fourth bug. At some point, the company is faced with a mountain of legacy software with “TBD” in the comments and nobody knows where anything belongs anymore. Cleaning up these things retrospectively costs a lot more effort than cleaning them up straight away.
How does quality become a matter of course?
Quality as an attitude is a process that takes time and doesn’t happen overnight. It starts with the basics, uses automation and develops a shared self-image of bringing good software into production.
A team needs a suitable framework for this. It is not the project manager who orders quality. It is more effective to lead by example. A quality engineer can coach others, act as a mentor and pass on knowledge, for example from good unit testing to good acceptance testing.
When these three aspects come together, the topic loses its gravity. Instead of sighing “We still have to do testing, who’s going to do it?”, quality becomes a matter of course. This is exactly what makes software long-lasting, instead of it becoming an old hat in ten years’ time that nobody dares to tackle anymore.
