A view from the outside

Software testing is the discipline of specifically checking whether software works as it should and finding errors in the process. Good testing requires a clear clarification of the task: What is being tested and what should the outcome be? Errors are not a flaw, but a source of learning from which both product quality and development processes can grow.

Key Takeaways

• Clarification of the assignment is the basic prerequisite for meaningful testing: If you do not clarify what is to be tested and what result is expected, you end up solving a different problem than the original one.
• Errors that are discovered late in the project cost significantly more because development, design and testing then have to be redone.
• A central skill of testers is relevance recognition: quickly grasping what is important in an unknown system and where the focus needs to be placed.
• Learning from mistakes means two things: product errors directly improve the software, process errors show where the process itself is stuck, and both types are too rarely systematically followed up.

Software testing is a blind spot for outsiders

Many people don’t know that software testing even exists. They imagine that software is developed, then it is there and simply runs. The fact that there are teams and specialists in between who check whether the software really works is completely out of the picture.

People who have nothing to do with IT usually think of programmers or developers when they think of software, often accompanied by the cliché of the nerd. Testing does not feature in this image at all. It is an expertise that works in the background and remains invisible.

Yet it involves real expertise. It’s not just about checking whether something works, but also about finding errors, asking the right questions and writing the right tests. This work is demanding, even if it is hardly noticed from the outside.

Why clarifying the order is crucial to success

Before testing can begin, it must be clear what is to be tested. It is precisely this step that is often skipped in software development. Tests are carried out, requirements are ticked off, but the why remains unclear.

In coaching, there is a well-established procedure for this. A client comes with a concern, tells their story and then there is a large section called clarifying the assignment. This is where it is determined what the problem is, where the path should lead and how success can be measured. The same logic applies to testing: what do we want to prove and what should the end result be?

If this clarification is missing, testing is simply carried out at random. Problems then emerge late, often only towards the end of a project. This is exactly when it becomes expensive, because things have to be redeveloped or redesigned.

This whole quality check is aimed at proving certain things, and these must be clear at an early stage.

Richard Seidl

The map change: when the wrong problem is solved in the end

In coaching, a change of map describes the moment when the level is changed unnoticed and a different problem is solved in the end than the one agreed. The result can sound appealing and still fail to achieve the objective.

An example makes this tangible. A client wants to lose weight, the goal is clearly defined: how much, by when, how he will notice it. If at the end of the process the desired weight is not achieved, but the realization “I can love myself as I am”, then the level has been changed. The original task remains open and the problem is very likely to resurface.

Applied to software projects, this means that if you are sloppy in clarifying the assignment, you run the risk of realizing late in the project that you have missed the actual goal. The clearer the assignment is clarified at the beginning, the smaller this risk is.

Recognizing relevance is the core competence of good testers

Good testers quickly recognize what is relevant and what the focus needs to be on. They enter an unfamiliar space, see through structures and processes and know what is important, even if the field is new to them.

This can be compared to finding your way around a large, unfamiliar airport. While some are still looking for the display board, others are already heading in the right direction. This ability to immediately recognize relevance carries over into many situations, including conversations, where it quickly becomes clear what is relevant and what is not.

A second strength is recognizing patterns and algorithms. Testers see through systems and their architecture and transfer classic error traps, which they know from experience, to new contexts. This leads to the right questions.

Talent is just the icing on the cake, the rest is practice

Talent alone does not make a good tester. As with any top performance, it is only the smaller part. In sport it is training and discipline, in testing it is mainly practice and experience.

Those who quickly familiarize themselves with a topic often do so less from memory than from a trained grasp. Skim a few pages, grasp the pattern, explain the topic: This succeeds because a lot has been tested and a lot has been solved over the years. This routine replaces the necessary knowledge.

Anyone who also engages in interdisciplinary exchange expands their wealth of experience beyond their own subject. Stories from other domains provide new perspectives that can be applied to your own work.

Mistakes are helpers, not flaws

People learn most from mistakes. A child learns to walk by falling down and getting up again without judging the fall as a failure. As we grow up and in our society, this attitude often changes: mistakes become flaws that should not be allowed to happen.

When testing, dealing with mistakes directly improves quality. It is worth putting energy into the cause instead of building workarounds. If you just patch over it instead of properly understanding what is going wrong, you are only shifting the problem.

The Photoshop example shows this mechanism from the user’s perspective. Over the years, the software has become increasingly voluminous and sluggish because functions were seemingly just added on instead of being properly worked through. Slimmer competitor programs suddenly ran smoothly and easily. Those who take errors and maintainability seriously avoid this path.

Product errors and process errors need different answers

When learning from errors, it is worth distinguishing between two types. Both are often just shoved into the backlog archive and hardly looked at again, but there is a lot of learning potential in both.

In recent years, agility has shown how valuable it is to look at process errors. Retrospectives reveal where things are stuck in the process and make the next run better.

Both types of error are about the same question: where do the errors come from and how can they be reduced in the future? You will never stop them completely, but you can always improve.

The trade-off between new features and maintainable software

There is a constant conflict in projects: creating new features versus maintaining existing ones. The market and customers want new functions, but at the same time the software must remain maintainable.

The real task is to maintain a balance between the two. If you neglect maintainability, you end up with a juggernaut that no longer works well. This is precisely the pattern that can be observed in many companies.

What testers learn from real-life use cannot be planned in advance

Some findings only emerge when users use the software for the first time. Then it becomes clear where they click and what they do, and the whole project team is amazed at things that nobody had thought of before.

The frequent reaction to this is a reflex: everything must be specified, everything must be precisely defined. This approach rarely leads anywhere. It makes more sense to start interacting earlier and observe what the user actually does with the software.

More can be learned from such situations than from any detailed planning. No matter how much time and budget you have, you cannot predict which device, which input or which detour a user will choose. The comparison with raising children is apt: You can’t play through every possible mistake in advance, you keep the framework and deal with the mistakes when they occur.