Der richtige Mix zwischen zu viel und zu wenig Software Testing

Software Testing findet Probleme, bevor sie in Produktion auffallen, und belegt, dass Funktionen tun was sie sollen. Entscheidend ist dabei nicht die Menge der Tests, sondern ihre Auswahl: Ein Testlauf, der nichts Geschäftskritisches abdeckt, kostet Zeit und liefert trotzdem keine Sicherheit.

Vier Testarten und wofür sie taugen

Die gängigen Methoden lassen sich in vier Klassen einordnen. Jede hat einen anderen Zweck, sie ersetzen einander nicht.

Unit- und Modultests

Sie prüfen die Funktionen einer einzelnen Komponente im Detail. Die Testroutinen entstehen in der Regel schon während der Entwicklung des Moduls, bevor es ins Gesamtsystem eingebunden wird oder live geht. In der agilen Entwicklung sind sie fester Teil der Umsetzung: Die Qualität eines Moduls steht damit fest, bevor es ausgerollt wird.

Integrationstests

Sie prüfen, ob die Komponenten eines Systems sauber zusammenspielen, allen voran die Schnittstellen. Läuft der Datenaustausch mit angebundenen Systemen fehlerfrei? Diese Frage wird wichtiger, je mehr Systeme an einer Plattform hängen. Ein Integrationstest besteht deshalb meist aus einer ganzen Reihe einzelner Testabläufe. Sie zeigen ausserdem früh, wie gut sich eine neue Lösung überhaupt in die bestehende Landschaft einfügt.

Smoke-Tests

Sie kontrollieren, ob Funktionen und Dienste überhaupt vorhanden und erreichbar sind. Zwei Zeitpunkte sind sinnvoll: vor dem Go-live einer neuen Anwendung, um die Verfügbarkeit der Gesamtplattform abschliessend zu prüfen, und im laufenden Betrieb. Fällt eine Komponente auf dem Server oder ein externes Skript unbemerkt aus, ist eine Funktion weg, ohne dass die Seite kaputt aussieht. Für die automatisierten Durchläufe setzen wir Ghost Inspector ein, das auch sonst Teil unseres Technologie-Stacks ist.

Manuelles Testing

Die aufwendigste Variante, und die einzige, die zeigt, wie sich eine Anwendung tatsächlich bedienen lässt. Hier fallen Abläufe auf, die technisch korrekt, aber umständlich oder unlogisch sind. Manuelles Testing ist damit vor allem ein Werkzeug für UX und UI und weniger für den Funktionsnachweis.

Der richtige Mix hängt am Projekt

Wie viel Testing ist genug? Aus unserer Sicht hängt das stark vom Projekt ab. Ein Website-Projekt hat meist deutlich weniger Funktionen als eine Webapplikation, die ganze Geschäftsprozesse abbildet, und braucht entsprechend weniger Testautomation und weniger Entwicklungsaufwand für Tests.

Die Leitplanke bleibt dieselbe: Alle businesskritischen Abläufe müssen abgesichert sein. Der Warenkorb in einem Webshop muss funktionieren, sonst geht direkt Umsatz verloren. Für solche Regeln schreiben wir Unit- oder Behat-Tests.

Behat-Tests beschreiben ein Szenario in normaler Sprache, bevor eine Zeile Testcode entsteht, nach dem Muster «Gegeben», «Wenn», «Dann». Dadurch lässt sich auch ohne Entwicklungshintergrund nachlesen, was ein Test tatsächlich absichert.

Weil sich die businesskritischen Abläufe von Projekt zu Projekt unterscheiden, lassen sich fertige Tests selten eins zu eins wiederverwenden. Umschreiben geht dagegen schnell, das hält den Aufwand pro Projekt im Rahmen.

Was Testing konkret bringt

Eine neue Plattform ohne Tests in Betrieb zu nehmen, ist in vernetzten IT-Umgebungen riskant: Funktioniert eine einzelne Komponente nicht wie erwartet, zieht das eine Reihe weiterer Prozesse mit. Der Nutzen liegt entsprechend auf mehreren Ebenen:

• Qualitätssicherung. Eine gezielte Teststrategie deckt ein breites Spektrum an Problemen ab, bevor sie in den produktiven Betrieb gelangen.
• Funktionsprüfung. Automatisierte Durchläufe kontrollieren in hoher Frequenz, ob die konfigurierten Abläufe verfügbar sind.
• Bessere Bedienbarkeit. Manuelle Tests decken Schwächen in UI und UX auf, die kein automatisierter Test findet.
• Kosteneffizienz. Ein automatisierter Testlauf verursacht nach dem Aufsetzen kaum noch Aufwand und läuft beliebig oft.

Wie wir dich einbinden

Das Ziel ist nicht, möglichst viel zu testen, sondern die richtigen Tests für das gewünschte Ergebnis zu wählen. Welche das sind, klären wir mit dir: bei Fachanwendungen kennt niemand die Anforderungen besser als du.

Dafür stellen wir dir eine eigene Testumgebung bereit, in der du selbst prüfen kannst. Mit dem Test- und Abnahmeprotokoll endet die Entwicklungsphase.

Welchen Mix wir in unseren eigenen Plattformen einsetzen, steht im Folgebeitrag.