Startseite > Embedded > Entwicklungstools > Tipps für das Software-Testmanagement

Empfehlungen aus der Trickkiste der Softwaretechnolgie

Tipps für das Software-Testmanagement

12. Oktober 2011, 15:06 Uhr | Von Stephan Grünfelder

▶ Diesen Artikel anhören

Fortsetzung des Artikels von Teil 2

Spaß am Test

Gleiches gilt für die Tester: Fehler, die in hausinternen Tests hätten gefunden werden sollen, aber bis zum Kunden durchgerutscht sind, müssen analysiert werden. Die Testtiefe, das Testdesign, die Testmittel, die Testabdeckung usw. müssen hinterfragt werden und ggf. die Prozesse angepasst werden, oder neue Testmittel angeschafft werden. Ein mögliches Resultat so einer kontinuierlichen Analyse könnte sein, dass verstärkt Dauertests durchgeführt werden müssen oder Werkzeuge zur Erkennung von Race Conditions [9] eingesetzt werden müssen.

Ein Mitarbeiter wird dann gute Arbeit machen, wenn er Spaß bei der Arbeit hat. Die Arbeit des Testers ist es, Fehler zu finden. Ich habe nicht selten Firmen gesehen, wo die Programmierer vor dem Release ihre eigene Software testen. Wem bitte macht es Spaß, wenn man sich im Anschluss an die Software-Programmierung im Test selbst nachweist, dass man Mist gebaut hat? Abgesehen vom Argument der Befangenheit ist auch das Argument der Freude an der Arbeit für mich ganz wichtig, wenn ich die nächste Empfehlung ausspreche.

Empfehlung 6: Achten Sie auf unabhängigen Test. Bestimmen Sie also für jede neue Aufgabe einen Entwicklungsverantwortlichen und eine andere Person mit Testverantwortung.

Als ehemaliger Projektleiter empfehle ich überdies, darauf zu achten, dass die Person, die Sie mit der Testaufgabe betrauen, diese Herausforderung auch gerne annimmt. Das Testen, insbesondere die Durchführung manueller Tests, erfreut sich nicht gerade großer Beliebtheit bei vielen Leuten. Nach meiner Erfahrung gibt es auch Personen, die es nicht schaffen, dem Produkt gegenüber so feindselig zu sein, dass sie ein ideenreiches Testdesign zu Wege bringen. Diese Personen müssen Sie erkennen und von Testaufgaben frei halten. Nun könnte sich ja jeder im Team dumm stellen - das Berufsleben kann ein Kindergarten sein - damit er/sie nicht testen muss. Um dem entgegenzusteuern, ist es wichtig, dem Testen ebensolche oder größere Wertschätzung beizumessen wie dem Entwickeln.

Wertschätzung kommt zum großen Teil aus der Führungsetage. Wenn man sich bei jedem zweiten Stammtisch erzählt, wie damals Mitarbeiter Meier beim nächtlichen Debugging beim wichtigen Kunden in Dubai endlich den knackigen Bug gefunden hat und dabei ins Schwärmen gerät, aber niemals die Mitarbeiterin Müller lobt, die durch akribische Tests verhindert hat, dass so ein kniffliger Bug jemals wieder in ein Release kam, dann ist kein Mitarbeiter motiviert, Tester zu werden. Lieber würden viele nach Dubai reisen, dort eine anstrengende, aber aufregende Nacht beim Kunden verbringen und nach der Rückkehr als Held gefeiert werden. Als Führungskraft muss man daher die Arbeit der stillen Heldin Müller offen loben und ehrliches Interesse dafür zeigen.

Testautomatisierung

Noch etwas kann helfen, Testaufgaben spannender zu machen und damit Mitarbeiter stärker zu motivieren, solche Aufgaben zu übernehmen: Automatisierung. Die wiederholte Durchführung von manuellen Tests ist in der Tat eine langweilige Angelegenheit. Eine alte Daumenregel besagt, dass sich der Aufwand von Testautomation ab rund 10 Durchführungen lohnt. Diese Regel kann ich aus eigener Erfahrung bestätigen.

Ich habe als Projektleiter in einem internationalen Projekt aber schon entschieden, Tests von nicht missionskritischer Software zu automatisieren, selbst wenn die Tests nur 3 bis 4 mal wiederholt werden mussten und somit Testautomation per se finanziell nicht gerechtfertigt war. Für mich gab es dafür drei Beweggründe: Erstens waren die Tests nach Indien ausgelagert und das vergleichsweise unerfahrene Team in Bangalore war trotz intensiver Bemühungen so ungeschickt in der Dokumentation der Tests, dass ich mit Hilfe der Automation etwas in der Hand haben wollte, das deren Tests trotz aller kulturellen Unterschiede eindeutig nachvollziehbar macht und ich als Auftraggeber einer peniblen Review unterziehen konnte. Eindeu-tiger als maschinell ausführbar kann die Dokumentation nicht sein.

Zweitens konnten wir so alle Tests bei Bugfixes auch bei uns im Auftraggeber-Team mit geringem Aufwand wiederholen und drittens macht das Programmieren von Tests deutlich mehr Spaß als die x-te Wiederholung eines manuellen Tests. Die Langeweile, die ein oftmalig wiederholter manueller Test mit sich bringt, halte ich für eine nicht zu unterschätzende Fehlerquelle. Mitarbeiter machen die Arbeit, die sie ungern machen, lange nicht so gut, als wenn es ihnen Spaß macht.

Empfehlung 7: Daher meine siebente Empfehlung: Automatisieren Sie Tests, sobald zu erwarten ist, dass diese Tests zumindest drei Mal wiederholt werden müssen. Die Automatisierung ist noch bedeutsamer, wenn eine rasche Time-To-Market bei einer Testwiederholung wichtig ist. Bei sicherheitsrelevanter Software empfehlen einschlägige Standards ohnehin immer die Automatisierung. Sicherheitsrelevantes wird immer am Zielsystem getestet. Das heißt: Eine Simulation, eine Analyse oder ein Test in einer anderen Umgebung ist nur in begründeten Fällen geduldet. Auch wenn das Gerät nicht sicherheitsrelevant ist, sollte man der Empfehlung des Tests am Zielsystem (anstelle einer Simulation) folgen. Denn beim Test am Zielsystem hat man die Chance, Lücken in der Spezifikation zu finden, die man beim Test gegen die Spezifikation in einer anderen Umgebung nicht finden könnte.

Damit Testautomation ein Erfolg ist, sollte sie möglichst die Hauptaufgabe von Mitarbeitern sein. Das heißt, Testdesign und -automatisierung ist eine Vollzeitbeschäftigung. Ich setze meine Mitarbeiter effizienter ein, wenn ich mir einige wenige Testautomatisierungsspezialisten heranziehe, als wenn ich jeden Entwickler auch ein wenig Testskripts programmieren lasse. Und bei all dem Lobgesang über Testautomatisierung auch eine Warnung:

Empfehlung 8: Testautomatisierung nicht um jeden Preis! Oft kann man sich viel Geld sparen, wenn man in einen sonst automatisch laufenden Test ein paar manuelle Handgriffe einbaut, etwa das Umstecken von Kabeln am Oszilloskop oder das Betätigen von Bedienelementen am Testobjekt. Ebenso kann ich mir das Leben einfacher machen, wenn ich im Bedarfsfall die Evaluierung des Testergebnisses manuell durchführe anstatt automatisch. Solch halbautomatisch laufende Tests haben noch immer fast alle zuvor erwähnten Vorteile gegenüber manuellen Tests, können aber, wie gesagt, deutlich preiswerter sein.