Einleitung
Dieses Handbuch bzw. Kompendium schreibe ich aus der Praxis heraus, die ich aus einem Testteam mit unterschiedlichen Rollen(fachlich, technisch-automatisieren, technisch-skripten) entwickelt habe, in dem ich alle Rollen ausfüllte. Um die Zusammenarbeit zuvertiefen ist es sinnvoll, dass jeder auch einmal die Rollen wechselt, um ein Verständnis für die Arbeit der anderen zugewinnen. Der Rollentausch endet aber da, wo es auf die spezifische Skills ankommt – Skills im Sinn von „man hat ein Faible dafür“,das Anlernen der Fähigkeiten ist dann nur noch eine Sache der Übung.
Das Testmanagement als eigenständige Rolle fällt in meiner Betrachtung aus, weil die erforderlichen Vorplanungen einmal im Voraus angestellt werden müssen, das kontinuierliche Leiten undSteuern kann zum einen bei einen erwachsenen Team selbständig erfolgen, wenn die Rahmenbedingungen gegeben sind und bei einer agilen Entwickung in einem cross-funktionalen erfolgt die permanente Steuerung durch das Team selbst, wobei ProductOwner die Anforderungen einbringt und der ScrumMaster die Kommunikation nach außen/oben übernimmt. Bestenfalls arbeiten sie so weit im Hintergrund, dass man ungestört arbeiten kann.
Diese will ich mit der Testlehre – insb. ISTQB-Definitionen –in Einklang bringen. Das in-Einklag-bringen erfolgt mittels intensiver Querverweise zwischen den Kapiteln.
Das erste Kapitel stellt die theoretischen Definitionen zusammen. Die weiteren Kapitel orientieren sich an den Bearbeitungsphasen der Testdurchführung, jeweils auf die unterschiedlichen Rollen.
Im zweiten Kapitel werden erstens die allgemeinen Voraussetzungen beschrieben (die Testumgebung mit dem Testobjekt) und zweitens das gemeinsam zu erarbeitende Verständnis der Testaufgabe. Die Testaufgabe wird wesentlich vor dem eigentlichen Testen ausformuliertin den frühen Projektphasen. Diskrepanzen die in dieser Frühphase aufgedeckt werden, ersparen für das ganze Projekt viel Aufwand, dennje früher Fehler gefunden werden, desto weniger wirken sie sich aus– indem sie weniger Folgefehler verursachen – und um so einfacherkönnen sie behoben werden. Meiner Erfahrung nach ergänzen sich unterschiedliche Sichtweisen, Entwickler wie auch Analysten denken, spezifizieren und implementieren algorithmisch, Tester dagegen exemplarisch! Die erhellende Frage, die der Tester im Refinement einbringt, lautet: für diese einen Fällen würde dieses erwartet, für die anderen Fälle jenes, und was ist mit den anderen Sonderfällen.
Das dritte und vierte Kapitel befasst sich mit der eigentlichen Testfallerstellung.
Das fünfte Kapitel – Testausführung – nimmt die Anlässe inden Blick, welcher Testumfang zu welchem Anlass wie durchgeführt werden kann. Die Ausführung wird meist als technische Aufgabe verstanden, sollte aber bei guter Automatisierung auch einfach von nicht-Technikern ausgeführt werden können.
Das sechste Kapitel – Testauswertung – beschreibt das Arbeiten mit den Durchführungsergebnissen, Ziel ist es dabei festzustellen,ob der Test einen Fehler aufgedeckt hat und um gegenüber Anforderern zu dokumentieren, dass die Anwendung umfassend korrekt arbeitet.
Das siebte Kapitel – Weiterentwicklung – nimmt nach derdurchgeführten Durchführung bereits die nächste Durchführung inden Blick, Soll-Ergebnisse oder auch die Testfälle selbst müssen angepasst werden, ebenso kann Bedarf an der Automatisierung festgestellt werden.