SwissQ
Wer kennt nicht folgende, typische Situation
Das Datum für den nächsten Release wurde bereits kommuniziert, allerdings ist die Entwicklung noch voll daran die erwarteten Features zu implementieren. Die geplante Testphase reduziert sich somit bereits zum dritten Mal auf das absolute Minimum, damit überhaupt ansatzweise das versprochene Releasedatum gehalten werden kann. Man verzichtet somit bewusst auf Feedback über die Qualität des Softwareprodukts…
Aber wer sind am Tagesende nun die Gewinner und Verlierer dieses Vorgehens?
Der Gewinner ist einzig der Projektmanager, der in Time und Scope abgeliefert und somit (wahrscheinlich) seinen Bonus kassiert hat. Mehr Gewinner fallen mir nicht ein, Verlierer hingegen gibt es (leider) viele z.B.:
- Der Kunde: Aufgrund unzureichender Qualitätskontrolle muss er mit verschiedenen Fehlern in der Software bei seiner täglichen Arbeit leben und hat vermutlich Effizienz-Einbussen.
- Die Entwicklungsfirma: Aufgrund der fehlerhaften Software erhält der Kunde einen schlechten Eindruck über die Entwicklungsfirma und das Softwareprodukt und wird diese nicht mehr weiterempfehlen und im schlimmsten Fall sogar negativ darüber sprechen.
- Der Betrieb: Dieser muss verschiedene „hot patches“ und „bug fixes“ einspielen und dabei jedes Mal das Risiko eingehen, dass die Applikation anschliessend nicht mehr vollumfänglich funktioniert, welches somit wieder in weiteren Patches endet…
Aber wie könnte man obige Situation vermeiden?
Natürlich mittels DevOps.
Aber was heisst das nun im Detail?
DevOps ist derzeit in aller Munde, und ich vermute, dass Euch bei Eurer Firma das Wort auch schon begegnet ist. Grundsätzlich steht DevOps für Development & Operation und enthält im Namen weder „Test“ noch irgendetwas mit „QA“. Dadurch könnte man schlussfolgern, dass es nichts mit Testing zu tun hat und mich somit in meiner Rolle als Tester/Test Manger/Test Engineer nicht betrifft.
Aber ist dem wirklich so?
Mittels DevOps wird u.a. versucht, den Flow von Design über Entwicklung, Testing bis hin zum Betrieb zu beschleunigen, ohne dabei auf Feedback über die Qualität durch das Testing zu verzichten. Diese Beschleunigung, mit dem Ziel schneller und mit höherer Qualität zu releasen, verlangt ein komplettes Umdenken der Tester.
In DevOps gibt es z.B. keine dedizierte Testphase mehr, sondern das Testing wird kontinuierlich durchgeführt, im Idealfall bei jedem Build. Man spricht hierbei von Continuous Testing (CT). Dieses kontinuierliche Testing bedingt natürlich auch einen hohen Grad an Automatisierung, insbesondere Testautomatisierung.
Was heisst das nun schlussendlich für mich als Tester?
Ihr habt bestimmt schon von dem „Testing shift-left“ gehört, d.h. das Testing muss näher zur Entwicklung rücken. Aber kennt Ihr auch „Testing shift-right“? Canary, Chaos Engineering oder A/B Testing dürfen für die Tester keine Fremdwörter sein.
Welche weiteren Praktiken werden im DevOps eingesetzt, damit schnelles Feedback über die Qualität möglich ist? Diese und weitere Fragen werden euch bei unserem DevOps® Fundamentals Kurs beantwortet.
Hallo Frederic, das Thema ist sehr spannend. In agilen Projekten bedarf es aber noch die Erweiterung um die Fachseite. Insofern sprechen wir eher von BizDevOps und hier sehe ich vor allem hinsichtlich des fachlichen Testings die grosse Herausforderung. Wie behalten wir die Übersicht zwischen der Entwicklungarbeit und den bereitgestellten Testobjekten die fortlaufend bereit gestellt werden? Welche Tools können dabei helfen, um den Überblick im Sinne des Big Pictures nicht zu verlieren? Taskmanagement-Tools wie Jira greifen hierfür zu kurz, da sie sehr granular funktionieren und nicht den Fortschritt bzw. den Gap zwischen Entwicklung und Testing messen und darstellen.
Danke für deine Einschätzung und Rückmeldung.
Gruess, Markus Lamprecht
Hallo Markus
DevOps besteht für mich aus Cross-Funktionalen Teams, welche jeweils alle Rollen umfasst, die an der Entwicklung und Betrieb eines (Software-) Produkts beteiligt sind (somit auch das Business).
Wie man den Überblick über die fachlichen Tests und der Entwicklungsarbeit behält ist primär eine Frage der Kommunikation und der Zusammenarbeit innerhalb des Cross-funktional Team. Es muss sichergestellt werden, dass die fachlichen Tester mitbekommen, wann ein entsprechendes Features aus der Entwicklung fertiggestellt wurde und somit testbereit ist. Im Idealfall habt man aber bereits ein ATDD Ansatz, mit welchem dann automatisch sichergestellt wird, das die fachliche Sicht getestet wird.
Das Big Picture könnte man basierend auf der Release-Planung messen, welches z.B. pro Quartal durchgeführt. Dadurch wäre es möglich den Gap zwischen Entwicklung und Testing darzustellen.