Freitag, 13. Januar 2023
Zero Bug-Policy (II)
 |
| Bild: Pexels / Picas Joe - Lizenz |
Zu den am häufigsten missverstandenen (und aus diesem Grund immer wieder kontrovers diskutierten) Begriffen der Software-Entwicklung gehört die Zero Bug Policy, sinngemäss übersetzt die Regel keine Fehler in der Software mehr zu haben. Da die sich daraus ergebenden Debatten intensiv und zeitfressend sein können lohnt es sich, einen näheren Blick darauf zu werfen - um was geht es hier eigentlich und wo findet das Missverständnis statt?
Um mit dem Letzten zu beginnen: das Missverständnis besteht darin, dass oft angenommen wird, eine Zero Bug-Policy hätte zum Inhalt, dass keine Bugs mehr entstehen dürften. Dass das zwar wünschenswert aber nicht umsetzbar ist dürfte jedem klar sein, der sich schon einmal mit Softwareentwicklung beschäftigt hat. Die Komplexität und Vernetztheit von Anforderungen und Systemen ist zu gross um Fehler auszuschliessen, auch bei grösster Mühe.
Was tatsächlich hinter dem Begriff steckt ist die Regel, entdeckte Bugs schnellstmöglich zu beheben und das nicht auf einen späteren Zeitpunkt zu verschieben. Man kann sich Zero Bugs in diesem Kontext als die Kurzform von "Zero Bugs left behind" vorstellen, das macht den Begriff plastischer. Und schnellstmöglich bedeutet (vereinfacht gesagt), dass man zwar natürlich erst die laufenden Arbeitspakete abschliessen kann, aber keine neuen bearbeitet so lange noch Bugs gefixt werden können.
Mit dieser Erklärung erscheint die Reglung zwar nicht mehr undurchführbar, kontrovers bleibt sie aber. Ein häufiger Einwand ist z.B., dass es nicht vermittelbar ist, neue Features (mit denen Geld verdient und Kunden gewonnen werden können) aufzuschieben, nur um kleinere Bugs zu beheben, von denen nur wenige Anwender betroffen sind, die nur selten auftreten oder für die es einen Workaround gibt. Und isoliert betrachtet stimmt das sogar.
In der Realität treten derartige Bugs allerdings meistens nicht mit einer derartigen, von Beginn an klar erkennbaren nachrangigen Wichtigkeit auf. Zu Beginn ist fast immer eine Analyse nötig, die dann auch bereits den Grossteil des nötigen Aufwandes ausmacht. Die eigentliche Behebung kann im Anschluss daran eher schnell stattfinden, was ausserdem den Nebeneffekt mit sich bringt, dass die Analyse nicht mehr dokumentiert werden muss um zum Behebungszeitpunkt präsent zu sein.
Selbst im Fall einer von Beginn an klar erkennbar nachrangigen Wichtigkeit gibt es aber ein Argument gegen das Aufschieben. Bereits nach erstaunlich kurzer Zeit führt dieses Vorgehen nämlich zum Entstehen von Bug-Backlogs, die die Tendenz haben aus sich heraus ständig Bürokratie zu erzeugen: sind diese Tickes noch relevant? Sind sie noch aktuell? Sind sie richtig priorisiert? Sind sie bereits redundant? Alleine das zu überprüfen und zu dokumentieren kann einen irrsinnigen Verwaltungsaufwand bedeuten.
Die wirtschaftlichste Art damit umzugehen ist tatsächlich die No Bug Policy. Alle auftretenden Fehler müssen behoben werden, und zwar so bald wie möglich. Im Einzelfall könnte man zwar fast immer argumentieren, dass gerade dieses spezielle Ticket in Relation zu anderen unwichtig ist, im Durchschnitt spart die sofortige Behebung aber Zeit, Aufwand und Nerven. Und jedem der das nicht sofort einsehen will kann man gerne die Verantwortung für Analyse, Dokumentation, Aktualisierung, Priorisierung und Triage von Bugs übertragen.1 Schnelle Lerneffekte sind dann garantiert.
Donnerstag, 9. September 2021
Bugs priorisieren
 |
| Bild: Pixabay / Jill Wellington - Lizenz |
Meine Tätigkeit als Test-Manager ist mittlerweile schon einige Jahre her, in vieler Hinsicht profitiere ich aber bis heute davon. Speziell die Frage wie in einem agilen Entwicklungsumfeld Qualitätssicherung betrieben wird ist spannend und herausfordernd, von der Zero Bug-Policy bis zum "agilen Testkonzept" gibt es vieles was anders ist als im klassischen Vorgehen. Ein weiterer derartiger Fall, der um den es hier gehen soll, ist die Priorisierung von Bug-Tickets.
Beginnen wir mit der Ausgangslage: klassisch werden Bugs in Kritikalitätsklassen eingeteilt, z.B. gering, mittel, schwerwiegend und systemkritisch.1 Worauf diese Einteilung zurückgeht ist von Unternehmen zu Unternehmen unterschiedlich (und nicht immer klar definiert) sie beruht aber in der Regel darauf wie viele Funktionalitäten betroffen sind, wie wichtig diese für das Funktionieren des Gesamtsystems sind und ob es einen Workaround gibt. Diese Kritikalität beeinflusst dann auch das weitere Vorgehen.
In der Theorie ist es so, dass systemkritische Bugs sofort repariert werden, schwerwiegende zeitnah, mittelschwere mittelfristig (z.B. in Stabilisierungsphasen) und gering wichtige irgendwann - oder nie.2 Die Idee dahinter ist meistens, dass es oberste Priorität ist neue Features zu bauen um die gesetzten (und mit Belohnung versehenen) Ziele zu erreichen. Die Qualitätssicherung erfolgt dann später im Projekt, ggf. sogar nach Go Live (mehr dazu hier) gering wichtige Bug-Tickets bleiben z.T. für immer ungefixt.
In der Realität funktioniert dieses Vorgehen auch im klassischen Kontext eher selten. Bei vielen Bugs fällt erst während der Behebung auf wie schwerwiegend sie sind, andere gelten wegen vorhandener Workarounds als weniger schwerwiegend, allerdings blockiert deren Nutzung die Weiterentwicklung der so genutzten Komponenten. Nochmal andere sind wirklich eher klein, sie beeinträchtigen die Benutzungserfahrung aber so sehr, dass die Nutzer unzufrieden werden. etc.
In einem agilen Entwicklungskontext wird ein solches Vorgehen dann völlig unmöglich, schliesslich soll die Anwendung (inclusive ihrer neuesten Features) durchgehend "potentially shippable" sein, also ständig im notwendigen Zustand um sofort released werden zu können. Das erfordert das zeitnahe Erledigen aller Bugtickets, wodurch der ursprüngliche Grund der klassischen Priorisierung (die Entscheidung welche Reparaturen auf später verschoben werden können) weitgehend obsolet wird.
Soviel zur Analyse, aber wenn die klassische Bug-Priorisierung im agilen Umfeld problematisch ist, wie geht es besser? Ein einfacher Ansatz mit dem ich gute Erfahrungen gemacht habe ist der: Bugs der Prioritätsklasse I werden sofort erledigt, ggf. sogar um den Preis des Sprint-Abbruchs. Bugs der Prioritätsklasse II kommen in den nächsten Sprint (und zwar alle, selbst wenn dann kein Platz mehr für Features bleibt), Bugs der Prioritätsklasse III werden nicht repariert und geschlossen.
Was steckt dahinter? Klasse I ist Produktionsausfall, Datenleck oder Vergleichbares, also etwas das alles andere schlägt. Klasse II ist Teil eins der Zero Bug-Policy, also die Reparatur aller reparaturwürdigen Fehler zum nächstmöglichen Zeitpunkt (der keinen Sprint sprengt), Klasse III ist Teil zwei der Zero Bug-Policy, in dessen Rahmen alle noch verbleibenden Bugs als so irrelevant eingruppiert werden, dass ihre Behebung den Aufwand nicht wert wäre.3
Vor allem zwei Vorteile enstehen durch diese neue Art der Priorisierung: zum einen wird die (oft widersprüchliche) Parallelität von Wichtig und Dringend aufgehoben, zum anderen wird das Backlog ausgemistet, das vorher durch Tickets verstopft wurde von denen jeder wusste, dass sie nie in die Umsetzung gehen würden. In Summe gehen Diskussions- und Pflegeaufwand zurück und es bleibt mehr Zeit für wirklich wichtige Themen.
An dieser Stelle gibt es übrigens auch einen weiteren Brückenschlag zur Agilität. Teams und Organisationen die weniger Zeit für ihre Bug-Verwaltung aufwenden müssen haben mehr Zeit für andere Themen und werden mit denen schneller fertig. Ein Zustand ein eigentlich jeder anstreben sollte, auch ohne einen Testmanagement-Hintergrund.
2Ja, tatsächlich. In vielen grossen Organisationen ist es Standard, dass kleine Bugs nie gefixt werden
3Z.B. ein Rechtschreibfehler in einem Tooltip eines internen Workflows oder ein falsches Farbschema in einem Bereich den nur der Admin sieht
Mittwoch, 28. Oktober 2020
Die Testautomatisierungs-Falle (und wie man ihr entkommt)
 |
| Bild: Flickr / Karen Rustad Tölva - CC BY 2.0 |
In den Diskussionen um Psychologische Sicherheit, Kultur, "Agile Mindset" und Change Management geht es manchmal unter, aber zumindest im IT-Kontext hat Agilität auch immer eine sehr technische Seite, ohne die schnelle Reaktions- und Lieferfähigkeit weder denkbar noch umsetzbar ist. Einer der wichtigsten Aspekte ist dabei die Automatisierung der Software-Tests, also der Qualitätssicherung der neu erstellten Funktionalitäten. Und wie so oft gilt auch hier - es reicht nicht es zu machen, man muss es auch richtig machen.
Zur Erinnerung: während die Abnahme-Tests im Sprint noch irgendwie mit manueller Arbeit zu stemmen sein können ist das bei den Regressionstests nicht mehr der Fall. Unter denen versteht man das regelmässige Überprüfen aller (!) älteren Funktionen, womit sichergestellt wird, dass diese nicht versehentlich durch neuere Entwicklungen beschädigt wurden. Bei grösseren IT-Systemen kann das eine fünfstellige Anzahl an Tests erfordern, was bei manuellem Durchklicken Wochen und Monate dauern kann.
Die einzige Lösung wenn man schnell sein will ist das Automatisieren möglichst aller Regressionstests. Erst wenn diese von einem Computerprogramm ausführbar sind können die erforderlichen Mengen und Geschwindigkeiten erreicht werden die nötig sind um Fehler schnell entdecken und beheben zu können. Ohne Testautomatisierung kommen bei grösseren Systemen die Jahres- und Quartals-Releases zurück. Aber (Ironie der Geschichte): auch eine falsch durchgeführte Testautomatisierung kann den selben Effekt haben.
Um aussagekräftig zu sein müssen die automatisierten Testsuiten immer dem aktuellen Stand der jeweiligen Anwendungsentwicklung entsprechen, sonst geben sie Fehlermeldungen aus sobald ein Feature verändert wurde, die Aktualisierung der Tests aber noch nicht stattgefunden hat. Das Risiko ist schnell erkennbar: wenn bei grösseren Änderungen hunderte von Tests aktualisiert werden müssen kann das einen Pflegeaufwand bedeuten, der wieder Wochen und Monate dauert - damit ist man wieder bei den Zeiträumen die man vorher hatte.
Um diesem Phänomen (der so genannten "Testautomatisierungs-Falle") zu entgehen müssen Erstellung und Struktur der automatisierten Tests an die agilen Entwicklungsprozesse angepasst werden. Wie das im Einzelfall aussieht kann von Fall zu Fall anders aussehen, folgende Grundsätze sind aber sehr häufig: Zusammenlegung von Test- und Entwicklungsteam, Modularisierung und Parametrisierung.
Die Zusammenlegung von Test- und Entwicklungsteam ist die einfachste, weil eher organisatorische Massnahme. Statt zwischen Entwicklung und Test einen kleinen Wasserfall aufzubauen werden die Tests jetzt gleich vom Entwicklungsteam erstellt, wodurch sie schneller fertig und aktueller sind. Ein unterschätzer Nebeneffekt kommt dazu: die "Tester" können in diesem Vorgehen selbst programmieren, was die Voraussetzung für Automatisierung ist.
Die Modularisierung sorgt dafür, dass der Instandhaltungsaufwand sinkt. Wenn z.B. nicht mehr in jedem von 100 Tests die Login-Schritte separat ausgeführt werden, sondern diese Schritte nur noch aus einem einzigen zentral gepflegten Modul abgerufen werden, muss ein geänderter Login-Vorgang nur noch einmal geändert werden statt 100 mal. Der Instandhaltungsaufwand sinkt damit auf 1% seines Umfangs (!).
Ähnliche Auswirkungen hat eine Parametrisierung. Bei ihr werden veränderbare Variablen (Testumgebungen, Browser, Testdaten, etc.) nicht mehr hart in den Test gecodet sondern ebenfalls zentral gepflegt. Bei der Test-Suite einer Web-Anwendung reicht es dann eine einzige zentrale Einstellung zu ändern und hunderte Tests laufen auf Firefox statt auf Chrome. Auch hier sinkt der Instandhaltungsaufwand immens.
Es ist offensichtlich, dass (und warum) die Testautomatisierungs-Falle und die dazugehörenden Gegenmassnahmen von zentraler Bedeutung für agile Software-Entwicklung sind. Und ganz nebenbei ergibt sich aus ihnen übrigens auch ein brauchbarer Lackmustest für Agile Coaches und Scrum Master. Die müssen nicht selbst Tests automatisieren können, sie sollten die Testautomatisierungs-Falle aber beschreiben können. Wenn das nicht geht sind sie (noch) zu technikfern.
Dienstag, 25. September 2018
Warum Agile/Scrum ohne Testautomatisierung nicht funktioniert (III)
 |
| Bild: NASA - Public Domain |
Es handelte sich um ein System mit mehreren über die Jahrzehnte zugekauften und integrierten Teilsystemen, die durch zahlreiche Schnittstellen verbunden waren. Insgesamt 75.000 Testfälle (!) mussten jedes mal durchgeklickt werden um sicherzustellen, dass neuentwickelte Features nicht versehentlich bestehende Anwendungsteile beschädigt hatten. Eine ungeheuerliche Zahl, deren Bewältigung nur möglich war weil Offshore-Testing in irgendeinem asiatischen Land mit niedrigen Löhnen betrieben wurde.
Die Durchführung eines solchen Regressionstestzyklus dauerte etwa ein Jahr, bei den letzten Malen waren dabei jeweils knapp 7000 kritische Bugs (→ funktionale Fehler ohne möglichen Workaround) entdeckt worden. Da nach dem Beheben dieser Bugs ein weiterer Regressionstestzyklus zu lange gedauert hätte wurden die Bugfixes gleichzeitig mit neuen Features eingecheckt, was natürlich Merge-Konflikte verursachte. Die Folge war das erneute Auftreten tausender Fehler, womit der Kreislauf von neuem begann.
Warum in diesem Fall nicht einmal im Entferntesten an agile Softwareentwicklung zu denken war ist offensichtlich: ein einziges, dazu noch Bug-verseuchtes, Grossrelease pro Jahr? Das ist weit, weit, weg von der Auslieferung nutzbarer Inkremente mehrfach pro Monat. Um weitgehend fehlerfreie Anwendungen auszuliefern hätte man sogar mindestens einen Regressionstestzyklus einer Bugfix-Welle abwarten müssen, in Summe hätte es dann zwei Jahre gedauert.
Wie man denn aus dieser Situation hauskommen könnte, war die Frage. Ein nachträgliches Automatisieren der Testfälle wäre wegen fehlendem Budget nicht möglich, ob es denn andere Wege gäbe agil zu arbeiten? Als das verneint wurde war relativ schnell klar, "dass Agil wohl nicht das Richtige für uns ist." Quod erat demonstrandum. Zwei Jahre später kam es zu einem zufälligen Treffen mit einem Kollegen des Testmanagers, der sich so geäussert hatte. Mittlerweile waren es keine 75.000 Testfälle mehr. Die Zahl war deutlich höher.
Freitag, 5. Mai 2017
Zero Bug-Policy
 |
| Bild: Wikimedia Commons/JohnSka - CC BY-SA 3.0 |
"Kann gar nicht sein", erwiederte die Delivery Managerin, Scrum Guide und Agiles Manifest habe sie beides gelesen, da würde nichts von Bugs stehen. Nun ja, nicht wörtlich, aber indirekt durchaus. Werfen wir einen Blick darauf. Zunächst der Scrum Guide: im Abschnitt Increment sagt er über das Sprintergebnis It must be in useable condition [...] und ergänzt im Abschnitt Definition of Done Each Increment is additive to all prior Increments and thoroughly tested, ensuring that all Increments work together. Weiter mit dem agilen Manifest: in seinen Prinzipien legt es fest: We follow these principles: [...] Deliver working software frequently [...] Working software is the primary measure of progress. Software soll also "Usable" und "Working" sein, und um das sicherzustellen darf sie keine bekannten Fehler mehr enthalten. Denn selbst wenn die Fehlfunktion scheinbar gering ist - niemand kann sagen ob nicht weitere Funktionen auf dieser einen fehlerhaften aufbauen. Wenn das so ist können selbst kleine Bugfixes wirken wie das Entfernen des untersten Steins in einem Jenga-Turm - alles bricht zusamen. Also: Agilität erfordert eine Zero Bug-Policy.
Erneut musste die Delivery Managerin widersprechen. Für das Fixen aller Bugs wäre gar keine Zeit da, es müssten doch Deadlines eingehalten werden. Auch den Hinweis, dass die aktuell laufende Bugfixing-Phase den Release um drei Monate nach hinten geschoben hätte wollte sie nicht gelten lassen. Einen besseren Weg gebe es nun mal nicht, oder könnte ich einen nennen? Zu ihrem Pech - ja, ich konnte. Er nennt sich Andon und ist eines ältesten agilen Vorgehensmuster überhaupt. Übernommen aus dem Maschinenbau bedeutet er (vereinfacht gesagt), dass beim Auftreten eines Fehlers die Produktion neuer Features sofort angehalten und erst dann fortgesetzt wird wenn der Fehler behoben ist. Dadurch befindet sich alles immer in einem auslieferungsfähigen Zustand (Zero Bugs) und monatelange Test-, Bugfixing- und Retest-Phasen entfallen. Selbst wenn die Fehlerbehebung die Feature-Produktion kurzfristig verzögert ist der Gesamtzeitraum bis zur Fertigstellung kürzer, man spart also Zeit und Geld.
Sichtbar verärgert legte die Delivery Managerin ihr letztes Argument auf den Tisch. Das wäre ja alles schön und gut, und irgendwo würde das sicher funktionieren, ganz sicher aber nicht in ihrer Firma. Da wäre die Situation eine besondere, weite Teile der Anwendung könnte man nämlich gar nicht testen. Nun ja, ein klarer Fall von Truthiness. Um es mit einem Sprichwort zu sagen: ich kann den Menschen nur die Tür aufhalten, durchgehen müssen sie selber. Manchmal tun sie es nicht. Für alle Anderen (zum Glück die Mehrheit) gilt: eine Zero Bug-Policy ist machbar, sie beschleunigt die Entwicklung, spart Kosten und sie macht agile Softwareentwicklung überhaupt erst möglich.
Freitag, 5. August 2016
Agile Testkonzepte
 |
| Bild: Public Domain Images/Amanda Mills - CC0 1.0 |
Aber was gehört in ein agiles Testkonzept?
Im Grunde das Gleiche, das man auch in einem "klassischen" Testkonzept erwarten würde. Es sollte dort geklärt werden wer was wann wie und wo testet. Folgende Punkte sollten sich meiner Meinung nach dort finden:- Was bedeutet Testen im agilen Umfeld? (so früh und umfassend wie möglich)
- Wer trägt QA-Verantwortung? (alle)
- Was wird getestet? (sowohl die neuen Features als auch regressiv alle alten)
- Wie wird getestet? (möglichst automatisiert)
- Auf welchen Ebenen wird getestet? (auf allen, in Form einer Testpyramide)
- Wann beginnt die Testphase? (ganz am Anfang, bzw. es gibt sie nicht gesondert)
- Welche Tools werden eingesetzt? (z.B. Jenkins, Fitnesse)
- Auf welchen Umgebungen wird getestet? (möglichst produktionsnah)
- Wie lang sind die Testzyklen (idealerweise maximal ein Tag, siehe Punkt 4)
- Gibt es spezielle Test-Arten? (z.B. Lasttests, Penetrationstests, A/B-Tests)
- Wie werden die Ergebnisse dokumentiert? (im Idealfall durch das Test-Tool selbst)
- Wie ist die Rolle des Testers definiert? (Teil des Entwicklungsteams)
- Wie ist die Rolle des Test-/QA-Managers? (Servant Leader)
- Gibt es Testvorgaben in den Anforderungen? (Ja, Definition of Done und Akzeptanzkriterien)
- Wer verfasst diese Vorgaben? (der Product Owner zusammen mit dem Team)
- Werden interne und externe Regulierungsvorgaben erfüllt? (z.B. durch Mapping-Tabelle)
- Sonstiges (z.B. Test Driven Development)
Donnerstag, 21. Juli 2016
20.000 mal automatisch getestet
 |
| Bild: Wikimedia Commons/Library of Congress - Public Domain |
Ganz abgesehen davon, dass diese Aussage für die Betroffenen nicht besonders tröstlich sein dürfte - sie steht symptomatisch für ein Problem an dem viele Firmen leiden: den Glauben, dass Risiken sich minimieren lassen indem einfach mehr Tests durchgeführt werden. Das ist zwar nicht völlig falsch, viele, in kurzen Abständen durchgeführte Tests können einen hohen Mehrwert bringen. Zu glauben, dass hier eine Kausalität bestehen würde ist allerdings hochgradig riskant. Die Anzahl der Tests ist bestenfalls ein Indikator, mehr nicht.
Ich habe es über die Jahre immer wieder erlebt, dass ein Management "ambitionierte Ziele" formuliert hat, die erfüllt werden mussten. Pro Woche wurde eine bestimmte Anzahl von Tests vorgegeben die zu schreiben waren, und zwar sowohl bei den manuellen Tests als auch bei Unit Tests, automatisierten GUI-Tests und in anderen Bereichen. Um nicht an die Wand gestellt zu werden taten die Entwickler und Tester alles dafür diese Vorgaben zu erfüllen. Am Ende wurde die Planzahl erfüllt, allerdings durch sinnloses Aufblähen: Unit Tests für Getter und Setter, eigene End to End Tests für praktisch identische Testdaten-Sets und Ähnliches mehr kam so zu stande.
Wesentlich wichtiger als die Anzahl der Tests ist aber ihre Qualität: decken sie auch negative Validierungen ab? Überprüfen sie Grenzwerte? Basieren sie auf Überlegungen wo eine Fehlfunktion besonders großen Schaden anrichten würde? Solche Sachen. Das Problem dabei - lässt man sich darauf ein kann man als Manager nicht mehr so einfach an irgendwelchen Stellschrauben drehen um die (Illusion von) Sicherheit zu erhöhen. Auf der anderen Seite produzieren solche Tests dann tatsächlich einen Mehrwert und nicht bloß eine imposant klingende Zahl. Wenn es darauf ankommt ist die nämlich weder tröstlich noch nützlich. Siehe oben.
Dienstag, 28. Juni 2016
Size matters (die umgedrehte Test-Pyramide)
Beim Durchsprechen einer Präsentation für einen unserer Kunden sind ein Kollege und ich zu einer bemerkenswerten Erkenntnis gekommen: die Benutzung der "umgedrehten Test-Pyramide" kann unter Umständen das Gegenteil des gewünschten Effekt bewirken. Um das zu erklären zunächst die Grundlage - das hier ist die Pyramide in ihrer richtigen und in ihrer umgedrehten Form1:
Die richtige Form auf der linken Seite stellt dar wie die Größenverhältnisse zwischen den verschiedenen Test-Arten sein sollten: Sehr viele Unit Tests, weniger Integrationstests und ganz wenige manuelle Tests der obersten Ebene. Die Realität entspricht oft der rechten Darstellung: Viele manuelle Tests, wenige Integrationstests und kaum Unit Tests. Die Präsentation dieser beiden Grafiken soll den Managern des Kunden die Missstände aufzeigen und sie dazu bewegen etwas an ihnen zu ändern. Die Pyramidenform hat sich in diesem Zusammenhang als bewährtes Mittel der Visualisierung erwiesen. Sie lässt sich einfach aufzeichnen, stellt Ebenen und Größenverhältnisse nachvollziehbar dar und ist auch ohne technisches Vorwissen einfach verständlich.
Trotzdem haben wir in dieser Darstellung der beiden Pyramidenformen eine Quelle für Missverständnisse und Fehlentscheidungen entdeckt, und zwar die folgende - beide Pyramiden sind gleich groß. Für eher technikferne Entscheidungsrunden entsteht auf diese Weise der Eindruck, die Testabdeckung wäre in beiden Fällen gleich. Natürlich ist in diesem Zusammenhang offensichtlich, dass die manuelle Ausführung länger dauert, aber das muss ja aus Managementsicht nicht schlimm sein. Ich erinnere mich in diesem Zusammenhang an ein Berliner Startup, dass statt Testautomatisierern manuelle Tester einstellte, da es für das selbe Geld doppelt so viele von denen gab.
Was dabei völlig untergeht ist die Tatsache, dass die rechte Pyramide nicht nur auf dem Kopf steht, sondern, dass ihre Tests in Summe auch eine viel geringere Testabdeckung ergeben, und zwar auch dann noch wenn unproportional viele manuelle Tester eingestellt werden. Weder von der Menge noch von der Frequenz kann eine Ausführung von Hand auch nur in Ansätzen mit einer automatisierten mithalten. In einer guten Präsentation sollte das berücksichtigt werden, ganz einfach dadurch, dass die rechte, umgekehrte Pyramide erkennbar kleiner ist als die linke:
Das alleine kann zwar noch nicht garantieren, dass in den Managementrunden die notwendigen Erkenntnisprozesse stattfinden, es ist aber ein weiterer Baustein. Einer von mehreren die in Summe die klare Botschaft vermitteln sollen, dass die umgekehrte Pyramide etwas schlechtes ist, etwas, dass man so schnell wie möglich loswerden sollte.
1Natürlich ist das eine sehr stark vereinfachte Form, z.B. könnte es noch eine Ebene für automatisierte Oberflächentests geben.
Montag, 22. Februar 2016
Finger weg vom roten Knopf
 |
| Bild: Flickr/Włodi - CC BY-SA 2.0 |
Dynamische und verschlüsselte IDs, Klassen, etc.
Auf vielen Internetseiten werden die IDs von Elementen nicht fest vergeben sondern bei jedem Aufruf dynamisch generiert. Der Compose-Button mit dem man bei Gmail Emails erstellt hat zum Beispiel eben nicht die ID id=composebutton sondern je nach Aufruf eine zufällige wie id=:gz, id=:dc oder id=:dn. Wenn dieser Button jetzt während der Testaufzeichnung mit einer dieser IDs identifiziert wird, beim nächsten Aufruf aber eine andere generiert wird, dann schlägt der Test natürlich fehl - obwohl das Element da ist und funktioniert wird es nicht erkannt. Der gleiche Effekt tritt auf wenn der HTML-Code verschlüsselt ist, was etwa bei Banken ein Sicherheitsstandard ist.
Verifizierungsschritte
Im Grunde können nur zwei Arten von Aktionen aufgenommen werden, nämlich Mouseclicks und Tastatureingaben. Für einen brauchbaren Testfall sind die aber nicht ausreichend, es fehlen die Verifizierungsschritte. Wenn beispielsweise eine Datei erstellt und abgespeichert wird muss auch überprüft werden ob sie danach tatsächlich vorhanden ist. Bei manueller Durchführung muss man nach dem Speichern nur nachsehen ob sie angezeigt wird, da das aber lediglich mit dem Auge geschieht kann das Testprogramm das nicht nachvollziehen. Stattdessen müssen Befehle wie |ensure|do|verifyElementPresent|on|id=product| (Selenium IDE/Xebium) oder Browser("x").Page("y").WebEdit("z").Waitproperty "visible", True, 5000 (HP UFT) separat eingegeben werden. Von Hand.
Parametrisierung
Um einen wirklichen Nutzen aus automatisierten Tests zu ziehen müssen diese auch in verschiedenen Kontexten wiederverwertbar sein, etwa in verschiedenen Entwicklungsumgebungen, die über unterschiedliche URLs aufgerufen werden. Im Fall von HP UFT müsste dazu zunächst über den Befehl Dictionary.Add "LoginURL", Environment.value("LoginURL") der URL-Parameter in die Ausführungsinstanz geladen und dann mit SystemUtil.Run "C:\Programme\Mozilla Firefox\firefox.exe", Dictionary.Item("LoginURL"),"","",3 in einen Ausführungsschritt eingesetzt werden. Auch das kommt nicht über die Aufnahmefunktion in die Testskripte sondern nur manuell.
Aber warum?
Diese kurze Liste hier ist natürlich nicht erschöpfend und könnte sicher erweitert werden, aber um Vollständigkeit soll es hier gar nicht gehen. Interessanter wäre die Frage warum trotz der offensichtlichen Unzulänglichkeit und Unmöglichkeit noch immer das Phantom des reinen "Testfälle Aufnehmens" durch manche Projekte geistert. Ist manchen Managern und Testern der Unsinn dieses Vorhabens nicht bewusst? Die wahrscheinliche und erschreckende Antwort ist: Leider nein, dafür fehlt ihnen häufig die IT-Affinität. Das zu besprechen würde jetzt aber zu weit führen.
1Genannt werden im Folgenden die Gründe gegen die "Aufnahme-Illusion". Dass Oberflächentests alleine keine ausreichende Testabdeckung ergeben ist nochmal ein gesondertes Thema.
Freitag, 6. November 2015
Warum Scrum ohne Testautomatisierung nicht funktioniert (II)
 |
| Bild: Pixabay/Charlemagne - Lizenz |
Derartig fragile Produkte habe auch ich bereits erleben dürfen - egal ob es um Fehler, Reparaturen oder Erweiterungen ging, jedes mal wenn man sie anfasste gab es einen lauten Knall und alles brach zusammen. Die Aufräumphase im Anschluss dauerte dann Wochen. Einer der Entwickler bezeichnete diese Anwendungen einmal mit dem schönen Begriff "Jenga-Software". Genau wie beim namensgebenden Spiel kam man erstaunlich schnell an den Punkt an, dem man sie nicht mehr berühren konnte ohne dass alles in sich zusammenfiel. Ursachen kann eine derartige Situation einige haben, und keine davon ist schmeichelhaft für das beteiligte Entwicklungsteam (es sei denn, dass ihm vom Management bereits ein kaputter Bestandscode vorgesetzt wurde). Klar ist aber, dass in einer derartigen Situation eine agile (Weiter)Entwicklung nicht mehr machbar ist, denn die lebt ja davon, dass man die Anwendung ständig um- und ausbaut.
Möchte man eine derartige Situation vermeiden hilft eigentlich nur eine umfassende Testautomatisierung in Form von Unit-, Integrations- und Oberflächentests, die jedes einzelne mal durchlaufen müssen wenn neuer oder geänderter Code eingespielt wird. Auf diese Weise wird sofort festgestellt ob durch ihn bestehende Komponenten geschädigt werden, und wenn ja kann man direkt auf die nächstältere Version zurückspringen. Das sagt sich natürlich relativ einfach, ist in der Realität aber eigentlich nur umzusetzen wenn es von Beginn an befolgt wird oder wenn man bereit ist in eine nachholende Testautomatisierung sehr viel Zeit und Geld zu investieren. Wenn man es nicht tut kommt man aber sehr schnell in die Situation in der jetzt anscheinend die Post ist. Und man muss auch schon ein Konzern dieser Größenordnung sein um von derartigen Verlusten nicht in der eigenen Existenz gefährdet zu werden.
Siehe auch: Warum Scrum ohne Testautomatisierung nicht funktioniert (I)
Mittwoch, 24. Juni 2015
Qualität ist mehr als Testen: Reverse Engineering
 |
| Bild: Pixabay / Ennelise - Lizenz |
Zu den häufigsten Problemen mit denen man als agiler Tester konfrontiert wird gehört das völlige oder weitgehende Fehlen von schriftlichen Anforderungen oder Dokumentationen. Im Normalfall ist das ein starker Indikator dafür, dass das Team Agilität nicht verstanden hat und sie nach dem Dilbert-Modell eingeführt hat. Viele Tester neigen in solchen Situationen dazu, die Entwickler zu fragen was sie programmiert haben, um dann genau das zu testen. Dieses Vorgehen ist deshalb häufig weil es der einfachste und schnellste Weg ist - und ausserdem ist es grundfalsch!
Was bei diesem Ansatz völlig unter den Tisch fällt ist die eigentlich wichtigste Frage, die nämlich ob das was entwickelt wurde tatsächlich das ist was der Kunde/Product Owner/Auftraggeber wirklich wollte. Ohne festgehaltene Anforderungen oder Dokumentationen besteht ein hohes Risiko, dass einer der folgenden Fälle eingetreten ist oder eintreten wird:
- Der Ersteller der Anforderungen wusste selbst nicht genau was er wollte und hat daher "hinreichend unscharf" formuliert. In diesem Fall sind ausufernde Diskussionen um Anspruch und Wirklichkeit kaum zu vermeiden.
- Der Ersteller der Anforderungen wusste was er wollte, konnte es aber nicht formulieren. Mit großer Wahrscheinlichkeit entspricht das Ergebnis nicht seinen Vorstellungen.
- Der Ersteller der Anforderungen wusste was er wollte, hat es aber mittlerweile wieder vergessen. Auch hier werden lange Diskussionen das Ergebnis sein.
- Die Entwickler haben eine "pragmatische Lösung" gefunden, oder mit anderen Worten: sie haben die Anforderung ganz oder in Teilen ignoriert.
Die dringend notwendige (und hochgradig undankbare) Aufgabe des agilen Testers muss es jetzt sein, so genanntes Reverse Engineering zu betreiben. Das bedeutet zunächst, noch vor dem Testen die ursprüngliche Anforderung zu recherchieren, sie von ihrem Ersteller absegnen zu lassen und erst auf dieser Basis fortzufahren. Und fortfahren bedeutet in diesem Fall zunächst nicht das Testen, sondern vielmehr ein Gespräch mit dem Entwicklern, in dem diese sagen können wie die Anforderung von ihnen verstanden worden ist. Im Regelfall stellt sich bereits an dieser Stelle heraus, dass die (rekonstruierte) Anforderung und die Implementation spürbar auseinenderliegen. Ein Softwaretest in dem Sinn, dass überprüft wird ob Anforderung und Implementation übereinstimmen macht von da an praktisch keinen Sinn mehr.
An die Stelle des Testens sollte jetzt sinnigerweise eine Analyse treten, an deren Ende die Antworten auf die folgenden Fragen stehen sollten:
- Welche Teile der rekonstruierten Anforderung sind umgesetzt worden?
- Welche Teile der rekonstruierten Anforderung sind nicht umgesetzt worden?
- Was ist umgesetzt worden obwohl es in der rekonstruierten Anforderung nicht gefordert war?
- Was ist umgesetzt worden obwohl es mit der rekonstruierten Anforderung nicht kompatibel ist?
Auf Basis dieser Erkenntnisse können dann neue Anforderungen (diesesmal nach Möglichkeit schriftlich) formuliert werden um den Spalt zwischen Anspruch und Wirklichkeit zu schließen. Erst danach macht das Durchführen von Tests wirklich Sinn.
PS:
Ein Tipp aus der Praxis: Sobald es absehbar ist, dass das Fehlen schriftlicher Anforderungen und Dokumentationen dazu geführt hat, dass das Verständnis von Anforderungsersteller und Entwicklern sich auseinanderentwickelt hat, besteht das Risiko von verstärktem Blaming und Fingerpointing. Es ist an dieser Stelle immer eine gute Idee sich a) nicht daran zu beteiligen und b) anzumerken, dass ein gemeinsames Arbeiten an einer Lösung wesentlich zielführender ist als gegenseitige Schuldzuweisungen.
Montag, 18. Mai 2015
Qualität ist mehr als Testen: User Stories und Akzeptanzkriterien
 |
| Grafik: Pixabay / Geralt - Lizenz |
In agilen Projekten gibt es weder Feinspezifikationen noch Klickanleitungen, so dass der Tester wesentlich selbstständiger arbeiten muss. Konkret bedeutet das nicht nur, dass er die Testfälle selbst verfassen muss (dazu ein anderes mal mehr) - auch für die Anforderungen auf denen die Testfälle beruhen ist er (mit)zuständig. Spätestens an dieser Stelle der Erzählung ist es in den letzten Jahren regelmässig vorgekommen, dass sowohl Tester als auch Fachabteilungsmenschen Schnappatmung bekommen haben. "Was?? Test schreiben geht ja gerade noch, aber an den Anforderungen mitarbeiten? Das klappt doch niemals. Das kann ein Tester gar nicht."1
Soweit die Zweifler dieser Welt. Ich sage aber: es geht und es ist gar nicht schwer. Und zwar so:
Qualitätssicherung der Anforderung/User Story
User Stories bestehen in ihrer ursprünglichen Reinform aus einem einzigen Satz nach dem Muster "Als [User mit Rolle A] möchte ich [Aktion B durchführen können] um [Mehrwert C zu haben]." Um ein Beispiel zu nennen: Als Kunde möchte ich in meinem Login-Bereich meine Lieferadresse eingeben können, damit mir meine Waren zugeschickt werden können. Die Aufgabe des Testers wären hier folgende Überprüfungen:- Ist die Story klar genug beschrieben ("Ich möchte im Login-Bereich meine Adresse eingeben können" statt "Ich will meine Adresse eingeben")?
- Ist die Story klar zu anderen Anforderungen abgegrenzt ("Ich möchte meine Lieferadresse eingeben können" statt "Ich will alle meine Daten pflegen")?
- Ist ein Mehrwert erkennbar (endet die Story mit einem Zwecksatz)?
- Ist die Story testbar (" Ich will Daten eingeben können" statt "Ich will ein Eingabefeld haben, das in einer späteren User Story eine Funktion bekommen wird")?
Verfassen der Akzeptanzkriterien
Akzeptanzkriterien sollten ähnlich wie die User Story selbst nicht in eine Feinspezifikation ausarten, sondern in einfacher, auch für den Nicht-Informatiker verständlicher Sprache geschrieben sein. Sie sollten vom Verfasser der Story gemeinsam mit dem Tester erarbeitet werden und beantworten im Idealfall die folgenden Fragen: Wer bin ich?, Wo kann ich eine neue Aktion durchführen?, Was für eine Aktion ist das?, Welchen Effekt löse ich damit aus? und Welche Voraussetzungen müssen dafür gegeben sein? Beim oben genannten Beispiel sähe das so aus:- Wenn ich mich als User mit Rolle "Kunde" einlogge sehe ich in der Kopfnavigation den neuen Menüpunkt "Lieferadresse pflegen"
- Nach einem Klick auf den Menüpunkt werden Eingabefelder für Strasse, Hausnummer, Postleitzahl und Stadt angezeigt sowie ein Save-Button
- Wenn die Daten eingegeben und gespeichert werden erscheinen sie in der nur für User mit der Rolle "Lieferant" sichtbaren Tabelle "Kundendaten"
- Voraussetzungen: Die User Stories "Login" und "Kundendaten" müssen abgeschlossen sein bevor diese User Story begonnen wird
AberAberAber!!
Jedem der schon einmal eine klassische (Fein)Spezifikation gesehen hat wird spätestens jetzt ein Gedanke kommen: Dem Entwickler wird hier ja gar nicht gesagt wie er zu entwickeln hat! Und es gibt gar keine pixelgenaue Vorgabe wo und in welcher Farbe welches Element erscheinen soll!! Die Antwort darauf ist - natürlich nicht! Darauf zu verzichten und darauf zu vertrauen, dass das Entwicklungsteam (in Absprache mit PO und Tester) von sich aus die beste und effizienteste Lösung finden wird, das gehört zum agilen Vorgehen dazu. Und wenn man das einmal verinnerlicht hat kommt man auch schnell zu der Einsicht, dass eine "nur" aus User Story und Akzeptanzkriterien bestehende Anforderung auch von einem Tester mitbearbeitet werden kann - und auch mitbearbeitet werden sollte, wenn man denn Wert auf Qualität legt.1Wörtliches Zitat
Mittwoch, 1. April 2015
Warum Scrum ohne Testautomatisierung nicht funktioniert (I)
 |
| Bild: Flickr/Thisisseba - CC BY-SA 2.0 |
Erster Irrtum: Tests muss man immer nur einen Sprint lang durchführen
Zugegeben, ein bisschen verleitet Scrum zu dieser Fehlannahme. Die Software wird in diesem Vorgehen bereits in der Anforderungsphase in kleine, für sich selbst funktionsfähige Bausteine, bzw. User Stories zerlegt, die nach und nach erstellt werden und dann sofort lauffähig (und damit auch vollumfänglich getestet) sein müssen. Wenn diese Komponenten aber abschließend getestet und im besten Fall bereits live gegangen sind, entfällt doch der Bedarf weitere Tests durchzuführen - oder? Nun, nicht ganz. Da zukünftige User Stories das bisher erstellte Gesamtsystem laufend erweitern kann nicht ausgeschlossen werden, dass die bereits fertigen Teile beeinträchtigt oder beschädigt werden. Da Scrum aber verlangt, dass die Anwendung nach jedem Sprint Go Live-bereit ist, muss in jedem Sprint ein vollständiger Regressionstest aller Funktionen stattfinden, selbst wenn diese zu einer User Story gehören, die schon längst abgenommen ist.
Zweiter Irrtum: Regressiontest bedeutet, dass man die Akzeptanztests der User Stories wiederholt
Auch da bedarf es eines genaueren Blicks auf die Details. Es ist eben nicht so, dass die Summe aller Akzeptanztests eine gute Testabdeckung der Software ergibt. Akzeptanztests in ihrer ursprünglichen Form machen nur während des Sprints Sinn, in dem die Story umgesetzt wird, zu der sie gehören. Würde man sie danach eins zu eins in die Regression übernehmen, würden Probleme entstehen: Zum Einen wird die in früheren Stories entstandene Funktionalität oft durch spätere Stories verändert. Ältere Akzeptanztests sind dann nicht mehr zutreffend oder sogar obsolet. Zum anderen können verschiedene User Stories Schnittmengen haben, durch die es zu Akzeptanztests kommt, die sich teilweise auch in anderen Stories wiederfinden. Würde man sie trotzdem alle zu Regressiontests machen, entstünden in den Testsuiten Redundanzen und erhöhter Pflegeaufwand. Um diese Effekte zu vermeiden ist es notwendig, die Akzeptanztests abgeschlossener User Stories zu verwerfen und stattdessen eine auf dem aktuellen Entwicklungsstand beruhende, nach jedem Sprint aktualisierte Regressionstestsuite zu erstellen.
Dritter Irrtum: Regressionstests werden nur am Sprintende durchgeführt
Ein weiterer Irrtum, der auf dem alten Wasserfall- bzw. V-Modell beruht, in dem man noch so vorgegangen ist. In Scrum ist dieses Vorgehen hochriskant: Wenn Tests erst am Sprintende durchgeführt werden, können Fehler auch erst ganz zum Schluss entdeckt werden. Zu dem Zeitpunkt fehlt aber die Zeit um sie wieder zu beheben, die Stories können nicht abgenommen werden, der Sprint scheitert. Im schlimmsten Fall stellt sich heraus, dass man Zeit und Geld verschwendet hat, weil man die Arbeit von Beginn an anders hätte machen müssen. Um dem vorzubeugen ist notwendig, dass die Regressionstests regelmässig, am besten sogar nach jedem Checkin von neuem Code durchgeführt werden.
Betrachtet man diese drei Irrtümer (und ihre Widerlegungen), so ist der Sinn der Testautomatisierung sofort klar: Wenn es notwenig ist die Testsuiten praktisch täglich auszuführen, wenn diese Suiten permanent größer werden und wenn sie ausserdem nach jeder User Story-Abnahme aktualisiert und sofort wieder ausgeführt werden müssen, dann ist das schon nach kurzer Zeit manuell nicht mehr zu leisten. Man hat also die Wahl: entweder man verzichtet auf die vollständige Qualitätssicherung der Software (und verstößt damit gegen eine ganze Reihe agiler Prinzipien), oder man automatisiert.
Donnerstag, 12. März 2015
Übergreifende Teamsteuerung mit Kanban-Boards
 |
| Bild: Pixabay / Geralt - Lizenz |
Zu erkennen ist der typische Kanban-Flow: Spalte 1 entspricht den hoch priorisierten Backlog Items, Spalte 2 zeigt die Stories des laufenden Sprints in denen noch gecoded wird, in Spalte 3 hängen die Stories in denen aktuell Akzeptanztests durchgeführt werden, Spalte 4 enthält die Stories die zur Abnahme durch die POs anstehen. Spalte 5 bildet den Übergang zur übergreifenden Qualitätssicherung: Die Tester der jeweiligen Scrumteams stellen die Stories und Tests den anderen Testern vor. In Spalte 6 hängen die Stories deren Tests gerade automatisiert werden (oder in bestehende automatisierte Tests eingearbeitet werden). Spalte 7 war wesentlich größer als hier gezeigt und bildete praktisch das Archiv.
Der Vorteil an diesem Vorgehen: Es entsteht ein großes Bild, das die gesamte Stecke zwischen den Team-Backlogs und den Regressionstest-Suiten zeigt, allen an der Qualitätssicherung beteiligten Personen ist immer bewusst woran die jeweils anderen arbeiten, Aufwände können visualisiert und gesteuert werden, es findet ein Wissenstransfer zwischen den Teams statt. Der Nachteil: Damit das Vorgehen funktioniert sind weitere Regeltermine nötig, also Querschnitts-Dailies (oder Bi-Weeklies) für alle Tester und Testautomatisierer. Die Vorteile wiegen diesen Nachteil allerdings bei weitem auf.
PS: In diesem Beispiel geht es lediglich um den Teilbereich der Qualitätssicherung, natürlich können aber auch viele andere Aspekte durch solche Boards teamübergreifend gesteuert werden.
Donnerstag, 5. März 2015
Fachartikel: Testautomatisierung mit Xebium
 |
| Screenshot von sigs-datacom.de |
Zum Artikel geht es hier (PDF).
