Test cases: Warum nicht mal einfach?

Vor eini­gen Wochen hat­ten wir uns an die­ser Stel­le die Anwen­dungs­fäl­le („Use Cases“) in der Soft­ware­ent­wick­lung ange­schaut. Heu­te gehen wir den nächs­ten Schritt.

Kei­ne Angst, es wird ein­fa­cher.

Use Cases stel­len näm­lich die größ­te Hür­de bei der Erstel­lung von Soft­ware und ihrer Doku­men­ta­ti­on dar, denn ohne ein Pro­dukt vor Augen zu haben, muss sich der Ent­wick­ler (und der ihn beglei­ten­de Tech­nik­re­dak­teur) in die Rol­le eines durch­schnitt­li­chen Anwen­ders ver­set­zen kön­nen, des­sen „men­ta­les Modell“ erah­nen und dann in einem Use Case umset­zen. Auch aus die­sem Grund ähnelt es sehr dem Scrip­ten eines Dreh­buchs oder eines Thea­ter­stücks: Eine Idee muss in einem Script oder Expo­sé soweit ver­fei­nert wer­den, dass der Plot erkenn­bar ist. Das sind die Anwen­dungs­fäl­le. Hier ist viel Gesprächs­be­darf erfor­der­lich, um die Grund­idee des Stücks zu erhal­ten oder her­aus­zu­stel­len, die Anzahl der Prot­ago­nis­ten (in den Use Cases sind das die „Akto­ren“) zu ermit­teln und vor allem auch das Zeit­bud­get und den Finan­zie­rungs­be­darf zu ermit­teln. Noch ist ja nichts erstellt und es wur­de kein Ticket und kei­ne Lizenz ver­kauft.1

Steht das Script aber, dann geht es ans Dreh­buch. Und je bes­ser die Use Cases ermit­telt wur­den, des­to ein­fa­cher ist es, sie in „Test Cases“ umzu­set­zen.2

Der Testfall

Der Test Case ist eigent­lich nur die Auf­tei­lung der Akto­ren und ihrer Hand­lun­gen in par­al­le­le „Hand­lungs­strän­ge“. Das geht am leich­tes­ten mit einer Tabel­le.3

Pro­jekt­na­me

Pro­gramm

Test­fall

Pro­gramm star­ten

Test­zeit und -datum

24. Janu­ar 1984, 9:00 h

Zusam­men­fas­sung

Der Benut­zer star­tet das Pro­gramm.

Vor­aus­set­zun­gen

Das Pro­gramm ist instal­liert.

Ablauf

Schritt

erwar­te­tes Ergeb­nis

tat­säch­li­ches Ergeb­nis

Kom­men­tar

1

Auf “Start” kli­cken.

Das Pro­gramm star­tet.

2

Der Start­bild­schirm wird ange­zeigt.

3

Die Über­sicht der zuletzt bear­bei­te­ten Doku­men­te wird ange­zeigt.

Das obi­ge Bei­spiel eines ein­fa­chen Test­falls ist die Umset­zung des Anwen­dungs­falls in eine hand­lungs­fä­hi­ge Vor­la­ge, die einer Benut­zer­an­lei­tung sehr nahe kommt. Es geht in ers­ter Linie dar­um, in einer zwei­di­men­sio­na­len Über­sicht die jewei­li­gen Pro­zes­se der Akto­ren zu ord­nen, damit die Pro­gramm­ent­wick­ler eine kla­re Vor­stel­lung davon bekom­men, wel­ches Ergeb­nis eine bestimm­te Hand­lung haben soll und in der Test­si­tua­ti­on tat­säch­lich hat.

Wie in einem Dreh­buch für eine Sze­ne muss die­se meist mehr­mals geprobt wer­den, sprich: der Test­fall besitzt des­halb Platz für Test­da­tum und -zeit­punkt, weil die Test­per­son mit Hil­fe der Vor­la­ge die­sen Fall so oft durch­spielt, bis er feh­ler­frei funk­tio­niert. Stel­len sich Abwei­chun­gen her­aus, muss ent­we­der der Anwen­dungs­fall ange­passt wer­den und in der Fol­ge dann auch der Test­fall (das ist die schlech­te­re Lösung, denn das bedeu­te­te ja, dass man bei den Anwen­dungs­fäl­len geschlampt hat) – oder aber die Ent­wick­lung hat etwas über­se­hen.

Was aber ist mit den Optionen?

Wer sich mit Anwen­dungs­fäl­len beschäf­tigt, stellt – nicht nur in der Soft­ware – häu­fi­ger fest, dass es bei man­chen Pro­zes­sen meh­re­re Wege zum Ziel gibt: ent­we­der mit einer ande­ren Benut­zer­rol­le (mehr Rech­te), in einem ande­ren Umfeld – oder schlicht weil man dem Benut­zer Optio­nen zur Hand geben möch­te. Im Anwen­dungs­fall sind dies die „alter­na­ti­ven Pfa­de“ (alter­na­ti­ve paths).

Was macht man damit im Test­fall?

Ganz ein­fach: es ist ein neu­er Test­fall. Jeder Test­fall stellt einen alter­na­tiv­lo­sen, gerad­li­ni­gen Weg zum Ziel dar. Optio­nen müs­sen in einem eige­nen Test­fall erfasst wer­den.

Außer natür­lich, man möch­te sich das Leben selbst schwe­rer machen…


  1. An die­ser Stel­le endet nor­ma­ler­wei­se die Lei­dens­ge­schich­te der „Vapor­wa­re“, die mit viel Idea­lis­mus ange­kün­digt, aber nie rea­li­siert wer­den kann. 

  2. Wohl­ge­merkt: es han­delt sich nicht dar­um, die Ent­wick­ler in ein Kor­sett zu zwän­gen. Der Anwen­dungs­fall und der dar­aus fol­gen­de Test­fall müs­sen daher so all­ge­mein gewählt wer­den, dass die Ent­wick­ler genü­gend Spiel­raum erhal­ten, ele­gan­ten Code zu schrei­ben und eine „sau­be­re“ Benut­zer­füh­rung umzu­set­zen. 

  3. Selbst­re­dend funk­tio­niert die­se Vor­ge­hens­wei­se auch außer­halb der Soft­ware-Ent­wick­lung – das macht ja gera­de ihren Charme aus. Denn ob es um das Dru­cken eines digi­ta­len Doku­ments han­delt oder das Wech­seln eines Staub­sauger­beu­tels ist für den Pro­zess weit­ge­hend egal.