Deutsche BlogsValidation und Verifikation

Psychologie des Testers

Verifikation und Validation

Die Psychologie des Testers ist ein oft stark unterschätzter Aspekt. Welche Eigenschaften kennzeichnen gute Leute die im Testbereich arbeiten? Naja, man kann da einige Kriterien definieren: Fachliche Kompetenz und Methoden Know-How sind sicher unabdingbare Eigenschaften. Darüber hinaus müssen sie Managementfähigkeiten besitzen und Sozialkompetenz mitbringen. Das alles sind sicher notwendige Fähigkeiten. Es fehlt aber ein wichtiger Punkt, den ich in diesem Blog etwas näher beleuchten will:

Wer ein Meister im Testbereich werden will, muss auch konstruktiv-destruktiv sein!

Psychologie des Testers

Konstruktiv-destruktiv – das ist zunächst einmal eine unglaubwürdige, widersprüchliche Kombination. Versetzen wir uns also in die Rolle des Testers. Er hat idealerweise die Anforderungen an ein Produkt in schriftlicher Form vorliegen, die er nun testen soll. In der Regel bedeutet das, er hat ein Requirement in natürlicher Sprache vor sich. Damit ist auch zwangsläufig klar, dass es Interpretationsspielraum gibt, da es nur ganz wenige Requirements in natürlicher Sprache gibt, die nicht oder kaum interpretiert werden können. Dies gilt auch für sehr gut geschriebene Requirements! Das Problem liegt hier in der Verwendung natürlicher Sprache. Je nach persönlichem Hintergrund, Lebenserfahrung, etc. kann man nahezu jedes Wort unterschiedlich interpretieren.

Der Tester hat nun also dieses interpretierbare Requirement als Grundlage seines weiteren Vorgehens. Was ist seine Aufgabe? Nun ja, er soll mit einem Test zeigen, dass dieses Requirement erfüllt ist, oder nicht erfüllt ist. Er wird sicher damit beginnen, zunächst einmal die offensichtlichen Inhalte des Requirements zu testen.
Der sehr gute Tester unterscheidet sich nun vom guten Tester, indem er z.B. überlegt, was die Negation dessen bedeutet, was hier im Requirement steht? Gibt es dafür ein anderes Requirement, oder ist dies ein offener Punkt? Entsprechend entwirft er dafür dann Testfälle. Ähnliches gilt für Grenzbereiche der im Requirement beschriebenen Funktion oder das Verhalten bei speziellen, nicht auf den ersten Blick offensichtlichen Kombinationen von Signalen.

Ebenso, schaut ein Tester im Labor nicht nur auf sein erwartetes Testergebnis, sondern er beobachtet auch kritisch Seiteneffekte, die sich während des Tests ergeben, aber nicht im direkten Fokus des eigentlichen Testfalls stehen. All dies bedeutet, dass der Tester eine gewisse destruktive Ader besitzen muss. Das bedeutet, er hat den Willen und das Ziel(!) in dem zu testenden System Fehler nachzuweisen.

Wenn wir aber auf der anderen Seite die sehr hohe Komplexität moderner Embedded Systeme betrachten. Wenn wir wissen, dass Software in diesen Systemen inzwischen einen sehr großen Anteil ausmacht, dann ist auch offensichtlich, dass es letztlich kein System gibt, das vollständig fehlerfrei ist.

Damit wird nun klar, warum der Tester auch eine konstruktive Seite benötigt. Der sehr gute Tester ist auch in der Lage abzuwägen, zwischen echten Problemen, die er weitergeben muss und eher unwesentlichem Fehlverhalten des Systems, das nicht weiterverfolgt werden braucht. Ebenso muss der Tester konstruktiv mitarbeiten, wenn es darum geht, wann er mit dem Test beginnen kann. Wie gut (reif) muss die Spezifikation sein? Sie wird nie perfekt sein, also benötigt er auch hier die konstruktive Abwägung. Wohl gemerkt, dies gilt alles auch für den Fall das sehr gute Requirements und Testspezifikationen geschrieben wurden und für Projekte bei denen ein sehr gutes Änderungsmanagement etabliert ist. Trotzdem gibt es noch einiges, was immer wieder interpretiert werden muss.

Fazit

Die sehr guten Tester können also unterscheiden, wann sie konstruktiv sein müssen und wann ihre destruktive Ader gefragt ist. Oft sagt man ja auch, dass Entwickler von Systemen konstruktiv sein müssen, d.h. sie haben in ihrer Kindheit im Sandkasten lieber Sandburgen gebaut, als sie zerstört. Der Tester hat dieser Logik folgend lieber die Sandburgen zerstört.

Mein Fazit dieses Beitrages ist, dass der wirklich gute Tester tatsächlich beides benötigt. Sicherlich muss er gerne Sandburgen zerstören wollen. Richtig gut ist er aber erst dann, wenn er den Zeitpunkt erkennt in dem er lieber die Sandburg baut. Der Entwickler von Systemen braucht dagegen sicher mehr den Willen Sandburgen zu bauen, sprich die konstruktive Seite. Er ist aber entsprechend auch ein sehr guter Entwickler, wenn er in der Lage ist zu erkennen, zu welchem Zeitpunkt er auch mal die Sandburg zerstören darf.

Gerne unterstütze ich Sie auch bei individuellen Fragen zu Ihrem Projekt. Senden Sie eine Mail an: martin.heininger[at]heicon-ulm.de
Einen unverbindlichen Überblick über die Leistungen finden sie auch auf der
HEICON Homepage.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.

Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahre mehr darüber, wie deine Kommentardaten verarbeitet werden.