In der schnelllebigen Welt der Softwareentwicklung bleibt die Zeit nicht stehen. QA- und Ingenieurteams können nur selten innehalten und auf die Geschehnisse der vergangenen Wochen oder Monate zurückblicken. Genau das tun wir jetzt.
Eine kurze Geschichte der Softwareentwicklung
Obwohl Agile Entwicklungsframeworks wie Kanban in den 1940er Jahren entstanden, blieb lange Zeit die Wasserfallmethode führend. Angesichts neu aufkommender Technologien und zunehmend globaler – und damit wettbewerbsbetonter – Märkte begannen Verbraucher, ihre Anforderungen und Erwartungen höherzustecken. Gleichzeitig sank die durchschnittliche Gebrauchsdauer der Produkte. Lange Rede, kurzer Sinn: Das Wasserfallmodell wurde schrittweise abgeschafft.
Agile Methoden und Frameworks gewannen schnell an Beliebtheit und werden heute bei praktisch allen Softwareentwicklungsprojekten eingesetzt. Damit konnten Unternehmen nicht nur schneller auf die ständig wechselnden externen Faktoren reagieren und sich daran anpassen, sondern die neuen Erkenntnisse auch direkt in ihre Entwicklungsprozesse übernehmen. In einer VUCA-Welt (dies steht für „volatile, uncertain, complex, and ambiguous“, also volatil, unsicher, komplex und mehrdeutig) kann Agile durchaus zum Wettbewerbsvorteil werden.
Die meisten Unternehmen (nicht nur im Technologiebereich) nutzen diese Methoden inzwischen. Sie gehen davon aus, so schnell auf wechselnde Anforderungen reagieren zu können. Schnelle Releases sind inzwischen die Norm und damit hat die bloße Geschwindigkeit ihren Status als Wettbewerbsvorteil verloren. Wie geht es also weiter?
Eine kurze Einführung in DevOps
Fragen wir uns nicht, wie es weiter geht, sondern was gerade los ist. Und die Antwort lautet: DevOps. DevOps ist die Fähigkeit, jederzeit vollständig betriebs- und geschäftsbereit zu sein. Es handelt sich um eine Reihe von Praktiken zur Automatisierung und zum Management des gesamten Engineering-Prozesses von Ende zu Ende, also zwischen Softwarentwicklungs-, QA- und IT-Betriebsteams. Mit dieser Methodik können diese Teams Software beständig und zuverlässig entwickeln, testen und veröffentlichen. So haben die Teams ein ganzheitlicheres Bild der internen Prozesse; die externe und an den Kundenbedürfnissen orientierte Herangehensweise der Agile Frameworks wird so ergänzt. Für Organisationen, die hochwertige und nahtlose Bereitstellungsprozesse garantieren wollen, obwohl mehrere Teams an denselben Produkten arbeiten, ist DevOps eine attraktive und moderne Option.
Alles automatisieren!
In der Vergangenheit wurde sowohl bei der Wasserfall- als auch der Agilen Methode die QA-Abteilung benachrichtigt, sobald die Entwicklung abgeschlossen und der neue Build testbereit war. QA führte dann manuelle Regressionstests sowie vollständige funktionsbasierte Tests aller neuen Komponenten durch und dann noch ein paar explorative Tests. War QA mit den Tests fertig, ging der Build entweder zurück in die Entwicklung, wo er überarbeitet wurde, oder die Organisation schaltete ihn live.
Mit der Skalierung auf zahlreiche Teams ist dieser Ansatz nicht mehr nachhaltig. Der ständige Wechsel verschiedener Builds in verschiedenen Staging-Umgebungen führt häufig zu Verwirrung.
Daher müssen sich die QA-Teams anpassen und deutlich mehr aneinander ausrichten. Das kann folgendermaßen gehen:
- Umgebungen standardisieren,
- Deployments automatisieren,
- Tests automatisieren (einschließlich Pre-Testing- und Post-Testing-Aufgaben),
- Testfälle automatisieren und in effizienten Sets gruppieren (Rauchtests, Regressionssuiten), um 100 % Testabdeckung zu erreichen,
- zuverlässiges Timeboxing beim Testen implementieren.
Wir stellen eins klar: Teams sollten den Test-Prozess so weit wie möglich automatisieren, damit er bei Bedarf effizient und effektiv automatisch ablaufen kann. Automatisierung erfordert weniger manuelle Arbeit und bringt die QA- und IT-Infrastruktur-Teams zusammen – das ist mit speziellen Automatisierungs- und CI/CD-Tools möglich. Außerdem wird ein ausgereiftes Automatisierungsframework ausschlaggebend, damit die Teams neue Testfälle schnell skripten und hinzufügen können.
Kann wirklich der ganze Testprozess automatisiert werden?
Leider kann man selbst bei einer Testabdeckung von 100 % nie ganz sicher sein, dass sich keine Bugs oder Probleme einschleichen. Daher muss die Frage oben aus drei Gründen mit „Nein“ beantwortet werden:
1. Man weiß nie alles
Automatisierte Testfälle bergen einen großen potenziellen Fehler: Sie werden von Menschen geschrieben. Das mag unfair klingen, aber sind wir mal ehrlich – eine Person kann sich nur eine begrenzte Anzahl von Szenarien vorstellen. Und selbst wenn der gesamte Code abgedeckt ist, könnten ihn verschiedene Bearbeitungsmethoden mit anderen Variablen/Testumgebungen stören. Außerdem wird man durch umfassende Erfahrung auch betriebsblind. Man rechnet einfach nicht mit Problemen in einem bestimmten Bereich, weil da noch nie etwas schiefgegangen ist. Das Problem ist, dass man nie weiß, was man nicht weiß.
2. Man kann nicht alles tun
Stellen wir uns jetzt eine Ausnahme vor; du weißt tatsächlich alles! (Ich bin übrigens sehr neidisch deswegen.) Trotzdem gibt es noch technologische Beschränkungen, die verhindern, dass du bestimmte Fälle automatisierst, selbst wenn du das möchtest. Hier ein Beispiel: ein Skript, in dem das Telefon aus- und wieder eingeschaltet werden muss. Schade!
3. Man tut nicht alles
Aha! Du bist also ganz pfiffig und schlägst vor, dass sich ein Roboter um die physischen Interaktionen wie das wiederholte Drücken des Ein-Schalters auf dem Fingerabdrucksensor kümmert. Das könnte funktionieren, aber wir alle sind mit knappen Ressourcen geschlagen, nämlich Zeit und Geld. Erstens wäre es einfach zu teuer, alle Geräte für die Tests zu kaufen. Zweitens würde es ewig dauern und damit den Prozess verschleppen.
Du würdest dich also für eine priorisierte Liste der abzudeckenden Geräte entscheiden und nur einen Teil aller Varianten der Testfälle, die durchgeführt werden können, auswählen.
Außerdem geht es bei Tests in der realen Welt nicht nur darum, die Funktionen abzudecken. Es müssen auch Dinge wie Benutzerfreundlichkeit, Zahlungsintegration, Lokalisierung, usw. bedacht werden. Vieles davon überschreitet den Arbeitsbereich von DevOps.
Der Schlüssel zum erfolgreichen Testen in DevOps: der richtige Testmix
Die Welt ist nie nur schwarz und weiß und der Happy Path führt nicht immer ans Ziel. In DevOps dreht sich alles um Automatisierung, und alle Unternehmen, die sich im digitalen Feld behaupten wollen, müssen sich in diese Richtung entwickeln.
Allerdings vermögen die meisten Unternehmen nicht einfach alles zu automatisieren, was automatisiert werden könnte. In vielen Bereichen wäre das Risiko für einen Fehlschlag zu groß, zum Beispiel:
- in nicht-funktionellen Bereichen,
- bei einer breiten Kundenbasis, die verschiedene Systeme nutzt,
- in Szenarien, die beim Skripten der Testfälle nicht bedacht wurden.
Daher sind manuelle Tests – insbesondere explorative Tests mit realen Nutzern und Geräten – eine hervorragende Ergänzung, um alle Bereiche und externen Faktoren abzudecken.
Manuelles Testen in DevOps integrieren
Da in DevOps so großer Wert auf Prozessautomatisierung gelegt wird, mag es scheinen, als ob manuelles Testen überhaupt keinen Platz mehr hat. Das ist so nicht richtig, wie wir eben dargestellt haben. Manuelles Testen bleibt weiterhin ein wichtiger Bestandteil des Testmixes der meisten Unternehmen.
Funktionsflaggen sind eine gute Möglichkeit, um das richtige Gleichgewicht zwischen manuellem Test und Automatisierung zu finden. Mit Funktionsflaggen werden Funktionen in der Produktion aktiviert, deaktiviert oder verborgen. So kann der Code an die Produktion geliefert werden und alle automatisierten Test- und Bereitstellungsprozesse durchlaufen, was eine gewisse Qualität sichert.
In der Produktion (oder beim Staging, usw.) können die Funktionsflaggen für einen bestimmten Prozentsatz der Nutzerschaft oder das QA-Team eingeschaltet werden, damit die manuellen Tests stattfinden können. So werden zusätzliche Erkenntnisse gewonnen und zum Entwicklungsteam geschickt. Die Länge solcher Tests hat keinen Einfluss auf die DevOps-Prozesse, weshalb diese eine solch gute Ergänzung sind.
Hier findest du mehr über unsere Lösung zu Integrierten funktionalen Test, wo du erfährst, wie du manuelles Testen und Testautomatisierung in einer umfassenden Herangehensweise verbindest.