Tester sein ist nicht einfach

Warum das Leben der Tester manchmal schwierig ist

Wer kennt sie nicht, die alltäglichen Probleme, die uns als Software Tester begegnen? Zu wenig Zeit oder ungenaue oder fehlende Spezifikationen? Testdaten, die nicht zur Verfügung stehen oder veraltete Testfälle? In diesem Blog möchte ich darauf eingehen, welche Probleme uns immer wieder beschäftigen, wo der Ursprung dafür liegen und Lösungansätze aufzeigen, wie diese verhindert werden könnten.

Typische Probleme

Den folgenden 4 Problemen, begegnen wir Tester häufig und sie bereiten uns immer wieder Sorgen.

• Problem der fehlenden Zeit

Probleme werden verursacht, weil bereits bei der Planung zu wenig Zeit für das Testen eingerechnet worden ist – oder es steht durch verschiedene Abklärungen oder Verzögerungen weniger Zeit für die Tests zur Verfügung als ursprünglich eingeplant war.

Problematisch kann es insbesondere in traditionell geführten Projekten werden, wenn ein neues System zu einem bestimmten Zeitpunkt fertiggestellt sein muss und dabei die Entwicklung länger dauert als geplant. Leider kommt es häufig vor, dass während der Tests sehr viele Fehler gefunden werden, welche korrigiert und neu geprüft werden müssen. Durch diese vielen Fehler und die dadurch notwendigen Fehlernachtests, steht dann am Ende womöglich nicht mehr genügend Zeit für die Regressionstests zur Verfügung. Dies hat zur Folge, dass die Qualität darunter leiden kann.

• Problem Spezifikationen

Spezifikationen führen zu Problemen, wenn:

- diese ungenau oder unvollständig beschrieben sind

- sie nicht verständlich sind

- sie Interpretationsspielraum zulassen

- sie nicht vorhanden sind

- Änderungen daran während des Projekts ohne Information an die Beteiligten erfolgen

Bei nicht vorhandenen oder zu ungenau beschriebenen Spezifikationen (Requirements, User Stories etc.) ist nicht klar, auf was beim Testen geachtet werden muss, und ob ein bestimmtes Verhalten korrekt ist oder nicht. Wie es sich im positiven Fall verhalten soll, ist meistens noch ausreichend beschrieben und verständlich. Aber wie sich das System beispielsweise verhalten soll, wenn Fehleingaben gemacht werden, wird meistens vergessen.

In klassisch geführten Projekten werden die Anforderungen zu Beginn detailliert erhoben. Diese müssen vor Entwicklungsanfang vollständig und stabil sein. Wenn sich diese Anforderungen jetzt während der Entwicklung ändern, entsteht die Gefahr, dass die Tester nicht darüber informiert werden. Diese Gefahr sollte in agilen Projekten eher nicht auftreten, da dort eine enge Zusammenarbeit zwischen Tester, Entwickler und Requirement Engineer erfolgen sollte.

• Problem Testdaten

Ein weiteres Problem ist, dass benötigte Testdaten gar nicht, oder so unstrukturiert vorliegen, dass sie für Testfälle nicht verwendet werden können. Wenn Testdaten nicht vorhanden sind, müssen diese vom Tester zuerst zeitaufwändig erfasst werden. Ohne valide Testdaten ist auch die Testautomatisierung unmöglich.

• Problem ungenaue Testfälle

Wurden Testfälle von jemandem erstellt, der das System sehr gut kennt, wurde möglicherweise implizites Wissen zur Testausführung weggelassen. Diese Informationen sind jedoch für Tester, die das System weniger gut oder gar nicht kennen, notwendig, um die entsprechenden Tests korrekt ausführen zu können. Wenn man mitten im Test feststellt, dass andere Daten hätten verwendet, oder eine bestimmte Vorbedingung hätte erfüllt sein müssen, wird durch ein erneutes Beginnen wieder Zeit benötigt. Durch ungenaue oder schlecht spezifizierte Testfälle wird die Organisation bezüglich neuer Tester auch sehr inflexibel. Man wird immer auf bestimmte Tester angewiesen sein, und zwar auf diejenigen die das System gut kennen. Die Einarbeitung neuer Test-Mitarbeiter lässt sich dadurch eher schwieriger gestalten. Dieses Problem wird noch verstärkt, wenn die Spezifikationen ungenau oder nicht vorhanden sind.

Auswirkungen

Eine nächste Frage die man sich stellen kann, ist, welche Auswirkungen durch die beschriebenen Probleme entstehen können. Die oben beschriebenen Probleme machen nicht nur das Leben der Tester schwierig, sondern haben natürlich auch Auswirkung auf andere Stakeholder. Die Nachfolgende Tabelle zeigt auf, welche Auswirkungen die oben ausgeführten Probleme auf die einzelnen Projekt- resp. Organisationsrollen haben können.

• Projekt-Sponsor.
  Die Probleme führen dazu, dass die Kosten steigen, die geforderte Qualität nicht erreicht wird oder die Einführung mit einer Verzögerung erfolgt. Dies alles wird folgen für das Budget haben. Will man das Ruder umwerfen, muss das Budget wahrscheinlich erhöht werden.
  

• Tester.
  Muss seine Arbeit unter erschwerten Bedingungen durchführen.
  So können möglicherweise am Ende bei einem Release die manuellen Regressionstestfälle nicht mehr durchgeführt werden, weil es dafür keine Zeit mehr gibt. Dadurch können noch unentdeckte Probleme im System vorhanden sein, die sich dann im produktiven System negativ bemerkbar machen.
  Eine mögliche Demotivierung der Tester sollte man nicht unterschätzen.
  
  

• Projektleiter.
  Werden mehr Test-Ressourcen benötigt, um zur geforderten Zeit fertig zu sein, entsteht die Frage für den Projektleiter wo er diese zusätzlichen Ressourcen herholen soll. Gute Tester findet man bekanntlich nicht wie Sand am Meer. Auch eine verspätete Einführung oder eine ungenügende Qualität, wird auch den Projektleiter nicht glücklich machen.
  In der heutigen Zeit, wo Zeitdruck und Konkurrenzdruck enorm sind, muss auf die Time-to-Market geschaut werden. Eine verzögerte Einführung im Markt hat eine Benachteiligung gegenüber der Konkurrenz zur Folge. Ein frühzeitiger Einbezug der Tester und dadurch ein früheres Entdecken und Beheben von Fehlern, kann ein wesentlicher Wettbewerbsvorteil sein.
  

• Endbenutzer.
  Die Endbenutzer sind schlussendlich die Leidtragenden, wenn die Qualität des Produktes zu wünschen übriglässt. Durch fehlende Zeit oder ungenaue Spezifikationen könnte der Endbenutzer ein fehlerhaftes Produkt erhalten oder sogar ein Produkt, dass er in der ausgelieferten Form so nicht gewünscht hat.
  

Lösungen

Schlussendlich kann man sich fragen, wie die oben erwähnten Probleme verhindert werden können.

• Genaue Planung und gute Kommunikation

Häufig liegt der Ursprung in der mangelhaften Planung oder ungenügenden Kommunikation. Wenn beispielsweise die Planung der benötigten Ressourcen (Tester, Zeit) nicht exakt genug gemacht wird, Terminverschiebungen nicht genug früh mitgeteilt werden, kann es dazu kommen, dass ursprünglich eingeplante Tester nicht mehr ausreichend oder gar nicht mehr zur Verfügung stehen. Eine gute Aufwandschätzung kann helfen, die benötigten Ressourcen möglichst genau festzulegen. Änderungen zur ursprünglichen Planung, wie z.B. Terminverschiebungen oder Änderungen an Anforderungen sind, wenn diese nicht verhindert werden können, möglichst rasch allen Beteiligten mitzuteilen. Wenn sich Spezifikationen während des Projektes ändern und dies entsprechend und frühzeitig kommuniziert wird, ist dies weniger problematisch, als wenn man dies erfährt, nachdem die geänderten Anforderungen schon implementiert wurden.

• Review der Spezifikation

Um unvollständigen oder unklaren Spezifikationen vorzubeugen, sollte man diese zu einem frühen Zeitpunkt im Projekt reviewen lassen. Damit die Testbarkeit der Anforderungen gegeben ist, müssen die Tester unbedingt in das Review involviert werden. Die Spezifikationen können dann anhand des Feedbacks angepasst und verbessert werden. Im agilen Bereich kommt hier das Tres Amigos Prinzip oder auch Power of Three Konzept zum Zug, bei dem durch den gemeinsamen Einbezug der Tester, Entwickler und Fachvertreter die Spezifikationen verfeinert werden und eine frühe und regelmässige Rückmeldung erfolgen kann. Dadurch können Missverständnisse bezüglich der Anforderungen vermieden werden, die ansonsten erst im Laufe des Entwicklungs-Zyklus erkannt würden.

• Gute Testdaten

Die für die Tests benötigten Testdaten stehen spätestens zu Beginn der Testausführung zur Verfügung. Hierdurch können Verzögerungen des Testanfangs verhindert werden.

• Gute Testfälle

Bei der Erstellung von Testfällen ist darauf zu achten, die relevanten Informationen, wie beispielsweise die Vorbedingungen, die Nachbedingungen, die einzelnen Schritte, die einzugebenden Daten zu beschreiben und keine wichtigen Informationen zu vergessen resp. wegzulassen. Es darf nicht vergessen werden, bei Änderungen am System, die vorhandenen Testfälle und Regressionstestfälle entsprechend anzupassen.

• Agiles Vorgehen

In traditionell geführten Projekten, wo spät mit dem Black Box Testing begonnen wird, erhalten die Entwickler spät ein Feedback über die Qualität der Software. Entsprechend spät können die Fehler behoben und erneute Tests durchgeführt werden. Hierdurch wird das Risiko auf Projekt Verzögerungen erhöht. Diese Problematik wird in agilen Projekten entschärft, da sich der Testaufwand durch die Aufteilung in jeweilige Sprints mehr über das gesamte Projekt verteilt. Dadurch erhalten die Entwickler früher ein Feedback und Bugs können frühzeitig korrigiert werden.

Fazit

In vielen Projekten wird das Leben der Tester durch die oben erwähnten Probleme unangenehmer gemacht. Dass Tester dadurch nach einer gewissen Zeit womöglich demotiviert werden, ist nicht auszuschliessen. Logischerweise führt dies zu abnehmender Testqualität. Wenn man dann nicht aufpasst, setzt eine Negativspirale ein. Unabhängig davon, ob diese Projekte klassisch oder agil geführt werden Es ist also wichtig, die Probleme frühzeitig aufzudecken und entsprechende Massnahmen einzuleiten. Durch einfache Änderungen oder Anpassungen an der Vorgehensweise kann uns das Testen angenehmer gemacht und somit die Qualität relativ einfach gesteigert werden. Wichtig ist dabei, die aufgedeckten Probleme als tatsächliche Probleme anzuerkennen. Das bedingt eine Offenheit gegenüber Fehlern und Problemen. Also eine Fehlerkultur mit einem Klima des Problemlösens. Nur so ist man in der Lage, das Testing und damit die Produktqualität zu verbessern.