Es ist mir eine grosse Freude, dass ich meinen Zühlke-Kollegen und erfahrenen Software-Architekten, Marcel Stalder, als Gast für diese Blogpost Serie gewinnen konnte.
Marcel arbeitet und lebt in der Schweiz. Seit seinen Teenagerjahren entwickelt er technische Lösungen, zuerst im Bereich Elektronik, später im Bereich Software. Nach seinem Abschluss in Informatik begann seine Karriere als begeisterter Software Engineer, Architekt und Consultant im Jahr 2001. In den vergangenen 22 Jahren hatte Marcel die Gelegenheit, sich als externer Berater und interner Experte in vielen spannenden Projekten in verschiedenen Unternehmen in den unterschiedlichsten Geschäftsbereichen zu beweisen und weiterzuentwickeln. Vor fast sechs Jahren hatte er die Gelegenheit, seine Reise gemeinsam mit Zühlke fortzusetzen, ebenfalls in mehreren Projekten und verschiedenen Rollen, derzeit als Principal Software Architekt. Marcels aktueller Schwerpunkt liegt auf Projekten in der Finanzbranche bei Banken und Versicherungen. Eines seiner Hobbys ist das Wandern: Einerseits ein grosser Kontrast zu seinem Job, aber auch mit Gemeinsamkeiten wie dem Festlegen einer Route zum Ziel und dem motivierten und ausdauernden Anpacken.
Pia:
Herzlich willkommen, Marcel! Vielen Dank, dass du dir heute Zeit nimmst mit mir über Software Qualität zu sprechen.
Wir beide kennen uns von Zühlke, bei welcher wir uns in einem sehr spannenden Projekt bei einer grossen Schweizer Bank getroffen haben. Ich durfte u.a. ein agiles Team unterstützen in welchem du kurz zuvor als Architekt tätig warst. Dort hast du Behaviour Driven Development (BDD) eingeführt.
Ich habe dich als Generalist erlebt, der stets am Fachkontext interessiert war. Ausserdem war es dir wichtig zu wissen was für das Testing relevant ist und was gute Qualität im jeweiligen Produkt bedeutet. Eine saubere technische Basis, gute Architektur und Clean Code waren obligatorische Bestandteile.
Und so kommt es, dass wir heute hier sitzen und deine Erfahrungen mit meinen Leser:innen teilen dürfen.
Was bedeutet gute Software-Qualität und Built-in Quality für dich?
Marcel:
Built-in Quality bedeutet für mich, dass die Qualitätsattribute im Fokus stehen, von Beginn weg und nicht erst in einer Testphase am Schluss. Das heisst, dass wir schon bei den Requirements starten und uns überlegen, wo die Qualitätsaspekte sind. Einerseits bei den funktionalen Anforderungen, aber auch bei den nicht-funktionalen Requirements (NFRs). Was soll das System in Spezialfällen machen? Wie schnell soll es sein? Was passiert in einem Fehlerfall etc.? Das bedeutet für mich als Solution Architekt, ich muss das Business verstehen. Ich muss die Anforderung im Detail verstehen, um fähig zu sein, eine Architektur und ein Design zu definieren und die Implementation umzusetzen.
Weiter wichtig ist, dass Qualität keine einmalige Sache ist, an die ich einen Haken setze und gut ist’s. Wir müssen fortlaufend die Qualität überprüfen. Stichwort: Regressionstests. Auch Requirements ändern sich. Das wirkt sich auf die Regressionstests aus, die idealerweise automatisch aktualisiert und ausgeführt werden. Stichwort: Living Documentation (siehe BDD, Specification by Example).
Pia:
Nach meiner bisherigen Erfahrung bist du unter den Software-Ingenieur:innen leider noch die Ausnahme was das Interesse am Business betrifft. Für dich ist klar, dass du das Fach verstehen musst. Das sehen nicht alle so. Viele fokussieren stark auf das Technische, haben gar keine Lust, sich mit dem fachlichen Kontext auseinanderzusetzen.
War das fachliche Interesse bei dir schon immer da oder hat sich das mit der Zeit entwickelt?
Marcel:
Ich hatte immer schon das Interesse am Fachlichen. Wenn ich bei Kunden oder direkt bei einer Firma angestellt bin, möchte ich das Geschäftsmodell verstehen. Ich möchte verstehen, wie die Firma tickt, wo die Herausforderungen liegen. Auch basierend auf der IT-Strategie: Wohin entwickelt sich das Unternehmen?
Weiter habe ich gesehen, dass ein zu starker Fokus auf die Technologie die Qualität reduziert. Gewisse Fragen zu Qualitätsaspekten stellst du dann nicht. Du gehst davon aus, das Business weiss es schon. Das Business sagt dir, was du tun musst. Du implementierst es und am Schluss findest du heraus, da fehlt was, da hat es Lücken. Dinge, die man sich nicht überlegt hat.
Ich habe für mich herausgefunden, dass es hilft, wenn du als Laie das Business ein bisschen forderst: «…du sprichst von diesem Begriff…was bedeutet denn das genau?». Das geht in die Richtung von Domain Driven Design und der sogenannten Ubiquitous Language (universelle Sprache). Nur schon, um das gleiche Verständnis zu haben, ist eine gemeinsame Sprache extrem wichtig.
Häufig bist du high-level unterwegs. Irgendjemand schreibt in einem Word-Dokument z.B. «ich möchte den Kunden aktivieren». Aber was bedeutet «Kunde»? Was bedeutet «aktivieren»?
Es ist nicht immer einfach für die Fachleute. Sie wissen ja (oder sie glauben zu wissen), was gemeint ist. Lustig ist dann, wenn Du herausfindest, dass auch die Fachpersonen unter sich ein unterschiedliches Verständnis haben von ihren «offensichtlich einfachen» Begriffen.
Pia:
Ja, das habe ich auch schon öfter erlebt.
Du bist jemand, der sich nicht scheut, Requirements Engineering oder Business Analyse zu betreiben. Vor allem wenn es das gemeinsame Verständnis und so die Produktqualität fördert. Du schlüpfst spontan in diese Rollen, ohne es aktiv zu betiteln. Ist das für dich Teil deines Job als Architekt?
Marcel:
Ja, für mich ist das ein Teil meines Jobs. Als Hintergrundinfo hierzu: ich hasse repetitive Arbeiten. Ich mache nicht gerne mehrfach das Gleiche und ich fasse auch nicht gerne mehrfach den gleichen Code an. Wenn du dann x Iterationen brauchst, bis du endlich am Ziel bist, stört mich das persönlich. Darum versuche ich von vorneherein ein gemeinsames Verständnis zu schaffen mit dem Ziel, möglichst schnell und einfach zur Lösung zu gelangen.
Das heisst aber nicht viel up-front Design, es soll agil und iterativ bleiben. Ich möchte nicht ein halbes Jahr Spezifikationen schreiben und dann herausfinden, dass trotzdem nicht alle Fälle abgedeckt sind. Man sollte möglichst schnell die Sachlage klären, mit der Implementation starten und dann darauf aufbauen.
Pia:
Absolut. Es ist wichtig, agil zu bleiben, um schnell auf Marktbedürfnisse reagieren zu können.
Hast du einen Tipp, wie man Software-Entwickler:innen dazu motiviert, sich mehr für den fachlichen Kontext zu interessieren?
Marcel:
Gute Frage… Ich denke, das hängt stark von der Persönlichkeit ab. Wenn jemand diese Motivation schon mitbringt, dann ist es einfacher. Wenn ich Personen begegne, die mir sagen, «Eigentlich interessiert mich diese fachliche Domäne gar nicht, ich will hier einfach coole Software schreiben.», dann ist das für mich ein Widerspruch. Aber das sind eben unterschiedliche Mindsets.
Was ich mir vorstellen könnte ist, wenn man initial die Domäne ein bisschen erklärt, das hilft zumindest mir. Also nicht, «bau jetzt da mal ein Feature ein oder mach mir ein neues Feld auf dem UI», sondern zu erklären, was wir eigentlich machen, was das grosse Ganze ist, warum wir das tun, wo die Herausforderungen sind usw. Jede Domäne hat spannende Dinge, die man lernen kann. Das hilft mir zu sagen, «Hey, das ist eigentlich eine coole Sache… Nicht alles ist spannend, aber es gibt spannende Bereiche».
Wenn man die Herausforderungen kennt, dann ist es einfacher, als wenn man gesagt bekommt, «Pass da mal diesen Code an».
Pia:
Ich hatte früher ständig das Gefühl, noch mehr technisches Know-how mitbringen zu müssen. Ich habe manchmal immer noch das Gefühl, wenn ich mit technisch sehr versierten Personen spreche, auch den Hands-on Part können zu müssen, um über gewisse Dinge sprechen zu dürfen. Das hast du gerade widerlegt.
Es hilft mir gerade sehr, darauf zu fokussieren, was der Businesskontext ist. Was ist in dieser Domäne spannend? Was passiert am Ende mit der Software, die wir entwickeln?
Marcel:
Ich denke, es hilft schon, die andere Seite zu kennen, und du kennst die andere Seite sehr gut. Daher finde ich interdisziplinäre Teams sehr spannend und passend. Der gegenseitige, interdisziplinäre Austausch ist sehr bereichernd.
Es ist vielleicht initial etwas mehr Aufwand, zu verstehen, wie die jeweiligen Disziplinen funktionieren. Was ist die Domäne, wie funktioniert die Technik, wie testen wir, was sind die qualitativen Attribute? Sobald man sich aber im Team gefunden hat, kommt man viel schneller und mit weniger Erklärungen und Worten vorwärts. Man weiss schon genau, was das Gegenüber braucht und worauf er oder sie Wert legt.
Pia:
Welche Erfahrungen hast du während deiner Laufbahn mit Test- oder QA-Spezialist:innen gemacht? Wie sollte die Zusammenarbeit mit Personen in Test- oder QA-Rollen aussehen?
Marcel:
Das alte Vorgehen, nennen wir es mal Wasserfall, bei demjemand die Requirements schreibt, jemand anderes implementiert diese, wieder jemand anderes testet das Produkt und ganz jemand anderes betreibt es, das gefällt mir gar nicht. Es ist sehr unflexibel und man spricht wenig miteinander. Es gibt Quality Gates und jede/r schaut nur, dass die eigene Phase erledigt wird.
Als ich in meinem ersten Scrum-Team war, interdisziplinär und auch mit einer Testerin, dann war das eine ganz neue Erfahrung. Du hast am Daily schon jemanden, die kritische Fragen stellt. Das hilft der Entwicklung. Sie kriegen fortlaufend mit, wie jemand denkt, der den Fokus auf die Qualität legt. Darum würde ich sagen, auch in einem interdisziplinären Team soll eine Person den Fokus auf Qualität haben. Das kann ein/e QA-Spezialist:in sein, das kann aber auch ein Architekt oder eine Entwicklerin sein. Wichtig ist, dass er oder sie das dann auch wirklich tut.
Und wie wir beide wissen, gibt es im Enterprise-Umfeld typischerweise dann trotzdem noch ein Team nachgelagert, welches Systemintegrationstests mit Tools wie Tosca macht. Das finde ich zu einem gewissen Grad wertvoll, denn das bringt nochmal eine andere Dimension rein. Du kannst dich auf ein System oder auf eine Applikation fokussieren und es gibt noch jemanden, der übergreifend testet. Ich würde es aber auch begrüssen, wenn man diese Tests integrieren könnte. Dadurch könnte ich bei einer Anpassung den Prozess direkt durchgehend testen.
Pia:
Das ist auch mein grosser Traum. Drücken wir die Daumen, dass er bald wahr wird!
Personen die länger im Testing tätig sind, haben oft Mühe bei dem Wechsel in ein agiles Team. Früher war ihre Rolle klar. Sie sind am Ende dran und sind diejenigen, die sagen müssen, ob die Software gut genug ist für den Release. Es lastete sehr viel Verantwortung auf den Schultern dieser Leute.
Heute ist es ja so, dass wir zwar eine Person mit dem Qualitäts-Fokus im Team haben möchten. Das bedeutet aber nicht, dass diese Person alles alleine testen muss. Es ist vielmehr so, dass die Arbeit aufgeteilt wird und die QA-Rolle darauf achtet, dass Qualität eingebaut und das Testing erledigt wird.
Was könnte Tester:innen dabei unterstützen, ihre Rolle in einem agilen Team zu finden? Wie kann man ihnen etwaige Ängste nehmen?
Marcel:
Für mich sind es zwei Dinge. Das eine ist, du bist als Tester:in nicht mehr am Schluss vom Prozess, sondern startest früher mit deiner Arbeit. Das andere sind die kürzeren Release-Zyklen.
Für den ersten Teil würde ich versuchen der Person die Angst zu nehmen und erklären: «Du machst eigentlich noch das Gleiche wie vorher: du überlegst dir, wie kann man die Qualität sicherstellen, wie kann ich etwas testen, welche Testfälle gibt es, usw. Du hast aber zusätzliche Möglichkeiten, das umzusetzen. Du bist in einem Team und kannst z.B. einem Entwickler etwas zum Automatisieren geben. Du hast eine bessere Übersicht, was getestet wird, wie und wo etwas getestet wird. Du bist nicht mehr alleine verantwortlich, sondern du hast ein Team».
Es gibt also spannende Möglichkeiten für Tester:innen in einem agilen Setup. Vor allem, dass sie viel früher involviert und näher am Geschehen sind, sind für mich sehr positive Effekte.
Das Zweite sind die kürzeren Release-Zyklen. Da hast du keine Chance, wenn Du manuell testen willst. Was du früher in einem Monat getestet hast, musst du heute in einer Woche schaffen. Das geht nicht. Und einfach mehr auf Applikationsebene automatisieren ist sehr limitiert. Nur schon, um das zu erreichen, muss sich der Prozess ändern. Auch die Person und der Arbeitsinhalt wird sich ändern.
Pia:
Ich beobachte, dass viele Tester:innen das Gefühl haben, sie müssen automatisieren lernen. Sie müssen das jetzt können, weil sie sonst keinen Job mehr haben.
Ich bin der Meinung, dass wenn jemand automatisieren kann, ist es nice-to-have, aber es ist kein obligatorisches Skill für Tester:innen. Heute ist man in einem interdisziplinären Team. Der Fokus liegt für Tester:innen darauf Testexpertise ins Team zu bringen. Wie können wir möglichst schlau auf welchen Stufen testen? Die Automatisierung von Testskripten kann ich an Teamkolleg:innen übergeben.
Marcel:
Ja, das sehe ich auch so. Und es gibt Zwischenwege wie BDD, wo die Testautomatisierung direkt aus den Requirements möglich wird. So können ganze UIs automatisiert getestet werden. Die Testfälle können ohne weiteres von Personen geschrieben werden, die die Technologie dahinter nicht kennen.
Pia:
Genau. Lass uns doch hier gerade in unser ehemaliges Projekt eintauchen.
Du hast dort in einem agilen Team, in welchem ich später als Testerin eingesetzt war, Behaviour Driven Development eingeführt. Das hat uns sehr geholfen unsere Testabdeckung im speziellen auf den unteren Teststufen zu verbessern
Wie bist du das angegangen? Wie hast du das Team für BDD begeistert? Wie hast du den Product Owner ins Boot geholt?
Marcel:
Das war ein iteratives Vorgehen. Ich habe mit einem Proof of Concept gestartet, um dem PO und dem ganzen Team zu zeigen, wie ein solches Feature File aussehen kann und wie ein Test implementiert werden kann. Ich habe ein paar sprechende Slides zusammengestellt und ihnen das Thema vorgestellt. Es ist wirklich keine Rocket Science. Ich habe gezeigt, wie das Tooling aussieht und dass man einfach zwischen Steps und Bindings springen kann. Das Feature File ist aber für alle Disziplinen leicht lesbar. Technisch ist es einfach auszuführen und lief in unserem Beispiel bereits im regulären Unittest-Set mit. Und dann haben wir mit den ersten Anforderungen gestartet. Wir haben ganz bewusst nicht den PO die ganze Definition machen lassen, sondern haben ihn von Anfang an unterstützt. Unsere Entwickler haben eine Anforderungen aufgenommen, das entsprechende Feature File erstellt und dem PO zurückgespielt. «Ich habe es so verstanden. Ist es das, was du möchtest?» So haben wir iterativ BDD in unserem Team etabliert. Von der Domäne her hat es ebenfalls gut gepasst.
Es war eine Rule Engine mit vielen Regeln, Spezialfällen und Ausnahmen. Das musste irgendwo festgehalten werden. Wir wollten das unseren PO nicht in einem Word-File aufschreiben lassen, sondern wollten die Anforderungen gleich direkt für unsere Tests verwenden können.
Pia:
Stimmt und ganz wichtig, die Domäne muss auf jeden Fall passen.
Wenn ich diese Geschichte erzähle, dann schauen viele ungläubig, denn sie denken bei BDD und der Gherkin Syntax geht es um Szenarien, die sich zwingend auf der grafischen Benutzeroberfläche abspielen müssen. Dem ist aber nicht so. Man beschreibt damit das Verhalten, das Behaviour, von einem System. Diese Beschreibung kann man durchaus, sofern es Sinn macht, bereits für den Unittest nutzen.
Das war für mich und das gesamte Team extrem hilfreich. Ich konnte bereits auf den unteren Teststufen mit meiner Expertise unterstützen. Es ist einfach lesbar und leicht verständlich. Und ich fand es noch cool in den Code rein zu sehen. Das hat mir geholfen, unsere Applikation technisch besser zu verstehen.
Marcel:
Das sagst du richtig. Typischerweise wird BDD mit Selenium in Kontakt gebracht, wo die Applikation auf dem UI durchgeklickt wird.
Hier musst du abstrahieren können. Du musst definieren, welche Funktionalität wo getestet wird. Ein Unittest ist einfach und läuft schnell. Der Entwickler ändert etwas und hat ein paar Sekunden später das Testresultat. Das hilft ungemein.
Jegliche Business Logik über das UI testen zu wollen ist nicht nur veraltet, sondern in der Regel gar nicht möglich. Ich sage deshalb, mach es modular, brich es auf und definiere, welche Funktionalität du wie auf welcher Stufe testen möchtest.
Pia:
Eine Frage, die sicher vielen unter den Nägeln brennt: Was machen wir, wenn wir viele Abhängigkeiten zu Umsystemen haben? Was können wir früher testen und was müssen wir dennoch in der realen Systemintegration testen?
Marcel:
Das ist so eine Sache mit der UAT (UAT= User Acceptance Test/User Acceptance Test-Umgebung, hier: letzte Testumgebung vor der Produktivumgebung). Häufig heisst es, auf den unteren Stufen ist die Datenqualität schlecht. Dieses Problem muss man natürlich angehen und aussagekräftige Daten auf allen Teststufen bzw. -umgebungen bereitstellen, synthetisch oder anonymisiert. Ich würde immer probieren möglichst viel, möglichst früh zu testen.
Business Logik kannst du früh testen. Interfaces auch. Wenn das nicht möglich ist, dann simulierst du die Interfaces eben. Und dann auf einer Integrationsumgebung noch die finalen Tests gegen die echten Interfaces, idealerweise automatisiert.
UAT könnte dann die Kür sein, wo jemand vom Business durchklickt und sagt «jawohl, passt». Diese Person muss nicht mehr im Detail testen. Du hast die Requirements ja bereits abgetestet.
Pia:
Was hältst du von dem Ansatz, möglichst schnell live zu gehen und in der produktiven Umgebung zu testen?
Marcel:
Gute Frage. Das passt zu dem, was ich vorhin noch erwähnen wollte: Warum sind Tester:innen wie sie sind? Ich denke, das liegt auch an einer suboptimalen Fehlerkultur in der Unternehmung. Oft wird bei einem Fehler in der Produktion nach Schuldigen gesucht. Wer hat da nicht getestet? Wer hat das verursacht? Das ist natürlich nicht hilfreich und kann dazu führen, dass die Produktivsetzung so lange wie möglich hinausgeschoben wird. Ich glaube, die Lösung wäre eine veränderte Fehlerkultur. Ausserdem sollte man häufiger deployen und releasen. Fix-Forward, wenn ein Fehler nicht früher gefunden wurde. Schnell beheben, re-testen, produktiv setzen und das Problem hat sich erledigt.
Natürlich gibt es Ausnahmen. Wenn dein Unternehmen in der Presse erscheint, weil dein E-Banking nicht funktioniert hat oder falsche Kontostände angezeigt wurden, ist es natürlich schlecht.
Was du hier tun kannst ist, verschiedene Quadranten zu definieren oder Kritikalitäten von Businessfunktionalitäten. Bestimmte Dinge müssen eingehend geprüft werden, das braucht Zeit. Andere Bereiche der Applikation sind weniger kritisch. Wenn da mal ein Fehler drin ist, macht es nichts. Die Alternative wäre, Regressionstests über alles. Alles muss getestet werden, alles muss stimmen. Nein, muss es nicht! Es gibt kritische Bereiche und es gibt weniger kritische Bereiche.
Pia:
Risikobasiertes Testen begleitet mich seit Tag 1 meiner Testing-Karriere. Es ist extrem wichtig, um die gegebenen Ressourcen bestmöglich einsetzen zu können.
Du hast erwähnt, man sollte öfter deployen. Deploy ist ja nicht gleich Release. Was ist deine Erfahrung mit Feature Toggles?
Ich habe leider mehrfach erlebt, dass diese zahlreich eingebaut, aber nie mehr abgeräumt wurden.
Marcel:
Feature Toggles sind hilfreich, aber ja, man muss sie wieder entfernen. Feature Toggles helfen dir, Release und Deployment zu trennen. Für viele ist das leider das Gleiche.
Bei langen Release-Zyklen, wenn nur alle paar Monate deployed wird, ist es auch mit Feature Toggles schwierig. Feature Toggles helfen aber definitiv bei kurzen Release-Zyklen, um z.B. auf verschiedenen Environments Funktionalitäten ein- bzw. auszuschalten und früh zu testen.
Was ich in der Vergangenheit auch häufig gesehen habe ist, dass man vergisst, das Feature Toggle anzupassen. Man hat es auf den unteren Stufen aktiviert und alles läuft perfekt. Dann geht es auf UAT und in die Produktion, und es kommt die grosse Frage: «Warum funktioniert dieses Feature nicht?... Hat jemand das Toggle eingeschaltet?»
Die Schwierigkeit ist, die Übersicht zu behalten. Was ist auf welcher Umgebung deployed und in welchem Zustand? Was ist aktiv, was ist inaktiv? Weiter sollte bereits bei der Erstellung eines Feature Toggles eine Story für die Entfernung des Toggles erstellt werden. Ein guter Zeitpunkt für die Entfernung ist der jeweils nächste Release, wenn ein Feature einen Release-Zyklus lang erfolgreich funktioniert hat.
Pia:
Genau, sonst kann es schnell sehr verwirrend werden.
Ein Beweggrund für Feature Toggles ist sicher auch, den Unterschied zwischen Code- bzw. Releaseständen klein zu halten. Früher ist man da monatelang auseinander gelaufen und am Ende hat es geknallt.
Marcel:
Das ist auch ein wichtiger Punkt. Wenn du mit Feature-Branches arbeitest, kannst du in der Regel nicht losgelöst testen, sondern musst es irgendwo deployen. Du hast aber nicht für jedes Feature eine eigene Testumgebung. Irgendwann musst du dich entscheiden, merge ich dieses Feature jetzt in den Release oder nicht. Wenn es einmal gemerged ist und dann nicht in den Release soll, wird es schwierig. Du musst es aufwändig zurückbauen. In solchen Fällen hilft ein Feature Toggle, das du nötigenfalls einfach deaktivieren kannst. Das gibt zusätzliche Sicherheit und mehr Flexibilität.
Pia:
Aus deiner mehr als 20-jährigen Erfahrung, was sind die wichtigsten Erfolgsfaktoren für gute Softwarequalität und vor allem dafür, dass Qualität von Anfang an eingebaut wird?
Marcel:
Anforderungen kritisch hinterfragen und auch über Spezialfälle nachdenken. Nicht nur den Happy Case abdecken.
Denken wie ein/e Tester:in. Entwickler:innen lieben es, Code zu schreiben, aber sie sollten auch verstärkt daran denken, wie sie ein Feature testen können. Aussagen wie „das ist nicht testbar“ oder „der Aufwand wäre zu hoch“ gehen nicht!
Ein System oder eine Applikation sollte testbar designed werden. Das startet mit der Architektur und endet mit der Implementation von Funktionalität. Du musst überlegen, wie die Implementationen strukturiert werden (separation of concerns), sodass sie einfach und schnell testbar sind. Stichwort: Onion, Hexagonal und Clean Architecture.
Automatisierung. Tests sollen bei Änderungen und Erweiterungen für neue sowie für existierende Funktionalität schnell Feedback liefern.
Behaviour Driven Development mit Fokus auf Living Documentation prüfen. Requirements so definieren, dass sie maschinenlesbar sind und für die Testautomatisierung verwendet werden können. So hat man immer eine aktualisierte System-Dokumentation.
Pia:
Vielen Dank, Marcel!
Gibt es noch etwas, das du unseren Leser:innen ausserdem mitgeben möchtest.
Marcel:
Testautomatisierung wird häufig vernachlässigt, weil man meint, es sei zeitaufwändig, kompliziert und darum teuer. Ich aber glaube, das Teure kommt erst, wenn man nicht automatisiert: Fehler, die spät gefunden werden, Daten, die korrigiert werden müssen, etc.
Deshalb: legt bereits bei Projektstart Wert auf Testautomatisierung sowie auf eine hohe Testabdeckung. Das macht euch das Leben später viel einfacher.
Comments