Key Note Lisa Crispin – Are Agile Testers Different?
Besucht und geschrieben von: Andreas & Thomas
Die Antwort auf die Fage aus dem Titel der Keynote lautet: Ja! Dabei hat Lisa auch wieder besonderen Fokus darauf gelegt, dass es in agilen Teams keine Silos gibt, sondern es darum geht gemeinsam die gestellte Aufgabe zu lösen. Hierzu sind (agile) Tester genauso wichtig wie (agile) Entwickler und alle anderen Mitglieder des Teams.
Lisa Crispin: „We (testers) don’t break code, it comes to us already broken!“ (im Original von Cem Kaner)
Insgesamt war Lisa’s Keynote sehr inspirierend, da sie sehr stark auf agile Werte und Vorstellungen eingegangen ist und hervorgehoben hat, wie die Arbeit mit diesen Methoden einfach mehr Spass macht durch die starke Teambindung und auch die sichtbaren Erfolge.
Hier noch zwei Links zu Blogposts zu dieser Keynote, so können wir uns hier etwas kürzer fassen, denn es wird eh ein ulimativ langer Blogpost.
- Gojko Adzic: Are agile testers different?
- Anthony Gardiner: Lisa Crispin – Are agile testers different?
Open Source Agile Testing von Péter Vajda
Besucht und geschrieben von: Andreas
Eigentlich hätte die Session „Wie man Scrum nicht umsetzen sollte“ heißen sollen. Péter Vajda präsentierte die Erfahrungen im Nokia Maemo Projekt, dem zukünftigen Linux-basiertem Betriebssystem für mobile Endgeräte, wie z.B. den bekannten Internet-Tablets N900. Vor zwei Jahren waren noch 200 MitarbeiterInnen an dem Projekt beteiligt, mittlerweile sind sie auf fast 1000 Leute und rund 50 Teams angewachsen (was eine Teamgröße von ca. 20 impliziert). Wärend die Kluft zwischen Open Source Communities und einem Endgerätehersteller überbrückt werden muss, wurde beschlossen jetzt mal agil zu werden und Scrum einzuführen, auf XP Praktiken und Lean-es Denken zu setzen. Neben einigen wohlbekannten Tatsachen (Scrumteams arbeiten am besten, wenn sie zusammen in einem Raum sitzen), wurden ein paar interessante Fakten erwähnt. Wie z.B. dass in Sprint 20 festgestellt wurde, dass Unit-Tests alleine nicht ausreichen, automatisierte Fachtests wünschenswert aber nicht vorhanden sind. Pause machen und erstmal Fachtests schreiben oder die alten Funktionalität ungetestet lassen? Der Kompromiss waren „Refactoring Backlog Items“ — in der Sache eine gute Idee, jedoch sollte auch bei solchen „System-User Stories“ immer der Wert herausgestellt werden. Und der liegt ja nicht darin, dass man gerne die Tests hätte, sondern die Fachtests sollten existieren, um in Zukunft schneller neue Features umsetzen zu können. Die Demo, in der gezeigt wurde, wie ein Qt-Taschenrechner mit Cucumber getestet wurde (das richtige, neue Gerät durfte leider nicht gezeigt werden) hat wenigstens eine (für mich) neue Erkenntniss gebracht.
Man kann mit Cucumber Verhaltenstests schreiben, welche nicht nur das Format „Given / When / Then“ unterstützen, sondern nachgelagert eine Tabelle für weitere Testdaten bereitstellen – eine Idee, die ich schon auf der Agile 2009 in Chicago kennengelernt hatte, dort aber im Kontext für FitNesse: One problem with given-when-then… the answer… „Other Examples Include“. Ich denke dieses Format ist eine hervorragende Idee, um Verhalten mit mehr Testdaten zu unterfüttern.
Agile Testing: A Report from the Frontline von Joke Hettema und Ralph van Roosmalen
Besucht und geschrieben von: Thomas
Joke startet mit einer kurzen Einführung, warum die Firma für die sie arbeitet auf agile Methoden umgestiegen ist. Dabei wiederholt sich ein bekanntes Muster, dass es mit den herkömmlichen Methoden einfach nicht mehr genug Transparenz gab, die anfallenden – um immer größer werdenden – Projekte umzusetzen. Um dieses Problem zu lösen, wurde Scrum als Methodik eingeführt und „gemischte“ Teams installiert, d.h. Entwickler, Tester und Architekten formen ein Scrum-Team. Bis hierhin nicht zu viel Neues würde ich sagen.
In Hinblick auf Tester und Testing wiederholen sich die Muster aus den gestrigen Tutorials und Lisa’s Keynote: Kein explizites Testteam mehr, gemeinsame Verantwortung für das Testen der Software. Eine Besonderheit ist jedoch ein „Scrum of Scrums“ für die Tester aller Teams. Hier werden spezielle Erfahrungen in Hinblick auf Testautomatisierung ausgetauscht. Für meinen persönlichen Geschmack wird hierdurch jedoch wieder eine künstliche Trennlinie zwischen Testern und Entwicklern gezogen, die ich persönlich eher weiter minimieren würde. Denn die Trennung wird auch in der Sprint-Planung fortgesetzt, wo Testing Tasks unabhängig von den Entwicklungsaufgaben geplant werden. Nach einer Rückfrage zeigt sich auch, dass Entwickler lediglich Unit-Test schreiben, sich für alle weiteren Tests jedoch auf die Tester verlassen. Hier scheint es also in der Realität nach wie vor eine recht starke Trennung zwischen Testern und Entwicklern innerhalb des Teams zu geben.
Joke beschreibt weiter das Problem von „Mini Waterfalls“. Dies passiert wenn Entwickler ihre Änderungen nicht täglich einchecken und dann zu einem späteren Zeitpunkt eine Menge Software auf einen Schlag getestet werden muss. Zu diesem Thema hat Fabian vor einiger Zeit bereits einen sehr guten Blogbeitrag geschrieben .
Auch bei der Sprintplanung spricht nicht das gesamt Team mit dem Product Owner, sondern es gibt einen „Functional Specialist“, der die Rolle eine Mediators zwischen dem Product Owner und dem Team übernimmt. Auch hier denke ich persönlich, dass dies nicht der optimale Ansatz ist. Auch Elisabeth hat in ihrem gestrigen Tutorial bei einer ähnlichen Frage betont, dass soviele Mitglieder des Teams wie möglich bei der Sprint-Planung dabei sein sollten, um Informationen aus erster Hand zu erhalten. Auch sollte das Domain-Wissen im Team vorhanden sein und nicht ausserhalb des Team. Allerdings merke ich gerade, wie es hier weg geht vom Testen und mehr hin zu allgemeinen agilen Vorgehensweisen, also back to topic.
Joke führt weiter aus, welche Dokumente erzeugt werden. Die Liste ist für eine agile Vorgehensweise doch recht lang mit: Test Strategy, Risk Matrix, Test Approach Document, Checklist, Session Tester und Bug Reporting Software. Auch bei der „Definition of Done“ werden Tester hervorgehoben, als die Teammitglieder, die „gegen den Rest des Teams“ sagen, dass die Software nicht feritg ist gemäß dieser Definition. Auch auf die Gefahr hin mich zu wiederholen birgt dies wieder die Gefahr einer Lagerbildung. Es sollte keine Frage der Tester sein dies zu entscheiden, sondern eine Teamentscheidung. Das Vertrauen in die eigene „Definition of Done“ scheint auch nicht 100%-tig zu sein, da es parallele „Release Testing Sprints“ gibt, die letzten Endes klassiche Release Tests sind mit einer Menge manueller Tests. Dazu passt auch die explizite Rolle eines übergeordneten Test Managers.
Ich denke insgesamt zeigt der Vortrag, dass es an der „Frontlinie“ – zumindest in diesem Fall – doch noch ein Stück des Weges zu gehen ist, um sich wirklich von der herkömmlichen QA-Methodik zu lösen und noch stärker in Richtung Agilen Testens zu gehen.
BDD approaches for Web Development von Thomas Lundström
Besucht und geschrieben von: Andreas
Zuerst hat Thomas Lundström einige Grundlagen zu BDD erläutert und den allgemeinen Kontext für die spätere Live-Demo gelegt. Das Vorgeplänkel hat meiner Meinung nach leider ein wenig zu viel Zeit in Anspruch genommen, man kann eigentlich erwarten, dass auf einer Konferenz speziell für agiles Testen jeder eine Vorstellung davon hat, was Behaviour Driven Development ist. Zudem wurden einige Teile anders erklärt, als ich sie für richtig halte, wie zum Beispiel das “goldene Dreieck”, die Verschmelzung von Anforderungen, Test und … Done?! Meines Wissens, und so ist das z.B. auch im Buch “Bridging the Communications Gap” von Gojko Adzic dargestellt, sind bei ausführbaren Spezifikationen die Anforderungen, der Test und die Beispiele (zur Verdeutlichung der Anforderungen) vereint. Die vorgeführte Kombination aus cucumber und webrat, ruby-basierte Werkzeuge, waren in der Livedemo in der Lage ein einfaches Gästebuch zu testen. Ok, User-Stories heißen in Cucumber (bzw. in der DSL Gherkin ) Features, und Acceptance Tests heißen nicht „Acceptance Tests“ sondern „Szenarios“, aber das sind nur Kleinigkeiten. Webrat unterstützt kein Ajax, was es wirklich nur für die einfachsten Einsatzszenarien prädestiniert, cucumber kommt aber auch mit Selenium oder HtmlUnit zurecht.
Einen wichtigen Punkt hat Lundström noch herausgestellt, den ich nicht missen möchte auch hier zu betonen. Es ist wichtig, in den automatisierten Fachtests / ausführbaren Spezifikationen die Regeln zu beschreiben, die abgetestet werden sollen – zwar inklusive des Kontexts und der Vorbedingungen, aber ohne die Schritte / das Skript, wie dieser Kontext erzeugt werden soll, das ist Aufgabe des Fixtures. Lundström brachte folgendes Beispiel und unterschied dabei den imperativen Stil (also das Skript) und den deklarativen Stil. Durch die Beschränkung auf die zu prüfende Logik ist der deklarative Test sehr viel robuster. Ein weiterer Vorteil ist meiner Meinung nach, dass es Möglichkeiten zum automatischen Refactoring eröffnet, wenn das Fixture (also die Anbindung des Tests an den zu testenden Code) in der gleichen Sprache entwickelt, wie das zu testende System. Ein Ding der Unmöglichkeit, wenn die Logik zur Erzeugung des Testkontexts im Testskript steckt.
Imperativer Fachtest
1Story: Animal Submission 2 3 As a Zoologist 4 I want to add a new animal to the site 5 So that I can share my animal knowledge with the community 6 7 Scenario: successful submission 8 Given I'm on the animal creation page 9 10 When I fill in Name with 'Alligator' 11 And select Phylum as 'Chordata' 12 And fill in Animal Class with 'Sauropsida' 13 And fill in Order with 'Crocodilia' 14 And fill in Family with 'Alligatoridae' 15 And fill in Genus with 'Alligator' 16 And check Lay Eggs 17 And click the Create button 18 19 Then I should see the notice 'Thank you for your animal submission!' 20 And the page should include the animal's name, phylum, animal class, order, family, and genus
Deklarativer Fachtest
1Story: Animal Submission 2 3 As a Zoologist 4 I want to add a new animal to the site 5 So that I can share my animal knowledge with the community 6 7 Scenario: successful submission 8 Given I'm on the animal creation page 9 10 When I add a new animal 11 12 Then I should see the page for my newly created animal 13 And the notice 'Thank you for your animal submission!'
Quelle: Imperative vs Declarative Scenarios in User Stories
Introduction to Robot Framework von Pekka Klärck
Besucht und geschrieben von: Thomas
Auch wenn Andreas im Vorfeld x-mal gesagt hat ich wüsste doch eh schon alles über das Robot Framework und könnte den Slot daher anders nutzen, sitze ich jetzt mit freudiger Erwartung in der Session und bin mir scher, Pekka hat auch für mich noch ein paar Neuigkeiten zu bieten :-).
Zunächst mal ein paar basic facts: Keyword-driven, basiert auf Python, Java-Unterstützung via Jython. Unterstützung für andere Sprachen via XML-RPC remote interface. Robot ist Open Source unter der Apache 2.0 Lizenz. Das Tool ist aus einer Studienarbeit bei Nokia Networs entstanden und wird heute noch von Nokia Siemens Networks gesponsort. Im Prinzip bringt es aber nich zu viel Infos von den Slides hier zu wiederholen, denn die Slides finden sich hier :-).
Die Diskussion startet mit der Präsentation von Keywords. Hier hat Andreas natürlich schon recht, denn ich träume im Prinzip schon in Keywords. Es geht weiter mit einem kurzen Vergleich zum Ansatz von FitNesse und Pekka führt aus, dass in Robot alles ein Keywords ist, was es in seinen Augen einfacher macht als der Ansatz verschiedener Fixtures in FitNesse. Das Beispiel kommt mir dann aber doch sehr bekannt vor und ich glaube Elisabeth hat schon einige Anleihen an diesem Beispiel für ihr Tutorial gestern genommen. Pekka hebt die Möglichkeit hervor lower-level Keywords zu mächtigeren higher-level Keywords zu kombinieren. Ein Robot-Feature in dem ich auch persönlich eine ganz grosse Stärke des Tools sehe. Es hat übrigens seine ganz eigene Fazination eine Präsentation auf Linux zu sehen, bei dem alle Menüs komplett in finnischer Sprache gehalten sind.
Pekka Klärck: „I have some confidence that really every tester – even without the slightest programming skills – can combine existing keywords to build new testcases.“
Es geht weiter mit dem Start von Robot aus der Shell. Dabei geht es natürlich besonders darum die Testausführung einfach in bestehende CI-Umgebungen einzubinden, was hier kein Problem darstellt. Weiter geht es mit den Reporting- und Statistik-Möglichkeiten des Robot Frameworks, insbesondere Tagging. Dies bildet auch eine Brücke zur ATDD-Session von gestern, bei der die FRage aufkam, wie man verhindern kann, dass das Build fehlschlägt aufgrund von Tests für die es noch keine Implementierung gibt. Tagging ist ein Teil der Antwort. Der zweite ist die Möglichkeit Tests mit gewissen Tags als unkritisch zu markieren und somit schlägt das Build nicht fehl, wenn Tests mit diesem Tag fehlschlagen. In ATDD ist dies ja ein gewünschter Effekt.
Beim grafischen Editor RIDE hat sich auch einiges getan. So lassen sich jetzt Keywords vervollständigen mittels CTRL-Space. Es werden alle Keywords angezeigt, die zu den Anfangsbuchstaben passen inkl. der entsprechenden Dokumentation. Das sieht wirklich vielversprechend aus und von RIDE verspreche ich mir persönlich noch sehr viel für die Zukunft. Auch der Ansatz „Ausführbarer Spezifikationen“ geht in eine sehr gute Richtung und wird sicherlich noch in einem weiteren Blogbeitrag genauer beleuchtet.
Nach dem Vortrag und beim Mittagessen gab es dann noch die Chance auf ein wenig Smalltalk mit Pekka, was mich besonders gefreut hat, da wir ja bei derselben Firma gearbeitet haben als das Robot Framewrk entstanden ist. Es hat auch nochmal gezeigt, dass die Entwicklung des Robot Frameworks sehr aktiv weiter voran geht und ich bin vor allen Dingen gespannt auf die finale RIDE-Version und die Weiterentwicklung des ATDD-Features.
Key Note Elisabeth Hendrickson – Agile Testing, Uncertainty, Risks and Why It All Works
Besucht und geschrieben von: Andreas & Thomas
Elisabeth hat einen wirklich guten und auch sehr aktiven Vortragsstil. Ihre Keynote dreht sich hauptsächlich um das, was sie die „7 Key Principles of Agile Testing“ nennt. Diese sind:
- ATDD
- TDD
- Exploratory Testing
- Automated System Tests
- Automated Unit Tests
- Collective Test Ownership
- Continuous Integration
Diese Punkte sind auch noch einmal sehr gut zusammengefasst in Anthony Gardiner’s Blog Post über die Keynote.
Elisabeth Hendrickson: „The only way to tell if you are agile is if you are successfully delivering software.“
Elisabeth Hendrickson: „Exploratory Testing is a dicipline. It is not just blindly banging on the keyboard.“
Das ich in obigem Blockquote statt „keyboard“ zunächst „keyword“ geschrieben habe kann man ja schon fast als Zeichen werten ;-). Aber zurück zu Keynote. Es geht weiter mit CI und der Erläuterung, dass Tests Artefakte sind, die zum Projekt gehören. Das unterschreibe ich absolut und ich kann Projekte nicht verstehen, bei denen Tests oder Testdokumente nicht im Versionskontrollsystem gespeichert werden und zwar zusammen mit dem Code!
Agile Quality Management – Axiom or Oxymoron? von David Evans
Besucht und geschrieben von: Andreas
David Evans stellte viele Vorbehalte, die Tester aus einem traditionellen Entwicklungsumfeld agilen Projekten entgegnen könnten, in ein anderes Licht. Dazu bediente er sich einer interessanten Struktur, jedem Vorbehalt wurde dabei einmal die Negativsicht (als Oxymoron) und die Positivsicht (als Axium) gegenübergestellt. Welches davon die zutreffende ist, überlasse ich mal als Übungsaufgabe dem geneigten Leser (oder der Leserin, selbstverständlich)
- Entwickler schreiben ihre eigenen Tests
- Oxymoron: Das ist als wenn man die eigenen Hausarbeiten korrigiert
- Axiom: Unit tests sind nur die ersten von vielen Qualitätsstrategien
- Entwickler und Tester sind voneinander abhängig
- Oxymoron: Unabhängigkeit ist notwendig zur Qualitätssteuerung
- Axiom: Das ganze Team ist verantwortlich für die Qualität
- Entwickler kennen die Fachtests (werden im Voraus definiert und beschlossen)
- Oxymoron: Sie schreiben nur den Code, damit der Test funktioniert
- Axiom: Sie schreiben keinen Code, der den Test fehlschlagen lässt
- Keine abgezeichneten Anforderungen (… die ändern sich wohl mit dem Wetter)
- Oxymoron: So kann ich niemals sicherstellen, dass die Anforderungen erfüllt wurden
- Axiom: Jede Anforderung ist mit dem Fachtest definiert, diese sind mit dem Kunden ausgehandelt und bestätigt
- Keine Testpläne (IEEE 829 Testpläne sind rar in agilen Projekten)
- Oxymoron: Fehlende Planung heißt den Fehlschlag zu planen! Wie sollen wir wissen, was wir testen sollen?
- Axiom: Der Testplan ist im Product Backlog impliziert: alles was wir bauen, das testen wir auch
- Kein Testmanager oder Testmanagement-Werkzeug
- Oxymoron: Wie sollen wir also das Testen managen?
- Axiom: Testers sind Teil des Teams, Tests sind die Spezifikation, da braucht man kein separates Management
Danach stellte er noch seine Empfehlung an Qualitätsprinzipien vor, wo sich aber keine großen Überraschungen versteckten (schnelles Feedback, gemeinsames „Done“-Verständnis, etc). Die richtige Einstellung zum Testen äusserte sich dann noch in zwei Zitaten:
„Defects are evidence of missing tests“
„Any test worth writing is worth running all the time“
Meint, wenn der Test „rot“ ist und den Kunden interessiert es nicht … dann kann der Test getrost gelöscht werden, er war es nicht wert geschrieben zu werden, da er unwesentliche Funktionalität testet.
Quality and Short Release Cycle von Lior Friedman
Besucht und geschrieben von: Thomas
Lior startet seinen Vortrag mit der Aussage: Die Aufgabe eines Entwicklers ist nicht einfach nur Code zu produzieren, sondern eine funktionierende und qualitativ hochwertige Software. Das kann man problemlos unterschreiben, aber es ist fast schon erschreckend, dass dies immer wieder betont werden muss. Es erscheint mir nur logisch, dass ich als Entwickler einen Mehrwert für meine Kunden schaffen möchte und nicht programmiere um des Programmierens willens (das kann ich in meiner Freizeit machen ;-)). Da zugrunde liegende Thema für mich hier ist Professionaltät.
Weiter geht es mit einer Diskussion Time versus Quality und der Tatsache, dass es hier in traditionellen Projekten immer Kompromisse geben muss, wenn die Resourcen fix sind. Mit agilen Methoden soll durch bessere Qualität auch gleichzeitig die benötigte Zeit reduziert werden.
Für den Rest halte ich mich einfach mal kurz, da es nichts wirklich Neues ist. Es geht um die Vorteile kurzer Release-Zyklen, besserer Qualität durch CI, weniger Fehler, mehr Effektivität, mehr Vertrauen vom Kunden, weniger Risiko. Kurz: All das warum wir letzten Endes agile Software-Entwicklung betreiben.
“Testify” – One-button Test-Driven Development tooling & setup von Mike Scott
Besucht und geschrieben von: Andreas
Anfangs gab es einige Überlappungen zu der früheren Präsentation des SQS-Kollegen David Evans. Schnell ging es aber mit der Live-Demo von „Testify “ los, ein Werkzeug mit dem sich ein vollständiges TDD/ATDD (Acceptance TDD) Projektsetup wahlweise in .Net oder Java aufsetzen lässt. Seit heute ist das SQS-interne Projekt OpenSource! Danke Scott!
- .Net integrierte Werkzeuge: nant, nunit, fit, fitnesse, richnesse, selenium, ncover, nsis, fx-cop, cruisecontrol
- Java: hier sah die Werkzeugbank ähnlich aus, ich war aber zu langsam alle mitzuschreiben
Im wesentlichen ist Testify ein sorgsam aufgesetztes Projekt, wobei einige Dateien als Velocity -Template umgestrickt wurden, um den Projektnamen (den einzigen Parameter den Testify bei der Projekterstellung entgegennimmt) in einigen Dateien zu ersetzen. Persönlich hätte ich hier eher auf Maven Archetypes gesetzt, die technisch gesehen das gleiche (und noch etwas mehr) machen; aber na gut, da hat man keine GUI. Wer keine Werkzeugpräferenzen oder andere Rahmenbedingungen hat, ist gut damit beraten zumindest mal 2 Stunden in das von Testify generierte Projekt zu investieren, um zu klären, ob das den eigenen Bedürfnissen entgegenkommt.
Test Driven TDD – TDD quality improvement based on test design technique and other testing theory von Wonil Kwon
Besucht und geschrieben von: Thomas
Sorry, hier lohnt sich leider die Zusammenfassung nicht, da der gesamte Vortrag doch extrem low-level war und nicht nur nichts wirklich Neues bietet, sondern teilweise auch falsche Beispiele bringt. Sorry Wonil.
Key Note Tom Gilb – Agile Inspections
Besucht von: Andreas & Thomas, Geschrieben von: Thomas
Yiha, es ist 18 Uhr und Tom legt los mit seiner Key Note. Ich hatte noch nie das Vergnügen Tom live zu erleben und nach einiger Zeit sieht es so aus, als ob es auch für einige Konferenzteilnehmer kein echtes Vergnügen ist, da agile Aspekte absolut keine Rolle spielen in seinem Vortrag. Im Gegenteil sollte es sogar so sein, dass er gegen Ende des Vortrags nochmal eine richtige Breitseite gegen „Agile“ abfeuert, getreu dem Motto: Macht Eure Standup-Meetings wenn es Euch Spass macht, aber ich glaube nicht das es was bringt für ernsthafte Projekte. Dafür brauch man messbare Ergebnisse.
Tom Gilb: „It is you’re fault if you accept garbage in!“ (about testers accepting bad requirement documents)
Und das war es worum es sich bei Tom’s Vortrag dreht: Wie kann ich die Anzahl der potentiellen Fehler in Requirement Specifications finden und diese minimieren? Denn für zwei Fehler in den Requirements wird es einen Fehler in der späteren Software geben. Andreas saß zu diesem Zeitpunkt schon etwas gequält neben mir, da er auch den agilen Hintergrund vermisst hat und duch die Folien ein wenig „geflashed“ war. Aber ich muss sagen: Mir hat es richtig gut gefallen und deswegen wollte ich auch gerne noch ein wenig mehr dazu schreiben :).
Tom Gilb: „Garbage in guarantees some garbage out no matter how clever you are.“
Ok, also Requirements ist das Thema. Keine ausführbaren Spezifikationen, keine fancy automatisierten Tests, sondern eine Methode Spezifikationen auf potentielle Fehler hin zu analysieren. Dabei ist es denke ich offensichtlich, das Tom es versucht – und geschafft – hat mit seinen Aussagen sehr zu polarisieren, insbesondere auf einer Konferenz mit dem Titel „Agile Testing“. Aber ich bin auch ein Fan davon alles von allen Seiten zu betrachten und Tom’s Ansatz kann als eine gute Ergänzung gesehen werden, die überhaupt nicht im Widerspruch steht zu den – zu einem späteren Zeitpunkt im Projekt – eingesetzten agilen Testmethoden.
Tom Gilb: „How lucky do you feel today, punk?“ (About the 50:50 chance that a bug in the requirements results in a bug in the final software.)
Die Methode sieht vor Spezifikationen dahingehend zu überprüfen, ob diese den folgenden Anforderungen genügen:
- Clear enough to test is.
- Unambigious with respect to intendend readers.
- Contains no design.
Requirement Spezifikationen werden nun seitenweise anhand dieser Regeln analysiert und es wird als Kenngröße die „Anzahl der Defekte pro Seite“ definiert. Dabei ist es genug mit einer Gruppe 10 Minuten lang ein oder zwei Seiten einer Requirement Spezifikation zu analysieren. Ich lasse ein paar Details aus, aber letzten Endes mittelt man die Werte der gefundenen Defekte, rechnet noch einen Tom-Erfahrungsfaktor drauf und kommt schnell auf Zahlen von 60-100 Defekten auf einer Seite einer Requirement-Spezifikation. Ein scheinbar durchaus normaler Wert, betrachtet man Spezifikationen, die ohne besonderes Augenmerk auf obige Regeln geschrieben wurden. Also 60-100 Defekte auf einer Seite mit ca. 300 Wörtern. (Tom hat auch extreme Beispiele genannt von 600 Defekten in 300 Wörtern.) Der Clou ist natürlich, dass wir hier über eine Seite reden. Sprich eine Requirement Spezifikation mit 10 Seiten hätte dann schon 600-1000 Defekte. 50% davon landen in der Software, d.h. wir haben 300-500 Fehler in unserer Software, die gefunden und gefixt werden müssen. Eine nahezu unmögliche und extrem teure Angelegenheit.
Diese Methodik sich (oder auch einem Kunden) potentielle Fehler in den Requirements vor Augen zu führen ist auf jeden Fall beeindruckend und auch definitiv mal einen Selbstversuch wert. Natürlich bietet Tom auch die passenden Lösung an, anhand einer stärker formalisierten Sprache, um Requirements zu beschreiben. Für mehr Infos kann man ja mal nach Tom’s Buch googeln. Sicherlich gibt es auch noch weitere Wege, hat man das Problem erstmal identifiziert. Danach sollte man dann den perfekten Input haben für eine „Executable Specification“ und dann haben wir auch wieder ein wenig Spass mit unseren agilen Methoden … ich denke Tom gönnt es uns und sieht tief in seinem innersten auch einige Vorteile darin ;-).
Chill out/Dinner Buffet – Oktoberfest
Besucht und geschrieben von: Andreas & Thomas
Das Dinner wird als Themenabend mit dem Hintergrund des Oktoberfests abgehalten. Nun sind wir beide nicht die grössten Oktoberfest-Fans und leider macht es die laute Musik auch recht schwierig noch ernsthafte fachliche Diskussionen zu führen. Aber was soll es, sowas ist immer Geschmackssache und es ist trotzdem eine nette Idee.
Wir ziehen uns etwas später in die Hotelbar zurück, um noch ein paar Gleichgesinnte zu finden und diesen „Monsterblogpost“ abzuschliessen. Das ist auch gleich noch eine kleine agile Retrospektive wert, ob es für den morgigen Tag nicht sinnvoller ist über den Tag verteilt mehrere kleinere Blogposts zu schreiben, quasi in kürzeren Iterationen. Das minimiert auch das Risiko, dass wir am Ende etwas produzieren, was niemand braucht, da es nach Ende der Konferenz nicht mehr fertig wird ;-).
War dieser Beitrag hilfreich?
Weitere Beiträge
von Thomas Jaspers
22.2.2019 Dein Job bei codecentric?
Jobs
Agile Developer und Consultant (w/d/m)
Alle Standorte
Weitere Artikel in diesem Themenbereich
Entdecke spannende weiterführende Themen und lass dich von der codecentric Welt inspirieren.
Gemeinsam bessere Projekte umsetzen.
Wir helfen deinem Unternehmen.
Du stehst vor einer großen IT-Herausforderung? Wir sorgen für eine maßgeschneiderte Unterstützung. Informiere dich jetzt.
Hilf uns, noch besser zu werden.
Wir sind immer auf der Suche nach neuen Talenten. Auch für dich ist die passende Stelle dabei.
Blog-Autor*in
Thomas Jaspers
Du hast noch Fragen zu diesem Thema? Dann sprich mich einfach an.
Du hast noch Fragen zu diesem Thema? Dann sprich mich einfach an.