DIE WESENTLICHEN ERFOLGSFAKTOREN BEIM TESTEN

Die wichtigsten Test-Regeln


Am Ende geht die Software natürlich produktiv, aber oft verbunden mit einem verschobenen Einführungstermin und viel Ärger in der Test- und Abnahmephase. Nicht alle, aber viele Probleme lassen sich vermeiden, wenn bestimmte Grundregeln berücksichtigt werden.


Stacks Image 74


1 > Testkonzept


Warum sollte das Testmanagement-Team bei knappen Ressourcen ein Konzept schreiben? Auch wenn es Mühe macht, es lohnt sich. Wesentliche Bestandteile sind die Auflistung der Testobjekte, die Vorgangsbeschreibung, die Skizzierung der Testumgebung sowie die Definition der Abnahmekriterien. Die Kunst liegt darin, das Konzept möglichst kurz zu halten und komplexe Sachverhalte wie beispielsweise eine Testumgebung mit vielen Schnittstellen durch Grafiken darzustellen. Ein gutes Konzept umfasst rund 20 bis 30 Seiten. Lassen Sie dieses sowohl von der Entwicklung als auch von der Fachseite abnehmen. Somit sind alle Beteiligten gezwungen, sich an definierte Vorgaben und Abläufe zu halten und Sie haben schriftlich definierte Kriterien für die Abnahme.


2 > Qualität der Testfälle


Den Fachabteilungen fehlt häufig die Zeit, die Testfälle zu erstellen. Folglich werden diese aus alten Vorhaben ‘recycelt‘, sind zu allgemein, zu granular oder treffen nicht die zu testende und abzunehmende Funktion. Das Resultat: Tester testen zu viel oder zu wenig, aber nicht die Features, die sie testen sollen. Der Fortschritt ist zu langsam, die Fehlerquote zu hoch und die Qualitätsverbesserung zu gering. Die Fachabteilung – und nicht die IT! – sollten sich also unbedingt die notwendige Zeit für die Testfälle nehmen. Im Idealfall werden sie bereits bei der Definition der Anforderungen oder in der Fachkonzeption grob beschrieben und vor Teststart verfeinert. Achten Sie darauf, dass in den Testfällen das Ziel und das erwartete Ergebnis spezifiziert, die Testfälle einem Review unterzogen und von der Fachabteilung abgenommen werden. Ein kontrolliertes ‘Nachjustieren‘ in der Testphase ist gängige und erlaubte Praxis, um neue Erkenntnisse einzuarbeiten.


3 > Priorisierung der Testfälle


Natürlich möchte die Fachabteilung alle Features und alle Varianten bis ins letzte Detail austesten. In der Regel fehlen dafür Zeit und Ressourcen. Am Ende des Tests steht die Abnahme. Und dann ist häufig ein erheblicher Teil der Tests nicht absolviert oder steht auf ‘Fehler‘. Folge: Die Abnahme ist gefährdet. Bewährte Praxis ist, die Testfälle zu priorisieren. Ein guter Ansatz ist das Risk Based Testing. Hier werden die Testfälle insbesondere hinsichtlich des Schadensmasses bei Fehlfunktionen gewichtet. Je höher die Gewichtung des zu testenden Prozesses und damit der Umfang eines möglichen Schadens, desto höher ist die Priorität des Testfalls. Üblicherweise müssen Testfälle der Priorität ‘hoch‘ in allen Testzyklen und jene der Priorität ‘mittel‘ mindestens in einem Testzyklus erfolgreich durchgeführt werden. Testfälle der Priorität ‘gering‘ sind „Nice to Have“.


4 > Testzyklen


Der erste Testzyklus läuft üblicherweise sehr holprig an. Es gibt Blockaden, die Tester sind nicht eingearbeitet und es ergeben sich viele Fehler. Die hohe Anzahl an Fehlerkorrekturen kann zu Seiteneffekten führen, die einen Retest bereits erfolgreich abgeschlossener Testfälle notwendig machen. Und ehe man es sich versieht, ist der Zyklus vorbei. Legen Sie daher nach dem ersten Testzyklus eine Pause ein und geben Sie der Entwicklung die Chance, alle kritischen Fehler zu beheben. Starten Sie dann mit einem konsolidierten Software- und Datenstand einen weiteren Zyklus, in dem Sie zumindest alle hoch und mittel eingestuften fehlerhaften Testfälle aus dem ersten Zyklus testen.


5 > Testumgebung(en)


Wer schon mal angereisten Testern gestanden hat, die wegen fehlenden Berechtigungen im System zwei Tage nicht arbeiten konnten, kann das nachvollziehen: Eine funktionierende Testumgebung ist die Voraussetzung für ein erfolgreiches Vorhaben. Planen und überwachen Sie daher mit Nachdruck das Bereitstellen der Testumgebung. Den ersten Pfeiler setzen Sie durch die Definition von Eingangskriterien im Konzept. Sind wesentliche Bedingungen nicht erfüllt, starten Sie erst gar nicht. Beschaffen Sie User-IDs für die Testumgebung und prüfen Sie die Berechtigungen. Und führen Sie technische Shake-Down-Tests durch, um Grundfunktionen und Schnittstellen zu testen. Unter Umständen sind auch regelmäßige Batch-Abläufe zu etablieren und Personal für den Betrieb zu rekrutieren.


6 > Testwerkzeuge/-tools


Das am häufigsten verwendete Werkzeug im
Testmanagement ist Excel. In Excel werden die Tests dokumentiert, die Abweichungen beschrieben, die Verteilung von Testfällen auf Tester verwaltet sowie deren Status und Abweichungen nachgehalten. Das mag bei einer geringen Anzahl von Fällen, Testern und Abweichungen funktionieren. Aber auch hier wird die Verlinkung zwischen Testfällen und Abweichungen schon schwierig. Insbesondere die manuelle Pflege ist aufwendig und fehlerträchtig. Spätestens ab einer Menge von ca. 100 Testfällen lohnt sich die Investition in ein integriertes Test- und Abweichungsmanagement-Werkzeug. Gute Werkzeuge sind z.B. HP Quality Center oder IBM Rational ClearQuest. Für SAP-Anwender bietet sich der Einsatz von testOffice (Spirit-Testing) oder der lizenzfreien SAP Solution Manager Test Workbench an. Im Bankenumfeld wird auch häufig Tosca verwendet.


7 > Kickoff-Meeting


Die Vorbereitungen sind aufwendig und anstrengend. Benötigt werden Foliensätze, Einladungen, Räumlichkeiten usw. Aber den zeitlichen wie personellen Aufwand, den Sie in ein gut vorbereitetes Kickoff investieren, fahren sie im täglichen Testbetrieb locker wieder ein. Die Tester werden beispielsweise über Testziele und Vorgehen, Testsysteme, Werkzeuge, Termine informiert. Dadurch vermeiden Sie viele Rückfragen im laufenden Testbetrieb. Lassen Sie auch Verantwortliche aus der Entwicklung auftreten. Das persönliche Kennenlernen erleichtert und beschleunigt die Kommunikation zwischen Test- und Entwicklungsteam. Bewährt hat sich, die Kickoff-Unterlagen und Statusreports, aber auch Konzepte und beispielsweise Datenlisten in einem für alle Beteiligten einfach zugreifbarem Medium wie MS SharePoint zur Verfügung zu stellen.


8 > Teststart


Das typische Szenario wie es schief geht: Die Software ist noch nicht komplett fertig und Sie stehen unter hohem Druck, den geplanten Starttermin für die Fachtests einzuhalten. Die ersten Tage überstehen Sie vielleicht noch durch das Kick-off, durch das Einarbeiten der Tester in die Tools und in die Software sowie durch den Test von weniger komplexen bzw. fertigen Software-Komponenten. Aber spätestens am dritten oder vierten Tag überrollt Sie die Fehlerwelle, die Tester fangen an zu murren und müssen aufgrund der Fehlersituation oder wegen Blockaden
nach Hause geschickt werden. Die Empfehlung lautet: Halten Sie den Druck aus und verschieben Sie die Tests, wenn die Software noch nicht bereit ist. Sie sparen sich und den Testern jede Menge Ärger und vermeiden vor allem die negative Ausstrahlung in die involvierten Fachabteilungen.


9 > Testblockaden


Versuchen Sie nicht die Welt zu retten, wenn Ihre Tests nicht weitergehen, da wichtige Infrastruktur- oder Softwarekomponenten nicht oder nur rudimentär zur Verfügung stehen. Natürlich macht es keinen Spass,
Tester in eng getakteten Fenstern nach Hause zu schicken. Auch bei der Entwicklung rennen Sie mit der Massnahme keine offenen Türen ein. Aber die negativen Konsequenzen wie unzufriedene Tester und Panik in den Fachabteilungen oder beim Vorstand aufgrund der mangelhaften Softwarequalität sind im Zweifelsfall höher zu bewerten als eine gezielte Unterbrechung. Diese können Sie für die Konsolidierung der Software nutzen. Flankieren Sie die Maßnahme durch eine klare und verlässliche Kommunikation.


10 > Kommunikation


Führen Sie regelmässig Status- und Fehlermeetings mit den Testern und der Entwicklung durch. Bewährt haben sich beispielsweise tägliche Stand-up-Meetings, in denen übergreifende Aspekte kommuniziert und Tester kurz über den Status und aktuelle Fehler berichten. Versuchen Sie, täglich mit jedem direkt zu sprechen, um mehr über konkrete Test- und vermeintliche Fehlersituationen zu erfahren. Ein kurzes Gespräch vermeidet häufig die Erstellung von Abweichungen und langwierige Kommunikation mit der Entwicklung. Bewährt hat sich auch, bei komplexen und nicht transparenten Sachverhalten, Entwickler zu Tests oder für den Retest von Fehlern hinzuzuziehen.

Ist das Testteam an unterschiedlichen Örtlichkeiten, hat sich der Einsatz von Kommunikations-Tools, wie zum Beispiel
gotoMeeting oder Skype for Business, sehr bewährt. Es lassen Sie auch Bildschirme für Erklärungen aufschalten. So kann viel (Reise-)Zeit gespart werden.


Ihre Qualitätssicherung ist unsere Herausforderung! Haben wir Ihr Interesse geweckt?


Wir freuen uns auf Sie!


Fill out my online form.


Stacks Image 77


Stacks Image 82


GABEX GMBH
Kefikerstrasse 4
8546 Menzengrüt

Sprechen: +41 44 508 20 54
Kontakt aufnehmen