Carsten Czeczine, Author at Binaris Informatik

Test Driven Development in sechs einfachen Schritten

Carsten Czeczine — Tue, 25 Apr 2023 11:51:38 +0000

Sie möchten eine neue Software entwickeln. Dabei haben Sie natürlich die Absicht ein tolles Produkt mit einer hervorragenden technischen Qualität zu erzeugen. Und diese hervorragende technische Qualität wollen Sie mit einer möglichst umfassenden Testabdeckung beweisen und absichern. Doch in erschreckend vielen Fällen werden die Punkte hervorragende technische Qualität und umfassende Testabdeckung deutlich verfehlt.

Bei der Suche nach einem Weg, wie Sie das in Zukunft besser machen können wird dann oft ein Konzept in den Raum geworfen, dass die Lösung für all unsere Probleme sein soll:

Test Driven Development

Wenn Sie dann fragen, wie Test Driven Development dieses Wunder denn vollbringen möchte, dann bekommen Sie oft zur Antwort, dass Sie einfach nur die Reihenfolge von Programmierung und Testen umdrehen müssen und der Rest regelt sich dann schon von ganz alleine.

In diesem Artikel wollen wir uns damit beschäftigen, ob dieses Versprechen zu schön ist, um wahr zu sein oder ob da doch etwas dran ist.

Um es hier gleich zum Anfang zu verraten: Ja, Test Driven Development kann tatsächlich dieses scheinbare Wunder wirken. Allerdings nur, wenn wir Test Driven Development, oft einfach auch nur TDD genannt, wirklich verstehen. Inklusive allem, was rund um das Grundkonzept mit zum Gesamtpaket TDD gehört.

„Test Driven Development ist nicht nur ‚erst Test, dann Programmierung‘, es ist ein Gesamtpaket“

Sehr oft beobachten wir, dass Unternehmen TDD einführen wollen und kurz danach wieder verwerfen, weil es bei ihnen scheinbar nicht funktioniert oder nicht passt. Unsere These ist dann in den meisten Fällen, dass sie nicht den vollen Umfang von TDD verstanden und nur den offensichtlichen Teil probiert haben. Deshalb schauen wir uns heute gemeinsam an, woraus das Gesamtpaket TDD besteht und welche Schritte notwendig sind, damit es auch bei Ihnen funktionieren kann.

Betrachten wir TDD genauer, dann stellen wir fest, dass bevor wir zum offensichtlichen Kernelement kommen, also die Reihenfolge Implementierung/Test umzudrehen, wir erst ein paar Hausaufgaben zu machen haben. Und dass wir nach der Umsetzung des Kernelements noch einen zusätzlichen Schritt weitergehen müssen, um wirklichen Erfolg haben zu können.

Aber keine Angst, in diesem einfachen 6-Schritte-Programm zeigen wir Ihnen, wie Sie Test Driven Development erfolgreich in Ihrem Unternehmen oder Projekt einführen und damit in Zukunft Ihre Erwartungen an technische Qualität und Testabdeckung erfüllen können.

Schritt Eins: Die Motivation zum Testen klären

Der erste Schritt besteht darin, zu klären was Tests eigentlich sind oder besser, warum wir eigentlich testen wollen.

„Warum müssen wir denn über den Grund für das Testen reden, der ist doch klar. Ich will nur wissen, ob mein Programm auch funktioniert!“ mag sich da so mancher nun denken. So haben es viele von uns auch ursprünglich mal gelernt. Wir schreiben ein Stück Software und dann überprüfen wir, ob es auch funktioniert. Fertig!

Doch die Realität ist ein bisschen komplexer. In unserer Wahrnehmung gibt es vier Gründe zum Testen bzw. zum Schreiben von automatisierten Tests:

Wir suchen die Ursache für einen Fehler und testen deshalb das Verhalten eines gegebenen Systems
Wir haben ein System oder einen Teil eines Systems erstellt und wollen nun die einwandfreie Funktionsweise unserer Schöpfung beweisen und auf Dauer sicherstellen
Wir haben vor, ein System oder einen Teil eines Systems zu erstellen und wollen über Tests bereits im Vorfeld unsere Erwartungshaltung definieren, damit wir genau das Richtige implementieren
Wir haben vor, ein System oder einen Teil eines Systems zu erstellen und wollen mit Tests dabei helfen, dass unser System wartbar und weiterentwickelbar ist bzw. bleibt

Für jede dieser Intentionen gibt es verschiedene Arten von Test und Vorgehensweisen, die den angestrebten Zweck erreichen können. Abhängig davon, was wir eigentlich mit unserem Testen erreichen wollen, müssen oder können wir die dazu passenden Formen von Tests und Vorgehensweisen wählen.

Das klingt sehr trivial und ist es auch. Vielleicht ist es gerade deshalb so wichtig, diesen Schritt bewusst zu gehen. Wenn wir ein neues Produkt erstellen oder ein bereits bestehendes um neue Funktionalitäten erweitern wollen, dann sind vor allem der dritte und vierte Grund unsere Hauptmotivation in Verbindung mit dem zweiten.

Nur den zweiten Grund als Motivation zum Testen zu sehen ist eine sehr eingeschränkte Sichtweise, die das volle Potenzial des Testens außen vor lässt und unsere Möglichkeiten beschränkt, die bessere Software erstellen zu können. Erst hinterher durch Tests die korrekte Funktionsweise einer Software sicherstellen zu wollen ist der Grund, warum in vielen Unternehmen die Qualitätssicherung nichts mit der Produktentwicklung zu tun hat und warum Testen als ein separater, von der Programmierung getrennter Schritt verstanden wird. Das ist die Absicht, erst hinterher festzustellen, dass „es“ nicht funktioniert und dann noch zu versuchen, das Produkt zu retten.

Wir dahingehen wollen Qualitätssicherung oder Qualitätsmanagement als Bestandteil der Produktentwicklung sehen. Wir wollen direkt das funktionierende, wartbare und erweiterbare Produkt bauen.

Schritt Zwei: Die Eigenschaften guter Software erkennen

Das führt uns direkt zum zweiten Schritt in unserem Programm, die technischen Eigenschaften guter Software. Gute, robuste Softwarekomponenten zeichnen sich durch folgende vier Eigenschaften aus:

Lauffähigkeit
Einfachheit
Relevanz
Redundanzfreiheit

Was bedeutet das? In erster Linie wollen wir, dass unsere Software funktioniert. Und zwar fehlerfrei. Das ist schon mal klar verständlich.

Dann möchten wir aus Gründen der Wartbarkeit, dass sie möglichst einfach ist bzw. dass alle einzelnen Komponenten möglichst simple und leicht verständlich sind. Jeder Softwareentwickler, der schon mal in eher schwer verständlichen Sourcecode Änderungen einbauen musste, ist von diesem Punkt direkt ein großer Fan. Und ebenso jeder Projektverantwortliche, der für eine Weiterentwicklung schon mal astronomische Aufwandsschätzungen zu hören bekam mit der Begründung, der aktuelle Softwarestand wäre schwer zu verstehen und deshalb schwer zu erweitern.

Und natürlich ist es eine gute Idee, wenn jedes Stück Sourcecode auch wirklich einen relevanten Teil zur Lösung des Problems beiträgt. Unnützer oder toter Code reduziert nur die Wartbarkeit.

Das gleiche gilt auch für die Freiheit von Redundanzen, also doppeltem Code; auch diese erhöht die Wartbarkeit und reduziert das Fehlerrisiko.

Relevanz und Redundanzfreiheit sind in dieser Liste Begriffe, die in sich schon sehr gut erklären, wann sie tatsächlich gegeben sind. Wenn jedes Stück Sourcecode auch wirklich benutzt wird, dann ist alles relevant und wenn es nirgendwo identische Codestellen gibt, dann ist die Software auch redundanzfrei.

Spannender wird es schon bei der Lauffähigkeit und der Einfachheit, denn für beides ist eine genauere Definition nötig. Die Lauffähigkeit lässt sich gut durch Akzeptanzkriterien definieren oder auch eine sogenannte Definition of Done, in der die Beteiligten gemeinsam festhalten, was es bedeutet, dass eine Funktionalität oder ein Feature fertig ist.

Ähnliches gilt für Einfachheit, auch diese Worthülse darf mit einer gemeinsamen Definition mit echtem Leben gefüllt werden, z.B. mit Code Metriken, Style Guides oder gemeinsamen Architekturkonzepten.

Schritt Drei: Das Schreiben echter Unit Tests lernen

Im nächsten Schritt dürfen wir lernen, was echte Unit Tests sind und wie sie geschrieben werden.

Wie wir jetzt auf Unit Tests kommen? Wie wir gleich sehen werden, sind Unit Tests die unterste und elementarste Ebene der technischen Tests und eine Grundlage beim Test Driven Development. Deshalb beschäftigen wir uns nun in diesem Schritt mit Unit Tests.

Bei dem Begriff Unit Test haben wir ähnliche Herausforderungen wie bei den Begriffen Lauffähigkeit und Einfachheit: Jeder hat den Begriff schon gehört und auch eine Vorstellung davon, was diese bedeuten. Nur bedeutet das noch lange nicht, dass wir auch alle das Gleiche darunter verstehen.

Die babylonische Sprachverwirrung

Modul-, Komponenten-, Integrations-, System-, Akzeptanz-, End-to-End- oder Abnahmetest, Namen für unterschiedlichen Testlevel oder -arten gibt es viele. Allerdings sind die Bedeutungen nicht wirklich standardisiert. Sie sind nur Vereinbarungen zwischen den betroffenen Personen. Stellen Sie also sicher, dass Sie wirklich alle das gleiche unter diesen Begriffen verstehen und gehen Sie nicht einfach blind davon aus. Den Begriffen oben ist gemeinsam, dass sie alle die Reichweite, den Scope, der Teststufe beschreiben und nicht das Verfahren. Im Gegensatz zu Begriffen wie Performance-, Last-, Langzeit-, Monkey- oder Smoketests. Und auch hier gilt: Klären Sie das gemeinsame Verständnis der Begriffe.

Definitionen zu Unit-Test, die wir schon oft von unseren Kunden zu gehört haben sind diese:

„Unit Tests sind die Entwicklertests, also alles, was die Entwickler testen“
„Mit Unit Tests testen wir einzelne Einheiten“
„Unit Tests sind Klassentests“
„Unit Tests testen die Funktionen von Klassen“
„Unit Tests sind die automatisierten Tests“
„Unit Tests sind Tests, die mit JUnit geschrieben wurden“

Jede dieser Definitionen ist durchaus nachvollziehbar und doch ist keine davon so richtig hilfreich. Gehen wir also in die genaue Klärung des Begriffs Unit Test.

In der Liste der Motivationen zum Testen sind Unit Tests ein geeignetes Mittel für die Punkte zwei, drei und vier. Um diese Behauptung überprüfen zu können, betrachten wir, was denn ein Unit Test eigentlich sein soll. Unser erster Versuch einer Definition lautet wie folgt:

Unit Tests sind ein Verfahren, um das Verhalten einer Komponente isoliert, d.h. ohne ihre Abhängigkeiten zu anderen Komponenten, zu überprüfen.

Das bedeutet, wir wollen ein bestimmtes Verhalten in einem klar definierten Kontext überprüfen und dabei jede Form von Seiteneffekten vermeiden. Deshalb klammern wir die Abhängigkeiten zu anderen Komponenten explizit aus. Jede weitere Komponente, von der unser zu testendes Verhalten abhängig ist, bedeutet einen weiteren Faktor, den wir kontrollieren müssen bzw. der das Ergebnis unseres Tests beeinflussen kann.

Wie können wir nun diesen Anspruch auf isoliertes Testen in unseren Tests umsetzen?

Sehen wir uns dazu ein Beispiel in Java an. In einem Baseballszenario wirft ein Pitcher einen Ball, den ein Spieler zu treffen versucht. Wir möchten einen Unit Test für die Methode hitBaseball() schreiben, bei der der Spieler einen durchschnittlich geworfenen Ball erfolgreich treffen soll. Spontan sähe unser Test so aus:

Der Pitcher erzeugt beim Werfen einen Ball, der alle Attribute eines Balles hat, der durchschnittlich geworfen wurden. Der Spieler versucht den Ball zu treffen und wir gehen eigentlich davon aus, dass er das müsste. Das ist unsere Erwartungshaltung.

Ist das nun ein Unit Test gemäß unserer Definition oben? Ganz klar nein!

Neben der Methode hitBaseball(x), dem Verhalten, dass wir eigentlich testen wollen, testen wir hier auch direkt noch throw(y) von Pitcher mit und die interne Implementierung von Baseball. Wenn dieser Test fehlschlägt, dann ist nicht deutlich ersichtlich, woran das liegen könnte, die Anzahl der Codestellen, die sich unerwartet verhalten ist einfach zu groß.

Probieren wir es mal anders:

Was ist jetzt anders?

Um die Methode hitBaseball testen zu können, benötigen wir einen Baseball. Nur lassen wir uns den diesmal nicht von einem Pitcher, den wir ja hier überhaupt nicht testen wollen, erzeugen. Stattdessen erzeugen wir uns mit Hilfe eines Mock Frameworks, hier Mockito, einen Mock, der so aussieht, wie ein Baseball.

Wir brauchen jetzt keinen Pitcher mehr und sind damit in unserem Test auch nicht mehr davon abhängig, dass der Pitcher sich wirklich wie erwartet verhält. Durch den Mock haben wir uns selber etwas erzeugt, dass wie ein Baseball aussieht. Allerdings müssen wir nun noch sicherstellen, dass sich dieser Mock auch wie ein durchschnittlich geworfener Baseball verhält.

In diesem Beispiel wissen wir aus der Implementierung vom BaseballPlayer, dass wir den Ball nach seiner Geschwindigkeit fragen werden. Also erklären wir dem Mock, dass er 90 (mph) zu antworten hat, wenn er nach seiner Geschwindigkeit gefragt wird.

So testen wir exakt nur noch das Verhalten von hitBaseball(x).

Wenn wir Tests auf diese Art und Weise schreiben, dann bekommen wir als Ergebnis eine ganze Menge an Tests, die jeweils nur ein ganz bestimmtes Verhalten einer Komponente testen. Wir sagen manchmal auch, ein Unit Test testet nur einen einzelnen Aspekt einer Komponente. Das verfeinert unsere Definition von Unit Test.

Aber warum tun wir uns das an? Es ist schon eine ganze Menge Arbeit, so viele so kleine Tests zu schreiben. Und es ist ja nicht nur die Menge der Tests, die nun zu schreiben sind. Auch die Implementierung selbst ist so zu halten, dass diese einzelnen Aspekte überhaupt isoliert testbar sind.

Wir könnten doch auch einfach eine kleinere Anzahl an großen Tests schreiben, die direkt mehrere, oder sogar alle Aspekte einer Komponente und das Zusammenspiel mit ihren abhängigen Komponenten testen, oder? Ja, könnten wir. Aber genau das wollen wir nicht mehr.

Lassen Sie uns drei Motivationen anführen, warum wir stattdessen echte Unit Tests verwenden möchten:

a. Wenn meine „großen“, komplexen Tests grün laufen, also kein Fehler auftritt, dann ist alles in Ordnung. Easy going. Aber wenn jetzt doch was nicht in Ordnung ist, was genau stimmt dann nicht. Mein „großer“ Test verrät es im schlimmsten Fall nicht, die einzige Aussage wäre: „Irgendetwas stimmt nicht!“ Und selbst bei einem besser strukturierten Test bleiben noch eine Reihe von potenziellen Fehlergründen offen, die wir nun manuell durchtesten müssten. Bis wir wüssten, was tatsächlich das Problem ist und es beheben könnten, müssten wir viel weitere Arbeit investieren. Haben wir viele einzelne Tests, die unabhängig voneinander einzelne Aspekte testen, zeigt uns der fehlschlagende Test direkt die Fehlerursache an. Fehlerfinden und -beheben wird damit zum Kinderspiel.

b. Ein größerer Testkontext besteht meistens aus einer größeren Anzahl an Parametern, Ausgangsbedingungen oder Ablaufmöglichkeiten, die unterschiedliche Ergebnisse erzielen können. Selbst wenn wir nur eine repräsentative Auswahl an realistischen Szenarien mit Tests abbilden möchten, wird durch die Komplexität der Abhängigkeiten die Anzahl der notwendigen Tests schnell groß, oft sogar sehr groß. Und wir reden hier von „größeren“ Tests, also höherem Aufwand pro Test. Haben Sie dadurch schon mal sehenden Auges eine geringere Testabdeckung in Kauf genommen, obwohl Sie ein schlechtes Gefühl dabei hatten? Seien Sie ehrlich! Die Reduzierung des Testkontextes auf den einzelnen Aspekt einer Komponente, reduziert damit auch die Komplexität der Tests. Weil diese Test unabhängig voneinander sind, entsteht für die Testabdeckung nun auch nicht mehr das Kreuzprodukt aller möglichen Kombinationen. Für die Auswahl der übergeordneten Tests, die das Zusammenspiel der Aspekte testen, können wir uns nun auf eine wirklich repräsentative Auswahl realistischer Szenarien beschränken. Wir werden später noch über diese Art von Tests reden.

c. Was schrieben wir oben? Für Unit Tests muss die Implementierung so geschrieben sein, dass die einzelnen Aspekte überhaupt einzeln testbar sind. Das bedeutet nichts anderes als ein wirklich modulares Design bis in den letzten Winkel und ein hohes Maß an loser Kopplung. Müssen wir hier noch über die Vorteile einer derartigen Architektur reden? Wohl kaum. Unit Tests zwingen uns also zum besseren technischen Design.

AAA-Regel

Um jetzt gute Unit Tests zu schreiben, gibt es ein paar Faustformeln, wie ein Unit Test aussehen sollte. Eine davon ist die AAA-Regel. AAA steht dabei für

Arrange
Act
Assert

und beschreibt den Aufbau eines Unit Tests.

Im Arrange wird die Startsituation des Tests definiert. Die Komponente wird erzeugt und initialisiert, Mocks werden erzeugt, gesetzt und evtl. das Verhalten der Mocks definiert, Variablen werden gesetzt.

Im Act wird die eigentliche Aktion, die das zu verifizierende Ergebnis erzeugen soll, durchgeführt. In der Regel ist das der Aufruf der Methode, deren Verhalten getestet werden soll. Ein guter Unit-Test besteht hier nur aus einem Aufruf. Ist mehr als ein Aufruf notwendig, dann ist das ein Hinweis darauf, dass mehr als nur ein einfacher Aspekt getestet wird!

Und schlussendlich wird im Assert nun überprüft, ob auch das erwartete Ergebnis durch das Act erzielt wurde. Hier gilt, dass nur ein einzelnes fachliches Ergebnis geprüft werden soll. Und dabei liegt die Betonung auf fachliches Ergebnis, nicht technisches. Das bedeutet also nicht zwangsläufig, dass dafür nur ein einzelnes Assert-Statement verwendet werden darf. Wenn über mehrere Vergleiche verschiedene Teilaspekte des fachlichen Ergebnisses überprüft werden müssen, dann ist das schon in Ordnung. Wenn allerdings z.B. ein Unit-Test TestInsertKunde im Assert prüft, ob der Kunde wirklich in der die Datenbank geschrieben UND ein entsprechender Logeintrag im Logfile erzeugt wurde, dann ist das ein Hinweis darauf, dass hier mehr als nur ein einzelner Aspekt getestet wurde.

So simple und vielleicht auch nervig, wie die Einhaltung der AAA-Regel auch scheinen mag, sie hilft, echte Unit Tests zu identifizieren.

Wir sehen in dem Beispiel, dass hier Act und Assert in einer Zeile, quasi ineinander verschachtelt stehen. Hier kann man argumentieren, dass für die bessere Lesbarkeit dieses zu trennen ist, also den Schlag des Spielers in einer einzelnen Zeile und das Ergebnis daraus in einer lokalen Variable fangen und dann diese im Assert auswerten.

Ob das nun der besseren Lesbarkeit und Wartbarkeit wegen wirklich notwendig ist, ist schwer objektiv zu beurteilen. Deshalb überlassen wir diese Entscheidung denen, die mit dem Code und den Tests arbeiten müssen.

FIRST

Ein anderes Akronym zur Identifizierung von guten Unit Tests ist FIRST, auch als FIRST Properties von Unit Tests bekannt. FIRST steht dabei für:

Fast
Isolated
Repeatable
Self-Validating
Timely

Fast: Ein Unit Test soll schnell in der Ausführung sein. Warum? Nun, so granular wie Unit Tests sind, reden wir bei der Durchführung der Tests nicht von einem oder zwei Unit Tests, sondern im Laufe der Zeit wird die Anzahl eher auf ein paar Hundert Unit Tests ansteigen, vielleicht auch ein paar Tausend. Und der große Vorteil einer guten Codeabdeckung durch automatisierte Tests ist, dass wir bei Änderungen quasi durch einen Mausklick überprüfen können, ob noch alles funktioniert. Wenn der Durchlauf aller Tests aber ein oder zwei Stunden dauert, oder vielleicht noch länger, dann wird die Motivation abnehmen, diese Testläufe in kurzen Intervallen durchzuführen. Das geht wieder auf Kosten der Qualität, weshalb jeder einzelne Unit Test schnell sein muss, zwei bis drei Sekunden maximal. Und noch schneller wäre noch besser.

Isolated: Unit Tests sind unabhängig voneinander. Das bedeutet, die Durchführbarkeit eines Unit Tests hängt weder davon ab, dass ein anderer Test bereits gelaufen ist, noch dass ein anderer Test vorher ein bestimmtes Ergebnis erzielt hat. Jeder Unit Test erzeugt im Arrange selbst die für ihn notwendige Startkonstellation.

Repeatable: Ein Test muss beliebig oft wiederholbar sein. Und zwar ohne, dass zwischen zwei Testläufen manuell oder auch durch einen anderen Prozess (z.B. ein anderer Test) die im ersten Testlauf erzeugten Zustände zurückgesetzt werden müssen. Oder anderes formuliert: Ein Unit Test hinterlässt keine persistenten Zustandsänderungen im System. Entweder erzeugt er erst keine Zustandsänderungen oder er räumt sie selber zum Abschluss des Tests wieder auf, indem er z.B. Werte aus der Datenbank wieder löscht oder zurücksetzt. Das steht in einem engen Zusammenhang mit den Punkt Isolated.

Self-Validating: Ein Unit Test kann immer selber eineindeutig bestimmen, ob er erfolgreich war oder fehlgeschlagen ist. Für diese Beurteilung ist definitiv keine manuelle Bewertung durch einen Menschen erforderlich. Klingt blöd und eigentlich selbstverständlich. Doch finden wir immer mal wieder vor, dass erst einer der Entwickler oder Tester nochmal darauf schauen muss, um zu beurteilen, ob der Testlauf jetzt ok war oder eher nicht. Wenn das der Fall ist, dann stimmt etwas mit der Grundidee der entsprechenden Tests nicht.

Timely: Unit Tests sind nicht besonders gut geeignet, um sie irgendwann mal später zu schreiben, vielleicht Tage, Wochen oder Monate nachdem der Sourcecode geschrieben wurde. Quasi nur, um nachträglich noch eine gute Testabdeckung zu erreichen. Wie wir oben schon gesehen haben, hat alleine das Schreiben der Unit Tests einen großen Einfluss darauf, wie der Sourcecode strukturiert wird. Deshalb gehören die Erstellung von Sourcecode und Unit Tests unmittelbar zusammen. Das werden wir uns gleich noch genauer ansehen, wenn wir über die testgetriebene Entwicklung reden.

Das sind eine Menge Faktoren, die für die Erstellung guter Unit Tests zu berücksichtigen sind. Und deshalb nochmal die Frage. Warum tun wir uns das an?

Nun, der konsequente Einsatz von Unit Tests hilft uns, Software zu schreiben, die die Kriterien guter, robuster Software erfüllen (siehe Schritt 2).

Also schreiben wir doch einfach konsequent Unit Tests. Doch jetzt gibt es beim klassischen Test-After Ansatz, das heißt ich schreibe erst meinen Sourcecode und erst danach die entsprechenden Tests, ein kleines Problem mit den Unit Tests. Wie wir oben gesehen haben, hat die Erstellung eines Unit Tests großen Einfluss auf die Struktur und das Design des eigentlichen Sourcecodes. Ich werde also vermutlich oft beim Schreiben eines Unit Tests feststellen, dass ich diesen Test so gar nicht schreiben kann, weil die Implementierung des Sourcecodes es nicht zulässt. Also zurück in den Sourcecode und diesen ändern. Beim nächsten Unit Test wieder und wieder und wieder. Das kann schnell nervig werden und die Motivation reduzieren, weitere Unit Tests zu schreiben.

Wenn jedoch meine Unit Tests mir sowieso schon vorgeben wollen, wie ich den Sourcecode zu schreiben habe, warum dann nicht direkt die ganze Idee einfach umdrehen? Also erst den Test schreiben und dann dazu passend implementieren? Und schon sind wir mitten in der testgetriebenen Entwicklung gelandet, auf Neudeutsch auch Test Driven Development oder TDD genannt.

Schritt Vier: Test Driven Development Grundprinzip verstehen

Also ist TDD einfach nur zuerst den Test zu schreiben und dann den Sourcecode?

Ja … und nein. Tatsächlich ist die einfache Umkehrung der Reihenfolge die Grundidee des TDDs. Schon alleine das wäre oft eine große Verbesserung im Hinblick auf Testqualität und -abdeckung. Doch die TDD-Gurus sagen immer so schön:

„TDD is a design process, not a testing process“

Es geht, genau wie bei den Unit Tests nicht nur darum, eine gute Testqualität und -abdeckung zu erzielen, sondern wir wollen besseren Sourcecode schreiben.

Damit wir das erreichen können, gibt es da noch ein paar weiterführende Ideen im TDD, die wir uns jetzt ansehen wollen. Die erste grundlegende Idee ist, dass der TDD-Zyklus nicht aus zwei, sondern aus drei Phasen besteht:

Schreibe einen Test
Implementiere gegen den Test
Räume auf

Zum ersten Schritt müssen wir nicht mehr viel sagen. Obwohl … ja doch, ein paar Anmerkungen gibt es auch dazu. Die Betonung liegt auf einen Test. Wir schreiben also nur einen Test und nicht gleich alle Tests, die uns gerade einfallen. Dann starten wir den Test und dieser Test muss fehlschlagen! Das ist wichtig. Wenn dieser Test jetzt schon erfolgreich durchlaufen würde, dann hätten wir in Wirklichkeit einen Test für eine bereits bestehende Lösung geschrieben. Und das wäre wieder Test-After.

Jetzt implementieren wir gegen den Test, das heißt, wir schreiben genau den Sourcecode, der nötig ist, damit der Test erfolgreich durchläuft. Und zwar auch nur so viel, wie unbedingt nötig ist und keine Zeile mehr. Alles, was wir mehr programmieren würden, wäre nicht durch einen Test abgedeckt. In dieser Phase geht es ausschließlich darum, eine lauffähige Lösung zu finden. Und noch nicht um Schönheit.

Wenn der Test erfolgreich durchgelaufen ist, räumen wir auf, inzwischen auch in Deutschland gerne als Refactoring bezeichnet. Nachdem wir bewiesen haben, dass wir die eigentliche Lösung gefunden haben, dürfen wir das Ganze auch hübsch machen, das heißt, wir entfernen jetzt eventuell redundanten Code, machen Variablen oder Methodennamen sprechender, überprüfen, ob wir uns an alle Programmiervorgaben gehalten haben, ob alle Code Metriken erfüllt sind und was sonst noch so ansteht, damit das Ergebnis unserer Definition von gutem Sourcecode entspricht.

Einige erfahrene Entwickler behaupten hier gerne, sie können sofort richtig und sauber programmieren, der letzte Schritt wäre damit unnötig. Auf einige ganz wenige Profis trifft das auch zu. Doch die meisten von uns sind in Wirklichkeit doch noch nicht ganz so weit. Das ist keine Schande, auch wir halten uns an die Trennung von zuerst die Lösung finden und erst dann aufräumen. Wir stehen dazu!

Was hier auch noch einen besonderen Hinweis verdient ist, dass das Aufräumen sich nicht nur auf unsere Lösungsimplementierung bezieht, sondern natürlich auch auf unseren Test Code. Sie erinnern Sich an das F in FIRST? F wie Fast. Jeder einzelne Test verdient es, dass Sie ihn nochmal unter die Lupe nehmen. Kann der nicht noch schlanker und schnell werden? Und auch noch lesbarer und wartbarer? Bedenken Sie, im Laufe der Zeit wird die Anzahl der Tests auf eine drei- bis vierstellige Anzahl anwachsen. Dann müssen die alle zusammen immer noch performant und wartbar sein. Kümmern wir uns also doch einfach direkt darum, bevor es zu spät ist.

Schritt Fünf: In kurze Zyklen zu arbeiten lernen

Wo wir gerade bei Geschwindigkeit sind, sehen wir uns doch mal die zweite grundlegende Idee an, der schnelle Durchlauf des kompletten TDD-Zyklus.

Eine sehr spannende Idee ist, dass ein vollständiger TDD-Zyklus (Testscheiben, Implementierung, Refactoring) innerhalb von 90 Sekunden durchlaufen werden soll.

90 Sekunden? Warum diese Eile?

Dies zwingt uns in kleinen Lösungsschritten zu arbeiten. Wenn ich in 90 Sekunden den ganzen Zyklus durchlaufen möchte, wie groß darf der Test dann maximal sein, dass ich in einem Teil der Zeit schreiben kann. Und wie groß darf das Problem maximal sein, dass ich dann in einem Teil der verbleibenden Zeit lösen muss. Diese selbstauferlegte Herausforderung erzwingt, dass wir wirklich in sehr kleinen Einheiten unser Softwareproblem lösen. Wir müssen große Probleme in kleinere und noch kleinere Probleme zerlegen, für die wir dann auch dementsprechend kleine Lösungen finden müssen. Das nimmt die Komplexität aus dem Thema und reduzierte Komplexität führt in den meisten Fällen zu besseren und zuverlässigeren Lösungen. Das erinnert stark an das, was wir oben über Unit-Tests besprochen haben.

Jetzt sind 90 Sekunden allerdings tatsächlich ziemlich knapp für die Vorstellung, in dieser Zeit aus dem Nichts einen vollständigen lauffähigen Unit Test und die dazu passende Implementierung zu schreiben und dann noch beides hübsch zu machen. Selbst dann, wenn wir uns nur ein sehr, sehr kleines Problem vornehmen wollen.

Deswegen dürfen wir verstehen, dass ein Durchlauf des Zyklus nicht bedeutet, dass danach schon alles fertig läuft. Ein Stück Software zu schreiben, auch wenn es nur ein sehr kleines Stück ist, erfordert viele Durchläufe des TDD-Zyklus.

Wie kann ich mir das jetzt vorstellen? Nun, das erste Testtool, das uns zur Verfügung steht, ist der Compiler. In den meisten modernen IDEs ist der bereits fest eingebunden und läuft im Hintergrund los, sobald wir Code eingeben. Und gibt uns umgehend Feedback darüber, ob wir zumindest aus Sicht des Compilers lauffähigen Sourcecode erzeugt haben oder nicht.

Nehmen wir an, wir wollen in Java z.B. mit Eclipse eine Klasse Rechner und in dieser eine Methode addieren erstellen.

Als erstes generieren wir z.B. eine JUnit Testklasse TestRechner und in dieser den Testfall TestAddierenEinfach. Und in diesem Testfall erzeugen wir uns eine Instanz von Rechner mit

Dumm nur, dass es die Klasse Rechner noch nicht gibt und der Compiler uns dementsprechend Feedback gibt. Das ist unser erster Testlauf und er schlägt fehl. Also implementieren wir jetzt so lange, bis der Test durchläuft, der Compiler zufrieden ist. Bedeutet in diesem Fall, wir implementieren eine leere Klasse Rechner. Das können wir bequem von der IDE erledigen lassen und bekommen dann zum Beispiel dieses hier als Ergebnis:

Zu refakturieren gibt es hier noch nicht viel, also ist der erste Durchlauf durch den Zyklus erledigt. Problemlos innerhalb von 90 Sekunden. Zugegeben, viel bekommen haben wir noch nicht. Aber jetzt geht es ja weiter.

Nun wollen im Test die Methode addieren mit den ganzen Zahlen 3 und 5 aufrufen und das Ergebnis in einer Variablen aufnehmen.

Auch hier bekommen wir unverzüglich Feedback vom Compiler, unserem ersten Testtool, er kennt die Methode addieren nicht. Also tun wir ihm den Gefallen und erzeugen sie, und am besten überlassen wir auch das wieder der IDE.

Der Compiler ist glücklich und der Testlauf damit bestanden, allerdings hätten wir diesmal durchaus ein paar Punkte, die wir bezüglich Lesbarkeit und Wartbarkeit verbessern können. Zum Beispiel ist die Benennung der Parameter in der Implementierung nicht so toll und wir verändern sie entsprechend:

Und auch im Testfall wollen wir vielleicht die konkrete Festlegung der Testwerte aus dem eigentlichen Aufruf herausziehen:

Schon sieht das Ganze deutlich zukunftsträchtiger aus. Wenn wir uns an die AAA-Regel erinnern, wir haben nun Arrange und Act, fehlt noch Assert:

Da der Compiler in diesem Fall nichts zu bemängeln hat, besteht der Test ab jetzt auch darin, den JUnit Test laufen zu lassen. Und der schlägt nun natürlich fehl, weil unsere aktuelle Implementierung stur 0 zurückgibt. Also implementieren wir nun soweit, dass unser Test grün läuft. In diesem Beispiel ist das ziemlich einfach:

Test neu laufen lassen und nun läuft er erfolgreich durch. Jetzt noch wieder den letzten Schritt des TDD-Zyklus, das Aufräumen. Die Implementierung sieht ok für uns aus, allerdings am Testfall ist noch was zu verbessern. Ähnlich wie bei den Summanden kann auch der Vergleichswert der Summe, der im Assert verwendet wird, in eine eigene Variable ausgelagert werden:

Wir haben jetzt in kurzen Zyklen eine Methode geschrieben, bei der wir jederzeit wiederholbar beweisen können, dass sie korrekt 3 und 5 addieren kann. Jetzt können wir in weiteren Zyklen erst mal sicherstellen, dass andere gültige Konstellationen funktionieren. Oder prüfen, wie die aktuelle Methode mit extremen Eingabewerten umgeht und das Verhalten der Methode dann entsprechend erweitern. Was passiert zum Beispiel, wenn wir 2147483647 und 1 addieren wollen. Das übersteigt den Wertebereich von int und wird zu unerwünschten Ergebnissen führen. Was uns der Test schnell zeigt und uns die Möglichkeit gibt, dass zu lösen.

Das war jetzt kein besonders schwieriges Beispiel, es zeigt jedoch sehr gut, wie in sehr kurzen Zyklen testgetrieben eine Lösung entwickelt werden kann. Es wird deutlich, dass jeder dieser Schritte mit etwas Übung innerhalb von 90 Sekunden realisiert werden kann.

Jetzt könnten wir allerdings mit diesem Verfahren fast unbegrenzt lange fortfahren und erst nach Stunden den ersten wirklich lauffähigen Test vorweisen. Was aber auch nicht der Sinn der Sache ist, denn erst wenn wir erste wirklich lauffähige Tests haben, sehen wir, dass wir auch etwas mit Wert schaffen. Also ergänzen wir unsere 90 Sekundenregel noch um eine 10 Minutenregel. Ziel ist, innerhalb von maximal 10 Minuten einen ersten/weiteren lauffähigen Test zu haben. Oder anders formuliert, wir wollen innerhalb von 10 Minuten einen durch Tests abgesicherten Mehrwert schaffen.

Damit sind wir wieder beim Fokus auf kleine Einheiten mit simplen Lösungen.

Wir sind jetzt soweit, dass wir durch Unit Test getrieben unsere Software schreiben. Oder zumindest die vielen kleinen technischen Komponenten. Das ist schon super. Aber ein Softwareprodukt besteht aus mehr nur kleinen technischen Komponenten, es besteht auch aus mehr oder weniger großen Zusammenhängen. Und genauso besteht eine gute Testabdeckung aus mehr als nur Unit Tests.

Schritt Sechs: Die Testpyramide aufbauen

Die drängende Frage lautet nun also: Kann ich mit Test Driven Development jetzt also nur Unit Tests schreiben? Das wäre ja nicht so günstig, denn wir wollen ja nicht nur die einzelnen, voneinander unabhängigen Aspekte unserer Komponenten testen, wir wollen auch sicherstellen, dass alles korrekt zusammen funktioniert.

Auch das kann ich testgetrieben machen. Nachdem ich z.B. durch Unit Tests getrieben zwei kleine Aspekte implementiert habe, schreibe ich einen Test, der das Zusammenspiel der beiden Aspekte testet. Anschließend implementiere ich dieses Zusammenspiel. Zu beachten ist dabei, dass ich in diesem ‚Integrationstest‘ jetzt nicht mehr die grundsätzliche Funktion der jeweiligen einzelnen Units testen muss, sondern wirklich nur noch das Zusammenspiel.

Auf diese Art und Weise können wir uns nun die Testpyramide hocharbeiten. Wie bei einer echten Pyramide legen wir immer erst unten Steine hin, bevor wir die Steine der nächsten Ebene setzen. Das Bedeutet im Bereich des Testens von Software:

Erst ein paar Unit Tests
dann die Modultests, die die getesteten Units verbinden
dann die Komponententests, die z.B. die bereits getesteten Module verbinden
dann evtl. schon der Integrationstest, bei dem unser bereits erstelltes und bis dorthin getestetes Stück Software jetzt mit Drittsystemkomponenten zusammen getestet wird
und dann weiter bis hin zum End-to-End-Test oder Akzeptanztest.

Dabei haben wir jetzt mit Ausnahme des Unit Tests die Begriffe der Teststufen nach unserem Ermessen gewählt.

Wie die jeweiligen Teststufen in Ihrem Unternehmen benannt werden, ist auch weiterhin Ihre Entscheidung.

Nur zur Wiederholung nochmal: Auch bei den Teststufen oberhalb der Unit Tests schreiben wir immer zuerst den Test und erst dann Implementieren wir den Sourcecode, der bereits getestete Einheiten zu einem größeren Ganzen zusammenfügt.

Ein einfaches Beispiel: Wir haben testgetrieben bereits eine sum Methode geschrieben, die zwei ganze Zahlen entgegennimmt und diese aufaddiert zurückgibt. Durch Unit Tests haben wir ausgiebig sichergestellt, dass das auch funktioniert. Auch haben wir bereits eine checksum Methode geschrieben, der wir eine ganze Zahl übergeben können und von dieser die Quersumme zurückbekommen. Auch das ist hinreichend durch Unit Tests sichergestellt. Nun wollen wir einen Handler schreiben, der zwei ganze Zahlen übergeben bekommt, sich diese durch die bereits vorhandenen Methode sum aufaddieren und das Ergebnis davon von checksum bearbeiten lässt.

Alles, was der Handler braucht, um sicherzustellen, dass er auch wirklich zwei ganze Zahlen bekommen hat, stellen wir durch Unit Tests sicher, denn das ist vermutlich eine neu zu erstellende Funktionalität. Wenn wir jetzt jedoch die Tests für den Ablauf „zwei ganze Zahlen durch sum aufaddieren und dann durch checksum bearbeiten lassen“ schreiben, dann müssen wir nun nicht mehr in diesem Test sicherstellen, dass sum oder checksum wirklich mit allen möglichen Eingaben klarkommen und die Ergebnisse wirklich stimmen. Das haben wir bereits in den entsprechenden Unit Tests sichergestellt.

Der Prozess des Test Driven Development führt uns auf diese Art von unten nach oben durch die verschiedenen Testebenen und wir wissen das wir mit dem Entwickeln fertig sind, wenn wir die Tests auf der obersten Ebene geschrieben haben und diese erfolgreich durchlaufen.

Warum nennen wir das Testpyramide, das sieht doch in der Abbildung oben gar nicht aus wie eine Pyramide? Dem können wir abhelfen.

In der ersten Abbildung haben wir den Scope der einzelnen Tests auf den verschiedenen Testebenen abgebildet. In der zweiten Graphik zeigen wir die typische Verteilung der Menge an Tests, die bei einer sauber umgesetzten Teststruktur entsteht.

Was auffällt ist, dass die Menge an Tests/Testfällen von unten nach oben hin abnimmt. Das ist das Ergebnis daraus, dass wir schon auf der Ebene der Unit Tests einen Großteil der Funktionalität mit Tests abdecken und dann von Ebene zu Ebene quasi nur noch den Mehrwert testen, der aus der Kombination kleinerer Einheiten entsteht.

Das hat direkt mehrere Vorteile:

a. Da jeder Test nur noch einen begrenzten Scope hat, den es an Funktionalität wirklich sicherzustellen hat, sind alles Tests relativ klein, leicht verständlich und gut wartbar

b. Je weiter oben in der Testhierarchie ein Test steht, umso schwieriger und aufwändiger ist es, Funktionalität weiter unten im System zu testen. Das ist das typische Problem von Black Box Tests. Je weiter unten in der Testhierarchie wir einen Test schreiben, umso einfacher ist es eine bestimmte technische Funktionalität testen zu können. Wir bewegen uns im Bereich der White Box Tests. Durch den Aufbau einer sauberen Testpyramide reduzieren oder vermeiden wir es sogar komplett die Notwendigkeit, von höheren Testebenen aus technische Detailfunktionen testen zu müssen, Tests auf höheren Ebenen sind damit einfacher (siehe Punkt a.)

c. Wenn zu einem späteren Zeitpunkt sich Verhalten im System unerwünscht ändert, also ein Fehler auftritt, dann zeigen uns die fehlschlagenden Tests in der Testpyramide konkret, an welcher Stelle das Verhalten des Systems nicht mehr stimmt. Bei der Fehleranalyse und Fehlerbehebung fangen wir dann immer mit den fehlschlagenden Tests auf der niedrigsten Ebene an. Die Fehleranalyse und Fehlerbehebung werden dadurch deutlich beschleunigt.

Diese Verteilung der Testfälle wird einige etwas überraschen, weil es sich nicht mit ihrer Erfahrung deckt. In vielen Unternehmen besteht die große Menge an Tests aus GUI-, Integrations- und Akzeptanztests. Und je weiter nach unten man in der Testhierarchie schaut, umso weniger Testfälle werden es. Wir reden hier auch von der sogenannten Eistüte.

Was in diesem Modell viele Projekte an die Grenzen oder sogar darüber hinausbringt ist, dass sehr viel auch der fundamentalsten technischen Basisfunktionalitäten über die oberste der Testebenen abgesichert werden muss. Wie wir gerade besprochen haben, ist genau das der ungünstigste, weil schwierigste und damit zeitaufwändigste Ort dafür. Die Konsequenz ist oft eine unzureichende Testabdeckung, weil das Schreiben dieser Tests in der notwendigen Menge zu aufwändig ist.

Nutzen Sie also lieber TDD und formen Sie Ihre Eistüte in eine Pyramide um.

Fazit

Richtig verstanden und angewendet ist TDD ein sehr mächtiges Vorgehensmodell, um funktionierende Software auf einem sehr hohen Qualitätsniveau zu erstellen. Allerdings stellt TDD keine Abkürzung dar, mit der man mal so auf die Schnelle ein Stück Software aus dem Boden stanzen kann und dann läuft es schon. TDD setzt voraus, das von Anfang an kompromisslos auf Qualität gesetzt und damit die dafür notwendige Zeit investiert wird. Im Nachhinein kann auch TDD die Qualität einer Software nicht mehr retten.

„Qualität ist nicht verhandelbar“

Den einen oder anderen Entscheider mag diese konsequente Investition in Qualität erst mal erschrecken, weil damit Quick-n-Dirty Schnellschüsse nicht mehr möglich sind. Aber sobald Sie TDD erst mal wirklich in Ihrem Unternehmen eingesetzt haben, werden Sie schnell merken, dass sich diese Investition doppelt und dreifach rechnet.

Was wir bekommen, ist eine Software, bei der von Anfang an die Funktionsfähigkeit bewiesen ist und die aufgrund des ständigen Refactorings während des Entwicklungsprozesses und der hohen Abdeckung durch automatisierte Tests jederzeit problemlos gewartet und weiterentwickelt werden kann.

Damit Sie allerdings das Beste aus TDD herausholen können, ist neben der guten Absicht auch eine gute Ausbildung Ihrer Softwareentwickler nicht nur im Umgang mit TDD, sondern auch in den Prinzipien guten Softwaredesigns sinnvoll.

Investieren Sie hier, um auch in Zukunft hervorragende Produkte zu bauen.

The post Test Driven Development in sechs einfachen Schritten appeared first on Binaris Informatik.

Schrödingers Katze im Projektmanagement

Carsten Czeczine — Mon, 24 Apr 2023 09:46:49 +0000

… oder, wie geht es eigentlich meinem Projekt?

Wenn wir ein großes Projekt durchführen wollen, dann wissen wir, dass es zu Abweichungen vom Projektplan kommen kann. Und niemand von uns mag es, erst am Ende des Projektes diese Abweichungen zu entdecken oder festzustellen, dass das Projekt ein Fehlschlag war. Deutlich angenehmer ist es für uns, von diesen Abweichungen früher zu erfahren, denn dann können wir darauf reagieren und das Projekt immer noch zum Erfolg führen. Diese Erkenntnis ist nun nicht neu im Projektmanagement und Generationen von Projektmanagern vor uns haben sich schon mit der Fortschrittskontrolle von Projekten beschäftig und dafür entsprechende Instrumente entwickelt. Und dennoch werden in vielen Projekten gravierende Probleme und Hindernisse erst in der Schlussphase entdeckt und führen dann oft zum Scheitern des Projektes oder zu unerwarteten Verzögerungen. Wie kann das sein?

1935 schlug der Physiker Erwin Schrödinger ein faszinierendes Gedankenexperiment vor. In eine undurchsichtige Stahlkammer wird eine Katze zusammen mit einer winzigen Menge einer radioaktiven Substanz, einem Geiger‘schen Zählrohr und einem Kolben Blausäure eingesperrt. Bei der radioaktiven Substanz besteht eine 50 prozentige Chance, dass innerhalb einer Stunde eines der Atome zerfällt, was von dem Geiger‘schen Zählrohr gemessen werden kann. Und in diesem Falle würde das Zertrümmern des Kolbens mit der Blausäure durch einen Hammer auslösen werden mit dem Ergebnis, dass die Katze stirbt.

Dann wird eine Stunde gewartet und erst nach Ablauf dieser Stunde nachgesehen, ob die Katze noch lebt oder Tod ist.

Da nur eine 50 prozentige Chance besteht, dass eines der Atome zerfällt, existiert die Katze in der Wahrnehmung der Außenwelt in dieser Stunde gleichzeitig in zwei sich wiedersprechenden Zuständen:

Sie ist tot
und sie ist lebendig (und vermutlich ziemlich verärgert).

Erst wenn wir nach Ablauf der Stunde die Stahlkammer öffnen und nachsehen, wird einer der beiden Zustände real und der andere verliert seine Bedeutung. Die Quantenphysiker sagen wir auch, mit der Messung kollabiert das System der überlagernden Zustände.

Was hat das nun mit Projektmanagement zu tun?

Bei der Durchführung von Projekten werden wir sehr oft mit Faktoren konfrontiert, die im Vorfeld nicht bekannt oder nicht genau vorhersagbar waren. Um derartige Projekte dennoch erfolgreich durchführen zu können ist der Einsatz von sinnvollem Projektcontrolling und erfolgreicher Projektsteuerung notwendig. Beides lebt davon, den aktuellen Zustand eines Projektes korrekt ermitteln zu können. Und hier fängt nun oft das Problem an. Die Wurzel unseres Problems liegt oft in der Art, wie wir klassisch Projekte planen.

Bevor wir mit der Umsetzung anfangen:

Sammeln wir alle Anforderungen an das zu erstellende Ergebnis
Erstellen wir daraus ein detailliertes fachliches Konzept
Erzeugen wir basierend auf dem fachlichen Konzept ein detailliertes und vollständiges technisches Konzept
Leiten wir aus dem technischen Konzept alle notwendigen Tätigkeiten ab
Erstellen wir den Projektplan, der genau festlegt, wer bis wann was tun wird

Das Ergebnis ist quasi die vollständige Beschreibung des Lösungswegs. Die Fortschrittskontrolle findet dann oft als Abgleich zwischen Tätigkeiten, die bis jetzt hätten fertig sein sollen und Tätigkeiten, die bis jetzt tatsächlich geleistet wurden statt. Wir messen den Projektfortschritt also auf der Basis geleisteter Arbeit verglichen mit geplanter Arbeit. Klingt erst mal logisch.

Der Irrtum dieses Verfahrens liegt in der Annahme, dass der Projektplan vollständig und seine Umsetzung fehlerfrei ist. Und wird damit daraus geschlussfolgert, dass das Befolgen des Projektplans automatisch zum gewünschten Projektergebnis führen muss.

Um herauszufinden, ob der Projektplan tatsächlich vollständig war und wir mit ihm damit auch das vollständige und Funktionierende Ergebnis erzeugt haben, dass gewünscht war, ist jedoch nur durch eine realistische Überprüfung genau dieser Ergebnisse möglich. In der klassischen Projektplanung findet dies zumeist erst zum Ende des Projektes statt und da kann das Erwachen dann sehr schmerzhaft sein. Wir finden dann erst in der Schlussphase des Projektes heraus, dass das Produkt eventuell nicht fertig ist oder nicht funktioniert. Und das, obwohl doch alle geplanten Tätigkeiten durchgeführt wurden. Jetzt noch das Projekt innerhalb von Time und Budget zu retten, ist schier unmöglich.

Der Grund für diese späte Erkenntnis ist, dass wir das Falsche messen. Wir messen die Menge an geleisteter Arbeit und vergleichen das mit der Menge an Arbeit, von der wir glauben, dass sie notwendig ist. Was wir nicht messen, ist das erzielte Ergebnis. Und mit Ergebnis meine ich das, was uns wirklich interessiert: Das fertige, funktionsfähige und benutzbare Produkt[JH9]. Dadurch, dass wir in diesem Szenario nur die Ausführung der Aufgaben, aber nicht den Zustand des Ergebnisses überprüfen, verbleibt unser Projekt während seiner Laufzeit trotz einer regelmäßigen scheinbaren Messung in einem überlagerten Zustand: Es ist gleichzeitig ein voller Erfolg (wir führen erfolgreich die geplanten Aufgaben durch) und ein totaler Misserfolg (wir wissen nicht, ob am Ende des gewünschte Ergebnis herauskommen wird). Im Bild von Schrödingers Katze wäre das so, als würden wir den Zustand der Katze rein durch das Verstreichen der Zeit bestimmen wollen, ohne dabei die Tür der Stahlkammer zu öffnen.

Wenn wir ein Projekt realistisch bewerten wollen, dann stellt sich zuerst die Frage nach dem erzielten Ergebnis, also was kann das erzeugte Produkt. Dicht gefolgt von der Frage nach den Kosten. Niemand wird uns aufrichtig für unseren unermüdlichen Arbeitseinsatz und die vielen geleisteten Stunden danken, wenn das Ergebnis nicht stimmt. Was unsere Kunden an erster Stelle interessiert ist, ob das Produkt fertig ist, wie gewünscht funktioniert und was es gekostet hat!

Wie können wir dieses Problem der falschen Fortschrittsmessung lösen? Nur indem wir in kurzen Abständen die Tür zur Stahlkammer öffnen und uns vom tatsächlichen Zustand der Katze überzeugen. Wir lassen das System der überlagernden Zustände durch die konkrete Messung kollabieren. Im Projektmanagement bedeutet das, dass wir uns in kurzen Abständen die tatsächlich erzielten Ergebnisse ansehen.

Das agile Framework Scrum zeigt, wie das funktionieren kann. In Scrum werden innerhalb kurzer Iterationen von maximal vier Wochen Länge sogenannte benutzbare Produktinkremente erzeugt. Das bedeutet, es werden immer vollständige Funktionalitäten erstellt, und zwar in finaler Marktqualität. Finale Marktqualität meint in diesem Kontext, dass innerhalb der Iteration alle notwendigen Tätigkeiten durchgeführt werden, um diese Funktionalität ausliefern zu können. Bei den meisten Softwareprodukten würde das z.B. das vollständige Testen, Vorbereitung von Build und Deployment und die Erstellung von Dokumentation mit einschließen. Das Ziel ist, dass eine Funktionalität am Ende einer Iteration wirklich fertig ist und keine versteckten Restaufwände mehr für diese Funktionalität existieren. Welche Ansprüche genau ein Produktinkrement erfüllen muss, damit es als benutzbar gilt, definieren wir in einer sogenannten Definition of Done.

Was sind jetzt versteckte Restaufwände? Versteckte Restaufwände sind alle die Tätigkeiten, die wir ungeplant zu einem späteren Zeitpunkt durchführen müssen, damit die Funktion wirklich produktiv funktioniert. Wir stellen zum Beispiel in der Test- oder Abnahmephase unseres Projektes fest, das eine Funktionalität nicht ordnungsgemäß funktioniert. Oder in unseren Entwicklungs- und Testumgebungen hat sie funktioniert, aber nach dem Deployment in der produktiven Endumgebung tut sie es nicht mehr. Und jetzt müssen wir das natürlich nachbessern. Für Nachbesserungen in der Test- oder Abnahmephase hatten wir initial vielleicht noch genügend Puffer eingeplant, sodass es noch passt. Vielleicht aber auch nicht. Bei Nachbesserungen in der produktiven Endumgebung liegen wir eindeutig außerhalb des Plans. Diese zusätzlichen Aufwände, die so nicht geplant waren sind es, was uns am Ende eines Projektes die Kopfschmerzen bereiten.

Wenn wir mit Scrum arbeiten. dann bewerten wir am Ende jeder Iteration, welche Funktionalitäten wirklich fertig sind und welche nicht. Wir bekommen damit einen realistischen Überblick über den Zustand unseres Projektes und eine realistische Information darüber, wie schnell wir tatsächlich sind.

Auf diese neue Art der Bewertung umzusteigen führt in vielen Projekten jedoch erst mal zur Ernüchterung. Plötzlich liegt Schwarz auf Weiß der Nachweis vor, dass die ursprünglichen Erwartungen mehr oder weniger zu optimistisch waren. Dieses Phänomen ist so normal, dass es sogar in der Psychologie Beachtung gefunden hat und dort als planning fallacy beschrieben wird. Gerne wird nun die überraschend geringe Entwicklungsgeschwindigkeit erst Mal dem Mehraufwand durch das direkte Testen zugeschrieben. Ich habe dann leider schon mehrmals erlebt, dass dann als Reaktion darauf das direkte Testen gestrichen und die Überprüfung wieder auf eine spätere Testphase verschoben wird. Denn gefühlt scheint es wichtiger zu sein, erst Mal möglichst viele Funktionalitäten zu erstellen und das gebündelte Testen und Korrigieren in dieser Phase wäre dann effizienter. Doch das ist purer Selbstbetrug. Den Aufwand zum Testen und Nachbessern müssen Sie so oder so betreiben. Je weiter Sie ihn aber nach hinten verschieben, desto mehr erhöhen Sie das Risiko eines Projektfehlschlages, da Sie nicht abschätzen können, wieviel Aufwand Testen und Korrigieren bedeuten wird und Ihnen damit möglicherweise am Ende die Zeit davonläuft, ein funktionierendes Produkt vorweisen zu können. Im schlimmsten Fall haben Sie am Ende ihres Budgets zwar viele Funktionalitäten erstellt, aber keine davon funktioniert wie gewünscht.

Wenn wir das Risiko in Projekten reduzieren wollen, dann müssen wir uns auftretenden Problemen stellen, sobald sie auftreten. Meine Lieblingsfrage, die ich Projekt- und Produktmanagern immer wieder gerne stelle, ist: „Wann möchten Sie wissen, dass Sie ein Problem in Ihrem Projekt haben?“ Und die für mich einzige sinnvolle Antwort darauf lautet: „So früh wie möglich!“

Je früher wir im Projekt wissen, dass wir ein Problem haben, umso mehr Optionen haben wir noch, dieses Problem zu lösen und das Projekt so erfolgreich zu Ende zu führen.

„Ja, aber bei uns ist es nicht möglich innerhalb von vier Wochen eine ganze Funktionalität zu realisieren“. Ist das wirklich so? In der Tat gibt es sehr vereinzelte Themenkomplexe, in denen Kernfunktionalitäten nicht so weit reduzierbar oder sinnvoll zerlegbar sind, dass sie innerhalb von vier Wochen umgesetzt werden können. Aber das ist bei weitem nicht so oft der Fall, wie es uns viele Projektmanager oder Produktverantwortliche glauben machen wollen. Denken Sie selbst mal darüber nach, könnte es genau diese Sichtweise von zu großen Funktionalitäten sein, die die Entwicklung Ihrer Produkte so komplex und herausfordernd macht?

Ein anderer gerne genommener Einwand ist: „Wir können nicht innerhalb von vier Wochen etwas entwickeln und vollständig testen. Unsere Tests sind dafür viel zu aufwendig.“

Hier müssen wir genau hinsehen, worin das Problem besteht. Ja, in einigen Kontexten sind die Tests und anderen Abnahmeverfahren aufgrund der Thematik ans sich tatsächlich, selbst bei bester Organisation, nicht in einem derart kurzen Zeitraum machbar. In den meisten Fällen liegt die Ursache für das Problem jedoch in der Struktur und Arbeitsweise der Organisation und nicht in der Thematik an sich. Vor allem in der Softwareentwicklung gibt es inzwischen eine Reihe von Ansätzen, über die das Testen deutlich leichtgewichtiger wird. Diese Ansätze setzen jedoch entsprechende Schulungen und oft auch Investitionen in Infrastruktur voraus und haben meistens auch Einfluss auf das Design der Lösungen, die in den Projekten entwickelt werden. In späteren Artikeln werden wir auf ein paar dieser Ansätze eingehen.

Es ist also in der Regel schon machbar, allerdings bedeutet es in vielen Fällen Investitionen in Knowhow und Infrastruktur und die Bereitschaft, alte Sichtweisen über Bord zu werfen.

Was wir also sehen ist, dass es für die Umstellung von Projekten auf ein realistischen Bewertungs- und Messverfahren in kurzen Intervallen nicht einfach mit dem Beschluss getan ist, sich alle vier Wochen die Ergebnisse ansehen zu wollen. Tatsächlich ist es dazu notwendig, den gesamten Prozess, wie Produkte und Projekte geplant, entwickelt und getestet werden unter die Lupe zu nehmen und auf das Ziel der stückweisen Abnahme in kleinen Inkrementen umzustellen. Eine Anstrengung, die sich jedoch immer lohnt, denn sie führt zu einem Unternehmen, das zukünftig in kürzerer Zeit die besseren Produkte in besserer Qualität entwickeln wird. Überlassen wir also Schrödingers Katze den Physikern und arbeiten lieber mit eindeutigen Zuständen.

In der Quantenphysik dient Schrödingers Katze als Parabel, um den quantenmechanischen Effekt der Zustandsüberlagerung zu veranschaulichen und führt dort zu neuen Erklärungsversuchen unserer Welt oder so faszinierenden Ideen, wie der Theorie unendlich vieler paralleler Universen. Im Projektmanagement dahingegen führt Schrödingers Katze zu Kopfschmerzen und zu manchmal scheinbar unendlicher Frustration.

Hier lässt sich Schrödingers Katze übrigens auch gut mit einer alten Weisheit der Dakota-Indianer kombinieren: Wenn dein Pferd tot ist, steig ab!

Diese Weisheit wird gerne im Kontext des Projektmanagements zitiert, um klarzumachen, dass gescheiterte Projekte losgelassen werden sollen. Aber wie wir oben schon gesehen haben, scheitern viele an der Frage, ob das Pferd denn wirklich schon tot ist.

So gesehen leiden viele Projekte sogar an Schrödingers Pferd!

The post Schrödingers Katze im Projektmanagement appeared first on Binaris Informatik.

Das Kano-Modell der Kundenzufriedenheit

Carsten Czeczine — Thu, 13 Apr 2023 09:44:36 +0000

In dem Artikel Prioritäten von Anforderungen – Kategorie oder Reihenfolge hatte ich mehrfach Bezug auf das Kano-Modell der Kundenzufriedenheit genommen, ohne dieses dabei näher zu erklären. In diesem Artikel holen wir das nach.

Die meisten von uns, die sich mit Produkt- oder Anforderungsmanagement auseinandersetzen, kennen das folgende Problem der Entscheidung: In welcher Reihenfolge sind Anforderungen umzusetzen bzw. welche sind überhaupt umzusetzen? Selten mangelt es an Anforderungen an das, was ein zu erstellendes Produkt alles können soll. Unzählige Interessenvertreter haben ihre eigenen Vorstellungen davon, was absolut unverzichtbar ist und damit auf jeden Fall umgesetzt werden muss. Und zwar immer als allererstes!

Das Kano-Modell versucht hierbei Licht ins Dunkel zu bringen und dem Entscheider ein Werkzeug an die Hand zu geben, um in diesem Wirrwarr die Streu vom Weizen zu trennen. Dadurch wird eine nachvollziehbare Grundlage für die Entscheidungen geschaffen, was umgesetzt wird und was eher nicht und in welcher Reihenfolge.

Damit ist jedoch auch klar, was das Kano-Modell nicht macht: Es unterstützt nicht bei der Erhebung der Anforderungen. Um diesen Pool an Anforderungen zu generieren, müssen vorher andere Techniken verwendet werden, auf die wir in diesem Artikel jedoch nicht eingehen wollen. Zur Entstehung des Modells möchte ich mich an dieser Stelle darauf beschränken, dass das Kano-Modell auf Prof. Dr. Noriaki Kano von der Universität Tokio zurückgeht.

Bevor wir in die Details des Kano-Modells einsteigen, klären wir erst noch kurz drei Definitionen.

Als erstes müssen wir festhalten, dass im Kano-Modell nicht von Anforderungen, sondern von Produktmerkmalen gesprochen wird. Anforderungen sollten sich in der Regel auf Produktmerkmale beziehen, d.h. sie „fordern an“, dass das Produkt ein bestimmtes Merkmal aufweist bzw. nicht aufweist. Ein Produktmerkmal selbst ist eine für den Kunden spürbare Eigenschaft des Produkts, also z.B., dass er sich anmelden kann. Und unter Kunden verstehen wir hier den Personenkreis, der mit unserem neuen Produkt umgehen muss bzw. es kaufen soll.

Kommen wir jetzt zum Kano-Modell. Dort werden Produktmerkmale in fünf Kategorien aufgeteilt:

Basis-/Must-Have Merkmal: Basismerkmale eines Produktes sind so grundlegend und selbstverständlich, dass sie dem Kunden erst bei Nichterfüllung bewusst werden. Werden sie aber nicht erfüllt, dann entsteht eine starke Unzufriedenheit. Umgekehrt entsteht aber bei Erfüllung nicht wirkliche Zufriedenheit. Ein Beispiel hierfür kann die Möglichkeit zur Anmeldung in einer Software sein.
Lineares-/Leistungsmerkmal: Lineare Merkmale sind dem Kunden durchaus bewusst und sie beseitigen Unzufriedenheit oder schaffen Zufriedenheit abhängig vom Ausmaß der Erfüllung. Die Bereitstellung linearer Merkmale wird von Kunden also bewusst mit Zufriedenheit belohnt. Ein Beispiel hierfür ist die Reaktionsgeschwindigkeit eines Softwareprodukts.
Begeisterungsmerkmal: Begeisterungsmerkmal sind Nutzen stiftende Merkmale, mit denen der Kunde nicht unbedingt rechnet, also Merkmale, die dem Kunden einen überraschenden Mehrwert liefern. Sie zeichnen das Produkt gegenüber der Konkurrenz aus und rufen damit oft Begeisterung hervor. Eine kleine Leistungssteigerung kann zu einer überproportionalen Nutzenstiftung führen. Die Differenzierungen gegenüber der Konkurrenz können gering sein, die Nutzenstiftung aber dennoch enorm.
Unerhebliches Merkmal: Sind sowohl bei Vorhandensein wie auch beim Fehlen ohne Belang für den Kunden. Sie können daher keine Zufriedenheit stiften, führen aber auch beim Fehlen nicht zu Unzufriedenheit.
Rückweisungsmerkmal: Rückweisungsmerkmale führen beim Vorhandensein zu Unzufriedenheit, beim Fehlen jedoch nicht zu Zufriedenheit. Rückweisungsmerkmale sind häufig Merkmale, die nicht dem Kunden, sondern dem Hersteller oder Produktanbieter nutzen. Ein Beispiel hierfür wäre ein Kopierschutz oder das Sammeln von Kundendaten für Marketingzwecke.

Soweit so gut, wir habe jetzt also auf der einen Seite 5 Kategorien und auf der anderen eine große Liste voll mit Anforderungen. Aber wie ordne ich jetzt meine Anforderungen in diese fünf Kategorien ein?

Eine Möglichkeit wäre, dass ich als der Produktverantwortliche dieses anhand der Beschreibungen oben jetzt selbst mache. Dafür muss ich aber die zukünftigen Kunden und deren Bedürfnisse schon ziemlich genau kennen. Und die Wahrscheinlichkeit, dass ich dabei des Öfteren mal danebenliege, dürfte recht hoch sein.

Besser also, ich frage die potenziellen Kunden selbst, und zwar möglichst viele davon. Allerdings stellt sich auch hier die Frage, nach welchen Kriterien eine Anforderung einer der fünf Kategorien zuzuordnen ist. Die Beschreibungen oben sind verhältnismäßig dürftig und könnten von jedem etwas anders verstanden werden. Dadurch wird die Aufgabe der Zuordnung schnell eine recht anspruchsvolle und komplexe Tätigkeit.

Deshalb geht das Kano-Modell einen anderen Weg, den einer bipolaren Befragung. Jede:r Proband:in wird zu jedem Merkmal jeweils mit einer funktionalen und einer dysfunktionalen Frage konfrontiert. Oder verständlicher ausgedrückt: Er:sie soll zu jedem Merkmal mitteilen, wie er:sie es fände, wenn:

es vorhanden ist
wenn es fehlt

Als Antwortmöglichkeiten stehen ihr:m für beide Fragen zur Verfügung:

Ich mag es genau so
Ich erwarte, dass es so ist
Mir egal
Ich kann damit leben
Das stört mich

Super, jetzt habe ich pro Merkmal sogar zwei Antworten von einem Probanden, wie soll ich denn daraus jetzt zu meiner Kategorie kommen? Hier kommt die Magie des Kano-Modells ins Spiel, und zwar in Form der Antworten-Kategorien-Matrix.

Wir finden in dieser Matrix in den Schnittpunkten der möglichen Antworten auf die beiden Fragen alle unsere fünf Kategorien wieder plus zweimal eine unlogische Kombination. Bei den beiden unlogischen Antwortkonstellationen hat möglicherweise der:die Proband:in die Fragestellungen nicht richtig verstanden. Entweder ignorieren wir das oder, wenn wir die Möglichkeit dazu haben, wir stellen die Frage nochmal und achten dabei auf das Verständnis der Fragestellungen.

Aus den Antworten auf die beiden Fragen einer:s Probanden:in kann nun die Kategorie einfach abgelesen werden. Jetzt befragen wir natürlich nicht nur einen Kunden, sondern pro Produktmerkmal fragen wir möglichst viele potenzielle Kunden und halten das Ergebnis in einer Tabelle fest. In der Tabelle unten habe ich ein Beispiel dafür erstellt.

Wir haben drei Merkmale befragt und die Verteilung der Zielkategorien der einzelnen Befragungen prozentual in einer Tabelle zusammengefasst.

Bei dem Produktmerkmal 1 haben wir mit 43,8% eine eindeutige Spitze für lineares Merkmal, bei dem Produktmerkmal 2 mit 54,3% eine eindeutige Spitze für Basismerkmal. Beim Produktmerkmal 3 jedoch haben wir zwei Spitzen, einmal 36,6% für Basismerkmal und dann nochmal 39,1% für Begeisterungsmerkmal.

Dies kann darauf hindeuten, dass wir vielleicht zwei unterschiedliche Arten von Kunden für unser Produkt haben, die unterschiedliche Erwartung an unser Produkt hegen. Sinnvollerweise analysieren wir in diesem Fall, welche unterschiedlichen Kundenarten das sind und legen anschließend fest, auf welche von beiden Kundenarten wir den Fokus legen wollen.

Kommen wir zurück zu unserer Ausgangssituation: Wir sind ein armer Produktverantwortlicher und alle Interessenvertreter haben uns mit Unmengen an Anforderungen zugeschüttet. Wir haben aus (fast) all diesen Anforderungen Produktmerkmale extrahiert und diese durch das Kano-Modell in Kategorien eingeordnet.

Ist damit jetzt klar, welche Anforderungen bzw. Produktmerkmale umzusetzen sind und in welcher Reihenfolge?

Leider nicht so ganz. Fangen wir mit den einfachen Fällen an: Die Rückweisungsmerkmale und die unerheblichen Merkmale.

Das Kano-Modell priorisiert Produktmerkmale aus Sicht des Kunden und aus dieser Sicht sollte auf Rückweisungsmerkmale auf jeden Fall verzichtet und unerhebliche Merkmale sollten nur am Schluss umgesetzt werden, wenn noch Zeit und Geld da ist. Obwohl sie aus dieser Sicht eigentlich nur Resourcenverschwendung sind. Also besser auch nicht umsetzen.

Allerdings bestimmen ja nicht immer nur die Kundenwünsche die Notwendigkeiten für bestimmte Produktmerkmalen. Bevor diese Merkmale also tatsächlich komplett gefeuert werden, müssen wir erst noch prüfen, was die Intention zu diesen Merkmalen war. Bei gesetzlichen Vorgaben oder technischen Notwendigkeiten kann die Welt schon ganz anders aussehen. Aber wenn nichts dergleichen zutrifft, dann raus damit und lieber ein schlankes Produkt gestalten.

Kommen wir zu unserem Dreigestirn: Basis-, lineare und Begeisterungsmerkmale.

Mit Basismerkmalen gewinnt man keinen Blumentopf, wenn sie aber fehlen, floppt wahrscheinlich das ganze Produkt. Also müssen sie wohl rein.

Wie dringend sie rein müssen, also mit welcher Priorität verglichen mit den Linearen und Begeisterungsmerkmalen, hängt davon ab, wie ich die Releases auf den Markt bringe. Wenn ich klassisch im Wasserfall arbeite und vielleicht nur alle 12 Monate ein neues Release rausbringe (oder sogar noch seltener), dann müssen alle Basismerkmale bereits im ersten Release drin sein, denn die Kunden werden das Produkt so lange nicht akzeptieren, wie die Basismerkmale nicht enthalten sind oder mit der baldigen Nachlieferung zu rechnen ist.

Wenn ich dahingegen in wesentlich kürzeren Zeitabständen meine Releases ausliefere, z.B. jeden Monat oder alle zwei und dieses auch entsprechend kommuniziere, dann sind Kunden schon eher geneigt, dass Fehlen von Basismerkmalen für kurze Zeit in Kauf zu nehmen.

Natürlich muss das, was ich ausliefere, immer in sich funktionsfähig sein, alles andere wäre ja völliger Unsinn. Aber anstatt für den gesamten geplanten Funktionsumfang des Produktes erst mal nur die Basismerkmale zu erstellen und auszuliefern und dem Kunden damit ein „ist ja ganz nett“ zu entlocken, fokussiert man nur einen bestimmten Funktionsbereich. Diesem realisieren wir mit seinen notwendigen Basismerkmalen plus weiteren linearen und Begeisterungsmerkmalen. Der Kunden gewinnt damit einen guten Eindruck dessen, was ihn nach und nach bei unserem Produkt erwarten wird und er kann evtl. auch mit der Teilfunktionalität schon Mehrwerte für sich erzielen.

Damit wäre das mit den Basismerkmalen schon mal geklärt. Aber wie gewichten wir lineare Merkmale gegenüber Begeisterungsmerkmalen?

Begeisterungsmerkmale sprechen oft ein sehr subjektives Empfinden gegenüber einem Produkt an und gewinnen in der Regel eher durch den Überraschungseffekt oder das Alleinstellungsmerkmal („das hat halt kein anderer so, deshalb ist es cool“). Beide Effekte nutzen sich aber mehr oder weniger schnell ab. Der Überraschungseffekt ebbt ab oder die Konkurrenz zieht nach.

Lineare Merkmale stellen dahingegen meist tatsächliche Wehrwerte des Produktes für den Kunden dar, die meistens auch auf Dauer erhalten bleiben. Rein ökonomisch gesehen wären deshalb die linearen Merkmale den Begeisterungsmerkmalen vorzuziehen. Unsere Kunden sind jedoch alle auch nur Menschen und die Begeisterungsmerkmale sind es, die dann doch oft die Kaufentscheidung oder die Akzeptanzbereitschaft für unser Produkt stark beeinflussen. So gesehen ist die Entscheidung für Begeisterungsmerkmale irgendwie auch ökonomisch. Zumindest für den, der das Produkt verkauft.

Im Endeffekt macht es die gesunde Mischung aus. Ein Produkt nur mit linearen Merkmalen ist zwar wertvoll, aber unsexy. Ein Produkt nur mit Begeisterungsmerkmalen verleitet zwar zum schnellen Kauf, aber nicht zur Nutzung. Ein guter Erfahrungswert ist, den Schwerpunkt auf lineare Merkmale zu setzen, damit der Kunden tatsächlich echten Mehrwert erhält und das mit einer Handvoll Begeisterungsmerkmale zu würzen, damit er sich auch für unser Produkt entscheidet bzw. die Nutzer das Produkt bereitwillig akzeptieren.

Ich hoffe, ich konnte ein bisschen Licht ins Dunkel bringen. Die Quintessenz ist, dass das Kano-Modell eine gute Unterstützung dabei anbietet, sich der Qualität von Anforderungen bewusst zu werden und sich aus der Vielzahl an Anforderungen auf die zu konzentrieren, die bei den Kunden gut ankommen werden. Es ist aber kein Mechanismus, in den ich oben einfach eine Liste an Anforderungen reinkippen kann und unten kommt dann die fertige Reihenfolge heraus. Der gesunde Menschenverstand der Produktverantwortlichen ist bei den Entscheidungen immer noch erforderlich.

Quellen:

Agile Estimating and Planning, Mike Cohn, 2006
https://de.wikipedia.org/wiki/Kano-Modell

The post Das Kano-Modell der Kundenzufriedenheit appeared first on Binaris Informatik.

Prioritäten von Anforderungen –Kategorie oder Reihenfolge?

Carsten Czeczine — Wed, 05 Apr 2023 14:25:08 +0000

Ein typisches Problem in jedem Projekt (nicht nur in der Softwareentwicklung) ist die Frage der Prioritäten der Anforderungen. Was muss zuerst erledigt werden, was geht auch später, auf was kann ggfs. ganz verzichtet werden?

Es gibt verschiedene Methoden und Verfahren, diese Wichtigkeiten der Anforderungen zu bestimmen, auf die ich heute nicht näher eingehen möchte. Heute möchten wir uns jedoch mit der Frage beschäftigen, wie diese Prioritäten anschließend festgehalten werden.

Aktuell sind mir dazu zwei Modelle geläufig:

Einteilung in feste Kategorien und
relative Priorität in Form einer Reihenfolge

Betrachten wir im ersten Schritt beide Modelle mal getrennt voneinander:

Das Modell der Kategorien

Zur Einteilung der Anforderungen wird eine Anzahl von n Kategorien definiert. Besonders beliebt sind die Kategorien Priorität 1 bis Priorität 5. Wenn sich der Prozessverantwortliche noch besonders viel Mühe gibt, dann bekommen die Kategorien auch noch so sprechende Bezeichnungen/Beschreibung wie z.B. „must have“, „nice to have“ oder auch „sehr wichtig“, „wichtig“ oder „normal“.

Dass sich mal jemand getraut hätte eine Kategorie ganz offen als „wird wohl niemals gemacht werden“ zu deklarieren, habe ich leider noch nicht erlebt. Aber richtig ehrlich wäre es. Und wenn Sie doch zu einem dieser Mutigen gehören, mailen Sie mich an, ich werde Sie in späteren Artikel lobend erwähnen.

Mittels einer geeigneten Methode (z.B. dem Kano Modell) oder oft auch dem Bauchgefühl wird nun jede Anforderung einer dieser Kategorien zugeordnet.

Der Vorteil dieses Modell ist, dass die meisten Methoden zur Priorisierung primär nur dieses Modell unterstützen (wie z.B. das schon erwähnte Kano Modell) und dass neue Anforderung mit teilweise wenig Aufwand einfach in eine der Kategorien gesteckt werden können. Die Entscheidung, welcher Kategorie eine Anforderung zugeordnet wird, kann für jede Anforderung isoliert gefällt werden.

Idealerweise sind für alle Kategorien klare Kriterien definiert, anhand der die Entscheidungen über die Zuordnung gefällt werden. In vielen Organisationen ist dies aber oft nicht der Fall.

Nachteile ergeben sich oft in der Abarbeitung der Anforderung nach Priorität bzw. bei der Planung von Iteration in agilen Vorgehensmodellen, da dieses Modell keine geeignete Unterstützung bei zu knappen Kapazitäten zur Umsetzung der Anforderungen biete. Dazu aber gleich mehr.

Das Modell der Reihenfolge

Hier werden die Anforderungen abhängig von ihrer Wichtigkeit/Dringlichkeit in eine lineare und eindeutige Reihenfolge gebracht. Dadurch wissen alle Projektbeteiligte genau genommen immer nur, die Anforderung A ist wichtiger als die Anforderung B und diese wiederum wichtiger als die Anforderung C, ohne dass es dadurch schon eine qualitative Bewertung gibt. Es ist dadurch z.B. noch nicht klar, ob A es überhaupt wert ist, umgesetzt zu werden.

Eine größere Menge an Anforderungen in eine sortierte Reihenfolge zu bringen, scheint auf den ersten Blick eine komplexe Aufgabe zu sein. Das ist sie aber nicht mehr, wenn man die Aufgabe in kleinere Schritte runterbricht.

Ich nehme mir wahlfrei zwei erste Anforderung und vergleiche in diesem Schritt nur, welche von beiden mir wichtiger ist. Diese ordnen ich denn oberhalb der anderen Anforderung an. Dann nehme ich mir eine weitere Anforderung und fange oben an und vergleiche diese neue Anforderung mit der obersten Anforderung in meiner „Liste“. Ist die neue Anforderung wichtiger als die aktuell wichtigste Anforderung, dann ordne ich sie oben in der Liste an. Ist sie weniger wichtig, dann gehe ich zum nächsten Eintrag in der Liste und vergleiche die neue Anforderung mit diesem Eintrag, usw.

In der Programmierung kennen wir diese Verfahren als Bubblesort

Der Nachteil ist, dass der Initiale Aufbau der Reihenfolge etwas aufwändig scheint, da man die einzelnen Anforderungen bei der Frage nach ihrer Priorität nicht isoliert betrachten kann. Und auch bei der Aufnahme weiterer Anforderungen ist ein Vergleich mit den anderen Anforderungen notwendig.

Dabei muss man allerdings bei der Einsortierung nicht immer ganz oben oder unten anfangen; wenn ich z.B. weiß, dass meine neue Anforderung H wichtiger ist als die bereits einsortierte Anforderung D, dann ist sie auch automatisch wichtiger als alle Anforderungen unterhalb von D und ich muss mich nur auf die Vergleiche oberhalb von D konzentrieren.

Wenn mir gerade kein direkter Vergleich präsent ist, dann kann ich alternativ auch auf ein Verfahren zurückgreifen, dass in der Softwareentwicklung als Binäres Suchen bekannt ist.

Bei diesem Verfahren fange ich mit dem Vergleich in der Mitte meiner Liste an. Ich nehme mir also als ersten Vergleichskandidaten eine Anforderung aus der Mitte meiner Anforderungsliste und beantworte mir die Frage, ob meine neue Anforderung wichtiger ist, als diese Anforderung in der Mitte. Ist sie mir wichtiger, dann nehme ich mir als nächsten Vergleichskandidaten eine Anforderung, die in der Mitte zwischen meinem letzten Vergleichskandidaten und dem oberen Ende der Liste liegt und vergleiche wieder. Abhängig von diesem Vergleich suche ich mir jetzt wieder die Mitte im oberen oder unteren Viertel meiner Liste für den Vergleich aus und mache das solange weiter, bis ich genau zwischen zwei Anforderungen lande, die entsprechend etwas wichtiger bzw. unwichtiger als meine neue Anforderung sind.

Die Mathematiker jetzt aber bitte nicht alle melden und darauf hinweisen, dass es optimalere Algorithmen für die Sortierung gibt. Ich kann mir nur schwer vorstellen, dass tatsächlich ein Produktverantwortlicher oder Anforderungsmanager einen mathematischen Sortieralgorithmus verwenden wird, die Vergleiche dienen hier nur als anschauliche Beispiele.

Der Vorteil der relativen Prioritäten (wie ich das Modell mit der Reihenfolge ab hier nennen möchte) ist, dass ich hier nun eine eindeutige Reihenfolge habe, in der die Anforderungen umzusetzen sind.

Was ist, wenn ich zwischen zwei Anforderungen nicht entscheiden kann, welche von beiden wichtiger ist? Dafür kann es eigentlich nur einen von zwei Gründen geben:

Der Unterschied in der Wichtigkeit ist so klein, dass ich deshalb keine eindeutige Entscheidung fällen kann oder es gibt sogar keinen. In diesem Fall treffen ich einfach eine Entscheidung. Durch Zufallsprinzip (Münzwurf) oder Bauchgefühl. Es spielt keine Rolle.
Mir fehlen bei beiden Anforderungen die notwendigen Informationen, um die Entscheidung fällen zu können. Auch in diesem Fall kann ich einfach so eine Entscheidung fällen, es ist zu diesem Zeitpunkt quasi nicht wichtig, welche von beiden wichtiger ist, da beide Anforderungen in diesem Zustand nicht umsetzbar sind. Meine Aufgabe nach der eher zufälligen Entscheidung (ich muss mich entscheiden) ist jetzt, die notwendigen Informationen zu erlangen, damit ich eine qualifizierte Entscheidung fällen kann. Idealerweise sollten beide Anforderungen in diesem Zustand nicht zur sofortigen Umsetzung anstehen.

Ist klar, dass eine der beiden Anforderungen aufgrund äußerer Umstände erst später umsetzbar sein wird, dann kann sie auch direkt weiter nach unten wandern. Dies gehört aber zum Thema, wie überhaupt bestimmt werden kann, welche Anforderungen wichtiger sind wie andere. Das werden wir in späteren Artikeln behandeln.

Der direkte Vergleich

Werfen wir beide Modell nun mal in den Ring und betrachten wir ihre Stärken und Schwächen im direkten Vergleich. Bei einer kleinen überschaubaren Anzahl an Anforderungen machen sich beide Kandidaten recht gut. Die Vergabe der Prioritäten im auf Kategorien basierenden Ansatzes ist wie bereits besprochen ja eh recht trivial:

Priorisierungsmethode der Wahl anwenden
Ergebnis nehmen und auf Kategorien transformieren
Fertig

Aber auch im relativen Modell ist der direkte Vergleich der Wichtigkeit der Anforderungen untereinander schnell erledigt. Und auch bei der Abarbeitung der Anforderungen bzw. der Einplanung zeigen sich beide Modelle in diesem Szenario noch recht hilfreich.

Wie sieht es denn bei einer größeren Anzahl an Anforderungen aus, wie sie in durchschnittlichen Projekten schnell erreicht ist? Wir unterstellen mal eine initiale Anzahl von 100 Anforderungen zum Projektstart. Und hier wird es langsam interessant.

Betrachten wir als erstes wieder den Aufwand für die Initiale Priorisierung der Anforderungen. Im auf Kategorien basierenden Modell nehmen wir mal die typische Aufteilung in fünf Kategorien an, die wir hier als P1 bis P5 bezeichnen wollen, wobei P1 für die wichtigsten Anforderungen stehen wird und P5 für die unwichtigsten.

Die Verteilung der 100 Anforderungen auf die fünf Kategorien ist erneut mit wenig Aufwand verbunden. Na gut, mit verhältnismäßig wenig Aufwand. Natürlich muss jede der 100 Anforderungen bewertet werden, das ist schon Arbeit. Als Ergebnis bestimmen wir jetzt in unserem Beispiel, dass 30 Anforderungen P1 sind, 40 P2, weitere 20 P3 und die restlichen 10 verteilen sich gleichmäßig auf P4 und P5.

Es scheint nicht unüblich zu sein, dass der überwiegende Teil der initialen Anforderungen als ziemlich wichtig bewertet wird. Zumindest begegnet mir das so laufend in Projekten.

Beim relativen Modell steigt der initiale Aufwand deutlich, denn hier müssen nun die 100 Anforderungen im Verhältnis zueinander nach Wichtigkeit sortiert werden. Das klingt aber schlimmer als es dann wirklich ist. Man fängt mit zwei Anforderungen an und fügt dann Anforderung für Anforderung hinzu. Und wie oben schon mal erklärt, muss nicht bei jeder Anforderung unten mit der Sortierung angefangen werden, sondern in der Regel kann direkt weiter oben in der Reihenfolge eingestiegen werden. Ich sage da gleich noch was zu.

Wie sieht es jetzt mit der Einplanung der Anforderungen aus? Auch hier treffen wir für unser Beispiel ein paar vereinfachte Annahmen. Wir definieren:

dass wir mit Scrum arbeiten,
dass alle Anforderungen mit einem Aufwand von einem Story Point geschätzt sind
und dass wir in einen Sprint 20 Story Points unterbringen können

Wenn wir nun unseren ersten Sprint planen, dann stellen wir im Kategorienmodell fest, dass wir insgesamt 30 Story Points haben, die Priorität vor allem anderen haben. Soweit ist das Modell ja schon mal hilfreich.

Im ersten Sprint unterbringen können wir aber nur 20 Story Points. Welche sollen wir da nun nehmen? Hier fangen wir dann vermutlich an, diese 30 Anforderungen untereinander zu vergleichen, um innerhalb dieser Gruppe eine gewisse Sortierung zu erzielen. Das gleiche gilt dann für die nächsten Sprints.

Vorausgesetzt, die 20 geplanten Story Points des ersten Sprints werden auch umgesetzt, dann stehen für den zweiten Sprint 10 weitere Story Points der Priorität P1 an und 40 der Priorität P2, von denen aber nur 10 im Sprint Platz finden. Also wieder vergleichen und sortieren innerhalb der Kategorie P2, und so weiter.

Wir fangen uns also hier genau den Aufwand ein, den wir vorher bei der initialen Priorisierung vermeintlich gespart hatten.

Bei der bereits eindeutig sortierten Reihenfolge des relativen Modells haben wir diese Probleme bei der Einplanung in die Sprints nicht mehr. Es ist jederzeit klar was als nächstes am wichtigsten ist. Dafür haben wir aber auch vorher mehr Aufwand reinstecken müssen.

Und jetzt kommen wir zur Königsdisziplin: Eine neue Anforderung, die wichtiger ist wie alles andere Anforderungen, die wir bereits aufgenommen und bewertet hatten. Sagen wir, eine gesetzliche Vorgabe, die scheinbar über Nacht vom Himmel gefallen ist. Natürlich ist sie nicht wirklich überraschend vom Himmel gefallen, aber einige Organisationen sind erstaunlich gut darin, z.B. neue gesetzliche Vorgaben so lange zu ignoriert, bis sie dann auf den letzten Drücker doch plötzlich unvermeidbar scheinen.

Wie bilde ich das mit meinen Kategorien ab?

P1 ist ja schon die höchste und wichtigste Kategorie. Aber meine neue Anforderung ist sogar noch wichtiger als die 30 bereits als P1 eingestuften Anforderungen. Definiere ich jetzt adhoc eine neue Kategorie P0, die noch über P1 steht? Da dauert es garantiert nicht lange, bis auch diese neue Kategorie regelmäßig gefüllt wird, denn Kategorien mit Top-Priorität haben die Eigenschaft, Anforderungen anzuziehen.

Wir haben hier also ein nichttriviales Problem, dass in vielen Fällen damit gelöst wird, dass zusätzlich zur eigentlichen Kategorie noch ein weiteres Attribut wie z.B. Severity hinzugefügt wird. Das kann dann z.B. so erklärungsbedürftige Ausprägungen wie blocker, critical, major, normal, minor, trivial und/oder enhancement annehmen.

Und falls Sie jetzt vermuten, dass ich mir das nur ausgedacht habe, dann schauen Sie doch mal in Tools in ihrem Unternehmen nach, welche Attribute dort für die Bewertung von Anforderungen oder Tickets vorhanden sind und wie diese bei Ihnen verwendet werden.

Diese zusätzlichen Attribute sind aber nicht nur redundant, sondern können auch zu Inkonsistenzen führen. Was ist denn nun wichtiger, eine Anforderung mit P1/enhancement oder eine mit P3/blocker? Und wieso kann eine P3 Anforderung ein Blocker sein, bzw. wieso kann ein scheinbarer Blocker nur die Priorität P3 haben? Das führt eindeutig zu Chaos!

Bei der eindeutigen Reihenfolge des relativen Modells ohne Kategorien ist das Problem der neuen Anforderung, die wichtiger ist als alle bisherigen, dahingegen leicht zu lösen. Die neue Anforderung wird einfach ganz oben einsortiert. Problem gelöst.

Bis hierhin scheint das relative Modell also besser geeignet zu sein.

Jetzt hatte ich aber weiter oben ausgeführt, dass die meisten Methoden zur Priorisierung von Anforderungen eher das Denken in Kategorien unterstützen. Das jetzt schon mehrfach zitierte Kano Modell der Kundenzufriedenheit z.B. teilt Produktmerkmale, aus denen später Anforderungen werden, in fünf Kategorien ein:

Basismerkmal,
Leistungsmerkmal,
Begeisterungsmerkmal,
Unerhebliches
und Rückweisungsmerkmal

Muss ich nun auf diese Methoden verzichten, wenn ich mit einem relativen Prioritätsmodell arbeiten möchte?

Natürlich nicht! Wenn ich eine eindeutige Reihenfolge meiner Anforderungen aufbauen möchte, dann muss ich die Wichtigkeit der einzelnen Anforderungen irgendwie begründen können. Warum ist denn die Anforderung A wichtiger als die Anforderung B? Da brauche ich für beide Anforderungen irgendwelche Anhaltspunkte dafür, weshalb sie wichtig oder auch nicht wichtig sind.

Und genau dafür sind viele Methoden der Priorisierung eine große Hilfe. Mit ihnen kann ich zumindest schon mal ein grobes Raster schaffen, dass mir bei der ersten Vorsortierung hilft. Und wenn die Anforderung A nach dem Kano Modell in die Kategorie Basismerkmal fällt und die Anforderung B in die Kategorie Leistungsmerkmal, dann weiß ich ganz automatisch, das A wichtiger ist als B. Und nur wenn die Anforderung C ebenfalls ein Basismerkmal zu sein scheint, muss ich mir im Vergleich von A und C mehr Informationen heranziehen, um hier eine eindeutige Entscheidung fällen zu können.

Fazit

Kommen wir zur Antwort auf die sich nun stellende Frage, ob Kategorien in der Priorisierung von Anforderungen strikt abzulehnen sind.

Ich sage nein, denn sie sind eine hilfreiche Zwischenstufe auf dem Weg zu einer sortieren Reihenfolge relativer Wichtigkeit. Und diese Zwischenstufe kann nicht nur viel Zeit sparen, sondern bei der Verwendung geeigneter Methoden die fundierte Basis für die Bewertung der relativen Wichtigkeiten liefern.

Ich allerdings davon ab, bei der Verwendung von Kategorien stehen zu bleiben und den Aufwand der Transformation in eine sortierte Liste zu scheuen, da z.B. in iterativen Verfahren wie Scrum die Kategorien meistens nicht dabei helfen zu identifizieren, was am sinnvollsten im nächsten Sprint umgesetzt werden soll.

The post Prioritäten von Anforderungen –Kategorie oder Reihenfolge? appeared first on Binaris Informatik.

Kartenspiel „Deine Meinung bitte! Scrum Edition“

Carsten Czeczine — Fri, 06 Aug 2021 11:44:13 +0000

Kartenspiel

"Deine Meinung bitte!" Scrum Edition

Durch die Pandemie hat sich in vielen Unternehmen nicht nur die Arbeit, sondern auch die Interaktion zwischen Teammitgliedern in Home Office verlagert. Sowohl die Zusammenarbeit wie auch die sozialen Aspekte des Miteinanders finden dort nun überwiegend online statt. Und damit hat sich auch eine neue Kultur für Team Building etabliert.

Etwas, dass sich bei uns gut bewährt hat, sind virtuelle Spielabende, bei denen wir uns im Kollegenkreis per Zoom (wahlweise gehen natürlich auch alles anderen Videokonferenztools) treffen und dann auf einem virtuellen Whiteboard System (wir verwenden dafür Miro https://miro.com) Kartenspiele spielen. Dafür haben wir beliebte Frage-Antwort-Spiele wie beispielsweise Sag Mal! von Spielehelden (https://spielehelden.eu) oder Verschätzt Noch Mal! von Kylskapspoesi ( https://www.kylskapspoesi.com/de/produkte/) verwendet.

Warum nicht ein Spiel, dass sich um unsere Themen dreht?

Schnell kam dabei die Idee auf, dass wir doch auch selbst so ein Kartenspiel entwickeln könnten, nur speziell für unsere Themen. Wir beschäftigen uns in unserer Projektarbeit viel mit Agilität und da vor allem mit Scrum. Fast alle Kollegen:innen arbeiten in agilen Teams, eine ganze Reihe sind sogar zertifizierte Scrum Master:innen und Product Owner:innen. Und auch wenn wir uns abends vor allem treffen, um uns auch mal abseits der geschäftlichen Tagesroutine auszutauschen, so ist doch nichts verkehrt daran, auch da über Agilität zu reden. Zumindest nicht solange, wie es Spaß macht. Und deshalb haben wir Deine Meinung bitte! Scrum Edition entwickelt, ein lustiges Frage-Antwort-Spiel rund um Scrum.

Ja, es geht schon um Scrum. Aber nicht immer so ganz ernst gemeint und vor allem nicht um ein reines Quiz, in dem theoretisches Wissen abgefragt wird. Deine Meinung bitte! Scrum Edition wirft spannende und unterhaltsame Fragen auf, zu denen wir die ganz persönlichen Meinungen und Ansichten der Mitspielenden hören möchten. Und die oft der Startpunkt für wertvolle Diskussionen sind.

Wie bekomme ich das Spiel?

Schön, dass wir jetzt dieses Spiel entwickelt haben und nutzen, aber was haben Sie davon? Wie kommen Sie an das Spiel und wie benutzen Sie es?

Alles ganz einfach. Unten finden Sie den Link auf eine Zip-Datei, in der wir das komplette Spiel inklusive Spielanleitung, aller Karten, einer Vorlage für einen virtuellen Spielraum und einer Anleitung, wie Sie das Spiel in einem virtuellen Spielraum vorbereiten können. Alles was Sie noch dazu beisteuern müssen ist ein Videokonferenztool, ein digitales Whiteboard System wie beispielsweise Miro oder Mural und natürlich begeisterte Mitspieler:innen.

Download: DeineMeinungBitteScrumEdition

Wofür kann ich Deine Meinung bitte! Scrum Edition verwenden?

Sie können Deine Meinung bitte! Scrum Edition für ein Kick-Off Meeting eines neuen Scrum Teams verwenden, bei einem gemütlichen Teamabend oder auch einem agilen Stammtisch. Neue Scrum Master:innen nutzen das Spiel, um das Scrum Team kennenzulernen, in das sie gekommen sind. Und umgekehrt nutzen Teams das Spiel, um sich mit ihrer:m neuen Scrum Master:in vertraut zu machen. Oder Sie nutzen es zum Beginn eines agilen Workshops oder Seminares, um das Eis zu brechen und spielerisch ins Thema zu kommen.

Den Anwendungsmöglichkeiten sind kaum Grenzen gesetzt. Probieren Sie es einfach aus!

Kostet mich die Verwendung was?

Nein, wir stellen das Spiel allen Interessierten kostenfrei zur Verfügung. Wenn es Ihnen Spaß macht und vielleicht auch beim Team Building hilft, dann sind wir schon glücklich.

Und wir freuen uns natürlich über Feedback. Was sind ihre tollsten Erlebnisse mit dem Spiel, was sind die verrücktesten oder ausgefallensten Antworten, die jemand in Ihren Runden gegeben hat. Wir sind gespannt darauf.

The post Kartenspiel „Deine Meinung bitte! Scrum Edition“ appeared first on Binaris Informatik.

Die AAA-Regel

Carsten Czeczine — Thu, 09 Apr 2020 12:28:31 +0000

Die Grundlage einer guten Testautomatisierung in der Softwareentwicklung sind Unit Tests. Um wirklich gute Unit Tests zu schreiben, gibt es ein paar Faustformeln dafür, wie ein Unit Test aussehen sollte. Eine davon ist die AAA-Regel.

AAA steht dabei für:

Arrange
Act
Assert

und beschreibt den Aufbau eines Unit Tests.

Im Act wird die eigentliche Aktion, die das zu verifizierende Ergebnis erzeugen soll, durchgeführt. In der Regel ist das der Aufruf der Methode, deren Verhalten getestet werden soll. Ein guter Unit-Test besteht dabei aus nur einem Aufruf. Ist mehr als ein Aufruf notwendig, ist das ein Hinweis darauf, dass mehr als nur ein einfacher Aspekt getestet wird! Das ist dann kein Unit Test mehr.

Und schlussendlich wird im Assert überprüft, ob das erwartete Ergebnis durch das Act erzielt wurde. Hier gilt, dass nur ein einzelnes fachliches Ergebnis geprüft werden soll. Dabei liegt die Betonung darauf, dass auf ein fachliches Ergebnis geprüft wird, nicht ein technisches. Das bedeutet nicht zwangsläufig, dass dafür nur ein einzelnes Assert-Statement verwendet werden darf. Wenn über mehrere Vergleiche verschiedene Teilaspekte des fachlichen Ergebnisses überprüft werden müssen, dann ist das schon in Ordnung. Wenn allerdings z.B. ein Unit-Test TestInsertKunde im Assert prüft, ob der Kunde wirklich in die Datenbank geschrieben UND ein entsprechender Logeintrag im Logfile erzeugt wurde, dann ist das ein Hinweis darauf, dass hier mehr als nur ein einzelner Aspekt getestet wurde. So simple und vielleicht manchmal auch nervig, wie die Einhaltung der AAA-Regel scheinen mag, sie hilft, echte Unit Tests zu identifizieren.

In dem Beispiel sehen wir, dass Act und Assert in einer Zeile, quasi ineinander verschachtelt stehen. Hier kann man argumentieren, dass für die bessere Lesbarkeit dieses zu trennen sind. Also den Schlag des Spielers in einer einzelnen Zeile und das Ergebnis daraus in einer lokalen Variable fangen und dann diese im Assert auswerten.

Ob das der besseren Lesbarkeit und Wartbarkeit wegen wirklich notwendig ist, ist schwer objektiv zu beurteilen. Deshalb überlassen wir diese Entscheidung denen, die mit dem Code und den Tests arbeiten müssen.

The post Die AAA-Regel appeared first on Binaris Informatik.