Manuelle Testfall-Erstellung: Voraussetzungen, Schwierigkeiten und praktische Durchführung

Transkript

1 Mauelle Testfall-Erstellug: Voraussetzuge, Schwierigkeite ud praktische Durchführug Mauelle Testfall-Erstellug: Voraussetzuge, Schwierigkeite ud praktische Durchführug Für das systematische Teste moderer Softwaresysteme ist das zumeist icht eifache mauelle Ableite vo Testfälle auf Basis existiereder, oft uvollstädiger Systemmodelle vo großer Bedeutug. I diesem Artikel wird erläutert, welche Voraussetzuge Systemmodelle wie UML-Aktivitätsdiagramme oder Zustadsdiagramme erfülle müsse, um die korrekte Ableitug vo Testfälle zu ermögliche. Darüber hiaus werde auch typische Schwierigkeite bei der Testfall-Ableitug ahad eies Experimets diskutiert ud darauf aufbaued praktische Tipps für die Ableitug vo Testfälle aus Systemmodelle gegebe. Mauelle Testfall-Ableitug aus Modelle I de letzte Jahre kote durch itesive Forschug ud dere Umsetzug i praxistaugliche Werkzeuge die vollautomatische Geerierug ud Ausführug modellbasierter Tests etscheided verbessert werde. Trotzdem ist das mauelle Ableite vo Tests auf Basis vorhadeer Verhaltesmodelle wie zum Beispiel UML-Aktivitäts- oder Zustadsdiagramme vo großer praktischer Bedeutug zur systematische Erstellug vo Testfälle für modere, veretzte Softwaresysteme. Ei wichtiger Grud, warum die vollautomatisierte Testfall-Ableitug aus Modelle i der Praxis ur eigeschräkt möglich ist, ist, dass dafür korrekte ud vollstädige Modelle, die alle für die Testfall-Ableitug otwedige Iformatioe ethalte, otwedig sid. Solche hochwertige ud detaillierte Modelle fidet ma i der Praxis jedoch selte. Häufig werde stattdesse i der Aalysephase Modelle erstellt, die gerade gut geug sid, damit das Projektteam die Awedugsdomäe ud die Geschäftsprozesse versteht. Dabei erfolgt die Modellierug vielfach ohe Werkzeuguterstützug (vgl. [Tot12]). Hier steht beim Erstelle och icht das Teste im Fokus, soder die Begriffsklärug ud Kommuikatio über Aforderuge. Um die Modelle icht zu überfrachte, wird das weggelasse, was dem meschliche Leser ohehi ituitiv klar ist, mehrere Schritte werde der Übersicht halber zu eiem zusammegefasst ud icht alle Spezial- ud Fehlerfälle werde dokumetiert. Für die dyamische Modellierug eies Softwaresystems aus fachlicher Sicht eige sich laut IREB (Iteratioal Requiremets Egieerig Board, vgl. [Poh11]) besoders diese UML-Diagrammtype: das Aktivitätsdiagramm für die Fuktiosperspektive das Zustadsdiagramm für die Verhaltesperspektive Grudsätzlich ist es möglich, aus eiem Aktivitäts- oder Zustadsdiagramm automatisiert so viele Testfälle abzuleite, dass eie Testüberdeckug i Bezug auf Aweisugs-, Zweig- oder Pfadüberdeckug (siehe Kaste 1) erreicht wird. Verschiedee Idustrie- ud Forschugsasätze zeige, wie ud uter welche Voraussetzuge dies möglich ist (vgl. [Bri02], [Ku09], [Kra13] für Aktivitätsdiagramme sowie [Off99], [Rie03], [Wei08] für Zustadsdiagramme). Damit die UML- Modelle auch wirklich alle für das Teste ötige Iformatioe ethalte, habe diese automatisierte Asätze die UML- Diagramme um passed defiierte Stereotype oder Ausdrücke i OCL (Object Costrait Laguage), um Schlüsselbegriffe (vgl. [Kra14]) aus eiem Metamodell ud um explizite Fuktiosaufrufe aus eier Testautomatisierugs-Bibliothek erweitert (vgl. [Kra13]). Außerdem sid spezielle Werkzeuge oder Apassuge besteheder Werkzeuge dafür ötig. Die mauelle Testfall-Ableitug aus Modelle ist vor allem dort relevat, wo zwar Modelle vorhade sid, aber die Voraussetzuge für die automatisierte Testfall- Erstellug fehle, also vor allem beim Systemtest aus fachlicher Sicht. Die mauelle Testfall-Erstellug ka hier zusätzlich dazu diee, die Qualität der fachliche Modelle zu ispiziere ud sicherzustelle, idem ihre Vollstädigkeit ud Testbarkeit geprüft wird (vgl. [Koc14]). Geerell sollte zusätzlich zu automatisiertem Teste immer auch och mauell explorativ, kreativ ud kotextabhägig getestet werde (vgl. [Ag13]). Weiterhi gibt es auch Hiweise darauf, dass das mauelle Ableite vo Testfälle aus Modelle sehr effektiv ist. Eie Fallstudie (vgl. [Pre05]) zeigte, dass sowohl die automatisiert als auch die mauell aus Modelle abgeleitete Testfälle deutlich mehr Aforderugsfehler fade als diejeige Testfälle, die direkt aus textuelle Afor- Die drei wichtigste Arte vo kotrollflussbasierter Testüberdeckug sid Aweisugs-, Zweig- ud Pfadüberdeckug. Bei der Aweisugsüberdeckug solle alle Kote eies Graphe (d.h. Aktivitäte bzw. Zustäde i Aktivitäts- bzw. Zustadsdiagramme) abgedeckt, also vo midestes eie Testfall durchlaufe werde. Bei der Zweigüberdeckug solle alle Kate eies Graphe (d. h. alle Übergäge zwische Aktivitäte bzw. Zustäde) durch midestes eie Testfall durchlaufe werde. Bei der Pfadüberdeckug solle alle mögliche Pfade zwische Start- ud Edkote getestet werde. Üblicherweise verlagt die Zweigüberdeckug mehr Testfälle als die Koteüberdeckug, währed die Pfadüberdeckug ur mit Eischräkuge ud i eifache Fälle mit verüftigem Aufwad erreicht werde ka. De jede Schleife müsste zur vollstädige Pfadüberdeckug icht ur eimalig durchlaufe werde, soder i eiem Testfall eimal, i eiem weitere zweimal usw. (vgl. [Spi12]). Kaste 1: Testüberdeckug. 56

2 Das Ableite vo Testfälle aus Systemmodelle: Wie viele Testfälle braucht ma für die Testüberdeckug ud wa ist der Testfall vollstädig? Welche Fehler werde beim Ableite gemacht? Die Beatwortug dieser für die Praxis sehr wichtige Fragestelluge i diesem Artikel basiert auf userer Berufs- ud Beratugserfahrug i der Software-Qualitätssicherug, auf eier vo us durchgeführte quatitativ ausgewertete empirische Utersuchug (vgl. [Fel15]) ud eier darauf basierede Utersuchug mit Praktiker. Experimet zum Erstelle testbarer Modelle Ei fachliches Modell ist da testbar, we es alle Iformatioe ethält, die für die Erstellug der Testfälle ötig sid. Zur Illustratio des Kozepts der Testbarkeit zeigt Abbildug 1 ei Aktivitätsdiagramm, das eie vereifachte Geldautomate ud desse Use-Case Geld abhebe fachlich modelliert. We der Testdesiger die Awedugsdomäe ket, sollte diese grafische Modellierug als Grudlage für das Teste geüge. Für die Spezifikatio der Testfälle verwede wir auch i idustrielle Projekte die i Tabelle 1 dargestellte Vorlage (vgl. [Fel13]). Das Eckfeld liks obe ethält eie Testfall-ID ud daebe die Vorbediguge, die vor Ausführug des Testfalls erfüllt sei müsse. Jeder Testschritt etspricht eier ummerierte Zeile, eischließlich auszuführeder Aktio, Eigabedate ud erwartetem Ergebis. Die für das Teste ötige Modelliformatioe lasse sich de folgede drei Kategorie zuorde: Abb. 1: Aktivitätsdiagramm eies (vereifachte) Geldautomate. deruge hergeleitet wurde. Obwohl jede mauelle Tätigkeit poteziell fehlerafälliger ist als ihre automatisierte Durchführug, fade i [Pre05] die automatisch abgeleitete Testfälle icht mehr Fehler pro ausgeführtem Testfall als die mauell abgeleitete. I diesem Artikel adressiere wir die zwei wichtigste Herausforderuge, die sich 01/2016 stelle, we ma System-Testfälle aus fachliche UML-Modelle mauell ableitet: Das Erstelle testbarer Modelle: Wa sid im Modell geüged Iformatioe vorhade, damit daraus vollstädige Testfälle mauell abgeleitet werde köe? Ihalte: Für die Erstellug eies Testfalls muss ei testbares Modell laut Tabelle 1 desse Vorbedigug, Aktioe, Eigabedate ud erwartetes Ergebis etweder ausdrücklich ethalte oder diese müsse sich für de meschliche Tester ituitiv schlüssig aus dem Modell ergebe. Was der Tester ituitiv ableite ka ud was icht, ist bisher icht erforscht. Wichtig ist jedoch Domäewisse, d. h. die Ketis des Awedugsbereichs der Software. Der Tester sollte eie solche oder ähliche Software bereits beutzt oder aderweitig keegelert habe. Ohe solches Vorwisse ka er kaum gültige Schlüsse ziehe. Diese Problematik 57

3 Mauelle Testfall-Erstellug: Voraussetzuge, Schwierigkeite ud praktische Durchführug Tabelle 1: Testfall-Vorlage mit dem Afag eies Testfalls für de Geldautomate. zeigt sich beispielsweise auch beim Offshorig, wo die Iformatio, die icht im Modell ethalte ist, dem Offshore- Parter oft fehlt, weil er sie icht auf ioffizielle Wege erhält oder durch kulturelle Koses bereits besitzt. Detailtiefe: Hilfreich ist es, we das Modell dieselbe Detailtiefe wie die Testfälle hat, also isbesodere eie Aktivität (im Aktivitätsdiagramm) bzw. ei Zustadsübergag (im Zustadsdiagramm) geau eiem Testschritt etspricht. Kotrollfluss: Damit der Tester die für eie Testüberdeckug ötige Azahl vo Testfälle ableite ka, müsse etweder alle Fehler- ud Soderfälle im Modell ethalte sei oder er muss vo dieser Uvollstädigkeit wisse ud selbstädig prüfe, ob a jeder Stelle alle mögliche Fälle abgedeckt sid. Notfalls muss er och Verzweiguge ud Pfade is Modell eifüge. Für usere Studie habe wir die Soderfälle vollstädig vorgegebe. Das mauelle Ableite vo Testfälle aus Systemmodelle Beim systematische Ableite vo Testfälle aus Systemmodelle geht es darum, das Modell geeiget zu überdecke (siehe Kaste 1), um jee Azahl vo Testfälle abzuleite, die das zu Grude liegede System ausreiched ud achvollziehbar teste. Zusätzlich sollte jeder Testfall für sich vollstädig sei, d. h. alle für seie Durchführug ötige Date ethalte. Um kokret herauszufide, welche Fehler beim Ableite vo Testfälle wie häufig auftrete, habe wir eie Utersuchug mit isgesamt 84 Studierede a zwei Hochschule im deutschsprachige Raum durchgeführt. Studierede köe durchaus repräsetativ sei für echte Testdesiger, da i der Praxis Tests häufig vo eue Mitarbeiter (zur Eiarbeitug) erstellt werde oder vo Key-User als Akzeptaztest/Abahmetest. Letztere kee zwar die Awedugsdomäe der Software sehr gut (wie die Studete im Rahme des Experimets), habe aber ur eie kurze Eiführug i die Testfall-Erstellug erhalte. Nach eier Eiführug i modellbasiertes Teste ud dem gemeisamem Durchspiele eies Beispiels sollte die Teilehmer jeweils die zur Zweigüberdeckug ötige Testfälle für eie Geträkeautomate ud eie Geldautomate (siehe Abbildug 1), also i de Studete vertraute Awedugsdomäe, ableite. Dabei bildete wir zwei Gruppe (siehe Tabelle 2): Gruppe A bearbeitete das Aktivitätsdiagramm des Geträkeautomate ud das Zustadsdiagramm des Geldautomate. Gruppe B bearbeitete umgekehrt das Aktivitätsdiagramm des Geldautomate ud das Zustadsdiagramm des Geträkeautomate. Für die Aktivitäts- ud Zustadsdiagramme galt, dass sie zwei der drei Kriterie für Testbarkeit erfüllte: Die Modelle besaße dieselbe Detailtiefe, wie wir sie vo de Testfälle erwartete, ud stellte alle mögliche Soderfälle dar. Es ware jedoch bewusst Vorbediguge, Eigabedate ud erwartete Ergebisse ur teilweise im Modell ausdrücklich geat. Wir wollte herausfide, ob die Testdesiger, die ja die Awedugsdomäe der Maschie kate, diese selbststädig ergäze kote. Zur Auswertug der mauell aus Modelle abgeleitete Testfälle zählte wir die gemachte Fehler ud ordete sie Fehlerkategorie zu. Um die Vollstädigkeit der Ergebisse zu beurteile, defiierte wir, dass alle Iformatioe, die tatsächlich für eie mauelle Test ötig ware, i dem tabellarische Testfall ethalte sei müsse. Als Referez erstellte wir für alle vier Fälle Testfälle als Musterlösuge. Usere Testdesiger erstellte 150 Sätze vo Testfälle, die isgesamt 342 Testfälle hätte ethalte solle. Wir zählte dari isgesamt Fehler. I 51 der 150 Datesätze stimmte die Azahl der Testfälle icht: I 4 Datesätze fehlte ei Testfall. I 3 Datesätze war ei Testfall zu viel. Tabelle 2: Gruppebildug i der Studie ud Azahl der Testfall-Sätze, die i der Studie etstade. 58

4 Abb. 2: Fehlerhäufigkeite, aufgeschlüsselt ach betroffeem Testfall-Feld (ZD steht für Zustadsdiagramm, AD für Aktivitätsdiagramm). I 44 Datesätze war zwar die Azahl der Testfälle korrekt, stimmte aber icht überei mit der auf dem Frageboge selbst agegebee Azahl a Testfälle als Atwort auf die Frage: Wie viele Testfälle sid für die Zweigüberdeckug ötig? Die häufigste Fehler ierhalb der Testfälle ware (i dieser Reihefolge): Aktio i Ergebis-Feld Fehleder Testschritt Aktio i Eigabe-Feld Bedigug fehlt im Eigabe-Feld Bedigug steht im Aktio-Feld Erwartetes Ergebis fehlt Die Fehlerzahle habe wir ach mehrere Kriterie aufsummiert ud ausgewertet: Us iteressierte, ob für bestimmte Felder der Testfall-Vorlage häufiger falsch ausgefüllt wurde als adere. Dies war icht der Fall (siehe Abbildug 2). Aktio (645 Mal falsch), Eigabedate (580) ud erwartetes Ergebis (624) ware ugefähr gleich häufig falsch. Fehler bei der Vorbedigug gab es ur halb so oft (280 Mal), was sich leicht dadurch erklärt, dass ei Testfall ur ei Vorbedigugsfeld hat, jedoch viele Testschritte. Fehler, die eie gaze Testschritt betrafe (z.b. fehleder Testschritt), gab es 279 Mal. Die Fehlerdate wertete wir aschließed och aus, um herauszufide, ob häufiger Ihalt fehlte oder zu viel vorhade war: 724 Mal fehlte ei Elemet im Testfall. 152 Mal war ei Feld im Testfall mit uötigem Ihalt befüllt. 695 Mal stad ei (richtiger) Ihalt im falsche Vorlagefeld. 194 Mal war ei Feldihalt ugültig. Es wird also häufiger etwas vergesse, als zu viel dargestellt. Daraus ka ma schlussfolger, dass das Fachmodell doch besser alle ötige Ihalte ethalte sollte ud ma möglichst weig darauf vertraue sollte, dass der Tester im Fachmodell fehlede Ihalte scho richtig ergäze wird. Schließlich vergliche wir auch och die Fehler bei de Aktivitäts- ud Zustadsdiagramme, um herauszufide, welche der beide Diagrammarte sich bei der Testfall-Ableitug als verstädlicher erwies. Bei der Ableitug vo Testfälle aus Aktivitätsdiagramme wurde (statistisch sigifikat) mehr Fehler gemacht als bei der Ableitug aus de Zustadsdiagramme. Dies ist umso iteressater, als die Teilehmer bei der Frage, wie verstädlich sie das jeweilige Diagramm gefude hatte, das Aktivitätsdiagramm (statistisch sigifikat) als verstädlicher bewertet hatte als das Zustadsdiagramm. Eie mögliche Erklärug für diese scheibare Widerspruch köte sei, dass die scheibar ituitive Verstädlichkeit ud gerigere Formalität des Aktivitätsdiagramms die Teilehmer zu Flüchtigkeitsfehler verleitete, währed das schwerer verstädliche Zustadsdiagramm mehr Sorgfalt erzwag. Oder es köte die weiger formale Aktivitätsdiagramme auch weiger eideutig sei als die Zustadsdiagramme. Zum Vergleich habe wir dieselbe Aufgabe auch mehrere Praktiker gestellt, die sich beruflich mit Teste beschäftige. Auch sie sollte aus Aktivitäts- ud Zustadsdiagramme vo Geld- ud Geträkeautomat die passede Testfälle ableite. Letztlich erhielte wir eu Sätze vo Testfälle. Die Praktiker fade jedoch die UML-Diagramme weiger verstädlich als die Studierede, machte bei der Beatwortug vo Verstädisfrage zu de Diagramme mehr Fehler ud ihre Testfälle ethielte mehr Fehler. Die mauelle Testfall-Ableitug ist also eie icht-triviale Tätigkeit, die auch dem Profi schwer fällt. (Wobei vermutlich bei de Praktiker ihr UML-Kurs scho läger her ist als bei de Studete.) Es sid also gezielte Maßahme ötig, um die Praxis der mauelle Ableitug vo Testfälle aus Modelle zu uterstütze. Dazu köe klare Schritt-für-Schritt-Aleituge gehöre. Fazit ud Ausblick Trotz existiereder Asätze zur automatisierte, modellbasierte Testfall-Ableitug hat die mauelle Ableitug vo Testfälle auf Basis vo Modelle eie große praktische Bedeutug, weil Systemmodelle i der Praxis oft icht vollstädig sid. Schwierigkeite bei der mauelle, modellbasierte Testfall-Ableitug betreffe zuächst die Erstellug eies testbare Fachmodells ud da die Ableitug der Testfälle aus diesem Modell. Hierbei sid eiige Vollstädigkeitsbediguge zu erfülle ud verschiedee Kategorie vo Fehler köe dabei auftrete. Ahad eier Utersuchug habe wir aufgezeigt, dass uerfahree ud erfahree Testdesiger recht viele Fehler mache. Wir habe auch quatitativ ausgewertet, wie sich diese Fehler auf verschiedee Kategorie verteile. Beispielsweise fehlte häufiger Ihalte, als dass etwas zu viel war. Das ituitive Ergäze fehleder Ihalte hat also oft icht fuktioiert. Folglich sollte Fachmodelle so vollstädig wie möglich sei, sodass der Testdesiger ichts ergäze muss oder der Testdesiger braucht Zugag zu de Stakeholder, um fehlede Iformatioe zu erfrage. Da oft richtige Ihalte im falsche Feld stade, brauche 01/

5 Mauelle Testfall-Erstellug: Voraussetzuge, Schwierigkeite ud praktische Durchführug die Tester klarere Aleituge für die Ableitug, beispielsweise Eie Aktivität im Aktivitätsdiagramm etspricht oft eier Aktio im Testfall. Auch explizite Vollstädigkeitsbediguge für die Testfälle (oder die Fachmodelle) köte helfe. Obwohl die Teilehmer die Aktivitätsdiagramme für verstädlicher hielte als die Zustadsdiagramme, machte sie doch bei de Aktivitätsdiagramme mehr Fehler. Über usere Studie habe wir umfagreiche Date zur Testfall-Ableitug erhalte. I eier Folgestudie möchte wir och detailliertere Date sammel, um de Ursache der Fehler auf de Grud zu gehe. So möchte wir messe, wer wie lage für welche Aktivität gebraucht hat, beispielsweise für das Lese des Diagramms oder das Erstelle der Testfälle. Damit köe weitere Frage wie die folgede utersucht ud beatwortet werde: Habe die Teilehmer die scheibar leicht verstädliche Aktivitätsdiagramme weiger lag betrachtet, bevor sie begae, die Testfälle zu erstelle? War die Testfall-Erstellug für Aktivitätsdiagramme scheller möglich als für Zustadsdiagramme? Habe die schellere Teilehmer mehr oder weiger Fehler gemacht? Gere möchte wir auch weitere Fallstudie mit Tester i Idustrieprojekte durchführe. Dazu etwickel wir weiteres uterstützedes Material zur Testfall-Ableitug aus Modelle. Dies umfasst isbesodere umfagreiches Traiigsmaterial, Richtliie für die Testfall-Ableitug sowie Checkliste für die Ispektio der Vollstädigkeit vo Systemmodelle ud Testfälle. Eie Fallstudie i der Praxis diet icht ur der wisseschaftliche Neugier, soder hilft auch eier Orgaisatio, ihre Testprozess zu verbesser, idem Fehler i de Testfälle ud dere Fehlerquelle idetifiziert werde mit dem Ziel, die Qualität der Testfälle zu verbesser. Ählich wie bei der Frage Wer scheidet dem Friseur die Haare? stellt sich beim Teste auch die Frage: Wer testet die Testfälle? Zur Beatwortug solcher ud ählicher Fragestelluge sowie zur Verbesserug des Testprozesses im Allgemeie sid empirisch begleitete Studie sehr wertvoll. Literatur & Liks [Ag13] R. Ager, F. Eichler, Keie Ausrede: Testautomatisierug i agile Projekte, i: OBJEKTspektrum 4/2013 [Bri02] L. Briad, Y. Labiche, A UML-based approach to system testig, i: Software ad Systems Modelig 1(1) 2002, S [Fel13] M. Felderer, A. Beer, Usig Defect Taxoomies to Improve the Maturity of the System Test Process: Results from a Idustrial Case Study, i: Software Quality. Icreasig Value i Software ad Systems Developmet, 2013 [Fel15] M. Felderer, A. Herrma, Maual test case derivatio from UML activity diagrams ad state machies: A cotrolled experimet, i: Iformatio & Software Techology, Nr. 61, S [Koc14] J. Koch, S. Middeke, Effizietere agile Prozesse: Testfallbasierte Aforderugsdokumetatio, i: OBJEKTspektrum 2/2014 [Kra13] A. Kramer, M. Beisser, Achilles ud die Schildkröte: Mit modellbasierter Testautomatisierug scheller zum Ziel, i: OBJEKTspektrum 4/2013 [Kra14] A. Krallma, M. Ligelbach, Modellbasierte Testautomatisierug: Vo der Aforderugsaalyse zu automatisierte Testabläufe, i: OBJEKTspektrum 2/2014 [Ku09] D. Kudu, D. Samata, A Novel Approach to Geerate Test Cases from UML Activity Diagrams, i: Joural of Object Techology 8(3) 2009, S [Off99] J. Offutt, A. Abdurazik, Geeratig Tests from UML Specificatios, i: UML99, Lecture Notes i Computer Sciece No. 1723, 1999 [Poh11] K. Pohl, C. Rupp, Basiswisse Requiremets Egieerig: Aus- ud Weiterbildug ach IREB-Stadard zum Certified Professioal for Requiremets Egieerig Foudatio Level, dpukt.verlag, 2011 [Rie03] M. Riebisch, I. Philippow, M. Götze, UML-Based Statistical Test Case Geeratio. Objects, Compoets, Architectures, Services, ad Applicatios for a Networked World, Lecture Notes i Computer Sciece, Volume 2591, 2003 [Tot12] S. Toth, K.N. Dugge, Aaloge Modellierug: Über die qualitätsstiftede Abkehr vom Tool, i: OBJEKTspektrum 6/2012, S [Wei08] S. Weißleder, D. Sokeou, Automatic Test Case Geeratio from UML Models ad OCL Expressios, i: Proc. of Software Egieerig (Workshops), 2008 [Spi12] A. Spiller, T. Liz, Basiswisse Softwaretest: Aus- ud Weiterbildug zum Certified Tester - Foudatio Level ach ISTQB-Stadard, dpukt.verlag, 2012 Die Autore Dr. habil. Adrea Herrma (herrma@herrma-ehrlich.de) ist freiberufliche Software-Egieerig-Traieri ud Berateri sowie Dozeti a verschiedee Hochschule. Sie hat 20 Jahre Berufserfahrug, sowohl als Berateri ud Projektleiteri als auch i Forschug ud Lehre. Dr. Michael Felderer (michael.felderer@uibk.ac.at) forscht ud lehrt am Istitut für Iformatik der Uiversität Isbruck. Zu seie Arbeitsschwerpukte zähle Teste vo Software, Softwareprozesse ud empirisches Software Egieerig. Er ist Geschäftsführer ud Seior Berater für die QE LaB Busiess Services GmbH. 60