Sicherstellen der Qualität

Convo Entwicklungszyklus – Teil 5

Dies ist der nächste Teil unserer Blog-Beitrag-Serie, diesmal zum Thema Test. Im vorherigen Beitrag wurde schon ausführlich beschrieben, wie Anforderungen von den Entwicklern umgesetzt werden. In diesem Beitrag wird der Ablauf beschrieben, wie wir von den Anforderungen zu einer qualitätsgesicherten Umsetzung kommen.

Testaspekte – was wird getestet?

Zuerst verschaffen wir uns einen Überblick darüber, was eigentlich getestet werden soll. Bevor konkret Testfälle geschrieben werden, sollte schon klar sein, was mithilfe der Testfälle überprüft werden muss. Dazu werden Testaspekte abgeleitet, die kurz und knackig erwartete Ergebnisse an Aktionen des Users knüpfen. Dabei folgen wir strikt dem Schema: Wenn ich dieses tue, erwarte ich folgendes. Ein Testaspekt ist beispielsweise nicht „In dem Header wird Convo richtig geschrieben“, sondern „Wenn man auf Convo in dem Header klickt, wird man zum Dashboard weitergeleitet“. Das heißt nicht, dass die Rechtschreibung nicht auch überprüft werden sollte! Aber in der Aufwand-Nutzen-Abwägung wird schnell klar, dass nicht zu jedem Textabschnitt einzeln ein Testaspekt angelegt werden sollte.

Bei Testaspekten kann es hilfreich sein, zwischen Positiv- und Negativfällen zu unterscheiden. Ein Positivfall beschreibt dabei Aktionen, die ein User durchführt, die dem erwarteten Verhalten entsprechen. Ein Negativfall beschreibt Aktionen, die ein User bei normaler Benutzung des Tools eigentlich nicht durchführen sollte, die aber trotzdem auftreten können. In beiden Fällen soll das Tool jedoch gleichermaßen korrekt auf die Aktion reagieren.

Die in Gitlab formulierte Anforderung (siehe Beitrag “Von einer Idee zur Anforderung“) ist der erste Ausgangspunkt für unsere Testaspekte. Die Akzeptanzkriterien sind häufig so formuliert, dass sich direkt Testaspekte für die Positivfälle daraus ableiten lassen. Die Negativfälle erfordern noch etwas mehr Analyse, aber aus detailliert geschriebenen Anforderungen leiten wir auch diese ab. Wie in den vorangegangenen Blogbeiträgen beschrieben, haben wir als Feature eine Vorschau umgesetzt, um sich in Convo erstellte Formulare anzeigen zu lassen. Ein Teil der Umsetzung zu den Änderungen der Vorschau ist zum Beispiel die Anzeige der Formulare in verschiedenen Geräterahmen.

Beispielhafter Positivfall: Wenn eine Größe für den Geräterahmen eingestellt wird, wird diese korrekt in der Vorschau angezeigt.
Beispielhafter Negativfall: Wenn versucht wird, bei der Größe für den Geräterahmen etwas anderes als Zahlen einzugeben, wird die Eingabe nicht übernommen.

Nicht jeder Testaspekt ist gleichwertig in dem Risiko, das er birgt, daher gibt es Unterschiede in der Priorisierung. Die Häufigkeit des Auftretens und der Schaden bei Fehlschlag eines Testaspekts sind ausschlaggebend für das Risiko. Dabei sind Positivfälle im Allgemeinen höher zu priorisieren als Negativfälle, da sie häufiger im normalen Gebrauch des Tools vorkommen. Ausnahmen bestätigen wie immer die Regel: Wenn es für den Benutzer “leicht” möglich ist, eine ungewollte Handlung durchzuführen, sollte das Tool diesem Szenario unbedingt standhalten können. Der Entwickler, der das Ticket bearbeitet, kann bereits während der Umsetzung die Testaspekte heranziehen, um etwaige Fallstricke (Negativfälle) zu berücksichtigen.

Nun könnte man bei dem Geräterahmenbeispiel annehmen, dass, wenn die Größe des Geräterahmens pixelgenau eingestellt werden kann, jede mögliche Eingabe einmal überprüft werden muss. Um sich extrem viel Aufwand zu sparen, aber gleichzeitig viele Risiken abzudecken, reduzieren wir die Menge der überprüften Eingaben. Dazu treffen wir Unterteilungen mithilfe von Grenzwertfällen und Äquivalenzklassen.

Der benutzerdefinierte Geräterahmen kann nur auf Pixelgrößen innerhalb eines festgelegten Bereiches eingestellt werden. Die Werte am Rand dieses Bereiches sind häufiger fehleranfällig (z. B. durch fehlerhafte Verwendung von < und ≤) und daher wichtiger zu überprüfen. Außerdem kann man mögliche Eingaben in Äquivalenzklassen unterscheiden. Es gehören alle erlaubten Zahleneingaben in eine Klasse, alle Zahleneingaben über- bzw. unterhalb des Grenzwertes in zwei weitere Klassen und schließlich alle nicht-Zahleneingaben wie Buchstaben und Sonderzeichen in eine letzte. Wir gehen davon aus, dass sich das System bei der Eingabe von Werten aus derselben Äquivalenzklasse gleich verhält.

Anhand dieser Anhaltspunkte reduzieren wir unsere Testaspekte: Wir überprüfen nur Zahleneingaben um die Grenzwerte herum, dabei jeweils die “gerade noch erlaubten” Werte (Positivfälle) und die “gerade nicht mehr erlaubten” Werte (Negativfälle). Zusätzlich kommt noch ein Testaspekt für die Eingabe von Buchstaben/Sonderzeichen, damit sind dann alle Grenzwertfälle und Äquivalenzklassen abgedeckt. Somit überprüfen wir letztendlich nur 5 unterschiedliche Eingaben, anstatt die quasi unendlich große Anzahl an möglichen Eingaben.

Testfälle – wie wird getestet?

Testfälle werden auf Basis der Testaspekte geschrieben. Dabei können häufig auch mehrere Testaspekte mit einem Testfall abgedeckt werden. Idealerweise werden bereits vor dem Mergen automatisierte Testfälle erstellt. Da dies nicht in allen Fällen möglich ist, werden ergänzend auch manuelle Testfälle erstellt.

Automatisierte Testfälle sind in der Regel insgesamt mit weniger Zeitaufwand verbunden, da sie, abgesehen von dem initialen Erstellen, nur sporadisch wieder bearbeitet werden müssen und schneller die programmierten Schritte durchführen, als ein manueller Tester dies kann. Um die automatisierten Testfälle zu schreiben, verwenden wir bei Convo das Framework Selenium. Die Testfälle werden in der beschreibenden Sprache Gherkin formuliert, wodurch sie auch für Personen ohne Programmierkenntnisse nachvollziehbar sind.

Bei Convo werden alle automatisierten Testfälle vor jedem Mergen vom Feature-Branch auf den allgemeinen Entwicklungsstand durchgeführt. Das hilft, Fehlerzustände rechtzeitig zu erkennen, die durch die Änderungen entstanden sein könnten. In diesem Zuge werden auch automatisch die Beschreibungen der automatisierten Testfälle in straX dokumentiert.

Testpläne – was wurde wann getestet?

StraX? Was ist das? Für die genaue Vorstellung von straX möchte ich auf den Beitrag “straX: Testmanagement mit Jira” meines Kollegen Jörg Paelke verweisen. In aller Kürze zusammengefasst, sind in straX alle Testaspekte dokumentiert, ihre Abdeckung durch einen Testfall festgehalten und mit den zugehörigen Testfällen verbunden. Auch die Durchführung der Testfälle und die Testpläne (also die Bündelung von Testfällen) sind in straX dokumentiert.

Während die Anforderungen bei Convo in Gitlab formuliert werden, wird durch das Verlinken zu straX eine Rückverfolgung in beide Richtungen hergestellt. Die Testpläne sind eine gute Möglichkeit, bei einer Auslieferung des Produkts den Stand der Tests (letzte Ausführung und Ausführungsergebnis) zu dokumentieren und zu archivieren. Und das für alle automatisierten und manuellen Testfälle. Durch die Verwendung von Gherkin sind die Testfälle im Allgemeinen ohne weitere Anmerkungen auch für Außenstehende verständlich.

Bugs – was hat nicht funktioniert?

Wenn etwas nicht wie erwartet funktioniert, wurde ein Bug gefunden. Das Ziel ist es, frühzeitig mithilfe der Testfälle möglichst viele Bugs zu identifizieren, damit diese schnell behoben werden können. Bugs können auch in Features auftreten, die zuvor fehlerfrei funktioniert haben, da Änderungen an einer Stelle im Code auch unerwartete Auswirkungen auf andere Bereiche des Codes haben können. Da wir bei Convo bereits vor dem Mergen alle automatisierten Tests durchführen, können wir die Entstehung dieser Bugs zum größten Teil schnell abfangen und schnell die Ursache ausfindig machen.

Wenn Bugs gefunden werden, wird ein Bugticket in Gitlab erstellt. Bei der Behebung des Bugs hilft es, möglichst viele Information in dem Ticket festzuhalten. Dazu wird der Testrun verlinkt, in dem der Bug aufgefunden wurde. Dies erleichtert die Nachvollziehbarkeit, welche Bedingungen und Schritte zu dem Bug geführt haben, wodurch das Fehlerverhalten wiederum schnellstmöglich behoben werden kann.

Fazit

Bei Convo werden automatisierte Testfälle genutzt, um sicherzustellen, dass die Qualität des Produkts gleichbleibend hoch ist. Diese werden ergänzt durch einige manuelle Testfälle, für die automatisierte Tests zu komplex wären. Werden neue Anforderungen umgesetzt, wird geprüft, ob alle neuen Komponenten auch getestet werden.
Durch unser methodisches Vorgehen bei dem Erstellen der Testaspekte und dem Priorisieren der Testaspekte nach dem Risiko können die meisten Fehler frühzeitig gefunden werden, was das Vertrauen in unsere Anwendung erhöht. Überzeugt euch selbst.