Sie befin­den sich hier:Start­sei­te/Agi­ler Soft­ware­test, Cus­to­mer Jour­ney, Health­ca­re/Modell­ba­sier­tes Tes­ten bei Siemens Health­ca­re MR

Success Story: Modellhafte Verbesserung in einer Testabteilung

Modellbasiertes Testen bei Siemens Healthcare MR

Am Ende einer Ent­wick­lung bleibt kaum noch Zeit für den Test. Teu­re Auto­ma­ti­sie­rungs­werk­zeu­ge kom­men nicht zum Ein­satz, da nie­mand die Zeit hat­te, sich mit deren auf­wen­di­gen Kon­fi­gu­ra­ti­on zu beschäf­ti­gen. Alles, was an gründ­li­cher Pla­nung und Test­ma­nage­ment vor­ge­dacht war, wird durch has­ti­ge Last-Minu­te-Ände­run­gen oder ‑Ergän­zun­gen überlagert.

Dabei wird seit vie­len Jah­ren an ver­schie­de­nen Stel­len der SW-Ent­wick­lung ent­we­der an der Stei­ge­rung der Effek­ti­vi­tät oder der Redu­zie­rung des Auf­wands gear­bei­tet. Las­sen sich aber unter den gege­be­nen Rah­men­be­din­gun­gen gleich­zei­tig die Effek­ti­vi­tät und die Effi­zi­enz steigern?

MBTsuite @ Siemens

Der konkrete Anwendungsfall

Für die bild­ge­ben­de Dia­gnos­tik mit­hil­fe der Kern­spin­to­mo­gra­fie exis­tie­ren SW-Pake­te für ver­schie­de­ne Anwendungsfelder:

  • Erzeug­te Bil­der wer­den durch eine Qua­li­täts­si­che­rung erst­ma­lig auf den Erfolg einer Auf­nah­me über­haupt geprüft.
  • Die­se wer­den anschlie­ßend zum Befund durch den jewei­li­gen Fach­arzt (z. B. Radio­lo­ge, Ortho­pä­de, Uro­lo­ge etc.) über ein Netz­werk an die ent­spre­chen­de Fach­ab­tei­lung geschickt.
  • Die Fach­ärz­te nut­zen SW-Modu­le, die ihnen durch spe­zi­el­le Fil­ter oder Ein­stel­lun­gen den fach­män­ni­schen Blick auf den zu unter­su­chen­den Pati­en­ten erlauben.
  • Anschlie­ßend wer­den die gespro­che­nen dik­tier­ten Befun­de zusam­men mit den Bil­dern bzw. Bil­der­se­quen­zen zen­tral gespeichert.

Sol­che SW-Pake­te exis­tie­ren inner­halb der Pro­dukt­fa­mi­lie eines Her­stel­lers basie­rend auf einer pro­prie­tä­ren Platt­form auch für ande­re bild­ge­ben­de Ver­fah­ren. Egal, ob man also an einem Com­pu­ter­to­mo­gra­fen, einem Angio­gra­fie­sys­tem, einem Ultra­schall­ge­rät oder einem Magnet­re­so­nanz­to­mo­gra­fen (soge­nann­te Moda­li­tä­ten) von Siemens Health­ca­re sitzt, immer arbei­tet der Benut­zer mit einer iden­ti­schen Bedieneroberfläche.

Die­se Soft­ware von Siemens „syngo.via“ ist ein Medi­zin­pro­dukt und muss gemäß den Vor­ga­ben des Medi­zin­pro­duk­te­ge­set­zes ent­wi­ckelt und sei­ne Qua­li­tät gesi­chert wer­den. So wie das medi­zi­ni­sche Dia­gnos­tik- oder The­ra­pie­ge­rät, auf dem eine Soft­ware instal­liert ist, ist syngo.via selbst auch ein Medi­zin­pro­dukt. Durch die EWG 93/42, eine EU-Richt­li­nie zur Her­stel­lung und dem Ver­trieb von Medi­zin­pro­duk­ten, darf ein Her­stel­ler die­se erst dann in der EU „in den Ver­kehr brin­gen“, wenn er nach­weis­lich diver­se ver­pflich­ten­de Nor­men, die die Ent­wick­lung oder die Her­stel­lung regeln, ein­ge­hal­ten hat. Für die Ent­wick­lung von syngo.via gilt unter ande­rem die IEC 62304, die z. B. vor­schreibt, dass alle Anfor­de­run­gen an das Medi­zin­pro­dukt lücken­los durch die Ent­wick­lung und den Test ver­folg­bar sein müs­sen. Neben den Fach­spe­zi­fi­schen exis­tie­ren ver­schie­dens­te Anfor­de­run­gen z. B. hin­sicht­lich der Sicher­heit oder der Gebrauchs­taug­lich­keit. Dar­über hin­aus wird eine neue Ver­si­on immer auch für alle Medi­zin­pro­duk­te, die die­se Soft­ware nut­zen, frei­ge­ge­ben. Es han­delt sich also um eine mehr­di­men­sio­na­le und sehr kom­ple­xe Anforderungslandschaft.

Über die ver­gan­ge­nen Jah­re konn­ten am kom­plet­ten Entwick­lungs­prozess (in einem V‑Modell inkl. der Tests) durch Pro­zess­op­ti­mie­rung, durch Ein­füh­rung geeig­ne­ter Werk­zeu­ge sowie den Ein­satz hoch qua­li­fi­zier­ter Mit­ar­bei­ter acht­ba­re Erfol­ge hin­sicht­lich Bewäl­ti­gung der stän­dig stei­gen­den Ansprü­che und Anfor­de­run­gen erzielt werden.

Dabei muss jede wei­te­re Ver­än­de­rung am Pro­zess und/oder den Werk­zeu­gen in die bestehen­de Land­schaft ein­ge­passt wer­den und die betrof­fe­nen Pro­zess­teil­neh­mer dafür gewon­nen wer­den. Je kom­ple­xer und grö­ßer der Kata­log der Anfor­de­run­gen an die Soft­ware ist, des­to schwie­ri­ger ist es, alle die­se ein­zel­nen Kom­po­nen­ten und vor allem deren Inte­gra­ti­on ins Gesamt­sys­tem detail­liert zu tes­ten, um mög­li­che Feh­ler her­aus­zu­fin­den und kor­ri­gie­ren zu können.

Das bedeu­tet viel Arbeit für Ste­fan Hal­ler und sein Team von Siemens Health­ca­re, die für den Test von syngo.via im Bereich Magnet­re­so­nanz­to­mo­gra­fie ver­ant­wort­lich sind: Sie sol­len alle nöti­gen Test­fäl­le beschrei­ben und durch­füh­ren, um zu ver­mei­den, dass die Soft­ware noch Feh­ler ent­hält, wenn sie an den Kun­den aus­ge­lie­fert wird.

Die Beschrei­bung von Test­fäl­len ist oft sehr umfang­reich und wenig ände­rungs­freund­lich. Gleich­zei­tig ändern sich aber Anfor­de­run­gen an die Soft­ware (und damit an den Test) sehr oft und oft­mals auch noch kurz vor der geplan­ten Fer­tig­stel­lung. Hr. Hal­ler stand schließ­lich vor der Fra­ge, sei­nem Team noch mehr Über­stun­den kurz vor der Frei­ga­be der Magnet­re­so­nanz (MR)- Appli­ka­tio­nen abzu­ver­lan­gen oder sich etwas grund­le­gend Neu­es auszudenken.

Das brach­te ihn und sein Team unter Mit­wir­kung der Fir­men AFRA GmbH aus Erlan­gen und sepp.med gmbh aus Röt­ten­bach im Früh­jahr 2006 dar­auf, die Model­lie­rung von Test­sze­na­ri­en in Enter­pri­se Archi­tect von Sparx­Sys­tems in UML2 unter Zuhil­fe­nah­me des modell­zen­trier­ten Tes­tens (.mzT) ein­zu­füh­ren und die­se dann durch den Test­fall­ge­ne­ra­tor MBT­sui­te auto­ma­tisch in Test­fäl­le umwan­deln zu lassen.

Der Paradigmenwechsel

Durch Nut­zung der Model­lie­rung in der Model­lie­rungs­no­ta­ti­on UML kön­nen kom­ple­xe Zusam­men­hän­ge struk­tu­riert dar­ge­stellt wer­den. Die sonst umständ­lich in Spra­che zu fas­sen­den Bedin­gun­gen und Vor­aus­set­zun­gen kön­nen in der visua­li­sier­ten Logik, z. B. in beschrei­ben­den Kno­ten und die Kno­ten ver­bin­den­den Kan­ten hin­ter­legt werden.

Die­se Logik kann durch geeig­ne­te Algo­rith­men durch­lau­fen und abge­prüft wer­den, sodass dar­aus auto­ma­tisch Test­fäl­le erzeugt wer­den kön­nen. Aus der gro­ßen Anzahl von Werk­zeu­gen, die eine Model­lie­rung in UML2 erlau­ben, wur­de „Enter­pri­se Archi­tect“ von Sparx­Sys­tems aus­ge­wählt. In Enter­pri­se Archi­tect kön­nen Requi­re­ments eben­so wie das dyna­mi­sche Ver­hal­ten eines zu tes­ten­den Sys­tems model­liert und ver­knüpft wer­den. Die­se Model­le wer­den für die Gene­rie­rung der Test­fäl­le und Test­da­ten verwendet.

Zum Ein­satz kommt bei Siemens ein Algo­rith­mus (sie­he [OSS07] und [PSO08]), der in Zusam­men­ar­beit mit der Uni­ver­si­tät Erlan­gen-Nürn­berg als For­schungs­pro­jekt der High­tech-Offen­si­ve Zukunft Bay­ern für den Ein­satz zur Test­fall- und Test­da­ten­ge­ne­rie­rung aus UML-Model­len ent­wi­ckelt wur­de. Die­ser soge­nann­te „gene­ti­sche“ Algo­rith­mus basiert auf Erkennt­nis­sen der bio­lo­gi­schen Ver­er­bungs­leh­re, nach der sich für vor­ge­ge­be­ne Umwelt­be­din­gun­gen beson­ders gut geeig­ne­te gene­ti­sche Eigen­schaf­ten wei­ter ver­er­ben und durch­set­zen. Die Über­tra­gung die­ses Mecha­nis­mus führt dazu, dass aus­ge­hend von einem ers­ten Satz von Test­fäl­len mit Test­da­ten wei­te­re Inkre­men­te erzeugt wer­den, die jeweils die „Gut“-Kriterien für Test­fäl­le mit in die nächs­te Ite­ra­ti­on wei­ter „ver­er­ben“ und damit die gewünsch­ten Kri­te­ri­en erreicht wer­den. Als Haupt­kri­te­ri­en die­nen hier die Maxi­mie­rung der Test­ab­de­ckung bei Mini­mie­rung des Testaufwands.

Mit die­ser auto­ma­ti­sier­ten Opti­mie­rungs­stra­te­gie hebt sich der „gene­ti­sche Algo­rith­mus“ von den bis­her ver­wen­de­ten Metho­den in ande­ren am Markt erhält­li­chen Sys­te­men zur Test­ge­ne­rie­rung ab: In jenen muss der Anwen­der aus einer Aus­wahl mög­li­cher Stra­te­gien (z. B. gewünsch­ter Abde­ckungs­grad aller Test­fäl­le oder aber Aus­wahl von mög­li­chen Pfa­den über Kno­ten und Kan­ten) selbst über die Opti­mie­rungs­mög­lich­kei­ten ent­schei­den und die­se ggfs. in meh­re­ren Inkre­men­ten vor­neh­men. Mit dem „gene­ti­schen Algo­rith­mus“ wird dage­gen sehr effek­tiv ein mög­lichst opti­ma­ler Satz an Test­fäl­len erzeugt.

Die­se Test­fäl­le kön­nen in belie­bi­gen For­ma­ten expor­tiert wer­den, sowohl in Text­form für eine manu­el­le Durch­füh­rung als auch für die auto­ma­ti­sche Durch­füh­rung als Skript. Im kon­kre­ten Anwen­dungs­fall wer­den die Test­fäl­le direkt in das Test­ma­nage­ment-Werk­zeug „Qua­li­ty Cen­ter“ von Hew­lett Packard geschrie­ben, da die­ses in die­ser Abtei­lung bei Siemens ver­wen­det wird. Am Ende der Ein­füh­rung der Model­lie­rung arbei­te­ten 5 der 13 Team­mit­glie­der an der Model­lie­rung und hat­ten erkannt und akzep­tiert, dass für alle die neue Metho­de einen Vor­teil bringt.

Das ist eine wesent­li­che Vor­aus­set­zung für die erfolg­rei­che Ein­füh­rung: Alle müs­sen die­se von sich aus ein­set­zen wol­len, es muss ein „Selbst­läu­fer“ wer­den. Wur­den in einem ers­ten Pro­jekt in der betrach­te­ten Siemens-Abtei­lung zunächst 10 Pro­zent der zu tes­ten­den Anfor­de­run­gen in 25 Model­len erstellt, so wur­den die­se für das dann erfolg­reich durch­ge­führ­te Pro­jekt auf 40 Pro­zent oder 29 Model­le aus­ge­wei­tet und damit 50 Pro­zent aller Test­fäl­le (in Sum­me 151) auto­ma­tisch erzeugt.

Änderungen im Prozess

  1. In Requi­si­te Pro gesam­mel­te und ver­wal­te­te Requi­re­ments wer­den auto­ma­tisch mit dem HP Qua­li­ty Cen­ter abgeglichen.
  2. Die Requi­re­ments wer­den für ein aus­ge­wähl­tes The­ma auto­ma­tisch in das UML-Modell impor­tiert und kön­nen dann vom Model­lie­rer im Modell ver­linkt werden.
  3. Die erstell­ten Model­le wer­den aus Enter­pri­se Archi­tect expor­tiert und von MBT­sui­te ein­ge­le­sen. Dar­aus wer­den nach vor­ge­ge­be­nen Abde­ckungs­kri­te­ri­en auto­ma­tisch Test­fäl­le mit zuge­hö­ri­gen Test­da­ten erzeugt.
  4. Die­se Test­fäl­le wer­den eben­so auto­ma­tisch ins HP Qua­li­ty Cen­ter geschrie­ben und ste­hen mit Ver­lin­kung zu den Anfor­de­run­gen für die Test­pla­nung und ‑durch­füh­rung zur Verfügung.
  5. Die Ver­bin­dung zwi­schen Requi­si­te Pro und dem HP Qua­li­ty Cen­ter macht es mög­lich, Test­fäl­le und deren Durch­füh­rung mit den Test­ergeb­nis­sen den ursprüng­li­chen Anfor­de­run­gen zuzuordnen.
  1. In Requi­si­te Pro gesam­mel­te und ver­wal­te­te Requi­re­ments wer­den auto­ma­tisch mit dem HP Qua­li­ty Cen­ter abgeglichen.
  2. Die Requi­re­ments wer­den für ein aus­ge­wähl­tes The­ma auto­ma­tisch in das UML-Modell impor­tiert und kön­nen dann vom Model­lie­rer im Modell ver­linkt werden.
  3. Die erstell­ten Model­le wer­den aus Enter­pri­se Archi­tect expor­tiert und von MBT­sui­te ein­ge­le­sen. Dar­aus wer­den nach vor­ge­ge­be­nen Abde­ckungs­kri­te­ri­en auto­ma­tisch Test­fäl­le mit zuge­hö­ri­gen Test­da­ten erzeugt.
  4. Die­se Test­fäl­le wer­den eben­so auto­ma­tisch ins HP Qua­li­ty Cen­ter geschrie­ben und ste­hen mit Ver­lin­kung zu den Anfor­de­run­gen für die Test­pla­nung und ‑durch­füh­rung zur Verfügung.
  5. Die Ver­bin­dung zwi­schen Requi­si­te Pro und dem HP Qua­li­ty Cen­ter macht es mög­lich, Test­fäl­le und deren Durch­füh­rung mit den Test­ergeb­nis­sen den ursprüng­li­chen Anfor­de­run­gen zuzuordnen.

Dadurch ent­stand eine geschlos­se­ne Werkzeugkette:

SiemensSuccessStory1 2

Zwischenbilanz

Für den Test von syngo.via wur­den 50 Pro­zent aller Test­fäl­le mit­hil­fe der neu­en Metho­de .mzT und Nut­zung des Werk­zeu­ges MBT­sui­te erzeugt. Es konn­te die­sel­be Rate gefun­de­ner Feh­ler wie beim her­kömm­li­chen Vor­ge­hen ermit­telt wer­den. Die Kos­ten dafür waren für den betrach­te­ten Ein­füh­rungs­zeit­raum nahe­zu gleich. Damit ergibt sich jetzt, da sich der Pro­zess eta­bliert, die Erwar­tung, dass sich der Auf­wand auf der Grund­la­ge zuneh­men­der Erfah­rung signi­fi­kant redu­zie­ren wird. Wich­ti­ge, bereits jetzt mehr­fach gemach­te posi­ti­ve Erfah­run­gen, sind klar erkennbar.

Die visu­el­le Dar­stel­lung des zu tes­ten­den Sys­tems in einem über­sicht­li­chen und struk­tu­rier­ten Modell ermög­licht es schon lan­ge vor der Aus­füh­rung der Tests, Feh­ler in der Spe­zi­fi­ka­ti­on zu erken­nen und sich weit­aus bes­ser inner­halb eines welt­weit koope­rie­ren­den Teams zu verständigen.

Die Kom­mu­ni­ka­ti­on mit den Ent­wick­lern wird ein­fa­cher, da sich bei­de Sei­ten auf der Ebe­ne der logi­schen Abbil­dung schnel­ler ver­ste­hen kön­nen, als dies durch eine unüber­sicht­li­che Pro­sa mög­lich wäre. Die erzeug­ten Model­le sind bes­ser anpass­bar und dadurch nach einer Ände­rung schnel­ler wie­der­zu­ver­wen­den. Reviews der erstell­ten Test­sze­na­ri­en müs­sen nicht durch ermü­den­des Durch­le­sen dut­zen­der Sei­ten oder unüber­sicht­li­cher Tabel­len durch­ge­führt wer­den, son­dern durch gemein­sa­mes Durch­ge­hen einer model­lier­ten und auf einem Bild ersicht­li­chen Logik.

Eine gefor­der­te Test-Abde­ckung kann auf Modell­ebe­ne durch den Ein­satz der MBT­sui­te selbst­ver­ständ­lich nach­ge­wie­sen werden.

Ausblick

Der oben beschrie­be­ne Infor­ma­ti­ons­aus­tausch über die Anwen­dung der neu­en Metho­de in dafür spe­zi­ell ein­ge­rich­te­ten Bespre­chun­gen wird über die Ein­rich­tung eines „Wiki’s“ insti­tu­tio­na­li­siert. Tipps, Tricks, Erfah­run­gen und wich­ti­ge Neu­ig­kei­ten rund um das The­ma Modell­ba­sier­ter Test@MR kön­nen ins Intra­net ein­ge­stellt und auch dort gele­sen wer­den. In einem nächs­ten Schritt soll auch der Key­word-dri­ven Test über MBT ermög­licht werden.

Eine span­nen­de Erwei­te­rung ist durch die Anwen­dung des MBT in der agi­len Ent­wick­lung vor­ge­se­hen. Dabei kön­nen nach einem gemein­sa­men Start von Ent­wick­lung und Test­mo­del­lie­rung für ein­zel­ne Sprints letz­te­re leicht für den nächs­ten Sprint ange­passt und erwei­tert wer­den. Test­fäl­le wer­den schnell für jedes Inkre­ment und jeden Sprint erzeugt.

Im Pro­jekt wur­de erfolg­reich der „gene­ti­sche Algo­rith­mus“ ein­ge­setzt, um 100% Abde­ckung bei mini­ma­lem Test­auf­wand zu errei­chen. Mit der aktu­ells­ten Ver­si­on der MBT­sui­te ste­hen vie­le wei­te­re Stra­te­gien zur Test­fall­ge­ne­rie­rung zur Ver­fü-gung. Mit „Full­path“ wer­den bei­spiels­wei­se zunächst alle mög­li­chen Test­fäl­le erzeugt und kön­nen anschlie­ßend unter zu Hil­fe nah­me von Fit­ler­me­cha­nis­men auf das opti­ma­le Maß redu­ziert wer­den. Es wer­den ver­schie­dens­te Mög­lich­kei­ten zur Ver­fü­gung gestellt , das opti­ma­le Test-Set für den jewei­li­gen Bedarf zu erstel­len. Zusätz­lich wer­den erfor­der­li­che Test­da­ten auto­ma­tisch gene­riert und eine Requi­re­ments-Abde­ckungs­ma­trix angeboten.

Schlussfolgerung

Mit einer intel­li­gen­ten und folg­lich rei­bungs­lo­sen Ein­füh­rung des MBT kön­nen die Qua­li­tät der Ergeb­nis­se gestei­gert sowie der Ein­satz von Res­sour­cen redu­ziert wer­den. Es gelingt somit eine gleich­zei­ti­ge Stei­ge­rung der Effek­ti­vi­tät und Effizienz.

Von ent­schei­den­der Bedeu­tung für die erfolg­rei­che Ein­füh­rung ist die gleich­zei­ti­ge kon­se­quen­te Ein­bin­dung aller invol­vier­ten Mit­ar­bei­ter sowie die Gewähr­leis­tung eines per­ma­nen­ten Kom­mu­ni­ka­ti­ons­pro­zes­ses durch das Manage­ment. So wird die Aner­ken­nung und Mit­wir­kung aller Betei­lig­ten gesi­chert und die Metho­de und das Werk­zeug wer­den zum „Selbst­läu­fer“.

Sie interessieren sich für unsere Leistungen?

Wir unter­stüt­zen Sie und sind für Sie da!

Spre­chen Sie mit uns!

Refe­ren­zen:

[OSS07] Oster, N.; Schie­ber, C.; Sagli­et­ti, F.; Pin­te, F.: Auto­ma­ti­sche, modell­ba­sier­te Test­da­ten­ge­ne­rie­rung durch Ein­satz evo­lu­tio­nä­rer Ver­fah­ren. In Infor­ma­tik 2007 – Infor­ma­tik trifft Logis­tik, Lec­tu­re Notes in Infor­ma­tics, Vol. 110, Gesell­schaft für Infor­ma­tik, 2007

[PSO08] Pin­te, F.; Sagli­et­ti, F.; Oster, N.: Auto­ma­tic Genera­ti­on of Opti­mi­zed Inte­gra­ti­on Test Data by Gene­tic Algo­rith­ms. In Soft­ware Engi­nee­ring 2008 – Work­shop­band, Lec­tu­re Notes in Infor­ma­tics, Vol. 122, Gesell­schaft für Infor­ma­tik, 2008

Wie dürfen wir Sie beim Softwaretest unterstützen?

Pro­fi­tie­ren Sie von der Exper­ti­se unse­rer Experten.

Kon­takt­for­mu­lar Felix Winter
* Pflicht­feld
Felix Winter 2 Pr
„Der ers­te Schritt ist der Wichtigste.
Spre­chen Sie mich an!“

Tel.: +49 9195 931–253

Felix Win­ter, Busi­ness Deve­lo­p­ment Consultant