It is undisputed: structured software testing has established itself as a profession in the IT industry. Hardly any company can afford not to test, whether due to the increasing complexity of systems, specifications and regulations or the ever-increasing expectations of quality on the part of users. Whether German Testing Board, Gesellschaft für Informatik e.V. or Arbeitskreis Software-Qualität und -Fortbildung e.V. - the prayer wheels for testing and quality have borne fruit, especially in Germany. In mid-2012, there were 25,000 of the 240,000 ISTQB certified testers worldwide in Germany alone. And a look at the market paints a similar picture: the density and range of service providers and consulting firms with a focus on software testing is large. From small local companies to global corporations, everything is represented. And the demand for professional testers remains high, as shown by the many vacancies in this area. And while some are just starting to structure and professionalize their testing, others are already ready to tackle topics such as test process improvement. These models are also mature and are constantly improving. Even if testers are always somewhat critical of this, we can say: “Testing made in Germany”: Yes - we do it well!
…and we want to get better! But in addition to all the opportunities that test process improvements offer us, there are other things where testers still have a lot of potential:
- the view through the customer’s eyes. Ultimately, software is always created for users. Be it an end customer or a specialist department employee. And even if all functional and non-functional requirements have been checked, this does not mean that the user is satisfied. But that is the aim of the test. As a tester, you should always free yourself from the defined test concepts and test case lists so that you can look at the application freely and without external specifications. Is the solution usable? Is it easy to use? Is it fun to work with? Is it useful to the user? It is so easy to run the risk of accepting the technical solution as a given, so that you don’t even think about whether it makes sense at all. For example, there are tons of programs that are bursting with configuration options - but which are never used. As a tester, you have to risk this view from the outside and also point out things that may not be explicitly stated in the requirements - even if you may have to expect headwinds and discussions.
- creative solutions: As a tester, you are usually faced with many challenges and little time. There is a well-assorted set of tools and methods for overcoming them. These can be used 1:1, but there is much more potential in their creative application. With new ideas, thinking outside the box and common sense, you can create much better quality test cases and thus find more errors. How about a one-hour equivalence class collection session in the team? Or a coffee with the specialist department and two derived state diagrams? When it comes to automation, it may not be necessary to implement every case in the large test automation suite if a small script can do the job - and even faster. What’s more, you don’t have to solve every problem yourself - many solutions can be found in the vastness of the Internet - or simply from another tester or developer. Just ask!
This feels familiar to testers who work in agile teams. The feedback and constant exchange with each other promotes creativity and understanding. Short sprints require quick solutions. The hard-nosed transparency of daily meetings exposes lengthy problem discussions. And testers and developers in the team are constantly focused on one goal: Creating value for the customer.
This does not necessarily require an agile approach. Many things can also be implemented in traditional projects, because it depends on the attitude and mindset. As a tester, I can always decide to do things differently than before: Not just working through test cases, but thinking outside the box, developing ideas, discussing solutions, even pointing out shortcomings if they are not 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. Tester 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.
