Software richtig testen

Das richtige Testen von Software ist ein heiß diskutiertes und durchaus umstrittenes Thema in der Softwareentwicklung. Aufgrund der Brisanz der Ergebnisse des Entwicklungsprozesses, sind dabei auch das Qualitäts- und Projektmanagement betroffen. Die Entwicklungsabteilung ist stets die erste Stelle, welche die eigenen Implementierungen testet, allerdings stellen sich häufig mehrere Fragen:

Warum eigentlich testen?
Was sollte getestet werden?
Wie sollte getestet werden?
Wer sollte testen?
Wann sollte getestet werden?

Die Frage “Warum” wird häufig spontan mit Qualität beantwortet. Softwarequalität kann nur dann sichergestellt werden, wenn die Software getestet wird. Doch was ist eigentlich Qualität? Die Tatsache, dass die Software funktioniert, oder dass sie tut was soll? JA! Aber, das ist bei weitem nicht alles. Zur Qualität gehören durchaus auch Merkmale wie Zuverlässigkeit, Änderbarkeit oder Design. Zum Punkt Design sagte Steve Jobs einmal: “Design is not just what it looks like and feels like. Design is how it works.” Und es sind genau solche Faktoren, welche die Qualität von Software entscheident beeinflussen und über den Erfolg oder Misserfolg von Softwareprojekten mitentscheiden. Als konkrete Richtlinie für dieSoftwarequalität kann deshalb der ISO/IEC-Standard 9126 herangezogen werden, welcher wie folgt aufgebaut ist.

Eine etwas genauere Spezifikation der einzelnen Ausprägungen kann hier heruntergeladen werden. Nach diesen ersten Überlegungen, kann die Frage “Warum” leicht beantwortet werden, denn es geht nicht nur darum zu testen, ob die Software funktioniert, sondern unter anderem auch wie sie funktioniert und ob sie, unter Beachtung der gegebenen Rahmenbedingen, das tut was die soll. Die Frage nach dem “Was” kann man demzufolge durch die ISO/IEC 9126 ebenfalls grob beantworten. Das konkrete Vorgehen sollte allerdings projektabhängig spezifiziert werden.

Kommen wir nun zur Frage “Wie”. Ein sehr guter und verbreiteter Ansatz stellt hierbei das V-Modell dar, genauer gesagt, dessen aufsteigender Ast (der absteigende Ast zielt im wesentlichen auf das Projektmanagement ab). Dieses Modell unterteilt den Testprozess in vier Teilprozesse: Unit-Tests, Integrations-Tests, System-Integration sowie Abnahme und Nutzung.

• Unit-Test: Test auf der Ebene einzelner Module (Klasse) mit dem Ziel der Sicherstellung korrekter Teilergebnisse. Hierbei werden also die einzelnen Komponenten einer Software unabhängig voneinander betrachtet und getestet. Andere Komponenten werden dabei durch Stubs oder Mocks simuliert. Bei dieses Tests handelt es sich um automatisierte Tests, welche beispielsweise mit JUnit oder PHPUnit realisiert werden.
• Integrations-Test: Test der Zusammenarbeit voneinander abhängiger Komponenten. Im Gegensatz zu den Unit-Tests, werden also andere Komponenten nicht mehr simuliert sondern tatsächlich verwendet. Ziel ist dabei die Sicherstellung korrekter Gesamtergebnisse durch das Zusammenspiel der unterschiedlichen Komponenten. Es handelt sich ebenfalls um automatisierte Unit-Tests, allerdings auf einer anderen Ebene.
• Systemtest: Test des Systems gegen die Anforderungen des Kunden auf einer Testumgebung. Wichtig ist dabei, dass die Testumgebung die Produktivumgebung simuliert. Systemtests machen nur bedingt Sinn, wenn die Hardware- oder Softwareressourcen nicht denen des Produktivsystems entsprechen. Diese Tests können sowohl automatisch (z.B. Oberflächentests mit Selenium bei Webanwendung) als auch manuell durchgeführt werden. Im Falle der manuellen Durchführung sind unterstützende Tools, wie beispielsweise Testopia, sehr sinnvoll, da dadurch die Tests leicht dokumentiert werden können.
• Abnahmetest (UAT = User Acceptance Test): Test der Software durch den Kunden. Es handelt sich also um die End-/Abnahmeprüfung vor der Produktivnutzung. Hier sollten im Idealfall keine Fehler mehr auftreten.

Aufbauend auf dem vorgestellten Testmodell, kann nun über die Frage “Wer” nachgedacht werden. Wie bereits erwähnt, werden die Unit- und Integrations-Tests in der Regel automatisch durchgeführt und müssen demnach implementiert werden. Gleiches gilt für die Verwendung von automatischen Oberflächentests. In manchen Fällen kann man diese Obenflächentests allerdings nicht automatisieren (was auch gut so ist), sodass hier echte Menschen ans Werk müssen. Hierbei ist stark davon abzuraten, die Entwickler als Tester einzusetzen, da diese mit einem suboptimalen Blickwinkel auf die Software sehen. Es sollten hierzu Personen herangezogen werden, welche mit dem Projekt möglichst wenig bis gar nichts zu tun haben, da diese am besten die Bedienbarkeit (also das Design) beurteilen können und eher versuchen werden, das System zum “erliegen” zu bringen. Idealerweise existiert im Unternehmen eine spezialisierte Test-Abteilung, welche sich genau dieser Aufgabe annimmt.

Wie man sieht, werden im V-Modell leider die Qualitätskriterien nicht zu 100% unterstützt – gerade was die eher technischen Aspekte betrifft. Diese Kriterien können am ehesten die Entwickler selbst, oder aber Entwickler aus fremden Projekte beurteilen.

Zu guter Letzt noch das TeTo-Prinzip: Test early, test often!