Good testers get better by looking at the application through the customer’s eyes and by using proven test methods creatively. This piece from 2013 shows where testers still have room to grow beyond test process improvement.
There’s no question about it: structured software testing has established itself as a profession in IT. Hardly any company can afford not to test, whether because of growing system complexity, specifications and regulations, or users’ ever higher expectations of quality. The German Testing Board, the Gesellschaft für Informatik e.V. and the Arbeitskreis Software-Qualität und -Fortbildung e.V. have been preaching testing and quality for years, and in Germany in particular it has paid off. In mid-2012, 25,000 of the 240,000 ISTQB certified testers worldwide were in Germany alone. The market paints a similar picture: there’s a dense and broad range of service providers and consultancies focused on software testing, from small local firms to global corporations. And demand for professional testers remains high, as the many open positions show. While some organizations are only starting to structure and professionalize their testing, others are already ready to tackle topics like test process improvement. Those models are mature, too, and keep getting better. Even if testers always look at this with a critical eye, we can say it: “Testing made in Germany”? Yes, we do it well!
…and we want to get better! Beyond everything test process improvement offers us, there are other areas where testers still have a lot of potential.
The Customer’s View
In the end, software is always built for users, whether that’s an end customer or someone in a business department. Even when every functional and non-functional requirement has been checked, that doesn’t mean the user is satisfied. Yet that’s the goal of testing. As a tester, you should step away from the defined test concepts and test case lists every now and then, so you can look at the application freely, without outside guidelines. Is the solution usable? Is it easy to use? Is it fun to work with? Does it help the user? It’s easy to accept the technical solution as a given and never ask whether it makes sense at all. There are countless programs, for example, that are packed with configuration options nobody ever uses. As a tester, you have to dare to take this outside view and point out things that may not be stated explicitly in the requirements, even if that means pushback and discussion.
Creative Use of Test Methods
Testers usually face lots of challenges and little time. To deal with them, there’s a well-stocked set of tools and methods. You can apply them by the book, but the real potential lies in using them creatively. With new ideas, a look beyond your own field and common sense, you can write much better test cases and find more defects. How about a one-hour session where the team collects equivalence classes together? Or a coffee with the business department that ends with two state diagrams? In automation, too, not every case needs to go into the big test automation suite if a small script does the job, and does it faster. And you don’t have to solve every problem yourself. Plenty of answers are out there on the internet, or simply with another tester or developer. Just ask!
Creative Testing Doesn’t Require an Agile Approach
Testers who work in agile teams will recognize this. Feedback and constant exchange with each other encourage creativity and understanding. Short sprints call for quick solutions. The relentless transparency of daily meetings exposes long, drawn-out problem discussions. And testers and developers on the team are kept aligned on one goal: delivering value to the customer.
You don’t necessarily need an agile approach for that. Much of it works in traditional projects too, because it comes down to attitude and mindset. As a tester, I can always decide to do things differently than before: not just working through test cases, but looking beyond them, developing ideas, discussing solutions, and pointing out shortcomings even when they aren’t based on written requirements.
Frequently Asked Questions
Why can companies hardly afford to do without structured testing anymore?
The 2013 article cited three drivers: the increasing complexity of systems, requirements and regulations, and users’ rising quality expectations. Software testing had thus established itself as a distinct profession within the IT industry. This was also evident in the market: service providers and consulting firms specializing in testing ranged from small local providers to global corporations.
How firmly is software testing established as a profession in Germany?
In 2012, Germany accounted for a strikingly large share of certified testers: Of the 240,000 ISTQB-certified testers worldwide, 25,000 worked in Germany alone. The article attributed this to the long-standing efforts of organizations such as the German Testing Board, the German Informatics Society, and the Working Group on Software Quality and Training. The demand for professional testers remained high at that time.
Is a test successful if all functional and non-functional requirements have been verified?
No. Verified requirements do not mean that the user is satisfied, and that is precisely the goal of testing. Software is always created for people, whether they are end customers or departmental staff. That’s why questions such as the following are essential: Is the solution usable? Is it easy to use? Does it actually benefit the user?
Should testers also report issues that aren’t listed in any requirements?
Yes. A tester should take an outside perspective and point out issues even if they aren’t based on written requirements, even if resistance and discussions are to be expected. Those who simply accept the technical solution as a given no longer check whether it makes sense. Example: Programs full of configuration options that no one ever uses.
How can traditional test design methods be used more creatively?
Methods can be applied exactly as written, but a creative approach holds more potential for better test cases, and thus more defects found. Examples include: a one-hour brainstorming session with the team on equivalence partitions, or a coffee break with the business unit that results in two state diagrams. And not every problem has to be solved on your own: ask other testers or developers.
Does every test case have to be included in the large test automation suite?
No. If a small script serves the same purpose and is ready faster, that’s sufficient. The article argued for using tools and methods based on common sense, rather than formally forcing every case into the existing automation solution. Testers usually face many challenges and have little time, which calls for pragmatic solutions.
Do we need agile projects for testers to work more creatively and closely with customers?
No. Agile teams certainly facilitate this: constant feedback fosters creativity and understanding, short sprints force quick solutions, and daily meetings reveal when people are spending too much time mulling over problems. However, much of this can also be implemented in traditional projects, because attitude and mindset are what really matter. A tester can decide at any time not just to work through test cases, but to develop ideas and discuss solutions.
