Be good, become better 

 April 1, 2013

Like it?
Share!

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 consultancies with a focus on software testing is large. From the small local company to the global corporation, everything is there. And the demand for professional testers remains high, as the many vacancies in this area show. And while some are just starting to structure and professionalize their testing, others are already ready to move on to topics like test process improvement. These models are also maturing 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:

  1. 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 are 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 specifications from the outside. 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 accept the technical solution as a given 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 are perhaps not explicitly in the requirements - even if you have to expect headwind and discussions.
  2. 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!

This is familiar to testers who work in agile teams. The feedback and the constant exchange with each other promote creativity and understanding. Short sprints require quick solutions. Long problem rolls are debunked by the hard-hitting transparency of daily meetings. And testers and developers in the team are constantly focused on one goal: To create benefits for the customer with the result.

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 to point out problems when they are not based on written requirements.

Do you like this post? Share it: