Automatisiertes Testing

Wie sich die Software selbst testen kann.

14.03.2022 · Tech

Automatisiertes Testing

99 little bugs in the code, 99 little bugs in the code. Take one down, patch it around 117 little bugs in the code. – Altes Entwickler-Volkslied

Wer schon einmal mit dem Testing im Backend zu tun hatte, kennt die Grösse und Komplexität, die diese Aufgabe mit sich bringt. Alles ist mit allem verknüpft. Die Abhängigkeiten und Zusammenhänge einer kleinen Codezeile sind im Vorfeld nicht immer ersichtlich. Aus diesem Grund versuchen wir bei whatwedo, so viel wie möglich unserer Testings zu automatisieren. Unser Head of Technology Nicolo plaudert ein wenig aus dem Nähkästchen.

Ein kleines Update oder ein überschaubares, neues Feature einzubauen, klingt meist nach einer kleinen Sache. Auch das Testing dieser Anpassung sollte doch nicht viel Arbeit in Anspruch nehmen…, oder? Die Antwort: Kann sein, muss aber nicht! Natürlich können solche Neuerungen ab und an unkompliziert ablaufen.

Beim regulären Testing werden die spezifizierten Änderungen anhand der Abnahmekriterien durch Projektleitung und Kunde getestet. Testing in diesem Rahmen geht aber nicht in eine solche Tiefe, wie dies mit einer automatisierten Lösung umgesetzt wird.

Konkret bedeutet dies, dass …

  • jede Codezeile
  • alle Library-Updates
  • sämtliche Änderungen in Datenbanken
  • und schlussendlich der komplette DevOps Bereich

getestet werden müssen, um eine konstant hohe Qualität vor der Auslieferung an den Kunden zu gewährleisten.

Da wir teilweise auch als Digital Nomads unterwegs sind, kommt zudem die Problematik der asynchronen Arbeitsweise dazu. Wenn vom anderen Ende der Welt gearbeitet wird, kann da eine Reaktion auf einen kleinen Tippfehler schon einige Stunden auf sich warten lassen.

Um den diesbezüglichen Aufwand so gering wie möglich zu halten, bot sich für uns das automatisierte Testing mit GitLab als Lösung an.

Und wie funktioniert das jetzt?

Wie immer bei der Entwicklung werden die Phasen Code-Test-Deploy durchlaufen. Zudem wird immer in mehreren Umgebungen getestet.

Development (DEV)

Unsere Entwicklungsumgebung, in welcher die Softwareanforderungen umgesetzt werden und bereits funktionale Tests durchgeführt werden.

Integration (INT)

Die Integrationsumgebung simuliert nun jene Umgebung, die der definitiven Produktionsumgebung möglichst nahe kommt – wie auch Schnittstellen nach aussen haben kann.

Produktion (PROD)

Dies ist die definitive Betriebsumgebung.

Während dem Modultest selber, welcher mittels PHP-Unit durchgeführt wird, wird der Code dann automatisch auf dessen Qualität geprüft. Zudem erfahren wir auch immer, wie viel Prozent des Codes getestet wurde.

In der DEV-Umgebung kann der Code theoretisch gesehen einfach durchgewunken werden. Sobald aber die INT-Umgebung erreicht wird, muss manuell die Bereitstellung respektive das Deployment freigegeben werden. Dazu wird beim Testing ein Report generiert, welcher anzeigt, wie viel Prozent des Codes überprüft wurden. Sollte also ein Test scheitern, ist ein automatisches Deployment nicht möglich. Mithilfe des Reports kann einfacher geprüft werden, wo der Logikfehler gefunden werden kann.

Die Kommunikation respektive das Feedback zum durchlaufenen Test passiert bei uns mittlerweile komplett automatisiert über unser Messaging Tool Slack. Bei der Durchführung unserer Projekte wird jeweils ein Projektchannel erstellt und mit GitLab synchronisiert. Sobald ein Test die komplette Pipeline durchlaufen hat, erhalten wir umgehend eine Meldung, ob der Test erfolgreich war oder gescheitert ist.

Vor- und Nachteile

Welche Vorteile bietet die Automatisierung der Testings? Der eigentliche Test-Prozess wird viel effizienter und effektiver. Zudem werden auch Fehler bei jedem kleinen Update entdeckt und können frühzeitig behoben werden, da die komplette Anwendung getestet wird, wodurch der Qualitätsaspekt mehr Gewicht erhält. Denn nur, wenn die komplette Anwendung reibungslos läuft, entspricht die Qualität unseren wie auch den Anforderungen unserer Kunden.

Der Nachteil, welcher ein Testing in dieser Form mit sich bringt, ist der grosse Initialaufwand. So ist bei neuen Features +/- mit einem Aufwand von ca. 4 Stunden Entwicklung zu rechnen, sofern nur Standard-Cases getestet werden. Beim Edge-Case Testing kann sogar der doppelte Zeitaufwand anfallen. Zudem ist auch ein immenser Erfahrungsschatz notwendig. Denn es können nur jene Tests entwickelt werden, welche uns selber auch bekannt sind. So müssen auch Szenarien, welche noch nie eingetroffen sind, berücksichtigt werden, was im Vorfeld schwer zu beurteilen ist.

Wann macht dieser Aufwand Sinn?

Zusammengefasst kann also gesagt werden, dass Testing in diesem Umfang mit viel Initialaufwand verbunden ist. Sobald aber alles läuft und das Grundgerüst steht, können alle Beteiligten davon profitieren. Daher macht ein Testing in diesem Rahmen vor allem bei längerfristiger Zusammenarbeit Sinn. Die Werte bei whatwedo bauen auf langfristiger Zusammenarbeit auf. So können wir mittels automatisierten Tests unseren Kunden Software liefern, die Freude (und keine Fehlermeldungen) macht. Somit ist diese Investition etwas, was für uns nicht mehr wegzudenken ist.

Nie mehr etwas verpassen!

Erhalte eine Benachrichtigung per E-Mail, wenn wir einen neuen Blogpost publizieren. So bleibst du von deinen Lieblingsnerds immer informiert. Stay up to date!

Möchten Sie Ihr Testing ebenfalls automatisieren?

Nicolo Singer
Head of Technology
+41 31 511 26 26
nicolo@whatwedo.ch

Weiterstöbern

Business / Tech
Die Relevanz der Barrierefreiheit

Unser Gast-Autor René Stalder verrät in diesem Beitrag die Relevanz der Barrierefreiheit für Ihr Softwareprojekt.

Das ist whatwedo
whatwedo ist ein Software-Studio aus Bern, welches individuelle Web-Applikationen und Software auf Basis von modernen Technologien entwickelt.

+41 31 511 26 26
welove@whatwedo.ch

get in touch 
with whatwedo