Sie befin­den sich hier:Start­sei­te/Blog/Der Inte­gra­ti­ons­test im Kon­text des Entwicklungsprozesses

Der Integrationstest im Kontext des Entwicklungsprozesses

Lese­zeit: 7 Minu­ten
integration socialshare

Das Sys­tem steht kurz vor der Fer­tig­stel­lung – nur noch schnell tes­ten und dann kann es pro­duk­tiv ein­ge­setzt wer­den. Häu­fig star­ten die Akti­vi­tä­ten zum Inte­gra­ti­ons­test sehr spät in der Ent­wick­lung. Völ­lig über­ra­schend tre­ten dann Pro­ble­me auf, deren Ursa­chen in vor­ge­hen­den (ver­meint­lich abge­schlos­se­nen) Ent­wick­lungs­pha­sen liegen.

Mächtig komplex

Eine Pro­ble­ma­tik liegt dar­in, dass die Sys­te­me unse­rer Zeit immer mäch­ti­ger und kom­ple­xer wer­den. Soft­ware­an­wen­dun­gen sind nur sel­ten noch Stand-Alo­ne-Pro­gram­me, son­dern ver­net­zen Infor­ma­tio­nen aus diver­sen Quel­len (z.B. Apps nut­zen zahl­lo­se Web-Ser­vices Drit­ter). Hard­ware­pro­duk­te besit­zen kom­ple­xe Soft­ware­steue­run­gen, wel­che nun unter dem Schlag­wort „Inter­net der Din­ge“ ver­netzt wer­den (z.B. digi­ta­le Stell­wer­ke der Bahn). Selbst ver­meint­lich ein­fa­che All­tags­pro­duk­te wer­den für die beque­me Bedie­nung von über­all ver­netzt (z.B. Smart-Home-Pro­duk­te). Häu­fig han­delt es sich auch nicht mehr um ein homo­gen ent­wi­ckel­tes Sys­tem eines ein­zi­gen Ent­wick­lungs­teams, son­dern es wird von ver­teil­ten Spe­zia­lis­ten­teams ent­wi­ckelt. Fer­ner beinhal­tet das Sys­tem oft älte­re Vor­gän­ger-Sub­sys­te­me und Sub­sys­te­me von Drit­ther­stel­lern, sei es Hard­ware (HW) oder Soft­ware (SW). Wei­ter­hin wird in vie­len Pro­jek­ten eine Midd­le­wa­re ein­ge­setzt, wel­che die ein­zel­nen Kom­po­nen­ten zu einem kom­plet­ten Sys­tem ver­bin­det. Die­se gestie­ge­ne Kom­ple­xi­tät erfor­dert bei der Sys­tem­ent­wick­lung äußers­te Sorg­falt. Män­gel hier­bei kön­nen heut­zu­ta­ge nicht mehr durch ein­zel­ne sehr erfah­re­ne Ent­wick­ler aus­ge­gli­chen wer­den, denn die Kom­ple­xi­tät des Gesamt­sys­tems kann in der Tie­fe nicht mehr von einer Per­son erfasst werden.

„Mein“ Entwicklungsprozess

Erprob­te Ent­wick­lungs­pro­zes­se sind bereits aus­gie­big beschrie­ben, sei es das klas­si­sche Vor­ge­hens­mo­dell (V‑Modell) oder agi­le Ent­wick­lungs­pro­zes­se wie Scrum. In der Pra­xis stößt man jedoch nicht sel­ten auf lücken­haf­te Pro­zes­se, bei denen häu­fig nur die Pro­gram­mier­tä­tig­keit im Vor­der­grund steht. Begrün­det wird dies meist damit, dass die bewähr­ten Ent­wick­lungs­pro­zes­se „nicht pas­send“ für das jewei­li­ge Pro­jekt sei­en und des­halb ein eige­ner Pro­zess genutzt wird. Die­ser ist dann meist nicht näher defi­niert, geschwei­ge denn in einem Pro­jekt­hand­buch dokumentiert.

Gera­de in Pro­jek­ten, die „agil“ sein wol­len, wird das agi­le Mani­fest gera­de­zu miss­braucht, um unge­plan­tes Arbei­ten auf Zuruf zu recht­fer­ti­gen und Doku­men­ta­ti­on als gene­rell über­flüs­sig abzu­leh­nen. Eine erfolg­rei­che Sys­tem­ent­wick­lung erfor­dert es aber, dass die Spe­zia­lis­ten eines Teams Hand-in-Hand zusam­men­ar­bei­ten, damit der Entwick­lungs­prozess gelin­gen kann.

Wir emp­feh­len:

  • Defi­nie­ren Sie Ihren Entwick­lungs­prozess (z.B. Pro­jekt­hand­buch, „Sprint 0“ in Scrum)
  • Nut­zen Sie bewähr­te Entwicklungsmethoden
  • Doku­men­tie­ren und hin­ter­fra­gen Sie eige­ne Adaptionen

Abb. 1: Vor­ge­hens­mo­dell (V‑Modell) mit den Abstraktionsebenen

System mit Fundament

Kon­zen­trie­ren wir uns im Fol­gen­den zunächst auf das V‑Modell (sie­he Abb. 1) und die klas­si­sche Ent­wick­lung. Basis eines Sys­tems ist das kun­den­sei­tig erstell­te Las­ten­heft und dar­auf auf­bau­end die Sys­tem­spe­zi­fi­ka­ti­on, das Pflich­ten­heft. Die Kom­ple­xi­tät wird dann zer­legt über den Sys­tem­ent­wurf (Archi­tek­tur & Schnitt­stel­len­spe­zi­fi­ka­ti­on). Für kom­ple­xe Daten­schnitt­stel­len ist zu emp­feh­len die­se in sepa­ra­ten Doku­men­ten zu beschrei­ben, da die­se für jedes an der Kom­mu­ni­ka­ti­on betei­lig­te Sub­sys­tem genutzt wird und Schnitt­stel­len eben­falls einer Ver­sio­nie­rung unter­lie­gen, wenn sie wei­ter­ent­wi­ckelt wer­den. Für jedes Sub­sys­tem ist dann eine Sub­sys­tem­spe­zi­fi­ka­ti­on zu erstel­len, in der das jewei­li­ge Sub­sys­tem als „Black Box“ beschrie­ben wird. Ggf. kön­nen noch wei­te­re Ver­fei­ne­rungs­ebe­nen für Kom­po­nen­ten und Modu­le fol­gen. Für die­se gel­ten die fol­gen­den Grund­sät­ze selbst­ver­ständ­lich ebenso.

Es ergibt sich schnell eine gro­ße Men­ge an Doku­men­ten mit einer hohen Zahl von Anfor­de­run­gen. Bei sau­ber defi­nier­ten Pro­zes­sen und kla­ren Regeln für das Anfor­de­rungs­ma­nage­ment kann nun ein belast­ba­res Fun­da­ment für alle fol­gen­den Ent­wick­lungs­schrit­te gelegt wer­den. Idea­ler­wei­se ver­fei­nern sich die Anfor­de­run­gen von Ebe­ne zu Ebe­ne wie folgt:

  • Jede Anfor­de­rung hat eine Moti­va­ti­on, d.h. min­des­tens einen Vor­gän­ger (kein „Gold-Pla­ting“)
  • Jede Anfor­de­rung wird wei­ter ver­fei­nert, d.h. hat min­des­tens einen Nach­fol­ger (kei­ne Umsetzungslücken)
  • Stel­len Sie kla­re prüf­ba­re Regeln für die Ver­folg­bar­keit (Tracea­bi­li­ty) durch die Doku­men­te auf (z.B. Ver­lin­kung nur zwi­schen benach­bar­ten Ebenen)

Abb. 2: Sche­ma­ti­sche Dar­stel­lung der Anfor­de­rungs­tracea­bi­li­ty über drei Abstraktionsebenen

Abstraktionsebenen prüfen

Bei der strik­ten Umset­zung die­ser Regeln tre­ten im Bereich des Anfor­de­rungs­ma­nage­ments teil­wei­se Pro­ble­me auf. Ursa­che sind hier­für nicht zu strik­te Regeln, son­dern lücken­haf­te Anfor­de­run­gen oder die feh­ler­haf­te Zuord­nung der Anfor­de­rung zur Abs­trak­ti­ons­ebe­ne (= Spe­zi­fi­ka­ti­ons­do­ku­ment, sie­he Abb. 2). For­dert der Kun­de in sei­nem Las­ten­heft z.B. nur eine spe­zi­el­le Benach­rich­ti­gungs­in­for­ma­ti­on nach 1000 Betriebs­stun­den für die War­tung des Sys­tems, so meint er ver­mut­lich eine kom­ple­xe Dia­gno­se­schnitt­stel­le über die Sta­tus­in­for­ma­tio­nen, War­tungs- und Feh­ler­mel­dun­gen. Schnell lässt sich erah­nen, dass hier­für plötz­lich ein gro­ßes Bün­del an Anfor­de­run­gen auf System‑, Sub­sys­tem- und Schnitt­stel­len­ebe­ne benö­tigt wird.

Ob eine Anfor­de­rung kor­rekt dem Spe­zi­fi­ka­ti­ons­do­ku­ment zuge­ord­net ist, kann sehr gut geprüft wer­den, indem die kor­re­spon­die­ren­de Test­pha­se betrach­tet wird. Lässt sich die Anfor­de­rung wirk­lich in die­ser Pha­se tes­ten oder gehört Anfor­de­rung und Test in eine ande­re Abs­trak­ti­ons­ebe­ne? Wird z.B. in einer Schnitt­stel­len­spe­zi­fi­ka­ti­on gefor­dert, dass inner­halb von 100ms eine Anfra­ge kor­rekt beant­wor­tet wer­den muss, so ist die­se falsch zuge­ord­net. Es ist eine Anfor­de­rung an das Sub­sys­tem! Für die Schnitt­stel­len­spe­zi­fi­ka­ti­on ist zutref­fend, dass es einen Time­out nach 100ms gibt. Das befrag­te Sub­sys­tem soll beim Time­out eine qua­li­fi­zier­te Feh­ler­nach­richt gene­rie­ren und ver­sen­den. Das anfra­gen­de Sub­sys­tem muss die­se Feh­ler­nach­rich­ten behan­deln sowie eigen­stän­dig Time­outs fest­stel­len (falls die Kom­mu­ni­ka­ti­on unter­bro­chen ist).

Wir emp­feh­len die Prü­fung (sie­he Abb. 3):

  • Sind die Anfor­de­run­gen den rich­ti­gen Anfor­de­rungs­do­ku­men­ten zugeordnet?
  • Sind die Anfor­de­run­gen in der jeweils kor­re­spon­die­ren­den Test­pha­se prüfbar?

Robuste Systeme

Bei der Defi­ni­ti­on von Schnitt­stel­len emp­fiehlt es sich, bereits vor­han­de­ne, stan­dar­di­sier­te Schnitt­stel­len zu nut­zen. Die­se sind bewährt, gewäh­ren Inter­ope­ra­bi­li­tät, ermög­li­chen den ein­fa­chen Aus­tausch von Sub­sys­te­men (z.B. von einem ande­ren Her­stel­ler) und ver­ein­fa­chen die Ein­ar­bei­tung von neu­en Mit­ar­bei­tern. Bei der Spe­zi­fi­ka­ti­on von Schnitt­stel­len und Sub­sys­te­men soll­ten nicht nur die funk­tio­nal erlaub­ten Daten­wer­te im Funk­ti­ons­be­reich betrach­tet wer­den, son­dern der gesam­te Wer­te­be­reich, der tech­nisch über die­se Schnitt­stel­le über­mit­telt wer­den kann. Das Sub­sys­tem soll­te robust aus­ge­legt sein, so dass im Fal­le von feh­ler­haf­ten Signa­len bzw. inkon­sis­ten­ten Daten qua­li­fi­zier­te Feh­ler­mel­dun­gen zurück­ge­mel­det wer­den. Selbst­ver­ständ­lich muss das auf­ru­fen­de Sub­sys­tem adäquat auf mög­li­che Feh­ler reagieren.

Wir emp­feh­len:

  • Betrach­ten Sie den kom­plet­ten Wer­te­be­reich der Schnittstellen
  • Legen Sie Sub­sys­te­me robust aus

Integrationsstrategie

Bereits im Test­kon­zept soll­te fest­ge­legt wer­den, wel­che Inte­gra­ti­ons­stra­te­gie ange­wen­det wer­den soll. Beim „Big-Bang“ wer­den alle Sub­sys­te­me gleich­zei­tig inte­griert. Nach­tei­lig ist hier, dass die Fer­tig­stel­lung aller Sub­sys­te­me abge­war­tet wer­den muss und alle Feh­ler­wir­kun­gen gleich­zei­tig auf­tre­ten. Inkre­men­tel­le Stra­te­gien wie z.B. Top-down- bzw. Bot­ton-up-Inte­gra­ti­on ermög­li­chen es früh­zei­tig mit Inte­gra­ti­ons­tests zu begin­nen, aller­dings benö­ti­gen die­se Platz­hal­ter (für die feh­len­den Funk­tio­nen) bzw. Test­trei­ber (für den Auf­ruf). Die Wahl einer pas­sen­den Stra­te­gie hängt von den Pro­jekt­ge­ge­ben­hei­ten ab, jedoch soll­te die „Big-Bang“-Strategie ver­mie­den werden.

Wir emp­feh­len:

  • Nut­zen Sie – wenn mög­lich – inkre­men­tel­le Integrationsstrategien
  • Stim­men Sie die Inte­gra­ti­ons­tests mit den Zeit­plä­nen des Pro­jek­tes ab und aktua­li­sie­ren Sie die­se im Bedarfsfall

Fokussierung beim Integrationstest

Fokus des Inte­gra­ti­ons­tests ist die Über­prü­fung, ob die zu inte­grie­ren­den Sub­sys­te­me zusam­men kor­rekt funk­tio­nie­ren. Vor­aus­ge­setzt wird, dass die ein­zel­nen Sub­sys­te­me funk­ti­ons­tüch­tig sind, also die Sub­sys­tem­tests abge­schlos­sen sind. Damit gibt es eine strik­te Tren­nung zwi­schen die­sen bei­den Test­pha­sen! Beim Inte­gra­ti­ons­test muss ledig­lich geprüft wer­den, ob die Sys­te­me kor­rekt mit­ein­an­der kom­mu­ni­zie­ren. Typi­sche Feh­ler sind z.B. das Ver­tau­schen von Pins bei der Ver­ka­be­lung der Sub­sys­te­me, das Nicht­be­ach­ten von ein­ge­schränk­ten Wer­te­be­rei­chen, wel­ches ein Sub­sys­tem vor­aus­setzt oder neue bzw. geän­der­te Nach­rich­ten, da die Sub­sys­te­me unter­schied­li­che Ver­sio­nen einer Schnitt­stel­len­spe­zi­fi­ka­ti­on nut­zen. Kurz­um: Es ist beim Inte­gra­ti­ons­test zu prü­fen, ob die Sub­sys­te­me sich „ver­ste­hen“ und zusam­men­spie­len – nicht mehr und nicht weni­ger (sie­he Abb. 4).

Wir emp­feh­len:

  • Tren­nen Sie strikt die Test­pha­sen zwi­schen Sub­sys­tem- und Inte­gra­ti­ons­test von­ein­an­der ab
  • Beach­ten Sie die Test­rei­hen­fol­ge – zuerst die Sub­sys­tem­tests abschließen!

Abb. 4: Bei­spiel für Inte­gra­ti­ons­stra­te­gie mit den Sub­sys­tem­tests und Integrationstests

Frühzeitig testen – auch beim Integrationstest

Wie bei ande­ren Test­pha­sen auch, soll­ten die Akti­vi­tä­ten für den Inte­gra­ti­ons­test früh­zei­tig begin­nen (Pro­jekt­pla­nung – Test­kon­zep­ti­on – Anfor­de­rungs­er­mitt­lung & ‑abstim­mung – Sys­tem­ar­chi­tek­tur). Die Spe­zi­fi­ka­ti­on der Inte­gra­ti­ons­tests kann sofort nach Abschluss der Anfor­de­rungs­spe­zi­fi­ka­ti­on begon­nen wer­den. So kön­nen Feh­ler oder Lücken der Anfor­de­rungs­spe­zi­fi­ka­ti­on zeit­nah auf­ge­deckt werden.

Auch wenn für die fina­le Durch­füh­rung des Inte­gra­ti­ons­tests zuerst auf den Abschluss der Sub­sys­tem­tests gewar­tet wer­den muss, kön­nen vor­ab durch­ge­führ­te Inte­gra­ti­ons­tests von Vor­ver­sio­nen der Sub­sys­te­me (mit ein­ge­schränk­ter Funk­tio­na­li­tät) sinn­voll sein. Mit die­sen Vor­ab­tests kann sicher­ge­stellt wer­den, dass die Sub­sys­te­me min­des­tens bei den grund­le­gen­den Funk­tio­nen kor­rekt zusammenspielen.

Wir emp­feh­len:

  • Bepla­nen Sie die Test­ak­ti­vi­tä­ten ab Projektstart
  • Füh­ren Sie die jewei­li­gen Test­ak­ti­vi­tä­ten so früh wie mög­lich durch
  • Sichern Sie mit Vor­ab­tests die gene­rel­le Funk­ti­on der Schnittstellen

Agil? – Alles anders?

Nein! Prin­zi­pi­ell gibt es die Test­pha­sen auch bei der agi­len Ent­wick­lung. Inso­fern sind auch die Inte­gra­ti­ons­tests mit zu betrach­ten. Oft wer­den die­se aber impli­zit im Rah­men des Sys­tem­tests mit durch­ge­führt. Wer­den aber Inte­gra­ti­ons­tests expli­zit gefor­dert (z.B. auf­grund der Kri­ti­ka­li­tät des Sys­tems), so müs­sen die­se auch bei der agi­len Ent­wick­lung expli­zit berück­sich­tigt und doku­men­tiert wer­den. Auto­ma­ti­sier­te Tests sind unver­zicht­bar, damit Tests zügig für jedes Inkre­ment des Sys­tems durch­ge­führt wer­den kön­nen. In der Pra­xis anzu­tref­fen sind Pro­jek­te, deren Sub­sys­te­me agil ent­wi­ckelt wer­den, for­ma­le Abnah­men mit Inte­gra­ti­ons- und Sys­tem­tests sowie wei­te­re Auf­ga­ben für die Aus­lie­fe­rung (Doku­men­ta­tio­nen, Inbe­trieb­set­zung) jedoch „klas­sisch“ zu bestimm­ten Zeit­punk­ten stattfinden.

Fazit:

Zusam­men­fas­send lässt sich fest­stel­len, dass die Ent­wick­lungs­pro­zes­se vie­ler Pro­jek­te aus­schließ­lich die Pro­gram­mie­rung fokus­sie­ren. Anfor­de­run­gen und Tests wer­den ger­ne ver­nach­läs­sigt. Dies stellt jedoch ein unnüt­zes Pro­jekt­ri­si­ko dar, wel­ches ins­be­son­de­re in Zei­ten von Fach­kräf­te­man­gel, Fluk­tua­ti­on von Mit­ar­bei­tern und dem Wil­len nach Wie­der­ver­wen­dung von (Sub-) Sys­te­men unver­ständ­lich ist.

Sie möch­ten mehr erfah­ren? Neh­men Sie ger­ne Kon­takt zu mir auf. 

Kommentare und Feedback gerne via Social Media:

Blei­ben Sie auf dem Lau­fen­den – mit dem monat­li­chen sepp.med Newsletter: