Effizientere agile Prozesse: Testfallbasierte Anforderungsdokumentation

Transkript

1 Effizietere agile Prozesse: Testfallbasierte Aforderugsdokumetatio Effizietere agile Prozesse: Testfallbasierte Aforderugsdokumetatio Aforderuge i Prosaform berge oft die Gefahr vo Missverstädisse ud Fehletwickluge, die auch agile Projekte i eie Schieflage brige köe. Hier hilft es, Aforderuge mithilfe vo Testfälle zu dokumetiere. Gerade i große oder verteilte Projekte, i dee eie effiziete Kommuikatio häufig schwierig ist, erreiche wir mit diesem Asatz immer wieder sehr gute Ergebisse die Resoaz der Beteiligte ist durchweg positiv. Dies hat us i de letzte Jahre motiviert, usere Erfahruge im treqs-asatz zu kosolidiere. Desse positive Effekt wolle wir i diesem Artikel vorstelle ud diskutiere. Ei charakteristisches Merkmal agiler Prozesse ist die kotiuierliche ud ege Zusammearbeit vo Kude ud Etwickler: Softwareetwicklug ist aus agiler Sicht ei gemeisamer Lerprozess. Nicht ur die Software etwickel wir weiter, auch user Verstädis des Projekts vertiefe wir auf alle Ebee ud wir kokretisiere oder korrigiere usere Zielvorstellug. Erketisse ud eue Idee sid us dabei willkomme ud wir berücksichtige sie im laufede Prozess. Dazu müsse sich Kude ud Etwickler i ihre uterschiedliche Rolle Sprit für Sprit über das gemeisame Ziel ud die kokrete ächste Aufgabe verstädige. Die zetrale Artefakte, über die sich Kude ud Etwickler dabei regelmäßig austausche, sid vor allem die User- Storys, die das Soll beschreibe, sowie die laufede Software. It s all about Feedback Die kotiuierliche ud systematische Abstimmug vo Soll- ud Ist-Stad ist ei weiteres charakteristisches Merkmal des agile Vorgehes. Feedback ist i agile Prozesse die etscheidede Kraft, die eie hohe Qualität ud Effiziez i der Umsetzug ermöglicht ud de Prozess i der Spur hält. Nur we die Qualität der Aforderuge ud der Umsetzug stimmt ud wir de Stad des Projekts exakt bestimme köe, sid wir i der Lage, im laufede Prozess auf geäderte Aforderuge agemesse zu reagiere, ohe das Projektziel aus de Auge zu verliere. I der Praxis beobachte wir aber, dass auch i agile Prozesse Qualität ud Effiziez icht garatiert sid. Falsch verstadee Aforderuge ud lagwierige Rückkopplugszykle köe agile Pro- Abb. 1: It s all about Feedback: Spritabahme gebe regelmäßig Orietierug. 26

2 zesse i eie Schieflage brige. Eie effiziete Kommuikatio ist esseziell für agile Projekte aber icht selbstverstädlich. I viele Projekte sid die Bediguge icht ideal ud Kommuikatiosprobleme sid wahrscheilich: Große Teams, verteilte Teams, Fluktuatio im Team (vgl. [Koc10]), Sprachbarriere, Zeitzoe, Zeitdruck, Komplexität ud viele weitere Faktore, dee wir i der Praxis begege, mache Missverstädisse wahrscheilich. Spritabahme gebe regelmäßig Orietierug I eiem gut fuktioierede agile Projekt stelle wir spätestes bei der Abahme am Ede eies Sprits fest, ob Aforderuge richtig verstade ud korrekt umgesetzt wurde. Diese regelmäßige Abahme i kurze Abstäde mache agile Projekte deutlich risikoärmer im Vergleich zu klassische Wasserfall-Projekte, i dee ur eie eizele Gesamtabahme am geplate Projektede steht. Über diese Spritabahme verschaffe wir us Sprit für Sprit ei geaues Bild des Projektstades (vgl. [Koc11]), auf desse Basis wir usere Plaug weiter kokretisiere oder korrigiere köe (siehe Abbildug 1). Diese Möglichkeit fehlt i klassische Wasserfall- Projekte. Natürlich wird auch i Wasserfall-Projekte die Qualität der Umsetzug im laufede Projekt geprüft, z.b. über Uit-Tests oder mauelle Etwicklertests, die auch dort agewedet werde. Jedoch sid diese Tests immer uter Vorbehalt zu sehe, da sie icht prüfe köe, iwieweit die Aforderuge richtig verstade worde sid Aforderuge köe ebe icht ur i der Umsetzug, soder auch im Testdesig missverstade werde. Auch i agile Projekte habe die Tests, die Etwickler im laufede Sprit durchführe, ur da eie verbidliche Aussage, we sie de Aforderuge exakt etspreche. Das letzte Wort hat der Kude Am Ede des Sprits sid wir i der Lage, Abweichuge vom Soll geau zu erkee. Dabei köe wir us auf die fachliche Expertise des Kude verlasse, der seie Abahmetests durchführt. Sofer bei der Spritabahme Missverstädisse auffalle, köe wir diese direkt kläre. Bewährt habe sich kurze, itesive Abahme-Workshops, i dee Etwickler ud Kude gemeisam die Software teste ud Probleme auf dem kurze Diestweg kläre. Doch auch i eiem agile Projekt gilt: We die Abahme fehlschlägt, muss das Umgesetzte aufwädig achgebessert werde. Das ist ieffiziet ud i der Summe letztedlich teuer, auch we die Fallhöhe am Ede eies Sprits geriger ist als beim Scheiter der Gesamtabahme am Ede eies Wasserfall-Projekts. Nachfrage ud Fehliterpretatioe wolle wir vermeide. Wir beötige daher eie Lösug, die es dem Kude ermöglicht, seie Aforderuge agemesse detailliert, vollstädig ud umissverstädlich zu beschreibe. Weiterhi soll diese Lösug de Etwickler i die Lage versetze, seie Ergebisse frühzeitig verbidlich zu überprüfe ud Fehletwickluge selbststädig zu erkee. Der treqs-asatz Am Ede des Sprits geligt us die Aufklärug vo Missverstädisse oder Fehler sehr gut. Wir habe us daher gefragt, ob wir dies icht auch scho vorher schaffe köe, de: We die Tests am Ede des Sprits helfe, Missverstädisse aufzukläre, da köe sie vorher helfe, Missverstädisse zu vermeide. Zu de Aufgabe des agile Teams gehört es, im Verlauf des Sprits Testfälle zu spezifiziere, sie zu dokumetiere ud durchzuführe. Warum mache wir das da icht bereits vor dem Sprit, um bereits währed des Sprits davo profitiere zu köe? Dabei soll der agile Charakter des Vorgehes icht verlore gehe. Wir möchte vor Spritbegi ur jee Testfälle erstelle, die wir bei desse Ede für die Spritabahme beötige. Die Devise No Big Upfrot Desig bleibt weiterhi bestehe. Die Geschichte Die grudsätzliche Idee der testfallbasierte Aforderuge habe wir 2005 i eiem verteilte agile Projekt erarbeitet, i dem Verstädigugsprobleme aufgrud vo Sprachbarriere immer wieder zu Missverstädisse führte. Das Etwicklerteam war als Folge davo erheblich mit Bug-Fixig beschäftigt ud der Kude mit lagwierige Spritabahme sowie dem Erfasse ud Nachteste vo Bugs. Beide Seite wedete zudem viel Zeit für das Kläre vo Aforderuge auf. Wir bemerkte aber durch das itesive Bug-Fixig, dass die Klickpfade, die wir bei der Erfassug vo Bugs agegebe habe, Der Mitarbeiter wählt eie Tag mit vorhadee Eiträge aus. Das System zeigt eie Übersicht mit alle Zeite, Aktivitäte ud Kommetare für diese Tag. Der Mitarbeiter kopiert alle diese Eiträge i de heutige Tag. Das System zeigt eie Übersicht für de heutige Tag. Die Übersicht ethält geau die Zeite, Aktivitäte ud Kommetare des zuvor gewählte Tages. Das System zeigt eie Meldug, wie viele Eiträge vo welchem Datum ach heute kopiert worde sid. Beispiel 1: Ei erster Akzeptaztest für die Beispiel-Story. es de Etwickler sehr leicht machte, die Aforderuge korrekt zu verstehe. Zudem machte sie das Nachteste für de Kude deutlich eifacher. Schließlich gige wir dazu über, auch die User-Storys prophylaktisch um solche Klickpfade zu ergäze, bis schließlich der größte Teil der Spezifikatio aus solche Pfade bestad. Die Aufwäde für Bug-Fixig ud Abstimmuge sake dadurch erheblich. Aufgrud userer Überleguge ud der immer wieder sehr positive Erfahruge habe wir diese Asatz (als agile Coachs oder produktive Projektmitglieder) auch i weitere agile Projekte verfolgt ud ausgearbeitet. Die Form Eie klassische User-Story hat die Form: Ich als Aweder i der Rolle möchte tu, um Für ei Zeiterfassugs-System köte eie User-Story also beispielsweise laute: Als Mitarbeiter möchte ich alle Zeite, Aktivitäte ud Kommetare eies Arbeitstages i de aktuelle Tag kopiere ud da apasse köe, um bei ählich strukturierte Arbeitstage möglichst weig eigebe zu müsse. Im treqs-asatz (test-based requiremets, gesproche tracks ) defiiere wir Aforderuge mithilfe vo relevate Akzeptaz-Testfälle aus Awedersicht. Für die Zeiterfassugs-Story liegt ei zetraler Akzeptaztest ahe (siehe Beispiel 1: Der Mitarbeiter wählt eie Tag mit vorhadee Eiträge aus). Weitere Akzeptaztestfälle köte sei: 02/

3 Effizietere agile Prozesse: Testfallbasierte Aforderugsdokumetatio Der Mitarbeiter wählt eie Tag mit vorhadee Eiträge aus. Das System zeigt eie Übersicht mit alle Zeite, Aktivitäte ud Kommetare für diese Tag. Das System zeigt eie Butto, um alle diese Eiträge i de heutige Tag zu kopiere, sofer der heutige Tag och keie Eiträge ethält, aderfalls ist der Butto deaktiviert. Der Mitarbeiter drückt auf diese Butto. Das System zeigt eie Übersicht für de heutige Tag. Die Übersicht ethält geau die Zeite, Aktivitäte ud Kommetare des zuvor gewählte Tages. Das System zeigt eie Meldug, wie viele Eiträge vo welchem Datum ach heute kopiert worde sid. Beispiel 2: Eie geauer gefasste Versio des Akzeptaztests für die Beispiel- Story. Der Mitarbeiter wählt eie Tag ohe Eiträge aus. Der Mitarbeiter wählt de heutige Tag aus. Der Mitarbeiter wählt eie Tag mit fehlerhafte Eiträge aus. Der heutige Tag ethält bereits Eiträge. Der erste Akzeptaztestfall wird we auch icht i alle Details bereits aus dem Prosatext der User-Story deutlich. Bei de weitere Akzeptaztestfälle ist das icht so. Es ist für de Kude auch beim Schreibe eies Prosatextes uerlässlich, alle relevate Awedugsfälle abzudecke. Idem wir sie als Testfälle dokumetiere, mache wir sie explizit. Dem Kude stehe zusätzliche Forme der Dokumetatio weiterhi offe. Dies köe beispielsweise Mockups sei oder Prosatexte, die Grudprizipie ud Überblickswisse vermittel, Hitergrüde erkläre oder die fachliche Motivatio beschreibe. Ebeso sid Diagramme, Tabelle, Skizze oder ebe auch die klassische User-Story-Prosatexte möglich. Alles, was zur Klärug der Aforderuge beiträgt, ist weiterhi erlaubt. Usere Devise beim treqs-asatz ist: ergäze, icht ersetze! treqs-testfälle sid Happy-Paths Im Rahme eies Softwareetwicklugsprojekts trifft ma ormalerweise auf vier Arte vo Testfälle: 1. Die Positiv-Testfälle bilde de gewüschte Normalablauf ab, üblicherweise, wie ih sich der Kude vorstellt. Diese Happy-Paths köe auch egative Ergebisse beschreibe (z.b. Azeige eies Warhiweises), solage es das gewüschte Ergebis aus Kudesicht ist. Der Kude gibt seie zetrale Positiv-Testfälle vor, die vo Testexperte um gegebeefalls ötige Testfallvariate ergäzt werde. Zumidest die zetrale Positiv-Testfälle sollte für eie Abahme durchgeführt werde, da hierüber geprüft wird, ob die Software ihre Zweck erfüllt. 2. Die Negativ-Testfälle werde vo de Testexperte im Projekt verfasst. Sie ergäze die Positiv-Testfälle um alle Aspekte, die zum Aufdecke vo Abweichuge ötig sid. Beispiele hierfür wäre überschrittee Grezwerte oder die Verwedug falscher Datetype (z. B. Buchstabe astelle vo Zahle). 3. Die Etwickler im Projekt spezifiziere die techische Testfälle. Normalerweise sid dies Kompoetetests. Hier stehe die techische Details der Umsetzug im Fokus, die dem Kude oft ubewusst sid. 4. Die icht-fuktioale Testfälle prüfe Aspekte außerhalb der fuktioale Eigeschafte, beispielsweise Performace oder Usability. Diese werde oft ebefalls vo de Testexperte verfasst. Die letzte drei Testfall-Arte basiere auf der Aforderugsdokumetatio des Kude, werde aber icht vo ihm verfasst. Die Autore dieser Testfälle köe die Aforderuge atürlich missverstehe. Missverstadee Aforderuge sid im Testfall-Etwurf besoders tückisch, da Testfälle, die Aforderuge icht korrekt wiedergebe, eie falsche Sicherheit vorspiegel ud damit i die Irre leite. Werde die Aforderuge über treqs-testfälle beschriebe, ist die korrekte Umsetzug der fachliche Kerfuktioalität gut abgesichert ud Irrtümer betreffe eher adere Aspekte (z.b. techische), die icht im Kompetezbereich des Kude liege. Wie fide ich geeigete Testfälle? Bei der Eiführug vo treqs i eiem Projekt beötige die Autore der treqs-testfälle afags Aleitug beim Schreibe. Das Schreibe vo Aforderuge ist eie sehr aspruchsvolle Tätigkeit. We es a das Formuliere geht, fehlt dem Kude oft eie Vorstellug davo, welche Iformatioe der Etwickler im Eizele beötigt, ud er ka dies oft auch icht ach eigeem Ermesse beurteile. Eie bewährte Daumeregel ist, sich beim Dokumetiere eier Aforderug die folgede Frage zu stelle: Was würde ich am Ede des Sprits kokret ausprobiere, um mich davo zu überzeuge, dass diese Aforderug ach meie Vorstelluge umgesetzt wurde? Diese Frage gibt dem Kude eie sehr kokrete Orietierug bei der Formulierug der Aforderuge. Vor allem ist er i der Lage, diese Frage ach eigeem Ermesse zu beatworte. Gleichzeitig et er so die Details, die ihm wichtig sid ud die der Etwickler für die korrekte Umsetzug beötigt. We der Kude de Beispiel-Testfall zum Zeiterfassugssystem och eimal aschaut ud sich die obige Frage stellt, bemerkt er evetuell, dass Teile des Testfalls geauer gefasst werde müsse. Um die Beutzug möglichst eifach zu halte, möchte der Kude Eiträge z.b. ur i de heutige Tag kopiere köe ud dazu ur auf eie Butto drücke müsse. Also passt der Kude de Testfall a (siehe Beispiel 2). So ist sichergestellt, dass Eiträge icht i eie beliebige Tag kopiert werde köe, dass ur ei eizeler Klick otwedig ist ud dass keie problematische Kollisioe vo Eiträge auftrete köe. Kompliziertere Lösuge, die i der Umsetzug, im Test ud i der Wartug teurer wäre, schließt der Kude damit i diesem Pukt aus. Wäre die Spezifikatio hier ugeauer, würde die Etwickler etweder selbst kreativ werde ud würde dabei auch fachlich möglicherweise irrelevate Soderfälle berücksichtige müsse oder sie würde im laufede Sprit versuche, die Aforderuge mit dem Kude zu kokretisiere. Eigeschafte eies gute treqs-testfalls Ei Testfall beschreibt die Aktioe eies Beutzers ud die darauf folgede Systemreaktioe Schritt für Schritt. Ei guter treqs-testfall (geau geomme jeder gute Testfall) erfüllt dabei folgede Eigeschafte: Er ist relevat: Die geprüfte Aforderug ist kokret ud wichtig. 28

4 Vorbedigug: Es existiere keie Eiträge für de heutige Tag. Es existiert midestes ei Tag mit midestes eiem Eitrag. Alle Eiträge dieses Tages sid gültig. Der Mitarbeiter wählt eie Tag mit ausschließlich gültige Eiträge aus. Das System zeigt eie Übersicht mit alle Zeite, Aktivitäte ud Kommetare diese Tag. Das System zeigt eie Butto, um alle diese Eiträge i de heutige Tag zu kopiere. Der Mitarbeiter drückt auf diese Butto. Das System zeigt eie Übersicht für de heutige Tag. Die Übersicht ethält geau die Zeite, Aktivitäte ud Kommetare des zuvor gewählte Tages. Das System zeigt eie Meldug, wie viele Eiträge vo welchem Datum ach heute kopiert worde sid. Beispiel 3: Die fertige Versio des Akzeptaztests für die Beispiel-Story. Er ist überprüfbar: Beutzeriteraktio ud Systemreaktio sid geau aufgeführt. Er ist exemplarisch: Die Schrittfolge ist eideutig ud verzichtet auf Verzweiguge. Er ist durchführbar: Er ist so detailliert wie ötig ud so klar wie möglich. Er ist wiederholbar: Hierzu gehört, dass kokrete Testdate agegebe werde. Er ist eifach: Er ethält weder Umwege och uötige Erkläruge. Mit diese Qualitätsmerkmale im Hiterkopf stellt user Beispielkude schell fest, dass der Testfall zum Zeiterfassugssystem och weiter verbessert werde muss. Der Testfall ist relevat ud auch eifach gehalte. Die Beutzeraktioe ud Systemreaktioe sid aus fuktioaler Sicht i de Teile, die dem Kude wichtig sid, geau beschriebe. Also ist der Test auch ausreiched überprüfbar. Der Testfall ist jedoch och icht exemplarisch, da er im dritte Schritt eie Verzweigug ethält, für de Fall, dass für de heutige Tag bereits Eiträge existiere. Bei der Durchführbarkeit ud Wiederholbarkeit fällt auf, dass die Frage offe bleibt, ob im erste Schritt auch ugültige Eiträge erlaubt sid. Der Kude bessert seie Testfall etspreched ach (siehe Beispiel 3) ud etscheidet sich für die Variate, i der der heutige Tag keie Eiträge ethält. Die adere Variate beschreibt der Kude da i eiem separate Testfall. Im Beispiel sid keie exakte Testdate agegebe. Da der Ablauf des Beispiel- Testfalls icht vo de kokrete Eiträge abhägt, ist das hier ukritisch. I adere Fälle ka es otwedig sei, sehr geaue Date azugebe, z.b. i eiem Testfall, der die korrekte Berechug der Gesamtstude eies Tages beschreibt. Der Testfall ist durchführbar ud wiederholbar, sofer die Vorbediguge erfüllt sid. Diese Vorbediguge herzustelle, ka bei der kokrete Durchführug schwierig sei. Direkt wiederholbar ist der Beispiel-Testfall z.b. ur, we evetuell vorhadee Eiträge des heutige Tages gelöscht werde köe. Eie eifache Lösug ka sei, die Beispiel-User-Story erst ach der Umsetzug der User-Story zum Lösche vo Eiträge eizuplae. Gegebeefalls ka es aber sehr aufwädig sei, die Vorbediguge eies Testfalls zu erfülle, oder es ist über eifache Beutzeraktioe sogar umöglich. So ka der Moatsabschluss i eiem Zeiterfassugssystem z.b. ur über ei Zurücksetze der Datebak zurückgeomme werde. Die Vorbediguge für Tests herzustelle, ist ach userer Erfahrug vor allem ei Problem i Projekte, i dee ur weig mauell getestet wird ud eie Ifrastruktur dafür fehlt. I Projekte, i dee wir de treqs-asatz vo Projektbegi a verfolgt habe, kote wir eie solche Ifrastruktur ach Bedarf schrittweise aufbaue. Bewertug des treqs-asatzes Der treqs-asatz wirkt sich bei all seier Eifachheit a viele Stelle des Etwicklugsprozesses ud für alle Projektbeteiligte sehr positiv aus. Kommuikatio Es hat sich gezeigt, dass Testfälle vo alle beteiligte Rolle gleichermaße gut ver- stade werde icht zuletzt, weil sie vo der Form her vertraut sid. Ahad der Testfälle etsteht frühzeitig ei gemeisames Verstädis der Fachlichkeit des zu bauede Systems ud eie gemeisame Sprache ka sich etabliere. Diskussioe über die Umsetzug sid bereits mit relevate Ergebisse möglich, och bevor die Umsetzug eier User-Story begoe hat. Auch spät im Prozess Beteiligte, wie z.b. Tester, köe zu eiem sehr frühe Zeitpukt Feedback gebe ud sich i die Kozeptio eibrige. Zudem ist die Umsetzug eier User-Story ahad der Testfälle vo jedem umittelbar überprüfbar. Selbst Persoe, die icht a der Kostruktio beteiligt sid, köe sich so kompetet zum Ergebis äußer. Das Team kommuiziert auf Basis der Testfälle wirkugsvoller ud reibugsloser ud rückt äher zusamme. Die Effiziez des Asatzes zeigt sich im laufede Prozess. Detaillierugsgrad der Aforderugsdokumetatio Dadurch, dass treqs-testfälle am System durchführbar sei solle, liegt der Fokus des Autors der User-Story beim Schreibe stark auf dem Umgag des Aweders mit dem System ud de kokrete fuktioale (ud zum Teil auch icht-fuktioale) Details. Diese werde etspreched geau beschriebe ud falle i der Regel auch icht ubeabsichtigt uter de Tisch. Dies gilt auch für selbstverstädliche Basis-Features, die gegeüber Leistugs- ud Begeisterugs-Features (vgl. [Ka84]) gere übersehe werde. Das Ergebis sid User-Storys, dere Detaillierugsgrad de Iformatiosbedarf bei Etwurf, Umsetzug ud Abahme des Systems geau trifft. Dadurch sikt i der Folge der Kommuikatiosbedarf, der sost afiele, um Uklarheite oder Missverstädisse bezüglich der Aforderuge im Nachhiei zu beseitige. Aus de treqs-testfälle wird der kokrete Eisatzkotext vo System-Features deutlich. Er ermöglicht es alle Beteiligte, de fachliche Bedarf hiter de Features ausreiched zu verstehe ud gegebeefalls ugeaue Formulieruge korrekt zu iterpretiere. All das reduziert Nachfrage ud Fehletwickluge. Qualitätssicherug Der treqs-asatz etlastet Etwickler ud Tester dari, Aforderuge richtig zu deute oder über Rückfrage ermittel zu müsse, um geeigete Akzeptazkriterie 02/

5 Effizietere agile Prozesse: Testfallbasierte Aforderugsdokumetatio abzuleite. Die Autoreschaft für die zetrale Testfälle des Systems liegt im treqs- Asatz grudsätzlich auf der Fachseite, die ihre eigee Aforderuge ud Akzeptazkriterie am beste ket. Seites der Etwickler ud Tester ist keie Iterpretatio bezüglich der Akzeptazkriterie ötig. Gleichzeitig lasse sich die treqs-testfälle aufgrud ihrer Testfallstruktur gut qualitätssicher, da formale Mägel dara meist für alle Beteiligte offesichtlich sid. Der treqs-asatz garatiert die Testbarkeit der Aforderuge, da die wichtigste Basis-Testfälle vo der Fachseite scho so früh wie möglich vorgegebe werde. Sie köe da vo Etwickler ud Tester direkt verwedet werde ud vergleichsweise leicht um techische Tests, Testvariatioe ud Negativ-Tests ergäzt werde. Der ötige Aufwad für die Testfallerstellug sikt hierdurch erheblich. Auch die Dokumetatio vo Bugs im Rahme vo Tests wird durch de treqs- Asatz deutlich eifacher. Bugs sid für alle Beteiligte offesichtlich zu ihrer Rekostruktio muss i der Regel ur auf de betroffee treqs-testfall verwiese werde. Bei der spätere Abahme durch de Auftraggeber helfe die kokrete treqs- Testfälle, da über sie der Zustad des abgelieferte Systems direkt überprüft werde ka. Ahad vo Prosatexte ist es ach userer Erfahrug sehr schwierig zu etscheide, iwieweit eie Umsetzug der Spezifikatio etspricht. Im Extremfall ka dies eie subjektive Etscheidug sei. treqs-testfälle ermögliche eie objektive Bewertug des aktuelle Etwicklugsstads gegeüber de Aforderuge. Der Fokus vo treqs liegt auf de Aforderuge für de aktuelle Sprit. Deoch köe treqs-testfälle weiter verwedet ud ach der Abahme i eie Bestad vo Regressiostestfälle aufgeomme werde. Häufige Kritikpukte Wie positiv sich treqs auf die Projektarbeit auswirkt, spürt das gesamte Team sehr schell, sobald die Fachseite damit begit, Aforderuge Testfall-basiert aufzuschreibe. Bevor es soweit ist ud treqs im praktische Eisatz für sich selbst spreche ka, müsse wir im Vorfeld auf ei paar typische Vorbehalte geauer schaue. Extra-Aufwad Der Asatz wirkt zuächst aufwädig ud ist es im Vergleich mit der oft gelebte Praxis sicher auch auf de erste Blick, isbesodere weil ach userer Beobachtug vo der Fachseite oftmals vollstädig auf die Formulierug vo explizite Akzeptazkriterie verzichtet wird. Die Aforderugsdokumetatio gestaltet sich subjektiv aufwädiger, da die Defiitio der Testfälle bereits beim Schreibe der User-Storys hizukommt. Dies wird afags häufig kritisiert, zumal das Schreibe der Testfälle eie aspruchsvolle ud etspreched aufwädige Tätigkeit ist. Deoch ist dieses Vorgehe sivoll ud erzeugt bei geauerem Hisehe keie zusätzliche Aufwäde: Uabhägig vom treqs-asatz muss eie gute Aforderugsdokumetatio alle relevate Awedugsfälle berücksichtige. Eie gute Qualitätskotrolle erfordert die Defiitio vo weitere, viel geauere ud umfassedere Tests, die zudem vo der Fachseite validiert werde müsse. Spätestes zur Abahme muss sich die Fachseite überlege, durch welche Tests sie sich davo überzeuge will, dass die Umsetzug de Aforderuge etspricht. Die Defiitio geau dieser Tests ziehe wir im treqs-asatz ach vore, also vor die Umsetzug. Die schiere Mege der Testfälle Ei weiterer Kritikpukt ist, dass die schiere Mege der Testfälle ab eiem Pukt uübersichtlich wird. Dies ist jedoch ur der Fall, we treqs-testfälle als Regressiostestfälle weiterverwedet werde. Dasselbe Problem tritt aber auf, we wir diese Regressiostestfälle im Nachhiei erstelle. Ei geeigetes Testmaagemet ist immer uerlässlich uabhägig vom treqs-asatz. Hoher Pflegeaufwad der Testfälle Äderugs- ud Ergäzugsbedarf a de Testfälle fällt jeweils ur für de ächste Sprit a. Es geht im treqs-asatz icht darum, de gesamte Bestad a Testfälle zu pflege ud aktuell zu halte. Eie vollstädige Spezifikatio ist im Rahme eies agile Prozesses bekatermaße icht otwedig ud auch icht erstrebeswert. Deoch gilt: Testfälle sid im Gegesatz zu Prosatext aufgrud ihrer übersichtliche Aufteilug i eizele Schritte vergleichsweise äderugsfreudlich ud damit icht schlechter zu pflege. Im Laufe des Projekts ka der Kude vorhadee Testfälle gaz pragmatisch als Vorlage für ähliche Aforderuge wiederverwede. Falls er Erweiteruge oder Soderfälle beötigt, so ka er diese später über zusätzliche Testfälle leicht achpflege. Frühes Commitmet der Fachseite urealistisch Ei Softwareprojekt ka ur erfolgreich sei, we die Fachseite verbidlich zu ihre Aforderuge steht. Bei agile Projekte ist dies miimal für die Aforderuge des ächste Sprits ötig. Im Falle des treqs-asatzes ist zudem die Bereitschaft der Fachseite otwedig, sich frühzeitig auf die Testfall-Spezifikatio eizulasse. Falls die Fachseite icht verbidlich zu ihre Aforderuge steht oder stehe ka, merke wir es im treqs-asatz also sehr viel früher als i adere Asätze. Damit köe wir ei wichtiges Projektrisiko vielleicht icht eifacher löse, aber frühzeitig agehe. Testfälle werde schell komplex Das Schreibe (ud später das Durchführe) vo Testfälle macht Mühe. Es gilt: Je eifacher das System, desto eifacher sid die Testfälle. Eie Aforderug, die eie aufwädige Lösug erfordert, beötigt meist auch aufwädige Testfälle. Das motiviert de Kude stark, das Desig eifach zu halte. Komplizierte Lösuge, wie sie z.b. durch Altsysteme vorgegebe werde, erscheie weig attraktiv, we sie durch aufwädige Testfälle beschriebe werde müsse. Die bloße Neug eizeler Features mit Verweis auf das Altsystem ist im treqs-asatz keie Optio. Das ist ei wichtiger psychologischer Pukt, der sehr zur Effiziez des treqs-asatzes beiträgt. Eifachheit loht sich früh für alle Beteiligte. Abgrezug zu ähliche Asätze Der Asatz, User-Storys bereits vor der Umsetzug mit Abahmekriterie zu versehe, ist grudsätzlich icht eu. Die Form solcher Akzeptazkriterie bewegt sich dabei vo freie Prosaformulieruge bis hi zu formale Testfall-Spezifikatioe, die z.b. durch Tools wie FitNesse ausführbar sid. Der treqs-asatz defiiert eie Formalisierugsgrad, der dazwische liegt: Er ist formal geug, um umissverstädlich zu sei, ud frei geug, um i der Sprache der Aweder ud bereits im Vorfeld eier kokrete Umsetzug formuliert werde zu köe. Das ermöglicht es, treqs icht ur für eizele Aspekte des Prozesses (wie z.b. die Qualitätskotrolle) zu verwede, soder a alle Stelle des Prozesses sivoll eizusetze. Test-Drive-Developmet Der treqs-asatz ähelt dem Test-Drive- Developmet (TDD), da er ebefalls mit 30

6 dem Schreibe der Tests begit. Allerdigs geht er i eiem Pukt wesetlich darüber hiaus: Der treqs-asatz setzt bereits im Requiremets-Egieerig a ud icht wie TDD erst im Rahme der softwaretechische Umsetzug. Zudem beschreibe treqs-testfälle die fachliche Aforderuge a das Gesamtsystem ud icht die Aforderuge a eie eizele techische Kompoete (Uit) des Systems. treqs-testfälle ethalte bereits viele hilfreiche Iformatioe, die TDD oder gaz allgemei das Schreibe vo Uit-Tests erleichter: So ka das Verhalte eizeler Kompoete im Rahme der i treqs beschriebee Testszearios betrachtet werde, um daraus wesetliche Teile der kokrete Uit-Tests iklusive Testdate abzuleite. Mauelle Etwicklertests werde durch treqs deutlich erleichtert ud garatiere gleichzeitig ei verbidliches Feedback. Zudem köe die Testfälle aus de treqs vo de Etwickler umittelbar ud selbstädig durchgeführt werde. Ei eg a TDD agelehtes Verfahre des treqs-asatzes ist es zum Beispiel, die treqs- Testfälle Schritt für Schritt zum Laufe zu brige. Die techische Umsetzug ist erfolgreich, we der Etwickler alle treqs- Testfälle erfolgreich durchführe kote. Das ist eie wichtige Qualitätssicherugsmaßahme im laufede Sprit, welche die fachliche Abahme am Ede des Sprits erleichtert. Use-Cases Use-Cases gehöre zu de übliche Wege, Aforderuge i eiem Softwareprojekt zu defiiere. treqs-testfälle stelle wie Use-Cases eie Auswahl vo repräsetative Szearios bezüglich der dokumetierte Aforderug dar. Beide sid i der Sprache der Aweder verfasst. Allerdigs sid treqs-testfälle kokreter als Use-Cases es sid quasi am System durchführbare Use-Cases, i dee die erwartete Reaktio des Systems geau spezifiziert wird. Literatur & Liks [Koc10] J. Koch, J. Sauer, A Task-Drive Approach o Agile Kowledge Trasfer, i: Agility Across Time ad Space, Spriger-Verlag 2010, siehe: [Koc11] J. Koch, S. Middeke, Trasparez ud Qualitätskotrolle i agile Projekte: Agile Selbstheilugsmechaisme, i: Javamagazi, 7/2011, siehe: [Ka84] N. Kao, Attractive Quality ad Must-be Quality, i: Joural of the Japaese Society for Quality Cotrol, H. 4, 1984 lege de Fokus aber auf die Automatisierug der Testfälle. Im treqs-asatz schließe wir die Automatisierug vo Akzeptaztests als zusätzliche Optio icht aus, de wir fide Testautomatisierug gut ud wichtig. Wir stelle sie aber aus zwei Grüde explizit icht i de Fokus: Zum eie sid maschielesbare Testfälle ach userer Erfahrug icht für jede meschliche Autor oder Leser gleichermaße geeiget, isbesodere icht vo der Fachseite, der die Verwedug vo Schlüsselwörter oft komplizierter erscheit als der Etwicklerseite. Zum adere ud das wiegt och schwerer solle treqs-testfälle i Bereiche vage bleibe dürfe, die der Kude icht exakt spezifiziere möchte sei es, um der Kreativität ud Expertise der Etwickler Raum zu gebe oder um Altbekates icht uötig geau beschreibe zu müsse. Automatisierte Testfälle lasse diese wichtige meschegerechte Ugeauigkeit icht zu. Wir möchte der Fachseite mit treqs ei Mittel a die Had gebe, mit dem es ihr leicht fällt, ihaltlich sehr gute Aforderugstexte zu schreibe. Zumeist tut sie es da auch gere. Die Autore Fazit Die Dokumetatio vo Aforderuge ud die Verstädigug zwische Kude ud Etwickler gehöre zu de größte Herausforderuge i eiem Softwareprojekt. Die meiste Aforderuge sid fuktioal ud basiere auf Beutzeriteraktioe. Derartige Aforderuge lasse sich sehr gut als Testfälle beschreibe, selbst we die Aforderuge als Prosatext schwer zu fasse wäre. Der treqs-asatz ist ei eifacher ud bewährter Weg, um Aforderuge als Testfälle zu dokumetiere ud die Kommuikatio ud Kooperatio im Team frühzeitig zu uterstütze. Er führt zu weiger Fehletwickluge ud Rückfrage a die Fachseite, ermöglicht verbidliche Etwicklertests ud damit eie erwartugskoforme Umsetzug. Dies spart Aufwäde, gerade i große, uübersichtliche Projekte ud i Teams, i dee die Kommuikatio schwierig ist. We Sie eugierig geworde sid, da ergäze Sie doch eie User-Story eimal um eie erste Happy-Path. Fage Sie klei a ud schaue Sie auf de positive Effekt. Sostige Asätze Darüber hiaus gibt es och zahlreiche weitere Asätze, die sich ebefalls mit der frühe Verwedug vo Akzeptazmerkmale beschäftige. Aufgrud der Name liegt ei Vergleich mit Acceptace Test Drive Developmet (ATDD), Behavior Drive Developmet (BDD) ud Specificatio by Example ahe. Alle drei Asätze weise zwar auf die Eigug vo Testfälle zur Spezifikatio hi, Jör Koch (joer.koch@treqs.org) ist Seior Software-Architekt bei der C1 WPS GmbH. Er leitet ud coacht seit 2001 agile Projekte ud besitzt lagjährige Erfahrug i der Eiführug ud im Tuig agiler Prozesse. Sebastia Middeke (sebastia.middeke@treqs.org) ist Seior Cosultat bei der Cogizat Solutios GmbH. Er berät seit 2005 agile Projekte zu Theme des Test- ud Aforderugsmaagemets ud coacht die Eiführug agiler Prozesse. 02/