Be good, getting better - Richard Seidl

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:

1. 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.
2. 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.