Testautomation und DevOps – Die Testpyramide von Zürich


SwissQ,

Sorry, this entry is only available in German. For the sake of viewer convenience, the content is shown below in the alternative language. You may click the link to switch the active language.

«Guten Morgen Peter!», ich setze mein strahlendes Lächeln auf. «Soll ich Dir einen Kaffee holen? Du könntest ja schon mal in den Testreport vom nächtlichen Deployment schauen. Die Testautomation ist fehlgeschlagen. Ist sicher nur eine Kleinigkeit.» «Schon wieder?» Während er seufzend die Jacke auszieht, verdrücke ich mich in die Küche.

Software Tester mit Lupe auf der Fehlersuche

Software Tester mit Lupe auf der Fehlersuche

Im Jahr 2005 habe ich manchen Morgen im Büro damit verbracht, Kaffee und Marzipan zu verteilen, damit die armen Frühaufsteher unter den Entwicklern die Check-In-Patzer der Nachteulen vom Vortag beheben. Continuous Integration (CI) & Continuous Deployment (CD) war noch neu für uns alle und häufig hat am Abend ein Entwickler vor dem nach Hause gehen «noch schnell einen Change eingecheckt». Der nächtliche Build ist nur selten ohne Fehler durchgelaufen und am Morgen musste jemand aufräumen.

An dem Prinzip des CI & CD hat sich bis heute nicht viel geändert, aber am Tempo schon. Haben wir vor zehn Jahren noch eine ganze Nacht für die Laufzeit der Testautomation gebraucht, sind es jetzt häufig nur noch Minuten. Auch Qualität und Anzahl der Testfälle sind rasant gestiegen. Vor allem aber hat ein Umdenken in den Köpfen stattgefunden. Unternehmen die DevOps konsequent einsetzen haben ein «das ist unser Produkt» Mindset. Jeder fühlt sich verantwortlich und ist bemüht den Ball am Laufen zu halten. Marzipan verteile ich immer noch, aber zum 15-Uhr-Kaffee und nicht mehr als «Belohnung».

Testautomation bei 10 Deployments pro Tag

«Another deployment?» Der Manager-Typ neben mir in der Tram schreit in sein Telefon. «What does QA say?» Ich verkneife mir ein Schmunzeln, als wir rumpelnd vom Paradeplatz abfahren. Ich höre nur eine Seite des Gesprächs, aber ich kann mir den Rest denken. Es ist immer die gleiche Geschichte: Jeder schiebt die Verantwortung auf eine andere Abteilung – auch aus Unsicherheit bezüglich Fehlern, die sich womöglich eingeschlichen haben.

In der Praxis heisst Continuous Deployment meist, dass mehrfach an einem Tag deployed wird. Nicht «ständig», aber innerhalb von Minuten. Insbesondere Hot-Fixes können direkt nach dem Beheben in die Produktion gehen. Das setzt aber voraus, dass ein hoher Grad an Vertrauen in die Software gegeben ist. Wenn die Entwickler nach jedem Check-In bereits die Unit-Tests laufen lassen, dann müssen auf der Testumgebung «nur noch» die systemübergreifenden API-Tests und notwendigen GUI-Tests durchgeführt werden (siehe unten).

Ohne Testautomation ist DevOps nicht denkbar. Häufige Deployments erzwingen auch ein entsprechend häufiges Testen. Dadurch entstehen aber eine Reihe von Problemen – überwiegend menschlicher Natur. Hier eine Auswahl:

  • Wer ist verantwortlich einen fehlgeschlagenen Testfall zu analysieren?
  • Wer behebt einen Fehler in «altem» Code?
  • Wie können tausende Testfälle in wenigen Minuten durchgeführt werden?
  • Wie können die Testdaten jederzeit in einem konsistenten Zustand gehalten werden? Dazu noch über mehrere Umgebungen?
  • Wie kann sichergestellt werden, dass Codeänderungen immer mit einem automatischen Test abgesichert werden? Wer ist verantwortlich, wer führt aus?
  • Wie werden Schnittstellen gehandhabt? (interne und externe)

Die meisten der hier genannten Probleme sind obsolet, sobald ein Grossteil des Codes mit Testfällen abgesichert ist – und diese innerhalb von Minuten durchlaufen.

Fehlerwirkung und Fehlerursache liegen dann unmittelbar beieinander.

Die Verantwortung für die Durchführung liegt im Team, nicht mehr «bei QA» oder «beim Betrieb». Beheben muss einen Fehler aber der, der es kann. Unmittelbar. Aber aufgrund des häufigen Check-Ins und den kleineren durchgeführten Änderungen am Code wird die Fehlerursache i.d.R. schnell gefunden und behoben. Dadurch steigt die Qualität des Produkts.

Die Testpyramide – Testautomation Best Practice

Tests werden typischerweise auf drei Ebenen automatisiert: Als Unit-Test direkt im Code, als API-Test auf den Schnittstellen zum System und als Automatisierung der GUI. Das ist ein Best-Practice, der sich über die letzten 20 Jahre etabliert hat. DevOps ändern daran nichts. Die Details zur Testpyramide können Sie dem PDF entnehmen:

Fazit und weitere Informationen

DevOps ist kein Buzzword mehr, sondern mehr und mehr Alltag in der IT. Die Testautomatisierung stellt dabei die Qualitätskontrolle sicher.

Entscheidend ist es nicht, möglichst viel, sondern das richtige zu testen!

Mit der Testpyramide hat man eine gute Basis für die Aufteilung der Testfälle. Das Thema Digitales Testen behandeln wir hier im Blog ausführlich. Lohnt sich Testautomation überhaupt? Unser interaktiver Rechner zeigt es Ihnen. Auch Mobile Testing ist ein wichtiger Bestandteil der Teststrategie.

Haben Sie noch Fragen? Wir beraten Sie gerne: Kontakt.

0 thoughts on “Testautomation und DevOps – Die Testpyramide von Zürich”


Leave a Reply