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 expectation 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. For example, in mid-2012 there were 25,000 ISTQB-certified testers in Germany alone out of 240,000 worldwide. 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 the small local company to the globally active corporation, everything is there. 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 getting better all the time. Even if, as a tester, you always view this somewhat critically, you can say: "Testing made in Germany": Yes - we do it well!
...and we want to get better! But besides all the possibilities that test process improvements offer us, there are other things where testers still have a lot of potential:
- The view through the customer's glasses. 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 tested, this does not mean that the user is satisfied. But that is the goal of the test. As a tester, you should always break away from the defined test concepts and test case lists in order to be able to 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 one does not even think about whether it is useful 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 in the requirements - even if you have to expect headwind and discussions.
- Creative solutions: As a tester, you usually face many challenges and little time. There is a well-assorted set of tools and methods for dealing with them. These can be used 1:1, but there is much more potential in their creative application. With new ideas, a look outside the box and common sense, qualitatively much better test cases can be created and thus more defects can be found. How about a one-hour equivalence class collection session as a team? Or a coffee with the business and two derived state diagrams? Even with automation, maybe not every case needs to be implemented in the big test automation suite when a small script will do it - and even faster. Moreover, you don't have to solve every problem yourself - many solutions can be found in the vastness of the internet - or even just with another tester or developer. Just ask!
Testers who work in agile teams find this familiar. The feedback and constant exchange with each other promote creativity and understanding. Short sprints require quick solutions. Long problem rolls are unmasked by the hard-hitting transparency of daily meetings. And testers and developers in the team are constantly aligned with a goal: With the result of creating benefits 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 the mindset. As a tester, I can always decide to do something different than before: Not only to work through test cases, but to think outside the box, to develop ideas, to discuss solutions, and also to point out deficiencies when they are not based on written requirements.