Software testing. Everyone has heard of it, but what does it really mean? In the first episode of our podcast series Back to Basics, we dive into the fundamentals of software testing with experts Jürgen and Günther. Why is testing more than finding bugs? What does quality actually mean? And why should testers be involved in a project as early as possible?
We list it for you.
A logical first question. You test, of course, to find errors, but that’s far from the full story. As Jürgen explains, “You look for errors in an application, yes, but you mainly help the customer achieve better quality.”
Testing is all about improving software to give the end user a good experience. Sometimes that literally means finding bugs and passing them on. But often it’s about much more than that: providing structure, assessing risks, guiding processes, thinking along on analyses and drafting test strategies. So testers are not only sleuths, but also advisors, quality ambassadors and bridge-builders between teams.
For many testers, tracking down bugs is like a sport. And don’t blame them: it’s satisfying when you find something that doesn’t work the way it should. Yet as a tester, you also have to be realistic. Not every bug gets fixed. That may sound contradictory, but it is the reality of software development.
After all, there is always a trade-off: how serious is the bug? Can the user live with it? Is it aesthetic or functional? How much will it cost to fix it? Sometimes a workaround is sufficient and the bug is simply documented. And that’s okay. What matters is that, as a tester, you paint a clear picture of the current quality and potential risks.
Another important insight: testers don’t decide anything, they advise. They run test cases, analyze the results and share their findings. Based on that, the team – or the customer – decides what to do with it. And that advice becomes stronger if, as a tester, you look not only at “does it work or not?” but also at context, ease of use and the bigger picture.
As Günther puts it beautifully in the podcast, “A good test is one that brings out a flaw so we can talk about it.”
What actually is “quality” in software? According to Jürgen, it is not always what you as a tester think is good, but what the customer requests. Even if you think “this could be better,” you have to ask yourself: is this what the customer asked for? Does it work for them?
So testing also means putting yourself in the user’s shoes. Understanding what they need, how they will use the software, and how the solution matches their expectations.
And at the same time, as a tester, you may also advise. Think of small improvements that improve the user experience, such as a search function in a drop-down list. These are things that the customer may not have asked for, but they do help them do their work more efficiently. That, too, is quality.
Testing is not something that you quickly add “at the end”. It is a structured process with three major components:
This structure has remained the same for decades, but the interpretation evolves with time and context. For one client, the focus will be on speed, for another on comprehensiveness. And for one organization, the bar is set at 80% coverage, for another at 100%. The important thing is that everyone has the same expectations, and that the testing goals are clear.
Testers ≠ developers (but we work together)
A common confusion: testers do not debug. Debugging is a job for developers. But testers can help tremendously. By providing clear test cases, documenting well what they did, and analyzing the error together with the developers, you as a tester help to find the cause of the problem faster.
It’s a collaboration: testers detect, developers analyze and fix. And together they take quality to the next level.
The answer is simple: as early as possible.
Ideally, the testing process should start at the analysis stage. Testers then help think about feasibility, help sharpen acceptance criteria and ensure that there is quality in the process from the beginning. We also call this shift left testing: moving testing to the beginning of the software lifecycle.
Yet in practice, we often see the opposite: testers don’t show up until the end. The result? Too little time, unclear documentation, and many last-minute bugs. This causes stress, time pressure and errors.
Because fair is fair: you can’t test everything. There’s always a deadline, there’s always time pressure. That’s why risk analysis is so important. What are the risks if we don’t test something? What are the possible consequences? By looking at that in advance, you can test in a more focused way, and make better informed choices when time is tight.
And that doesn’t just help with testing itself. It also creates more awareness among the entire team about what really matters.
In Agile projects, software is delivered in pieces (sprints). This is ideal for testing during the development process. But that only works if testing is also part of that cadence. Testers must be present during sprint planning, so they know what is coming up, what needs to be tested and what is required to do so (such as test data or specific test tools).
And it helps if at the end of the cycle there is a sprint with no new features – purely to test and stabilize. That doesn’t always happen, but it makes a world of difference.
Software testing is much more than bug-finding. It is a field where collaboration, communication and insight are key. It’s about quality, managing risk, improving processes and working with customers to make better software.
The technology and tools are important, but ultimately it is the people who make the difference.
Would you like to know more about how software testing can help your organization to deliver better digital products? Or are you curious how M2Q can support you in this? Please feel free to contact us at info@m2q.be – we would like to think along with you!
This episode can be listened to not only through our website, but also through your favorite podcasting platforms: Apple Podcasts and Spotify
