Wird das Testen allein an das Projektende verschoben, können sich Probleme so verketten, dass sie erst in einer schwer zu durchschauenden Phase auffallen. Sinnvoller ist es, das erwartete Verhalten vor der Entwicklung zu besprechen und fertiggestellte Teile während des gesamten Prozesses zu prüfen. So wird der Liefertag nicht zum ersten echten Testtag.
01Ein gemeinsames Verständnis des erwarteten Verhaltens schaffen
Die Aussage „ein Berichtsbildschirm wird erstellt“ bedeutet nicht für alle Beteiligten dasselbe. Welcher Zeitraum wird verwendet, wie sieht ein leeres Ergebnis aus, wer darf den Bericht exportieren? Werden die Antworten auf diese Fragen in Testszenarien überführt, können Entwickler, Designer und Kunde dasselbe Ergebnis bewerten. Frühe Klarheit hilft, spätere Doppelarbeit zu vermeiden.
02Auch fehlgeschlagene Abläufe testen
Ein Nutzer kann falsche Daten eingeben, seine Sitzung kann ablaufen, oder er klickt versehentlich zweimal auf „Speichern“. Der Testplan muss diese Fälle ebenso abdecken wie den korrekten Ablauf. Bleiben gespeicherte Daten erhalten, ist die Fehlermeldung verständlich, entsteht der Vorgang nicht versehentlich doppelt? Die Zuverlässigkeit eines Produkts zeigt sich genau in diesen kleinen Momenten.
03Die Schnittstellen zwischen den Teams prüfen
Arbeiten verschiedene Entwickler parallel an einem Projekt, reicht es nicht, dass jedes Modul für sich funktioniert. Auch die zwischen den Bildschirmen übertragenen Informationen, Nutzerrollen und Datenformate müssen konsistent sein. Das breit aufgestellte Entwicklerteam und das professionelle Testteam von Paradigma7 behandeln diese Schnittstellen als festen Bestandteil des Lieferplans. Die dahinterliegende parallele Arbeitsweise beschreiben wir in unserem Beitrag zum globalen Team. Geschwindigkeit entsteht nicht dadurch, dass Kontrollschritte entfallen.
04Den Nachweis der Lieferung verständlich aufbereiten
Ein Testergebnis sollte nicht nur aus dem Wort „bestanden“ bestehen. Festgehalten werden sollte, welches Szenario in welcher Version getestet wurde, welche Auswirkung ein verbliebenes Problem hat und wie das erneute Prüfergebnis ausfiel. So kann der Kunde erkennen, welcher Umfang tatsächlich abgeschlossen ist. Tests verringern Risiken, versprechen aber nicht, dass unter keinen Umständen ein Fehler auftritt – stattdessen sorgen sie für sichtbare Qualität und einen nachvollziehbaren Prozess. Die Rolle des Testnachweises im Lieferpaket behandeln wir in unserem Leitfaden zur schlüsselfertigen Softwarelieferung. In unserem Individualsoftware-Service ist Testen auf diese Weise in jeder Phase verankert.
05Kurze Checkliste
- Wurde für jede wichtige Aufgabe das erwartete Verhalten in ein schriftliches Szenario überführt?
- Wurden fehlgeschlagene Abläufe wie falsche Eingaben, abgelaufene Sitzungen und Doppelklicks getestet?
- Wurden Datenübertragung zwischen Modulen und Rollenrechte gemeinsam getestet?
- Sind Testergebnisse zusammen mit der Versionsnummer dokumentiert?
- Wurde dem Kunden die Auswirkung offener Probleme erklärt?
Geschrieben von
Das Paradigma7-Team
Produkt, Entwicklung und Betrieb
Wir sind ein Team aus Ankara und entwickeln Software für Europa. Nichts davon ist Theorie: Es sind die Prozesse, die wir in Kundenprojekten tatsächlich fahren.
Über uns