Tester sind der Schlüssel zu guter Software

Wer Texte schreibt, macht Rechtschreibefehler. Das weiss jeder Journalist. Genauso ergeht es auch einem Softwareentwickler, der beim Schreiben des Codes aus Versehen Syntaxfehler einbaut. Diese zu finden, ist meist kein grosses Problem, da man davon ausgehen kann, dass Code mit Syntaxfehlern gar nicht kompiliert.

Perfider als syntaktisch falscher Code ist daher Code, der zwar syntaktisch gesehen richtig ist, aber ein Fehlverhalten der Software hervorruft. Darum muss neuer Code immer wieder getestet werden. Der Entwickler kontrolliert seinen Code bereits selbst, beispielsweise mit Unit-Tests. Sobald er den Code freigibt, müssen die Tester ran. Sie müssen dabei sehr genau und aufmerksam arbeiten und viel Geduld mitbringen. Ihre Arbeit kann eintönig sein, und am Ende eines Tages haben sie nicht wie ein Entwickler eine neue Softwarefunktion erschaffen, sondern sie haben Fehler gefunden, die die Entwicklungsabteilung wieder ausbügeln muss.

Tester und Entwickler im Clinch

Es erstaunt daher nicht, dass die Beziehung zwischen Entwicklern und Testern ein gewisses Konfliktpotenzial birgt. Oder um es mit den Worten von Adrian Zwingli, CEO von SwissQ und Conference Chair Swiss Testing Day, auszudrücken: "Tester sind diejenigen, die schlechte Nachrichten bringen. Wer schlechte Nachrichten bringt, wird meist 'erschossen'."

Die Beziehung zwischen Entwickler und Tester bezeichnet auch Michael Flühmann, CCO bei Akros, als "Spannungsschnittstelle". Taucht ein Fehler auf, handelt es sich dabei entweder um ein Problem in der Software, sprich einen Entwicklungsfehler oder einen Testfehler. In einem Team, in dem man eng zusammenarbeitet, wird dies folglich entspannter gehandhabt, da dort das Verständnis für die jeweilige Position viel grös ser ist. Dabei geht oft vergessen, dass Tester mit jedem gefundenen Fehler einen wesentlichen Beitrag zur Qualität des Codes leisten. Denn wenn Software nicht das macht, was sie eigentlich sollte, ist sie schlichtweg unbrauchbar. Ein Unternehmen wiederum, das schlecht programmierte Software entwickelt, hat keine realistischen Überlebenschancen auf dem Markt. Dies hat die Wirtschaft erkannt und misst dem Thema Testing heute mehr Gewicht bei als früher. Dennoch gibt es noch viel Entwicklungspotenzial.

Tester früher und heute

"Früher wurde Tester, wer als Entwickler ausgedient hatte", sagt Flühmann. Zwar hatten sie schon damals eine grosse Verantwortung, da sie das Programm ja quasi "absegnen" mussten, aber die Rolle des Testers war damals nicht sonderlich angesehen. Fauzia Candrian, Verantwortliche für Integration und Testing IT-Zahlungsverkehr bei der Postfinance, drückt es so aus: "Früher war die Idee des Testens primär, Fehler zu finden. Heute geht es viel eher darum, Fehler zu vermeiden sowie proaktiv mitzuarbeiten, damit diese Fehler vermieden werden können."

Es wird daher immer wieder betont, wie wichtig es sei, den Testern genügend Anerkennung entgegenzubringen. Mit der Bedeutung, die das Testing gewinnt, wachsen auch die Anforderungen an die Tester. Früher habe ein Tester die Spezifikation erhalten und nur darauf geachtet, dass es so realisiert wurde, wie es auf dem Papier stand, so Candrian. Heute müsse einTester mehr wissen. Er müsse die Prozesse kennen und einen ganzheitlichen Ansatz pflegen, sprich, er müsse darauf achten, dass die Lösung auch wirklich funktioniere.

An der Ausbildung haperts

Höhere Anforderungen erfordern auch eine entsprechende Ausbildung. In diesem Bereich scheint es noch Mängel zu geben. Zwar gibt es für Tester eine Zertifizierung nach ISTQB (International Software Testing Qualifications Board), aber es gibt keine spezifische Ausbildung, wie dies beispielsweise für Softwareentwickler der Fall ist. Bei Akros achtet man darauf, dass Tester die Zertifizierung nach ISTQB vorweisen können. "Dies garantiert uns, dass wir alle von einer einheitlichen Sprache ausgehen", erklärt Flühmann.

Auch bei der Postfinance hat diese Zertifizierung einen hohen Stellenwert. Zudem gibt es bei der Postfinance zwei verschiedene Rollen im Testing: Test Manager und Test Engineer. Ein Test Manager schliesst idealerweise ein Informatikstudium ab, beispielsweise an der Fachhochschule. Ein Test Engineer hingegen macht normalerweise eine Ausbildung als Informatiker und lässt sich dann nach den Standards von ISTQB zertifizieren.

Eine weitere Anforderung, die heute vermehrt an Tester gestellt wird, ist die, dass sie ihr Metier kennen müssen. Denn wer Software testet, muss nicht nur sicherstellen können, dass der Code stimmt und eine Software macht, was sie soll. Er muss auch über fach- und branchenspezifische Kenntnisse verfügen und wissen, wie die Software beispielsweise eine Mehrwertsteuer-Abrechnung erstellen muss oder wie eine Bedarfsberechnung in der Produktion ermittelt wird. Sprich, er muss die Resultate, die ausgegeben werden, überprüfen können.

Welche Testmethode?

Neben der Rekrutierung geeigneter und gut ausgebildeter Mitarbeiter muss ein Unternehmen auch herausfinden, welche Testmethode für die eigenen Bedürfnisse am besten geeignet ist. Es gibt verschiedene Ansätze und alle haben Vor- und Nachteile. Einer der bekanntesten Ansätze ist wahrscheinlich das Wasserfallmodell sowie die Entwicklung nach Hermes. Beiden Projektführungsmethoden liegt zugrunde, dass zuerst die Anforderungen abschliessend definiert werden sollen und anschliessend entwickelt wird. Ein Vorgehen, das in der Realität nicht immer gut funktioniert, da der Kunde im Laufe des Projekts meist mit Zusatzwünschen antrabt, die man "wenn möglich doch auch noch umsetzen könnte".

Postfinance arbeitet mit Hermes und macht damit gute Erfahrungen. Dass die Entwicklung damit lange dauert, bestreitet Candrian nicht. Sie spricht von einem Zeitrahmen von ungefähr 18 Monaten, bis etwas wirklich umgesetzt ist. Ein agiler Ansatz wie Scrum würde das Unternehmen vor grosse Herausforderungen stellen. "Wir verfügen über ungefähr 100 Applikationen, daher ist das Wasserfallmodell für uns gut geeignet", so Adrian Tschannen, Teamleiter Informatik Internationaler Zahlungsverkehr bei der Postfinance. Bei einem agilen Ansatz würde die hohe Integration der Applikationen ein Problem darstellen. "Um die Verarbeitungsprozesse zu testen, muss die gesamte Applikationslandschaft in integrierter Form zur Verfügung stehen." Sprich, alles muss "am Stück" getestet werden können. Scrum hingegen verfolgt die Idee, primär in kleinen Schritten zu testen, um immer eine lauffähige Version zur Verfügung zu haben.

Die Ruf-Gruppe in Schlieren arbeitet teilweise mit Scrum, teilweise mit einem Konzept, das Ansätze des Wasserfallmodells beinhaltet. Für Neuentwicklungen verwendet Ruf Scrum. Die Vorteile von Scrum sind klar: Die Iterationszeiten verkürzen sich, zudem steht stets eine lauffähige und fertig getestete Version zur Verfügung. Zudem ist es dank Scrum möglich, von den Stakeholdern sehr schnell ein Feedback zu erhalten.

Testphasen zeitlich fixiert

Für die Branchenlösungen, die derzeit bei verschiedenen Gemeinden im Einsatz sind, gibt es bei Ruf zweimal pro Jahr einen Release. Die Testphasen sind demnach zeitlich vorausgeplant. Eine Testphase dauert einen Monat, während dieser Zeit wird sowohl automatisiert wie auch manuell getestet. Primär werden dabei die neu entwickelten Funktionen getestet, aber es muss auch sichergestellt werden, dass die bestehenden Funktionen noch einwandfrei funktionieren. Ist der Testmonat vorbei, wird die neue Software zusätzlich bei mehreren Pilotgemeinden getestet, bevor das Produkt auf den Markt kommt. Ruf will damit sicherstellen, dass die neue Software möglichst wenig Fehler enthält, wenn sie an die Kunden ausgeliefert wird. "Bei einem grossen Release mit vielen Änderungen ist es eigentlich fast unmöglich, alle Fehler zu finden. Die fehlerfreie Software gibt es daher faktisch nicht", hält Marco Ehmke, der für die technische Entwicklungsleitung der Neuentwicklungen zuständig ist, fest.

Auch die Postfinance hat fest definierte Testzeiten. Es gibt zwei bis drei Releases pro Jahr. In diesen Releases kommen alle Änderungen zusammen. Ziel der Testphase ist es, gute Qualität in die Produktion abzugeben, sodass nach dem Release alles reibungslos läuft. Es kann aber trotzdem sein, dass nach einem Release kleine oder mittelschwere Fehler oder Probleme auftreten. Ein Release findet immer an einem Wochenende statt. Die Arbeiten beginnen am Freitagabend, am Sonntag ist das produktive System mit dem neuen Release bereit. Dann werden nochmals wichtige Tests von der Testabteilung und dem Fachdienst durchgeführt. Falls später dennoch Probleme in der Produktion auftreten, werden diese direkt an den User Helpdesk gemeldet. Die Testabteilung analysiert die produktiven Fehler bis zwei Wochen nach dem Release, um unter anderem Erkenntnisse über die Qualität der Testfälle zu gewinnen.

Einsatz von Testrobotern

Solvaxis in Sonceboz verfolgt einen ganz anderen Ansatz als das Wasserfallmodell. Das Unternehmen, dessen Entwicklungsabteilung im bernischen Jura ansässig ist, entwickelt ihre eigene schweizerische ERP-Lösung. "Wir fangen schon während der Entwicklung mit Testen an", erklärt Eric Müller, Development Manager bei Solvaxis. Das Unternehmen setzt auch zu einem grossen Teil auf Testautomatisierung, sprich auf Testroboter. Der Tester erstellt ein Testscript, basierend auf Anwendungsfällen, und trainiert damit den Testroboter. Dieser kann dann diese Tests automatisch ausführen. Jede Nacht wird ein Build mit den neuesten Codefragmenten durchgeführt, sodass der Testroboter mit seiner Arbeit beginnen kann.

Auch Akros bevorzugt den agilen Entwicklungsansatz. "Beim Wasserfallmodell wird das Change Management oft nicht sauber gefahren", erklärt Flühmann. Die Folge davon ist, dass die Spezifikationen nicht nachgeführt sind und somit nicht mit der endgültigen Lösung übereinstimmen. "Beim Wasserfallmodell testet ein Tester oft gegen alte Requirements und die Testresulate sind dadurch wertlos." Das ergebe unschöne Ping-Pong-Spiele zwischen dem Entwickler und dem Tester.

Zukunft Testautomation

Akros setzt heute konsequent auf automatisiertes Testen und hat diesen Bereich kontinuierlich, unter anderem mit einer Firmenübernahme, ausgebaut. "Ich erwarte, dass die Testautomation in zirka einem Jahr unseren Hauptumsatz im Q-Bereich ausmachen wird", erklärt Flühmann. Klar lasse sich nicht alles automatisieren, aber man gehe davon aus, dass sich heute mindestens 50 Prozent der Testfälle automatisieren lassen. Früher seien es vielleicht zehn Prozent gewesen. Die erfolgreiche Einführung der Testautomation bedinge aber ein Umdenken im Qualität- und Prozessdenken.

Doch auch der agile Ansatz wie die Entwicklung nach Scrum ist nicht immer frei von Problemen: Vielfach sind bei neuen Applikationen die Test- und Produktionsumgebungen noch gar nicht vorhanden. Dies, weil Unternehmen Geld sparen und die Server und Umgebungen nicht umsonst laufen lassen wollen, wie Flühmann erklärt. Oft folgen die Test- und Produktionsumgebungen erst im letzten Drittel des Projekts, was ein kontinuierliches, agiles Testen von Projektbeginn an stark erschwert. Dies wiederum kann zu einem Problem werden, da Unternehmen oft unterschätzen, wie lange es dauert, um diese Umgebungen aufzubauen und produktionsfähig zu machen. "Ich verstehe aber auch, dass man nicht einfach Tausende von Franken für den Betrieb dieser Umgebungen ausgeben will." Bei der Arbeit mit Scrum sei man aber zwingend auf diese Test- und Produktionsumgebungen angewiesen.

Den eigenen Weg finden

Testautomatisierung, Testen mit dem Wasserfallmodell, testen mit Scrum – welcher Ansatz ist nun eigentlich der richtige? Im Prinzip geht es darum, herauszufinden, in welchem Kontext man welchen Ansatz anwenden muss, wie Adrian Zwingli, CEO von SwissQ, meint. Eines der grössten Probleme beim Testen sieht Zwingli bei den Anforderungen. Häufig wird definiert, wie das Endprojekt aussehen soll. Beim Testen muss man ja das Soll-Ergebnis kennen.

Die Anforderungen seien aber meistens so unklar und so oberflächlich beschrieben, dass der Tester selbst herausfinden müsse, was eigentlich gemeint sei. Diesem Problem liegt zugrunde, dass man die Anforderungen oft bewusst vage beschreibt, um später noch kleinere Anpassungen vornehmen zu können. Zwingli weist auch darauf hin, wie wichtig es ist, mehr in das Requirements Engineering zu investieren. Ein Tester müsse die Anforderungen reviewen können, bevor sie umgesetzt würden. Zwingli hat es "eigentlich nie erlebt", dass Anforderungen freigegeben werden konnten, ohne dass Änderungen notwendig gewesen wären oder bereits alle nötigen Informationen vorhanden waren.

Kommunikation verbessern

Um Missverständnissen vorzubeugen, ist es daher umso wichtiger, dass Entwickler und Tester eng zusammenarbeiten. Trennt man die beiden, fliessen die nötigen Informationen nicht mehr und es entstehen unterschiedliche Kulturen. Für Entwickler sei es wichtig, vom Denkansatz "Was will der denn noch? Der macht mir mein Programm kaputt!" wegzukommen und stattdessen zu denken: "Cool, wenn der Tester dabei ist."

In diesem Zusammenhang erzählte Zwingli eine kleine Anekdote. Anlässlich der Swiss Testing Days entschied sich ein Entwickler eines Unternehmens dafür, diese zu besuchen. Er wollte damit mehr über die Tester herausfinden, um sie besser verstehen zu können. Weil er sich aber alleine etwas fehl am Platz gefühlt hätte, fragte er einen Tester, ob dieser ihn begleiten würde. "Wenn das passiert, kann die erfolgreiche Zusammenarbeit beginnen."