Istqb Ctal Lehrplan v2007

CERTIFIED TESTER Advanced Level Syllabus
Version 2007
International Software Testing Qualifications Board
Deutschsprachige Ausgabe
German Testing Board e.V.

in Kooperation mit dem Swiss Testing Board und dem Austrian Testing Board
Urheberrecht () Dieses Dokument darf sowohl ganz als auch in Auszgen vervielfltigt werden, sofern die Quelle angegeben wird.
Certified Tester Advanced Level Syllabus (Deutschsprachige Ausgabe)
Urheberrecht () an der englischen Originalausgabe: International Software Testing Qualifications Board (nachfolgend ISTQB genannt). Mitglieder der Advanced Level Arbeitsgruppe: Bernard Homs (Leitung), Graham Bath, Rex Black, eder Sigrid Eldh, Jayapradeep Jiothis, Paul Jorgensen, Vipul Kocher, Judy McKay, Klaus Olsen, Randy Rice, Jrgen Richter, Eric Riou Du Cosquer, Mike Smith, Geoff Thompson, Erik Van Veenendaal; Erik 2006-2007. bersetzung des englischsprachigen Lehrplans des International Software Testing Qualifications Board (ISTQB), Originaltitel: Certified Tester, Advanced Level Syllabus. Urheberrecht 2007 der berarbeitung der englischen Originalausgabe 2007 besitzen die oben Originalausgabe genannten Autoren. Die Rechte sind bertragen auf das International Software Testing Qualifications Board (ISTQB). ISTQB ist ein eingetragenes Warenzeichen des International Software Testing Qualifications Board. bersetzung/bertragung in die deutsche Sprache, 2007/2008: Horst Pohlmann (GTB), Thomas rsetzung/bertragung Mller (STB), Graham Bath (GTB, Leitung) mit Untersttzung durch das bersetzungsbro: Elke Bath und der Technical Writerin: Dagmar Boedicker. Die Autoren danken den folgenden Reviewern: Petra Bukowski (GTB), Matthias Hamburg (GTB), lgenden Horst Pohlmann (GTB), Timea Illes-Seifert (GTB), Helmut Pichler (ATB), Thomas Mller (STB), Anton -Seifert Schlatter (GTB), Maud Schlich (GTB), Stephanie Ulrich (GTB), Sabine Uhde (GTB), Uwe Hehn (GTB (GTB), Martin Klonk (ATB), Wiltrud Breuss (ATB), Harry Sneed (ATB) und,Kurt Aigner (ATB). Die Autoren, GTB und ISTQB haben folgenden Nutzungsbedingungen zugestimmt: 1. Jede Einzelperson und jeder Seminaranbieter darf den Lehrplan als Grundlage fr Seminare verwenden, sofern die Inhaber der Urheberrechte als Quelle und Besitzer des Urheberrechts anerkannt und benannt werden. Des Weiteren darf der Lehrplan zu Werbungszwecken erst nach der Akkreditierung durch ein vom ISTQB anerkanntes Board verwendet werden. 2. Jede Einzelperson oder Gruppe von Einzelpersonen darf den Lehrplan als Grundlage fr Artikel, Bcher oder andere abgeleitete Verffentlichungen verwenden, sofern die Autoren und der ISTQB als Quelle und Besitzer des Urheberrechts genannt werden. 3. Jedes vom ISTQB anerkanntes nationale Board darf den Lehrplan bersetzen und den Lehrplan es (oder die bersetzung) an andere Parteien lizensieren. Das Werk einschlielich aller seiner Teile ist urheberrechtlich geschtzt. Die Verwertung ist - soweit sie nicht ausdrcklich durch das Urheberrechtsgesetz (UrhG) gestattet ist nur mit Zustimmung der Berechtigten zulssig. Dies gilt insbesondere fr Vervielfltigungen, Bearbeitungen, bersetzungen, Mikroverfilmung, Einspeicherung und Verarbeitung in elektronischen Systemen, ffentliche Zugnglichmachung.
Version 2007
Seite 2 von 136
Januar 2010 20100131
nderungsbersicht der deutschsprachigen Ausgabe

Version V2007Beta V2007Beta2 V2007Beta3 V2007 Datum 6. Juni 2008 1.Oktober 2008 25.August 2009 Januar 2010 Bemerkungen Certified Tester Advanced Level Syllabus Version 2007 (Lehrplan Aufbaukurs Certified Tester) Abgleich mit CTFL Abgleich mit Glossar 2.0 Freigabeprfung Freigabe durch D.A.CH (nach internem Review).
Version 2007
Seite 3 von 136
Januar 2010 20100131
Inhaltsverzeichnis
Inhaltsverzeichnis ................................ ................................................................................................................................ 4 .................................... Dank ................................................................ ........................................................................................................................ 8 ........................ 0. Einfhrung in den Lehrplan ................................ ................................................................................................ ............................................. 9 0.1 Das International Software Testing Qualifications Board ...................................................... 9 ftware ...................... 0.2 Erwartungen ................................ ......................................................................................................................... 11 ......................... 0.2.1 Testmanager Advanced Level ......................................................................................... 11 ......................... 0.2.2 Test Analyst Advanced Level .......................................................................................... 12 .......................... 0.2.3 Technical Test Analyst Advanced Level ................................................................ .......................................... 12 0.3 Lernziele/Kognitive Ebenen des Wissens ................................................................ ............................................ 13 0.4 Lernziele fr Testmanager ................................................................................................ 14 ................................... 0.5 Lernziele fr Test Analysts ................................................................................................ 21 ................................... 0.6 Lernziele fr Technical Test Analysts ................................................................ .................................................. 25 1. Grundlegende Aspekte des Softwaretestens ................................................................ ............................................... 30 1.1 Einfhrung ................................ ............................................................................................................................ 30 ............................ 1.2 Testen im Softwarelebenszyklus ......................................................................................... 30 ......................... 1.3 Spezifische Systeme ................................ ................................................................................................ ............................................ 32 1.3.1 Multisysteme ................................ .................................................................................................................... 32 .................... 1.3.2 Sicherheitskritische Systeme ........................................................................................... 33 ........................... 1.4 Metriken und Messung ................................ ................................................................................................ ......................................... 34 1.5 Ethische Leitlinien ................................ ................................................................................................ ................................................ 35 2. Testprozesse ................................ ................................................................................................................................ 36 ................................ 2.1 Einfhrung ................................ ............................................................................................................................ 36 ............................ 2.2 Testprozessmodelle ................................ ................................................................................................ ............................................. 36 2.3 Testplanung und -steuerung ................................................................................................ 37 steuerung ................................ 2.4 Testanalyse und Testentwurf ............................................................................................... 37 ............................... 2.4.1 Testbedingungen identifizieren ........................................................................................ 38 ........................ 2.4.2 Testflle entwerfen ................................ ................................................................................................ .......................................... 38 2.5 Testrealisierung und Testdurchfhrung ................................................................ ............................................... 39 2.5.1 Testrealisierung ................................ ................................................................................................ ............................................... 39 2.5.2 Testdurchfhrung ................................ ................................................................................................ ............................................. 40 2.6 Testauswertung und Bericht ................................................................................................ 42 ................................ 2.7 Abschluss der Testaktivitten .............................................................................................. 43 .............................. 3. Testmanagement ................................ .......................................................................................................................... 45 .......................... 3.1 Einfhrung ................................ ............................................................................................................................ 45 ............................ 3.2 Testmanagement-Dokumentation ........................................................................................ 45 Dokumentation ........................ 3.2.1 Testrichtlinie ................................ ..................................................................................................................... 45 ..................... 3.2.2 Teststrategie ................................ .................................................................................................................... 46 .................... 3.2.3 Mastertestkonzept ................................ ................................................................................................ ........................................... 47 3.2.4 Stufentestkonzept ................................ ................................................................................................ ............................................ 48 3.3 Dokumentvorlagen fr Testkonzepte ................................................................ ................................................... 48 3.4 Testaufwandsschtzung ................................................................................................ ...................................... 48 3.5 Zeitliche Testplanung ................................ ................................................................................................ ........................................... 50 3.6 Testfortschritt berwachen und steuern ................................................................ ............................................... 50 3.7 Geschftswert des Testens Testens................................................................................................ 52 .................................. 3.8 Verteiltes Testen, Outsourcing und Insourcin ................................................................ 53 Insourcing .................................... Version 2007 Seite 4 von 136 Januar 2010 20100131
3.9 Risikoorientiertes Testen................................................................................................ ...................................... 53 3.9.1 Einfhrung in das risikoorientierte Testen ................................................................ ....................................... 53 3.9.2 Risikomanagement ................................ ................................................................................................ .......................................... 54 3.9.3 Risikomanagement im Softwarelebenszyklus ................................................................ 58 ................................. 3.10 FMEA (Fehler-Mglichkeits und Einfluss-Analyse) ............................................................ 59 Mglichkeits............................ 3.10.1 Anwendungsbereiche ................................................................................................ 59 .................................. 3.10.2 FMEA durchfhren ................................................................................................ ...................................... 59 3.10.3 Kosten und Nutzen ................................................................................................ ...................................... 60 3.11 Besonderheiten beim Testmanagement ................................................................ .............................................. 60 3.11.1 Testmanagement beim explorativen Testen ............................................................... 60 ............................... 3.11.2 Testmanagement bei Multisystemen Multisystemen................................................................ ........................................... 61 3.11.3 Testmanagement bei sicherheitskritischen Systemen ................................ ................................................ 61 3.11.4 Sonstige Besonderheiten beim Testmanagement ...................................................... 62 ...................... 4. Testverfahren ................................ ................................................................................................................................ 65 ................................ 4.1 Einfhrung ................................ ............................................................................................................................ 65 ............................ 4.2 Spezifikationsorientierte Testverfahren ................................................................ ................................................ 65 4.3 Strukturorientierte Testverfahren ......................................................................................... 67 ......................... 4.4 Fehlerbasierte und erfahrungsbasierte Testverfahren ......................................................... 69 erte ......................... 4.4.1 Fehlerbasierte Testverfahren........................................................................................... 69 ........................... 4.4.2 Erfahrungsbasierte Testverfahren ................................................................ ................................................... 70 4.5 Statische Analyse ................................ ................................................................................................ ................................................. 71 4.5.1 Statische Analyse des Programmcodes ................................................................ .......................................... 72 4.5.2 Statische Analyse der Softwarearchitektur ................................................................ ische ...................................... 72 4.6 Dynamische Analyse ................................ ................................................................................................ ............................................ 73 4.6.1 bersicht ................................ .......................................................................................................................... 73 .......................... 4.6.2 Speicherengpsse aufdecken ......................................................................................... 73 ......................... 4.6.3 Fehlerhafte Zeiger aufdecken .......................................................................................... 74 .......................... 4.6.4 Systemleistung analysieren ............................................................................................. 74 ............................. 5. Test der Softwareeigenschaften ................................................................................................ 75 ................................... 5.1 Einfhrung ................................ ............................................................................................................................ 75 ............................ 5.2 Qualittsmerkmale bei fachlichen Tests ................................................................ .............................................. 75 5.2.1 Tests auf Richtigkeit ................................ ................................................................................................ ........................................ 76 5.2.2 Tests auf Angemessenheit .............................................................................................. 76 .............................. 5.2.3 Interoperabilittstests ................................ ................................................................................................ ....................................... 76 5.2.4 Funktionale Sicherheitstests ............................................................................................ 76 erheitstests ............................ 5.2.5 Benutzbarkeitstests ................................ ................................................................................................ ......................................... 76 5.2.6 Zugnglichkeitstests ................................ ................................................................................................ ........................................ 78 5.3 Qualittsmerkmale bei technischen Tests ................................................................ ........................................... 79 5.3.1 Technische Sicherheitstests ............................................................................................ 79 chnische ............................ 5.3.2 Zuverlssigkeitstests ................................ ................................................................................................ ....................................... 81 5.3.3 Effizienztests ................................ .................................................................................................................... 82 .................... 5.3.4 Wartbarkeitstests ................................ ................................................................................................ ............................................. 84 5.3.5 Portabilittstests................................ ................................................................................................ ............................................... 84 6. Review ................................................................ ................................................................................................ .......................................... 87 6.1 Einfhrung ................................ ............................................................................................................................ 87 ............................ 6.2 Grundstze von Reviews ................................................................................................ ..................................... 87 6.3 Review-Arten ................................ ........................................................................................................................ 88 ........................ 6.3.1 Management-Review und Audit Review Audit....................................................................................... 88 ....................... 6.3.2 Reviews von bestimmten Arbeitsergebnissen ................................................................ 89 ................................. 6.3.3 Formales Review durchfhren ......................................................................................... 89 ......................... Version 2007 Seite 5 von 136 Januar 2010 20100131
6.4 Einfhrung von Reviews ................................................................................................ ...................................... 89 6.5 Erfolgsfaktoren fr Reviews ................................................................................................ 90 ................................. 7. Fehler- und Abweichungsmanagement ........................................................................................ 92 ........................ 7.1 Einfhrung ................................ ............................................................................................................................ 92 ............................ 7.2 Wie lsst sich ein Fehlerzustand aufdecken? ................................................................ ...................................... 92 7.3 Fehlerlebenszyklus ................................ ................................................................................................ .............................................. 92 7.3.1 Schritt 1: Erkennung (Recognition) ................................................................ .................................................. 93 7.3.2 Schritt 2: Analyse (Investigation) ..................................................................................... 93 ..................... 7.3.3 Schritt 3: Bearbeitung (Action) ......................................................................................... 93 ......................... 7.3.4 Schritt 4: Abschluss (Disposition) .................................................................................... 93 .................... 7.4 Pflichtfelder fr die Erfassung von Fehlern und Abweichungen ................................ .......................................... 93 7.5 Metriken und Abweichungsmanagement ................................................................ ............................................. 94 7.6 Abweichungen kommunizieren ............................................................................................ 94 ............................ 8. Standards in der Testprozess-Verbesserung ................................................................ ............................................... 95 8.1 Einfhrung ................................ ............................................................................................................................ 95 ............................ 8.2 Normen und Standards ................................ ................................................................................................ ........................................ 95 8.2.1 Allgemeine Aspekte von Standards ................................................................ ................................................. 96 8.2.2 Internationale Standards ................................................................................................ 96 .................................. 8.2.3 Nationale Standards ................................ ................................................................................................ ........................................ 97 8.2.4 Branchenspezifische Standards ...................................................................................... 97 ...................... 8.2.5 Sonstige Standards ................................ ................................................................................................ ......................................... 98 8.3 Testverbesserungs-Prozess ................................................................................................ 99 Prozess ................................ 8.3.1 Einfhrung in die Prozessverbesserung ................................................................ .......................................... 99 8.3.2 Arten der Prozessverbesserung .................................................................................... 100 .................... 8.4 Testprozess verbessern ................................ ................................................................................................ ..................................... 100 8.5 Testprozess mit TMM verbessern ...................................................................................... 101 ...................... 8.6 Testprozess mit TPI verbessern ........................................................................................ 102 ........................ 8.7 Testprozess mit CTP verbessern ....................................................................................... 103 ....................... 8.8 Testprozess mit STEP verbessern .................................................................................... 104 .................... 8.9 Capability Maturity Model Integration, CMMI ................................................................ ..................................... 104 9. Testwerkzeuge und Automatisierung ......................................................................................... 106 ......................... 9.1 Einfhrung ................................ .......................................................................................................................... 106 .......................... 9.2 Testwerkzeugkonzepte ................................ ................................................................................................ ...................................... 106 9.2.1 Kosten, Nutzen und Risiken von Testwerkzeugen und Automatisierung ...................... 107 9.2.2 Testwerkzeugstrategien ................................................................................................ 108 ................................. 9.2.3 Integration und Informationsaustausch zwischen Werkzeugen ................................ 108 .................................... 9.2.4 Automatisierungssprachen: Skripte, Skriptsprachen ..................................................... 109 ..................... 9.2.5 Konzept der Testorakel................................................................................................ 109 .................................. 9.2.6 Testwerkzeuge in Betrieb nehmen ................................................................ ................................................ 109 9.2.7 Open Source-Testwerkzeuge verwenden ................................................................ 110 Testwerkzeuge ................................... 9.2.8 Eigene Testwerkzeuge entwickeln ................................................................ ................................................ 110 9.2.9 Testwerkzeuge klassifizieren ......................................................................................... 111 ......................... 9.3 Testwerkzeugkategorien ................................................................................................ 111 .................................... 9.3.1 Testmanagementwerkzeuge ......................................................................................... 111 ......................... 9.3.2 Testausfhrungswerkzeuge........................................................................................... 112 erkzeuge ........................... 9.3.3 Debugging und Fehleranalysewerkzeuge ................................................................ ..................................... 113 9.3.4 Fehlereinpflanzungs- und Fehlerinjektionswerkzeuge .................................................. 113 .................. 9.3.5 Simulations- und Emulationswerkzeuge ................................................................ ........................................ 114 9.3.6 Statische und dynamische Analysewerkzeuge ............................................................. 114 atische ............................. 9.3.7 Schlsselwortgetriebene Testautomatisierung .............................................................. 115 .............................. Version 2007 Seite 6 von 136 Januar 2010 20100131
9.3.8 Performanztestwerkzeuge ............................................................................................. 115 ............................. 9.3.9 Hyperlink-Testwerkzeuge .............................................................................................. 116 Testwerkzeuge .............................. 10. Soziale Kompetenz und Teamzusammensetzung ................................................................ 117 ................................ 10.1 Einfhrung ................................ .......................................................................................................................... 117 .......................... 10.2 Individuelle Fhigkeiten................................ ................................................................................................ ...................................... 117 10.3 Dynamik im Testteam ................................ ................................................................................................ ........................................ 118 10.4 Testen in der Organisationsstruktur etablieren ................................................................ 118 .................................. 10.5 Motivieren ................................ ........................................................................................................................... 119 ........................... 10.6 Kommunizieren ................................ .................................................................................................................. 120 .................. 11. Referenzen ................................ ............................................................................................................................. 121 ............................. 11.1 Standards ................................ ........................................................................................................................... 121 ........................... 11.1.1 Nach Kapiteln ................................ ................................................................................................ ............................................ 121 11.1.2 Alphabetisch ................................ ................................................................................................ .............................................. 121 11.2 Literatur ................................ .............................................................................................................................. 122 .............................. 11.3 Sonstige Referenzen ................................ ................................................................................................ .......................................... 124 12. Anhang A Hintergrundinformationen zum Lehrplan ............................................................ 125 ............................ 13. Anhang B Hinweise fr die Leser ........................................................................................ 126 ........................ 13.1 Prfungsinstitutionen ................................ ................................................................................................ .......................................... 126 13.2 Prfungskandidaten und Ausbildungsanbieter ................................................................ 126 .................................. 14. Anhang C Hinweise fr die Ausbildungsanbieter ................................................................ 127 ................................ 14.1 Module................................ ................................................................................................................................ 127 ................................ 14.2 Ausbildungszeiten ................................ ................................................................................................ .............................................. 127 14.2.1 Ausbildung je Modul ................................................................................................ 127 .................................. 14.2.2 Gemeinsamkeiten................................ ................................................................................................ ...................................... 127 14.2.3 Quellen ................................ ...................................................................................................................... 127 ...................... 14.3 Praktische bungen ................................ ................................................................................................ ........................................... 127 15. Anhang D Empfehlungen ................................................................................................ 129 .................................... 15.1 Empfehlungen fr die Industrialisierung ................................................................ ............................................. 129 16. Index ................................................................ ................................................................................................ ....................................... 132
Version 2007
Seite 7 von 136
Januar 2010 20100131
Dank
Dieses Dokument wurde von einem Kernteam der Arbeitsgruppe Advanced Level Syllabus (Lehrplan Aufbaukurs) des International Software Testing Qualifications Board erstellt. Dieser Arbeitsgruppe gehrten an: Bernard Homs (Vorsitzender), Graham Bath, Rex Black, Sigrid Eldh, Jayapradeep Jiothis, Paul Jorgensen, Vipul Kocher, Judy McKay, Thomas Mueller, Klaus Olsen, Randy Rice, Olsen, Jrgen Richter, Eric Riou Du Cosquer, Mike Smith, Geoff Thompson, Erik Van Veenendaal. Die Mitglieder der Arbeitsgruppe bedanken sich beim Reviewteam und bei den nationalen Testing TestingBoards fr die konstruktiven Verbesserungsvorschlge und Beitrge. Bei Fertigstellung des Advanced Level Lehrplans hatte die Arbeitsgruppe Advanced Level die folgenden Mitglieder (in alphabetischer Reihenfolge): Graham Bath, Robert Bender, Rex Black, Chris Carter, Maria Clara Choucair, Sigrid Eldh, Dorothy Graham, Bernard Homs (Vorsitzender), Jayapradeep Jiothis, Vipul Kocher, Anastasios aham, Kyriakopoulos, Judy McKay, Thomas Mueller, Klaus Olsen, Avinoam Porat, Meile Posthuma, Erkki Pyhnen, Jrgen Richter, Eric Riou Du Cosquer, Jan Sabak, Hans Schaefer, Maud Sc Schlich, Rajesh Sivaraman, Mike Smith, Michael Stahl, Geoff Thompson, Erik Van Veenendaal. Folgende Personen haben an Review, Kommentierung und der Abstimmung ber diesen Lehrplan mitgearbeitet: Bernard Homs (Leitung) Reto Armuzzi Phillip Isles Horst Pohlmann Sue Atkins Pr. Paul C. Jorgensen Meile Posthuma Graham Bath Vipul Kocher Eric Riou Du Cosquer Paul Beekman Anastasios Kyriakopoulos Stefan Ruff Armin Beer Junfei Ma Hans Schaefer Rex Black Fergus McClachlan Maud Schlich Francisca Blunschi Judy McKay Rajesh Sivaraman Armin Born Don Mills Mike Smith Con Bracke Katja Stalder Gary Mogyorodi Chris Carter Richard Morgan Neil Thompson Maria Clara Choucair Silvio Moser Benjamin Timmerma Timmermans Robert Dankanin Ernst Mller Chris van Bael Reto Mller Piet de Roo Jurian van de Laar Thomas Mller Marnix van den Ent Sigrid Eldh Tim Edmonds Peter Mullins Mark van der Zwan Erwin Engelsma Beat Nagel Stephanie van Dijck Richard Neeve Jan van Moll Graham Freeburn Erik Van Veenendaal Dorothy Graham Klaus Olsen Dale Perry Roland Weber Brian Hambling Phillip Whettlock Jeff B Higgott Helmut Pichler Jrg Pietzsch Derek Young Bernard Homs Mike Young Rob Hendriks Avionam Porat Dr Suhaimi Ibrahim Iris Pinkster Wenqiang Zheng. Dieses Dokument wurde von der Hauptversammlung des ISTQB am 12. Oktober 2007 offiziell ISTQB freigegeben.
Version 2007
Seite 8 von 136
Januar 2010 20100131
0. Einfhrung in den Lehrplan

0.1 Das International Software Testing Qualifications Board
Das International Software Testing Qualifications Board (nachfolgend ISTQB genannt) setzt sich zusammen aus den Mitgliedsboards verschiedener Lnder und Regionen der ganzen Welt. Zum Zeitpunkt der Herausgabe der englischsprachigen Orginalausgabe des Dokuments (12, Oktober 2007) hatte das ISTQB 33 Mitgliedsboards. Weitere Informationen ber Aufbau und Mitgliedschaft im ISTQB finden Sie unter www.ISTQB.org www.ISTQB.org.
Zweck dieses Dokuments

Dieser Lehrplan bildet die Grundlage fr das Softwaretest Qualifizierungsprogramm der Aufbaustufe Softwaretest-Qualifizierungsprogramm (Advanced Level) des International Software Testing Qualifications Board. Das ISTQB stellt den Board. Lehrplan folgenden Adressaten zur Verfgung: 1. Nationalen/regionalen Boards zur bersetzung in die jeweilige Landessprache und zur ationalen/regionalen Akkreditierung von Ausbildungsanbietern. Die nationalen Boards knnen den Lehrplan an die eigenen sprachlichen Anforderungen anpassen sowie die Querverweise ndern und an die prachlichen bei ihnen vorliegenden Verffentlichungen angleichen. 2. Prfungsinstitutionen zur Erarbeitung von Prfungsfragen in der jeweiligen Landessprache, die sich an den Lernzielen der jewei jeweiligen Module orientieren. 3. Ausbildungsanbietern zur Erstellung ihrer Kursunterlagen und zur Bestimmung einer geeigneten Unterrichtsmethodik. 4. Prfungskandidaten zur Vorbereitung auf die Prfung (als Teil des Ausbildungslehrgangs oder auch kursunabhngig). 5. Allen Personen, die im Bereich Software und Systementwicklung ttig sind und die len Softwareprofessionelle Kompetenz beim Testen von Software verbessern mchten, sowie als Grundlage fr Bcher und Fachartikel. Das ISTQB kann auch anderen Personenkreisen oder Institutionen die Verwendung dieses Institutionen Lehrplans fr andere Zwecke genehmigen, wenn diese vorab eine entsprechende schriftliche Genehmigung einholen.
Certified Tester Advanced Level im Bereich Softwaretesten

Die Aufbaustufe (Advanced Level) des Certified Tester Ausbildungsprogramms richtet sich an Ausbildungsprogramms Personen, die eine fortgeschrittene Stufe in ihrem beruflichen Werdegang im Bereich Softwaretesten erreicht haben. Dazu gehren Personen in Rollen wie Tester, Test Analysts, Testingenieure, Testberater, Testmanager, Abnahmetester und Softwareentwickler. Die Aufbaustufe des Certified Abnahmetester Tester Ausbildungsprogramms ist auch fr Personen geeignet, die ein grundlegendes Verstndnis ber das Thema Softwaretesten erwerben mchten, beispielsweise Projektleiter, Qualittsmanager, Softwareentwicklungs-Manager, Fachanalytiker, IT Leiter oder Managementberater. Fr die Manager, IT-Leiter Zertifizierung als ISTQB Certified Tester Advanced Level mssen die Prfungskandidatinnen und -kandidaten das Zertifikat ISTQB Certified Tester Foundation Level vorweisen und bei der fr sie kandidaten und zustndigen Prfungsinstitution ausreichende praktische Erfahrung nachweisen, um als fr die Aufbaustufe (Advanced Level) qualifiziert zu gelten. Bitte wenden Sie sich an die fr Sie zustndige Prfungsinstitution, dort erfahren Sie mehr ber die spezifischen Kriterien zum Nachweis der notwendigen praktischen Erfahrung.
Version 2007
Seite 9 von 136
Januar 2010 20100131
Lernziele/Kognitive Ebenen
Die Lernziele der jeweiligen Kapitel dieses Lehrplans sind so unterteilt, dass sie den einzelnen Modulen eindeutig zugeordnet werden knnen. Weitere Details und Beispiele fr Lernziele enthlt Weitere Abschnitt 0.3. Der Inhalt des Lehrplans, die Begriffe und die wichtigsten Elemente aller aufgefhrten Normen und Standards sollen zumindest wiedergegeben werden knnen (K1), auch wenn dies in den Lernzielen nicht ausdrcklich erwhnt wird.
Prfung
Alle Prfungen fr das Advanced Level Certificate mssen sich auf den vorliegenden Lehrplan und den Foundation-Level-Lehrplan beziehen. Antworten auf die Prfungsfragen knnen Stoff aus mehreren Kapiteln dieses Lehrplans und des Foundation-Level-Lehrplans voraussetzen. s Grundstzlich knnen alle Kapitel beider Lehrplne geprft werden. Das Format der Prfung ist in den Richtlinien Advanced Exam Guidelines des ISTQB festgelegt. Einzelne nationale Boards knnen auf Wunsch auch andere Prfungsformate anwenden. ationale Die Prfungen knnen im Rahmen eines akkreditierten Ausbildungslehrgangs abgelegt werden oder kursunabhngig, beispielsweise in einem Prfungszentrum. Die Prfungen knnen in Papierfor oder Papierform elektronisch absolviert werden, jedoch auf jeden Fall mit Prfungsaufsicht (d.h. berwachung der Prfung durch eine vom nationalen Board oder von der Prfungsinstitution beauftragte Person).
Akkreditierung
Ausbildungsanbieter, deren Ausbildungsunterlagen auf diesem Lehrplan basieren, mssen durch ein Ausbildungsunterlagen vom ISTQB anerkanntes nationales Testing Board akkreditiert werden. Die entsprechenden Testing-Board Akkreditierungsrichtlinien knnen vom zustndigen nationalen Testing Board angefordert werden oder Testing-Board von der Organisation, die die Akkreditierung im Auftrag des nationalen Boards erteilt. Akkreditierte ation, Kurse sind als zu diesem Lehrplan konform anerkannt und drfen als Bestandteil des Lehrgangs die ISTQB Prfung enthalten. Weitere Anleitungen enthlt Anhang C Hinweise fr die Ausbildungsanbieter
Detaillierungsgrad
Der Detaillierungsgrad dieses Lehrplans erlaubt konsistentes Lehren und Prfen auf internationaler Ebene. Um dieses Ziel zu erreichen, enthlt der vorliegende Lehrplan allgemeine Lernziele, die die Absicht des Advanced Level (Aufbaustufe) beschreiben, Lernziele fr jeden Wissensbereich, die das zu erzielende kognitive Lernergebnis und und die zu erzielende Einstellung der Teilnehmer beschreiben, ende eine Liste zu lehrender Inhalte mit ihrer Beschreibung und, wo notwendig, Verweise auf weiterfhrende Quellen, eine Liste mit Begriffen, die die Teilnehmer wiedergeben knnen und verstanden haben mssen, eine Beschreibung der wichtigsten zu lehrenden Konzepte, einschlielich der Quellen, wie schreibung anerkannte Fachliteratur oder Normen und Standards. Der vorliegende Lehrplan ist keine vollstndige Beschreibung des Wissensgebiets Softwaretesten. Er gibt an, wie detailliert der Stoff in den Lehrgngen des Advanced Level zu behandeln ist. t
Version 2007
Seite 10 von 136
Januar 2010 20100131
Aufbau des Lehrplans

Der Lehrplan besteht aus 10 Hauptkapiteln, jeweils mit einem einfhrenden Abschnitt zu Beginn des Kapitels, in dem dargestellt wird, wie die jeweiligen Inhalte (Module) fr die verschiedenen Testrollen relevant sind. Die Abschnitte 0.3 bis 0.6 enthalten kapitelweise fr jedes Modul die Lernziele fr Trainingszwecke. In diesen Abschnitten ist auch angegeben, wie viel Unterrichtszeit fr ein Thema mindestens aufzuwenden ist. Es wird dringend empfohlen, mit einem Kapitel des Lehrplans parallel die jeweiligen Lernziele zu lesen. Diese Vorgehensweise ermglicht es, die Anforderungen in einem Kapitel zu verstehen, und die wesentlichen Inhalte des jeweiligen Kapitels fr jedes der drei Module zu erkennen.
Begriffe und Definitionen

Viele Begriffe in der Software-Fachliteratur sind austauschbar. Die gltigen Definitionen fr diesen Fachliteratur Advanced Level Lehrplan sind im Standard Glossar der Testbegriffe festgeschrieben, das vom Standard-Glossar ISTQB verffentlicht wurde.
Testanstze
Es gibt verschiedene Anstze fr das Testen von Software, die auf vorliegenden Spezifikationen, Programmstrukturen, Daten, Risiken, Prozessen, Normen und Standards und Taxonomien basieren. Unterschiedliche Prozesse und Werkzeuge untersttzen die Testprozesse; darber hinaus existieren Werkzeuge Methoden fr die Verbesserung bestehender Prozesse. Der vorliegende Advanced Level Lehrplan ist gem den in ISO 9126 vorgegebenen Anstzen aufgebaut, mit einer klaren Trennung zwischen funkti funktionalen, nicht-funktionalen und untersttzenden funktionalen Anstzen. Er nennt untersttzende Prozesse und einige Verbesserungsmethoden. Organisation und Prozesse wurden nach freiem Ermessen ausgewhlt und sollen Testern und Testmanagern eine gute Grundlage liefern.
0.2 Erwartungen
Prfung und Zertifizierung in der Aufbaustufe (Advanced Level) sind im vorliegenden Lehrplan nach einer Gliederung in drei Hauptaufgabenbereiche beschrieben. Jede Aufgabenbeschreibung steht fr bestimmte grundlegende Zustndigkeiten und Erwartungen in einer Organisation. Die Zustndigkeiten gkeiten und die damit verbundenen Aufgaben knnen in einer Organisation auf mehrere Personen verteilt sein oder alle von einer einzelnen Person wahrgenommen werden. Die folgenden Abschnitte skizzie skizzieren diese Zustndigkeiten.
0.2.1 Testmanager Advanced Level

Professionelle Testmanager des Advanced Level sollten bergeordnete Testziele und strategien fr die zu testenden Systeme festlegen knnen bergeordnete strategien knnen; Aufgaben planen, Termine dafr festlegen und ihren Fortschritt verfolgen knnen Fortschritt knnen; die notwendigen Aktivitten beschreiben und organisieren knnen ie knnen; ausreichende Ressourcen fr die Aufgaben auswhlen, beschaffen und zuordnen knnen knnen: Mitglieder eines Testteams auswhlen, Testteams organisieren und leiten knnen knnen; die Kommunikation zwischen den Mitgliedern der Testteams untereinander sowie zwischen mmunikation den Testteams und allen anderen Betroffenen organisieren knnen und knnen;
Version 2007
Seite 11 von 136
Januar 2010 20100131
getroffene Entscheidungen begrnden und, gegebenenfalls, geeignete Berichtsunterlagen , erstellen knnen.
0.2.2 Test Analyst Advanced Level

Test Analysts des Advanced Level sollten die in der Teststrategie definierten Aufgaben nach den Anforderungen des Geschftsbereichs strukturieren knnen; das System detailliert genug analysieren knnen, um die Erwartungen der Anwen Anwender an die Qualitt zu erfllen; die Systemanforderungen bewerten und damit die Gltigkeit fr einer Fachdomne berprfen knnen; geeignete Manahmen vorbereiten und durchfhren sowie ber ihren Fortschritt berichten durchfhren, knnen; die notwendigen Nachweise fr Auswertungen bereitstellen knnen und die notwendigen Werkzeuge und Techniken zum Erreichen der definierten Testziele implementieren knnen.
0.2.3 Technical Test Analyst Advanced Level

Technical Test Analysts des Advanced Level sollten die in der Teststrategie definierten Aufgaben hinsichtlich der technischen Anforderungen strukturieren knnen; die systeminterne Struktur detailliert genug analysieren knnen, um Testflle zu entwerfen, die die erwartete Qualitt nachweisen knnen knnen; das System hinsichtlich seiner technischen Qualittsmerkmale, wie Leistung, Sicherheit, usw. bewerten knnen; geeignete Manahmen vorbereiten und durchfhren sowie ber ihren Fortschritt berichten durchfhren, knnen; technische Testaktivitten durchfhren knnen knnen; die notwendigen Nachweise fr Ausw Auswertungen bereitstellen knnen und die notwendigen Werkzeuge und Techniken zum Erreichen der definierten Testziele implementieren knnen.
Version 2007
Seite 12 von 136
Januar 2010 20100131
0.3 Lernziele/Kognitive Ebenen des Wissens

Die nachfolgend definierten Lernziele bilden die Grundlage des Lehrplans. Jedes Thema des Lehrplans wird anhand des zugeordneten Lernziels geprft. Kognitive Ebene 1: Kennen (K1) Der oder die Lernende kann Begriffe oder Konzepte erkennen, sich an sie erinnern und sie wiedergeben. Schlsselbegriffe: erinnern, erkennen, kennen, wieder wiedergeben. Beispiel: Sie knnen die Definition von Fehlerwirkung erkennen als das Nichterbringen einer definierten Leistung gegenber einem Anwender oder anderen Betroffenen, oder erwarteten oder die tatschliche Abweichung einer Komponente oder eines Systems von der erwa vereinbarten Auslieferung, Dienstleistung oder vom erwarteten Ergebnis. Kognitive Ebene 2: Verstehen (K2) Der oder die Lernende kann Aussagen zu einem Thema begrnden und erklren. Er kann Sachverhalte, Testkonzepte und Testvorgehen zusammenfassen, unterscheiden, klassifizieren und zusammenfassen, anhand von Beispielen erlutern. Fr Sachverhalte kann er beispielsweise Fachbegriffe vergleichen und fr Testvorgehen den Ablauf erklren. Schlsselbegriffe: darstellen, erlutern anhand von Beispielen, gegenberstellen, interpretieren, gegenberstellen, kategorisieren, klassifizieren, schlussfolgern, bertragen, vergleichen, zuordnen, zusammenfassen Beispiele: Erklren Sie, weshalb Tests so frh wie mglich entworfen werden sollten: Um Fehler zu finden, solange deren Behebung noch kostengnstiger ist. Um die wichtigsten Fehler zuerst zu finden. Erklren Sie Gemeinsamkeiten und Unterschiede von Integrations und Systemtests: Integrations Gemeinsamkeiten: Es wird mehr als eine Komponente getestet, nicht funktionale Aspekte nicht-funktionale knnen getestet werden. Unterschiede: Integrationstests konzentrieren sich auf Schnittstellen und Interaktionen; Systemtests auf die Aspekte des Gesamtsystems, wie End End-to-End-Ablufe. Kognitive Ebene 3: Anwenden (K3) Der oder die Lernende kann die korrekte Anwendung eines Testkonzepts oder eines Testverfahrens Testkonzepts auswhlen und auf einen gegebenen Kontext anwenden. K3 bezieht sich normalerweise auf prozedurales Wissen. Kreative Aufgaben, wie die Bewertung einer Softwareanwendung oder das Erstellen eines Modells fr eine bestimmte Software, gehren nicht dazu. Wenn ein gegebenes Modell Software, vorliegt, und im Lehrplan das schrittweise Vorgehen zur Erstellung eines Testfalls vom Modell abgedeckt wird, dann gehrt es zu K3. Schlsselbegriffe: anwenden, durchfhren, implementieren, eine Vorgehensweise befolgen, ein Vorgehensweise Verfahren ausfhren Beispiele: Identifizieren Sie die Grenzwerte fr gltige und ungltige quivalenzklassen. Befolgen Sie die allgemeine Vorgehensweise fr das Erstellen von Testfllen, und whlen Sie aus einem vorgegebenen Zustandsbergangsdiagramm (und Testfllen) die notwendigen Zustandsbergangsdiagramm Testflle aus, um alle Statusbergnge abzudecken.
Version 2007
Seite 13 von 136
Januar 2010 20100131
Kognitive Ebene 4: Analysieren (K4) Der oder die Lernende kann Informationen zu bestimmten Testszenarien oder Testverfahren zum besseren Verstndnis in ihre Bestandteile zerlegen und zwischen Sachverhalten und abgeleiteten e Schlussfolgerungen unterscheiden. Typische Anwendungen sind die Analyse eines Dokuments, einer 1 Software oder Projektsituation und der Vorschlag angemessener Manahmen zur Problemlsung. Schlsselbegriffe: analysieren, auswhlen, beurteilen, bewerten, entwerfen, erstellen, fokussieren, generieren, Hypothesen aufstellen, konstruieren, koordinieren, planen, produzieren, strukturieren, synthetisieren, berwachen, unterscheiden, zerlegen, zurc zurckfhren. Beispiele: Analysieren Sie Produktrisiken und schlagen Sie vorbeugende oder korrigierende Manahmen vor. Beschreiben Sie, welche Teile eines Abweichungsberichts einen Sachverhalt darstellen und bei welchen es sich um Schlussfolgerungen aus den Erg Ergebnissen handelt. Literatur (zum Thema Kognitive Ebenen von Lernzielen) Bloom, B. S. (1956). Taxonomy of Educational Objectives, Handbook I: The Cognitive Domain, David McKay, Co. Inc. Anderson, L. W. and Krathwohl, D. R. (Hg.) (2001). A Taxonomy for Learning, Teaching, and rning, Assessing: A Revision of Bloom's Taxonomy of Educational Objectives Allyn & Bacon. Objectives,
0.4 Lernziele fr Testmanager

Dieser Abschnitt enthlt die detaillierten Lernziele fr das Testmanager Testmanager-Modul. Fr alle Teile dieses Lehrplans gilt, dass sie auf der Wissensstufe K1 geprft werden knnen. Dies bedeutet, dass der oder die Lernende den entsprechenden Begriff oder das Konzept erkennt, sich daran erinnert und es wiedergeben kann. Die folgende Auflistung enthlt deshalb nur die Lernziele der Wissensstufen K2, K3 und K4. deshalb Einfhrung in den Lehrplan Testmanager [60 Minuten] (einschlielich Wiederholung des Lehrplans zum ISTQB Foundation Level) Kapitel 1: Grundlegende Aspekte des Softwaretestens [150 Minuten] 1.2 Testen im Softwarelebenszyklus esten LO-1.2.1 (K2) LO-1.2.2 (K4) Sie knnen beschreiben, wie das Testen Bestandteil aller Softwareentwicklungs und SoftwareentwicklungsWartungsaktivitten ist ist. Sie knnen Softwarelebenszyklusmodelle analysieren und eine kurze bersicht ber die entsprechenden Aufgaben/Testaktivitten geben, die durchzufhren sind, und tsprechenden dabei zwischen Test und Entwicklungsaktivitten unterscheiden. Test-
Die kognitive Ebene K4 wird hier in einem erweiterten Sinn verwendet und schliet Fhigkeiten des Beurteilens (Evaluate) und Erschaffens (Create) mit ein. Dies im Gegensatz zur angegebenen (Create) Literatur, die diese Fhigkeiten gesondert ausweist. Version 2007 Seite 14 von 136 Januar 2010 20100131
1.3 Spezifische Systeme LO-1.3.1 (K2) LO-1.3.2 (K2) Sie knnen anhand von Beispielen die spezifischen Aspekte beim Testen von Multisystemen erklren. Sie knnen erklren, weshalb die drei wichtigsten Ergebnisse beim Testen von sicherheitskritischen Systemen die Einhaltung der Vorschriften (Konformitt) (Konformitt nachweisen mssen.
1.4 Metriken und Messung LO-1.4.1 (K2) LO-1.4.2 (K3) Sie verstehen testbezogene Standardmetriken und knnen sie miteinander e vergleichen. Sie knnen Testaktivitten durch Messung des Testobjekts oder der Testobjekte und des Testprozesses berwachen.
Kapitel 2: Testprozess [120 Minuten] 2.3 Testplanung und Teststeuerung tplanung LO-2.3.1 (K2) LO-2.3.2 (K2) Sie knnen anhand von Beispielen erlutern, wie sich Teststrategien auf die Testplanung auswirken. Sie knnen Testarbeitsergebnisse vergleichen und anhand von Beispielen die Zusammenhnge zwischen Arbeitsergebnissen in der Entwicklung und beim Test erlutern. Sie knnen die Aktivitten zur Teststeuerung klassifizieren, mit denen nachgewiesen werden soll, ob bergeordnete Testzielsetzung, Teststrategien und Testziele erreicht wurden.
LO-2.3.3 (K2)
2.5 Testrealisierung und Testdurchfhrung LO-2.5.1 (K2) LO-2.5.2 (K2) Sie knnen die Voraussetzungen fr die Testdurchfhrung erlutern. Sie knnen anhand von Beispielen die Vor und Nachteile einer frhzeitigen VorTestrealisierung erlutern, und dabei unterschiedliche Testmethoden (wie in Kapitel 4 unterschiedliche aufgefhrt) bercksichtigen. Sie knnen erlutern, warum Nutzer und/oder Kunden an der Durchfhrung der Tests teilnehmen knnen. Sie knnen darstellen, wie der Umfang der Testprotokollierung je nach Teststufe Testprotokollierung variieren kann.
LO-2.5.3 (K2) LO-2.5.4 (K2)
2.6 Testauswertung und -bericht LO-2.6.1 (K2) Sie knnen zusammenfassen, welche Informationen im Lauf des Testprozesses fr eine korrekte Testberichterstattung und Bewertung der Testendekriterien zu sammeln sind.
2.7 Abschluss der Testaktivitten LO-2.7.1 (K2) Sie knnen die vier Gruppen von Testabschlussaktivitten zusammenfassen.
Version 2007
Seite 15 von 136
Januar 2010 20100131
LO-2.7.2 (K3)
Sie knnen die in der Testabschlussphase gewonnenen Erkenntnisse verallgemeinern, um die Bereiche fr eine Verbesserung oder Wiederholung zu Verbesserung identifizieren.
Kapitel 3: Testmanagement [1120 Minuten] 3.2 Testmanagement-Dokumentation Dokumentation LO-3.2.1 (K4) LO-3.2.2 (K2) Sie knnen einige Testmanagement Dokumente erlutern, wie Testkonzept, Testmanagement-Dokumente Testentwurfsspezifikation und Testvorgehen gem IEEE Standard 829. gem Sie knnen mindestens vier wichtige Elemente einer Teststrategie oder eines Testansatzes darstellen und angeben, welche Dokumente gem IEEE Standard 829 Teststrategieelemente enthalten. Sie knnen darstellen, wie und warum Abweichungen von der Teststrategie in den ellen, anderen Testmanagement Testmanagement-Dokumenten behandelt werden.
LO-3.2.3 (K2)
3.3 Dokumentvorlagen fr Testkonzepte LO-3.3.1 (K2) LO-3.3.2 (K2) Sie knnen den Aufbau eines Mastertestkonzepts gem IEEE Standard 829 zusammenfassen. Sie knnen die Themen eines gem IEEE Standard 829 aufgebauten Testkonzepts umschreiben und interpretieren. Dabei knnen Sie eingehen auf die Anpassung des Testkonzepts an ein Unternehmen/eine Organisation, auf das Produktrisiko sowie auf Risiko, Gre und Formalitt eines Projekts.
3.4 Testschtzung LO-3.4.1 (K3) Sie knnen den Testaufwand fr ein kleines Beispielsystem unter Anwendung einer metrikbasierten und einer erfahrungsbasierten Vorgehensweise schtzen; dabei knnen Sie die Einf Einflussfaktoren aus Kosten, Aufwand und Zeitdauer bercksichtigen. Sie knnen anhand von Beispielen die im Lehrplan aufgefhrten Faktoren erlutern, die zu ungenauen Testschtzungen fhren knnen.
LO-3.4.2 (K2)
3.5 Zeitliche Testplanung LO-3.5.1 (K2) Sie knnen anhand von Beispielen die Vorteile einer frhzeitigen und iterativen Erstellung eines Testkonzepts erlutern.
3.6 Testfortschritt berwachen und steuern LO-3.6.1 (K2) LO-3.6.2 (K2) Sie knnen die verschiedenen Verfahren zur Steuerung des Testfortschritts vergleichen. Sie knnen mindestens fnf konzeptionell unterschiedliche Beispiele nennen, wie die Ergebnisse der Testfortschrittsberwachung den Verlauf des Testprozesses beeinflussen. Sie knnen Ergebnisse aus der berwachung und Steuerung des Testfortschritts dazu verwenden, Manahmen und einen Aktionsplan auszuarbeiten, mit denen der aktuelle Testprozess verbessert werden kann. Sie knnen Verbesserungen vorschlagen.
LO-3.6.3 (K4)
Version 2007
Seite 16 von 136
Januar 2010 20100131
LO-3.6.4 (K4)
Sie knnen Testergebnisse analysieren und den Testfortschritt beurteilen, wie er mit Testfortschritt allen Berichtsdimensionen in Testfortschrittsbericht und Testabschlussbericht dokumentiert ist.
3.7 Geschftswert des Testens LO-3.7.1 (K2) LO-3.7.2 (K3) Sie knnen Beispiele (Manahmen) fr alle vier Kategorien nennen, die di die Qualittskosten bestimmen. Sie knnen die relevanten quantitativen und/oder qualitativen Werte fr einen gegebenen Kontext nennen.
3.8 Verteiltes Testen, Outsourcing und Insourcing LO-3.8.1 (K2) Sie knnen Risiken, Gemeinsamkeiten und U Unterschiede der drei Personalorganisations-Modelle Personalorganisations Modelle (verteiltes Testen, Outsourcing, Insourcing) nennen.
3.9 Risikoorientiertes Testen 3.9.1 Einfhrung in das risikoorientierte Testen LO-3.9.1.1 (K2) Sie knnen anhand von Beispielen erlutern, auf welche unterschiedliche Art und 3.9.1.1 welche Weise risikoorientiertes Testen auf Risiken reagiert. LO-3.9.1.2 (K4) Sie knnen die Risiken eines Projekts und eines Produkts identifizieren und eine 3.9.1.2 geeignete Teststrategie und ein Testkonzept fr diese Risiken bestimmen. 3.9.2 Risikomanagement 3.9.2.1 LO-3.9.2.1 (K3) Sie knnen eine Risikoanalyse fr ein Produkt aus Sicht der Tester durchfhren und dabei die FMEA-Vorgehensweise befolgen. Vorgehensweise LO-3.9.2.2 (K4) Sie knnen Ergebnisse aus der Sicht verschiedener wichtiger Betroffener 3.9.2.2 zusammenfassen. Sie knnen deren kollektive Beurteilung dazu nutzen, geeignete fassen. Testaktivitten zur Risikobeherrschung zu skizzieren. 3.9.3 Risikomanagement im Softwarelebenszyklus LO-3.9.3.1 (K2) Sie knnen die Merkmale des Risikomanagements darstellen, die urschlich dafr 3.9.3.1 urschlich sind, dass Risikomanagement ein iterativer Prozess ist. LO-3.9.3.2 (K3) Sie knnen eine gegebene risikoorientierte Teststrategie in konkrete Testaktivitten 3.9.3.2 umsetzen und deren Auswirkungen beim Testen berwachen. LO-3.9.3.3 (K4) Sie knnen die Testergebnisse analysieren und dokumentieren und Restrisiken bestimmen oder benennen, um so dem Projektmanagement intelligente Release ReleaseEntscheidungen zu ermglichen. 3.10 FMEA (Fehler-Mglichkeits- und Einfluss Einfluss-Analyse) LO-3.10.1 (K2) Sie knnen das Konzept der FMEA beschreiben und anhand von Beispielen ihre Anwendung in Projekten und den Nutzen fr die Projekte erlutern. Version 2007 Seite 17 von 136 Januar 2010 20100131
3.11 Besonderheiten beim Testmanagement LO-3.11.1 (K2) Sie knnen die Besonderheiten des Testmanagements beim explorativen Test Testen, beim Test von Multisystemen und beim Test sicherheitskritischer Systeme vergleichen bezglich Teststrategie, Vor und Nachteilen und Angemessenheit und Vorbezglich der Auswirkungen auf Testplanung, berdeckung, berwachung und Steuerung. Kapitel 4: Testverfahren [0 Minuten] Kein Lernziel dieses Kapitels (auf keiner der kognitiven Ebenen) betrifft die Rolle Testmanager. Kapitel 5: Test der Softwareeigenschaften [0 Minuten] Kein Lernziel dieses Kapitels (auf keiner der kognitiven Ebenen) betrifft die Rolle Testmanager. Kapitel 6: Review [120 Minuten] 6.2 Grundstze von Reviews LO-6.2.1 (K2) Sie knnen die Vorteile von Reviews im Vergleich zu dynamischen und weiteren statischen Testverfahren erlutern. 6.4 Einfhrung von Reviews LO-6.4.1 (K2) Sie knnen Review-Arten miteinander vergleichen und deren relative Strken, -Arten Schwchen und Einsatzbereiche aufzeigen. LO-6.4.2 (K3) Sie knnen ein Review Team durch ein formales Review mit den notwendigen in Review-Team Schritten fhren. LO-6.4.3 (K4) Sie knnen einen R Review-Plan als Teil des Qualitts-/Testkonzepts eines Projekts /Testkonzepts skizzieren, der die Review Techniken unter Bercksichtigung der aufzudeckenden Review-Techniken Fehler und der Fhigkeiten des verfgbaren Personals einsetzt und auf die geeigneten dynamischen Testanstze absti abstimmt. 6.5 Erfolgsfaktoren fr Reviews LO-6.5.1 (K2) Sie knnen die mglichen Risiken erlutern, wenn technische, organisatorische und personenbezogene Faktoren beim Durchfhren von Reviews nicht bercksichtigt werden. Kapitel 7: Fehler- und Abweichungsman Abweichungsmanagement [80 Minuten] LO-7.1 (K3) LO-7.2 (K3) LO-7.3 (K4) 1993 Sie knnen einen Abweichung nach dem in IEEE Standard 1044-1993 festgelegten Abweichungsmanagement-Lebenszyklusmodell bearbeiten. Abweichungsmanagement Sie knnen Fehlerberichte auf Basis des IEEE Standard 1044 1993 und der 1044-1993 angewendeten Fehlertaxonomie bewerten, um deren Qualitt zu verbessern. wendeten Sie knnen die im Lauf der Zeit erstellten Fehlerberichte analysieren und die Fehlertaxonomie aktualisieren.
Kapitel 8: Standards im Testverbesserungs Testverbesserungs-Prozess [120 Minuten] LO-8.1 (K2) Sie knnen Quellen der Softwarestandards zusammenfassen und Sie knnen die Ntzlichkeit der Softwarestandards fr das Softwaretesten erklren.
8.4 Testverbesserungs-Prozess
Version 2007
Seite 18 von 136
Januar 2010 20100131
LO-8.4.1 (K3) LO-8.4.2 (K2)
LO-8.4.3 (K2)
Sie knnen einen Testverbesserungsplan erstellen und testen und dabei die inen und allgemeinen Prozessschritte einsetzen und die richtigen Personen beteiligen. Sie knnen die in den Modellen TMM, TPI, CTP, STEP definierten Testverbesserungs-Prozesse zusammenfassen sowie die Prozessbereiche -Prozesse Verifizierung und Validierung nach CMMI. ung Sie knnen die Bewertungskriterien der Testverbesserungs Testverbesserungs-Modelle TMM, TPI, CTP, e STEP und die Prozessbereiche Verifizierung und Validierung nach CMMI erklren.
Kapitel 9: Testwerkzeuge und Automatisierung [90 Minuten] 9.2 Testwerkzeugkonzepte LO-9.2.1 (K2) Sie knnen die Grundgedanken und Wesensmerkmale in jedem der folgenden berlegungen zu Testwerkzeugen miteinander vergleichen: Kosten, Nutzen und Kosten, Risiken von Testwerkzeugen und Automatisierung Testwerkzeugstrategien Automatisierung, erkzeugstrategien, Integration und Informationsaustausch, Automatisierungssprachen, Testorakel, Integration Informationsaustausch, Testwerkzeuge in Betrieb nehmen Open Source-Werkzeuge, Eigene Testwerkzeuge nehmen, Eigene Testwerkzeuge entwickeln sowie Testwerkzeuge klassifizieren. entwickeln Sie knnen beschreiben, warum und wann es wichtig ist, eine Strategie fr den eschreiben, Einsatz von Testwerkzeugen zu erstellen. Sie verstehen die verschiedenen Phasen der Testwerkzeug Implementierung. ie Testwerkzeug-Implementierung.
LO-9.2.2 (K2) LO-9.2.3 (K2)
9.3 Testwerkzeugkategorien LO-9.3.1 (K2) LO-9.3.2 (K2) Sie knnen die Testwerkzeugkategorien nach Zielsetzung, Verwendungszweck, estwerkzeugkategorien Strken, Risiken und mit Beispielen zusammenfassen. Sie knnen die spezifischen Anforderungen an Testwerkzeuge und Open Source ie SourceTestwerkzeuge zusammenfassen, die beim Testen sicherheitskritischer Systeme sicherheitskritischer eingesetzt werden. Sie knnen wichtige Aspekte und Konsequenzen unterschiedlicher Testwerkzeuge ichtige und deren Implementierung, Verwendung und ihre Auswirkung auf den Testprozess beschreiben. eschreiben, Sie knnen beschreiben, wann und warum die Entwicklung eines eigenen Werkzeugs in Frage kommt, sowie die damit verbundenen Vorteile, Risiken und Folgen.
LO-9.3.3 (K2)
LO-9.3.4 (K2)
Kapitel 10: Soziale Kompetenz und Teamzusammensetzung [240 Minuten] 10.2 Individuelle Fhigkeiten LO-10.2.1 (K3) Sie knnen einen vorgegebenen Fragebogen anwenden, um Strken und Schwchen von Teammitgliedern festzustellen bezogen auf die Anwendung von Softwaresystemen, Kenntnissen des Geschftsbereichs/der Branche, den Bereich der Systementwicklung, des Softwaretestens und den zwischenmenschlichen Softwaretestens Fhigkeiten. 10.3 Dynamik im Testteam
Version 2007
Seite 19 von 136
Januar 2010 20100131
LO-10.3.1 (K3) Sie knnen eine Soll/Ist Analyse durchfhren, um die bentigten technischen ine Soll/Ist-Analyse Fhigkeiten oder erforderliche soziale Kompetenz fr die offenen Positionen einer Organisation zu bestimmen. nisation 10.4 Testen in der Organisationsstruktur etablieren LO-10.4.1 (K2) Sie knnen die verschiedenen organisatorischen Optionen bzgl. der Unabhngigkeit ie des Testens charakterisieren und mit Insourcing, Outsourcing und Off Shoring Off-Shoring vergleichen.
10.5 Motivieren LO-10.5.1 (K2) Sie knnen Beispiele anfhren fr die Tester motivierende und demotivierende Faktoren. 10.6 Kommunizieren LO-10.6.1 (K2) Sie knnen anhand von Beispielen eine professionelle, objektive und effektive nhand Kommunikation in einem Projekt aus Sicht des Testers beschreiben Stellen Sie d ation beschreiben. dabei auch Risiken und Chancen dar.
Version 2007
Seite 20 von 136
Januar 2010 20100131
0.5 Lernziele fr Test Analysts

Dieser Abschnitt enthlt die detaillierten Lernziele fr das Modul Test Analyst. Fr alle Teile dieses Lehrplans gilt, dass sie auf der Wissensstufe K1 geprft werden knnen. Dies e bedeutet, dass der oder die Lernende den entsprechenden Begriff oder das Konzept erkennt, sich daran erinnert und es wiedergeben kann. Die folgende Auflistung enthlt deshalb nur die Lernziele der Wissensstufen K2, K3 und K4. lt Einfhrung in den Lehrplan Test Analyst [60 Minuten] (einschlielich Wiederholung des Lehrplans zum ISTQB Foundation Level) Kapitel 1: Grundlegende Aspekte des Softwaretestens [30 Minuten] Kapitel 2: Testprozesse [180 Minuten] 2.4 Testanalyse und Testentwurf LO-2.4.1 (K2) LO-2.4.2 (K2) LO-2.4.3 (K2) LO-2.4.4 (K2) Sie knnen erklren, warum funktionale Tests in bestimmten Lebenszyklusphasen einer Anwendung stattfinden. Sie knnen anhand von Beispielen die Kriter Kriterien erlutern, die bei der Entwicklung von Testbedingungen Struktur und Tiefe beeinflussen. Sie knnen beschreiben, inwiefern Testanalyse und Testentwurf statische Testtechniken sind, die zur Aufdeckung von Fehlern eingesetzt werden knnen. Sie knnen anhand von Beispielen das Konzept der Testorakel erlutern und wie ein Testorakel in Testspezifikationen eingesetzt werden kann.
2.5 Testrealisierung und Testdurchfhrung LO-2.5.5 (K2) Sie knnen die Voraussetzungen fr die Testdurchfhrung beschreiben, einschlielich Testdurchfhrung Testmitteln, Testumgebung, Konfigurationsmanagement und Abweichungsmanagement.
2.6 Testendekriterien auswerten, Bericht LO-2.6.2 (K3) Sie knnen mit vorgegebenen Metriken bewerten, ob ein bestimmtes Testendekriterium erfllt ist.
Kapitel 3: Testmanagement [120 Minuten] 3.9.2 Risikomanagement LO-3.9.2.3 (K3) Sie knnen die Auswahl von Testfllen, Testberdeckung und Testdaten auf Basis 3.9.2.3 des Risikos priorisieren und das angemessen in einem Testkonzept und einer Testspezifikation dokumentieren. LO-3.9.2.4 (K2) Sie knnen die Aktivitten bei einem risikoorientierten Testansatz fr Planung und 3.9.2.4 Durchfhrung von fachlichen Tests umreien.
Version 2007
Seite 21 von 136
Januar 2010 20100131
Kapitel 4: Testverfahren [1080 Minuten] 4.2 Spezifikationsorientierten Testverfahren LO-4.2.1 (K2) Sie knnen Beispiele fr typische Fehlerzustnde anfhren, die sich mit den jeweiligen spezifikationsorientierten Testverfahren identifizieren lassen, und den entsprechenden berdeckungsgrad angeben. Sie knnen Testflle aus vorgegebenen Softwaremodellen erstellen und dabei n folgende Testentwurfsverfahren anwenden. Die Tests sollen dabei eine gegebene Modellberdeckung erzielen: quivalenzklassenbildung Grenzwertanalyse Entscheidungstabellentest Zustandsbasiert Test Zustandsbasierter Klassifikationsbaumverfahren Paarweises Testen Anwendungsfallbasierte Testen Anwendungsfallbasiertes Sie knnen ein System oder dessen Anforderungsspezifikation analysieren und festlegen, welche spezifikationsorientierten Testverfahren fr bestimmte Zielsetzungen anzuwenden sind, und Sie knnen eine Testspezifikation nach IEEE setzungen Standard 829 skizzieren, mit dem Schwerpunkt auf funktionalen und fachlichen Testfllen und Testverfahren.
LO-4.2.2 (K3)
LO-4.2.3 (K4)
4.4 Fehlerbasierte und erfahrungsbasierte Testverfahren LO-4.4.1 (K2) Sie knnen Prinzip und Grnde fr das fehlerbasierte Testentwurfsverfahren beschreiben und gegen den Einsatz spezifikationsorientierter und strukturorientierter Testverfahren abgrenzen abgrenzen. Sie knnen anhand von Beispielen Fehlertaxonomien und deren Einsatz erlutern. Sie knnen das Prinzip der erfahrungsbasierten Testentwurfsverfahren und die Grnde fr ihren Einsatz verstehen und wann sie genutzt werden. Sie knnen Tests nach dem explorativen Testentwurfsverfahren spezifizieren, durchfhren und darber berichten. Sie knnen Fehlerzustnde gem den Zielen verschiedener Fehlerangriffe klassifizieren. Sie knnen ein System analysieren um festzulegen, welche analysieren, spezifikationsorientierten, spezifikationsorientierte fehlerbasierten oder erfahrungsbasierten Testverfahren fr bestimmte Ziele einzusetzen sind.
LO-4.4.2 (K2) LO-4.4.3 (K2) LO-4.4.4 (K3) LO-4.4.5 (K2) LO-4.4.6 (K4)
Kapitel 5: Test der Softwareeigenschaften [210 Minuten] 5.2 Qualittsmerkmale bei fachlichen Tests LO-5.2.1 (K4) Sie knnen anhand von Beispielen erlutern, welche der in Kapitel 4 erwhnten welche Testverfahren geeignet sind, um Richtigkeit, Angemessenheit, Interoperabilitt, funktionale Sicherheit und Zugnglichkeit eines Systems zu testen.
Version 2007
Seite 22 von 136
Januar 2010 20100131
LO-5.2.2 (K3)
Sie knnen Benutzbarkeitstests skizzieren, entwerfen, spezifizieren und durchfhren spezifizieren durchfhren. Sie knnen dabei die geeigneten Verfahren einsetzen und vorgegebene Testziele und zu findende Fehlerzustnde bercksichtigen.
5.3 Qualittsmerkmale beim technischen Testen LO-5.3.1 (K2) Sie knnen erklren, warum Effizienztests, Zuverlssigkeitstests und technische Sicherheitstests Teil einer Teststrategie sein sollten, und Beispiele fr Fehlerzustnde anfhren, die damit gefunden werden sollen. Sie knnen nicht-funktionale Testarten fr das technische Testen anhan typischer funktionale anhand Fehlerzustnde charakterisieren, die gezielt angegriffen werden (Fehlerangriffe) die typische Anwendung im Lebenszyklus einer Anwendung, und die fr das Testdesign geeigneten Testverfahren.
LO-5.3.2 (K2)
Kapitel 6: Review [180 Minuten] 6.5 Erfolgsfaktoren fr Reviews LO-6.5.1 (K3) LO-6.5.2 (K3) LO-6.5.3 (K2) Sie knnen eine Review Review-Checkliste verwenden, um Programmcode und Architektur erwenden, aus Sicht eines Testers zu verifizieren. Sie knnen eine Review Review-Checkliste verwenden, um Anforderungen und erwenden, Anwendungsflle aus Sicht d Testers zu verifizieren. des Sie knnen Review-Arten miteinander vergleichen und deren relative Strken, Schwchen und Einsatzbereiche aufzeigen.
Kapitel 7: Fehler- und Abweichungsmanagement [120 Minuten] 7.4 Pflichtfelder fr die Erfassung von Fehler und Abweichungen ng FehlerLO-7.4.1 (K4) Sie knnen funktionale und nicht funktionale Fehlerwirkungen analysieren, unktionale nicht-funktionale klassifizieren, in verstndlichen Abweichungsberichten und beschreiben.
Kapitel 8: Standards im Testverbesserungs Testverbesserungs-Prozess [0 Minuten] Kein Lernziel dieses Kapitel (auf keiner der kognitiven Ebenen) betrifft die Test Analysts. Kapitel 9: Testwerkzeuge und Automatisierung [90 Minuten] 9.2 Testwerkzeugkonzepte Sie knnen die Elemente und Aspekte in jedem der folgenden Testwerkzeugkonzepte folgenden vergleichen: Kosten, Nutzen und Risiken von Testwerkzeugen und Automatisierung Kosten, Automatisierung, Testwerkzeugstrategien Integration und Informationsaustausch, Testwerkzeugstrategien, Automatisierungssprachen, Testorakel, Testwerkzeuge in Betrieb nehmen Open Testwerkzeuge nehmen, Source-Werkzeuge, Werkzeuge, Eigene Testwerkzeuge entwickeln sowie Testwerkzeuge Testwerkzeuge klassifizieren. 9.3 Testwerkzeugkategorien LO-9.2.1 (K2)
Version 2007
Seite 23 von 136
Januar 2010 20100131
LO-9.3.1 (K2) LO-9.3.5 (K2)
Sie knnen die Testwerkzeugkategorien nach Zielsetzung, Verwendungszweck, estwerkzeugkategorien Strken und Risiken zusammenfassen sowie Beispiele nennen. zusammenfassen, Sie knnen die Werkzeuge der verschiedenen Werkzeugkategorien den unterschiedlichen Teststufen und Testarten zuordnen.
Kapitel 10: Soziale Kompetenz und Teamzusammensetzung [30 Minuten] 10.6 Kommunizieren LO-10.6.1 (K2) Sie knnen anhand von Beispielen eine professionelle, objektive und effektive nhand Kommunikation in einem Projekt aus Sicht des Testers beschreiben Stellen Sie dabei Risiken und Chancen dar.
Version 2007
Seite 24 von 136
Januar 2010 20100131
0.6 Lernziele fr Technical Test Analysts

Dieser Abschnitt enthlt die detaillierten Lernziele fr das Modul Technical Test Analyst. Fr alle Teile dieses Lehrplans gilt, dass sie auf der Wissensstufe K1 geprft werden knnen. Dies bedeutet, dass der oder die Lernende den entsprechenden Begriff oder das Konzept erkennt, sich daran erinnert und es wiedergeben kann. Die folgende Auflistung enthlt deshalb nur die Lernziele der Wissensstufen K2, K3 und K4. Einfhrung in den Lehrplan Technical Test Analyst [60 Minuten] (einschlielich Wiederholung des Lehrplans zum ISTQB Foundation Level) erholung Kapitel 1: Grundlegende Aspekte des Softwaretestens [30 Minuten] Kapitel 2: Der Testprozess [180 Minuten] 2.4 Testanalyse und Testentwurf LO-2.4.1 (K2) Sie knnen die Stufen im Softwarelebenszyklus einer Anwendung erklren, in denen sich nicht-funktionale Tests und architekturorientierte Tests einsetzen lassen. Sie funktionale knnen erklren, warum nicht funktionale Tests nur in bestimmten Stufen des nicht-funktionale Lebenszyklus stattfinden. Sie knnen anhand von Beispielen die Kriterien erlutern, die bei der Entwicklung von von Testbedingungen Struktur und Tiefe beeinflussen. Sie knnen beschreiben, inwiefern Testanalyse und Testentwurf statische Testtechniken sind, die zur Aufdeckung von Fehlern eingesetzt werden knnen. eingesetzt Sie knnen anhand von Beispielen das Konzept der Testorakel erlutern, und wie ein Testorakel in Testspezifikationen eingesetzt werden kann.
LO-2.4.2 (K2) LO-2.4.3 (K2) LO-2.4.4 (K2)
2.5 Testrealisierung und Testdurchfhrung LO-2.5.5 (K2) Sie knnen die Voraussetzungen fr die Testdurchfhrung beschreiben, einschlielich oraussetzungen Testmittel, Testumgebung, Konfigurationsmanagement und Abweichungsmanagement.
2.6 Testendekriterien auswerten, Bericht LO-2.6.2 (K3) Sie knnen mit vorgegebenen Metriken bewerten, ob ei bestimmtes ein Testendekriterium erfllt ist.
Kapitel 3: Testmanagement [120 Minuten] 3.9.2 Risikomanagement LO-3.9.2.5 (K2) Sie knnen die Aktivitten bei einem risikoorientierten Testansatz fr Planung und Durchfhrung von fachlichen Tests umreien.
Version 2007
Seite 25 von 136
Januar 2010 20100131
Kapitel 4: Testverfahren [930 Minuten] 4.2 Spezifikationsoriente Verfahren LO-4.2.1 (K2) LO-4.2.2 (K3) Sie knnen Beispiele fr typische Fehlerzustnde anfhren, die sich mit den jeweiligen spezifikationsorientierten Testverfahren identifizieren lassen. Sie knnen Testflle aus vorgegebenen Softwaremodellen erstellen und dabei folgende Testentwurfsverfahren anwenden, wobei die Tests eine gegebene Modellberdeckung erzielen sollen: quivalenzklassenbildung Grenzwertanalyse Entscheidungstabellentes Entscheidungstabellentest Zustandsbasierter Test Sie knnen ein System oder dessen Anforderungsspezifikation analysieren und festlegen, welche spezifikationsorienten Testverfahren fr bestimmte Zielsetzungen anzuwenden sind, und Sie knnen eine Testspezifikation nach IEEE Standard 829, nach mit dem Schwerpunkt auf Testfllen fr Komponententests und nicht-funktionale funktionale Tests und Testverfahren skizzieren skizzieren.
LO-4.2.3 (K4)
4.3 Strukturorientierte Testverfahren LO-4.3.1 (K2) LO-4.3.2 (K3) Sie knnen Beispiele fr typische Fehler anfhren, die sich mit den jeweiligen strukturorientierten Testverfahren identifizieren lassen. Sie knnen mit den folgenden Testentwurfsverfahren echte Testflle entwerfen, wobei die Tests eine vorgegebene Modellberdeckung erzielen sollen: Anweisungs Anweisungsberdeckungstest Entscheidungsberdeckungstest Definierter Bedingungs Bedingungsberdeckungstest Mehrfachbedingungsberdeckungstest Sie knnen ein System analysieren, um festzulegen, welches strukturorientierte Testverfahren fr bestimmte Zielsetzungen anzuwenden ist. Sie knnen jedes der strukturorientierten Testentwurfsverfahren und die zugehrigen berdeckungsgrade verstehen sowie, wann welches Verfahren verwendet wird. Sie knnen vergleichen und analysieren, welches strukturorienti strukturorientierte Testentwurfsverfahren in unterschiedlichen Situationen einzusetzen ist.
LO-4.3.3 (K4) LO-4.3.4 (K2) LO-4.3.5 (K4)
4.4 Fehlerbasierte und erfahrungsbasierte Testverfahren LO-4.4.1 (K2) Sie knnen Prinzip und Grnde fr das fehlerbasierte Testentwurfsverfahren beschreiben und gegen den Einsatz spezifikationsorientierter und strukturorientierter Einsatz Testverfahren abgrenzen abgrenzen. Sie knnen anhand von Beispielen Fehlertaxonomien und deren Einsatz erlutern. Sie knnen Prinzip und Grnde fr den Einsatz erfahrungsbasiert erfahrungsbasierter Testentwurfsverfahren verstehen und wann sie genutzt werden. Sie knnen Tests unter Nutzung explorativen Testens spezifizieren, durchfhren und darber berichten. Sie knnen Tests nach den Zielen verschiedener Fehlerangriff spezifizieren Fehlerangriffe spezifizieren.
LO-4.4.2 (K2) LO-4.4.3 (K2) LO-4.4.4 (K3) LO-4.4.6 (K2)
Version 2007
Seite 26 von 136
Januar 2010 20100131
LO-4.4.7 (K4)
Sie knnen ein System analysieren um festzulegen, welche analysieren, spezifikationsorientierten, spezifikationsorientierte fehlerbasierten oder erfahrungsbasierten Testverfahren fr bestimmte Ziele anzuwenden sind.
4.5 Statische Analyse LO-4.5.1 (K3) Sie knnen die Algorithmen Kontrollflussanalyse und Datenflussanalyse nnen anwenden, um zu verifizieren, dass der Programmcode keine Kontroll oder KontrollDatenflussanomalie hat. Sie knnen die Ergebnisse der Kontrollfluss und Datenflussanalyse interpret Kontrollflussinterpretieren, die ein Werkzeug liefert, und bewerten, ob eine Kontroll oder Datenflussanomalie Kontrollvorliegt. Sie knnen den Einsatz von Aufrufgraphen zur Bewertung der Architekturqualitt erklren. Dazu gehren die zu identifizierenden Fehlerzustnde, die Anwendung fr Testentwurf und Testplanung und die mglicherweise eingeschrnkte Gltigkeit der Ergebnisse.
LO-4.5.2 (K4)
LO-4.5.3 (K2)
4.6 Dynamische Analyse LO-4.6.1 (K2) Sie knnen erklren, wie eine dynamische Analyse des Programmcodes durchgefhrt wird, und zusammenfassen, welche Fehlerzustnde mit diesem Verfahren aufgedeckt zusammenfassen, werden knnen und wo die Grenzen dieses Verfahrens liegen.
Kapitel 5: Test der Softwareeigenschaften [240 Minuten] 5.3 Qualittsmerkmale beim technischen Testen LO-5.3.2 (K2) Sie knnen nicht-funktionale Testarten fr das technische Testen anhand typischer nktionale Fehlerzustnde charakterisieren, die gezielt angegriffen werden (Fehlerangriffe), die typische Anwendung im Lebenszyklus einer Anwendung, und die fr das Testdesign geeigneten Testverfahren. Sie knnen verstehen und erklren, in welchen Lebenszyklusphasen einer Software oder eines Systems Sicherheits Zuverlssigkeits- und Effizienztests angewendet Sicherheits-, werden (einschlielich der entsprechenden Teilmerkmale nach ISO 9126) Sie knnen die Arten von Fehlern unterscheiden, die durch Sicherheits-, SicherheitsZuverlssigkeits- und Effizienztests aufgedeckt werden (einschlielich der entsprechenden Teilmerkmale nach ISO 9126) Sie knnen Testanstze fr das Testen auf Sicher Sicherheits-, Zuverlssigkeits und , ZuverlssigkeitsEffizienzmerkmale und deren entsprechende Teilmerkmale nach ISO 9126 charakterisieren. Sie knnen Testflle fr das Testen auf Sicherheits Zuverlssigkeits- und Sicherheits-, Effizienzmerkmale und deren entsprechende Teilme Teilmerkmale nach ISO 9126 spezifizieren. Sie knnen verstehen und erlutern, warum Wartbarkeit, Portabilitt und Zugnglichkeitstest Teil einer Teststrategie sein sollten. Sie knnen Testflle fr nicht nicht-funktionale Tests auf nderbarkeit und Portabilitt arkeit spezifizieren.
LO-5.3.3 (K2)
LO-5.3.4 (K2)
LO-5.3.5 (K2)
LO-5.3.6 (K3)
LO-5.3.7 (K2) LO-5.3.8 (K3)
Kapitel 6: Review [180 Minuten] 6.4 Einfhrung von Reviews Version 2007 Seite 27 von 136 Januar 2010 20100131
LO-6.4.1 (K2)
Sie knnen Review-Arten miteinander vergleichen und deren relative Strken, -Arten Schwchen und Einsatzbereiche aufzeigen.
6.5 Erfolgsfaktoren fr Reviews LO-6.5.3 (K4) Sie knnen eine Review Checkliste skizzieren, um typische Fehlerzustnde Review-Checkliste aufzudecken, die bei Reviews von Code und Architektur gefunden werden.
Kapitel 7: Fehler- und Abweichungsmanagement [120 Minuten] 7.4 Pflichtfelder fr die Erfassung von Fehler und Abweichungsmeldungen FehlerLO-7.4.2 (K4) Sie knnen nicht-funktionale Abweichungen in verstndlichen Abweichungsberichten funktionale analysieren, klassifizieren und beschreiben.
Kapitel 8: Standards und Testverbesserungs Testverbesserungs-Prozess [0 Minuten] Kein Lernziel dieses Kapitel (auf keiner der kognitiven Ebenen) betrifft die Technical Test Analysts. Kapitel 9: Testwerkzeuge und Automatisierung [210 Minuten] 9.2 Testwerkzeugkonzepte LO-9.2.1 (K2) Sie knnen die Elemente und Aspekte in jedem der folgenden Testwerkzeugkonzepte der vergleichen: Kosten, Nutzen und Risiken von Testwerkzeugen und Automatisierung Kosten, Automatisierung, Testwerkzeugstrategien Integration und Informationsaustausch, Testwerkzeugstrategien, Automatisierungssprachen, Testorakel, Testwerkzeuge in Betrieb nehmen Open Testwerkzeuge nehmen, Source-Werkzeuge, Werkzeuge, Eigene Testwerkzeuge entwickeln sowie Testwerkzeuge Testwerkzeuge klassifizieren.
9.3 Testwerkzeugkategorien LO-9.3.1 (K2) LO-9.3.5 (K2) estwerkzeugkategorien Sie knnen die Testwerkzeugkategorien nach Zielsetzung, Verwendungszweck, Strken, Risiken und mit Beispielen zusammenfassen. Sie knnen die Werkzeuge der verschiedenen Werkzeugkategorien den unterschiedlichen Teststufen und Testarten zuordnen.
9.3.7 Schlsselwortgetriebene Testautomatisierung Schlsselwort-/Aktionswort-Tabellen mit Hilfe des Schlsselwort bellen SchlsselwortLO-9.3.7.1 (K3) Sie knnen Schlsselwort Algorithmus erstellen, den ein Testausfhrungs Werkzeug verwenden wird. Testausfhrungs-Werkzeug 9.3.8 Performanztestwerkzeuge LO-9.3.8.1 (K3) Sie knnen Performanztests entwerfen und planen, um Systemmerkmale messen zu K3) knnen. Kapitel 10: Soziale Kompetenz und Teamzusammensetzung [30 Minuten] ale 10.6 Kommunizieren
Version 2007
Seite 28 von 136
Januar 2010 20100131
LO-10.6.1 (K2) Sie knnen anhand von Beispielen eine professionelle, objektive und effektive nhand Kommunikation in einem Projekt aus Sicht des Testers beschreiben. Stellen Sie dabei beschreiben. Risiken und Chancen dar. iken
Version 2007
Seite 29 von 136
Januar 2010 20100131
1. Grundlegende Aspekte des Softwaretestens

Begriffe:
ethische Leitlinien, Softwarelebenszyklus. Messung, Metrik, Multisysteme, sicherheitskritische Systeme,
1.1 Einfhrung
Dieses Kapitel enthlt zentrale Testthemen, die von allgemeiner Relevanz fr alle Mitarbeiter im Bereich Testen sind, d.h. fr Testmanager, Test Analysts und Technical Test Analysts. Die Ausbildungsanbieter werden diese allgemeinen Themen im Kontext des jeweiligen Moduls behandeln und durch relevante Beispiele ergnzen. Im Modul Technical Test Analyst gibt es beispielsweise zum allgemeinen Thema Metriken und Messung (Abschnitt 1.4) Beispiele fr technische Metriken, w ) wie Performanzmessungen. Abschnitt 1.2 betrachtet den Testprozess als Teil des gesamten Softwarelebenszyklus. Das Thema baut auf den grundlegenden Konzepten auf, wie sie im Foundation-Level-Lehrplan eingefhrt wurden. Es legt besonderen Wert auf das Angleichen des Testprozesses an den Softwarelebenszyklus und sonderen andere IT-Prozesse. Systeme knnen verschiedene Ausprgungen annehmen, die die Vorgehensweise beim Testen erheblich beeinflussen knnen. Abschnitt 1.3 stellt zwei spezifische Systemtypen vor, die allen Testern bekannt sein mssen: Multisysteme und sicherheitskritische Systeme. Fortgeschrittene Tester sind mit einigen schwierigen Aufgaben konfrontiert, wenn sie die in diesem Lehrplan beschriebenen unterschiedlichen Testaspekte in ihren Organisationen, Teams und Aufgabenbereichen einfhren.
1.2 Testen im Softwarelebenszyklus

Testen ist integraler Bestandteil verschiedener Software Software-Entwicklungsmodelle: sequenziell (Wasserfallmodell V-Modell und W-Modell) Wasserfallmodell, iterativ (Rapid Application Development (RAD) und Spiralmodell) inkrementell (evolutionre und agile Methoden Methoden) Das langfristige Einbinden des Testens in den Softwarelebenszyklus sollte als Teil der Teststrategie betrachtet und beschrieben werden. Dazu gehren Organisation, Prozessbeschreibungen sowie rieben Auswahl von Werkzeugen und Methoden. Testprozesse werden nicht isoliert ausgefhrt, sondern stehen in Zusammenhang mit anderen Prozessen und beziehen sich auf diese, wie: Anforderungsanalyse und -management management Projektmanagement Konfigurations- und nderungsmanagement Softwareentwicklung Softwarewartung technischer Support Erstellen technischer Dokumentation Seite 30 von 136 Januar 2010 20100131
Version 2007
In sequenziellen Softwareentwicklungs Modellen steht die frhzeitige Testplanung in e Softwareentwicklungs-Modellen einem engen Zusammenhang mit der spteren Testdurchfhrung. Die Testaktivitten knnen sich zeitlich berlappen und/oder gleichzeitig stattfinden. nderungs- und Konfigurationsmanagement sind wichtige untersttzende Aufgaben beim Softwaretesten. Ohne geeignetes nderungsmanagement lassen sich die Auswirkungen von netes nderungen auf das System nicht beurteilen. Ohne Konfigurationsmanagement besteht die Gefahr, dass parallele Entwicklungen verloren gehen oder schlecht verwaltet werden. Abhngig vom Projektkontext knnen zustzlich zu den im Lehrplan definierten Teststufen noch t weitere definiert werden, beispielsweise: Hardware-Software Integrationstest Software Systemintegrationstest Interaktionstest der Funktionen t Produktintegrationstest beim Kunden ntegrationstest Jede Teststufe lsst sich wie folgt kennzeichnen: Testziele Testumfang Rckverfolgbarkeit zur Testbasis Eingangsbedingungen und Testendekriterien nd Test-Arbeitsergebnisse und Berichterstattung Arbeitsergebnisse Testverfahren Mae und Metriken Testwerkzeuge Einhaltung von organisationsinternen oder anderen Standards Je nach Kontext lassen sich Ziele und Umfang der Teststufen isoliert oder auf Proje Projektebene betrachten (beispielsweise, um unntiges Wiederholen hnlicher Tests in unterschiedlichen Teststufen zu vermeiden). Testaktivitten mssen an das ausgewhlte Softwarelebenszyklusmodell angepasst werden, das sequenziell sein kann (beispielsweise Was Wasserfall, V-Modell, W-Modell), iterativ (beispielsweise Rapid Modell), Application Development (RAD), Spiralmodell) oder inkrementell (beispielsweise evolutionre und , agile Methoden) . Im V-Model lsst sich beispielsweise der fundamentale Testprozess des ISTQB auf der Stufe Model Systemtest folgendermaen anpassen: Der Systemtest wird gleichzeitig mit dem Projekt geplant, und die Teststeuerung und -berwachung dauert an, bis die Testdurchfhrung und der Abschluss der Testaktivitten berwachung erfolgt sind. Systemtestanalyse und -entwurf finden parallel zum Erstellen von Anforderungsspezifikation, entwurf System- und (abstraktem) Architekturentwurf statt, und auf einer niedrigeren Ebene Architekturentwurf gleichzeitig mit dem Komponentenentwurf. Die Bereitstellung der Testumgebung (beispielsweise Testrahmen) kann whrend des funktionalen Systementwurfs beginnen, obwohl der grte Aufwand normalerweise gleichzeitig mit der Implementierung und dem Komponententest anfllt. Die Arbeit an der eitig Testrealisierung dauert dagegen oft bis wenige Tage vor Beginn der Testdurchfhrung. Die Testdurchfhrung beginnt, wenn alle Eingangsbedingungen fr den Systemtest erfllt sin sind (oder auf sie verzichtet wird), was normalerweise bedeutet, dass mindestens der Komponententest und oft auch der Integrationstest abgeschlossen sind. Die Testdurchfhrung dauert, bis die Testendekriterien erfllt sind. Seite 31 von 136 Januar 2010 20100131
Version 2007
Whrend der gesamten Testdurchfhrung werden die Testendekriterien bewertet und die Testdurchfhrung Testergebnisse berichtet, normalerweise mit grerer Hufigkeit und Dringlichkeit, je nher der Projektendtermin rckt. Die Testabschlussaktivitten folgen, wenn die Testendekriterien erfllt sind und die Testdurchfhrung als abgeschlossen erklrt wird. Sie knnen aber manchmal verschoben estdurchfhrung werden, bis auch der Abnahmetest abgeschlossen ist und alle Projektaktivitten beendet sind. Fr jede Teststufe und fr jede ausgewhlte Kombination von Softwarelebenszyklus und Testprozess Softwarelebenszyklus muss der Testmanager diese Anpassung whrend der Testplanung und/oder Projektplanung vornehmen. Bei besonders komplexen Projekten, beispielsweise Multisystem Projekten (verbreitet Multisystem-Projekten beim Militr und in Grofirmen), mssen die Testprozesse nicht nur angepasst, sondern auch je nach nicht dem Kontext des Projekts modifiziert werden (beispielsweise wenn es einfacher ist, einen Fehlerzustand auf einer hheren Teststufe aufzudecken als auf einer niedrigeren).
1.3 Spezifische Systeme

1.3.1 Multisysteme
Ein Multisystem (System von Systemen) ist ein System zusammenarbeitender Komponenten (mit Hardware, individuellen Softwareapplikationen und Kommunikation), die miteinander eine einen gemeinsamen Zweck erfllen; es gibt keine eindeutige Managementstruktur fr Multisysteme. Zu Merkmalen und Risiken eines Multisystems gehren: Das schrittweise Zusammenfgen unabhngiger Einzelsysteme, damit nicht ein ganzes System vllig neu erstellt werden muss. Dazu lassen sich beispielsweise COTS Systeme mit werden geringem zustzlichem Entwicklungsaufwand integrieren. Technische und organisatorische Komplexitt (beispielsweise zwischen verschiedenen Betroffenen) stellen ein Risiko fr effektives Management dar. Wenn die Teilsysteme nach unterschiedlichen Entwicklungsmodellen erstellt werden, knnen Kommunikationsprobleme zwischen den verschiedenen Teams entstehen (Entwicklung, Testen, Herstellung, Produktionslinie, Nutzer usw.). Das bergeordnete Management eines Multisystems muss mit der hohen technischen Komplexitt umgehen knnen, die mit der Integration der verschiedenen Teilsysteme verbunden ist. Es muss verschiedene organisatorische Themen wie Outsourcing und Off-Shoring bewltigen knnen. Shoring Vertraulichkeit und Schutz von spezifischem Know how, Schnittstellen zwischen it Know-how, verschiedenen Organisationen (beispielsweise im staatlichen und privaten Bereich) oder Regulierungen (beispielsweise ein Monopolverbot) knnen dazu fhren, dass ein komplexes System als ein Multisystem betrachtet werden muss. ultisystem Multisysteme sind in der Regel weniger zuverlssig als Individualsysteme, weil sich jede Beschrnkung eines (Teil-)Systems automatisch auf das gesamte Multisystem auswirkt. )Systems Die einzelnen Komponenten eines Multisystems mssen ein hohes Niveau an technischer mssen und funktioneller Interoperabilitt liefern, dadurch wird der Integrationstest kritisch und wichtig und erfordert przise spezifizierte und vereinbarte Schnittstellen.
1.3.1.1 Management und Testen von Multisystemen Die hhere Komplexitt von Projektmanagement und Konfigurationsmanagement ist Multisystemen gemeinsam. Zu komplexen Systemen und Multisystemen gehren meist eine strkere Einflussnahme der Qualittssicherung und definierte Prozesse. Oft sind mit Multisystemen formelle Entwicklungs EntwicklungsLebenszyklen, Meilensteine und Reviews verbunden.
Version 2007
Seite 32 von 136
Januar 2010 20100131
1.3.1.2 Merkmale des Lebenszyklus von Multisystemen Zu jeder Teststufe eines Multisystems gehren neben den in Abschnitt 1.2 Testen im Softwarelebenszyklus beschriebenen Merkmalen noch die folgenden: lebenszyklus mehrstufiges Integrations- und Versionsmanagement, lange Projektdauer, formale Weitergabe von Informationen zwischen den Pro Projektmitgliedern, nicht-gleichzeitige Entwicklung der Komponenten und die Notwendigkeit, Regressionstests gleichzeitige auf Multisystem-Ebene durchzufhren, Ebene Wartungstests, weil Einzelkomponenten wegen Veralterung oder Erweiterung ersetzt werden. Teststufen mssen bei Multisystemen sowohl mit ihrem eigenen Detaillierungsgrad als auch auf einer tisystemen hheren Integrationsstufe bercksichtigt werden. So lsst sich der Systemtest fr ein Subsystem als Komponententest fr die bergeordnete Komponente betrachten. Normalerweise wird jede Einzelkomponente eines Multisystems auf jeder Teststufe getestet, bevor sie de in das Multisystem integriert wird, wobei weitere Tests erforderlich sind. Spezielle Managementaspekte von Multisystemen enthlt Abschnitt 3.11.2.
1.3.2 Sicherheitskritische Systeme rheitskritische

Sicherheitskritische Systeme sind Systeme, bei denen Betriebsausflle oder Funktionsbeeintrchtigungen (beispielsweise als Folge von unsachgemer oder unachtsamer unsachgemer Bedienung) katastrophale oder kritische Konsequenzen haben. Der Lieferant eines sicherheitskritischen Systems kann fr den Schaden oder Schadensersatz haftbar gemacht werden; daher werden Testaktivitten eingesetzt, um die Haftung zu reduzieren. Die Testaktivitten liefern den Beweis dafr, dass das System adquat getestet worden ist, um katastrophale oder kritische Folgen mglichst zu vermeiden. Beispiele fr sicherheitskritische Systeme sind Flugzeug Steuerungssysteme, automatisc Flugzeug-Steuerungssysteme, automatische Handelssysteme, Systeme zur berwachung von Atomkraftwerken, medizinische Systeme usw. Folgende Aspekte sollten fr sicherheitskritische Systeme umgesetzt werden: Rckverfolgbarkeit zu regulatorischen Anforderungen und Methoden zur Konformitt (dem Nachweis, dass die Auflagen erfllt sind), hweis, striktes Vorgehen bei Entwicklung und Test, Sicherheitsanalyse, redundante Architektur und ihre Qualifizierung, Schwerpunkt auf Qualitt, hohes Niveau der Dokumentation (Tiefe und Umfang der Dokumentation), hohe Auditierbarkeit. Spezielle Testmanagementaspekte im Zusammenhang mit sicherheitskritischen Systemen enthlt Abschnitt 3.11.3. 1.3.2.1 Konformitt/Einhalten der Vorschriften /Einhalten Sicherheitskritische Systeme sind oft Gegenstand staatlicher, internationaler oder branchenspezifischer Auflagen oder Standards (siehe Abschnitt 8.2). Sie knnen sich auf . Entwicklungsprozess und Organisationsstruktur beziehen oder auf das zu erstellende Produk Produkt. Um die Konformitt der Organisationsstruktur und des Entwicklungsprozesses nachzuweisen, knnen Organisationsdiagramme und Audits ausreichen. Um die Konformitt mit den spezifischen Regulierungen fr das zu erstellende System (Produkt) nachzuweisen, muss gezeigt werden, dass jede Anforderung aus diesen Regulierungen adquat s Version 2007 Seite 33 von 136 Januar 2010 20100131
erfllt ist. Der Weg von der Anforderung zu ihrer Umsetzung muss sich vollstndig verfolgen lassen, um die Konformitt zu beweisen. Das beeinflusst whrend des gesamten Entwicklungspr Entwicklungsprozesses Management, Entwicklungslebenszyklus, Testaktivitten und Qualifizierung oder Zertifizierung (durch eine dafr zugelassene Stelle). 1.3.2.2 Sicherheitskritische Systeme und Komplexitt Viele komplexe Systeme und Multisysteme haben sicherheitskritische Komponenten. Der Sicherheitsaspekt ist nicht immer auf System oder Teilsystemebene ersichtlich, sondern auf der Systemhheren Ebene, auf der komplexe Systeme implementiert werden (beispielsweise Avioniksysteme fr implementiert Luftfahrzeuge oder Flugsicherungs-Systeme). Ein Router beispielsweise ist an sich kein sicherheitskritisches System, aber er kann dazu werden, kein wenn lebenswichtige Daten bertragen werden, wie im Fall von Telemed Telemedizin. Risikomanagement, das die Eintrittswahrscheinlichkeit und/oder die Auswirkungen von Risiken reduziert, ist unverzichtbar fr sicherheitskritische Entwicklungen und den Testkontext (siehe Kapitel 3 Testmanagement). Hufig werden auerdem FMEA (siehe Abschnitt 3.10) und Software Common ). ) Cause Failure Analysis (Analyse der gemeinsamen Ursachen von Ausfllen) in diesem Analyse Zusammenhang eingesetzt.
1.4 Metriken und Messung

Eine Vielzahl von Metriken und Messungen sollte whrend des Softwarelebenszyklus Anwendung finden (beispielsweise Planung, berdeckung Arbeitsbelastung usw.). In jedem Fall muss eine berdeckung, Referenzkonfiguration (engl. Baseline) festgelegt und dann der Fortschritt in Bezug auf diese Referenzkonfiguration verfolgt werden. Erfassbare Gren sind 1. Zeitplan, berdeckungsgrad und ihre zeitliche Entwicklung 2. Anforderungen, ihre Entwicklung und ihre Auswirkungen auf Zeitplan, Ressourcen und , Aufgaben 3. Arbeitspensum und Nutzung der Ressourcen sowie ihre zeitliche Entwicklung 4. Meilensteine und ihr Umfang sowie deren zeitliche Entwicklung 5. Tatschliche und bis zur Erfllung der A Aufgaben geplante Kosten 6. Risiken und Manahmen zur Risikominderung sowie deren zeitliche Entwicklung 7. Gefundene Fehlerwirkungen, behobene Fehlerwirkungen und Korrekturdauer Mit Metriken knnen Tester ihrem Management in gleichbleibender Art und Weise bericht berichten, und der Fortschritt im zeitlichen Verlauf lsst sich kohrent verfolgen. Drei Bereiche sind zu bercksichtigen: Metriken definieren: Eine begrenzte Menge von sinnvollen Metriken sollte definiert werden. Sind sie definiert, mssen sich alle Betroffenen auf ihre Interpretation einigen, um zuknftige Diskussionen zu vermeiden, wenn die Metrikwerte vorliegen. Metriken knnen passend zu den Zielen eines Prozesses oder einer Aufgabe festgelegt werden, fr Komponenten oder Systeme, fr Einzelpersonen oder Teams. Oft werden tendenziell zu viele Metriken definiert, Teams. anstatt die aussagekrftigsten festzulegen. Metriken verfolgen: Berichte ber und Zusammenstellungen von Metriken sollten mglichst weit automatisiert werden, um den zeitlichen Aufwand fr die Generierung der Metrikwerte Generierung niedrig zu halten. Abweichungen bei den Daten im zeitlichen Ablauf knnten auch andere Informationen widerspiegeln als die, ber deren Interpretation in der Definitionsphase Einigkeit erzielt wurde. Seite 34 von 136 Januar 2010 20100131
Version 2007
Metriken berichten: Ziel ist es, die Information fr das Management unmittelbar verstndlich darzustellen. Prsentationen knnen eine Momentaufnahme der Metrik zu einem bestimmten Zeitpunkt wiedergeben oder die zeitliche Entwicklung der Metrik(en), sodass sich Tendenzen einschtzen lassen.
1.5 Ethische Leitlinien

Durch ihre Ttigkeit im Bereich Softwaretesten erhalten Personen oft Zugang zu vertraulichen und rechtlich privilegierten Informationen. Damit diese Informationen nicht missbruchlich verwendet n werden, sind ethische Leitlinien ntig. In Anlehnung an den Ethik Kodex von ACM und IEEE stellt das Ethik-Kodex ISTQB die folgenden ethischen Leitlinien auf. ffentlichkeit fizierter Das Verhalten zertifizierter Softwaretester soll dem ffentlichen Interesse nicht widersprechen. Kunde und Arbeitgeber Das Verhalten zertifizierter Softwaretester soll den Interessen ihrer Kunden und Arbeitgeber entsprechen und dabei dem ffentlichen Interesse nicht widersp widersprechen. Produkt Zertifizierte Softwaretester sollen sicherstellen, dass die Arbeitsergebnisse, die sie liefern (fr die von ihnen getesteten Produkte und Systeme), hchste fachliche Anforderungen erfllen. Urteilsvermgen Zertifizierte Softwaretester sol sollen bei ihrer professionellen Beurteilung aufrichtig und unabhngig sein. Management Zertifizierte Software-Testmanager und Testleiter sollen eine ethische Haltung beim Testmanager Management des Softwaretest Softwaretestens haben und frdern. Berufsbild Zertifizierte Softwaretester sollen Integritt und Ansehen ihrer Profession frdern und ster dabei dem ffentlichen Interesse nicht widersprechen. Kollegen Zertifizierte Softwaretester sollen sich ihren Kolleginnen und Kollegen gegenber fair und hilfsbereit verhalten und die Koopera Kooperation mit Softwareentwicklern frdern. Persnlich Zertifizierte Softwaretester sollen sich ihr Leben lang fort und weiterbilden und eine fortethische Haltung in ihrer Berufsausbung vertreten.
Version 2007
Seite 35 von 136
Januar 2010 20100131
2. Testprozesse
Begriffe:
Abschluss der Testaktivitten, BS 7925/2 , 7925/2, IEEE 829, Testbedingungen, Testbericht , Testbericht, Testdurchfhrung, , Testendekriterien, Testendekriterien Testentwurf, Testfall, Testplanung, , Testprotokoll, Testprotokoll Testrealisierung, Testskript, Teststeuerung Testszenario, Testvorgehen. , Teststeuerung,
2.1 Einfhrung
Im ISTQB Foundation-Level-Lehrplan sind folgende Aktivitten eines grundlegenden Testprozesses Lehrplan beschrieben: Testplanung und -steuerung steuerung Testanalyse und Testentwurf Testrealisierung und Testdurchfhrung Testauswertung und Bericht Abschluss der Testaktivitten Diese Aktivitten knnen sequenziell oder teilweise auch parallel ablaufen. So knnen sich beispielsweise Testanalyse und Testentwurf mit Testrealisierung und Testdurchfhrung zeitlich berlappen, whrend die anderen Aktivitten sequenziell durchgefhrt werden. Da das Testmanagement in einem grundlegenden Zusammenhang mit dem Testprozess steht, mssen Testmanager in der Lage sein, den gesamten Inhalt dieses Kapitels im konkreten Kapitels Testmanagement eines spezifischen Projekts umzusetzen. Das im ISTQB Foundation Level erworbene Wissen dagegen ist weitgehend ausreichend fr Testanalysts und Technische Testanalysts, mit Ausnahme der oben angefhrten Aufgaben in der Testentwicklung. Das dafr ntige Testentwicklung. Wissen wird in diesem Kapitel allgemein abgehandelt und in den Kapiteln 4 Testverfahren und 5 Test der Softwareeigenschaften vertieft.
2.2 Testprozessmodelle
Prozessmodelle sind Annherungen und Abstraktionen. Sie knnen nicht den gesamten Testprozess in all seiner Komplexitt abdecken, mit all den Nuancen und Aktivitten, die in realen Projekten oder Vorhaben vorkommen. Ein Testprozessmodell sollte nicht als starres Korsett aufgefasst werden werden, sondern als Leitfaden, mit dessen Hilfe Testprozesse sich besser verstehen und organisieren lassen lassen. Dieser Lehrplan verwendet den im ISTQB Foundation-Level-Lehrplan beschriebenen Testprozess als Beispiel (siehe oben), es gibt aber auch andere wichtige Testprozessmodelle. Drei Beispiele folgen. Bei den drei Modellen handelt es sich um Testprozessmodelle und Modelle zur Verbesserung des Testprozesses. Alle drei Modelle (Practical Software Testing enthlt das Test Maturity Model) sind elle im Hinblick auf die Reifestufen definiert, die sie untersttzen. Weitere Informationen zu den drei Testprozessmodellen und TPI enthlt Abschnitt 8.3 Testverbesserungs-Prozess. Practical Software Testing Test Maturity Model [Burnstein03] Critical Testing Processes [Black03] Systematic Test and Evaluation Process (STEP)
Version 2007
Seite 36 von 136
Januar 2010 20100131
2.3 Testplanung und -steuerung steuerung

Dieses Kapitel behandelt die Prozesse bei der Testplanung und -steuerung. Die Testplanung erfolgt grtenteils in der Anfangsphase des Testens; dazu gehrt es, alle Testaktivitten und Ressourcen zu identifizieren und festzulegen, die zur Erfllung d der in der Teststrategie festgelegten Aufgaben und Testziele notwendig sind. Das risikoorientierte Testen (siehe Kapitel 3 Testmanagement) liefert fr den Testplanungs ) Testplanungs-Prozess Informationen ber geeignete Manahmen zur Reduzierung der identifizierten Risiken. Wird te beispielsweise bei einem bestimmten Projekt festgestellt, dass die schwerwiegendsten Fehler normalerweise in der Designspezifikation zu finden sind, dann knnte der Testplanungs Testplanungs-Prozess zustzliche statische Tests (Reviews) der Designspezifikation festlegen, bevor sie in Code umgesetzt iche wird. Risikoorientiertes Testen liefert dem Testplanungs Prozess auerdem Informationen ber die Testplanungs-Prozess jeweiligen Prioritten der verschiedenen Testaktivitten. Zwischen Testbasis, Testbedingungen, Testfllen und Testvorgehen kann ein komplexes n Beziehungsgeflecht bestehen, das zu vielen wechselseitigen Beziehungen zwischen diesen Arbeitsergebnissen fhrt. Tester mssen diese Wechselbeziehungen verstehen, um eine effektiv effektive Testplanung und Teststeuerung durchfhren zu knnen. Die Teststeuerung ist eine fortlaufende Aktivitt, bei der der tatschliche Testfortschritt mit dem Plan verglichen und der aktuelle Status berichtet werden, einschlielich mglicher Abweichungen vom , Plan. Sie steuert den Testprozess, damit Aufgabenumfang, Teststrategie und Testziele erfllt werden lan. werden; auch die Anpassung der Testplanungs Testplanungs-Dokumente nach Bedarf gehrt dazu. Die Teststeuerung muss auf die Informationen durch das Testen und auf vernderte Randbedingungen eines Projekts oder Vorhabens adquat reagieren. So mssen Risikoanalyse und dbedingungen Zeitplan revidiert werden, wenn beispielsweise beim dynamischen Testen gehufte Fehler in Bereichen entdeckt werden, wo man sie fr unwahrscheinlich gehalten hatte, o oder wenn die verfgbare Zeit fr die Tests wegen einer Verzgerung beim Testbeginn gekrzt wurde. Das kann dazu fhren, dass Tests neu priorisiert und verbleibende Ressourcen neu verteilt werden mssen. Weitere Informationen zum Inhalt der Testplanungs Testplanungs-Dokumente enthlt Kapitel 3 Testmanagement Testmanagement. Mgliche Metriken zur berwachung der Testplanung und steuerung sind Risiko- und Testberdeckung Fehlerfindung und -information information Verhltnis geplanter zu tatschlich aufgewendeten Stunden fr die Entwicklung der Testmittel aufgewendeten und die Durchfhrung der Testflle
2.4 Testanalyse und Testentwurf

Whrend der Testplanung werden auch die Testziele identifiziert. Sie dienen in der Testanalyse und TestanalyseTestentwurfsphase dazu: Testbedingungen zu identifizieren, Testflle zu entwerfen, mit denen die identifizierte Testbedingungen behandelt werden. identifizierten Die bei der Risikoanalyse und Testplanung festgelegten Priorisierungskriterien sollten whrend des gesamten Testprozesses angewendet werden, von Testanalyse und -entwurf bis hin zu entwurf Testrealisierung und -durchfhrung. durchfhrung.
Version 2007
Seite 37 von 136
Januar 2010 20100131
2.4.1 Testbedingungen identifizieren

Testbedingungen werden identifiziert durch die Analyse von Testbasis und Testzielen. Sie legen fest, Testzielen. was durch die Anwendung von in der Teststrategie und/oder im Testkonzept identifizierter Testverfahren zu testen ist. Auf der Basis von funktionalen und nicht funktionalen Merkmalen der Testobjekte lsst sich nicht-funktionalen entscheiden, wie Granularitt und Strukturierung der Testbedingungen festzulegen sind. Folgende laritt Aspekte sind relevant: 1. Granularitt der Testbasis: Allgemeine Anforderungen knnen zunchst zu abstrakten Testkriterien fhren, wie Nachweisen, dass Bildschirm X funktioniert. Daraus lsst sich dann Daraus ein konkretes Testkriterium ableiten, beispielsweise Nachweisen, dass Bildschirm X eine Kontonummer zurckweist, die ein Zeichen zu wenig hat. 2. Behandelte Produktrisiken: Fr ein als hoch eingestuftes Risiko knnten beispielsweise sehr detaillierte Testbedingungen als Ziel festgelegt werden. 3. Anforderungen fr die Berichterstattung an das Management und die Rckverfolgbarkeit der Informationen. 4. Entscheidung, dass nur mit Testbedingungen gearbeitet wird und keine Testflle daraus entwickelt werden (z.B. um mit Testbedingungen den Fo us fr explorative Tests festzulegen) t Fokus
2.4.2 Testflle entwerfen

Testflle werden in einer schrittweisen Ausarbeitung und Verfeinerung der identifizierten Testbedingungen entworfen. Dabei nutzen die Tester Testverfahren (siehe Kapitel 4), die in der Testverfahren Teststrategie festgelegt wurden. Testflle sollten wiederholbar, nachprfbar und auf die Anforderungen zurckzufhren sein. Zum Entwurf von Testfllen gehrt die Identifizierung v von: Vorbedingungen, wie projektbezogene oder lokale Testumgebungen (Testvorrichtungen) und deren geplante Bereitstellung Anforderungen an die Testdaten erwarteten Ergebnissen aus dem Testfall und dessen Nachbedingungen Oft stellt die Definition der erwarteten Testergebnisse eine besondere Herausforderung dar. Es gilt, ten ein oder mehrere Testorakel zu finden, die Sollergebnisse fr den Testfall liefern knnen. Bei der Suche nach Sollergebnissen werden nicht nur Bildschirmausgaben untersucht, sondern auch Daten und Nachbedingungen nach dem Testfall in der Testumgebung. Wenn die Testbasis klar definiert ist, ist das theoretisch einfach. In der Praxis ist die Testbasis jedoch oft vage oder widersprchlich, deckt Schlsselbereiche nicht ab, ist unvollstndig oder g nicht gar vorhanden. In solchen Fllen mssen Tester entweder selbst fachliche Expertise haben oder sie zumindest abrufen knnen. Auch wenn die Testbasis gut spezifiziert vorliegt, knnen komplexe Interaktionen zwischen verschiedenen Stimuli und ausgelsten Reaktionen die Definition der erwarteten Testergebnisse erschweren. Tester brauchen deshalb ein Testorakel. Es hat nur sehr begrenzten Wert einen Test durchzufhren, wenn sich die Richtigkeit der Testergebnisse nicht berprfen lsst, denn daraus knnen sich ungltige Abweichungsberichte und unbegrndetes sich Vertrauen in das System ergeben. Die oben beschriebenen Aktivitten lassen sich auf allen Teststufen anwenden, nur die Testbasis ndert sich. So werden fr Anwender Anwender-Abnahmetests in erster Linie die Anforderungsspezifikation, erungsspezifikation, Anwendungsflle und definierte Geschftsprozesse als Basis verwendet, whrend Komponententests meist auf einer detaillierten Entwurfsspezifikation basieren.
Version 2007
Seite 38 von 136
Januar 2010 20100131
Bei der Entwicklung der Testbedingungen und Testflle entstehen in der Regel v verschiedene Arbeitsergebnisse aus der begleitenden Dokumentation. IEEE Standard 829 enthlt Vorgaben fr diese Dokumentation und erlutert die wichtigsten Dokumente zu Testanalyse und -entwurf, Testentwurfs- und Testfallspezifikation sowie Testrealisierung. In der Praxis gibt es jedoch groe Testfallspezifikation Unterschiede bei Umfang und Detaillierungsgrad der Dokumentation von Arbeitsergebnissen. Dies wird beispielsweise beeinflusst durch: Projektrisiken (was muss dokumentiert werden und was nicht) den Mehrwert, den die Dokumentation fr das Projekt schafft Normen und Standards, die eingehalten werden mssen das Lebenszyklusmodell (bei agilen Methoden wird der Umfang der Dokumentation beispielsweise weitgehend durch enge und hufige Kommunikation im Projektteam minimiert) die Anforderung an Rckverfolgbarkeit von der Testbasis ber die Testanalyse bis hin zu Testentwurf, Testfllen und Testdurchfhrung (inklusive der Testergebnisse) Je nach Testumfang knnen sich Testanalyse und Testentwurfsphase auch mit den M TestanalyseMerkmalen des Testobjekts befassen. ISO 9126 bietet dafr eine ntzliche Referenzgrundlage. Beim Testen von Hardware-/Softwaresystemen knnen weitere Merkmale relevant sein. /Softwaresystemen Der Testanalyse- und Testentwurfs Testentwurfs-Prozess lsst sich durch eine Verknpfung mit Reviews und rch statischer Analyse qualitativ verbessern Die Durchfhrung des Testanalyse- und entwurfsprozesses verbessern. entwurfsprozesses basierend auf der Anforderungsspezifikation ist beispiel weise eine ausgezeichnete Vorbereitung auf beispielsweise die Review-Sitzung fr die Anforderungsspezifikation. Auch die Arbeitsergebnisse von Tests, r Risikoanalysen und Testplnen sollten Reviews und statischen Analysen unterzogen werden. In der Testentwurfsphase lassen sich Anforderungsdetails an die Testinfrastruktur definieren; i der in Praxis werden sie aber erst zu Beginn der Testrealisierung endgltig festgelegt. Hinweis: Zur Testinfrastruktur gehrt mehr als nur Testobjekte und Testmittel (Beispiele sind Rumlichkeiten, Ausrstungen, Personal, Software, Werkzeuge, Peripheriegerte, Kommunikationseinrichtungen, Peripheriegerte, Zugriffsberechtigungen, und alles was sonst zum Durchfhren des Test ntig ist). Metriken fr die berwachung von Testanalyse und -entwurf sind prozentualer Anteil der Anforderungen, die von Testbedingungen abgedeckt werde werden prozentualer Anteil der Testbedingungen, die von Testfllen abgedeckt werden Anzahl der Fehlerzustnde, die whrend der Testanalyse und Testentwurfsphase aufgedeckt Testanalysewurden
2.5 Testrealisierung und Testdurchfhrung

2.5.1 Testrealisierung
Bei der Testrealisierung werden die Testflle in Testszenarien (Testdrehbuch/Testablaufspezifikation) (Testdrehbuch/Testablaufspezifikation umgesetzt, wobei Testdaten und Testumgebungen endgltig festzulegen sind. Daraus entsteht der Testausfhrungsplan. Wenn er vorliegt, kann die Ausfhrung der Testflle beginnen. Dazu gehrt stausfhrungsplan. auch die berprfung anhand von expliziten und impliziten Eingangsbedingungen fr die betroffene Teststufe. Die Testszenarien sollten priorisiert sein, damit die in der Teststrategie festgelegten Testziele in mglichst effizient erreicht werden. Das kann heien, die wichtigsten Testszenarien zuerst auszufhren. Der in der Testrealisierung notwendige Detaillierungsgrad und die damit verbundene Komplexitt der Aufgaben knnen durch den Detaillierungsgrad der anderen Arbeitsergebnisse (Testflle und nnen Testbedingungen) beeinflusst werden. In manchen Fllen gelten gesetzliche Bestimmungen und die Version 2007 Seite 39 von 136 Januar 2010 20100131
Tests mssen den Nachweis erbringen, dass die gltigen Normen und Standards tats tatschlich erfllt sind, wie die fr den Flugzeugbau von der United States Federal Aviation Administration definierte Norm DO-178B/ED 12B. Wie in Abschnitt 2.4 angefhrt, sind Testdaten fr das Testen ntig, und diese Datenmengen knnen ziemlich umfangreich sein. Whrend der Testrealisierungsphase erzeugen die Tester Eingabe und EingabeUmgebungsdaten, die in Datenbanken oder anderen Repositories abgelegt werden. Sie erstellen Skripte und andere Datengeneratoren fr die Daten, die dann beim Durchfhren des Tests als eingehende Last an das System gesendet werden. In der Testrealisierungsphase sollten die Tester die Reihenfolge der durchzufhrenden manuellen und automatisierten Tests endgltig festlegen. Bei einer Automatisierung der Tests gehrt zur Automatisierung Testrealisierungsphase auch das Erstellen von Testrahmen und Testskripten. Dabei sind Einschrnkungen genau zu beachten, die mglicherweise eine bestimmte Reihenfolge der Tests vorgeben. Abhngigkeiten von bestimmten Testumgebungen oder Testdaten mssen bekannt sein Testumgebungen und berprft werden. Die Testrealisierung befasst sich auerdem mit der Testumgebung oder den umgebungen. In dieser umgebungen. Phase und noch vor der Testdurchfhrung sollten sie vollstndig vorhanden und verifiziert sein. E Eine zweckdienliche Testumgebung ist unverzichtbar: Sie sollte so beschaffen sein, dass sich vorhandene Fehlerzustnde unter definierten Rahmenbedingungen aufdecken lassen; sie sollte normal operieren, Rahmenbedingungen solange keine Fehlerwirkungen auftreten, und schlielich sollte sie bei Bedarf in den hheren schlielich Teststufen beispielsweise die Produktions oder Anwendungsumgebung angemessen abbilden. ProduktionsIn der Testrealisierungsphase mssen die Tester bzw. muss der Testmanager sicherstellen, dass die fr Erzeugung und Wartung der Testumgebung zustndigen Personen bekannt und verfgbar sind, und dass die Testmittel und Werkzeuge zur Testuntersttzung sowie die zugehrigen Prozesse einsatzbereit sind. Das schliet ein: Konfigurationsmanagement, FehlerFehler und Abweichungsmanagement, Testprotokollierung und Testmanagement. Auerdem mssen die protokollierung Verfahren verifiziert werden, mit denen die Daten fr Testendekriterien und fr Berichte ber die Testergebnisse gesammelt werden. Fr die Testrealisierung empfiehlt sich ein ausgewogener Ansatz. Risikoorientierte, analytische Risikoorientierte, Teststrategien werden beispielsweise oft mit dynamischen Teststrategien kombiniert. In diesem Fall wird ein Teil des Testdurchfhrungsaufwands fr das Testen ohne Skripte verwendet. Testen ohne Testskripte sollte aber nicht ad hoc oder ziellos sein, da der Zeitaufwand schwer hoc einzuschtzen ist, falls keine zeitliche Eingrenzung erfolgt (siehe SBTM, Abschnitt 3.11.1 Im Laufe 3.11.1). der Zeit haben Tester verschiedene erfahrungsbasierte Verfahren entwickelt, wie Fehlerangriffe (siehe Abschnitt 4.4 und [Whittaker03]), intuitive Testfallermittlung (Fehlerraten) [Myers79] und exploratives Testen. Dabei kommen Testanalyse, Testentwurf und Testrealisierung immer noch vor, allerdings vorwiegend beim Durchfhren des Tests und nicht vorab. Wenn solche dynamischen Teststrategien fhren verfolgt werden, dann beeinflussen die Testergebnisse jedes einzelnen Tests Analyse, Entwurf und Realisierung der nachfolgenden Tests. Diese Teststrategien sind leicht und oft sehr effektiv beim Auffinden von Fehlern, sie bentigen aber erfahrene Tester. Auch ist ihre Dauer schwer abzuschtzen, sie liefern oft nicht die notwendigen Informationen zur Testberdeckung, und ohne ein spezifisches Werkzeug fr Regressionstests knnen sie s schwierig zu wiederholen sein.
2.5.2 Testdurchfhrung
Die Testdurchfhrung beginnt, sobald das Testobjekt zur Verfgung steht und die Eingangsbedingungen fr die Testdurchfhrung erfllt sind. Die Tests sollten gem den Testszenarien (Testablaufspezifikation) durchgefhrt werden, obwohl den Testern ein gewisser enarien Spielraum eingerumt werden kann, damit sie zustzliche interessante Testszenarien und Version 2007 Seite 40 von 136 Januar 2010 20100131
Testverhalten verfolgen knnen, die sich erst whrend des Testens ergeben. Werden bei einer Abweichung vom festgelegten Testvorgehen Fehlerwirkungen aufgedeckt, mssen die nderungen der Testvorgehen so dokumentiert werden, dass sich die Fehlerwirkungen reproduzieren lassen. Automatisierte Tests laufen ohne Abweichung von den definierte Vorgaben ab. definierten Kernstck der Testdurchfhrung ist der Vergleich zwischen tatschlichen und erwarteten Testergebnissen. Diese Aufgabe verlangt allergrte Aufmerksamkeit und Sorgfalt, denn alle Arbeit bei Entwurf und Realisierung des Tests kann umsonst gewesen sein, wenn Fehlerwirkungen gewesen bersehen werden (falsch positives Ergebnis), oder wenn korrektes Verhalten irrtmlicherweise als inkorrekt gedeutet wird (falsch negatives Ergebnis). Wenn erwartete und tatschliche Testergebnisse nicht bereinstimmen, dann liegt eine Abweichung vor. Abweichungen mssen sorgfltig berprft werden, um die Ursachen festzustellen (und ob es sich dabei um einen Fehlerzustand im Testobjekt handelt), und um die Daten zum Beheben der Abweichung zu sammeln. Weitere Informationen zu zum Abweichungsmanagement enthlt Kapitel 7. Wird eine Fehlerwirkung entdeckt, sollte zunchst die Testspezifikation einer genauen Bewertung unterzogen werden, um deren Richtigkeit sicherzustellen. Testspezifikationen knnen aus verschiedenen Grnden inkorrekt sein: bei Problemen mit den Testdaten, bei Fehlern im chiedenen Testdokument, oder wenn der Test falsch ausgefhrt wurde. Stellt sich heraus, dass die Testspezifikation inkorrekt war, muss sie korrigiert und der Test wiederholt werden. n nderungen an Testbasis und Testobjekt knnen dazu fhren, dass eine Testspezifikation nicht mehr stimmt, obwohl sie schon mehrmals erfolgreich abgearbeitet wurde. Es sollte den Testern deshalb immer bewusst sein, dass beobachtete Testergebnisse auch auf einem inkorrekten Test beruhen knnten. einem Whrend der Testdurchfhrung mssen die Testergebnisse angemessen protokolliert werden. Wenn ein Test durchgefhrt wurde, die Ergebnisse aber nicht aufgezeichnet wurden, muss er eventuell wiederholt werden, um das korrekte Ergebnis festzustellen. Das ist ineffizient und fhrt zu korrekte Verzgerungen. (Hinweis: Adquate Protokollierung kann aber die Vorbehalte bezglich berdeckungsgrad und Wiederholbarkeit bei dynamischen Teststrategien entkrften.) Da sich Testobjekt, Testmittel und Testumgebungen weiterentwickeln knnen, muss aus der Protokollierung el hervorgehen, welche Version getestet wurde. Die Testprotokollierung liefert eine chronologische Aufzeichnung aller relevanten Details der Testdurchfhrung. Die Testergebnisse sind sowohl bei einzelnen Tests als auch bei Ereignissen zu protokollieren. Jeder Test sollte eindeutig gekennzeichnet und sein Status im Verlauf der Testdurchfhrung protokolliert werden. Ereignisse, die sich auf das Durchfhren des Tests auswirken, sind zu protokollieren. Die protokollieren. Testprotokollierung sollte ausreichende Informationen aufzeichnen, um die Testberdeckung zu messen und Grnde fr Verzgerungen oder Unterbrechungen im Testbetrieb zu dokumentieren. Darber hinaus mssen Informationen protokolliert werden, die fr Teststeuerung, werden, Testfortschrittsberichte, Messung der Testendekriterien und fr Verbesserungen des Testprozesses von Nutzen sind. Je nach Teststufe und -strategie ist die Protokollierung unterschiedlich. Bei automatisierten strategie Komponententests zeichnen beispielsweise die automatisierten Tests den grten Teil der chnen Protokolldaten selbst auf. Bei manuellen Abnahmetests kann der Testmanager das Testprotokoll erstellen. In manchen Fllen, wie bei der Testrealisierung, beeinflussen Vorschriften oder Audi AuditAnforderungen die Testprotokollierung. IEEE Standard 829 Standard for Software Testing Documentation beschreibt die Informationen, die in einem Testprotokoll festzuhalten sind Testprotokoll-ID (eindeutige Kennung des Testpr ID Testprotokolls) Beschreibung Seite 41 von 136 Januar 2010 20100131
Version 2007
Aktivitts- und Ereigniseintrge Auch der britische Standard BS 7925 ritische 7925-2 enthlt eine Beschreibung der zu protokollierenden Informationen. In manchen Fllen sind Nutzer oder Kunden am Durchfhren des Tests beteiligt, was dazu dienen beteiligt, kann, ihr Vertrauen in das System zu strken. Voraussetzung ist dann aber, dass die Tests im Auffinden von Fehlern weitgehend erfolglos bleiben. Eine derartige Annahme trifft in den frhen Teststufen selten zu, kann whrend der Abn Abnahmetests aber durchaus gelten. Mgliche Metriken fr die berwachung der Testrealisierung und Testdurchfhrung sind prozentualer Anteil der konfigurierten Testumgebungen prozentualer Anteil der geladenen Testdatenstze prozentualer Anteil der durchgefhr durchgefhrten Testbedingungen und Testflle prozentualer Anteil der automatisierten Testflle
2.6 Testauswertung und Bericht

Weitere Informationen zu den Themen Dokumentation und Berichte fr die Testfortschrittsberwachung und Teststeuerung enthlt Abschnitt 3.6. Fr den Testprozess geht es g . bei der berwachung des Testfortschritts vor allem darum, Informationen gem den Anforderungen an die Berichte zu sammeln. Dazu gehrt auch, den Testfortschritt mit Bezug auf die den Testendekriterien zu messen. Zu den Metriken fr die berwachung von Testfortschritt und abschluss gehrt, dass die in der abschluss Testplanungsphase festgelegten Testendekriterien abgebildet sind, dazu kann eine oder mehrere d der folgenden Metriken gehren: Vergleich der geplanten mit den tatschlich durchgefhrten Testbedingungen, Testfllen oder Testspezifikationen, jeweils mit der Angabe, ob sie bestanden wurden oder nicht Gesamtzahl der aufgedeckten Fehlerzustnde, jeweils mit Schweregrad und Prioritt, fr die korrigierten und die noch offenen Fehler Anzahl der nderungen (nderungsantrge), die erzeugt, akzeptiert (implementiert) und getestet wurden geplante Kosten gegenber tatschlichen Kosten geplanter Zeitaufwand gege gegenber tatschlich aufgewendeter Zeit identifizierte Risiken, eingeteilt in durch die Testaktivitten geminderte Risiken und verbleibende prozentualer Anteil der Testzeit, die durch blockierende Ereignisse verloren ging Testobjekte, die einem Fehlernachtes unterzogen wurden Fehlernachtest geplante Gesamttestzeit gegenber tatschlich aufgewendeter Testzeit Fr einen Testbericht spezifiziert IEEE Standard 829 folgende Abschnitte: Kennung/ID des Testberichts Zusammenfassung Abweichungen umfassende Bewertung Zusammenfassung der Testergebnisse g Testauswertung Zusammenfassung der Testaktivitten Genehmigungen/Freigaben
Version 2007
Seite 42 von 136
Januar 2010 20100131
Die Testberichte knnen jeweils nach Abschluss einer Teststufe erstellt werden, aber auch zum Abschluss der gesamten Testarbeiten.
2.7 Abschluss der Testaktivitte Testaktivitten

Nachdem die Testdurchfhrung als abgeschlossen erklrt wurde, sollten die wichtigsten Ergebnisse festgehalten und entweder an die zustndige Person weitergeleitet oder archiviert werden. Man bezeichnet das als den Abschluss der Testaktivitten. Testabschlussaktivitten knnen in folgende hluss vier Hauptgruppen eingeteilt werden: 1. Sicherstellen, dass alle Testaufgaben tatschlich abgeschlossen sind: So sollten alle geplanten Tests tatschlich durchgefhrt oder aber gezielt bersprungen worden sein. Alle bersprungen bekannten Fehlerzustnde sollten entweder behoben und nachgetestet oder auf einen zuknftigen Release verschoben worden sein, oder aber als permanente Einschrnkung akzeptiert sein. 2. Die wertvollen Arbeitsergebnisse den Personen oder Stellen liefern, die sie bentigen: So sollten beispielsweise diejenigen, die das System benutzen oder seine Benutzung betreuen werden (beispielsweise Support), erfahren, welche bekannten Fehler verschoben oder akzeptiert wurden. Die fr die Wartungstests zustndigen Personen sollten Tests und Wartungstests Testumgebungen erhalten. Ein anderes Arbeitsergebnis knnte ein Satz manueller oder automatisierter Regressionstests sein. 3. Besprechungen ber die Erfahrungen aus dem Testen (Bewertungssitzung,lessons learn (Bewertungssitzung,lessons learned) halten oder an ihnen teilnehmen: In diesen Besprechungen knnen wichtige Erkenntnisse sowohl aus dem eigentlichen Testprozess als auch aus dem gesamten Softwarelebenszyklus dokumentiert und daraus Manahmen abgeleitet werden, damit sie sich nicht wiederhol wiederholen. Falls sich Probleme nicht lsen lassen, knnen sie zumindest in zuknftigen Projektplnen bercksichtigt werden. Beispiele: a. Weil es unerwartete Fehleranhufungen erst relativ spt aufdecken konnte, kommt das Team vielleicht zu der Erkenntnis, dass an den Besprechungen zur Qualittsrisikoanalyse bei zuknftigen Projekten ein breiterer Querschnitt an Nutzern teilnehmen sollte. b. Mglicherweise waren die Testschtzungen sehr unzutreffend, sodass sich hieraus Lehren fr zuknftige Schtzaktivitten ziehen lassen, vor allem aus den Ursachen. lassen, So kann es an ineffektivem Testen gelegen haben, oder die Schtzung war von vornherein zu niedrig angesetzt. c. Die Tester knnen Tendenzen feststellen und Ursache und Wirkung bei aufgedeckten Fehlern analysieren. Dazu verfolgen sie, warum und wann die Fehler verfolgen auftraten, und untersuchen, ob sich Tendenzen abzeichnen. So knnten spte nderungsantrge die Qualitt von Analyse und Entwicklung beeinflusst haben. Auch nach ungeeigneten Praktiken knnen die Tester suchen, und wie vi Zeit viel diese gekostet haben, wie das Auslassen einer Teststufe, die die Fehler frher und kosteneffektiver aufgedeckt htte. Einige Fehlertendenzen lassen sich auch mit Rahmenbedingungen in Zusammenhang bringen, wie dem Einsatz neuer Technologien, Personalwechsel oder fehlender fachliche Qualifikation. Personalwechsel d. Mgliche Verbesserungen fr den Testprozess identifizieren. 4. Ergebnisse, Protokolle, Berichte und andere Dokumente und Arbeitsergebnisse im Konfigurationsmanagement-System archivieren, mit Anbindung an das System. So sollten Konfigurationsmanagement ystem. beispielsweise Testkonzept und Projektplan im Planungsarchiv archiviert werden und eindeutig auf das System und die Version verweisen, fr die sie eingesetzt wurden.
Version 2007
Seite 43 von 136
Januar 2010 20100131
All diese Aufgaben sind wichtig, auch wenn sie oft vergessen werden, und sie sollten explizit ein Teil des Testkonzepts sein. Oft werden eine oder mehrere dieser Aufgaben ausgelassen, meist weil das Testteam zu frh aufgelst wird, weil Zeit oder Ressourcen fr nachfolgende Projekte bentigt werden, oder weil das Team berarbeitet und erschpft ist. Bei Vertragsprojekten, beispielsweise kundenindividuellen itet Entwicklungsauftrgen, sollten die notwendigen Aufgaben im Vertrag spezifiziert sein. Mgliche Metriken fr den Abschluss der Testaktivitten sind prozentualer Anteil der bei der Testdurchfhrung ausgefhrten Testflle (berdeckung) i prozentualer Anteil der Testflle, die in das Repository fr wiederverwendbare Testflle aufgenommen wurden Anteil der automatisierten gegenber den zu automatisierenden Testfllen prozentualer Anteil der Testflle, die als Regressionstests gelten teil prozentualer Anteil ungelste Fehlerberichte, die geschlossen wurden (beispielsweise ungelster verschoben, keine weiteren Manahmen, nderungsanforderung usw.) prozentualer Anteil der identifizierten und archivie archivierten Arbeitsergebnisse.
Version 2007
Seite 44 von 136
Januar 2010 20100131
3. Testmanagement
Begriffe:
FMEA, Mastertestkonzept, Produktrisiko Projektrisiko, Risikobeherrschung bzw. -steuerung, , Produktrisiko, , Risikoanalyse, Risikoidentifizierung, Risikomanagement risikoorientierter Test, Risikostufe Risikotyp, , Risikomanagement, , Risikostufe, session-based Testmanagement, Stufentestkonzept, Testfortschrittsbericht, Testmanagement , Stufentestkonzept, Testmanagement, Testpunktanalyse (TPA), Testrichtlinie Testschtzung, Teststeuerung, Teststrategie, Teststufe , Testrichtlinie, , Teststufe, Testberwachung, zeitliche Testplanung Wideband Delphi. , Testplanung,
3.1 Einfhrung
Dieses Kapitel deckt die Wissensgebiete ab, die speziell fr Testmanager relevant sind.
3.2 Testmanagement-Dokumentation Dokumentation

Dokumentation entsteht oft als Teil des Testmanagements. Whrend Bezeichnungen und Umfang der Testmanagement-Dokumente oft variieren, so sind doch die folgenden typischen Testmanagement Dokumente TestmanagementDokumente in Unternehmen und Projekten blich: Testrichtlinie: Sie beschreibt die Unternehmensphilosophie fr das Testen (mglicherweise Unternehmensphilosophie auch fr die Qualittssicherung). Teststrategie: Sie beschreibt die Testmethoden beim Risikomanagement von Produkt und ProduktProjektrisiken, die Aufteilung des Tests in Schritte, die generelle Teststrategie, Teststuf Teststufen oder Testphasen sowie bergeordnete testbezogene Aktivitten im Unternehmen. Mastertestkonzept (Projekttestkonzept Testvorgehensweise): Es beschreibt die Anwendung Projekttestkonzept, ): der Teststrategie fr ein bestimmtes Projekt, einschlielich der jeweiligen Teststufen und bestimmtes deren Verhltnis zueinander. Stufentestkonzept (Phasentestplan): Es beschreibt die in den jeweiligen Teststufen (Phasentestplan): durchzufhrenden Aktivitten, einschlielich etwaiger Erweiterungen des Mastertestkonzepts Erweiterungen fr die spezifisch dokumentierte Teststufe. In einigen Unternehmen und Projekten werden die oben aufgefhrten Dokumente in einem einzigen Dokument zusammengefasst, oder sie sind in anderen Dokumenten enthalten, oder der Inhalt w wird einfach als intuitive, ungeschriebene oder traditionelle Testmethodik zu Grunde gelegt. Grere, runde formal strukturierte Unternehmen und Projekte gestalten die Dokumente meist als Arbeitsergebnisse in schriftlicher Form, whrend in kleineren Unternehmen und Projekten meist weniger dokumentiert und wird. Der Lehrplan beschreibt jedes der oben angefhrten Dokumente, in der Praxis gibt aber der konkrete Unternehmens- und Projektzusammenhang vor, wie das jeweilige Dokument richtig anzuwenden ist.
3.2.1 Testrichtlinie
Die Testrichtlinie beschreibt die Unternehmensphilosophie fr das Testen (mglicherweise auch fr die Qualittssicherung). Verschiedentlich wird die Testrichtlinie auch als Testpolitik bezeichnet. Sie liegt entweder in schriftlicher Form vor oder als eine Managementanweisung und beschreibt die allgemeinen Ziele, die das Unternehmen durch das Testen erreichen mchte. Die Richtlinie kann
Version 2007
Seite 45 von 136
Januar 2010 20100131
durch die Abteilungen IT, Forschung und Entwicklung oder Produktentwicklung erstellt werden und Produktentwicklung sollte die unternehmerischen Werte und Ziele hinsichtlich des Testens darstellen. Die Testrichtlinie kann entweder eine Ergnzung zur allgemeinen Qualittsrichtlinie des Unternehmens sein oder ein Teil davon. Die Qualittsrichtlinie legt fest, welche Werte und Ziele das Qualittsrichtlinie Management in Bezug auf die Qualittsansprche des Unternehmens anstrebt. Wenn eine Testrichtlinie vorliegt, kann sie ein kurzes abstraktes Dokument sein, das das Testen definiert, im Sinne einer vertrauensbildenden Manahme, dass das System wie vertrauensbildenden beabsichtigt funktioniert, oder dass Fehler aufgedeckt werden. einen fundamentalen Testprozess festschreibt, der beispielsweise bestehen kann aus: Testplanung und -steuerung, Testanalyse und -entwurf, Testrealisierung und steuerung, entwurf, Testdurchfhrung, Testauswertung der Testendekriterien und Berichterstattung sowie Abschluss der Testaktivitten. beschreibt, wie Wirksamkeit und Effizienz des Testens zu bewerten sind, beispielsweise die Fehlerfindungsrate und die Kosten von im Test gefundenen Fehlern im Gegensatz zu den gefundenen Kosten, die Fehlerzustnde nach der Freigabe verursachen. gewnschte Qualittsziele definiert, wie Zuverlssigkeit (beispielsweise gemessen an der Ausfallrate) oder Benutzbarkeit. Aktivitten fr die Testprozessverbesserung vorgibt, beispielsweise Einsatz des Test Maturity Testprozessverbesserung Modells (TMM) oder des Test Process Improvement Modells (TPI), oder die Umsetzung von Erkenntnissen aus abgeschlossenen Projekten. Die Testrichtlinie kann sich sowohl auf Testaktivitten fr Neuentwicklungen als auch auf die Wartung Neuentwicklungen beziehen. Sie kann auerdem ein verbindlicher unternehmensweiter Standard fr Testterminologie sein.
3.2.2 Teststrategie
Die Teststrategie beschreibt die Testmethoden des Unternehmens. Beschrieben werden auch des Produkt- und Projekt-Risikomanagement, die Aufteilung des Testens in Teststufen oder Testphasen komanagement, sowie die bergeordneten testbezogenen Aktivitten. Der in der Teststrategie beschriebene Testprozess und die Testaktivitten sollten der Tes richtlinie entsprechen. Die Teststrategie sollte die itten Testrichtlinie allgemeinen Testerfordernisse fr das Unternehmen oder fr ein oder mehrere Pr jekte liefern. Projekte Wie im Foundation-Level-Lehrplan beschrieben, lassen sich generelle Teststrategien und vorgehensweisen) nach dem Beginn der Testentwurfsphase klassifizieren: ) Eine vorbeugende Strategie entwirft den Test frhzeitig, um Fehler zu verhindern. Eine reagierende Strategie entwirft den Test, nachdem die Software oder das System erstellt wurde. Typische Teststrategien und Testvorgehensweisen sind u.a.: analytische Strategien, wie das risikoorientierte Testen modellorientierte Strategien, wie das am Anwendungsprofil orientierte Testen methodische Strategien, beispielswe beispielsweise auf Qualittsmerkmalen basierend prozesskonforme oder standardkonforme Strategien, beispielsweise auf dem Standard IEEE 829 basierend dynamische und heuristische Strategien, wie die Nutzung fehlerbasierter Angriffe beratende Strategien, wie das anwende anwendergesteuerte Testen Regressionstest-Strategien, beispielsweise weitgehende Automatisierung Strategien, Seite 46 von 136 Januar 2010 20100131
Version 2007
Verschiedene Strategien lassen sich kombinieren. Die ausgewhlte Strategie sollte sich an den Erfordernissen und Mitteln des Unternehmens orientieren, und Unternehmen knnen die Strategien auf ihre eigenen speziellen Ablufe und Projekte zuschneiden. Oft erlutert eine Teststrategie die Projekt und Produktrisiken, und wie im Testprozess mit diesen ProjektRisiken umzugehen ist. Der Zusammenhang zwischen Test und Risiken sollte ausdrcklich erklrt sollte werden, wie auch die Mglichkeiten fr Risikominderung und -management. den, Die Teststrategie kann die auszufhrenden Teststufen beschreiben. Sie sollte dann eine grobe Leitlinie fr die Eingangs- und Ausgangsbedingungen jeder Teststufe sowie fr die Beziehungen zwischen den Teststufen (beispielsweise Aufteilung Testberdeckungsziele) vorgeben. stufen Die Teststrategie kann auerdem beschreiben Vorgehensweise fr die Integration Testspezifikationsverfahren Unabhngigkeit des Testens (kann je nac Teststufe variieren) nach Verpflichtend oder freiwillig einzuhaltende Normen/Standards Testumgebungen Testautomatisierung Wiederverwendbarkeit von Software und Arbeitsergebnissen des Testens Fehlernachtest und Regressionstests Teststeuerung und -berichte berichte Testmae und -metriken Abweichungsmanagement Konfigurationsmanagement der Testmittel Es sollten sowohl kurz- als auch langfristige Teststrategien definiert werden, entweder in einem oder mehreren Dokumenten. Unterschiedliche Teststrategien eignen sich fr unte ren unterschiedliche Unternehmen und unterschiedliche Projekte. Wenn es beispielsweise um sicherheitsrelevante oder sicherheitskritische Anwendungen geht, dann sind intensivere Strategien geeigneter. tische
3.2.3 Mastertestkonzept
Das Mastertestkonzept beschreibt die Anwendung der generellen Teststrategie fr ein spezifisches Projekt. Dazu gehren die auszufhrenden Teststufen und die Beziehungen zwischen ihnen. Das Mastertestkonzept sollte mit der Testrichtlinie und der Teststrategie konsistent sein. Falls es in bestimmten Bereichen davon abweicht, sollten die Abweichungen und Ausnahmen erklrt werden. Das Mastertestkonzept sollte den Projektplan oder das Betriebshandbuch ergnzen und den Testaufwand beschreiben, der Teil eines greren Projekts oder einer gr eren Operation ist. greren Inhalt und Aufbau des Mastertestkonzepts knnen je nach Unternehmen, den im Unternehmen verwendeten Dokumentationsstandards und der im Projekt gelebten Formalitt variieren. Typische Themen fr ein Mastertestkonzept sind en Objekte, die getestet oder nicht getestet werden sollen Qualittsmerkmale, die getestet oder nicht getestet werden sollen Testplan und Budget fr das Testen (in Anlehnung an das Projekt oder Betriebsbudget) ProjektTestdurchfhrungszyklen und deren Beziehung zum Release Plan fr die Software ngszyklen Release-Plan wirtschaftliche Begrndung fr das Testen und Geschftswert des Testens Beziehungen und Arbeitsergebnisse der Testabteilung zu anderen Personen oder Abteilungen definierte Abgrenzungen zwisch Testobjekten in den jeweiligen Teststufen zwischen
Version 2007
Seite 47 von 136
Januar 2010 20100131
Spezifikation der Eingangsbedingungen, Unterbrechungs und Wiederaufnahmekriterien Unterbrechungssowie Ausgangsbedingungen fr jede Teststufe und der Beziehungen zwischen den Teststufen Testprojektrisiken In kleineren Projekten oder Unternehmen, in denen nur eine Teststufe formal getestet wird, werden en Mastertestkonzept und Testkonzept fr diese Teststufe oft in einem Dokument zusammengefasst. Ist der Systemtest die einzige formale Teststufe, mit einem informellen, von den Entw Entwicklern durchgefhrten Komponenten- und Integration test und einem informellen Abnahmetest, der vom Integrationstest Kunden als Teil eines Beta-Tests durchgefhrt wird, so knnen all diese Elemente im Tests Systemtestkonzept enthalten sein. Meist hngt das Testen von anderen Aktivitten im Projekt ab. Wenn diese Aktivitten nicht Aktivitten ausreichend dokumentiert sind, vor allem was ihren Einfluss auf und ihre Beziehung zum Testen reichend betrifft, dann kann dies im Mastertestkonzept (oder im entsprechenden Stufentestkonzept) abgedeckt werden. Ist beispielsweise der Konfigurationsmanagement t Konfigurationsmanagement-Prozess nicht dokumentiert, dann sollte im Mastertestkonzept festgehalten werden, wie Tes objekte an das Testteam geliefert werden. Testobjekte
3.2.4 Stufentestkonzept
Das Stufentestkonzept beschreibt die in jeder Teststufe auszufhrenden Aktivitten. Wenn ntig, kann es das Mastertestkonzept fr die dokumentierte Teststufe erweitern und beispielsweise Details zu Terminplan, Aufgaben und Meilensteinen spezifizieren, die im Mastertestkonzept nicht dokumentiert spezifizieren, sind. Wenn unterschiedliche Standards und Dokumentvorlagen fr die Spezifikation der Tests in verschiedenen Teststufen gelten, werden sie im Stufentestkonzept dokumentiert. In weniger formalen Projekten oder Unternehmen entsteht oft ein Stufentestkonzept mit nur einer Unternehmen Stufe als einziges Testmanagementdokument. Es kann dann einige der in den Abschnitten 3.2.1, mentdokument. 3.2.2 und 3.2.3 erwhnten Informationen enthalten enthalten.
3.3 Dokumentvorlagen fr Testkonzepte

Wie in Abschnitt 3.2 erwhnt, variieren Inhalt und Aufbau des Mastertestkonzepts je nach Mastertestkonzepts Unternehmen, Dokumentationsstandards und der Formalitt des Projekts. Viele Unternehmen erstellen eigene Dokumentvorlagen oder passen vorhandene an, um so fr die Testkonzeptdokumentation Einheitlichkeit und Lesbarkeit projekt projekt und prozessbe prozessbergreifend sicherzustellen. Dokumentvorlagen fr die Testkonzeptdokumentation stehen zur Verfgung. IEEE Standard 829 Standard for Software Testing Documentation enthlt Vorlagen fr die Testdokumentation und eine Anleitung zu ihrer Anwendung sowie eine Anleitung fr die Erstellung von Testkonzepten. Die Norm befasst sich auch mit dem verwandten Thema der Testobjektbergabe (Freigabe von Testobjekten fr den Test).
3.4 Testaufwandsschtzung
Aufwandsschtzungen als Managementaktivitt fhren zu einem ungefhren Kosten und Terminplan Kostenfr die Aktivitten in einem bestimmten Unternehmen oder Projekt. Die besten Aufwandsschtzungen Aufwandsschtzungen: reprsentieren die kollektive Erfahrung von erfahrenen Praktikern und werde von allen werden Betroffenen getragen liefern detaillierte Aufstellungen der Kosten, Ressourcen, Aufgaben und beteiligten Mitarbeiter zeigen die wahrscheinlichen Kosten, Aufwand und Dauer fr jede geschtzte Aktivitt.
Version 2007
Seite 48 von 136
Januar 2010 20100131
Die Schtzung von Aufgaben in der Sof Software- und Systementwicklung ist bekanntermaen schwierig, sowohl technisch als auch politisch, obwohl es im Projektmanagement Best Practice Verfahren fr die Practice-Verfahren Schtzung gibt. Die Testschtzung ist die Anwendung dieser Verfahren auf die Testaktivit Testaktivitten in einem Projekt oder Unternehmen. Die Testschtzung sollte alle Aktivitten im Testprozess einschlieen, von Testplanung und Teststeuerung ber Testanalyse und Testentwurf, Testrealisierung und -durchfhrung, abschlieende durchfhrung, Testauswertung und Berichte bis zum Abschluss der Testaktivitten. Geschtzte Kosten, Aufwand Abschluss und vor allem Dauer der Testdurchfhrung interessieren das Management oft besonders, weil die Testdurchfhrung typischerweise auf dem kritischen Pfad des Projekts liegt. Schtzungen der Testdurchfhrung sind aber schwierig und tendenziell unzuverlssig, wenn die Gesamtqualitt der Software schlecht ist oder nicht bekannt. Es ist gngige Praxis, die Anzahl von erforderlichen Testfllen zu schtzen. Die getroffenen Annahmen bei der Aufwandschtzung sollten immer als Teil zen. der Aufwandsschtzung dokumentiert we werden. Die Testschtzung sollte alle Faktoren bercksichtigen, die Kosten, Aufwand und Dauer der Testaktivitten beeinflussen knnen. Dazu gehren: tivitten erforderliches Qualittsniveau des Systems Gre des zu testenden Systems estenden historische Daten aus frheren Testprojekten (auch Benchmark Benchmark-Daten) Prozessfaktoren, wie die Entwicklung der Teststrategie; Wartungslebenszyklus und Prozessreife; Richtigkeit der Projektschtzung Materialfaktoren, wie Testautomatisierung und Testwerkzeuge, Testumgebung, Testdaten, und Entwicklungsumgebung(en); Projektdokumentation (beispielsweise Anforderungen, Entwrfe, usw.) und wiederverwendbare Arbeitsergebnisse are Personalfaktoren, wie Manager und Technische Leiter; Engagement und Erwartungen der Geschftsleitung und des oberen M nagements; fachliches Knnen, Erfahrung und Motivation Managements; im Projektteam, Stabilitt des Projektteams, Beziehungen der Projektmitglieder untereinander; Hilfe bei der Nutzung der Test und Debuggingumgebung; Verfgbarkeit qualifizierter TestAuftragnehmer und Berater; Fachwi Fachwissen. Weitere Faktoren knnen die Testaufwandsschtzung beeinflussen: Komplexitt des Testprozesses; Technik, Organisation; Anzahl der Betroffenen beim Testen; viele rumlich getrennte Teilteams, auergewhnlicher Aufwand fr den Aufbau der Testmannschaft, Training und Einarbeitung; licher , Anpassung oder Entwicklung von neuen Testwerkzeugen, Verfahren, kundenspezifische Hardware, Anzahl der Testmittel; Anforderungen fr eine auergewhnlich detaillierte Testspez Testspezifikation, besonders bei Anwendung eines nicht vertrauten Dokumentationsstandards; komplexe Terminierung der Komponentenbeschaffung, besonders fr Integrationstest und Testentwicklung; und vernderliche nentenbeschaffung, Testdaten (beispielsweise Daten mit Lschfristen). Die Testaufwandsschtzung lsst sich Bottom staufwandsschtzung Bottom-Up oder Top-Down durchfhren, dabei knnen die Down folgenden Testaufwandsschtzverfahren eingesetzt werden: aufwandsschtzverfahren Intuition und Raten Erfahrungen aus frheren Projekten Aufteilen in Aufgabenblcke und Erstellung eine Projektstrukturplans (WBS, Work Breakdown Projektstrukturplans Structures) gemeinsame Schtzungen im Team (beispielsweise Wideband Delphi) Drei-Punkt-Schtzung Testpunktanalyse (TPA) [Pol02] Unternehmensstandards und Normen
Version 2007
Seite 49 von 136
Januar 2010 20100131
prozentualer Anteil am Gesamtprojekt oder an bestimmten Mitarbeitergruppen (beispielsweise Mitarbeitergruppen das Verhltnis von Testern zu Entwicklern) Modelle, basierend auf gemessenen Werten, zum Schtzen der Anzahl von Fehlerwirkungen, Testzyklen, Testfllen; des durchschnittlichen Aufwands je Test und der Anzahl von Regressionstestzyklen Durchschnittswerte der Branche und Vorhersagemodelle, wie Testpunkte (test points), Funktionspunkte (function points), Anzahl der Codezeilen, geschtzter Aufwand der tion Entwicklerinnen und Entwickler oder andere Projektpar Projektparameter Wenn die Testaufwandsschtzung erstellt ist, muss sie meist mit einer B grndung (siehe Abschnitt schtzung Begrndung 3.7) dem Management vorgelegt werden. Oft folgen Verhandlungen, die nicht selten zu einer ) berarbeitung der vorgelegten Zahlen fhren. Im Id Idealfall ist die endgltige Version der t Testaufwandsschtzung der beste mgliche Kompromiss zwischen Unternehmenszielen und Projektzielen hinsichtlich Qualitt, Zeitplan, Budgetierung und erwarteter Funktionalitt.
3.5 Zeitliche Testplanung

Wenn Aktivitten vorab geplant werden, lassen sich meist schon im Vorfeld zum einen Risiken in Zusammenhang mit diesen Aktivitten entdecken und beherrschen, und zum andern diese Aktivitten mit den Beteiligten sorgfltig und frhzeitig koordinieren, was sich in einem qualitativ hochwertigen orgfltig Plan niederschlgt. Das gilt auch fr die Testplanung. Testplanung auf Basis der Testschtzung bietet noch mehr Vorteile: Entdeckung und Management von Projektrisiken und Problemen auch auerhalb des Testens Problemen Entdeckung und Management von Produktrisiken (Qualittsrisiken) und Problemen vor Beginn der Testdurchfhrung Erkennen von Problemen im Projektplan oder bei anderen Arbeitsergebnissen des Projekts Chancen auf Bewilligung e einer Aufstockung des Testteams, des Budgets, des Aufwands und/oder der Dauer, um damit eine hhere Qualitt zu erreichen Identifizierung kritischer Komponenten, um die frhere Lieferung dieser Komponenten in den Test zu beschleunigen Bei der Testplanung sollte das Testteam eng mit den Entwicklern zusammenarbeiten, denn das llte Testen hngt stark vom Zeitplan fr En Entwicklung und Lieferung ab. Bis alle zur Erstellung des Testkonzepts notwendigen Informationen vorliegen, kann aber wertvolle Zeit verstrichen sein und der mgliche Nutzen verloren gehen. Deshalb sollten Entwrfe von Testkonzepten mglichst frh erstellt und vorgelegt werden. Wenn dann neue Informationen verfgbar sind, kann sie der Verfasser des Testkonzepts (in der Regel ein Testmanager) einarbeiten Dieser einarbeiten. iterative Ansatz fr Erstellung, Freigabe und Review des Testkonzepts frdert Konsens, Kommunikation und Diskussion beim Testen. kussion
3.6 Testfortschritt berwachen und steuern

Die fnf wesentlichen Aspekte fr die berwachung des Testfortschritts sind Produktrisiken Fehlerzustnde Tests berdeckungsgrad Vertrauen in die Softwarequalitt
Version 2007
Seite 50 von 136
Januar 2010 20100131
Whrend des Betriebs oder eines Projekts werden Produktrisiken, Fehlerzustnde, Testflle und Fehlerzustnde, berdeckungsgrad auf spezielle Art und Weise gemessen und berichtet (Testfortschrittsbericht). Die Messungen sollten mit den im Testkonzept definierten Testendekriterien verknpft sein. Vertrauen in der Softwarequalitt, auch wenn es durch Umfragen messbar ist, wird normalerweise subjektiv , berichtet. Mgliche Metriken fr Produktrisiken sind Anzahl der Restrisiken einschlielich Art des Risikos und Risikostufe Anzahl der geminderten Risiken einschlielich Art des Risikos und Risikostu Risikostufe Mgliche Metriken fr Fehler sind Gesamtzahl der gemeldeten (identifizierten) gegenber der Gesamtzahl behobener (abgeschlossener) Fehlerzustnde durchschnittliche Zeit zwischen dem Auftreten von Fehlerwirkungen Analyse der Anzahl Fehlerzustnde, bezogen auf bestimmte Testobjekte oder Komponenten; bezogen Ursachen, Quellen; Testversionen; Phasen, in denen sie eingefhrt, festgestellt oder entfernt wurden, und in einigen Fllen Eigentmer der Fehlermeldung Trends bei der Dauer zwischen Eingehen der Fehlermeldung und Behebung Mgliche Metriken fr Tests sind Gesamtzahl geplanter, spezifizierter (entwickelter), durchgefhrter, bestandener/nicht bestandener, blockierter und ausgelassener Tests Status der Regressions- und Fehlernachtests Anzahl fr das Testen geplanter gegenber tatschlich geleisteten Stunden pro Tag geplanter Mgliche Metriken fr die Testberdeckung sind Anforderungsberdeckung und berdeckung der entwickelten Komponenten Risikoberdeckung Testumgebungs-/Konfigurationsberdeckung /Konfigurationsberdeckung Die Messungen knnen in Textform, tabellarisch oder graphisch berichtet werden, und lassen sich fr orm, verschiedene Zwecke nutzen, beispielsweise: Analysen, um anhand der Testergebnisse herauszufinden, was mit dem Produkt, im Projekt oder Prozess geschieht Berichte, um die Testergebnisse an Projektmitglieder und Betroffene zu kommunizieren Teststeuerung, um den Verlauf eines Tests oder auch des Projekts als Ganzes zu ndern und um die Ergebnisse der Kurskorrektur zu berwachen Wie die Messwerte der Tests geeignet gesammelt, analysiert und berichtet werden, hngt vom und spezifischen Informationsbedarf ab, sowie den Zielen und den Fhigkeiten der Adressaten, die diese , Messungen nutzen. Wenn der Steuerungsaufwand eines Projekts anhand der Testergebnisse gemessen oder beeinflusst werden soll, bestehen folgende Mglichkeiten: stehen Qualittsrisikoanalyse, Testprioritten und/oder Testkonzepte berarbeiten weitere Ressourcen bereitstellen oder den Testaufwand der vorhandenen Ressourcen erhhen Auslieferungstermin verschieben Testendekriterien abschwchen oder verschrfen Die Umsetzung erfordert normalerweise Konsens unter den Projektmitarbeitern und Betroffenen im Unternehmen sowie die Zustimmung von Projektmanagern oder Geschftsfhrung. Version 2007 Seite 51 von 136 Januar 2010 20100131
Wie der Testbericht strukturiert ist, hngt weitgehend von den Adressaten ab, beispielsweise Adressaten Projektmanagement oder Geschftsfhrung. Projektmanagerin oder Projektmanager interessieren sich wahrscheinlich fr ausfhrliche Informationen zu Fehlerzustnden, whrend das Hauptinteresse der Geschftsfhrung bei Informationen ber den Status der Produktrisiken liegen drfte. ber IEEE Standard 829 Standard for Software Test Documentation liefert eine Dokumentvorlage fr einen zusammenfassenden Testbericht. Bei Abweichungen vom Testkonzept sollte die Teststeuerung auf Basis des Testfortschrittsberichts Testfortschrittsberichts eingreifen, um Abweichungen zu minimieren. Folgende Steuerungsmanahmen sind mglich: Testfallpriorisierung berdenken zustzliche Ressourcen beschaffen Release-Termin verschieben ermin Projektumfang (Funktionalitt) ndern Testendekriterien berdenken (nur mit Zustimmung der Betroffenen) n Betroffenen).
3.7 Geschftswert des Testens

Zwar halten die meisten Unternehmen das Testen fr in gewisser Weise wertvoll, aber nur wenige Manager, Testmanager eingeschlossen, knnen diesen Wert quantifizieren, beschreiben oder in nager Worte fassen. Viele Testmanager, Testleiter und Tester konzentrieren sich vor allem auf die Ausfhrungsdetails des Testens (Aspekte, die die konkrete Aufgabe oder Teststufe betref spekte, betreffen), lassen aber die bergeordneten strategischen Gesichtspunkte auer Acht, fr die sich andere Projektbeteiligte interessieren, vor allem Manager. Das Testen bringt dem Unternehmen, dem Projekt und/oder dem Betrieb Nutzen, quantitativ wie qualitativ: Der quantitative Nutzen des Testens liegt darin, dass es Fehler vor einer Freigabe vermeidet oder behebt, Fehler vor der Freigabe bekannt macht, Risiken durch die Tests vermindert und r Informationen ber den Projekt Prozess- und Produktstatus liefert. Projekt-, Der qualitative Nutzen des Testens liegt in gesteigerter Reputation fr Qualitt, reibungsloseren und besser berechenbaren Releases, neuem und/oder gesteigertem Vertrauen in die Software, Schutz vor Haftungsansprchen sowie im Reduzieren des Risikos, , ganze Auftrge oder sogar Menschenleben zu verlieren. ftrge Testmanager und Testleiter sollten verstehen, wo der relevante geschftliche Nutzen fr ihr Unternehmen, ihr Projekt und/oder den Betriebsablauf liegt, und sie sollten anderen diesen geschftlichen Nutzen des Testens vermitteln knnen. estens Eine bewhrte Methode fr die Messung von quantitativem Nutzen und Effizienz des Testens ist in dem Begriff Qualittskosten zusammengefasst (manchmal auch als Kosten schlechter Qualitt bezeichnet). Die Qualittskosten fassen Proj Projekt- oder Betriebskosten in drei Kategorien zusammen: 1. Kosten fr die Vorbeugung 2. Kosten fr die Aufdeckung 3. Kosten fr die interne Fehlerwirkungen 4. Kosten fr die externe Fehlerwirkungen Die Gesamtkosten fr die Vorbeugung und fr die Aufdeckung sind meist weniger als die Kosten der Fehlerwirkungen; das Testen ist deshalb auerordentlich wertvoll. Testmanager und Testleiter haben berzeugende wirtschaftliche Argumente fr das Testen, wenn sie die Kosten in diesen Kategorien aufzeigen knnen. Version 2007 Seite 52 von 136 Januar 2010 20100131
3.8 Verteiltes Testen, Outsourcing und Insourcing ,

Oft besteht das Testteam, das den gesamten Testaufwand leistet, nicht nur aus Mitarbeitern des Projektteams und arbeitet nicht am selben Ort wie das Projektteam. Beim Testen an mehreren Standorten spricht man von verteiltem Testen. Wenn Personen an einem oder mehreren Standorten testen, die nicht Mitarbeiter des Projektteams sind und nicht an seinem Standort arbeiten, spricht man von Outsourcing. Wenn Personen testen, die nicht Mitarbeiter des Projektteams sind, aber am selben Standort arbeiten, dann spricht man von Insourcing. Alle drei Arten der Testorganisation brauchen klare Kommunikationswege und gut definierte und Erwartungen an Ziel, Aufgaben und Arbeitsergebnisse. Das Projektteam kann sich dabei kaum auf informelle Kommunikationswege verlassen, wie Gesprche unter Kollegen im Flur, oder auf auerbetriebliche soziale Kontakte. Unterschiedliche Standorte, Zeitzonen, kulturelle und sprachliche Standorte, Verschiedenheit machen die Zusammenarbeit kritisch. Alle drei Arten der Testorganisation mssen auch ihre Methodiken angleichen. Wenn zwei Testteams verschiedene Methoden anwenden, oder wenn das Testteam eine andere Methode als die andere Entwicklungsabteilung oder die Projektleitung benutzt, fhrt das besonders bei der Testdurchfhrung zu gravierenden Problemen. Beim Testen an verschiedenen Standorten muss die Aufteilung explizit und intelligent festgelegt sein. Auch die kompetenteste und hoch qualifizierte Gruppe kann ohne solche Vorgaben die Testa ie Testarbeit nicht erfolgreich durchfhren. Die Testarbeit wird Lcken (mit steigendem Restrisiko fr die Qualitt bei Auslieferung) und berlappungen haben (was die Effizienz verri verringert). Letztlich ist fr alle drei Arten der Testorganisation entscheidend, dass das ganze Projektteam das Vertrauen entwickelt und behlt, dass jedes Testteam seine Rollen richtig ausfhrt, auch angesichts von organisatorischen, kulturellen, sprac sprachlichen und geographischen Grenzen. Ein Mangel an n Vertrauen kann dazu fhren, dass durchgefhrte Aktivitten berdurchschnittlich kontrolliert werden und kann die Entwicklung von effektiven Testmannschaften bremsen. Dabei entstehen Ineffizienzen und mgliche Schwierigkeiten bei der Einhaltung von Plnen. wierigkeiten
3.9 Risikoorientiertes Testen

3.9.1 Einfhrung in das risikoorientierte Testen
Risiko ist die Mglichkeit, dass es zu einem unerwnschten Ergebnis kommt. Ein Risiko besteht Ergebnis grundstzlich immer, wenn Probleme auftauchen, die die Produktqualitt oder den Projekterfolg mindern knnten, wie sie von Kunden, Anwendern, Beteiligten oder Betroffenen wahrgenommen werden. Wenn sich das potenzielle Problem in erster Linie auf die Produktqualitt auswirkt, dann bezeichnet m man derartige Probleme als Produktrisiken (oder Qualittsrisiken). Ein Beispiel hierfr sind Fehler aufgrund mangelnder Zuverlssigkeit, die einen Systemabsturz whrend des normalen Betrie Betriebs verursachen knnten. Wenn sich das potenzielle Problem dagegen vor allem auf den Projekterfolg auswirkt, dann bezeichnet man derartige Probleme als Projektrisiken (oder Planungsrisiken). Ein Beispiel hierfr wre eine Personalknappheit, die den Abschluss des Projekts verzgert. Abschluss Nicht alle Risiken geben gleich viel Anlass zu Besorgnis. Unterschiedliche Faktoren beeinflussen die Risikostufe: die Wahrscheinlichkeit, dass das Problem auftreten wird die Auswirkungen, die das Problem haben wird, falls es auftr auftritt.
Version 2007
Seite 53 von 136
Januar 2010 20100131
Beim risikoorientierten Testen begegnet man dem Risiko auf drei verschiedene Arten: Der Aufwand muss der Risikostufe der identifizierten Produkt oder Qualittsrisiken Produktangemessen sein. Es sind Umfang des Testaufwands, Wahl der Testverfahren, Ablauf d . der Testaktivitten und Beheben der Fehlerzustnde zu beachten. Planung und Management der Testaktivitten mssen geeignet sein, jedes wesentliche identifizierte Projekt- oder Planungsrisiko zu beherrschen und auch auf unerwartete Ereignisse angemessen zu reagieren. Testergebnisse und Projektstatus in den Berichten mssen auf die Restrisiken verweisen; wenn beispielsweise Tests noch nicht durchgefhrt oder ausgelassen wurden, oder wenn Fehler noch nicht behoben oder noch nicht nachgetestet wurden. Tester sollten dem Risiko mit diesen drei Reaktionen nicht nur zu Beginn und Ende des Projekts, llten sondern whrend des gesamten Softwarelebenszyklus begegnen. Im Verlauf des Projekts sollten sie vor allem dadurch die Risiken reduzieren, dass sie die wichtigsten Fehler (bei Produktrisiken) entdecken, und dass sie geeignete Manahmen zur Risikobeherrschung und Vorkehrung gegen Risiken so umsetzen, wie in der Teststrategie und im Mastertestkonzept vorgesehen; und Auswirkungen Risiken so bewerten, dass sie Wahrscheinlichkeit oder Auswirkungen der bereits identifizierten und analysierten Risiken so erhhen oder vermindern, wie es Informationen und Erkenntnisse aus dem Projektverlauf nahe legen. In beiden Fllen beeinflussen die Manahmen, wie das Testen auf das Risiko reagiert. Risikoorientiertes Testen hat vieles gemeinsam mit einer Versicherung. Man kauft dann eine entiertes Versicherung, wenn man sich Sorgen ber ein potentielles Risiko macht, und man ignoriert Risiken, ber die man sich keine Sorgen macht. Quantitative Analysen, wie sie im Versicherungsgeschft Versicherungsgeschft blich sind, knnen anwendbar sein, beim risikoorientierten Testen verlassen die Tester sich aber meist auf qualitative Analysen. Fr fachgerechtes risikoorientiertes Testen sollten die Tester typische Produkt und Projektrisiken Produktidentifizieren, analysieren und beherrschen knnen, sei es im Zusammenhang mit der zieren, Betriebssicherheit, geschftlichen und wirtschaftlichen Aspekten, System und Datensicherheit sowie Systemmit technischen und geschftspolitischen Faktoren.
3.9.2 Risikomanagement
Das Risikomanagement besteht aus drei Hauptaktivitten: 1. Risikoidentifikation 2. Risikoanalyse und bewertung 3. Risikobeherrschung (auch als Risikosteuerung bezeichnet) An sich folgen diese Aktivitten aufeinander. Weil aber ein kontinuierliche Risikomanagement Risikomanagement notwendig ist, wie in den vorigen und nachfolgenden Abschnitten erwhnt, sollten alle drei Arten von Risikomanagement iterativ fast whrend des ganzen Projekts eingesetzt werden. Risikomanagement ist am effektivsten, wenn alle Betroffenen im Projekt daran beteiligt werden. Manchmal werden Betroffene auch vertreten. Bei der Entwicklung von Standard-Software fr den Software Massenmarkt kann es beispielsweise eine kleine Gruppe mglicher Kunden sein, die dabei hilft, die Fehler auszumachen, die ihre Nutzung der Software am meisten beeintrchtigen wrden. Diese Nutzung Gruppe mglicher Kunden steht dann fr den gesamten mglichen Kundenkreis. Wegen ihres speziellen Fachwissens sollten die Test Analyst Analystes aktiv an Risikoidentifikation und Risikoanalyse beteiligt werden. Version 2007 Seite 54 von 136 Januar 2010 20100131
3.9.2.1 Risikoidentifikation Tester knnen sowohl die Produktrisiken als auch die Projektrisiken durch ein oder mehrere der folgenden Verfahren identifizieren: Experten-Interviews unabhngige Bewertungen Verwendung von Risiko-Vorl Vorlagen Erfahrungen aus dem Testen (beispielsweise Besprechungen beim Projektabschluss) Risiko-Workshops (beispielsweise mit Fehler-Mglichkeits- und Einfluss-Analyse ( Workshops Analyse (FMEA), siehe Abschnitt 3.10) Brainstorming Checklisten Erfahrungen aus der Vergangenheit ngen Je breiter die Basis der Betroffenen im Risikoidentifikations-Prozess ist, desto hher die Prozess Wahrscheinlichkeit, dass dabei die grtmgliche Menge an wichtigen Risiken auf deckt wird. aufgedeckt Bei manchen Vorgehensweisen zur Risikoidentifikation endet der Prozess schon mit Identifizierung Risikoidentifikation des eigentlichen Risikos. Andere Verfahren, beispielsweise die Fehler-Mglichkeits- und Einfluss-Analyse (FMEA), gehen weiter. Hier mssen fr jede potenzielle Fehlerwirkung die Auswirkungen auf das rest restliche System (einschlielich bergeordneter Systeme bei Multisystemen) und auf mgliche Anwender des Systems identifiziert werden. Wieder andere Verfahren, beispielsweise die Gefhrlichkeitsanalyse, erfordern eine Annahme ber die Risikoquelle. Weitere Informationen zu Fehler Fehler-Mglichkeits- und Einfluss-Analyse (FMEA) sowie SoftwareFehlermglichkeits-, Einfluss- und Kritikalitts Kritikalitts-Analyse (FMECA) enthalten Abschnitt 3.10 sowie [Stamatis95], [Black02], [Craig02], [Gerrard02]. 3.9.2.2 Risikoanalyse und -bewertung bewertung Whrend es bei der Risikoidentifikation darum geht, mglichst viele vorhandene Risiken zu identifizieren, befasst sich die Risikoanalyse mit der Untersuchung der identifizierten Risiken. Sie kategorisiert das Risiko und legt Eintrittswahrscheinlichkeit und -wirkungen fest. ko Risiken zu kategorisieren bedeutet eine Einteilung in Risikotypen. ISO Standard 9126 fr Qualittsmerkmale behandelt typische Qualittsrisiken die eine Klassifizierung von Risiken Qualittsrisiken, untersttzen. Manche Organisationen arbeiten mit eigenen Qualittsmerkmalen. Hinweis: Bei einer Risikoidentifikation auf Basis von Checklisten wird oft beim Identifizieren das Risiko einem bestimmten Risikotyp zugeordnet. Fr die Festlegung der Risikostufe werden fr jedes einzelne Risiko die Eintrittswahrscheinlichkeit und jedes die Auswirkung (Schadenshhe, damit verbundener Schaden) eingeschtzt. Eintrittswahrscheinlichkeit (Wahrscheinlichkeit des Auftretens, Auftrittswahrscheinlichkeit) bezeichnet oft die Wahrscheinlichkeit, dass das potenzielle Problem im getesteten System vorhanden ist. Es geht t, also um ein technisches Risiko. Folgende Faktoren beeinflussen das technische Risiko: Komplexitt der Technologie und des Teams Ausbildung und Erfahrung der Testbeteiligten (z.B. Mitarbeiter von Fachbereichen, Systementwickler, Programmierer Konflikte im Team vertragliche Probleme mit Zulieferern Seite 55 von 136 Januar 2010 20100131
Version 2007
rumlich verteilte Entwicklungsorganisation Altsysteme versus neue Herangehensweisen Werkzeuge und Technologie schlechte organisatorische oder technische Leitung che Zeitdruck, knappe Ressourcen, Druck durch das Management Fehlen eines bisherigen Qualittsmanagements hufige nderungen hohe bisherige Fehlerraten Schnittstellen-/Integrationsproblematik /Integrationsproblematik Die Auswirkung bezeichnet oft das Ausma der Wirkung auf Anwender, Kunden oder andere Ausma Betroffene. Es geht also um ein Geschftsrisiko. Folgende Faktoren beeinflussen das geschftliche Risiko: Hufigkeit der Nutzung bei einer betroffenen Funktion Schaden fr die Reputation entgangene Geschfte mgliche finanzielle, kologische oder soziale Verluste oder Haftungsansprche zivil- oder strafrechtliche Manahmen Aberkennung der Lizenz fehlende vernnftige Lsungsalternativen das negative Erscheinungsbild, wenn Mngel bekannt werden Die Risikostufe lsst sich entweder quantitativ oder qualitativ betrachten. Wenn e Risikowahrscheinlichkeit und auswirkungen quantitativ bestimmt werden knnen, ergibt ein einfaches auswirkungen Multiplizieren der beiden die Kosten einer Gefhrdung, also den erwarteten Verlust bei ei einem bestimmten Risiko. In der Regel lsst die Risikostufe sich aber nur qualitativ bestimmen. Dabei kann die Wahrscheinlichkeit zwar mit sehr hoch, hoch, mittel, gering oder sehr gering angegeben werden; aber es lsst sich nicht genau sagen, ob sie bei 90%, 75%, 50%, 25%, oder 10% liegt. Trotzdem ist diese 90%, Vorgehensweise nicht weniger wertvoll als die quantitative Methode. Wenn das quantitative Vorgehen nicht fachgerecht eingesetzt wird; knnte es vielmehr die Betroffenen darber tuschen, inwieweit Risiko sich tatschlich verstehen und managen lsst. Informelle Vorgehensweisen, wie in [vanVeenendaal02], [Craig02] und [Black07b] beschrieben, sind oft qualitativ und weniger rigoros. Wenn die Risikoanalyse nicht auf umfangreichen und statistisch korrekten Risikodaten beruht, wie im Risikodaten Versicherungsbereich, dann wird sie, ob quantitativ oder qualitativ, immer auf der jeweiligen Wahrnehmung von Risikowahrscheinlichkeit und -auswirkungen basieren. Persnliche Wahrnehmung auswirkungen und Auffassungen ber die Faktoren werden die Einstufung des Risikos beeinflussen. Projektmanager, Programmierer, Anwender, Fachanalytiker, Systemarchitekten und Tester haben unterschiedliche Wahrnehmungen und deshalb vielleicht auch ganz andere Ansichten ber die Risikostufe des jeweiligen Risikos. Die Risikoanalyse sollte deshalb Wege vorsehen, wie Konsens zu Die erreichen ist, oder im ungnstigsten Fall die gltige Risikostufe anzuordnen ist. Nur dann knnen die Risikostufen eine Richtschnur fr die Aktivitten zur Risikobeherrschung bieten. 3.9.2.3 Risikobeherrschung Nachdem ein Risiko identifiziert und analysiert wurde, gibt es vier Mglichkeiten damit umzugehen:
2
Gebruchliche Synnonyme in diesem Kontext: Risikovermeidung, Risikosteuerung und bewltigung, Risikoberwachung Version 2007 Seite 56 von 136 Januar 2010 20100131
1. das Risiko durch vorbeugende Manahmen beherrschen, um Risikowahrscheinlichkeit und/oder auswirkungen zu minimieren auswirkungen 2. Notfallplne, um die mglichen Auswirkungen bei einem Auftreten des Risikos zu reduzieren 3. das Risiko an eine andere Partei auslagern 4. das Risiko akzeptieren und nicht weiter beachten Welche dieser Optionen tatschlich gewhlt wird, hngt sowohl von den Vorteilen und Chancen jeder Vorteilen Option, als auch von ihren Kosten und mglichen Folgerisiken ab. Strategien zur Risikobeherrschung Grundlage des Mastertestkonzepts und anderer Testplne bei den meisten risikoorientierten Teststrategien sind Risikoidentifizierung, Risikoanalyse und das Festlegen von Aktivitten zur Risikobeherrschung. Die Risikostufe fr das jeweilige Risiko entscheidet ber den Umfang des Testaufwands, der zur Risikobeherrschung verwendet wird. An der Sicherheit orientierte Standards, icherheit wie FAA DO-178B/ED 12B oder IEC 61508, schreiben Testverfahren und Grad der berdeckung je nach Risikostufe vor. Beherrschung von Projektrisiken Wenn Projektrisiken identifiziert wurden, mssen die Projektmanager eventuell darber informiert Projektmanager werden und handeln. Nicht alle Risiken lassen sich innerhalb der Testorganisation durch entsprechende Manahmen reduzieren. Es gibt aber auch Projektrisiken, die die Testmanager erfolgreich steuern knnen: einsatzbereite Testumgebung und Werkzeuge te Verfgbarkeit und Qualifikation des Testpersonals schlechte Testbasis zu hohe nderungsrate an der Testbasis fehlende Standards, Regeln und vorgeschriebene Verfahren fr das Testen Zum Vorgehen bei der Risikobeherrschung gehren eine frhe Vorbereitung der Testmittel, gehren Vorabtests der Testausstattung, Vorabtests frherer Produktversionen, strengere Testeingangsbedingungen, Anforderungen an die Testbarkeit, Teilnehmen an Reviews frherer Projektergebnisse, Teilnehmen am Problem und nderungsmanagement, berwachung des Problem- nd Projektfortschritts und der Qualitt. Beherrschung von Produktrisiken Das Testen ist eine Art der Risikobeherrschung fr Produkt und Qualittsrisiken. Wenn die Tester ProduktFehler finden, reduzieren sie das Risiko, weil sie das Bewusstsein fr vorhandene Fehler schrfen sie und die Mglichkeit schaffen, sie vor Release des Systems zu beheben. Wenn die Tester keine Fehler finden, reduzieren sie beim Testen das Risiko, denn sie stellen sicher, dass das System unter bestimmten (den getesteten) Bedingungen richtig funktioniert. en Produkt- oder Qualittsrisiken lassen sich auch durch Aktivitten steuern, die nicht im eigentlichen Sinne Testaktivitten sind. Wird beispielsweise festgestellt, dass die Anforderungen nicht gut spezifiziert sind, dann sind grndliche Reviews sicher ein geeignetes Mittel zur Risikobeherrschung. t Sie sind weitaus effizienter als das Entwerfen und Priorisieren von Tests, die erst dann durchgefhrt werden, wenn eine schlecht spezifizierte Software entwickelt und in Code umgesetzt wurde. Die Risikostufe wird auch fr die Priorisierung der Tests verwendet. Manchmal werden alle hohen Risikostufen vor den niedrigeren Risikostufen getestet, und die Tests erfolgen streng nach der Reihenfolge der Risikos (Depth-first, d.h. Testen in die Tiefe). In anderen Fllen machen die Tester first, d.h. Stichproben von identifizierten Risiken aller Risikostufen, gewichten die Risiken und whlen Tests aus, wobei sie dafr sorgen, dass jedes Risiko mindestens einmal abgedeckt wird (Breadth (Breadth-first, d.h. Testen in die Breite). Version 2007 Seite 57 von 136 Januar 2010 20100131
Weitere Aspekte der Risikobeherrschung sind die Auswahl eines geeigneten Testentwurfsverfahrens Reviews und Inspektionen Review des Testentwurfs Unabhngigkeitsgrad der Testorganisation die erfahrenste Person wird eingesetzt wie Fehlernachtests durchgefhrt werden e Regressionstests In [Gerrard02] wird das Konzept der Testeffektivitt als (prozentualer) Indikator dafr eingefhrt, wie effektiv das Testen fr die Risikobeherrschung eingeschtzt wird. Demnach wrde man das Testen nicht als eine Manahme zur Risikobeherrschung einsetzen, wenn es nur wenig effektiv ist. icht Unabhngig davon, ob beim risikoorientierten Testen in die Tiefe oder in die Breite getestet wird, ist es mglich, dass die Zeit fr das Testen abluft, ohne dass alle Tests durchgefhrt wurden. Beim risikoorientierten Testen knnen die Tester in solchen Fllen das Management ber das verbleibende Restrisiko informieren, und das Management kann entscheiden, ob dieses Restrisiko an die Anwender, Kunden, Helpdesks oder technische Untersttzung und/oder an das Bedienpersonal technische weitergegeben wird. Anpassung des Testens an weitere Testzyklen Wenn noch Zeit fr weitere Tests zur Verfgung steht, dann sollten zustzliche Testzyklen auf Basis einer neuen Risikoanalyse erfolgen. W ichtige Faktoren dafr sind mgliche neue oder deutlich Wichtige vernderte Produktrisiken, instabile oder fehleranfllige Bereiche des Systems, die im Laufe des Testens identifiziert wurden, Risiken als Folge behobener Fehler, eine Konzentration auf Fehler, die sich beim Testen als typische Fehler herausgestellt haben, sowie nicht ausreichend getestete ch Bereiche des Systems (Bereiche mit niedriger Testberdeckung). Die Planung neuer oder zustzlicher Testzyklen sollte auf einer Analyse derartiger Risiken basieren. Es ist auerdem sehr empfehlenswert, Es zu jedem Meilenstein eine aktualisierte Risikoeinschtzung zu erstellen.
3.9.3 Risikomanagement im Softwarelebenszyklus

Im Idealfall begleitet das Risikomanagement den gesamten Softwarelebenszyklus. Gibt es eine Softwarelebenszyklus. Testrichtlinie und/oder eine Teststrategie in einer Organisation, dann sollten sie den grundlegenden Prozess beschreiben, nach dem Produkt und Projektrisiken im Testen behandelt werden. Sie sollten Produktzeigen, dass Risikomanagement integraler Bestandteil aller Teststufen ist, und wie es sie beeinflusst. Die Aktivitten zur Risikoidentifikation und analyse knnen whrend des Anfangsstadiums eines analyse Projekts beginnen, unabhngig vom Lebenszyklusmodell der Softwareentwicklung. Manahmen zur Risikobeherrschung lassen sich als Teil des gesamten Testplanungs Prozesses planen und Testplanungs-Prozesses umsetzen. Im Mastertestkonzept und/oder in den Teststufenplnen knnen sowohl Projekt als auch ProjektProduktrisiken bercksichtigt werden. Art des Risikos und Risikostufe beeinflussen dann die Teststufen fr das Risiko, den Umfang des zur Risikobeherrschung verwendeten Testaufwands, Test Testund andere verfahren zur Risikobeherrschung, und die Kriterien, nach denen beurteilt wird, ob die verfahren Manahmen zur Risikobeherrschung ausr ausreichend waren. Nachdem die Planungsphase abgeschlossen ist, sollte das Risikomanagement einschlielich Risikoidentifikation, -analyse und reduzierung ein fortlaufender Prozess whrend des gesamten reduzierung Projekts sein. Es schliet die Identifikation neuer Risiken, erneutes Bewerten der Risikostufen fr Risiken, bestehende Risiken und die Bewertung ein, ob Risikobeherrschungsmanahmen effektiv waren. Ein Beispiel: Wurden whrend der Anforderungsanalyse Risikoidentifikation und analyse auf Basis der analyse Anforderungsspezifikation durchgefhrt, dann sollten die Risiken nach Vorliegen des Systementwurfs on neu bewertet werden. Ein weiteres Beispiel: Falls beim Testen weit mehr Fehler in einer Komponente Version 2007 Seite 58 von 136 Januar 2010 20100131
gefunden wurden als erwartet, dann kann man annehmen, dass die Fehlerwahrscheinli Fehlerwahrscheinlichkeit in diesem Bereich hher ist als angenommen und Wahrscheinlichkeit und Risikostufe nach oben korrigieren. Fr diese Komponente knnte das zu einem erhhten Testaufwand fhren. Nachdem die Risikoidentifikation und analyse abgeschlossen sind und Mana analyse Manahmen zur Risikobeherrschung greifen, ist messbar, wie weit die Risiken reduziert wurden. Dazu werden die Testflle und aufgedeckten Fehlerzustnde auf die dazugehrigen Risiken zurckverfolgt Die Tester zurckverfolgt. knnen whrend der Tests und beim Aufdecken von Fehlern das Restrisiko feststellen Damit Fehlern feststellen. untersttzt das risikoorientierte Testen bei der Festlegung des richtigen Zeitpunkts fr die Freigabe Freigabe. [Black03] enthlt ein Beispiel fr die Berichterstattung von Testergebnissen basierend auf der Risikoberdeckung. Aus den Testberichten sollten kontrollierte und noch offene Risiken, sowie erzielter und noch ausstehender Nutzen hervorgehen.
3.10
FMEA (Fehler-Mglichkeits und Einfluss-Analyse) Mglichkeits-
Die Fehlermglichkeits- und Einfluss Einfluss-Analyse (FMEA, Failure Mode and Effects Analysis) sowie die Variante Fehlermglichkeits-, Einfluss und Kritikalitts-Analyse (FMECA, Failure Mode Effects and , EinflussMode, Criticality Analysis), die eine Kritikalittsanalyse einschliet, sind iterative Aktivitten zur Analyse von , einschliet, Auswirkung und Kritikalitt der Fehlerzustnde im System. Wenn Software damit analysiert wird, heien sie auch SFMEA und SFMECA, wobei das S fr Software steht. Die Informationen in den folgenden Abschnitten gelten auch fr die drei anderen Methoden, es wird aber immer die Abkrzung en FMEA benutzt. Tester sollen zum Erstellen von FMEA Dokumenten beitragen knnen. Dazu mssen sie Zweck und FMEA-Dokumenten Anwendung dieser Dokumente verstehen und ihr Fachwissen zur Bestimmung von Risikofaktoren einbringen.
3.10.1

Anwendungsbereiche
wenn die Kritikalitt der Software oder des Systems analysiert werden muss, um das Fehlerrisiko zu reduzieren (beispielsweise bei sicherheitskritischen Systemen wie Flugzeug sicherheitskritischen FlugzeugSteuerungssystemen). wenn obligatorische oder gesetzliche Anforderungen gelten (siehe Abschnitt 1.3.2 Sicherheitskritische Systeme rheitskritische Systeme). um Fehler in einem mglichst frhe Stadium zu beseitigen. frhen um fr sicherheitskritische Systeme spezielle Erwgungen beim Testen, Einschrnkungen beim Betrieb und designrelevante Entscheidungen zu definieren.
Die FMEA sollte angewendet werden,
3.10.2
FMEA durchfhren
Eine FMEA sollte eingeplant werden, sobald vorlufige Informationen auf bergeordneter Ebene sobald verfgbar sind, und, sobald Details verfgbar werden, auf niedrigere Ebenen erweitert werden. Die FMEA kann auf jeder System- oder Softwareebene angewendet werden, je nach verfgbaren Informationen und Programmanforderungen. Dabei werden iterativ fr jede kritische Funktion, Modul oder Komponente eine Funktion ausgewhlt und ihre Fehlermglichkeiten festgestellt, beispielsweise, wie sie fehlschlagen knnte
Version 2007
Seite 59 von 136
Januar 2010 20100131
mgliche Ursachen fr die Fehlerwirkung definiert und die Folgen dargestellt; und definiert Mechanismen zur Reduktion oder Beherrschung der Fehlerwirkungen entworfen.
3.10.3
Kosten und Nutzen
FMEA bietet folgende Vorteile: Erwartete Systemausflle durch Fehlerwirkungen der Softwareausflle oder Anwendungsfehler lassen sich aufdecken. Wird sie systematisch eingesetzt, kann sie zur Analyse auf Ebene des Gesamtsystems beitragen. Ergebnisse knnen zu Entwurfsentscheidungen und/oder begrndungen beitragen. begrndungen Ergebnisse knnen verwendet werden, um bestimmte (kritische) Bereiche der Software besonders intensiv zu testen. Folgende Aspekte sind bei der Anwendung der FMEA zu bercksichtigen bercksichtigen: Mgliche Folgefehler werden selten beachtet. Es kann viel Zeit kosten, die FMEA FMEA-Tabellen zu erstellen. Es kann schwierig sein, unabhngige Funktionen zu definieren. chwierig Es kann schwierig sein, die Fehlerfortpflanzung zu identifizieren.
3.11
3.11.1
Besonderheiten beim Testmanagement

Testmanagement beim explorativen Testen
Session-based Testmanagement (SBTM) ist ein Managementkonzept fr exploratives Testen. Eine (SBTM) Session (Testsitzung) ist die grundlegende Testeinheit; die Tester konzentrieren sich d dabei mit einem bestimmten Testziel (Test-Charta) ohne Unterbrechung auf ein spezifisches Testobjekt. Am Ende jede ) einzelnen Testeinheit erstellen sie einen Bericht ber die in der Testsitzung durchgefhrten Aktivitten (Session Sheet). SBTM arbeitet mit einer strukturierten Testdokumentation und erzeugt Protokolle, die ). die Verifizierungsdokumentation ergnzen. Eine Testeinheit lsst sich in drei Stufen unterteilen: Testeinheit aufbauen: Einrichten der Testumgebung und besseres Kennenlernen des Produkts Test entwerfen und durchfhren: Untersuchen des Testobjekts und Problemsuche Fehleranalyse und Bericht: Sie beginnen, sobald ein Tester auf etwas stt, das eine Fehlerwirkung sein knnte. Das SBTM Session Sheet besteht aus: ht Test-Charta Name des oder der Tester Datum und Uhrzeit des Beginns Aufteilen der durchgefhrten Aufgaben in Testeinheiten oder Testsitzungen Testdatendateien Testnotizen Probleme Fehlerwirkungen
Version 2007
Seite 60 von 136
Januar 2010 20100131
Am Ende jeder Testsitzung hlt der Testmanager eine Abschlussbesprechung mit dem Testteam. Dabei findet ein Review der Session Sheets statt, die Chartas werden verbessert, das Testteam teilt seine Eindrcke mit und der Manager schtzt und plant weitere Testsitzungen. Die Tagesordnung fr eine solche Abschlussbesprechung lsst sich mit dem englischen Begriff Abschlussbesprechung PROOF abkrzen: Past: Was passierte in der abgelaufenen Testsitzung? ast: Results: Welche Ergebnisse wurden erzielt? esults: Outlook: Vorschau; was ist noch zu tun? utlook: Obstacles: Welche Hrden fr gutes Testen gab es? bstacles: Feelings: Was denken oder fhlen die Tester in diesem Zusammenhang? eelings:
3.11.2
Testmanagement bei Multisystemen

Testmanagement ist komplexer, denn mglicherweise werden die einzelnen Systeme, aus denen das Multisystem besteht, an unterschiedlichen Standorten getestet, von unterschiedlichen Organisationen und mit unterschiedlichen Lebenszyklusmodellen. Deshalb sieht das Mastertestkonzept fr ein Multisystem in der Regel ein formelles Lebenszyklusmodell vor und legt besonderen Wert auf Managementaspekte, wie Meilensteine oder Quality-Gates. Oft gibt es einen formalen Qualittssicherungs Prozess, der in einem Gates. Qualittssicherungs-Prozess, eigenen Qualittsplan definiert ist. Untersttzende Prozesse, wie Konfigurationsmanagement, nderungs und Releaseersttzende nderungsManagement mssen formal definiert und die Schnittstellen zum Testmanagement vereinbart werden. Diese Prozesse sind unverzichtbar, damit die Softwarelieferungen kontrolliert erfolgen, nderungen systematisch eingebracht werden und die Referenzkonfiguration der zu n, testenden Anwendungen richtig definiert ist. Es kann eine groe technische und organisatorische Herausforderung sein, reprsentative Testumgebungen einschlielich der Testda Testdaten zu erstellen und verwalten. Mglicherweise mssen Simulatoren fr die Teststrategie beim Integrationstest entwickelt werden. Fr frhe Teststufen kann das relativ einfach und kostengnstig sein; Simulatoren fr ganze Systeme und die bergeordneten Integrationstests bei Multisystemen knnen aber Integrationstests komplex und teuer werden. Deshalb finden Planung, Kostenschtzung und Entwicklung von Simulatoren oft in einem separaten Projekt statt. Abhngigkeiten zwischen den Teilsystemen erzeugen zustzliche Restriktionen fr Systemund Abnahmetests; Systemintegrationstests und die zugehrigen Testbasisdokumente (beispielsweise Schnittstellenspezifikationen) gewinnen an Bedeutung.
Zum Testmanagement von Multisystemen gehren folgende Aspekte:
3.11.3
Testmanagement bei sicherheitskritischen Systemen

Normalerweise gelten die (industrie (industrie-)spezifischen Standards der jeweiligen Branche (beispielsweise Transport, Medizintechnik, Militr). Sie knnen den Entwicklungsprozess und den organisatorischen Aufbau betreffen, oder das Produkt, das entwickelt wird. Weitere n Informationen enthlt Kapitel 6. Haftung ist bei sicherheitskritischen Systemen oft ein wichtiges Thema. Deshalb knnen fr die Konformitt (den Nachweis, dass die Auflagen erfllt sind) formale Aspekte ntig sein, wie Rckverfolgbarkeit der Anforderungen, Erreichen eines bestimmten Testberdeckungsgrads, Erfllen von Abnahmekriterien und vorgeschriebene Testdokumentation. rien Seite 61 von 136 Januar 2010 20100131
Aspekte beim Testmanagement von sicherheitskritischen Systemen Systemen:
Version 2007
Konformitt bei Organisationsstruktur und Entwicklungsprozess lassen sich mglicherweise durch Organisationsdiagramme und Audits nachweisen. Es wird ein definierter Entwicklungslebenszyklus zu Grunde gelegt, je nach vorgeschriebenem nach Standard. Die Lebenszyklen sind in der Regel sequenziell. Falls das System von einer Organisation als kritisch eingestuft wurde, mssen die folgenden nicht-funktionalen Eigenschaften in der Teststrategie und/oder im Testkonzept bercks funktionalen bercksichtigt werden: Zuverlssigkeit (Reliability) eliability) Verfgbarkeit (Availability) vailability) Wartbarkeit (Maintainability) aintainability) Sicherheit des Betriebs/gegenber Angriffen ( (Safety/security) Aufgrund dieser Eigenschaften bezeichnet man solche Systeme auch als RAMS RAMS-Systeme (Abkrzung aus den Anfangsbuchstaben der englischen Begriffe). ung
3.11.4
Sonstige Besonderheiten beim Testmanagement
Wenn nicht-funktionale Tests nicht eingeplant wurden, kann das ein erhebliches Risiko fr den Erfolg funktionale einer Anwendung bedeuten. Andererseits sind viele Arten nicht funktionaler Tests mit erheblichen wendung nicht-funktionaler Kosten verbunden, deshalb sind Kosten und Risiko gegeneinander abzuwgen. Es gibt viele unterschiedliche nicht nicht-funktionale Tests. Nicht alle sind unbedingt fr eine be icht bestimmte Anwendung geeignet. Folgende Faktoren knnen die Planung und Durchfhrung nicht funktionaler Tests beeinflussen: nicht-funktionaler Anforderungen der Betroffenen bentigte Werkzeuge bentigte Hardware organisatorische Faktoren Kommunikation Sicherheit der Daten
3.11.4.1 Anforderungen der Betroffenen orderungen Nicht-funktionale Anforderungen sind oft unbekannt oder kaum spezifiziert. Die Tester mssen funktionale deshalb in der Planungsphase die Erwartungshaltungen der Betroffenen sondieren und daraufhin bewerten, welche Risiken sie fr das Projekt bedeuten. rten, Beim Ermitteln der Anforderungen sollten verschiedene Perspektiven bercksichtig werden. Sie bercksichtigt mssen die Anforderungen beispielsweise von Kunden, Anwendern, Bedien und Wartungspersonal Bedieneinholen, sonst bersehen sie mglicherweise Anforderungen. rsehen Folgende Aspekte sind wesentlich fr die Verbesserung der Testbarkeit nicht nicht-funktionaler Anforderungen: Der Aufwand fr die Spezifikation testbarer Anforderungen ist fast immer kosteneffektiv. Wichtig sind dabei eine einfache Ausdrucksweise und konsistente und richtige Terminologie, e die mit dem Projekt-Wrterbuch/Glossar bereinstimmt. Bestimmte Formulierungen sind Wrterbuch/Glossar einzuhalten: muss (ist Pflicht), sollte (ist wnschenswert) und soll (kann als Synonym fr muss verwendet werden, am besten vermeidet man es aber). et Leserinnen und Leser der Anforderungen haben unterschiedliche Hintergrnde. . Anforderungen sind klar, deutlich und unmissverstndlich zu formulieren, es sollte ein Standardformat fr die Anforderungen verwendet werden. Wann immer mglich, sollten die Tester Anforderungen quantitativ spezifizieren. Dabei ist zu entscheiden, welche Metrik fr ein bestimmtes Merkmal am besten geeignet ist Seite 62 von 136 Januar 2010 20100131
Version 2007
(beispielsweise Millisekunden fr die Messung von Leistung), und innerhalb wel welches Wertebereichs die Ergebnisse akzeptiert oder nicht akzeptiert werden. Fr bestimmte nicht nichtfunktionale Eigenschaften ist das nicht einfach (beispielsweise Benutzbarkeit). 3.11.4.2 Bentigte Werkzeuge Kommerzielle Werkzeuge oder Simulatoren sind besonders relevant fr das Messen von Leistung und Simulatoren Effizienz sowie fr einige Sicherheitstests. Die Testplanung sollte die geschtzten Kosten und Vorlaufzeiten fr die bentigten Werkzeuge bercksichtigen. Wenn Spezialwerkzeuge zum Einsatz kommen, sind damit verbundene Lernkurven oder die Kosten fr den Einsatz externer Spezialisten zu en, bercksichtigen. Einen komplexen Simulator zu entwickeln, kann zu einem eigenen Entwicklungsprojekt werden, es sollte dann auch entsprechend geplant werden. Wenn Simulatoren fr sicherheitskritische Anwendungen eingesetzt werden sollen, sind auch die entsprechenden Abnahmetests und eine etwaige Zertifizierung des Simulators durch eine unabhngige Instanz zu planen. 3.11.4.3 Bentigte Hardware Fr viele nicht-funktionale Tests wird eine produktionshnliche Testumgebung bentigt, um funktionale realistische Messungen zu ermglichen. Je nach Gre und Komplexitt des zu testenden Systems kann das Planung und Finanzierung der Tests mageblich beeinflussen. Kosten fr das Durchfhren nicht-funktionaler Tests knnen so hoch sein, dass nur begrenzt Zeit dafr zur Verfgung steht. funktionaler Will man beispielsweise die Anforderungen an die Skalierbarkeit einer stark frequentierten Internetseite verifizieren, kann dafr eine simulierte Nutzung durch Hunderttausende virtuelle Nutzer simulierte ntig sein. Das wrde die Hardware und Werkzeugkosten erheblich beeinflussen. Da derartige HardwareKosten in der Regel durch Mietlizenzen fr die bentigten Lasttestwerkzeuge minimiert werden (Aufstockung von Lizenzen), ist die verfgbare Zeit fr solche Tests begrenzt. Benutzbarkeitstests setzen mglicherweise eigens eingerichtete Versuchslabors oder zahlreiche Fragebgen voraus. Normalerweise werden diese Tests nur einmal im Entwicklungslebenszyklus eines Systems durchgefhrt. Andere nicht-funktionale Tests (beispielsweise Sicherheitstests, Performanztests) mssen in einer funktionale produktionshnlichen Testumgebung durchgefhrt werden. Da die Kosten fr solche Testumgebungen hoch sein knnen, ist die Nutzung der echten Produktionsumgebung oft die einzig praktikable Alternative. Die Durchfhrung der Tests muss dann allerdings sorgfltig geplant werden, sie knnen wahrscheinlich nur zu bestimmten Zeiten (beispielsweise nachts) stattfinden. Wenn Effizienztests durchgefhrt werden sollen (beispielsweise Performanz oder Last), sind t Hardwarekapazitten und Kommunikationsbandbreiten einzuplanen. Der Bedarf orientiert sich in erster Linie an der Zahl der simulierten virtuellen Nutzer und dem voraussichtlichen Volumen ihres Netzwerkverkehrs. Wird er nicht einbezogen, sind die Messungen nicht reprsentativ. werkverkehrs. 3.11.4.4 Organisatorische Aspekte Bei nicht-funktionalen Tests ist oft auch das Verhalten mehrerer Komponenten eines Gesamtsystems funktionalen zu messen (beispielsweise Server, Datenbanken, Netzwerke). Wenn diese Komponenten auf weise unterschiedliche Standorte und Organisationen verteilt sind, kann das erheblichen Aufwand fr die Planung und Koordinierung der Tests bedeuten. So knnen bestimmte Softwarekomponenten nur zu bestimmten Uhrzeiten oder nur an bestimmten Tagen im Jahr fr den Systemtest zur Verfgung stehen. Organisationen stellen mglicherweise nur eine begrenzte Anzahl von Tagen zur Verfgung, an denen sie das Testen untersttzen. Es kann zu empfindlichen Strungen der geplanten Tests Strungen fhren, wenn nicht im Vorfeld geklrt worden ist, dass die Systemkomponenten und das Personal der anderen Organisationen fr die Testzwecke auf Abruf bereitstehen.
Version 2007
Seite 63 von 136
Januar 2010 20100131
3.11.4.5 Kommunikationsaspekte Ob Spezifikation und Durchfhrung bestimmter nicht funktionaler Tests (vor allem Effizienztests) ion nicht-funktionaler mglich sind, kann davon abhngen, ob sich bestimmte Kommunikationsprotokolle fr die Testzwecke ndern lassen. In der Planungsphase sollte das sichergestellt werden, beisp beispielsweise mit Werkzeugen, die Kompatibilitt erzeugen. 3.11.4.6 Sicherheit der Daten Spezifische Sicherheitsmanahmen fr ein System sollten bereits in der Testplanungsphase einkalkuliert werden, damit alle vorgesehenen Testaktivitten tatschlich mglich sind. Werden beispielsweise die Daten verschlsselt, kann es schwierig sein, Testdaten zu erzeugen und die Testergebnisse zu verifizieren. Richtlinien und gesetzliche Bestimmungen zum Datenschutz schlieen mglicherweise aus, dass die Tester virtuelle Nutzer auf Basis der Produktionsdaten generieren. Es kann eine schwierige Aufgabe sein, die Testdaten zu anonymisieren, und muss als Teil der Testdurchfhrung geplant werden.
Version 2007
Seite 64 von 136
Januar 2010 20100131
4. Testverfahren
Begriffe:
anforderungsbasierter Test, , Anweisungsberdeckungstest, Anweisungsberdeckungstest, anwendungsfallbasierter Test, Test quivalenzklassenbildung, (einfacher) Bedingungsberdeckungstest BS 7925-2, Datenflussanalyse , Bedingungsberdeckungstest, , Datenflussanalyse, dynamische Analyse, EE-Pfad, Entscheidungstabellentest, Entscheidungsberdeckungstest , Entscheidungstabellentest, Entscheidungsberdeckungstest, erfahrungsbasiertes Testverfahren, exploratives Testen fehlerbasiertes Testverfahren, intuitive stverfahren, Testen, Testfallermittlung, fehlerhafter Zeiger (wilder Zeiger), Fehlertaxonomie, Grenzwertanalyse , , Grenzwertanalyse, Klassifikationsbaumverfahren , Kontrollflussanalyse LCSAJ, Mehrfachbedingungsberdeckungstest Kontrollflussanalyse, , Mehrfachbedingungsberdeckungstest, Pfadberdeckungstest, Fehlerangriffe Speicherengpass, spezifikationsorientiertes Testverfahren, , Fehlerangriffe, , statische Analyse, strukturorientiertes szenarienbasierter Test, Testsitzung, Testverfahren, Test , basierter TestCharta, Ursache-Wirkungs-Graph, zustandsbasierter Test Zweigtest Graph, Test,
4.1 Einfhrung
Kategorien fr die in diesem Kapitel behandelten Testentwurfsverfahren sind Spezifikationsorientierte Testverfa Testverfahren (auch Black-Box-Verfahren) Strukturorientierte Testverfahren (auch White White-Box-Verfahren) Fehlerbasierte Testverfahren Erfahrungsbasierte Testverfahren Die Verfahren ergnzen sich wechselseitig und knnen unabhngig von der Teststufe je nach Testaktivitt eingesetzt werden. Obwohl Test Analysts und Technical Test Analysts jedes der itt Verfahren anwenden knnen, unterscheidet dieser Lehrplan nach der blichen Arbeitsteilung: Spezifikationsorientierte Testverfahren Test Analysts und Technical Test Analyst Analysts Strukturorientierte Testverfahren Technical Test Analysts Erfahrungsbasierte Testverfahren Test Analysts und Technical Test Analysts Fehlerbasierte Testverfahren Test Analysts und Technical Test Analysts Neben diesen Verfahren beschreibt das Kapitel weitere Testverfahren, wie Fehlerangriffe, statische Kapitel Analyse und dynamische Analyse. Sie werden in der Regel von Technical Test Analysts angewendet. Hinweis: Spezifikationsorientierte Verfahren knnen entweder fr das fachliche Testen (siehe Abschnitt 5.2) oder das technische Testen (siehe Abschnitt 5.3) eingesetzt werden werden.
4.2 Spezifikationsorientierte Testverfahren

Bei spezifikationsorientierte Testverfahren werden die Testbedingungen und Testflle aus der werden Testbasisdokumentation der Komponente oder des Systems abgeleitet und ausgewhlt. Die interne Struktur von Komponente oder System bleibt unbercksichtigt. Gemeinsame Merkmale der spezifikationsorientiertem Test Testverfahren sind Die Spezifikation des zu lsenden Problems, der Software oder ihrer Komponenten beruht auf formellen oder informellen Modellen. Aus diesen Modellen knnen die Testflle systematisch abgeleitet werden. Einige Verfahren liefern Kriterien fr den berdeckungsgrad als Ma fr die Testentwurfsaufgabe. den Wenn der berdeckungsgrad vollstndig ist, heit das nicht, dass die Menge von Tests vollstndig ist. Version 2007 Seite 65 von 136 Januar 2010 20100131
Es bedeutet vielmehr, dass das Modell fr das vorliegende Testverfahren keine weiteren ntzlichen Tests bietet. Spezifikationsorientierte Tests basieren oft auf Anforderungen. Da die Anforderungsspezifikation das Systemverhalten vorgeben sollte, vor allem hinsichtlich seiner Funktionalitt, lassen sich aus den spezifizierten Anforderungen Tests ableiten, die das Verhalten des Systems prfen. Fr die oben in ableiten, diesem Abschnitt erwhnten Testverfahren lsst sich das Modell fr das Systemverhalten aus dem Text und den Grafiken der Anforderungsspezifikation ableiten. Die Tests werden auf dieser Basis durchgefhrt wie oben beschrieben. fhrt Der Advanced Level Lehrplan umfasst die folgenden spezifikationsorientierte Testentwurfsverfahren: Name Verfahren Kriterien fr die berdeckung
quivalenzklassentest Beschreibung siehe ISTQB Foundation-LevelLehrplan 2007, Abschnitt 4.3.1. Grenzwertanalyse Beschreibung siehe ISTQB Foundation-LevelLehrplan 2007, Abschnitt 4.3.2. , Hinweis: Die Grenzwertanalyse kann mit zwei oder mit drei Werten durchgefhrt werden. Die Entscheidung darber wird sich am Risiko orientieren.
berdeckte berdeckte Klassen/Gesamtzahl der quivalenzklassen
berdeckte Grenzwerte/Gesamtzahl der berdeckte Grenzwerte
Entscheidungstabellentest und Ursache Ursache-Wirkungs-Graph-Analyse Beschreibung des Entscheidungstabellentests berdeckte Kombinationen von berdeckte siehe ISTQB Foundation Foundation-Level-Lehrplan 2007, Bedingungen/Gesamtzahl der Abschnitt 4.3.3. Kombinationen von Bedingungen Beim Entscheidungstabellentest wird jede mgliche Kombination von Bedingungen, Beziehungen und Beschrnkungen getestet. Zustzlich kann auch ein Graph in logischer ustzlich Notation, der Ursache-Wirkungs Wirkungs-Graph, verwendet werden. Hinweis: Neben dem Testen aller mglichen Kombinationen von Bedingungen sind auch eingeschrnkte Tabellen mglich. Die Entscheidung darber wird sich wahrsch wahrscheinlich am Risiko orientieren [Copeland03]. Zustandsbasiertes Testen Beschreibung siehe ISTQB Foundation-LevelLehrplan 2007, Abschnitt 4.3.4. itt
Fr einfache Zustandsbergnge (Transitionen) ist das berdeckungsma der prozentuale Anteil aller gltigen, whrend des Tests ausgefhrten Transitionen. Es wird als 0 0-Switchberdeckung bezeichnet. Fr n Transitionen ist das berdeckungsma Januar 2010 20100131
Version 2007
Seite 66 von 136
Name
Verfahren
Kriterien fr die berdeckung der prozentuale Anteil aller gltigen r Folgen von n Transitionen, die whrend des Tests ausgefhrt werden. Es wird als (n-1)-Switch-berdeckung bezeichnet. berdeckung
Klassifikationsbaumverfahren, Testen mit orthogonalen Arrays und paarweises Testen , Es werden zu untersuchende Faktoren oder Kriterien hngen vom verwendeten m Variablen und die Optionen oder Werte Verfahren ab, das berdeckungsma des identifiziert, die sie annehmen knnen. Die Verfahrens Paarweises Testen Optionen oder Werte werden dann einzeln, unterscheidet sich beispielsweise von paarweise oder in Kombinationen von drei oder mbinationen dem des Klassifikationsbaum Klassifikationsbaumverfahrens. sogar mehr identifiziert. [Copeland03] Das Klassifikationsbaumverfahren setzt eine graphische Notation ein, um die Testbedingungen (-klassen) und ihre Kombinationen fr die klassen) Testflle abzubilden. [Grochtmann94] Anwendungsfallbasiertes Testen (szenarien (szenarienbasiertes Testen) Beschreibung siehe ISTQB Foundation-LevelLehrplan 2007, Abschnitt 4.3.5. , Es sind keine formalen Kriterien anwendbar.
Manchmal werden fr die Erstellung von Tests auch Verfahren kombiniert. So knnen beispielsweise die in einer Entscheidungstabelle identifizierten Bedingungen eine quivalenzklassen einer ivalenzklassenbildung unterzogen werden, um unterschiedliche Mglichkeiten herauszufinden, wie eine Bedingung erfllt werden kann. Die Tests decken dann nicht nur alle Kombinationen von Bedingungen ab, sondern es werden zustzliche Tests fr die quivalenzklassen der Bedingungen erstellt, sodass auch diese quivalenzklassen berdeckt werden.
4.3 Strukturorientierte Testverfahren

Strukturorientierte Testentwurfsverfahren heien auch White White-Box- oder codebasierte Testverfahren. Dabei verwenden die Tester Code, Daten, Architektur oder Systemfluss als Grundlage des en Testentwurfs und leiten die Tests systematisch aus der Struktur ab. Welche Elemente der Struktur bercksichtigt werden, hngt vom Verfahren ab. Das Verfahren liefert auch Kriterien f fr den berdeckungsgrad, der entscheidet, wann die Ableitung von Tests abgeschlossen werden kann. Wenn der berdeckungsgrad vollstndig ist, heit das nicht, dass die Menge von Tests vollstndig ist. Es bedeutet vielmehr, dass die untersuchte Struktur fr das vorliegende Testverfahren keine weiteren ntzlichen Tests bietet. Der berdeckungsgrad muss gemessen und mit dem Ziel verglichen werden, das fr Projekt oder Unternehmen definiert wurde. Gemeinsame Merkmale der strukturorientierte Testverfahren sind Die Testflle werden aus Informationen darber abgeleitet, wie die Software aufgebaut ist, e beispielsweise dem Code und der Struktur. Der berdeckungsgrad der Software lsst sich fr die bestehenden Testflle messen. Zustzliche Testflle lassen sich systematisch ableiten, um die berdeckung zu erhhen. systematisch
Version 2007
Seite 67 von 136
Januar 2010 20100131
Der Advanced Level Lehrplan behandelt folgende strukturorientierte Testentwurfsverfahren: Name Verfahren Kriterien fr die berdeckung
Anweisungstest Es werden alle ausfhrbaren (nicht kommentierten und nicht leeren) Anweisungen identifiziert. Entscheidungsberdeckungstest Es werden alle Entscheidungsanweisungen identifiziert, wie if/else, switch/case for und while. switch/case, Zweigberdeckungstest Es werden alle Verzweigungen identifiziert, wie if/else, switch/case, for und while while-Anweisungen. Hinweis: Entscheidungstests und Zweigtests sind dungstests bei einem berdeckungsgrad von 100% gleich, knnen sich bei niedrigeren berdeckungsgraden aber unterscheiden. Einfacher Bedingungstest Es werden alle Wahr/Falsch Wahr/Falsch-Bedingungen in Verzweigungsanweisungen identifiziert (beispielsweise if/else, switch/case, for und while). Mehrfachbedingungsberdeckungstest berdeckungstest Es werden alle mglichen Kombinationen von Wahr/Falsch-Bedingungen identifiziert. Bedingungen
Anzahl der ausgefhrten Anweisungen/ Gesamtzahl der Anweisungen Anzahl der ausgefhrten Entscheidungen/Gesamtzahl der Entscheidungen Anzahl der ausgefhrten Zweige/Gesamtzahl der Zweige
Anzahl der ausgefhrten booleschen Bedingungen/Gesamtzahl der booleschen Bedingungen
Anzahl der ausgefhrten Kombinationen von booleschen Bedingungen/ Gesamtzahl der Kombinationen von booleschen Bedingungen
Definierter Bedingungstest Es werden alle mglichen Kombinationen von Wahr/Falsch-Bedingungen identifiziert, die sich auf Bedingungen die Verzweigungsentscheidung (Zweige) auswirken knnen. LCSAJ (Schleifentest) Es werden die mglichen Bedingungen identifiziert, die das Durchlaufen von Schleifen steuern. LCSAJ (Linear Code Sequence and Jump) [Beizer95] wird e verwendet, um einen bestimmten Abschnitt im Code zu testen (eine lineare Folge ausfhrbarer Anweisungen). Der Abschnitt beginnt an einem bestimmten Kontrollfluss und endet mit einem Sprung zu einem anderen Kontrollfluss oder zum Ende des Programms. Diese Code Code-Fragmente werden auch als EE-Pfade bezeichnet Pfade Version 2007 Seite 68 von 136
Anzahl der booleschen Operanden, die unabhngig voneinander die ig Entscheidung beeinflussen/Gesamtzahl der booleschen Operanden
Anzahl der ausgefhrten LCSAJ LCSAJTests/Gesamtzahl der LCSAJ LCSAJ-Tests
Januar 2010 20100131
Name
Verfahren (Entscheidung zu Entscheidung). Das Verfahren wird verwendet, um spezifische Testflle mit den zugehrigen Testdaten zu definieren, die den gewhlten Kontrollfluss ausfhren. Fr den Entwurf dieser Tests wird ein Modell des Quellcodes bentigt, das die Sprnge im Kontrollfluss definiert. LCSAJ kann als Basis fr die Codeberdeckungsmessung dienen.
Kriterien fr die berdeckung
Pfadberdeckungstest Es werden alle eindeutigen Folgen von Anweisungen (Pfade) identifiziert.
Anzahl der ausgefhrten Pfade/Gesamtzahl der Pfade
Mittels strukturorientierter Verfahren ermittelte berdeckungskriterien messen oft die Vollstndi Vollstndigkeit oder Unvollstndigkeit einer Menge von Tests, die mit spezifikationsorientierten und/oder erfahrungsbasierten Testverfahren entworfen wurden. Dazu werden Testwerkzeuge eingesetzt, sogenannte Codeberdeckungswerkzeuge, um die von den Tests erzielte strukturelle berdeckung strukturelle zu erfassen. Wenn dabei wichtige Lcken in der strukturellen berdeckung aufgedeckt werden (oder die durch geltende Standards vorgeschriebene berdeckung nicht erreicht wird), dann schliet man diese Lcken durch zustzliche Tests nach strukturorientierten oder anderen Testverfahren. nach Analyse der berdeckung Ob eine bestimmte Codeberdeckung erzielt wurde oder nicht, lsst sich durch dynamisches Testen nach strukturorientierten oder anderen Testverfahren feststellen. Bei kritischen Systemen liefert es Testverfahren den Nachweis, dass eine spezifische Codeberdeckung erreicht wurde (siehe Abschnitt 1.3.2). Die Ergebnisse knnen zeigen, dass einige Codeabschnitte nicht ausgefhrt wurden, und zu einer wurden, Definition zustzlicher Testflle fhren, damit auch diese Abschnitte ausgefhrt werden.
4.4 Fehlerbasierte und erfahrungsbasierte Testverfahren

4.4.1 Fehlerbasierte Testverfahren
Bei fehlerbasierten Testentwurfsverfahren dient die Kategorie des gesuchten Fehlers als Basis fr den Testentwurf, wobei die Tests systematisch davon abgeleitet werden, was ber den Fehler bekannt ist. Das Verfahren liefert auch Kriterien fr den berdeckungsgrad, der entscheidet, wann die Ableitung von Tests abgeschlossen werden kann. In der Praxis sind die Kriterien fr berdeckungsgrade bei fehlerbasierten Testentwurfsverfahren weniger systematisch als bei verhaltensbasierten und fahren strukturorientierten Verfahren. Die allgemeinen Regeln zur berdeckung sind zwar vorgegeben, es liegt aber im eigenen Ermessen, wo genau die Grenze einer sinnvollen berdeckung in Testentwurf und -durchfhrung liegt. Wenn der berdeckungsgrad vollstndig ist, heit das nicht, dass die Menge durchfhrung von Tests vollstndig ist. Es bedeutet vielmehr, dass die bercksichtigten Fehler fr dieses Testverfahren keine weiteren sinnvollen Tests erlauben. Der Advanced Level Lehrplan behandelt das folgende fehlerbasierte Testentwurfsverfahren: d
Version 2007
Seite 69 von 136
Januar 2010 20100131
Name
Verfahren
Kriterien fr die berdeckung Identifizierte Datenfehler und Fehlerarten.
Fehlertaxonomien (Kategorien und Listen mglicher Fehler) Der Tester, der eine Fehlertaxonomie verwendet, whlt ein potenzielles Problem zur Analyse aus der Liste. Fehlertaxonomien knnen Grundursache, Fehlerzustnde und Fehlerwirkung angeben, sie listen die hufigsten Fehler in der getesteten Software auf. Die Liste wird fr den Entwurf von Testfllen verwendet.
4.4.2 Erfahrungsbasierte Testverfahren

Es gibt weitere Testentwurfsverfahren, bei denen die Fehlerhistorie eine Rolle spielt, die aber nicht zwangslufig systematische berdeckungsgrade liefern. Sie fallen unter die Kategorie der erfahrungsbasierten Testentwurfsverfahren. Bei erfahrungsbasierten Tests nutzt man die fachliche Kompetenz und Intuition der Tester sowie deren Erfahrungen mit hnlichen Anwendungen oder Technologien. Die Tests sind durchaus effektiv beim Auffinden von Fehlern, sie sind aber weniger geeignet als andere Verfahren, wenn es darum ffinden geht, bestimmte berdeckungsgrade zu erzielen oder wiederverwendbare Testszenarien zu produzieren. Beim Einsatz dynamischer oder heuristischer Anstze neigen Tester dazu, erfahrungsbasierte Tests dazu, zu verwenden. Das Testen ist dann eher eine Reaktion auf Ereignisse als eine geplante Vorgehensweise. Auerdem finden Testdurchfhrung und Testauswertung gleichzeitig statt. Einige strukturierte Vorgehensweisen bei erfahrungsbasierten Tests sind nicht durchweg dynamisch; die erfahrungsbasierten Tests werden also nicht vollkommen gleichzeitig entworfen und durchgefhrt. Hinweis: Erfahrungsbasierte Verfahren liefern keine formalen Kriterien fr berdeckungsgrade, auch wenn in der nachfolgenden Tabelle einige Aspekte der berdeckung erscheinen. Der Advanced Level Lehrplan behandelt die folgenden erfahrungsbasierten Testentwurfsverfahren: Name Verfahren Kriterien fr die berdeckung Intuitive Testfallermittlung Tester nutzen ihre Erfahrung, um Fehler zu er erraten, die vielleicht gemacht wurden, und bestimmen die Methoden fr deren Aufdeckung. Das Erraten von Fehlen ist auch bei der Risikoanalyse ntzlich, um potenzielle Fehlerwirkungen zu identifizieren. [Myers97] Checklistenbasiert Erfahrene Tester benutzen eine abstrakte e Checkliste mit Punkten, die beachtet und geprft werden mssen oder nicht vergessen werden drfen. Es kann auch ein Satz von Vorschriften und Kriterien sein, gegen die das Produkt geprft und verifiziert werden muss. Diese Checklisten werden aus einer Reihe von Standards, Erfahrungen und anderen relevanten berlegungen zusammengestellt. Beispiel fr einen checklistenbasierten Test ist eine Checkliste mit Standards fr Benutzerschnittstellen, die als Version 2007 Seite 70 von 136 Anzahl der identifizierte Datenfehler und hl Fehlerkategorien, wenn eine Taxonomie eingesetzt wurde. Ohne Taxonomie ist die berdeckung begrenzt durch die Erfahrenheit des Testers und die verfgbare Zeit. Alle Punkte der Checkliste wurden abgedeckt.
Januar 2010 20100131
Name
Verfahren
Kriterien fr die berdeckung
Grundlage der Tests fr die Anwendung dient. ie Explorativ Die Tester lernen gleichzeitig das Produkt und dessen Fehler kennen, planen vorgesehene Testaufgaben, entwerfen die Tests und fhren sie durch, und berichten ber die Testergebnisse. Gute explorative Tests sind geplant, interaktiv und kreativ. Die Tester passen die Testziele whrend der Testdurchfhrung dynamisch an und dokumentieren dabei nur sparsam. [Veenendaal02]
Es lassen sich Test-Chartas erstellen, Chartas die Aufgaben, Ziele und ufgaben, Arbeitsergebnisse spezifizieren. Fr explorative Testsitzungen lsst sich spezifizieren, was erreicht werden soll, worauf man sich konzentrieren sollte, was innerhalb und auerhalb des Leistungsumfangs liegt und welche Ressourcen vorzusehen sind. hen Auerdem knnen Heuristiken ber Fehler und Qualitt einflieen. Kriterien sind die verschiedenen Schnittstellen der getesteten Anwendung. Die wichtigsten sind Benutzerschnittstelle, Bet Betriebssystem, Kernel des Betriebssystems, APIs und Dateisystem.
Fehlerangriffe Die Tester bewerten die Systemqualitt, indem sie gezielt versuchen, bestimmte Fehlerwirkungen auszulsen. Bei [Whittaker03] ist das Prinzip v von Fehlerangriffen, dass sie auf den Interaktionen der getesteten Software mit ihrer Betriebsumgebung basieren. Dazu gehren: Benutzerschnittstelle, Betriebssystem mit Kernel, Systemschnittstellen (APIs) und Dateisystem. Die Interaktionen basieren auf einem genau definierten Datenaustausch, m falsche Einstellungen bei einer oder mehreren Interaktionen knnen eine Fehlerwirkung verursachen.
Fehler- und erfahrungsbasierte Testentwurfsverfahren nutzen die Kenntnis von Fehlern und andere Erfahrungen, um die Fehleraufdeckung zu erhhen. Sie reichen von Schnelltests, bei denen Tester berhaupt keine formal geplanten Aktivitten haben, ber geplante Testsitzungen bis hin zu Tests mit Testskripten (skriptbasiertes Testen). Sie sind fast immer ntzlich; unter folgenden Bedingungen sind sie aber besonders wertvoll: Es sind keine Spezifikationen vorhanden oder verfgbar. tionen Das zu testende System ist schlecht dokumentiert. Fr Entwurf und Erstellung von Testszenarien ist nicht genug Zeit. Die Tester sind in diesem Fachbereich und/oder in der Technologie besonders erfahren. Es wird eine Erhhung der Vielfalt gegenber dem reinen Testen auf Basis von Testskripten g gesucht. Betriebsausflle sind zu analysieren. Fehler- und erfahrungsbasierte Testentwurfsverfahren sind auerdem ntzlich, wenn sie mit verhaltensbasierten und strukturorientierten Verfahren kombiniert werden, weil sie die Lcken in der Verfahren Testberdeckung schlieen, die aus den systematischen Schwchen dieser Verfahren resultieren.
4.5 Statische Analyse

Bei der statischen Analyse wird getestet, ohne dass die zu testende Software tatschlich ausgefhrt die wird; man betrachtet beispielsweise den Code oder die Systemarchitektur. Version 2007 Seite 71 von 136 Januar 2010 20100131
4.5.1 Statische Analyse des Programmcodes

Als statische Analyse bezeichnet man jede Art von Testen, die durchgefhrt werden kann, ohne den Testen, Programmcode auszufhren. Es stehen die folgenden Analyseverfahren zur Verfgung. 4.5.1.1 Kontrollflussanalyse Die Kontrollflussanalyse liefert Informationen ber logische Entscheidungsknoten im Softwaresystem Entscheidungsknoten und die Komplexitt ihrer Struktur. Die Kontrollflussanalyse ist im ISTQB Foundation-Level-Lehrplan und in [Beizer95] beschrieben. 4.5.1.2 Datenflussanalyse Die Datenflussanalyse ist ein strukturiertes Testverfahren, bei dem Datenflusspfade zwischen dem Setzen einer Variablen und ihrer spteren Verwendung analysiert werden. Diese Pfade bezeichnet man als Define-Use-Paare (Definieren Paare (Definieren-Verwenden) oder Set-Use-Paare (Setzen-Verwenden). Bei Verwenden). dieser Methode werden Testmengen erstellt, die nach Mglichkeit eine 100%ige berdeckung all ser dieser Paare erreichen. Obwohl das Verfahren als Datenflussanalyse bezeichnet wird, prft es auch den Kontrollfluss der Software, weil es Setzen und Verwendung jeder Variablen prft und dabei dem Kontrollfluss der Software folgt. [Beizer95]. 4.5.1.3 Konformitt mit Programmierkonventionen Die statische Analyse kann auch die Einhaltung von Programmierkonventionen im vorhandenen Code bewerten. Programmierkonventionen geben sowohl Aspekte der Systemarchitektur als auch die erlaubte oder nicht erlaubte Verwendung von Programmierstrukturen vor. Die Einhaltung von Programmierkonventionen beim Codieren verbessert Wartbarkeit und Testbarkeit Wartbarkeit der Software. Statische Analysen knnen auch bestimmte Sprachanforderungen prfen. 4.5.1.4 Erzeugung von Codemetriken Bei einer statischen Analyse knnen Codemetriken ermittelt werden, die bei Einhaltung festgelegter Grenzen zu einer hheren Wartbarkeit und Zuverlssigkeit des Programmcodes beitragen. Beispiele fr solche Metriken sind zyklomatische Zahl Gre Hufigkeit von Kommentaren Anzahl der Verschachtelungen Anzahl von Funktionsaufrufen fen
4.5.2 Statische Analyse der Softwarearchitektur

4.5.2.1 Statische Analyse einer Webseite Auch die Architektur einer Webseite lsst sich mit Hilfe von statischen Analysewerkzeug bewerten. Analysewerkzeugen Hier geht es darum zu prfen, ob die Baumstruktur der Webseite ausgeglichen ist oder ob eine Unausgewogenheit vorliegt, die folgende Konsequenzen haben knnte: schwierigere Testaufgaben hherer Arbeitsaufwand fr die Wartung schwierige Navigation fr den Nutzer tion Spezifische Testwerkzeuge, die mit web spider engines ausgerstet sind, knnen ber die statische Analyse auch Informationen ber die Gre der Seiten liefern, Dauer des Herunterladens sowie ber
Version 2007
Seite 72 von 136
Januar 2010 20100131
das Vorhandensein/Fehlen einer Seite (http error 404). Das sind ntzliche Informationen fr (http Entwickler, Webmaster und Tester. 4.5.2.2 Aufrufgraphen Aufrufgraphen knnen unterschiedlichen Zwecken dienen: Tests entwerfen, die ein bestimmtes Modul aufrufen Herausfinden, wo das Modul berall aufgerufen wird en, Vorgehensweisen fr die Integration vorschlagen (paarweise und benachbarte Integration [Jorgensen02]) Struktur des Gesamtcodes und seiner Architektur bewerten Zustzlich kann die dynamische Analyse (siehe Abschnitt 4.6) Informationen darber liefern, wie oft ein Modul aufgerufen wird. Die Tester knnen die Informationen aus den Aufrufgraphen der statischen Analyse mit denen aus der dynamischen Analyse zusammenfhren und sich dann auf die Module konzentrieren, die oft und/oder wiederholt aufgerufen werden. Wenn es auerdem komplexe Module t sind (siehe Abschnitt 1.3.2.2), sollten sie umfangreich und im Detail getestet werden. ),
4.6 Dynamische Analyse

Die dynamische Analyse untersucht die laufende Anwendung. Dazu ist meist eine Instrumentierung e notwendig, die manuell oder automatisch in eine temporre Kopie des Programmquellcode eingefgt wird.
4.6.1 bersicht
Fehlerwirkungen, die nicht ohne W eiteres reproduzierbar sind, knnen erhebliche Konsequenzen fr den Testaufwand haben und knnen die Softwareproduktionsfreigabe verhindern. Ursachen solcher Fehler knnen Speicherengpsse sein, inkorrekter Einsatz von Zeigern und andere Korruptionen (beispielsweise des System-Stacks) [Kaner02]. Diese Art von Fehlern kann zu einer allmhlichen Stacks) Verschlechterung der Systemleistung oder sogar zu Systemabstrzen fhren; die Teststrategie muss deshalb die mit diesen Fehlern verbundenen Risiken bercksichtigen. Falls ntig, mssen die Risiken Falls durch eine dynamische Analyse reduziert werden (normalerweise mit Hilfe von Testwerkzeugen). Die dynamische Analyse wird durchgefhrt, whrend die Software luft, und soll Fehler verhindern, indem fehlerhafte wilde Zeiger und Speicherengpsse aufgedeckt und werden. Systemausflle analysieren, die nicht leicht reproduzierbar sind. Netzwerkverhalten bewerten. die Systemleistung verbessern, indem Informationen ber das Laufzeitverhalten des Systems erfasst werden. Die dynamische Analyse kann in jeder Teststufe durchgefhrt werden, sie ist aber besonders ntzlich alyse fr Komponenten- und Integrationstests. Zum Spezifizieren der Testziele und vor allem fr die Analyse der Testergebnisse sind technische Fhigkeiten und Systemkenntnisse erf erforderlich.
4.6.2 Speicherengpsse aufdecken

Ein Speicherengpass tritt auf, wenn der Speicher (RAM) der fr ein Programm verfgbar ist, zwar (RAM), allokiert, wegen Programmierfehlern aber nicht wieder freigegeben wird. Das Programm kann dann wird. auf diesen Teil des Speichers nicht mehr zugreifen und der nutzbare Speicherplatz kann ausgehen.
Version 2007
Seite 73 von 136
Januar 2010 20100131
Speicherengpsse verursachen Probleme, die sich erst allmhlich entwickeln und oft nicht erkennbar sind, so beispielsweise, wenn die Software erst krzlich installiert oder das System neu gestartet e wurde, was beim Testen oft geschieht. Die negativen Auswirkungen von Speicherengpssen werden deshalb oft erst bemerkt, wenn das Programm in Produktion gegangen ist. Symptom eines Speicherengpasses ist die kontinuierlichen Verlangsamung der Antwortzeiten, die ngpasses letztendlich zu einem Systemausfall fhren kann. Man kann solchen Ausfllen zwar mit einem Neustart (Rebooten) des Systems begegnen, das ist aber oft unpraktisch oder sogar unmglich. Bereiche, in denen Speicherengpsse vorkommen, lassen sich mit Werkzeugen identifizieren, so dass ereiche, die Speicherengpsse korrigiert werden knnen. Mit einem einfachen Speichermonitor lsst sich herausfinden, ob der verfgbare Speicherplatz sich allmhlich verringert, dann msste noch eine verringert, Nachanalyse durchgefhrt werden. Es mssen noch andere Arten von Engpssen betrachtet werden, beispielsweise bei Dateibezeichnern, Zugriffsgenehmigungen (Semaphore) und Verbindungspools fr Ressourcen.
4.6.3 Fehlerhafte Zeiger auf aufdecken

Fehlerhafte (wilde) Zeiger in einem Programm sind unbrauchbare Zeiger. Sie entstehen, wenn es die Objekte oder die Funktionen nicht mehr gibt, auf die sie zeigen, oder wenn sie nicht auf den vorgesehenen Speicher verweisen, sondern beispielsweise auf einen Speicherbereich auerhalb des orgesehenen zugewiesenen Arrays. Wenn ein Programm fehlerhafte Zeiger enthlt, kann das verschiedene Folgen haben: 1. Unter Umstnden funktioniert das Programm wie erwartet, wenn der Zeiger auf quasi freie wenn Speicherbereiche zeigt, die vom Programm zurzeit nicht genutzt werden. 2. Das Programm kann abstrzen, wenn der Zeiger auf einen kritischen Teil des Speichers fr die Programmumgebung zeigt (beispielsweise des Betriebssystems). 3. Das Programm funktioniert nicht korrekt, weil es auf bentigte Objekte nicht zugreifen kann. Es kann dann zwar weiterhin funktionieren, gibt aber Fehlermeldungen aus. 4. Durch fehlerhafte Zeiger knnen Daten zerstrt oder unbrauchbar werden, sodass dann inkorrekte Werte verwendet werden. rekte Hinweis: Jede nderung an der Speichernutzung durch das Programm (beispielsweise ein neuer Build nach einer Softwarenderung) kann eine dieser vier Folgen haben. Dies ist vor allem dann kritisch, wenn das Programm zunchst wie erwartet funktioniert, obwohl es fehlerhafte Zeiger enthlt, jedoch nach einer Softwarenderung abstrzt (vielleicht sogar im Produktionseinsatz). Solche Ausflle sind Symptome eines Fehlerzustands (des fehlerhaften Zeigers) und nicht der Fehler selbst (s (siehe auch [Kaner02], Lesson 74). Werkzeuge knnen fehlerhafte Zeiger identifizieren, die ein Programm verwendet, unabhngig von den Folgen der Zeiger fr die Programmausfhrung.
4.6.4 Systemleistung analysieren

Mit einer dynamischen Analyse lsst sich auch die Programmleistung analysieren. Werkzeuge knnen Leistungsengpsse identifizieren und ein breites Spektrum an Performanzmetriken erzeugen. Damit knnen die Entwickler das System in einer sogenannten Performanzprofilierung (performance Performanzprofilierung profiling) optimieren.
Version 2007
Seite 74 von 136
Januar 2010 20100131
5. Test der Softwareeigenschaften

Begriffe
Anwendungsprofil, Benutzbarkeitstest betrieblicher Abnahmetest, Effizienztest, heuristische , Benutzbarkeitstest, , Evaluation, Interoperabilittstest, Portabilittstest Sicherheitstest, SUMI (Software Usability , Portabilittstest, , Measurement Inventory), Test auf Richtigkeit Wartbarkeitstest, Wiederherstellbarkeitstest , Richtigkeit, , Wiederherstellbarkeitstest, Zugnglichkeitstest, Zuverlssigkeitstest Zuverlssigkeits-Wachstumsmodell , Zuverlssigkeitstest,
5.1 Einfhrung
Whrend das vorige Kapitel die verschiedenen Testverfahren fr Tester beschreibt, behandelt dieses Kapitel wie Tester die Verfahren anwenden, um die wichtigsten Qualittsmerkmale fr Softwareanwendungen oder Systeme zu bewerten. Die Qualittsmerkmale, die von Test Analysts und von Technical Test Analysts zu bewerten sind, werden in separaten Abschnitten dieses Lehrplans behandelt. Hintergrund ist die Beschreibung der Qualittsmerkmale im ISO Standard 9126. Die verschiedenen Qualittsmerkmale zu verstehen, ist grundlegendes Lernziel aller drei Module. Je nachdem, welches der Qualittsmerkmale behandelt wird, entsteht entweder im Modul fr Test es Analysts oder im Modul fr Technical Test Analysts ein tieferes Verstndnis. Die jeweiligen Adressaten knnen so typische Risiken erkennen, geeignete Teststrategien entwickeln und Testflle spezifizieren.
5.2 Qualittsmerkmale bei fachlichen Tests

Funktionale Tests sind in erster Linie darauf fokussiert, was das Produkt leistet (weniger auf das Wie). Sie basieren im Allgemeinen auf einer Spezifikation oder einem Anforderungsdokument, spezifischer Expertise in einem Fachgebiet oder einem unterstellten Bedarf. Funktionale Tests unterscheiden sich je nach der Teststufe oder -phase, in der sie durchgefhrt werden. So wird beispielsweise bei ei phase, einem Integrationstest die Funktionalitt der Schnittstellenmodule fr eine definierte Funktion getestet. Systemtests prfen die Funktionalitt der gesamten Anwendung. Bei Multisystemen werden mit funktionalen Tests vor allem die gesamten integrierten System End to End getestet. Systeme Funktionale Tests setzen viele unterschiedliche Testverfahren ein (siehe Kapitel 4). Dabei kann entweder ein dedizierter Tester die funktionalen Tests durchfhren, ein Fachexperte oder ein Entwickler (wenn es um Komponenten geht). Folgenden Qualittsmerkmale werden untersucht: lgenden Richtigkeit Angemessenheit Interoperabilitt Funktionale Sicherheit Benutzbarkeit Zugnglichkeit
Version 2007
Seite 75 von 136
Januar 2010 20100131
5.2.1 Tests auf Richtigkeit

Funktionale Tests auf Richtigkeit prfen die Einhaltung von spezifizierten oder impliziten Richtigkeit Anforderungen an eine Anwendung; sie knnen auch die Richtigkeit der Berechnungen prfen. Tests auf Richtigkeit nutzen viele der Testverfahren aus Kapitel 4.
5.2.2 Tests auf Angemessenheit

Tests auf Angemessenheit bewerten und validieren, ob sich eine Menge von Funktionen fr die vorgesehenen spezifizieren Aufgaben eignen. Die Tests knnen auf Anwendungsfllen (use cases) oder auf Vorgehen basieren.
5.2.3 Interoperabilittstests
Interoperabilittstests prfen, ob eine Anwendung in allen vorgesehenen Umgebungen (Hardware, Software, Middleware, Betriebssystem usw.) korrekt funktionieren. Fr die Spezifikation der Interoperabilittstests sind Kombinationen der vorgesehenen Zielumgebungen zu identifizieren, zu konfigurieren und dem Testteam zur Verfgung zu stellen. Diese Umgebungen werden dann mit ausgewhlten funktionalen Testfllen getestet, welche die verschiedenen Komponenten der estfllen Testumgebung prfen. Interoperabilitt betrifft das Zusammenwirken verschiedener Softwaresysteme. Software mit guten Interoperabilittseigenschaften lsst sich leicht mit verschiedenen anderen System integrieren, ohne System dass grere nderungen ntig sind. Messen lsst sich die Interoperabilitt durch die Anzahl notwendiger nderungen und den damit verbundenen Aufwand. Beim Testen der Softwareinteroperabilitt knnen beispielsweise die folgenden Designmerkmale im Designmerkmale Fokus stehen: die Verwendung von industrie blichen Kommunikationsstandards, beispielsweise XML; industrie-blichen die Fhigkeit der Software, die Kommunikationsanforderungen anderer Systeme automatisch zu erkennen, mit denen sie zusammenwirkt, und sie entsprechend anzusteuern. entsprechend Interoperabilittstests sind besonders wichtig fr Unternehmen, die kommerzielle Standardsoftware und werkzeuge entwickeln, werkzeuge die Entwicklung von Multisystemen. Die Tests finden vorwiegend whrend der Systemintegrationstests statt.
5.2.4 Funktionale Sicherheitstests ionale

Funktionale Sicherheitstests (Penetrationstests) fokussieren die Fhigkeit der Software, unberechtigten Zugriff auf Daten oder Funktionen zu verhindern, unabhngig davon, ob der Zugriff unbeabsichtigt oder vorstzlich erfolgt. Die Tests untersuchen Rechte der Nutzer, Zugriff und Berechtigungsklassen. Diese Informationen sollten in den Spezifikationen des Systems enthalten sein. Sicherheitstests betreffen auch einige Aspekte, die eher fr Technical Test Analysts relevant sind, sie behandelt Abschnitt 5.3.
5.2.5 Benutzbarkeitstests
Die Ursachen fr mgliche Schwierigkeiten von Benutzern bei ihrer Arbeit mit dem zuknftigen bei System mssen erkennbar sein. Nutzer knnen zu sehr unterschiedlichen Personengruppen gehren, angefangen von IT-Experten bis hin zu Kindern oder Menschen mit besonderen Bedrfnissen. Experten Einige nationale Verbnde (beispielsweise das British Royal National Institute for the Blind) (beispielsweise empfehlen, dass Webseiten fr behinderte, blinde, sehbehinderte oder taube Nutzer und fr Version 2007 Seite 76 von 136 Januar 2010 20100131
Menschen mit Bewegungs- oder Wahrnehmungseinschrnkungen auch zugnglich sein sollten. Die Prfung, ob eine Webseite fr diese Personengruppen nutzbar ist, verbessert die Benutzbarkeit auch fr alle anderen. Benutzbarkeitstests prfen die Eignung der Software fr ihre Nutzer. Sie messen dabei anhand der folgenden Faktoren, ob festgelegte Nutzer in bestimmten Umgebungen oder Anwendungskontexten Umgebungen spezifizierte Ziele erreichen: Effektivitt: Eignung der Anwendung fr die Nutzer, spezifizierte Ziele in einem spezifizierten Anwendungskontext richtig und vollstndig zu erreichen Effizienz: Eignung der Anwendung fr die Nutzer, der Effektivitt angemessene Ressourcen in einem spezifizierten Anwendungskontext einzusetzen Zufriedenheit: Eignung der Anwendung, die Nutzer in einem spezifizierten , Anwendungskontext zufriedenzustellen Messbare Merkmale sind oftwaremerkmale, Verstndlichkeit: Softwaremerkmale, die beeinflussen, welchen Aufwand die Nutzer leisten mssen, um das logische Konzept und dessen Anwendbarkeit zu erkennen Erlernbarkeit: Softwaremerkmale, die beeinflussen, welchen Aufwand die Nutzer leisten mssen, um die Anwendung zu erl erlernen Operabilitt: Softwaremerkmale, die beeinflussen, welchen Aufwand die Nutzer leisten mssen, um Aufgaben effektiv und effizient auszufhren Attraktivitt: Eigenschaft der Software, dass sie dem Nutzer gefllt Die Bewertung der Benutzbarkeit hat zwei Ziele: Benutzbarkeitsfehler zu beseitigen (auch formative Bewertung) zu testen, ob die Benutzbarkeitsanforderungen erfllt sind (auch summative Bewertung) Die Tester sollten Wissen oder Expertise in folgenden Wissensbereichen haben: Soziologie Psychologie Einhaltung nationaler Standards oder Vorschriften (beispielsweise das Allgemeine Gleichbehandlungsgesetz ((AGG)) vom 17. August 2006) Ergonomie Das implementierte System sollte unter realittsnahen Bedingungen validiert werden. Mglicherweise Bedingungen muss dazu ein Benutzbarkeitslabor eingerichtet werden mit Videokameras, nachgebauten Bros, Review-Gruppen, Nutzern usw., damit das Entwicklungsteam die Wirkung des tatschlichen Systems Gruppen, auf echte Personen beobachten kann. Viele Benutzbarkeitstests werden als Teil anderer Tests durchgefhrt, beispielsweise beim funktionalen Systemtest. Eine Ergonomierichtlinie ist hilfreich beim konsistenten Herangehen an Aufdeckung und Berichterstattung von Benutzbarkeitsfehlern in allen Softwarelebenszyklusphasen. allen 5.2.5.1 Benutzbarkeitstests spezifizieren Die wichtigsten Verfahren fr Benutzbarkeitstests sind Reviews (z.B. Inspektionen) oder Bewertungen Verifizierung und Validierung der tatschlichen Systemimplementierung Gutachten und Befragungen
Version 2007
Seite 77 von 136
Januar 2010 20100131
Reviews Weil Reviews (z.B. Inspektionen) von Spezifikation und Entwrfen unter Gesichtspunkten der Benutzbarkeit die Nutzerbeteiligung erhhen, knnen sie Probleme frh entdecken und kosteneffektiv entdecken sein. Mit einer heuristischen Evaluation (der systematischen Inspektion des Entwurfs einer Benutzerschnittstelle auf ihre Benutzbarkeit) lassen sich Probleme der Benutzbarkeit im Entwurf aufdecken, sodass sie im iterativen Entwurfsprozess bearbeitet werden knnen. Dabei prft ein ass kleines Prferteam die Schnittstelle und ihre Konformitt mit anerkannten Grundstzen der Benutzbarkeit (den heuristischen Grundstzen der Ergonomie). Validierung der tatschlichen Systemimplementierung chen Zur Validierung der tatschlichen Systemimplementierung knnen Benutzbarkeitstestszenarien aus Tests entwickelt werden, die fr den funktionalen Systemtest spezifiziert wurden. In diesen Testszenarien werden statt der funktionalen Ergebnisse die spezifischen Benutzbarkeitsmerkmale funktionalen gemessen, beispielsweise Lerngeschwindigkeit oder Operabilitt. Es lassen sich spezifische Benutzbarkeitstestszenarien fr das Testen von Syntax und Semantik entwickeln: Syntax: Aufbau oder Grammatik der Schnittstelle (was beispielsweise in ein Eingabefeld eingegeben werden kann) Semantik: Bedeutung und Zweck (beispielsweise sinnvolle und aussagekrftige Systemmeldungen und ausgaben an den Nutzer) ausgaben Mgliche Verfahren fr die Entwicklung solcher Testszenar Testszenarien sind Black-Box-Verfahren, wie beispielsweise im BS 7925 2 (British Standard) beschrieben Verfahren, 7925-2 Anwendungsflle, definiert entweder in Textform oder UML (Unified Modeling Language Language) Testszenarien fr Benutzbarkeitstests enthalten Anleitungen fr die Nutzer, Zeitrume vor und nach tstests den Tests fr Interviews, in denen die Anleitung vermittelt oder die Rckmeldungen gesammelt werden, sowie das vereinbarte Vorgehen im Verlauf der Testeinheiten. Das Vorgehen legt fest, w wie die Tests ausgefhrt werden, ihren zeitlichen Ablauf, Protokollierung und Aufzeichnung der Testsitzung sowie die Methoden fr Begutachtung und Befragung. Gutachten und Befragungen Mit Gutachten und Befragungen lassen sich Beobachtungen ber das Verhalten der Anwender bei der sich Systemnutzung in einem Testlabor sammeln. Standardisierte und ffentlich zugngliche Gutachten, wie etwa SUMI (Software Usability Measurement Inventory) und WAMMI (Website An Analysis and MeasureMent Inventory) ermglichen ein Benchmarking gegen eine Datenbank mit frheren Benutzbarkeitsmessungen. SUMI liefert konkrete Benutzbarkeitsmetriken, diese lassen sich als Testende- oder Abnahmekriterien verwenden.
5.2.6 Zugnglichkeitstests
Es ist wichtig, die Zugnglichkeit der Software fr Menschen mit besonderen Anforderungen oder eingeschrnkten Nutzungsmglichkeiten zu prfen. Dazu gehren auch behinderte Personen. Die relevanten Standards sollten eingehalten werden, wie etwa Richtlinien ber Barrierefreiheit (Web andards Content Accessibility Guidelines) oder Anti Anti-Diskriminierungsgesetze (Disability Discrimination Acts Acts, Grobritannien, Australien) und Section 508 (USA).
Version 2007
Seite 78 von 136
Januar 2010 20100131
5.3 Qualittsmerkmale bei technischen Tests

Die fr Technical Test Analysts relevanten Qualittsmerkmale sind in erster Linie darauf fokussiert, wie das Produkt funktioniert (weniger auf das funktionale Was). Die Tests knnen in jeder Teststufe stattfinden, besonders relevant sind sie fr: Komponententest (besonders fr Echtzeitsysteme und eingebettete Systeme) Performanz-Benchmarking Ressourcennutzung Systemtests und betrieblicher Abnahmetest (Produktionsabnahmetest) s Je nach Risiken und verfgbaren Ressourcen gehren dazu die nachfolgend genannten Qualittsmerkmale und Teilmerkmale. Technisch ausgerichtete Tests in dieser Teststufe beziehen sich auf das Testen eines gerichtete spezifischen Systems, d.h. einer Kombination aus Hardware und Software, einschlielich Server, Clients, Datenbanken, Netzwerken und anderen Ressourcen. Diese Tests werden oft auch noch durchgefhrt, nachdem die Software in Produktion gegangen ist. Dann ist oft ein separates Team oder eine Organisation dafr zustndig. Metriken fr die Qualittsmerkmale aus den Tests vor Produktionseinfhrung knnen als Grundlage fr die Service Level-Vereinbarungen zwischen Lieferant und Betreiber des Softwaresystems dienen. reinbarungen Folgenden Qualittsmerkmale werden getestet: technische Sicherheit Zuverlssigkeit Effizienz Wartbarkeit Portabilitt
5.3.1 Technische Sicherheitstests

Sicherheitstests unterscheiden sich von anderen Formen fachlicher oder technischer Tests in zwei wichtigen Aspekten: 1. Standardverfahren zur Auswahl der Testeingangsdaten knnen wichtige Sicherheitsthemen bersehen. 2. Die Symptome von Sicherheitsfehlern unterscheiden sich grundlegend von Symptomen bei e anderen Testverfahren. Sicherheits-Schwachstellen gibt es an Stellen, wo die Software nicht nur funktioniert wie im Entwurf Schwachstellen vorgesehen, sondern wo sie zustzlich weitere, nicht beabsichtigte Aktionen ausfhrt. Solche beabsichtigte Nebeneffekte sind eine der grten Bedrohungen fr die Softwaresicherheit gegenber Angriffen. Beispiel: Eine Abspielsoftware spielt Audio korrekt ab, schreibt dabei aber Dateien in einen nicht verschlsselten Zwischenspeicher. Softwarepiraten knnten diesen Nebeneffekt ausnutzen. icher. Wichtigste Aufgabe der Softwaresicherheit ist es, eine nicht beabsichtigte Nutzung von Informationen durch nicht autorisierte Personen zu verhindern. Sicherheitstests versuchen, die Sicherheitsri Sicherheitsrichtlinie eines Systems auer Kraft zu setzen, indem sie seine Schwachstellen fr Bedrohungen durch verschiedene Manahmen ausnutzen: Nicht autorisiertes Kopieren von Anwendungen oder Daten (beispielsweise Softwarepiraterie) Nicht autorisierter Zugriff (Aktionen auszufhren, fr die der Nutzer keine Zugriffsberechtigung (Aktionen hat)
Version 2007
Seite 79 von 136
Januar 2010 20100131
berlauf des Eingabebereichs (Pufferberlauf), der beispielsweise durch Eingabe extrem langer Zeichenketten ber ein Eingabefeld der Benutzerschnittstelle ausgelst werden kann. Nach diesem berlauf lsst sich mglicherweise bsartiger Code ausfhren. esem Denial of Service-Angriff, sodass die Anwendung nicht mehr genutzt werden kann Angriff, (beispielsweise indem ein Webserver von bermengen von Stranfragen berschwemmt wird) agungen Abhren von Datenbertragungen in Netzwerken, um an vertrauliche Informationen zu gelangen (beispielsweise ber Kreditkarten Kreditkarten-Transaktionen) Verschlsselungscodes knacken, die vertrauliche Daten schtzen Logische Fallen (logic bombs, in den USA manchmal Easter Eggs genannt), die in bsartiger Absicht in den Code eingeschleust und nur unter bestimmten Bedingungen aktiviert werden (beispielsweise an einem bestimmten Datum). Werden diese logischen Fallen aktiviert, so lsen sie Schadaktionen aus, wie das Lschen von Dateien oder Formatieren von Festplatten. Formatieren Sicherheitsbelange lassen sich folgendermaen einteilen: Die Benutzerschnittstelle betreffend nicht autorisierter Zugriff bsartige Eingaben Das Dateisystem betreffend Zugriff auf vertrauliche Daten in Dateien oder Repositorie Repositories Das Betriebssystem betreffend unverschlsseltes Ablegen von sicherheitskritischen Informationen, wie Passwrtern. Wird das System durch bsartige Eingaben zum Absturz gebracht, knnen die Informationen zugnglich werden. Externe Software betreffend Interaktionen zwischen externen Komponenten, die das System nutzt. Sie knnen auf ktionen Netzwerkebene stattfinden (wenn beispielsweise inkorrekte Datenpakete oder Meldungen bertragen werden) oder auf Ebene der Softwarekomponenten (wenn beispielsweise eine Softwarekomponente ausfllt, die vom System bentigt wird). ponente Hinweis: Verbesserungen bei der Sicherheit eines Systems knnen die Systemleistung beeintrchtigen. Es ist also ratsam, nach den Sicherheitsverbesserungen die Performanztests zu wiederholen. 5.3.1.1 Sicherheitstestspezifikation spezifikation Mgliche Verfahren beim Entwickeln der Sicherheitstests sind Informationen abrufen Mit verbreiteten Werkzeugen wird ein Profil oder Netzwerkplan des Systems erstellt. Mglic Mgliche Informationen sind: Mitarbeiter, physikalische Adressen, Details der internen Netzwerke, IP IPNummern, Typ der verwendeten Software/Hardware, Betriebssystem Betriebssystem-Version. Schwachstellen scannen Mit den verbreiteten Werkzeugen wird das System gescannt. Diese W erkzeuge werden nicht Werkzeuge dazu verwendet, in das System direkt einzudringen, sondern zur Identifizierung von Schwachstellen, die eine Verletzung der Sicherheitsrichtlinie darstellen oder dazu fhren knnen. Spezifische Schwachstellen lassen sich auch mit Hilfe von Checklisten, wie etwa bei www.testingstandards.co.uk, www.testingstandards.co.uk identifizieren. Fehlerangriffe entwickeln Mit den gesammelten Informationen werden Testaktionen geplant, die die Sicherheitsrichtlinie eines bestimmten Systems durchdringen sollen. Fr die Angriffsplne mssen mehrere immten
Version 2007
Seite 80 von 136
Januar 2010 20100131
Eingaben ber verschiedene Schnittstellen (beispielsweise Benutzerschnittstelle, Dateisystem) spezifiziert werden, um so die schwersten Sicherheitsdefekte aufzudecken. Die verschiedenen bei [Whittaker04] beschriebenen Fehlerangriffe sind eine wertvolle Quelle en fr Verfahren, die speziell fr Sicherheitstests entwickelt wurden. Weitere Informationen zu Fehlerangriffen enthlt Abschnitt 4.4.
5.3.2 Zuverlssigkeitstests sts

Ein Ziel beim Testen der Zuverlssigkeit ist es, das statistische Ma an Softwarereife (Maturity) ber eine Zeitspanne zu berwachen und mit der zu erzielenden Zuverlssigkeit zu vergleichen. Metriken knnen sein: Die durchschnittliche Zeit zwischen Ausfllen (MTBF, Mean Time Between Failures die (MTBF, Failures), durchschnittliche Zeit fr die Fehlerbehebung (MTTR Mean Time to Repair) oder eine andere (MTTR, ) Messung der Fehlerdichte (beispielsweise wchentliche Anzahl der Fehler mit einem bestimmten Schweregrad). Ein Modell zur berwachung von Zuverlssigkeitswerten ber eine Zeitspanne bezeichnet man auch als Zuverlssigkeits Zuverlssigkeits-Wachstumsmodell (Reliability Growth Model). ). Es gibt verschiedene Formen von Zuverlssigkeitstests, beispielsweise eine Menge definierter Tests, die wiederholt werden, zufllig aus einem Pool gewhlte Tests oder Testflle, die a aus einem statistischen Modell generiert wurden. Der Zeitaufwand fr diese Tests kann daher erheblich sein, bis zu mehreren Tagen. Die Analyse der ber eine Zeitspanne gemessenen Softwarereife kann Testendekriterien (beispielsweise fr die Produktionsfreigabe) liefern. Bestimmte Metriken, wie MTBF und MTTR, Produktionsfreigabe) knnen in Service Level-Vereinbarungen umgesetzt und in der Produktion berwacht werden Vereinbarungen werden. Software Reliability Engineering & Testing (SRET) ist ein Standardverfahren fr das (SRET) Zuverlssigkeitstesten. 5.3.2.1 Robustheitstest Whrend funktionale Tests die Fehlertoleranz der Software gegenber unerwarteten Eingaben bewerten (Negativtests), bewerten die technisch ausgerichteten Tests eher die Toleranz des Systems gegenber Fehlern, die auerhalb der zu testenden Anwendung auftreten. Normalerweise meldet das Betriebssystem solche Fehler (beispielsweise Festplatte voll, Prozess oder Dienst nicht verfgbar, Datei nicht gefunden, Speicher nicht verfgbar). Fr Tests der Fehlertoleranz auf Systemebene gibt es spezifische Werkzeuge. 5.3.2.2 Wiederherstellbarkeitstest Weitere Formen von Zuverlssigkeitstests bewerten, wie sich das System nach Hardware oder HardwareSoftwareversagen mit einem definiertem Vorgehen wiederherstellen lsst, sodass anschlieend der normale Betrieb fortgesetzt werden kann. Zu Wiederherstellbarkeitstests gehren auch Failover Tests und Backup- und Wiederherstellungstests Wiederherstellungstests. Failover Tests werden durchgefhrt, wenn die Konsequenzen eines Softwareversagens so gravierend sind, dass spezielle Hardware- und/oder Softwaremanahmen beim System implementiert wurden, beim um den weiteren Betrieb selbst nach einem Versagen sicherzustellen. Failover Tests knnen sinnvoll sein, wenn beispielsweise das Risiko finanzieller Verluste als extrem hoch einzustufen ist, oder wenn kritische Sicherheitsanforderungen vorliegen. Wenn die Ursache solcher Systemausflle eine nforderungen Katastrophe sein kann, bezeichnet man diese Art von Wiederherstellbarkeitstests auch als Katastrophentests. Typische Hardware-basierte Manahmen knnen beispielsweise ein Lastausgleich b mehrere basierte ber Prozessoren sein, das Clustern von Servern, Prozessoren oder Festplatten, sodass bei einem Ausfall sofort die eine Komponente von der anderen bernehmen kann (beispielsweise RAID, Redundant Array of Inexpensive Disks). Eine typische Software Software-basierte Manahme kann die Implementierung ierte Version 2007 Seite 81 von 136 Januar 2010 20100131
von mehr als einer unabhngigen Instanz des Softwaresystems in so genannten redundanten Systemen sein (beispielsweise beim Steuerungssystem eines Flugzeugs). Redundante Systeme sind normalerweise eine Kombination aus Software und Hardwaremanahmen und werden je nach rweise SoftwareAnzahl der unabhngigen Instanzen als zweifach/dreifach/vierfach redundante Systeme bezeichnet. Unterschiedliche Lsungen lassen sich dadurch erreichen, dass zwei (oder mehr) un unabhngige Entwicklungsteams dieselben Softwareanforderungen zur Umsetzung erhalten. Die gleiche Leistung wird dann mit unterschiedlichen Softwarelsungen erbracht. Das schtzt die mehrfach redundanten Systeme, weil nicht wahrscheinlich ist, dass hnliche fehlerhafte Eingaben das gleiche Ergebnis fehlerhafte haben. Diese Manahmen zur Verbesserung der Wiederherstellbarkeit eines Systems knnen auch dessen Zuverlssigkeit direkt beeinflussen und bei der Durchfhrung der Zuverlssigkeitstests bercksichtigt werden. Durch die Simulation von Fehlerwirkungen oder das Ausfhren in einer kontrollierten Umgebung sind Failover Tests ausdrcklich auf das Testen redundanter Systeme ausgelegt. Nach einer Fehlerwirkung wird der Failover-Mechanismus getestet, um sicherzustellen, dass der Vorfall weder Mechanismus Datenverlust noch Datenkorruption bewirkt hat, und dass die Service Level Vereinbarungen Level-Vereinbarungen eingehalten wurden (beispielsweise Funktionsverfgbarkeit, Antwortzeiten). Weitere Informationen zu Failover Tests unter www.testingstandards.co.uk. Backup- und Wiederherstellungstests untersuchen Manahmen und Verfahren, die die mglichen Fehlerwirkungen minimieren sollen. Sie bewerten die (meist in einer Teststrategie dokumentierten) Verfahrensweisen, nach denen die verschiedenen Sicherungsarten erstellt und die Daten nach erstellt Datenverlust oder korruption wiederhergestellt werden. Die Testflle werden so entworfen, dass korruption kritische Pfade im Verfahren abgedeckt sind. Als Trockenbung fr diese Szenarien lassen sich technische Reviews durchfhren, die die Handbcher fr die tatschliche Installationsprozedur Handbcher validieren. Beim betrieblichen Abnahmetest werden diese Szenarien in einer echten Produktionsumgebung oder in einer produktionshnlichen Umgebung eingesetzt, um ihre tatschliche Anwendung zu validieren. Mgliche Metriken fr die Messung bei Backup und Wiederherstellungstests sind Backup bentigte Zeit fr die verschiedenen Backup Arten (beispielsweise vollstndig, inkrementell) Backup-Arten bentigte Zeit fr die Wiederherstellung der Daten garantierte Sicherungsstufen (beispielsweise Wiederherstellung aller Daten, die nicht lter als (beispielsweise 24 Stunden sind, oder spezifischer Transaktionsdaten, die nicht lter als eine Stunde sind).
5.3.2.3 Zuverlssigkeitstest-Spezifikation Spezifikation Zuverlssigkeitstests basieren meist auf Anwendungsmustern (Nutzungsprofilen); sie knnen formal s oder je nach Risiko durchgefhrt werden. Die Testdaten knnen mit Zufalls Zufalls- oder Pseudozufallsmethoden generiert werden t werden. Die Wahl der Zuverlssigkeits-Wachstumskurve sollte gut begrndet sein und der Satz von Wachstumskurve begrndet Fehlerdaten mit Werkzeugen analysiert werden, damit die Zuverlssigkeits Wachstumskurve den Zuverlssigkeits-Wachstumskurve vorhandenen Daten angemessen ist. Zuverlssigkeitstest eignen sich auch fr die gezielte Suche nach Speicherengpssen. Sie mssen dann so spezifiziert werden, dass sie besonders speicherintensive Vorgnge wiederholt ausfhren und eine ordnungsgeme Speicherfreigabe nachweisen.
5.3.3 Effizienztests
Das Qualittsmerkmal Effizienz wird mit Test zu Zeit- und Ressourcenverhalten bewertet. Die Tests folgenden Abschnitte behandeln Effizienztests bezogen auf das Zeitverhalten unter den Aspekten Performanz-, Last-, Stress- und Skalierbarkeitstests. Version 2007 Seite 82 von 136 Januar 2010 20100131
5.3.3.1 Performanztests Es gibt unterschiedliche Arten von Performanztests, je nach betrachteten nicht nicht-funktionalen Anforderungen. Zu diesen Testarten gehren Performanz Last-, Stress- und Skalierbarkeitstests. Performanz-, Performanztests untersuchen die Fhigkeit einer Komponente oder eines Systems, auf Eingaben des Komponente Nutzers oder Systems innerhalb einer definierten Zeit und unter den spezifizierten Bedingungen zu reagieren (siehe auch Lasttests und Stresstests in den folgenden Abschnitten). Dabei variieren die Performanzmessungen je nach Zielsetzung des Tests. So kann die Performanzmessung einer n einzelnen Softwarekomponente die CPU CPU-Zyklen berechnen; bei Client-basierten Systemen lsst sich basierten dagegen die Zeit messen, die das System bentigt, um auf eine bestimmte Nutzeranfrage zu reagieren. Bei Systemarchitekturen, die aus mehreren Komponenten bestehen (beispielsweise agieren. Clients, Servern, Datenbanken) wird die Performanz zwischen den einzelnen Systemkomponenten gemessen, um Engpsse zu identifizieren. 5.3.3.2 Lasttests Lasttests messen die Fhigkeit eines Systems, ansteigende Grade erwarteter, realistische realistischer Systemlasten zu bewltigen, die eine Anzahl paralleler Nutzer als Transaktionsanforderungen generiert. Die durchschnittlichen Antwortzeiten der Nutzer werden in typischen Nutzungsszenarien (Nutzungsprofile) gemessen und analysiert (siehe auch [Splaine01]). Es gibt zwei Untergruppen von Lasttests, solche mit einer realistischen Nutzeranzahl und solche, wo ein hohes Datenvolumen im Vordergrund steht (groe Anzahl von parallelen/gleichzeitigen Nutzern). Lasttests messen sowohl die Antwortzeiten als auch Netzwerkdurchsatz. 5.3.3.3 Stresstests Stresstests untersuchen die Fhigkeit eines Systems, Spitzenlasten an oder ber den spezifizierten Kapazittsgrenzen zu bewltigen. Mit steigender berbelastung sollte die Systemleistung allmhlich, vorhersehbar und ohne Ausfall abnehmen. Vor allem sollte die funktionale Integritt des Systems unter Spitzenlast getestet werden, um mgliche Fehlerzustnde bei der funktionalen Verarbeitung en, oder Dateninkonsistenzen aufzudecken. Mgliches Ziel von Stresstests kann es sein, die Grenze zu erreichen, an der das System tatschlich ausfllt, um so das schwchste Glied in der Kette zu identifizieren. Bei Stresstests ist es erlaubt, dem System rechtzeitig zustzliche Komponenten hinzuzufgen (beispielsweise Speicher, CPU CPU-Kapazitt, Datenbankspeicher). In Spitzentests (spike tests) werden Bedingungen simuliert, die zu pltzlichen extremen Systemlasten fhren. Bei Bounce-Tests wechseln solche Spitzenlasten mit Zeiten geringer Nutzung ab. Die Tests Tests untersuchen, wie gut das System mit diesen Lastnderungen fertig wird, und ob es nach Bedarf Ressourcen in Anspruch nimmt und wieder freigibt (si (siehe auch [Splaine01]). 5.3.3.4 Skalierbarkeitstests Skalierbarkeitstests untersuchen die Fhigkeit eines Systems, zuknftige Effizienzanforderungen zu erfllen, die ber den gegenwrtigen liegen knnen. Ziel dieser Tests ist es zu beurteilen, ob das Ziel System wachsen kann (beispielsweise mit mehr Nutzern oder greren Mengen von gespeicherten Daten), ohne die vereinbarten Grenzen zu berschreiten oder zu versagen. Sind diese Grenzen bekannt, lassen sich Schwellenwerte definieren und in der Produktion berwachen, sodass bei enwerte bevorstehenden Problemen eine Warnung erfolgen kann. 5.3.3.5 Prfung der Ressourcennutzung Effizienztests der Ressourcennutzung bewerten die Verwendung von Systemressourcen Verwendung (beispielsweise Hauptspeicher- und Festplattenkapazitten, Bandbreiten im Netz). Die Verwendung
Version 2007
Seite 83 von 136
Januar 2010 20100131
dieser Ressourcen wird sowohl bei normaler Systemauslastung gemessen als auch in Stresssituationen durch beispielsweise hohe Transaktionsraten oder groe Datenmengen. Transaktionsraten So spielt beispielsweise bei eingebetteten Echtzeitsystemen die Speichernutzung (memory footprint) eine wichtige Rolle bei Performanztests. 5.3.3.6 Spezifikation von Effizienztests Testspezifikationen der Testarten Performanz Last- und Stresstests basieren auf definierten kationen Performanz-, Nutzungsprofilen mit verschiedenen Formen des Nutzungsverhaltens bei der Interaktion mit der Anwendung. Fr eine Anwendung kann es mehrere Nutzungsprofile geben. Die Anzahl der Nutzer pro Nutzungsprofil lsst sich mit Monitorwerkzeugen bestimmen (wenn die tatschliche oder eine vergleichbare Anwendung bereits zur Verfgung stehen), oder durch eine Voraussage. Voraussagen knnen auf Algorithmen basieren oder von der Betriebsor Betriebsorganisation stammen, sie sind besonders wichtig fr die Spezifizierung der Nutzungsprofile bei Skalierbarkeitstests. Nutzungsprofile sind Grundlage der Testflle und werden in der Regel mit Testwerkzeugen generiert. Simulierte Nutzer im Nutzungsprofil werden normalerweise als virtuelle Anwender bezeichnet. werden
5.3.4 Wartbarkeitstests
Wartbarkeitstests untersuchen, wie einfach die Software analysiert, gendert und getestet werden kann. Geeignete Verfahren fr Wartbarkeitstests sind statische Analysen und Checklisten. Wartbarkeitstests 5.3.4.1 Dynamische Wartbarkeitstests Dynamische Wartbarkeitstests untersuchen vorrangig die dokumentierten Verfahren, die fr die dokumentierten Wartung einer Anwendung entwickelt wurden (beispielsweise fr ein Update der Software). Als pdate Testflle dienen Wartungsszenarien, um sicherzustellen, dass die geforderten Service Levels mit den dokumentierten Verfahren erreicht werde knnen. werden Diese Art des Testens ist besonders wichtig bei komplexen Infrastrukturen, bei denen mehrere Abteilungen/Organisationen an den Supportverfahren beteiligt sind. Die Tests knnen Teil der betrieblichen Abnahmetests sein [siehe www.testingstandards.co.uk]. 5.3.4.2 Analysierbarkeit (korrektive Wartung) Bei dieser Art von Wartbarkeitstests wird die Zeit gemessen, die fr Diagnose und Behebung von im System erkannten Problemen ntig ist. Eine einfache Metrik kann der durchschnittliche Zeitaufwand fr Diagnose und Korrektur des Fehlers sein. d 5.3.4.3 nderbarkeit, Stabilitt und Testbarkeit (adaptive Wartung) Die Wartbarkeit eines Systems lsst sich auch auf den Aufwand bezogen messen, der fr nderungen ntig ist (beispielsweise Programmnderungen). Da der bentigte Aufwand von weise mehreren Faktoren abhngt, wie der verwendeten Softwaredesign Methodik (beispielsweise Softwaredesign-Methodik objektorientiert), von Programmierstandards usw., sind auch Analysen oder Reviews fr diese Wartbarkeitstests geeignet. Die Testbarkeit hngt in erster Linie vom Aufwand fr das Testen der ignet. nderungen ab. Die Stabilitt hngt in erster Linie von der Reaktion des Systems auf nderungen ab. Systeme mit niedriger Stabilitt zeigen nach jeder nderung eine groe Anzahl an Folgeproblemen jeder (ripple effect). [ISO9126] [www.testingstandards.co.uk www.testingstandards.co.uk]
5.3.5 Portabilittstests
Portabilittstests untersuchen, wie einfach es ist, eine Software in ihre vorgesehene Umgebung zu bertragen, entweder bei der Erstinstallation oder aus einer bestehenden Umgebung. Bei Version 2007 Seite 84 von 136 Januar 2010 20100131
Portabilittstests werden Austauschbarkeit getestet.
Installierbarkeit,
Koexistenz/Kompatibilitt, Koexistenz/Kompatibilitt,
Anpassbarkeit
und
5.3.5.1 Installationstests Installationstests testen Software fr die Software Installation in einer Zielumgebung. Das kann eine Software-Installation Software sein, mit der ein Betriebssystem auf einem Prozessor installiert wird, oder ein Installationsprogramm (Wizard), mit dem ein Produkt auf einem Client PC verwendet wird. Ziele von Client-PC Installationstests sind Validieren, dass die Software erfolgreich installiert werden kann, indem man die Anweisungen kann, des Installationshandbuchs befolgt (einschlielich der Ausfhrung von Installationsskripten) oder einen Installationswizard nutzt. Dabei sind auch die unterschiedlichen Optionen fr mgliche HW-/SW-Konfigurationen sowie fr verschiedene Installationsstufen (ganz oder Konfigurationen verschiedene teilweise) zu testen. Testen, ob die Installationssoftware richtig mit Fehlerwirkungen umgeht, die bei der Installation auftreten (beispielsweise DLLs nicht geladen werden), ohne das System in einem undefinierten Zustand zu lassen (beispielsweise mit nur teilweise installierter Software oder inkorrekten Systemkonfigurationen). Testen, ob sich eine nur teilweise Installation/Deinstallation der Software abschlieen lsst. Testen, ob ein Installationswizard eine ungl ungltige Hardware-Plattform oder Betriebssystem Plattform BetriebssystemKonfigurationen erfolgreich identifizieren kann. Messen, ob der Installationsvorgang im spezifizierten Zeitrahmen oder mit weniger als der spezifizierten Anzahl von Schritten abgeschlossen werden kann. Validieren, dass sich eine frhere Version installieren oder die Software deinstallieren lsst. n, Nach dem Installationstest wird normalerweise die Funktionalitt getestet, um Fehler aufzudecken, die durch die Installation eingeschleust worden sein knnen (beispielsweise inkorrekte Konfigurationen, (beispielsweise nicht mehr verfgbare Funktionen). Parallel zu den Installationstests laufen in der Regel Benutzbarkeitstest (beispielsweise zur Validierung, dass die Anwender bei der Installation verstndliche Anweisungen und Fehler Fehler-/Meldungen erhalten). 5.3.5.2 Koexistenz Computersysteme, die nicht miteinander interagieren, sind dann kompatibel, wenn sie in derselben Umgebung (beispielsweise auf derselben Hardware) laufen knnen, ohne sich gegenseitig zu knnen, beeinflussen (beispielsweise durch Ressourcenkonflikte). Kompatibilittstests knnen dann durchgefhrt werden, wenn eine neue Software oder eine Aktualisierung in einer neuen Umgebung (beispielsweise auf einem Server) installiert wird, in der bereits Anwendungen installiert sind. installiert Kompatibilittsprobleme knnen entstehen, wenn eine Anwendung als die einzige in einer Umgebung getestet wurde und Inkompatibilitten nicht erkennbar waren, wenn diese Anwendung dann in einer anderen, beispielsweise der Produktionsumgebung, installiert wird, in der bereits andere ispielsweise Anwendungen installiert sind. Typische Ziele von Kompatibilittstests sind Bewertung mglicher negativer Auswirkungen auf die Funktionalitt, wenn Anwendungen in derselben Umgebung geladen werden (beispielsweise Konflikte in der Ressourcennutzung, ng wenn mehrere Anwendungen auf demselben Server laufen), Bewertung der Auswirkungen auf jede Anwendung, die sich aus Modifikationen oder dem Installieren einer aktuelleren Betriebssystemve Betriebssystemversion ergeben. Kompatibilittstests werden normalerweise nach dem erfolgreichen Abschluss der System Systemund Anwenderabnahmetests durchgefhrt.
Version 2007
Seite 85 von 136
Januar 2010 20100131
5.3.5.3 Anpassbarkeitstests Anpassbarkeitstests sollen zeigen, ob eine bestimmte Anwendung in allen geplanten Zielumgebungen keitstests korrekt funktioniert (Hardware, Software, Middleware, Betriebssystem usw.) Fr die Spezifikation der usw.). Anpassbarkeitstests mssen Kombinationen der beabsichtigten Zielumgebungen identifiziert, Zielumgebungen konfiguriert und dem Testteam zur Verfgung gestellt werden. Diese Umgebungen werden dann mit ausgewhlten funktionalen Testfllen getestet, bei denen die verschiedenen Komponenten der Testumgebung geprft werden. Anpassbarkeit kann sich darauf beziehen, dass sich die Software durch Ausfhrung eines definierten Verfahrens auf verschiedene spezifizierte Umgebungen portieren lsst. Beim Testen kann das Verfahren bewertet werden. Anpassbarkeitstests knnen zusammen mit Installierbarkeitstests durchgefhrt werden. Installierbarkeitstests Normalerweise finden anschlieend funktionale Tests statt, um Fehler aufzudecken, die durch das Anpassen der Software an die andere Umgebung entstanden sein knnen. 5.3.5.4 Austauschbarkeitstests Austauschbarkeit drckt aus, ob sich Softwarekomponenten eines Systems gegen andere Komponenten austauschen lassen. Das ist besonders relevant bei Systemen, die kommerzielle Standardsoftwareprodukte fr bestimmte Softwarekomponenten verwenden. Austauschbarkeitstests knnen parallel zu den funktionalen Integrationstests durchgefhrt werden, wenn mehr als eine Komponente alternativ fr die Integration in das Gesamtsystem verfgbar ist. Die Austauschbarkeit lsst sich in technischen Reviews oder Inspektionen bewerten, bei denen Gewicht auf eine klare Definition der Schnittstellen zu mglichen Austauschkomponenten gelegt wird.
Version 2007
Seite 86 von 136
Januar 2010 20100131
6. Review
Begriffe
Audit, IEEE 1028, informelles Review Inspektion, Leiter einer Inspektion, Management , Review, , Management-Review, Moderator, Review, Prfer, technisches Review Walkthrough. Review,
6.1 Einfhrung
Zu einem erfolgreichen Review-Prozess gehren das Planen von Reviews, die Durchfhrung und die Prozess Nachbereitung. Ausbildungsanbieter mssen dafr sorgen, dass die Testmanager ihre Verantwortung Testmanager bei den Planungs- und Nachbereitungsaufgaben verstehen. Tester mssen aktiv am Review Review-Prozess teilnehmen und ihre individuelle Perspektive einbringen. Sie sollten ein formales Review Review-Training erhalten haben, damit sie ihre jewe jeweiligen Rollen bei einem technischen Review-Prozess besser Prozess verstehen. Alle Teilnehmerinnen und Teilnehmer mssen vom Nutzen gut durchgefhrter Reviews berzeugt sein. Wenn sie ordnungsgem durchgefhrt werden, leisten Reviews nicht nur den . grten einzelnen, sondern auch den kosteneffektivsten Beitrag zur gelieferten Qualitt. Ein n, internationaler Standard fr Reviews ist IEEE 1028.
6.2 Grundstze von Reviews

Ein Review ist ein statisches Test Testverfahren. Hauptziel des Reviews ist oft das Aufdecken von Fehlerzustnden. Die Prfer finden Fehler, indem sie die Dokumente direkt untersuchen. Weitere Informationen zu den grundlegenden Review Arten enthalten Abschnitt 3.2 des FoundationReview-Arten Level-Lehrplans (Version 2007) und der folgende Abschnitt 6.3. s Alle Review-Arten werden am besten ausgefhrt, sobald die relevanten Quellendokumente Arten (Dokumente, in denen die Projektanforderungen spezifiziert sind) und die Standards (die im Projekt einzuhalten sind) zur Verfgung stehen. Fehlt noch ein Dokument oder ein Standard, so lassen sich r Fehler und Inkonsistenzen in der Gesamtdokumentation nicht aufdecken, sondern nur in einem einzelnen Dokument. Den Prfern muss das zu prfende Dokument mit einem geeigneten Vorl Vorlauf zur Verfgung gestellt werden, sodass sie ausreichend Zeit haben, um sich damit vertraut zu machen. Jede Dokumentart kann Gegenstand eines Reviews sein, beispielsweise Quellcode, Anforderungsspezifikationen, Konzepte, Testkonzepte, Testdokumentationen usw. Das dynamische Testen findet normalerweise nach dem Review des Quellcodes statt und sucht die Fehler, die sich in der statischen Prfung nicht finden lassen. Ein Review kann drei mgliche Ergebnisse haben: Das Dokument lsst sich ohne oder mit nur geringfgigen nderungen verwenden. geringfgigen Das Dokument muss gendert werden, aber es ist kein weiteres Review ntig. Das Dokument muss grndlich gendert werden, und ein weiteres Review ist ntig. Rollen und Verantwortlichkeiten der Teilnehmer eines typischen formalen Reviews beschreibt der formalen Foundation-Level-Lehrplan. Es sind Manager, Moderator oder Leiter, Autor, Prfer und Protokollant. . Auerdem knnen Entscheidungstrger oder Betroffene und Vertreter der Kunden oder Nutzer am Review teilnehmen. Eine zustzliche optionale Rolle bei einigen Inspektionen ist die des Vorlesers. Er oder sie soll Textpassagen aus den Abschnitten der Arbeitsergebnisse in der Sitzung mit eigenen Worten ausdrcken und zusammenfassen. Zustzlich zu den erwhnten Rollen beim Review knnen
Version 2007
Seite 87 von 136
Januar 2010 20100131
einzelne Prfer jeweils eine bestimmte fehlerorientierte Aufgabe bernehmen und sich bei der Suche inzelne auf bestimmte Fehlerarten konzentrieren. Auf ein einzelnes Produkt lassen sich mehrere Review Arten anwenden. So kann beispielsweise ein Review-Arten Team in einem technischen Review entscheiden, welche Funktionalitten in der nchsten Iteration chen implementiert werden sollen. Danach knnte eine Inspektion der Spezifikationen fr die eingearbeiteten Funktionalitten durchgefhrt werden.
6.3 Review-Arten
Im Foundation-Level-Lehrplan wurden folgende Review Review-Arten eingefhrt: Informelles Review Walkthrough Technisches Review Inspektion In der Praxis knnen auch Mischformen aus diesen Review Arten vorkommen, wie ein technisches Review-Arten Review, das einen Satz von Regeln nut nutzt.
6.3.1 Management-Review und Audit Review

Zustzlich zu den im Foundation-Level Level-Lehrplan eingefhrten Review-Arten beschreibt IEEE Standard Arten 1028 auch die folgenden: Management-Review Audit Schlsselmerkmale eines Management es Management-Reviews: Hauptzwecke sind: Fortschritt berwachen, Status beurteilen, Entscheidungen ber zuknftige Manahmen treffen. Durchgefhrt wird es von Managern bzw. fr Manager mit direkter Verantwortung fr das Projekt oder System. Auerdem wird es durchgefhrt von bzw. fr einen Betroffenen oder Entscheidungstrger, beispielsweise gehobenes Management oder Direktor. Es wird geprft, ob Plne konsistent eingehalten werden oder es Abweichungen gibt, und es prft, wird festgestellt, ob die installierten M Managementverfahren adquat sind. Es enthlt die Bewertung von Projektrisiken. Das Ergebnis nennt die durchzufhrenden Manahmen und zu lsenden Probleme. Es wird erwartet, dass sich die Teilnehmer auf die Sitzungen vorbereiten, Entscheidungen werden dokumentiert. Hinweis: Testmanager sollten an den Management Reviews teilnehmen bzw. Management Management-Reviews Management-Reviews zum Testfortschritt ansetzen. Audits sind sehr formal und werden in der Regel dann durchgefhrt, wenn Konformitt mit bestimmten Erwartungen nachgewiesen werden soll, beispielsweise Konformitt mit einem geltenden Standard den oder einer vertraglichen Verpflichtung. Audits sind daher die am wenigsten effektive Methode zum Aufdecken von Fehlerzustnden. Schlsselmerkmale eines Audits: Hauptzweck ist die unabhngige Bewertung der Konformitt mit bestimmten Verfahren, unabhngige Vorschriften, Standards usw. Der Leiter des Audits ist fr das Audit verantwortlich und bernimmt die Moderation. Seite 88 von 136 Januar 2010 20100131
Version 2007
Die Prfer sammeln Beweise fr die Konformitt durch Interviews, Beobachtungen und die Prfung von Dokumenten. Zu den Ergebnissen des Audits gehren Beobachtungen, Empfehlungen, Abhilfemanahmen und eine abschlieende Beurteilung (bestanden/nicht bestanden).
6.3.2 Reviews von bestimmten Arbeitsergebnissen

Reviews lassen sich anhand ihrer Arbeitsergebnisse oder der Aktivitten benennen, die geprft werden, beispielsweise: Review des Vertrags Review der Anforderungen Review des Designs Preliminary Design Review Critical Design Review Abnahme-Review/Qualifizierungs alifizierungs-Review Betriebsbereitschafts-Review Review Ein Review des Vertrags kann im Zusammenhang mit einem vertraglich festgelegten Meilenstein durchgefhrt werden; typischerweise ist es ein Management-Review fr sicherheitskritische oder Review sicherheitsrelevante Systeme. Teilnehmer sind Manager, Kunden und technische Mitarbeiter. e Ein Review der Anforderungen kann ein Walkthrough, ein technisches Review oder eine Inspektion sein. Das Review kann Anforderungen an die Sicherheit und an die Systemstabilitt sowie f Systemstabilitt, funktionale und nicht-funktionale Anforderungen prfen. Ein Review der Anforderungen kann auch funktionale . Abnahmekriterien und Testbedingungen enthalten. Reviews des Designs sind normalerweise technische Reviews oder Inspektionen, an denen technisches Personal und Kunden oder Betroffene teilnehmen. Im Preliminary Design Review werden den erste Anstze fr technischen Entwurf und Tests geprft, whrend das Critical Design Review alle vorgeschlagenen Entwurfslsungen, einschlielich Testfllen und szenarien abdeckt. Bei Abnahme-Reviews geht es um die Genehmigung des Systems durch das Management. Sie Reviews werden auch als Qualifizierungs-Reviews bezeichnet und sind normalerweise entweder Management Reviews ManagementReviews oder Audits.
6.3.3 Formales Review durchfhren

Im Foundation-Level-Lehrplan werden die sechs Phasen eines formalen Reviews beschrieben: Planung, Kick-off, Individuelle Vorbereitung, Review Sitzung, berarbeitung und Nachbereitung. Fr off, Review-Sitzung, ein Arbeitsergebnis, das Gegenstand des Reviews ist, sollte ein Prfer mit geeigneter Qualifikation ausgewhlt werden, beispielsweise ein Testkonzept fr einen Testmanager, fachliche Anforderungen oder ein Testentwurf fr einen Test Analyst, und eine Funktionsspezifikation, Testflle oder Testskripte fr einen Technical Test Analyst.
6.4 Einfhrung von Reviews

Zur erfolgreichen Einfhrung von Reviews in einer Organisation sind die folgenden Schritte notwendig (nicht unbedingt in dieser Reihenfolge): Untersttzung durch das Management sicherstellen Information der Manager ber Kosten, Nutzen und Implementierungsfragen mation Seite 89 von 136 Januar 2010 20100131
Version 2007
Auswahl und Dokumentieren von Review Review-Verfahren, -templates und infrastruktur templates (beispielsweise der Datenbank fr Review Review-Metriken) Review-Techniken und -verfahren trainieren verfahren Um Untersttzung der Mitarbeiter werben, die die Reviews durchfhren werden oder deren Arbeitsergebnisse in Reviews geprft werden Pilot-Reviews abhalten Nutzen von Reviews in Form von Kosteneinsparungen darstellen Reviews fr die wichtigsten Dokumente durchfhren, beispielsweise Anforderungen, Vertrag, beispielsweise Planungsdokumente usw. Wie erfolgreich die Einfhrung von Reviews ist, lsst sich anhand vom Metriken feststellen, wie die Reduzierung oder Vermeidung von Kosten fr das Beheben von Fehlerwirkungen und/oder deren Folgen, die durch frhes Aufdecken von Fehlerzustnden und Beheben von Fehlerwirkungen e eingespart werden. Einsparungen lassen sich auch in Zeiteinheiten messen, die durch frhes . Aufdecken und Beheben von Fehlerwirkungen eingespart werden. Review-Prozesse sollten kontinuierlich berwacht und im Lauf der Zeit optimiert werden. Manager tinuierlich sollten sich bewusst machen, dass das Erlernen einer neuen Review Technik eine Investition ist, Review-Technik deren Nutzen sich nicht sofort auszahlt, sondern im Laufe der Zeit deutlich wchst.
6.5 Erfolgsfaktoren fr Reviews sfaktoren

Es gibt eine ganze Reihe von Faktoren, die zum Erfolg von Reviews beitragen. Reviews sind zwar nicht schwierig in ihrer Durchfhrung, knnen aber ihr Ziel verfehlen, wenn diese Faktoren nicht beachtet werden. Technische Faktoren Stellen Sie sicher, dass der fr die Art des Reviews definierte Prozess korrekt befolgt wird, besonders bei den eher formalen Review Arten wie beispielsweise Inspektionen. Review-Arten Halten Sie die Kosten der Reviews (einschlielich des Zeitaufwands) und den erzielten Zeitaufwands) Nutzen fest. Prfen Sie in Reviews vorlufige Entwrfe und Teildokumente, um Fehlermuster zu identifizieren, bevor sie in das Gesamtdokument eingehen. Stellen Sie sicher, dass das Dokument oder Teildokument reif fr ein Review ist, bevor Sie mit dem Review-Prozess beginnen (wenden Sie Eingangsbedingungen an). Prozess Verwenden Sie organisationsspezifische Checklisten fr bliche Fehler. Setzen Sie je nach Zielsetzung ggf. mehr als nur eine Review-Art ein, beispielsweise fr die Art endgltige Fertigstellung des Dokuments, technische Verbesserung, Informationsaustausch , oder Fortschrittsmanagement. Prfen Sie vor einem Management Review zur Bewilligung wichtiger Projektbudgets alle Management-Review Dokumente durch Review oder Inspektion, die Grundlage fr wichtige Entscheidungen sind, beispielsweise Angebot, Vertrag oder bergeordnete Anforderungen. Untersuchen Sie versuchsweise einen begrenzten Teil des Dokuments. Ermutigen Sie dazu, die wichtigsten Fehlerzustnde aufzuspren, und konzentrieren Sie sich dabei auf den Inhalt und nicht auf das Format. bei Verbessern Sie den Review Review-Prozess kontinuierlich.
Organisatorische Faktoren
Version 2007
Seite 90 von 136
Januar 2010 20100131
Stellen Sie sicher, dass das Management ausreichend Zeit fr die Review Aktivitten bewilligt, Review-Aktivitten auch unter Termindruck. Denken Sie daran: Zeit- und Kostenaufwand sind nicht proportional zur Menge der gefundenen Fehler. Planen Sie ausreichend Zeit ein fr die Nacharbeiten zum Beheben identifizierter Fehler. Verwenden Sie die Metriken der Reviews niemals fr personenbezogene Leistungsbeurteilungen. Stellen Sie sicher, dass die richtigen Personen an den jeweiligen Review Arten beteiligt sind. Review-Arten Stellen Sie Schulungen in Review Techniken zur Verfgung, besonders fr die formaleren Review-Techniken Arten von Reviews. Untersttzen Sie ein Forum fr Review Review-Leiter zum Austausch von Erfahrungen und Ideen. ter Stellen Sie sicher, dass alle an Reviews teilnehmen, und dass alle ein Review ihrer Dokumente bekommen. Nutzen Sie fr die wichtigsten Dokumente die formalsten Review Review-Techniken. Stellen Sie sicher, dass das R Review-Team ausgewogen mit Personen unterschiedlicher Team Fhigkeiten und Erfahrungen besetzt ist. Untersttzen Sie Manahmen zur Prozessverbesserung, um systemische Probleme zu berwinden. Erkennen Sie die Verbesserungen an, die durch den Review Review-Prozess erreicht wurden. cht
Personenbezogene Aspekte Machen Sie den Betroffenen klar, dass bei einem Review Fehler zu erwarten sind, und dass Betroffenen Zeit fr Nacharbeit und Wiederholung des Reviews einzuplanen ist. Stellen Sie sicher, dass das Review fr die Autorin/den Autor eines Dokuments eine positive Erfahrung ist. Begren Sie die Fehleridentifikation in einer offenen Atmosphre ohne Schuldzuweisungen. Stellen Sie sicher, dass Kommentare konstruktiv, hilfreich und objektiv sind, und nicht subjektiv. iew Fhren Sie kein Review durch, wenn der Autor nicht zustimmt oder nicht dazu bereit ist. Ermutigen Sie alle dazu, sich mit den wichtigsten Aspekten des zu prfenden Dokuments eingehend auseinanderzusetzen. Fr weitere Informationen ber Reviews und Inspektionen siehe [Gilb9 [Gilb93].
Version 2007
Seite 91 von 136
Januar 2010 20100131
7. Fehler- und Abweichungsmanagement

Begriffe
Abweichung, Abweichungsprotokollierung, Anomalie, Fehlerwirkung, Fehlerzustand, Fehlhandlung, Anomalie, Grundursachenanalyse, IEEE 829, IEEE 1044, IEEE 1044.1, Configuration Control Board, Prioritt, , 1044, Schweregrad.
7.1 Einfhrung
Testmanager und Tester mssen mit dem Prozess des Fehler und Abweichungsmanagements Fehlervertraut sein. Testmanager konzentrieren sich vor allem auf diesen Prozess, mit Methoden zum ager Erkennen, Verfolgen und Beheben von Fehlerzustnden. Tester dagegen befassen sich vor allem damit, Probleme richtig aufzuzeichnen, die sie in ihren jeweiligen Testbereichen finden. Fr jeden Schritt im Lebenszyklus haben Test Analysts und Technical Test Analysts eine unterschiedliche Ausrichtung. Test Analysts bewerten das Verhalten des Systems aus der geschftlichen und Anwenderperspektive, beispielsweise: Wrden Nutzer wissen, was zu tun ist, wenn diese Meldung tun erscheint, oder wenn das System sich so verhlt? Technical Test Analysts bewerten das Verhalten der Software selbst, sie werden das Problem eher unter technischen Gesichtspunkten untersuchen, indem sie beispielsweise die gleiche Fehlerwirkung auf verschiedenen Plattformen oder mit unterschiedlichen Speicherkonfigurationen testen.
7.2 Wie lsst sich ein Fehlerzustand aufdecken?

Eine Abweichung ist ein unerwartetes Ereignis, das nher untersucht werden muss. Das Erkennen muss. einer Fehlerwirkung, die durch einen Fehlerzustand verursacht wurde, ist eine Abweichung. Eine Abweichung muss kein Fehler sein und kann zur Erstellung eines Abweichungsberichts fhren oder nicht. Ein Fehlerzustand ist ein tatschliches Problem, das festgestellt wurde und durch eine Problem, nderung gelst werden muss. Ein Fehlerzustand lsst sich durch statische Tests finden; eine Fehlerwirkung dagegen nur durch dynamisches Testen. Fr jede Phase des Softwarelebenszyklus sollte es eine Methode zu zum Erkennen und Beseitigen mglicher Fehlerwirkungen geben. Whrend der Entwicklungsphase sollten das beispielsweise Code-Reviews und Reviews des Designs zum Aufdecken von Fehlerzustnden Reviews sein. Bei dynamischen Tests werden Testflle zum Finden von Fehlerwirkungen verwendet. Je frher Fehlerwirkungen eine Fehlerwirkung erkannt und korrigiert wird, desto geringer sind die Kosten der Qualitt fr das Gesamtsystem. Hinweis: Fehlerwirkungen knnen sowohl im Testobjekt als auch in den Testmitteln auftreten.
7.3 Fehlerlebenszyklus
Alle Fehlerzustnde haben einen Lebenszyklus, auch wenn einige Fehler nicht alle Phasen durchlaufen. Der Fehler- und Abweichungslebenszyklus (gem IEEE 1044 1993) besteht aus vier 1044-1993) Schritten: Schritt 1: Erkennung (Recognition) Schritt 2: Analyse (Investigation)
Version 2007
Seite 92 von 136
Januar 2010 20100131
Schritt 3: Bearbeitung3 (Action) Schritt 4: Abschluss (Disposition Disposition) In jedem dieser Schritte gibt es drei Aktivitten zur Informationserfassung: Aufzeichnen Klassifizieren Auswirkungen identifizieren
7.3.1 Schritt 1: Erkennung (Recognition)

Der Erkennungsschritt beginnt, wenn ein mglicher Fehler (eine Abweichung) entdeckt wird. Das kann in jeder Phase des Softwarelebenszyklus sein. Zum Zeitpunkt der Entdeckung werden die Entdeckung Datenelemente aufgezeichnet, die den Fehler kennzeichnen. Dazu gehren Informationen ber die Umgebung, in der der Fehler beobachtet wurde, meldende Organisation oder Person, Beschreibung, Zeitpunkt und ggf. Anbieter. Beim Erkennungsschritt wird der mglichen Fehler anhand bestimmter Erkennungsschritt Merkmale klassifiziert, wie Projektaktivitt, Projektphase, vermutete Ursache, Wiederholbarkeit, Symptom(e) und Produktstatus als Folge der Anomalie. Mit diesen Informationen lassen sich die Auswirkungen anhand des Fehlerschweregrads und der Folgen fr Projektzeitplan und Projektkosten nd bewerten.
7.3.2 Schritt 2: Analyse (Investigation)

Nach der Erkennung werden mgliche Fehlerzust Fehlerzustnde untersucht. Dieser Schritt wird dazu genutzt, d eventuelle weitere Probleme in diesem Zusammenhang aufzudecken und Lsungsvorschlge zu erarbeiten. Eine Lsung kann auch sein, keine Manahmen einzuleiten (wenn beispielsweise der potenzielle Fehler nicht mehr als tatschlicher Fehler betrachtet wird). In diesem Schritt werden betrachtet zustzliche Daten aufgezeichnet und Fehlerklasse und Auswirkungen aus dem vorherigen Schritt erneut bewertet.
7.3.3 Schritt 3: Bearbeitung (Action)

Der Manahmenschritt arbeitet mit den Ergebnissen der Untersuchung. Sie erstreckt sich sowohl auf itet Manahmen, die zur Behebung des Fehlers notwendig sind, als auch auf Manahmen, mit denen sich Prozesse und Methode berprfen und verbessern lassen, damit hnliche Fehler in Zukunft nicht mehr vorkommen. Nach jeder nderung mssen Regressions und Fehlernachtests vorgenommen Regressionsund der Testfortschritt kontrolliert werden. In diesem Schritt werden zustzliche Daten aufgezeichnet und Fehlerklasse und Auswirkungen aus dem vorigen Schritt er erneut bewertet.
7.3.4 Schritt 4: Abschluss (Disposition)

Die Abweichung erreicht damit den Abschlussschritt, in der etwaige weitere Datenelemente aufgezeichnet werden und der Abschluss klassifiziert wird als: geschlossen, zurckgestellt, hlossen, zusammengefasst oder an ein anderes Projekt verwiesen.
7.4 Pflichtfelder fr die Erfassung von Fehler und Abweichungen Fehlern

IEEE Standard 1044-1993 legt eine Reihe von Pflichtfeldern fest, die zu verschiedenen Zeiten im 1993 Fehlerlebenszyklus gefllt werden. Er definiert auch eine groe Menge optionaler Felder. Gem IEEE Standard 1044.1 ist es bei der Implementierung von IEEE Standard 1044 1993 zulssig, 1044-1993
3
Synonym: Behebung Version 2007 Seite 93 von 136 Januar 2010 20100131
Begriffe in einem Unternehmen transparent auf die Begriffe des IEEE Standards fr die em IEEE-Standards Abweichungsfelder abzubilden. IEEE Standard 1044 1993 lsst sich so einhalten, ohne dass man sich 1044-1993 bis ins Detail an die vorgegebene Terminologie halten muss. Die Konformitt mit dem IEE IEEE-Standard erlaubt den Vergleich von Informationen ber Abweichungen zwischen unterschiedlichen Unternehmen und Organisationen. Unabhngig davon, ob die Konformitt mit dem IEEE Standard ein Projektziel ist, sollen die IEEE-Standard Abweichungsfelder ausreichend Informationen fr entsprechende Manahmen liefern. Ein fr Informationen Manahmen geeigneter Abweichungsbericht ist vollstndig, kurz und prgnant, richtig, objektiv. Der Bericht muss nicht nur das Beheben des spezifischen Fehlerzustands ermglichen, er muss auch die notwendigen Informationen fr eine korrekte Klassifizierung des Fehlerzustands, eine gen Risikoanalyse und ggf. eine Prozessverbesserung enthalten.
7.5 Metriken und Abweichungsmanagement

Die Informationen ber Abweichungen mssen geeignet sein fr die Testfortschrittsberwachung, die Analyse der Fehlerdichte, Messungen gefundener gegenber behobenen Fehlerzustnde und Fehlerzustnden Konvergenzmetriken (offen/geschlossen). Auerdem sollen Abweichungsinformationen die Initiativen sollen zur Prozessverbesserung untersttzen indem sie die phasenspezifischen Informationen verfolgen sie untersttzen, verfolgen; sollen eine Grundursachenanalyse liefern und Fehlertendenzen als Input fr strategische Manahmen zur Risikobeherrschung identifizieren. herrschung
7.6 Abweichungen kommunizieren

Das Abweichungsmanagement braucht eine effektive Kommunikation ohne gegenseitige Schuldzuweisungen. Es untersttzt das Sammeln und Interpretieren von objektiven Inform Informationen. Damit die Beziehungen zwischen den Menschen, die Fehler berichten, und denjenigen, die sie beheben, professionell bleiben, mssen Abweichungsberichte korrekt sein, die Klassifizierungen stimmen, und unverkennbare Objektivitt ist ntig. Tester knnen gefragt werden, welche Wichtigkeit knnen ein Fehlerzustand hat, und sollten dann objektiv die verfgbaren Informationen beisteuern. Besprechungen zur Abweichungsbeurteilung (triage meetings) knnen bei einer angemessenen Priorisierung helfen. Ein Fehlerverfo Fehlerverfolgungs-Werkzeug kann und sollte eine gute Kommunikation nicht Werkzeug ersetzen. Genauso wenig sollten aber die Besprechungen zur Abweichungsbeurteilung als Ersatz fr ein gutes Fehlerverfolgungs-Werkzeug dienen. Ein effektiver Fehlerverfolgungs Prozess braucht Werkzeug Fehlerverfolgungs-Prozess beides: Kommunikation und eine angemessene Untersttzung durch Werkzeuge. des:
Version 2007
Seite 94 von 136
Januar 2010 20100131
8. Standards in der Testprozess Testprozess-Verbesserung

Begriffe
Capability Maturity Model (CMM), Capability Maturity Model Integration (CMMI), Test Maturity Model , (TMM), Test Maturity Model Integrated (TMMi), Test Process Improvement (TPI). ,
8.1 Einfhrung
Verschiedene Quellen untersttzen die Einfhrung und kontinuierliche Verbesserung von Testprozessen. Dieses Kapitel befasst sich zunchst mit den Standards, die eine ntzliche und sich manchmal obligatorische Informationsquelle fr eine ganze Reihe von Testthemen sind. Fr Testmanager und Test Analysts ist es ein Lernziel zu wissen, welche Standards es gibt und wo oder wie sie anzuwenden sind. Ausbildungsanbieter sollten die fr das jeweilige Trainingsmodul besonders en relevanten Standards herausstellen. Ist ein Testprozess eingefhrt, sollte er kontinuierlich verbessert werden. Abschnitt 8.3 beleuchtet zunchst allgemeine Themen zur Testprozessverbesserung; es folgt eine Einfhrung in einige st spezifische Modelle fr die Testprozessverbesserung. Testmanager mssen den gesamten Inhalt dieses Abschnitts verstehen, aber auch fr Test Analysts und Technical Test Analysts ist es wichtig zu Analysts wissen, welche Testprozessverbesserungs Testprozessverbesserungs-Modelle es gibt, weil Test Analysts und Technical Test e Analysts eine Schlsselrolle bei der Implementierung der Verbesserungen spielen.
8.2 Normen und Standards

Dieser Lehrplan nennt einige Standards, wie schon der Foundation-Level-Lehrplan. Es gibt Standards r . zu vielen Softwarethemen: Lebenszyklus der Software und in der Softwareentwicklung Softwaretesten und Methoden Softwarekonfigurationsmanagement Softwarewartung Qualittssicherung Projektmanagement Anforderungen Programmiersprachen Softwareschnittstellen Abweichungsmanagement Es ist nicht Sinn und Zweck dieses Lehrplans, bestimmte Standards aufzulisten oder zu empfehlen. Tester sollten aber wissen, wie Standards entstehen und wie sie in der Anwendungsumgebung entstehen einzusetzen sind. Standards knnen aus unterschiedlichen Quellen stammen: Internationale Standards oder solche mit internationalen Zielsetzungen Nationale Standards oder nationale Anwendung internationaler Stan Standards Branchenspezifische Standards, fr die internationale oder nationale Standards fr bestimmte Industriezweige angepasst oder eigene Standards fr bestimmte Branchen entwickelt wurden Bei der Anwendung von Standards sind verschiedene Aspekte zu beachten, die in diesem Abschnitt beachten, genauer beschrieben sind. Version 2007 Seite 95 von 136 Januar 2010 20100131
8.2.1 Allgemeine Aspekte von Standards

8.2.1.1 Quellen der Standards Standards werden von Expertinnen und Experten erstellt und spiegeln ihr kollektives Wissen wider. Es gibt zwei Hauptquellen internationaler Standards: IEEE und ISO (siehe 8.2.2). Darber hinaus stehen . wichtige nationale und branchenspezifische Standards zur Verfgung. Tester sollten wissen, welche Standards fr ihr Testumfeld und ihren Testkontext zutreffen. Das kontext knnen formale Standards sein (international, national oder branchenspezifisch), oder unternehmensinterne Standards und empfohle empfohlene Praktiken. Da Standards sich weiterentwickeln und ndern, ist es fr die Konformitt wichtig, immer die jeweils gltige Version des Standards anzugeben (Datum der Verffentlichung). Fehlt Datum oder Version in einem Verweis auf einen Standard, geht man von der aktuellen Version aus. 8.2.1.2 Ntzlichkeit von Standards Standards untersttzen die konstruktive Qualittssicherung, die das Minimieren von Fehlern anstrebt ersttzen und weniger ihre Aufdeckung beim Testen (wie die analytische Qualittssicherung). Nicht alle Standards sind fr alle Projekte relevant; Informationen in einem Standard knnen fr ein Projekt knnen ntzlich sein, aber auch hinderlich. Wenn Tester einen Standard um des Standards willen einhalten, wird ihnen das nicht helfen, mehr Fehler in einem Arbeitsprodukt aufzudecken [Kaner02]. Normen und Standards knnen aber ein Referenzrahmen sein und eine Basis fr die Definition von Testlsungen Referenzrahmen bieten. 8.2.1.3 Konsistenz und Konflikte Einige Standards lassen eine Konformitt mit anderen Standards vermissen oder geben widersprchliche Definitionen. Die Anwender von Standards entscheiden, wie ntzlich ein Standard in der eigenen Umgebung und im Kontext ist.
8.2.2 Internationale Standards

8.2.2.1 ISO ISO [www.iso.org] ist die Abkrzung fr: International Standards Organization (krzlich umbenannt in International Organization for Standardization). ISO setzt sich zusammen aus Mitgliedern verschiedener nationaler Organisationen, die fr die Standardisierung in ihrem Land reprsentativ sind. Die internationale Organisation hat einige hilfreiche Standards und Normen fr Softwaretester . herausgegeben: ISO 9126:1998, jetzt aufgeteilt in die folgenden Standards und technischen Berichte (TR, Technical Report): 1:2001 engineering Product quality Part 1: Quality model ISO/IEC 9126-1:2001 Software engineer ISO/IEC TR 9126-2:2003 Software engineering Product quality Part 2: External 2:2003 metrics 3:2003 metrics ISO/IEC TR 9126-3:2003 Software engineering - Product quality Part 3: Internal metri ISO/IEC TR 9126-4:2004 Software engineering Product quality Part 4: Quality in use 4:2004 metrics ISO 12207:1995/Amd 2:2004 Systems and Software Engineering Software Lif /Amd Lifecycle Processes ISO/IEC 155044-2:2003 Information technology Process assessment Part 2: Performing an assessment
ISO 15504 ist auch bekannt unter dem Begriff SPICE, der vom SPICE Projekt abgeleitet wurde. SPICE-Projekt Version 2007 Seite 96 von 136 Januar 2010 20100131
Die Liste ist nicht vollstndig; weitere ISO Standards knnen fr einen bestimmten Testkontext und ISO-Standards -umgebung gelten. 8.2.2.2 IEEE IEEE [www.ieee.org] ist die Abkrzung fr: Institute of Electrical and Electronics Engineers, einen Berufsverband mit Sitz in den Vereinigten Staaten. Nationale Reprsentanten dieser Organisation gibt es in mehr als hundert Lndern. IEEE hat einige hilfreiche Standards und Normen fr Softwaretester herausgegeben: IEEE 610:1991 IEEE Standard computer dictionary, eine Zusammenstellung von IEEE IEEEStandard-Computerglossaren Computerglossaren IEEE 829:1998 IEEE Standard for software test documentation IEEE 1028:1997 IEEE Standard for software reviews IEEE 1044:1995 IEEE Guide to classification for software anomalies Die Liste ist nicht vollstndig; weitere IEEE Standards knnen fr einen bestimmten Testkontext und g; IEEE-Standards -umgebung gelten.
8.2.3 Nationale Standards

Viele Lnder haben eigene spezifische Standards, von denen einige fr das Softwaretesten anwendbar und/oder ntzlich sind Der britische BS 7925-2:1998 Software testing. Software sind. component testing ist ein solcher Standard. Er liefert Informationen fr viele der in diesem Lehrplan erluterten Testverfahren: quivalenzklassenbildung Grenzwertanalyse Zustandsbasierter Test Ursache-Wirkungs-Graph-Analyse Analyse Anweisungstest Zweigtest/Entscheidungsberdeckungstest Bedingungstest Zufallstest BS 7925-2 enthlt auch eine Beschreibung fr das Komponententesten. 2
8.2.4 Branchenspezifische Standards

Standards gibt es auch fr verschiedene technische Bereiche. Manche Branchen passen andere Standards an die eigene technische Fachrichtung an. Auch hier gibt es interessante Aspekte fr das Softwaretesten, fr Softwarequalitt und -entwicklung. 8.2.4.1 Avioniksysteme Der branchenspezifische Standard RTCA DO DO-178B/ED 12B Software Considerations in Airborne Systems and Equipment Certification ist anwendbar auf Software fr die zivile Luftfahrt. Der Standard gilt auch fr Software, mit der Software fr die zivile Luftfahrt erstellt oder verifiziert wird. Die United States Federal Aviation Administration (FAA) und die internationale Joint Aviation Authorities (JAA) schreiben fr Avionik-Software bestimmte strukturelle Abdeckungskriterien vor, je nach Kritikalitt der Software zu testenden Software:
Kritikalitt Mgliche Auswirkung bei Versagen Bentigte strukturelle berdeckung
Version 2007
Seite 97 von 136
Januar 2010 20100131
Kritikalitt
Mgliche Auswirkung bei Versagen
Bentigte strukturelle berdeckung Definierte Bedingungsberdeckung, Entscheidungen und Anweisungen
A Katastrophal
Verhindert die sichere Fortsetzung des F Flugs und die Landung groe Verminderung von Sicherheit und Funktionsfhigkeit Besatzung kann mglicherweise ihre Aufgaben nicht korrekt und vollstndig ausfhren tndig schwere Verletzungen oder Verletzungen mit Todesfolge bei einer kleinen Zahl von Flugzeuginsassen bedeutende Verminderung der Sicherheit bedeutend erhhte Arbeitsbelastung der Besatzung Unannehmlichkeiten fr Flugzeuginsassen, einschlielich hmlichkeiten Verletzungen leichte Verminderung der Sicherheitsmargen und der Funktionsfhigkeit leicht erhhte Arbeitsbelastung der Besatzung einige Unannehmlichkeiten fr die Flugzeuginsas Flugzeuginsassen keine Auswirkung auf die Funktionsfhigkeit des Flugzeugs keine erhhte Arbeitsbelastung der Besatzung
B gefhrlich/ schwer wiegend bis bedeutend C bedeutend D geringfgig E keine Auswirkung
Entscheidungen und Anweisungen
Anweisungen
keine
keine
Das angemessene Niveau struktureller berdeckung hngt ab von der Kritikalittsstufe der Software, die fr den Einsatz in der zivilen Luftfahrt zu zertifizieren ist. nsatz 8.2.4.2 Raumfahrtindustrie Einige Industriezweige nutzen abgenderte und andere angepasste Standards fr die eigene Branche. Das hat die Raumfahrtindustrie mit ihrem Standard ECSS (European Cooperation on Space Standardization, [www.ecss.org]) getan. Je nach Kritikalitt der Software empfiehlt der ECSS ECSSStandard Methoden und Verfahren, die mit den ISTQB Lehrplnen fr Foundation und Advanced Level bereinstimmen, u.a: SFMECA - Software-Fehlermglichkeits Einfluss- und Kritikalitts-Analyse Fehlermglichkeits-, SFTA - Softwarefehlerbaum Softwarefehlerbaum-Analyse HSIA - Hardware Software Interaction Analysis (Hardware (Hardware-Software-Interaktionsanalyse) Interaktionsanalyse) SCCFA - Software Common Cause Failure Analysis (Analyse der gemeinsamen Ursachen von Ausfllen)
8.2.4.3 Food & Drug Administration (FDA) Fr medizinische Systeme, die Title 21 CFR Part 820 unterliegen, empfiehlt die US USamerikanische Bundesbehrde zur berwachung von N Nahrungs- und Arzneimitteln (FDA (FDA) bestimmte strukturelle und funktionale Testverfahren. Auerdem empfiehlt die FDA Teststrategien und grundstze, die mit den ISTQB Lehrplnen fr grundstze, Foundation und Advanced Level bereinstimmen.
8.2.5 Sonstige Standards

Es gibt sehr viele Standards fr die verschiedenen Industriezweige. Einige sind Anpassungen an die eigene Branche oder das eigene Fachgebiet; andere gelten fr bestimmte Aufgaben oder erklren, wie ein Standard anzuwenden ist.
Version 2007
Seite 98 von 136
Januar 2010 20100131
Tester mssen die verschiedenen Standards (einschlielich firmeninterner Standards, empfohlene Praktiken usw.) in ihrer Branche, ihrem Fachbereich oder Kontext kennen. Manchmal sind die gltigen Standards hierarchisch nach ihrem Geltungsbereich fr bestimmte Vertrge festgelegt. Testmanager bestimmte mssen wissen, welche Standards eingehalten werden mssen, und sie mssen auf angemessene Konformitt achten.
8.3 Testverbesserungs-Prozess Prozess

So wie das Testen dazu dient, die Software zu verbessern, werden Softwarequalitts verbessern, Softwarequalitts-Prozesse gewhlt und eingesetzt, um den Softwareentwicklungs Prozess (und die daraus resultierenden Softwareentwicklungs-Prozess Arbeitsergebnisse) zu verbessern. Prozessverbesserung ist auch fr Testprozesse mglich. Es gibt unterschiedliche Mglichkeiten und Methoden, durch die das Testen von Software und von Systemen eiten mit Software verbessert werden kann. Diese Methoden haben das Ziel, den Prozess (und damit die Arbeitsergebnisse) zu verbessern, indem sie Richtlinien und Einsatzbereiche fr die Verbes Verbesserungen zur Verfgung stellen. Das Testen macht oft einen wesentlichen Teil der Gesamtkosten eines Projekts aus, trotzdem findet der Testprozess in den diversen Modellen zur Softwareprozessverbesserung, wie CMM (der Vorgnger von CMMI) und.CMMI (siehe unt CMMI unten), nur begrenzte Beachtung. Testprozessverbesserungs-Modelle, wie Test Maturity Model (TMM), Systematic Test and Evaluation e, Process (STEP), Critical Testing Processes (CTP und Test Process Improvement (TPI) wurden ), (CTP) entwickelt, um diese Lcke zu schlieen. Die Modelle TPI und TMM liefern ein gewisses Ma an organisationsbergreifenden Metriken fr Benchmark Benchmark-Vergleiche. Es gibt in der Industrie heute viele Verbesserungsmodelle. Neben den Modellen in diesem Kapitel sind Test Organization Maturity (TOM), Test Improvement Model (TIM und Software Quality Rank (SQR) beachtenswert. Darber ), (TIM) ) hinaus gibt es noch eine groe Anzahl regionaler Modelle, die eingesetzt werden. Testexperten sollten sich ber alle verfgbaren Modelle informieren, um festzustellen, welches in ihrer spezifischen Situation am besten passt. Die Modelle in diesem Kapitel sind nicht als Empfehlungen zu verstehen, sie sollen vielmehr eine als reprsentative Darstellung von Funktionsweise und Inhalt von Modellen sein.
8.3.1 Einfhrung in die Prozessverbesserung

Prozessverbesserungen sind sowohl fr den Softwar Softwareentwicklungs- als auch fr den Testprozess relevant. Eine Organisation lernt aus den eigenen Fehlern und kann dann die Prozesse verbessern, die sie fr die Entwicklung und das Testen von Software einsetzt. Der PDCA Zyklus nach Deming PDCA-Zyklus (Plan/Do/Check/Act = Planen/Ausfhren/Prfen/Handeln) ist seit vielen Jahrzehnten im Einsatz und ist auch heute noch relevant, wenn Tester den verwendeten Prozess verbessern mssen. Prozessverbesserung geht davon aus, dass die Qualitt eines Systems stark von der Qualitt des Prozesses abhngt, der zur Entwicklung der Software verwendet wird. Qualittsverbesserungen in der Softwareindustrie verringern die fr die Wartung der Software bentigten Ressourcen und stellen dadurch einen greren zeitlichen Freiraum fr das Ausarbeiten von mehr und besseren Lsungen fr n die Zukunft zur Verfgung. Prozessmodelle bieten einen Ansatz fr Verbesserungen, indem sie die Prozessreife in der Organisation mit Hilfe des Modells messen. Das Modell dient auerdem als Rahmenwerk fr die Verbesserung der Prozesse in einer Organisation anhand der Bewertungsergebnisse. g Eine Prozessbewertung fhrt zu einer Bewertung der Prozessreife, die wiederum eine Prozessverbesserung anregt. Spter lsst sich in einer weiteren Prozessbewertung die Wirkung der Verbesserungen messen. Version 2007 Seite 99 von 136 Januar 2010 20100131
8.3.2 Arten der Prozessverbesserung

Es gibt zwei verschiedene Modelle der Prozessverbesserung: Prozessreferenzmodelle und Inhaltsreferenzmodelle. 1. Das Prozessreferenzmodell dient als Rahmenwerk fr die Bewertung, wenn die Fhigkeiten eines Unternehmens mit dem Modell verglichen werden, und dazu, anhand des Rahmenwerks die Organisation zu bewerten. 2. Das Inhaltsreferenzmodell dient der Verbesserung des Prozesses, nachdem die Bewertung durchgefhrt wurde. Einige Modelle verbinden beide Teile, whrend andere nur aus einem Teil bestehen. nige
8.4 Testprozess verbessern

Seit einiger Zeit nutzt die IT-Branche Modelle zur Testprozessverbesserung bei ihren Bemhungen Branche um mehr Reife und Professionalitt. Dabei dienen Standardmodelle dazu, organisationsbergreifende nalitt. Metriken und Mae zu entwickeln, die einen Vergleich ermglichen. Stufenmodelle, wie TMM liefern TMMi Standards fr Vergleiche zwischen verschiedenen Unternehmen und Organisationen. Kontinuierliche Modelle erlauben es den Organisationen, die Themen mit der hchsten Prioritt freier in der Reihenfolge der Implementierung zu handhaben. Da es in der Testbranche einen klaren Bedarf fr Prozessverbesserungen gibt, haben sich mehrere Standards herausgebildet, beispielsweise STEP herausgebildet, STEP, TMMi, TPI und CTP, die alle in diesem Abschnitt behandelt werden. , Mit jedem dieser vier Modelle fr die Testprozessbewertung kann eine Organisation herausfinden, wo sie gegenwrtig mit ihrem derzeitigen Testprozess steht. Nach der Bewertung liefern TMMi und TPI rtig eine verbindlichen Weg fr die Verbesserung des Testprozesses. Die Modelle STEP und CTP dagegen helfen einem Unternehmen herauszufinden, wo sich Investitionen in die Testprozessverbesserung am besten bezahlt machen, und berlassen ihm die Wahl des geeigneten prozessverbesserung Verbesserungswegs. Wenn Einigkeit herrscht, dass die Testprozesse geprft und verbessert werden sollen, sind folgende Prozessschritte durchzufhren: Initiate (initiieren) Measure (messen) Prioritize and Plan (priorisieren und planen) rioritize Define and Redefine (definieren und neu definieren) edefine Operate (betreiben) Validate (validieren) Evolve (weiterentwickeln) (Die Anfangsbuchstaben der englischen Begriffe ergeben das Wort IMPROVE, verbessern) IMPROVE, Initiieren In diesem Schritt werden Zielsetzungen, Umfang und berdeckungsgrad der vorgesehenen Prozessverbesserungen vereinbart und die Zustimmung der Betroffenen eingeholt. Auerdem wird das Prozessmodell zur Identifizierung der Verbesserungen ausgewhlt. Zur Wahl stehen Verbesserungen entweder die verffentlichten Modelle oder ein individuell definiertes Modell. Bevor die Aktivitten zur Prozessverbesserung beginnen, sollten Erfolgskriterien definiert sowie die Methode implementiert werden, die whrend der Prozessverbesserungsaktivitten zur d Messung dieser Erfolgskriterien anzuwenden ist. Messen
Version 2007
Seite 100 von 136
Januar 2010 20100131
Der vereinbarte Bewertungsansatz wird durchgefhrt und liefert als Ergebnis eine Liste mglicher sansatz Prozessverbesserungen. Priorisieren und planen Die Liste der mglichen Prozessverbesserungen wird nach Prioritt geordnet. Die Prioritt kann glichen sich orientieren an: Rentabilitt, Risiken, Angleichung an die Gesamtstrategie der Organisation, messbarem quantitativen oder qualitativen Nutzen. Nach der Priorisierung sollte ein Plan fr die Durchfhrung der Verbesserungen entwickelt und auf e den Weg gebracht werden. Definieren und neu definieren Anhand der erkannten Anforderungen an die Prozessverbesserung werden bentigte Prozesse neu definiert oder bestehende Prozesse nach Bedarf umdefiniert und einsatzbereit gemacht. Betreiben Nachdem ihre Entwicklung abgeschlossen ist, werden die Prozessverbesserungen umgesetzt. Dazu knnen Schulungen oder Coachings anfallen, es kann die Pilotierung von Prozessen einschlieen und fhrt schlielich zur vollstndigen Implementierung der Verbesserungen. chlielich Validieren Wenn die Prozessverbesserungen im Einsatz sind, ist unbedingt zu prfen, ob sich die vorab vereinbarten Vorteile verwirklicht haben (beispielsweise Nutzenrealisierung), und ob alle Erfolgskriterien fr die Prozessverbesserungsmanahmen erfllt wurden. Weiterentwickeln Je nach verwendetem Prozessmodell ist dies der Schritt im Verbesserungsprozess, mit dem die nchste Reifestufe anvisiert wird, und die Entscheidung fllt,ob der Verbesserungszyklus von sserungszyklus vorne beginnen oder vorerst an diesem Punkt enden soll. Bewertungsmodelle sind eine bliche Methode, sie bieten einen standardisierten Ansatz fr die Verbesserung der Testprozesse nach erprobten und bewhrten Verfahren. Eine Testprozessverbesserung ist aber auch ohne Modell mglich, beispielsweise durch analytische erbesserung Anstze und Bewertungssitzungen.
8.5 Testprozess mit TMM verbessern

Das Test Maturity Model besteht aus fnf Stufen und soll CMM ergnzen. Jede der fnf Stufen enthlt definierte Prozessbereiche, die vollstndig erfllt sein mssen, bevor die Organisation mit der nchsten Stufe fortfahren kann (Stufendarstellung). TMM bietet sowohl ein Prozessreferenzmodell als auch ein Inhaltsreferenzmodell. Die TMM-Stufen sind Stufe 1: Initiierung Auf dieser ersten Stufe gibt es keinen formal dokumentierten oder strukturierten Testprozess. Tests werden normalerweise nach dem Programmieren ad hoc entwickelt und das Testen als Debugging verstanden. Ziel des Testens ist nach allgemeiner Auffassung der Nachweis, dass die el Software funktioniert. Stufe 2: Definition Die zweite Stufe wird erreicht durch das Formulieren von Testrichtlinien und Testzielen, Einfhren eines Testplanungs-Prozesses und Implementieren grundlegender Testverfahren und -methoden. Prozesses Implementieren Stufe 3: Integration
Version 2007
Seite 101 von 136
Januar 2010 20100131
Die dritte Stufe wird erreicht, wenn ein Testprozess in den Softwarelebenszyklus integriert und in formalen Standards, Verfahren und Methoden dokumentiert wird. Es sollte eigene Rollen fr Softwaretester geben, und das Testen sollte gesteuert und berwacht werden. Stufe 4: Management und Messung Die vierte Stufe wird erreicht, wenn sich der Testprozess effektiv messen und steuern lsst, und wenn er fr spezifische Projekte angepasst werden kann. Stufe 5: Optimierung In der letzten Stufe ist eine Testprozessreife erreicht, bei der sich Daten aus dem Testprozess nutzen lassen, um Fehlerzustnden vorzubeugen, und die weitere Optimierung des etablierten Prozesses in den Fokus rckt. Um eine bestimmte Stufe zu erreichen, mssen eine Reihe definierter Reifeziele und untergeordneter stimmte Teilziele erfllt sein. Die Ziele werden definiert als Aktivitten, Aufgaben und Verantwortlichkeiten, und sie werden bewertet aus den festgelegten Perspektiven von Manager, Entwickler/Tester und Manager, Kunde/Anwender. Weitere Informationen enthlt [Burnstein03]. Die TMMi Foundation [www.tmmifoundation.org] hat das Nachfolgemodell von TMM definiert: TMMi. www.tmmifoundation.org] TMMi ist ein detailliertes Modell fr die Testprozessverbesserung. Es basiert auf dem TMM s TMMRahmenwerk, wie es vom Illinois Institute of Technology entwickelt wurde, und auf praktischen Erfahrungen bei dessen Anwendung. Es soll das CMMI ergnzen. TMMi basiert in seiner Struktur weitgehend auf der des CMMI, beispielsweise mit Prozessbereichen, generischen Zielen, generischen Praktiken, spezifischen Zielen und spezifischen Praktiken.
8.6 Testprozess mit TPI verbessern

TPI (Test Process Improvement) basiert auf einer kontinuierlichen Darstellung, statt auf einer rovement) stufenweisen wie TMM. Der bei [Koomen99] beschriebene Plan zur Testprozessoptimierung umfasst eine Anzahl von Kernbereichen, die auf die vier Eckpfeiler Lebenszyklus, Organisation, Infrastruktur/Werkzeuge und Infrastruktur/Werkzeuge Verfahren verteilt sind. Die Kernbereiche lassen sich auf den Ebenen A bis D bewerten, A ist die unterste Ebene. Sind Kernbereiche noch sehr unreif, erreichen sie die Einstiegsebene A mglicherweise nicht. Es gibt Kernbereiche, d nur A, welche die nur A und B (beispielsweise die Schtzung und Planung), welche, die nur A.B und C, sowie welche, die A,B,C und D erreichen knnen , (beispielsweise Metriken). Welche Ebene ein Kernbereich erreicht hat, lsst sich durch die Bewertung von Kont Kontrollpunkten bestimmen, die im TPI-Modell definiert sind. Sind beispielsweise alle Kontrollpunkte fr den Modell Kernbereich Berichterstattung in den Ebenen A und B erfllt, dann hat dieser Kernbereich die Ebene B erreicht. Das TPI-Modell definiert Abhngigkeiten zwischen den verschiedenen Kernbereichen und Ebenen. Modell Diese Abhngigkeiten dienen dazu, dass sich der Testprozess gleichmig entwickelt. So ist es beispielsweise nicht mglich, im Kernbereich Metriken die Ebene A zu erreichen, wenn der Kernbereich Berichterstattung sie noch nicht erreicht hat (es ntzt beispielsweise wenig Metriken zu rstattung erheben, wenn nicht darber berichtet wird). Der Einsatz von Abhngigkeiten im TPI Modell ist nicht TPI-Modell zwingend. TPI ist in erster Linie ein Prozessreferenzmodell. Es stellt eine Testreifematrix zur Verfgung, die die Ebenen (A, B, C oder D) fr jeden der Kernbereiche in 13 Entwicklungsstufen des gesamten Testprozesses abbildet. Diese Stufen sind in drei Kategorien eingeteilt: Version 2007 Seite 102 von 136 Januar 2010 20100131
beherrschbar effizient optimierend Bei einem TPI-Assessment werden quantitative Metriken und qualitative Befragungen verwendet, um sment die Ebenen der Testprozessreife zu bewerten.
8.7 Testprozess mit CTP verbessern

Wie in [Black02] beschrieben, ist der Grundsatz beim CTP-Bewertungsmodell (Critical Testing Bewertungsmodell Process), dass bestimmte Testprozesse als kritisch gelten. Wenn diese kritischen Prozesse gut ausgefhrt werden, dann sind sie eine Untersttzung fr erfolgreiche Testteams. Das gilt auch umgekehrt: Wenn diese Aktivitten schlecht ausgefhrt werden, bleiben selbst begabte Tester und : Testmanager wahrscheinlich erfolglos. Das CTP Modell kennt zwlf kritische Testprozesse. CTP-Modell CTP ist in erster Linie ein Inhaltsreferenzmodell. Das Modell der kritischen Testprozesse ist ein kontextabhngiger Ansatz, der sich anpassen lsst, tprozesse beispielsweise durch: Identifizieren von spezifischen Herausforderungen Erkennen von Merkmalen guter Prozesse Auswahl der Reihenfolge und der Wichtigkeit fr die Implementierung von Prozessverbesserungen Das CTP-Modell lsst sich fr alle Vorgehensmodelle der Softwareentwicklung anpassen. Modell Prozessverbesserungen mit dem CTP Modell beginnen mit einer Bewertung des bestehenden CTP-Modell Testprozesses. Dabei wird identifiziert, welche Prozesse stark und welche schwach sind. Die Bewertung liefert priorisierte Empfehlungen fr Verbesserungen, die auf die Bedrfnisse der Organisation zugeschnitten sind. Abhngig von ihrem Kontext beim Einsatz variieren die Bewertungen, normalerweise werden bei einem CTP CTP-Assessment blicherweise folgende quantitativen Metriken untersucht: Fehlerfindungsrate Rentabilitt der Investition ins Testen Anforderungs- und Risikoberdeckung Indirekte Release-bezogene Kosten bezogene Anteil der zurckgewiesenen Fehlerberichte Bei einem CTP-Assessment werden normalerweise folgende qualitativen Faktoren bewertet: Assessment Rolle und Effektivitt des Testteams Ntzlichkeit des Testkonzepts Kompetenz des Testteams bzgl. Testen, Branchenkenntnissen, Technologie Ntzlichkeit der Fehlerberichte Ntzlichkeit der Ergebnisberichte t Ntzlichkeit und Ausgewogenheit des nderungsmanagements Sind im Assessment die Schwachstellen identifiziert, werden Plne fr die Verbesserung umgesetzt. Das Modell liefert allgemeine Verbesserungsplne fr jeden der kritischen Testprozesse; es wird Testprozesse; jedoch vom Assessment-Team erwartet, dass es sie deutlich anpasst. Team
Version 2007
Seite 103 von 136
Januar 2010 20100131
8.8 Testprozess mit STEP verbessern

STEP (Systematic Test and Evaluation Process) setzt wie CTP (und anders als TMMi und T TPI) nicht voraus, dass Verbesserungen in einer bestimmten Reihenfolge erfolgen. Grundvoraussetzungen der Methode sind u.a.: Eine anforderungsbasierte Teststrategie; das Testen beginnt am Anfang des Softwarelebenszyklus; Tests werden als Anforderungs und Nutzungsmodelle eingesetzt; Anforderungs das Design der Testmittel fhrt zum Softwaredesign; Fehlerzustnde werden frher gefunden oder ganz vermieden; Fehlerzustnde werden systematisch analysiert; Tester und Entwickler arbeiten zusammen. STEP ist in erster Linie ein Inhaltsreferenzmodell. nhaltsreferenzmodell. Die STEP-Methode folgt der Vorstellung, dass das Testen eine Aktivitt ber den gesamten Methode Softwarelebenszyklus ist, dass es mit der Formulierung der Anforderungen beginnt und fortgefhrt wird, bis das System auer Betrieb genommen wird Die STEP-Methode verfhrt nach dem Grundsatz wird. Methode erst testen, dann programmieren. Ihre anforderungsbasierte Teststrategie soll erreichen, dass frh erstellte Testflle die Anforderungsspezifikation noch vor Systemdesign und -programmierung programmierung validieren. Die Methode setzt auf die Verbesserung der folgenden drei Hauptphasen des Testens: Planung Durchfhrung Messung Bei einem STEP-Assessment werden quantitative Metriken und qualitative Befragungen verwendet. Assessment Mgliche quantitative Metriken sind Entwicklung des Teststatus im Zeitablauf Anforderungs- oder Risikoberdeckung Fehlertendenzen mit Aufdeckung, Schwere und Anhufung Fehlerdichte Effektivitt der Fehlerbehebung Fehlerfindungsrate Phasen der Fehlereinfhrung, -findung und behebung Testkosten in Zeit, Aufwand und Geld Mgliche qualitative Faktoren sind Nutzung des definierten Testprozesses Kundenzufriedenheit Das STEP-Assessment-Modell wird manchmal mit dem TPI Modell TPI-Reifemodell kombiniert.
8.9 Capability Maturity Model Integration CMMI Integration,

CMMI kann bzgl. zweier unterschiedliche Darstellungen implementiert werden: gestuft oder unterschiedlicher kontinuierlich. Bei der gestuften Darstellung gibt es fnf Reifegrade oder -ebenen, wob jede Ebene benen, wobei auf den Prozessbereichen aufbaut, die in de vorangegangenen Ebenen erfllt wurden. Bei der den kontinuierlichen Darstellung kann die Organisation die Prozessbereiche nach dem eigenen dringenden Bedarf verbessern, sie muss sich nicht an den Vorgngerebenen orientieren. Vorgngerebenen
Version 2007
Seite 104 von 136
Januar 2010 20100131
Die gestufte Darstellung ist im CMMI vor allem deshalb vorhanden, damit eine gemeinsame Basis mit dem CMM-Modell besteht. Die kontinuierliche Darstellung wird allgemein als die flexiblere Methode Modell betrachtet. Beim CMMI beziehen sich die Prozessbereiche Validierung und Verifizierung sowohl auf statische als auch auf dynamische Testprozesse.
Version 2007
Seite 105 von 136
Januar 2010 20100131
9. Testwerkzeuge und Automatisierung

Begriffe
Debuggingwerkzeug, dynamisches Analysewerkzeug Emulator, Fehlereinpflanzungs ches Analysewerkzeug, , Fehlereinpflanzungswerkzeug, Hyperlink-Werkzeug, Lasttestwerkzeug schlsselwortgetriebener Test, Simulator statischer , Lasttestwerkzeug, , Simulator, Analysator, Testausfhrungswerkzeug Testmanagementwerkzeug, Testorakel werkzeug,
9.1 Einfhrung
Dieser Abschnitt vertieft den Foundation Foundation-Level-Lehrplan zunchst mit einigen allgemeinen Konzepten. Anschlieend werden einige Werkzeuge ausf ausfhrlich erklrt. Die Konzepte knnen unterschiedlich relevant entweder fr Testmanager, Test Analysts oder Technical Test Analysts sein. Professionelle Tester brauchen aber Grundkenntnisse von allen. Die Grundkenntnisse lassen sich dann bei Bedarf erweiter erweitern. Werkzeuge lassen sich unterschiedlich gruppieren, unter anderem nach ihren tatschlichen Nutzerinnen und Nutzern, beispielsweise Testmanager, Test Analysts oder Technical Test Analysts. Diese Einteilung entspricht den Modulen dieses Lehrplans, sie wird deshalb auch in diesem Kapitel verwendet. Generell sind die Werkzeuge in den folgenden Abschnitten fr ein bestimmtes der drei Module relevant; es gibt aber auch bestimmte Werkzeuge (beispielsweise Testmanagementwerkzeuge) mit breiterer Bedeutung. In diesen Fllen nennen die diesen Ausbildungsanbieter Beispiele fr den Einsatz des Werkzeugs im spezifischen Kontext.
9.2 Testwerkzeugkonzepte
Mit Testwerkzeugen lassen sich Effizienz und Effektivitt des Testens erheblich steigern, allerdings nur dann, wenn die geeigneten Werkzeuge fachgerecht eingesetzt und implementiert werden. Testwerkzeuge mssen als ein zustzlicher Aspekt einer gut gefhrten Testorganisation gemanagt werden. Testautomatisierung wird oft mit Testdurchfhrung gleichgesetzt, es gibt aber fr die meisten gleichgesetzt, manuellen Ttigkeiten unterschiedliche Arten der Testautomatisierung, deshalb lassen sich die meisten Aufgabenbereiche des Testens bis zu einem gewissen Grad automatisieren, falls die richtigen Werkzeuge vorhanden sind. Jede Version eines Testwerkzeugs, alle Testskripte, Testsitzungen und jede Testbasis sollten dem Konfigurationsmanagement unterliegen und mit der Softwareversion verbunden sein, fr die sie eingesetzt wurden. Jedes Testwerkzeug ist wichtiger Bestandteil der Testmittel und sollte Testmittel dementsprechend gemanagt werden: die Architektur vor dem Testwerkzeug entwerfen korrektes Konfigurationsmanagement von Skripten und Werkzeugversionen, Patches usw. sicherstellen, einschlielich Versionsinformation Bibliotheken erstellen und pflegen (fr die Wiederverwendung hnlicher Konzepte bei Testfllen), Implementierung des Testwerkzeugs dokumentieren (beispielsweise wann das Werkzeug im Prozess in der Organisation eingesetzt und wie es benutzt wird) vorausschauend planen durch Strukturierung der Testflle fr eine zuknftige Strukturierung Weiterentwicklung, indem sie beispielsweise erweiterbar und wartbar gestaltet werden
Version 2007
Seite 106 von 136
Januar 2010 20100131
9.2.1 Kosten, Nutzen Automatisierung
und
Risiken
von
Testwerkzeugen
und
Eine Kosten-Nutzen-Analyse sollte grundstzlich immer durchgefhrt werden, um die Rentabilitt zu Analyse belegen. Als wichtigste Elemente einer Kosten Kosten-Nutzen-Analyse sollte sie folgende Kostenfaktoren Analyse erfassen und dabei jeweils die Kosten fr die aktuelle manuelle Vorgehensweise (ohne Einsatz von s Werkzeugen) vergleichen mit denen fr werkzeugbasiertes Testen (Stunden umgerechnet in Kosten, direkte Kosten, wiederkehrende Kosten, einmalige Kosten): Einfhrungskosten fr Wissensaneignung (Lernkurve fr das Werkzeug) eignung Evaluierung (Werkzeuge vergleichen), falls zutreffend Integration mit anderen Werkzeugen Kauf, Anpassung oder Eigenentwicklung des Werkzeugs Wiederkehrende Kosten fr Werkzeugbesitz (Wartung, Lizenzgebhren, Supportgebhren, Supportgebhren, Kenntnisse aufrechterhalten) Portabilitt Verfgbarkeit und Abhngigkeiten (wenn Testwerkzeuge nicht vorhanden sind) kontinuierliche Kostenbewertung Qualittsverbesserung, um die optimale Nutzung der gewhlten Werkzeuge sicherzustellen Eine Wirtschaftlichkeitsrechnung (Business Case) nur auf Grundlage von Automatisierungs haftlichkeitsrechnung AutomatisierungsPilotprojekten bersieht oft wichtige Kosten, beispielsweise Kosten fr Wartung, Aktualisierung und Erweiterung der Testskripte bei Systemnderungen. Die Lebensdauer eines Testfalls ist die Dauer, fr Testfalls die er ohne berarbeitung gltig bleibt. Die erste Version eines automatisierten Testskripts zu implementieren, dauert oft wesentlich lnger als eine manuelle Ausfhrung; ber einen lngeren Zeitraum gesehen, macht die automatisierte Variante es aber mglich, zahlreiche hnliche Testskripte viel schneller zu erstellen und so die Anzahl der guten Testflle zu erhhen. Beim zuknftigen Einsatz der Automatisierung nach der Implementierungsphase lassen sich auerdem Testberdeckung und Testeffizienz wesentlich verbessern. Die Wirtschaftlichkeitsrechnung fr die Einfhrung von teffizienz Testwerkzeugen muss daher auf einer langfristigen Perspektive basieren. Jeder spezifische Testfall muss betrachtet werden, um festzustellen, ob sich eine Automatisieru Automatisierung lohnt. Viele Automatisierungsprojekte basieren auf der Implementierung naheliegender manueller Testflle, ohne den tatschlichen Nutzen jedes einzelnen Testfalls zu prfen. Wahrscheinlich kann jeder gegebene Satz von Testfllen oder jede Testsuite manuelle, halbautomatisierte und manuelle, automatisierte Tests enthalten. Zustzlich zu den im Foundation-Level-Lehrplan behandelten Themen, sollten folgende Aspekte bercksichtigt werden: Zustzlicher Nutzen: Die Zeit fr die automatisierte Testdurchfhrung lsst sich leichter schtzen. Regressionstests und Fehlervalidierung in spteren Projektphasen sind schneller und sicherer, wenn die Testflle automatisiert sind. Der Einsatz von Automationswerkzeugen kann den Status und die technische Kompetenz des Testers oder des Testteams erhhen. Automatisierung lsst sich bei der parallelen, iterativen und inkrementellen Entwicklung einsetzen, um besseres Regressionstesten bei jedem Build zu ermglichen. Das Werkzeug deckt bestimmte Testarten ab, die sich manuell nicht abdecken lassen (beispielsweise Performanz und Zuverlssigkeit). Seite 107 von 136 Januar 2010 20100131
Version 2007
Zustzliche Risiken: Unvollstndiges oder inkorrektes Testen wird so automatisiert, wie es ist. Es ist schwierig, die Testmittel zu warten; wenn die zu testende Software gendert wird, mssen mehrere nderungen nachgezogen werden. Dadurch, dass die Tester bei der Testdurchfhrung nicht mehr direkt involviert sind, kann die Fehlerfindungsrate sinken, weil ausschlielich automatisierte Tests mit Testskript durchgefhrt werden.
9.2.2 Testwerkzeugstrategien
Testwerkzeuge sollen normalerweise fr mehr als ein Projekt eingesetzt werden. Je nach Hhe der Investition und Projektdauer kann es sein, dass sich der Einsatz fr nur ein Projekt zunchst nicht rentiert, sondern erst bei nachfolgenden Versionen der Software. So ist beispielsweise die olgenden Wartungsphase oft sehr testintensiv, bei jeder nderung ist eine groe Regressions Regressions-Testsuite auszufhren. Deshalb kann es kostengnstig sein, ein System in der Wartungsphase zu automatisieren, wenn sich das aufgrund einer langen Systemlebensdauer lohnt. Ein weiteres Beispiel: Beim manuellen Testen knnen den Testern beispielsweise leicht Tippfehler unterlaufen, sodass die Kosten-Nutzen-Rechnung positiv ausfllt, wenn in einer Testsuite die Dateneingaben und der Rechnung Dateneingaben Vergleich der Ergebnisdaten mit den Daten des Testorakels automatisiert werden. Fr Unternehmen, die viele Testwerkzeuge benutzen (fr unterschiedliche Teststufen und -zwecke) und von diesen abhngig sind, empfiehlt sich eine langfristige Testwerkzeugstrategie, die als Testwerkzeugstrategie, Entscheidungshilfe dient, wenn es um die Einfhrung oder das Auslaufen von bestimmten Werkzeugversionen und Werkzeug Support geht. Fr grere Unternehmen mit intensiver Werkzeug-Support Werkzeugnutzung kann es ratsam sein, eine allgemeine Richtlinie fr die Werkzeugbeschaffung, Richtlinie Strategien, Werkzeug-Paradigmen oder zu verwendende Skriptsprachen zu erstellen. Paradigmen
9.2.3 Integration und Informationsaustausch zwischen Werkzeugen

In einem Test- (und Entwicklungs-)prozess wird in der Regel mehr als ein Testwerkzeug eingesetzt. )prozess So kann ein Unternehmen beispielsweise gleichzeitig ein statisches Analysewerkzeug einsetzen, ein Testmanagementund -berichtswerkzeug, berichtswerkzeug, ein Konfigurationsmanagementwerkzeug, ein Abweichungsmanagement- und ein Testausfhrungswerkzeug. Dann sollte das Unternehmen prfen, ob die Werkzeuge sich integrieren lassen, und ob ein ntzlicher Informationsaustausch mglich ist. Es wre beispielsweise gnstig, wenn alle Statusinformationen aus einer Testdurchfhrung direkt an das einer Testmanagement-System berichtet wrden, und sich damit der Testfortschritt sofort aktualisieren und System Anforderungen sich direkt zu einem bestimmten Testfall zurckverfolgen lieen. Es ist nicht nur aufwndiger, sondern auch eine mgliche Fehlerquelle, wenn die Testskripte sowohl in einer h Testmanagementdatenbank als auch in einem Konfigurationsmanagement System gespeichert Konfigurationsmanagement-System werden. Will ein Tester mitten in einem Testfall einen Abweichungsbericht herausgeben, dann mssen Fehlerverfolgungsund Testmanagement-Systeme Testmanagement Systeme integriert sein. Statische Analysewerkzeuge knnen zwar getrennt von anderen Werkzeugen arbeiten, es wre aber viel effizienter, wenn diese Werkzeuge Abweichungen, Warnungen und andere Rckmeldungen direkt an das Testmanagement-System berichten wrden. System Die Beschaffung von Testwerkzeugen vom selben Anbieter bedeutet nicht zwangslufig, dass die Werkzeuge in der beschriebenen Weise miteinander arbeiten, selbst wenn dies eine realistische Erwartung wre. All diese Aspekte sollten bercksichtigt werden: Von den Kosten fr eine ekte Automatisierung des Informationsaustauschs bis zu den Risiken durch Datenverflschung oder -verlust bei rein manuellen Ablufen (wenn die Organisation berhaupt Zeit hat fr diese Arbeiten). verlust
Version 2007
Seite 108 von 136
Januar 2010 20100131
Neue Konzepte, wie integrierte Entwicklungsumgebungen (beispielsweise Eclipse), zielen darauf ab, Integration und Einsatz verschiedener Werkzeuge in derselben Umgebung zu erleichtern, indem sie eine gemeinsame Schnittstelle fr Entwicklungs und Testwerkzeuge bieten. So knnen Entwicklungsieten. Werkzeuganbieter ein Plug-in zum Eclipse Framework bereitstellen und damit erreichen, dass ihr in Eclipse-Framework Werkzeug Eclipse-konform wird. Das Werkzeug sieht dann so aus und lsst sich benutzen wie jedes konform andere Werkzeug im Eclipse-Rahmenwerk, was fr die Nutzer vorteilhaft ist. Hinweis: Auch wenn die Rahmenwerk, die Benutzerschnittstellen hnlich sind, bedeutet das nicht, dass die Werkzeuge automatisch integriert sind und untereinander Informationen austauschen knnen.
9.2.4 Automatisierungssprachen Skripte, Skriptsprachen Automatisierungssprachen:

Skripte und Skriptsprachen knnen fr die bessere Implementierung und Ausweitung von Testbedingungen und Testfllen eingesetzt werden. So kann beispielsweise beim Testen einer Web werden. WebAnwendung ein Skript verwendet werden, um die Benutzerschnittstelle zu umgehen und die Schnittstelle des Anwendungsprogramms selbst (API, Application Programming Interface) Application angemessener zu testen. Ein anderes Beispiel ist die Automatisierung des Tests einer Benutzerschnittstelle, um alle mglichen Kombinationen von Eingaben zu testen. Mit einem manuellen Vorgehen wre das nicht umsetzbar. Skriptsprachen haben sehr unterschiedliche Fhigkeiten. Hinweis: Skriptsprachen knnen normale Skriptsprachen Programmiersprachen bis zu sehr spezifischen standardisierten Notationen sein, beispielsweise TTCN-3.
9.2.5 Konzept der Testorakel

Testorakel werden verwendet, um erwartete Ergebnisse zu bestimmen. Als solche erfllen sie die gleiche Funktion wie die zu testende Software und sind daher selten verfgbar. Sie knnen jedoch dann eingesetzt werden, wenn ein altes System durch ein neues mit identischer Funktionalitt ersetzt werden soll; das alte System kann dann als Testorakel dienen. Testorakel knnen auch dann verwendet werden, wenn die Performanz des zu liefernden Systems wichtig ist. Ein Orakel mit niedriger Leistung kann gebaut oder verwendet werden, um die erwarteten Ergebnisse der funktionalen Tests der leistungsstrkeren Software zu erzeugen. er
9.2.6 Testwerkzeuge in Betrieb nehmen

Jedes automatisierte Werkzeug ist eine eigene Software, die Hardware oder Softwareabhngigkeiten Hardwarehaben kann. Auch das Werkzeug sollte dokumentiert und getestet sein, ob es fertig gekauft, adaptiert dokumentiert oder in der Organisation erstellt wurde. Einige Werkzeuge lassen sich gut in die Umgebung integrieren, andere funktionieren besser im Einzelbetrieb. Wenn das zu testende System auf proprietrer Hardware, Betriebssystemen, eingebetteter Software Hardware, luft, oder wenn es nicht standardmige Konfigurationen nutzt, kann es notwendig sein, ein Werkzeug zu erstellen (zu entwickeln) oder ein Werkzeug anzupassen, damit es in die spezifische Umgebung passt. Es ist immer eine Kosten mmer Kosten-Nutzen-Analyse empfehlenswert, die die anfnglichen Analyse Kosten und die langfristigen Wartung bercksichtigt. Bei Inbetriebnahme eines Testautomatisierungswerkzeugs ist es nicht ratsam, die manuellen Testflle eins zu eins zu bernehmen, sondern sie vielmehr fr die Automatisierung neu zu definieren. Dazu sondern mssen die Testflle formatiert werden, wiederverwendbare Muster bercksichtigt, die Eingaben durch Variablen statt fest programmierter Werte erweitert und die Vorteile des Testwerkzeugs genutz genutzt werden (beispielsweise seine Fhigkeit zum Verbinden von Testfllen, Wiederholen, ndern der Reihenfolge, bessere Analyse- und Berichtsfunktionen). Viele Testautomatisierungswerkzeuge setzen Programmierkenntnisse voraus, um effiziente und effektive Testprogramme (Skripte) und Testsuiten Testprogramme Version 2007 Seite 109 von 136 Januar 2010 20100131
zu erstellen. Groe Testsuiten sind oft schwierig zu aktualisieren und zu managen, wenn sie nicht mit Sorgfalt entworfen wurden. Deshalb sind geeignete Schulungen fr Anwendung der Testwerkzeuge, Programmierung und Entwurfsverfahren sehr wertvoll, damit sich die Vorteile der Werkzeuge sverfahren vollstndig nutzen lassen. Auch wenn manuelle Testflle automatisiert wurden, ist es wichtig, sie regelmig auch manuell auszufhren, damit das Wissen nicht verloren geht, wie der Test funktioniert, und um die korrekte funktioniert, Arbeitsweise zu verifizieren. Wenn ein Werkzeug im Einsatz ist und die Anzahl der Testskripte stetig zunimmt, kann es ntig werden, bestimmte Funktionen hinzuzufgen, die andere Werkzeuge bieten. Das ist nicht immer mglich, da nicht alle Werkzeuge eine offene Schnittstelle bieten und manchmal eigene, nicht standardisierte Skriptsprachen verwenden. Es ist daher ratsam, Werkzeuge einzusetzen, die sich ber Plug-ins in offene Rahmenwerke einfgen lassen oder ber API ins API-Schnittstellen verfgen. Das garantiert eine bessere Zukunftsfhigkeit der Testskripte als Testmittel. Fr jede Art von Werkzeug sollten die nachfolgend aufgelisteten Eigenschaften betrachtet werden, unabhngig von der Testphase, in der das Werkzeug eingesetzt werden soll. Diese Eigenschaften soll. sind sowohl bei der Evaluierung von Werkzeugen als auch bei der Eigenentwicklung ntzlich. Ein Werkzeug kann in jedem dieser Aspekte schwach oder stark sein. Eine solche Liste eignet sich deshalb auch zum Vergleich der Fhigkeiten unterschiedlicher Werkzeuge. Analyse: Konzept, Eingaben und manuell oder automatisch eingebrachte Informationen Entwurf: manuelle oder automatische Erstellung Auswahl: manuelle oder automatische Auswahl auf Basis von Kriterien, beispielsweise berdeckung Ausfhrung: manuelle oder automatische Ausfhrung, Steuerung, Wiederanlauf etc etc. Bewertung (beispielsweise Testorakel) und Prsentation: Sie werden oft als manuelle oder automatische Protokollier- und Berichtsfunktionen bezeichnet, die beispielsweise Vergl Vergleiche mit einer Vorlage, einem Standard oder mit einem bestimmten Kriterium durchfhren durchfhren.
9.2.7 Open Source-Testwerkzeuge verwenden Testwerkzeuge

Werkzeuge fr den Test von sicherheitskritischen Systemen mssen je nach Verwendungszweck und geltenden Standards zertifiziert sein. Open Source-Werkzeuge sollten bei sicherheitskritischen ltenden Werkzeuge Systemen nur eingesetzt werden, wenn eine entsprechende Zertifizierung des Werkzeugs vorliegt. Die Qualitt von Open Source-Software hngt von ihrer Verbreitung, Vorgeschichte und jeweiligen Software Verbreitung, Verwendung ab. Es lsst sich nicht davon ausgehen, dass die Qualitt von Open Source Open Source-Software besser oder schlechter als kommerzielle Werkzeuge ist. Fr jedes Testwerkzeug sollte immer eine Qualittsbewertung durchgefhrt werden, um dessen durchgefhrt Eignung zu bewerten. Bei einigen Werkzeugarten kann es zu irrefhrenden Ergebnissen in der Bewertung kommen, wenn ein positives Bewertungsergebnis durch eine inkorrekte Werkzeuganwendung erzielt wurde (wenn beispielsweise ein Schritt nicht ausgefhrt wurde, aber nicht nicht berichtet wurde welcher). Lizenzgebhren sollten genau betrachtet werden Es knnte (von der werden. Open Source Community) erwartet werden, dass man Verbesserungen bzw. Erweiterungen, die man pen macht, allgemein zur Verfgung stell stellt.
9.2.8 Eigene Testwerkzeuge entwickeln

Viele Testwerkzeuge werden entwickelt, weil Tester oder Entwickler ihre Arbeit beschleunigen wollen oder mssen. Andere Grnde fr die Eigenentwicklung von Testwerkzeugen knnen sein dass es sein, keine geeigneten Werkzeuge auf dem Markt gibt, oder dass proprietre Hardware oder Version 2007 Seite 110 von 136 Januar 2010 20100131
Testumgebungen verwendet werden mssen. Diese Werkzeuge sind oft sehr effizient beim Ausfhren der vorgesehenen Aufgaben; sie hngen aber oft auch sehr von der Person ab, die sie entwickelt hat. Person Deshalb sollten sie so dokumentiert werden, dass auch andere Personen sie pflegen knnen. Bevor sie in einer Organisation weiter verbreitet werden, sollten unbedingt ihre Zwecke, Ziele, Vor und VorNachteile geprft werden. Es kommt oft vor, dass solche Werkzeuge fr neue Anforderungen verwendet werden, oder dass sie weit ber ihren ursprnglichen Gebrauch hinaus erweitert werden, was nicht immer von Vorteil ist.
9.2.9 Testwerkzeuge klassifizieren

Testwerkzeuge lassen sich danach klassifizieren, welche Aktivitten sie untersttzen ( (FoundationLevel-Lehrplan). Weitere Mglichkeiten der Klassifizierung sind ). Einteilung der Werkzeuge nach Teststufe (Komponenten , Integrations (Komponenten-, Integrations-, System-, Abnahmetest) Einteilung der Werkzeuge nach Fehlerzustnden, die mit ihnen bearbeitet und untersttzt nteilung werden Einteilung der Werkzeuge nach Testvorgehensweise oder Testverfahren (siehe unten) Einteilung der Werkzeuge nach Zweck des Testens, beispielsweise Messung, Treiber Treiber, Protokollierung, Vergleiche Einteilung der Werkzeuge nach bestimmten Fachbereichen, beispielsweise Verkehrssimulation und -leitung, Netzwerke, Protokolle, Transaktionen, TV leitung, TV-Bildschirme, Expertensysteme Einteilung der Werkzeuge nach Aufgabenbereichen, die sie untersttzen, beispielsweise Dateneingabe, Umgebung, Konfiguration oder andere konzeptionelle Bereiche Einteilung der Werkzeuge nach der vorgesehenen Anwendung: als Standardprodukt, Rahmenwerk (zur Anpassung), Plug Plug-in (beispielsweise Eclipse), Standard-Testsuite oder Testsuite fr Zertifizierungen, firmeninterne Werkzeugentwicklung Auerdem lassen sich Werkzeuge nach ihren tatschlichen Nutzern klassifizieren, wie Testmanager, Test Analysts und Technical Test Analysts. Diese Einteilung entspricht den Modulen dieses Lehrplans, sie wird deshalb auch in den folgenden Abschnitten verwendet. Der Foundation Foundation-LevelLehrplan enthlt bereits ein Kapitel ber Testwerkzeuge, die nachfolgenden Abschnitte ergnzen Aspekte der Testwerkzeuge.
9.3 Testwerkzeugkategorien
Dieser Abschnitt hat folgende Ziele: Er liefert zustzliche Informationen fr die bereits in Kapitel 6 des ISTQB Foundation Foundation-LevelLehrplans s beschriebenen Werkzeuge (beispielsweise Testmanagementwerkzeuge, Testmanagement Testausfhrungs- und Lasttestwerkzeuge). Er fhrt neue Werkzeugkategorien ein. Allgemeine Informationen ber Werkzeugkategorien, die in diesem Abschnitt nicht behandelt werden, enthlt ISTQB Foundation-Level-Lehrplan Kapitel 6. Lehrplan,
9.3.1 Testmanagementwerkzeuge
Allgemeine Informationen ber Testmanagementwerkzeuge enthlt ISTQB Foundation Foundation-LevelLehrplan, Abschnitt 6.1.2. Die folgenden Informationen sollten Testmanagementwerkzeuge liefern knnen: Version 2007 Seite 111 von 136 Januar 2010 20100131
Rckverfolgbarkeit von Testartefakten Erfassung der Testumgebungsdaten in komplexen Umgebungen Daten zur gleichzeitigen Ausfhrung von Testsuiten in unterschiedlichen Testumgebungen whrend derselben Testsitzung an mehreren Einsatzorten (in verschiedenen Organisationen) Metriken und Indikatoren, wie Anzahl der Testbedingungen l Anzahl der Testflle Dauer der Ausfhrung (beispielsweise des Testfalls, einer Testsuite, einer Regressionstestsuite) und andere wichtige Zeiten, einschlielich Durchschnittswerten, die fr Managemententscheidungen wichtig sein knnte knnten Anzahl der Testflle, Testartefakte und Testumgebungen Anteil der bestandenen/nicht bestandenen Tests Anzahl der noch offenen Testflle (und der Grnde, weshalb sie nicht ausgefhrt wurden) Tendenzen Anzahl der Anforderungen Anzahl der Beziehungen zw zwischen und Verfolgbarkeit von Testartefakten Konzepte, die von den Testmanagementwerkzeugen untersttzt werden, wie Organisation von Testartefakten, Repositories und Treibern von Testfllen Testbedingungen und Testumgebungen Regressionstestsuiten, Test Testsitzung Protokollierung und Information zur Fehlerbearbeitung Wiederanlauf der Umgebung (und Neuinitialisierung) Testmetriken ber die Testartefakte (Testdokumentation), um den Testfortschritt zu dokumentieren Testmanagementwerkzeuge werden von Testmanagern, Test Analysts und Technical Test Analysts e ern, benutzt.
9.3.2 Testausfhrungswerkzeuge
Allgemeine Informationen ber Testausfhrungswerkzeuge enthlt ISTQB Foundation Foundation-LevelLehrplan 2007, Abschnitt 6.1.5. Testausfhrungswerkzeuge werden berwiegend von Test Analysts und Technical Test Analysts auf ungswerkzeuge allen Teststufen eingesetzt, um Tests auszufhren und die Ergebnisse zu kontrollieren. Testausfhrungswerkzeuge verfolgen normalerweise eins oder mehrere der folgenden Ziele Ziele: Kosten reduzieren (Aufwand oder Zeit) mehr Tests ausfhren Tests leichter wiederholbar machen Testausfhrungswerkzeuge werden meist zur Automatisierung der Regressionstests eingesetzt. Testausfhrungswerkzeuge fhren eine Reihe von Anweisungen in einer Programmiersprache aus, die oft auch Skriptsprache genannt wird. Die Anweisungen fr das Werkzeug sind sehr ausfhrlich und spezifizieren Details, wie einzelne Schaltflchenaktivierungen, Tastendrucke und Mausbewegungen. Diese detaillierten Skripte werden dadurch sehr anfllig fr nderungen an der Software unter Test (SUT), vor allem wenn sie die graphische Benutzerschnittstelle (GUI) betreffen. Ausgangspunkt fr ein Skript kann ein Mitschnitt (Capture/Replay) sein, oder ein erstelltes oder ) bearbeitetes Skript auf der Grundlage vorhandener Skripte, Vorlagen oder Schlsselwrter. Ein Skript ist ein Programm und funktioniert wie jede Software. Beim Erfassen (oder Aufzeichnen) lsst sich ein (oder Audit Trail fr das nicht-systematische Testen aufzeichnen. Die meisten Testausfhrungswerkzeuge systematische haben einen Testkomparator, der die tatschlichen mit den gespeicherten erwarteten Testergebnissen Version 2007 Seite 112 von 136 Januar 2010 20100131
vergleicht. Beim Testen (wie beim Programmieren) geht der Trend weg von detaillierten Anweisungen e und hin zu hheren Sprachen, auch hier werden Bibliotheken, Makros und Unterprogramme benutzt. Folgen von Anweisungen in einem Skript knnen mit einem Namen (Schlsselwort oder Aktionsw Aktionswort) gekennzeichnet werden; daher werden diese schlsselwortgetriebene oder aktionswortgetriebene Tests genannt. Hauptvorteil ist die Trennung der Skriptanweisungen von den Daten. Wie bei der Nutzung von Vorlagen fr die Skripterstellung soll dieses Konzept den Aufwand minimieren. Konzept Hauptgrund fr das Versagen von Testwerkzeugen in der Praxis sind geringe Programmierfhigkeiten und ein mangelndes Verstndnis dafr, dass ein Testwerkzeug durch die automatisierte Testdurchfhrung nur einen Teil der Probleme lst. Jede Automatisierung der Testdurchfhrung lst. bedeutet Management, Aufwand, besondere Qualifikationen und Sorgfalt, beispielsweise fr Testarchitektur und Konfigurationsmanagement. Das heit auch, dass Testskripte Fehler enthalten knnen. Eine Testmittel-Architektur kann eine gewisse Unabhngigkeit von einem bestimmten chitektur Werkzeuglieferanten bieten. Wenn ein Werkzeug beschafft wird, meinen viele, dass seine Vorgaben befolgt werden mssen, beispielsweise bei Aufbau und Namenskonventionen von Skripten. Mit der Automatisierung des Testaufbaus lassen sich aber die eigene optimale Weise, die Tests zu tomatisierung organisieren, mit den Ablagestrukturen verbinden, die das Werkzeug fordert, um die Tests ausfhren zu knnen.
9.3.3 Debugging und Fehleranalyse Fehleranalysewerkzeuge

Die Fehleranalyse kann mit Werkzeugen den Bereich eingrenzen, im dem ein Fehlerzustand auftritt. Das kann auch ntig sein, wenn in einem System nicht offensichtlich ist, welcher Fehlerzustand die Fehlerwirkung ausgelst hat. Fehleranalysewerkzeuge enthalten eine Ablaufverfolgung und simulierte irkung Umgebungen fr die Interaktion mit der Software, oder sie ziehen Informationen aus dem System, um so den Ort der Fehlerwirkung einzugrenzen. Mit Debugging- und Verfolgungswerkzeugen reproduzieren Programmierer Fehler und untersuchen olgungswerkzeugen den Zustand von Programmen. Sie knnen damit damit: Programme Zeile fr Zeile ausfhren Programme an einer beliebigen Programmanweisung anhalten Programmvariable setzen und untersuchen Hinweis: Debugging und die Werkzeuge dafr haben zwar Gemeinsamkeiten mit dem Testen, sind s: aber nicht damit gleichzusetzen. Debuggingwerkzeuge sind keine Testwerkzeuge. Tester knnen Debugging- und Verfolgungswerkzeuge zur Fehleranalyse einsetzen, um den Ursprun einer Ursprung Fehlerwirkung zu orten, und um zu bestimmen, wohin der Abweichungsbericht zu senden ist. Debugging-, Verfolgungs- und Fehleranalysewerkzeuge werden hauptschlich von Technical Test Analysts benutzt.
9.3.4 Fehlereinpflanzungs und Fehlerinjektionswerkzeuge FehlereinpflanzungsFehlereinpflanzung und Fehlerinjektion sind zwei unterschiedliche Verfahren, die beim Testen eingesetzt werden knnen. Die Fehlereinpflanzung nutzt ein Werkzeug, das einem Compiler hnelt, nutzt und generiert damit systematisch einzelne oder bestimmte Arten von Codefehlern. Diese Werkzeuge werden oft beim Mutationstestverfahren eingesetzt und werden manchmal auch Mutationstest MutationstestWerkzeug genannt. Fehlerinjektion soll die vorhandenen Schnittstellen zu Testkomponenten ndern, fr die kein Quellcode verfgbar ist. Sie kann aber auch gezielt einen bestimmten Fehlerzustand einbringen, um einerseits zu prfen, ob die Software damit umgehen kann (Fehlertoleranz), oder um festzustellen, ob ein Test in der Testsuite den absichtlich eingeschleusten Fehler findet. Fehlereinpflanzungs und FehlereinpflanzungsFehlerinjektionswerkzeuge werden vor allem von Technical Test Analysts auf Codeebene verwendet, Version 2007 Seite 113 von 136 Januar 2010 20100131
Test Analysts knnen damit aber auch Daten in einer Datenbank manipulieren oder Fehlerzustnde in den Datenstrom einschleusen, um das Systemverhalten zu testen.
9.3.5 Simulations- und Emulationswerkzeuge

Simulatoren untersttzen das Testen dann, wenn Code oder andere Systeme nicht verfgbar, teuer oder ungeeignet sind (beispielsweise beim Testen von Software, die mit einer nuklearen Kernschmelze umgehen muss). Einige Simulatoren und Testrahmen knnen auch das Fehlerverhalten untersttzen oder abbilden, sodass sich Fehlerzustnde oder Fehlerszenarien prfen lassen. Das grte Risiko beim Einsatz dieser Werkzeuge ist, dass sie Fehler in Zusammenhang mit den Ressourcen (beispielsweise Timing Timing-Probleme) mglicherweise nicht finden, die fr manche Arten licherweise von Systemen sehr wichtig sind. Emulatoren gehren zur Kategorie der Simulatoren, sie sind Software, die zum Abbilden einer Hardware geschrieben wird. Ihr Vorteil ist, dass sie ausgefeiltere Tests ermglichen, und vor allem, ermglichen, dass Ablaufverfolgung, Debugging und zeitabhngige Ursachen nachgestellt werden knnen, was in einem echten System vielleicht nicht mglich wre. Emulatoren sind teuer zu erstellen, der Vorteil einer Analyse, bei der das System quasi in Zeitlupe luft, ist aber fr manche parallelen, Zeitlupe zeitabhngigen und komplexen Systeme unbezahlbar. Diese Werkzeuge werden, je nach der bentigten Art der Emulation, von Test Analysts und Technical Test Analysts eingesetzt.
9.3.6 Statische und dynamische Analysewerk Analysewerkzeuge

Allgemeine Informationen ber statische und dynamische Analysewerkzeuge enthlt ISTQB Foundation-Level-Lehrplan 2007, Abschnitt 6.1.6 Werkzeuguntersttzung fr Performanzmessung , Performanzmessung und Testmonitore. 9.3.6.1 Statische Analysewerkzeuge Statische Analysewerkzeuge lassen sich in allen Phasen des Softwarelebenszyklus einsetzen und auch in allen Phasen oder Stufen der Softwareentwicklung, je nachdem, welche Messungen sie liefern. Statische Analysewerkzeuge berichten gefundene Fehler als Warnungen. Unbegrndete Warnungen bezeichnet man als falsch positiv. Wahr positive Meldungen sind tatschliche Fehlerzustnde, die in der Ausfhrung zu Fehlerwirkungen oder Ausfllen fhren knnen. Es kann schwierig und zeitaufwndig sein, zwischen falschen und wahren Positiven zu unterscheiden, weil dazu eine fachgerechte Fehleranalyse ntig ist. Neuere statische Analysewerkzeuge knnen Informationen aus dem dynamischen Binden whrend des Kompilierens nutzen, und sie sind daher wirkungsvoller beim Kompilierens Finden echter Fehler (weniger falsch Positive). Diese Werkzeuge werden von Technical Test Analysts Positive). benutzt. 9.3.6.2 Dynamische Analysewerkzeuge Dynamische Analysewerkzeuge liefern Laufzeitdaten ber den Status der ausfhrenden Software. Laufzeitdaten Diese Werkzeuge werden berwiegend eingesetzt, um nicht zugeordnete Zeiger zu identifizieren, die Zeigerarithmetik zu prfen, um Zuweisung, Nutzung und Freigabe von Speicherplatz zu berwachen und Engpsse anzuzeigen, und zum Aufdecken anderer, mit statischen Methoden schwer zeigen, auffindbarer Fehler. Speicherwerkzeuge sollten in groen und komplexen Systemen wiederholt auf mehreren Ebenen eingesetzt werden, weil Speicherprobleme dynamisch entstehen. Hinweis: unterschiedliche kommerzielle Testwerkzeuge knnen unterschiedlich implementiert sein und deshalb iedliche auch unterschiedliche Speicher- oder Ressourcenprobleme (Stacks, Heaps) suchen und berichten. Das bedeutet, dass zwei verschiedene Speicherwerkzeuge auch unterschiedliche Probleme unterschiedliche Version 2007 Seite 114 von 136 Januar 2010 20100131
identifizieren knnten. Speicherwerkzeuge sind besonders ntzlich fr das Testen bestimmter Programmiersprachen (beispielsweise C, C++), bei denen die Programmierer das Speichermanagement bernehmen. Diese Werkzeuge werden von Technical Test Analysts benutzt.
9.3.7 Schlsselwortgetriebene Testautomatisierung

Schlsselwrter (manchmal Aktionswrter genannt) werden meist (aber nicht ausschlielich) dazu verwendet, bergeordnete Geschftsinteraktionen mit einem System zu benennen (beispielsweise: det, Auftrag stornieren). Jedes Schlsselwort bezeichnet dabei normalerweise eine Reihe detaillierter Interaktionen mit dem zu testenden System. Die Testflle werden als Seq Sequenzen von Schlsselwrtern (mit den relevanten Testdaten) spezifiziert [Buwalda01]. Beim automatisierten Testen werden die einzelnen Schlsselwrter als ein oder mehrere auszufhrende Testskripte implementiert. Die Werkzeuge lesen die mit Schlsselwrtern erstellten Testflle und rufen die entsprechenden Testskripte auf. Die Testskripte sind sehr modular implementiert, damit sie sich leicht auf bestimmte Schlsselwrter abbilden lassen. Fr die Implementierung der modularen Skripte sind Programmierkenntnis ntig. Programmierkenntnisse Die wichtigsten Vorteile der schlsselwortgetriebenen Testautomatisierung sind: Experten fr einen bestimmten Anwendungs oder Geschftsbereich knnen die AnwendungsSchlsselwrter definieren. Das macht die Spezifikation der Testflle effizienter. Fr eine Person, die vorwiegend Fachexpertise hat, ist die automatische Testfalldurchfhrung e vorteilhaft (nachdem die Schlsselwrter in Form von Testskripten implementiert wurden). Es ist einfacher, Testflle zu warten, die unter Verwendung der Schlsselwrter geschrieben wurden, weil sie mit geringerer Wahrscheinlichkeit modifiziert werden mssen, wenn sich Details der zu testenden Software ndern. Testfallspezifikationen sind unabhngig von der Implementierung. Die Schlsselwrter knnen mit verschiedenen Skriptsprachen und Werkzeugen implementiert werden. ptsprachen Die schlsselwortgetriebene Testautomatisierung wird berwiegend von Fachexperten und Test Analysts benutzt.
9.3.8 Performanztestwerkzeuge
Allgemeine Informationen ber Performa Performanztestwerkzeuge enthlt ISTQB Foundation-Level-Lehrplan 2007, Abschnitt 6.1.6 Werkzeuguntersttzung fr Performanzmessung und Testmonitore. , Performanztestwerkzeuge leisten zweierlei: Lastgenerierung Messung und Analyse des Systemverhaltens bei der generi generierten Last Zur Lastgenerierung wird ein definiertes Nutzungsprofil (siehe Abschnitt 5.3.3 als Skript 5.3.3) implementiert. Das Skript kann zunchst fr einen einzigen Nutzer erfasst werden (beispielsweise mit einem Mitschnittwerkzeug), und wird dann durch das Lasttestwerkzeug fr das festgelegte g), Nutzungsprofil implementiert. Die Implementierung muss die Datenschwankungen pro Transaktion (oder Menge von Transaktionen) bercksichtigen. Performanztestwerkzeuge generieren eine Last, indem sie eine groe Nutzerzahl (virtuelle Nutzer) mit indem bestimmten Mengen von Eingabedaten simulieren. Im Unterschied zu den Mitschnittwerkzeugen, die die Nutzungsinteraktion ber eine graphische Benutzerschnittstelle simulieren, erzeugen viele Performanztestskripte die Nutzungsinteraktionen mit dem System auf der Ebene des kripte Kommunikationsprotokolls. Nur wenige Lastgenerationswerkzeuge knnen die Last generieren, indem sie die Anwendung ber die Benutzerschnittstelle steuern.
Version 2007
Seite 115 von 136
Januar 2010 20100131
Performanztestwerkzeuge liefern eine Vielzahl von Messungen fr die Analyse whrend oder nach Durchfhrung des Tests. Typische Metriken und Berichte dieser Testwerkzeuge sind Anzahl simulierter Nutzer Anzahl und Art der von den simulierten Nutzern erzeugten Transaktionen Antwortzeiten fr bestimmte, von den Nutzern angeforderte Transaktionen Berichte auf Basis von Testprotokollen oder -logs und Graphen, die Last und Antwortzeiten logs Antwortzeiten. gegenberstellen Systemmonitordaten (wie z.B. CPU Auslastung) Wichtige Faktoren beim Implementieren von Perfor Performanztestwerkzeugen sind Hardware und die Netzwerkbandbreiten, die fr die Lastgenerierung bentigt werden Kompatibilitt des Werkzeugs mit dem Kommunikationsprotokoll des zu testenden Systems ausreichende Flexibilitt des Werkzeugs fr die einfache Implementierung unterschiedlicher Implementierung Nutzungsprofile bentigte berwachungs-, Analyse und Berichtsfunktionen , AnalysePerformanztestwerkzeuge werden in der Regel gekauft, weil deren Entwicklung sehr aufwndig ist. Es kann aber sinnvoll sein, ein bestimmtes Performanztestwerkzeug zu entwickeln, wenn technische Performanztestwerkzeug Einschrnkungen den Einsatz eines Produkts nicht zulassen, oder wenn Nutzungsprofil und bentigte Funktionen relativ einfach sind. Performanztestwerkzeuge werden in der Regel von Technical Test Analysts benutzt. Hinweis: Performanzbezogene Fehlerzustnde haben oft tief greifende Auswirkungen auf die zu weis: testende Software. Wenn die Anforderungen an die Performanz des Systems sehr wichtig sind, ist es meist sinnvoll, die Performanz der kritischen Komponenten zu testen ( (mittels Treibern und Platzhaltern), und nicht bis zu den Systemtests zu warten. ),
9.3.9 Hyperlink-Testwerkzeuge Testwerkzeuge

Mit Hyperlink-Werkzeugen werden Webseiten darauf analysiert und kontrolliert, ob keine Hyperlinks Werkzeugen ungltig sind oder fehlen. Einige Werkzeuge liefern auerdem zustzliche Informationen, ind beispielsweise einen Graphen mit der Architektur oder Baumstruktur der Seite, Geschwindigkeit und Gre des Downloads (je URL), Trefferzahl und Volumen. Mit Hyperlink-Testwerkzeu Testwerkzeugen lsst sich auch die Konformitt mit Service Level Vereinbarungen (Service Level Agreement, SLA) berwachen. Level-Vereinbarungen Hyperlink-Testwerkzeuge werden von Test Analysts und Technical Test Analysts benutzt Testwerkzeuge benutzt.
Version 2007
Seite 116 von 136
Januar 2010 20100131
10. Soziale Kompetenz und Teamzusammensetzung mensetzung

Begriffe
Unabhngigkeit des Testens
10.1
Einfhrung
Professionelle Tester sollten wissen, welche individuellen Fhigkeiten sie zur fachgemen Erfllung ihrer spezifischen Aufgaben brauchen. Dieses Kapitel beleuchtet zunchst die individuellen zunchst Fhigkeiten, bevor es sich mit Themen befasst, die fr Testmanager besonders wichtig sind, beispielsweise Gruppendynamik, Organisation, Motivation und Kommunikation.
10.2
Individuelle Fhigkeiten
Eine Person kann entweder durch ihre Erfahrung oder durch Schulung in verschiedenen on Arbeitsbereichen zum Testen von Software befhigt sein. Folgende Aspekte knnen zu ihrer Wissensbasis beitragen: Nutzung von Softwaresystemen Kenntnis des Geschfts- oder Fachberei Fachbereichs Ttigkeiten in den verschiedenen Phasen der Softwareentwicklung, einschlielich Analyse, Entwicklung und technische Support technischen Ttigkeiten im Bereich Softwaretesten Anwender von Softwaresystemen sind vertraut mit der Nutzerseite der Systeme und haben g gute Kenntnisse darber, wie die Systeme angewendet werden, in welchen Bereichen Fehlerwirkungen die schwerwiegendsten Auswirkungen haben wrden, und welches Systemverhalten erwartet werden kann. Fachexperten wissen, welche Bereiche fr das Geschft von grter Wichtigkeit sind, und grter kennen den Einfluss dieser Bereiche auf die Fhigkeit des Unternehmens, die geschftlichen Anforderungen zu erfllen. Dieses Wissen lsst sich nutzen fr die Priorisierung der Testaktivitten, den Entwurf realistischer Testdaten bzw. Testfllen und die Verifizierung oder Beschaffung von Anwendungsfllen. Die Kenntnis des Softwareentwicklungs Prozesses (Anforderungsanalyse, Entwurf, Programmierung) Softwareentwicklungs-Prozesses erklrt, wie sich Fehler einschleichen, wo sie zu finden sind, und wie Fehlern vorgebeugt werden vorgebeugt kann. Erfahrung im technischen Support liefert Wissen ber die Praxis der Nutzer und ihre Erwartungen und Anforderungen an die Benutzbarkeit. Erfahrung im Bereich Softwareentwicklung ist wichtig fr den Einsatz von anspruchsvollen Testautomatisierungswerkzeugen, die Programmier und Testautomatisierungswerkzeugen, ProgrammierEntwurfsspezialisten erfordern. Zu den spezifischen Fertigkeiten beim Softwaretesten gehren die Fhigkeit zur Analyse von Spezifikationen, Teilnahme an Risikoanalyse , Entwurf von Testfllen sowie Flei und Sorgfa beim Risikoanalysen, Sorgfalt Durchfhren der Tests und der Aufzeichnung der Ergebnisse. Fr Testmanager sind Wissen, Fhigkeiten und Erfahrung im Projektmanagement besonders wichtig, weil das Management eines Tests der Leitung eines Projekts entspricht - mit Ttigkeiten, wie Erstellen des Plans, berwachung und Kontrolle des Fortschritts sowie Berichten an die Betroffenen Betroffenen. Zwischenmenschliche Fhigkeiten, wie der Umgang mit Kritik, Einflussnahme und Verhandlungsgeschick sind alle wichtig fr die Rolle des Testers. Technisch kompetente Tester kompetente knnen ihrer Rolle als Tester kaum gerecht werden, wenn sie die ntigen zwischenmenschlichen Version 2007 Seite 117 von 136 Januar 2010 20100131
Fhigkeiten nicht haben und einsetzen. Erfolgreiche Tester mssen nicht nur mit anderen effektiv zusammenarbeiten, sondern auch ihre Arbeit gut organisieren knnen, ein Auge frs Detail haben und organisieren ausgeprgte kommunikative Fhigkeiten besitzen, sowohl schriftlich als auch mndlich.
10.3
Dynamik im Testteam
Eine der wichtigsten Funktionen des Managers in einer Organisation ist die Auswahl der Mitarbeiter. die Neben einer individuellen Befhigung fr die Aufgabe sind viele Aspekte zu bercksichtigen. Wenn eine Person fr das Team ausgewhlt wird, ist auch die Dynamik im Team zu beachten. Wird diese Person die im Testteam vorhandenen Fhigkeiten und verschiedenen Persnlichkeiten sinnvoll Fhigkeiten ergnzen? Es kann Vorteile haben, wenn in einem Testteam sowohl unterschiedliche Persnlichkeiten als auch unterschiedliche technische Fhigkeiten zusammenkommen. Ein starkes Testteam kann mit mehreren Projekten unterschiedlicher Komplexitt umgehen und zugleich die zwischenmenschlichen Beziehungen zu den anderen Mitgliedern im Projektteam erfolgreich gestalten. Neue Teammitglieder mssen schnell vom Testteam integriert werden und eine angemessene Betreuung erhalten. Jede Person im Team sollte ihre definierte Rolle haben, die sich aus einer euung individuellen Beurteilung ergeben kann. Ziel ist es, dass jedes Mitglied als einzelne Person erfolgreich ist und gleichzeitig zum Erfolg des gesamten Teams beitrgt. Das lsst sich zum Einen durch passende Teamrollen fr die jeweiligen Persnlichkeitstypen erreichen, und zum Anderen, indem man sowohl auf die vorhandenen Fhigkeiten des Einzelnen baut als auch sein oder ihr Portfolio an Fhigkeiten erweitert. Hinweis: Es gibt kaum je die perfekt geeignete Person, aber man kann ein starkes Team auch bilden, indem man die Strken und Schwchen der einzelnen Teammitglieder ausgewogen miteinander kombiniert. Durch Wissenstransfer im Team lsst sich das Teamwissen pflegen und aufbauen, was und letztendlich die Flexibilitt erhht.
10.4
Testen in der Organisationsstruktur etablieren
Unternehmen ordnen das Testen sehr unterschiedlich in ihre Organisationsstruktur ein. Die Qualitt gehrt zwar whrend des gesamten Softwarelebenszyklus in die gemeinsame Verantwortung aller, ein unabhngiges Testteam kann aber entscheidend zur einem hochwertigen Produkt beitragen. In der Praxis ist das Testen in unterschiedlichem Mae unabhngig, wie die folgenden Auflistung zeigt, e die von der geringsten zur hchsten Unabhngigkeit reicht: Keine unabhngigen Tester Es gibt keine Unabhngigkeit, und der Entwickler testet seinen eigenen Programmcode. Falls ihm Zeit fr das Testen zur Verfgung steht, wird der Entwickler feststellen, ob das Programm so funktioniert, wie von ihm beabsichtigt. Ob damit die tatschlichen Anforderungen erfllt sind, bleibt offen. Der Entwickler kann aufgedeckte Fehlerzustnde schnell korrigieren. Ein Entwickler testet, der das Programm nicht geschrieben hat. Es gibt nur wenig Unabhngigkeit zwischen Entwickler und Tester. Ein Entwickler, der den Programmcode eines anderen Entwicklers testet, wird Fehlerzustnde mglicherweise ungern berichten. Die Mentalitt eines Entwicklers beim Testen fhrt meist zu einem Fokus auf positive beim Testflle. Ein Tester (oder Testteam) aus dem Entwicklungsteam testet. Tester (oder Testteam) berichten an das Projektmanagement.
Version 2007
Seite 118 von 136
Januar 2010 20100131
Die Mentalitt eines Testers fhrt meist zu einem Fokus darauf, die Einhaltu Einhaltung von Anforderungen zu verifizieren. Weil der Tester Mitglied des Entwicklungsteams ist, kann er zustzlich Entwicklungsaufgaben haben. Tester kommen aus den Fachabteilungen des Unternehmens, aus dem Kreis der Nutzer oder einer anderen technischen Organisation, die nicht mit Softwareentwicklung befasst ist. Organisation, Es wird unabhngig an die Betroffenen berichtet. Qualitt ist das Hauptinteresse dieses Teams. Entwicklung von Fhigkeiten und Schulung konzentrieren sich auf das Testen. Externe Testexperten testen fr spezifische Testziele. Testziele knnten beispielsweise Benutzbarkeit, Sicherheit oder Performanz sein. Qualitt sollte das Hauptinteresse dieser Experten sein; das hngt aber vom Berichtsweg ab. Eine externe Organisation testet. Es gibt maximale Unabhng Unabhngigkeit. Der Wissenstransfer kann unzureichend sein. Es sind eindeutige Anforderungen und eine gut definierte Kommunikationsstruktur notwendig. Die Qualitt der externen Organisation muss regelmig in einem Audit bewertet werden Der Grad der Unabhngigkeit zwischen Entwicklungs und Testorganisationen variiert stark. Hinweis: t EntwicklungsEin Mehr an Unabhngigkeit kann mit mehr Isolation und weniger Wissenstransfer einhergehen. Ein geringeres Ma an Unabhngigkeit kann das Wissen ber das System verbessern, es kann ab zu aber Interessenskonflikten durch widersprchliche Zielsetzungen fhren. Der Grad der Unabhngigkeit wird auch vom Softwareentwicklungs-Modell bestimmt: bei einer agilen Entwicklungsmethode sind Tester Modell beispielsweise meist Teil des Entwicklungsteams. Die oben erwhnten Optionen knnen in einem Unternehmen gemischt vorkommen. Es kann in der ben Entwicklungsabteilung getestet werden und zustzlich durch eine unabhngige Testabteilung; abschlieend kann eine externe Organisation zertifizieren. Es ist wichtig, Zustndigkeiten und Zustndigkeiten Erwartungen fr die einzelnen Teststufen zu verstehen, und die Anforderungen an sie so zu stellen, dass sich die bestmgliche Qualitt des Endprodukts im Rahmen der zeitlichen und finanziellen Grenzen erzielen lsst. Outsourcing ist eine Mglichkeit, eine externe Organisation mit dem Testen zu betrauen. Es kann sich glichkeit, dabei um ein anderes Unternehmen handeln, das die Testleistungen vor Ort, an einem externen Standort im eigenen Land, oder im Ausland (off (off-shore) erbringt. Outsourcing ist eine Herausforderung, erausforderung, vor allem, wenn die externe Organisation im Ausland angesiedelt ist. Folgende Aspekte sollten bercksichtigt werden: kulturelle Unterschiede berwachung der Outsourcing Outsourcing-Ressourcen Informationstransfer, Kommunikation Schutz geistigen Eigentums ums Bestehende Fhigkeiten, Entwicklung weitere Fhigkeiten und Schulungen Fluktuation der Mitarbeiter genaue Kostenschtzungen Qualitt
10.5
Version 2007
Motivieren
Seite 119 von 136 Januar 2010 20100131
Es gibt viele Mglichkeiten, die einzelnen Testmitarbeiter zu motivieren, darunter
Anerkennung fr die bewltigten Aufgaben Einverstndnis des Managements Respekt im Projektteam und in der Gruppe angemessene materielle Anerkennung der geleisteten Arbeit (einschlielich Gehalt, Leistungszulagen und Bonuszahlungen) Bestimmte Projekteinflsse knnen die Anwendung dieser Anreize erschweren. So arbeitet ein Tester sse mglicherweise sehr hart an einem Projekt mit einem unmglichen Endtermin. Er oder sie kann dann alles Menschenmgliche unternehmen (berstunden, Mehrarbeit), um die Qualittsziele im Team voranzutreiben, aber das Produkt wird aufgrund externer Einflsse vorzeitig ausgeliefert und kann trotz aller Bemhungen des Testers eine schlechte Qualitt haben. Solche Vorkommnisse knnen demotivieren, vor allem, wenn der Einsatz des Testers nicht verstanden und angerechnet wird, nicht unabhngig davon, ob das Endprodukt erfolgreich ist. Das Testteam muss geeignete Metriken festhalten, um nachzuweisen, dass bei Durchfhrung des Testens gute Arbeit geleistet, Risiken minimiert und Ergebnisse richtig protokolliert wurden , tokolliert wurden.Werden diese Informationen nicht erfasst und mitgeteilt, kann ein Team leicht demotiviert werden, weil ihm die Anerkennung fr seine gute Arbeit fehlt. Anerkennung zeigt sich nicht nur in abstrakten Konzepten, wie Respekt und Zustimmung, sie wird deutlich wahrnehmbar in konkreten Befrderungschancen, Gehaltsstufen und Laufbahnen. Wird die Testgruppe nicht respektiert, dann knnen solche Chancen fehlen. Anerkennung und Respekt gewinnen die Tester, wenn es offensichtlich wird, dass sie den M Mehrwert eines Projekts steigern. Bei einem einzelnen Projekt lsst sich das am schnellsten erreichen, indem die Tester bereits an der Konzeption des Projekts beteiligt werden und es ber den gesamten Softwarelebenszyklus bleiben. Mit der Zeit werden die Tester Anerkennung und Respekt fr ihren Tester Beitrag zur positiven Entwicklung des Projekts erhalten; ihr Beitrag sollte aber auch als geringere Kosten fr die Qualitt und Risikobeherrschung quantifiziert werden.
10.6
Kommunizieren
Die Kommunikation im Testteam findet vorwiegend auf drei Ebenen statt: kation Dokumentation der Testprodukte: Teststrategie, Testkonzept, Testflle, Testberichte, Fehlerberichte usw. Review-Feedback zu geprften Dokumenten: Anforderungen, Funktionsspezifikationen, Feedback Anwendungsflle, Komponententestdokumentation usw. gsflle, Sammeln und Verteilen von Informationen: Interaktion mit Entwicklern, anderen Testteammitgliedern, Management usw. Die Kommunikation muss immer professionell, objektiv und effektiv sein, damit das Testteam von anderen respektiert wird. Wenn Tester anderen Beteiligten Rckmeldungen, vor allem konstruktive deren Kritik, zu deren Arbeitsergebnissen mitteilen, brauchen sie Fingerspitzengefhl und Objektivitt. Zweck der Kommunikation sollte immer sein, die Testziele zu erreichen und sowohl die Qualitt des erreichen Produkts zu verbessern als auch die der Prozesse fr die Produktion der Softwaresysteme. Tester kommunizieren mit einem breiten Personenkreis, wie Nutzern, Projektteammitgliedern, Management, externen Testgruppen und Kunden. Die Kommunikation muss fr die jeweiligen Adressaten effektiv n. sein. So kann beispielweise ein Bericht fr die Entwickler, der die wchentliche Menge der gefundenen Fehlern mit einem bestimmten Schweregrad aufzeigt, fr eine Managementprsentation auf Vorstandsebene zu detailliert und damit ungeeignet sein. rstandsebene
Version 2007
Seite 120 von 136
Januar 2010 20100131
11. Referenzen
11.1
11.1.1
Standards
Nach Kapiteln
Dieser Abschnitt nennt die in diesem Lehrplan erwhnten Standards.
Folgende Kapitel verweisen auf Standards: erweisen Kapitel 2 BS 7925-2, IEEE 829, DO-178B/ED 178B/ED-12B Kapitel 3 IEEE 829, D0-178B/ED-12B 12B Kapitel 4 BS 7925-2 Kapitel 5 ISO 9126, BS 7925-2 Kapitel 6 IEEE 1028 Kapitel 7 IEEE 829, IEEE 1044, IEEE 1044.1. Kapitel 8 IEEE 829, IEEE 1028, IEEE 1044, IEEE 1044.1, BS 7925-2
11.1.2
Alphabetisch
Folgende alphabetisch aufgelisteten Standards werden in den angegebenen Kapiteln erwhnt: [BS 7925-2] BS 7925-2 (1998) Software Component Testing 2 Kapitel 2 und 4 [IEEE 829] IEEE Std 829 (1998) IEEE Standard for Software Test Documentation Kapitel 2, 3, 7 und 8 [IEEE 1028] IEEE Std 1028 (1997) IEEE Standard for Software Reviews Kapitel 6 und 8 [IEEE 1044] IEEE Std 1044 (1993) IEEE Standard Classification for Software Anomalies Kapitel 7 und 8 [ISO 9126] ISO/IEC 9126-1:2001, Software Engineering Software Product Quality 1:2001, Kapitel 5 [ISTQB] ISTQB Glossary of terms used in Software Testing, Version 2.0, 2007 Fr die entsprechende deutschsprachige Fassung des Glossars, siehe bitte die Web ehe Web-Site des German Testing Boards ( www.german www.german-testing-board.info ).
Version 2007
Seite 121 von 136
Januar 2010 20100131
[RTCA DO-178B/ED-12B]: Software Considerations in Airborne systems and Equipment 12B]: certification, RTCA/EUROCAE ED12B.1992. UROCAE Kapitel 2 und 3
11.2
Literatur
[Beizer95] Beizer Boris, Black-box testing, John Wiley & Sons, 1995, ISBN 0 box 0-471-12094 12094-4 [Black02] Rex Black, Managing the Testing Process (2nd edition), John Wiley & Sons: New Yo York, 2002, ISBN 0-471-22398-0 [Black03] Rex Black, Critical Testing Processes, Addison Addison-Wesley, 2003, ISBN 0-201-74868 74868-1 [Black07] Rex Black, Pragmatic Software Testing, John Wiley and Sons, 2007, , ISBN 978-0-470-12790-2 [Burnstein03] Ilene Burnstein, Practical Software Testing, Springer, 2003, ISBN 0 ractical 0-387-95131-8 [Buwalda01] Hans Buwalda, Integrated Test Design and Automation Addison Wesley Longman, Addison-Wesley 2001, ISBN 0-201-73725-6 [Copeland03] Lee Copeland, A Practitioner's Guide to Software Test Design, Artech House, 2003, Artech ISBN 1-58053-791-X [Craig02] Craig, Rick David; Jaskiel, Stefan P., Systematic Software Testing, Artech House, 2002, ISBN 1-580-53508-9 [Gerrard02] Paul Gerrard, Neil Thompson, Risk Risk-based e-business testing, Artech House, 2002, ISBN business 1-580-53314-0 [Gilb93] Gilb Tom, Graham Dorothy, Software inspection, Addison Addison-Wesley, 1993, ISBN 0-201-63181-4 [Graham07] Dorothy Graham, Erik van Veenendaal, Isabel Evans, Rex Black Foundations of Software Testing, Thomson Learning, 2007, ISBN 978 978-1-84480-355-2 [Grochmann94] M. Grochmann (1994), Test case design using Classification Trees, in: conference proceeedings STAR 1994 [Jorgensen02] Paul C.Jorgensen, Software Testing, a Craftsmans Approach second edition, CRC press, 2002, ISBN 0-8493-0809 9-7 [Kaner02] Cem Kaner, James Bach, Bret Pettichord; Lessons Learned in Software Testing; Wiley, 2002, ISBN: 0-471-08112-4 [Koomen99] Tim Koomen, Martin Pol, Test Process Improvement, Addison Addison-Wesley, 1999, y, ISBN 0-201-59624-5 [Myers79] Glenford J.Myers, The Art of Software Testing, John Wiley & Sons, 1979, ers, ISBN 0-471-46912-2 [Pol02] Martin Pol, Ruud Teunissen, Erik van Veenendaal, Software Testing: A Guide to the Tmap Approach, Addison-Wesley, 2002, ISBN 0 Wesley, 0-201-74571-2 [Splaine01] Steven Splaine, Stefan P.,Jaskiel, The Web Testing Handbook, STQE Publishing, 2001, , Web-Testing ISBN 0-970-43630-0 [Stamatis95] D.H. Stamatis, Failure Mode and Effect Analysis, ASQC Quality Press, 1995, ISBN 0-873-89300 [vanVeenendaal02] van Veenendaal Erik, The Testing Practitioner, UTN Publsihing, 2002, Practitioner, ISBN 90-72194-65-9
Version 2007
Seite 122 von 136
Januar 2010 20100131
[Whittaker03] James Whittaker, How to Break Software, Addison Addison-Wesley, 2003, ISBN 0-201-79619-8 [Whittaker04] James Whittaker and Herbert Thompson, How to Break Software Security, Peason / Addison-Wesley, 2004, ISBN 0-321-19433-0
Version 2007
Seite 123 von 136
Januar 2010 20100131
11.3
Sonstige Referenzen
Die folgenden Referenzen verweisen auf Informationen im Internet. Die Referenzen wurden zum Zeitpunkt der Verffentlichung dieses Advanced Level Lehrplans vom ISTQB geprft, das ISTQB kann aber keine Verantwortung fr ihre Verfgbarkeit bernehmen. , Kapitel 5 www.testingstandards.co.uk Kapitel 8 TMMi www.tmmifoundation.org Weitere www.sei.cmu.edu/cmmi/adoption/pdf/cmmi-overview06.pdf www.sei.cmu.edu/cmmi/adoption/pdf/cmmi Bug Taxonomy: www.testingeducation.org/a/bsct2.pdf Sample Bug Taxonomy based on Boris Beizers work: inet.uni2.dk/~vinter/bugtaxst.doc inet.uni2.dk/~vinter/bugtaxst.doc Gute bersicht ber verschiedene Taxonomien: testingeducation.org/a/bugtax.pdf Heuristic Risk-Based Testing von James Bach. James Bach, Interview auf What is Based Testing.com. www.whatistesting.com/interviews/jbach.htm www.satisfice.com/articles/et-article.pdf www.satisfice.com/articles/et From Exploratory & Risk Risk-Based Testing (2004) www.testingeducation.org Exploring Exploratory Testing, Cem Kaner and Andy Tikam, 2003 Pettichord, Bret, An Exploratory Testing Workshop Report, www.testingcraft.com/exploratorypettichord
Version 2007
Seite 124 von 136
Januar 2010 20100131
12. Anhang A Hintergrundinformationen zum Lehrplan

Ziele fr die Advanced Level Zertifizierung und Qualifizierung
Anerkennung des Testens als eine eigene essentielle und professionelle Disziplin der Softwareentwicklung Schaffung eines standardisierten Rahmens fr die berufliche Laufbahn von Softwaretestern Verbesserung der Anerkennung von professionellen und qualifizierten Testern durch er Arbeitgeber, Kunden und Arbeitskollegen; Schrfung ihres Profils Frderung konsistenter und guter Testpraktiken in allen Disziplinen der Softwareentwicklung Identifizierung von Testthematiken, die fr die Industrie relevant und wertvoll sind Testthematiken, Softwarelieferanten zu ermglichen, dass sie zertifizierte Tester einstellen und mit dieser Personalpolitik einen Wettbewerbsvorteil gegenber der Konkurrenz erzielen Testern und am Testen interessierten Personen zu ermglichen, dass sie eine international interessierten anerkannte Qualifizierung erlangen
Zulassungsanforderungen fr diese Qualifikation

Fr die Zulassung zur Prfung fr das ISTQB Advanced Level Zertifikat Softwaretes Softwaretesten gelten folgende Kriterien: Basiszertifikat Foundation Level, ausgestellt von einer vom ISTQB anerkannten Prfungsinstitution oder einem ISTQB Mitgliedsboard. angemessene Anzahl von Jahren der Erfahrung im Bereich Softwaretesten oder Softwareentwicklung, gem Festlegung durch die Prfungsinstitution oder das ISTQB ung, Mitgliedsboard, die fr die Advanced Level Level-Zertifizierung zustndig sind Anerkennung des in diesem Lehrplan enthaltenen Ethik Ethik-Kodex. Es wird weiterhin empfohlen, dass die Prfungskandidaten an einem Kurs teilnehmen, der von einem Prfungskandidaten ISTQB Mitgliedsboard akkreditiert ist. Fr die Teilnahme an einer ISTQB Prfung ist die Schulung nicht zwingend vorgeschrieben. Bestehende Zertifizierungen im Softwaretesten (Practitioner Certificate oder Advanced Certificate), Advanced die von einem vom ISTQB anerkannten Mitgliedsboard oder Prfungsinstitution vor Einfhrung dieses internationalen Zertifikats ausgestellt wurden, sind als gleichwertig mit dem Internationalen Zertifikat anerkannt. Das ISTQB Advanced Level Zertifikat Softwaretesten wird nicht ungltig und muss nicht erneuert werden. Das Datum der Ausstellung ist auf dem Zertifikat angegeben. In den teilnehmenden Lndern werden lokale Aspekte vom jeweiligen vom ISTQB anerkannten nationalen Testing-Board kontrolliert. Die Pflichten der Mitgliedsboards sind vom ISTQB festgelegt, oard werden aber durch die jeweiligen nationalen Organisationen umgesetzt. Zu den Pflichten der Mitgliedsboards gehrt die Akkreditierung von Ausbildungsanbietern und das Ansetzen von Prfungen, die direkt oder indirekt durch eine oder mehrere vertraglich verpflichtete Prfungsinstitutionen durchgefhrt werden.
Version 2007
Seite 125 von 136
Januar 2010 20100131
13. Anhang B Hinweise fr die Leser

13.1 Prfungsinstitutionen
Dieser Advanced Level Lehrplan des Aufbaukurses setzt die Kenntnis des Inhalts des Lehrplans des Grundkurses (ISTQB Certified Tester Foundation Level, Version 2005) voraus, mit der im erwhnten Grundkurs-Lehrplan festgelegten Wissensstufe. Lehrplan Vom ISTQB anerkannte Prfungsinstitutionen knnen Prfungsfragen aus allen Themen dieses QB Lehrplans erarbeiten. Es wird empfohlen, dass die Prfungsfragen unterschiedlich gewertet werden, je nach den Lernzielen des entsprechenden Themas. Beispiel: Einer Prfungsfrage der kognitiven Ebene K1 werden weniger Prfungsfrage Punkte zugeordnet als einer der kognitiven Ebene K3, eine Prfungsfrage der Ebene K4 bekme mehr Punkte.
13.2
Prfungskandidaten und Ausbildungsanbieter
Fr die Zertifizierung als ISTQB Certified Tester Advanced Level mssen die Prfungskandidaten ertifizierung das Zertifikat ISTQB Certified Tester Foundation Level vorweisen und der fr sie zustndigen Prfungsinstitution nachweisen, dass sie ausreichend praktische Erfahrung haben, um als fr die haben, Aufbaustufe (Advanced Level) qualifiziert zu gelten. Bitte wenden Sie sich an die fr Sie zustndige Prfungsinstitution, um die spezifischen Kriterien zum Nachweis der notwendigen praktischen 5 Erfahrung zu erfahren . Um ein angemessen Knnen fr den Advanced Level-Status im Berufsfeld angemessenes Status Softwaretesten zu erreichen, wird von den Prfungskandidaten mehr verlangt als nur die Inhalte dieses Lehrplans zu kennen. Prfungskandidaten und Ausbildungsanbieter sollten mehr Zeit als in diesem Lehrplan angegeben aufbringen, um sich mit der Thematik zu beschftigen, sei es durch plan Lesen oder Recherche. Dieser Lehrplan enthlt eine Liste der Referenzen, Bcher und Standards, die als zustzliche Lektre fr Prfungskandidaten und Ausbildungsanbieter gedacht sind, damit sie die Themen des Lehrplans gedacht detaillierter verstehen.
Fr mgliche Aktualisierungen siehe bitte die Web ite des German Testing Boards (www.german ehe Web-Site (www.germantesting-board.info) Version 2007 Seite 126 von 136 Januar 2010 20100131
14. Anhang C Hinweise fr die Ausbildungsanbieter

14.1 Module
Dieser Lehrplan enthlt die Inhalte der drei f folgenden Module: 1. Advanced Level Testmanager 2. Advanced Level Test Analyst 3. Advanced Level Technical Test Analyst Mit Bestehen der Prfungen zu allen drei Modulen ist der Prfungskandidat zertifiziert als Full Advanced Level Testing Professional.
14.2
14.2.1
Ausbildungszeiten szeiten
Ausbildung je Modul
Der Unterricht in jeder der 3 unterschiedlichen Rollen sollte die folgende Zeit dauern: 1. Advanced Level Testmanager 5 Tage 2. Advanced Level Test Analyst 5 Tage 3. Advanced Level Technical Test Analyst 5 Tage Die Kursdauer basiert auf der Anzahl der Kapitel je Modul und den spezifischen Lernzielen des jeweiligen Kapitels. Die minimale Zeitdauer je Kapitel und Rolle ist festgelegt. Ausbildungsanbieter knnen mehr als die angegebene Zeit ansetzen, und die Kandidaten knnen darber hinaus zustzliche Zeit fr Studium und Recherche aufwenden. Das Kursprogramm muss die Reihenfolge der Kapitel in diesem Lehrplan nicht einhalten. Die Kurse mssen nicht an aufeinander folgenden Tagen stattfinden. Es ist den Ausbildungsanbietern freigestellt, ihre Kurse anders zu organisieren, beispielsweise 3 + 2 Tage fr Testmanager, oder 2 re gemeinsame Tage gefolgt von jeweils 3 Tagen fr Test Analysts und Technical Test Analysts.
14.2.2
Gemeinsamkeiten
Ausbildungsanbieter knnen sich entscheiden, gemeinsame Themen nur einmal zu vermitteln, um so die Gesamtdauer zu verringern und Wiederholungen zu vermeiden. Die Ausbildungsanbieter werden aber darauf hingewiesen, dass dasselbe Thema manchmal aus unterschiedlichen Perspektiven zu betrachten ist, je nach Kursmodul.
14.2.3
Quellen
Der Lehrplan enthlt Referenzen auf gngige Standards, die fr die Vorbereitung der Kursmaterialien zu verwenden sind. Jeder Standard muss dabei in der im Lehrplan referenzierten Version verwendet werden. Weitere Publikationen, Vorlagen oder Standards, die in diesem Lehrplan nicht angegeben die sind, knnen verwendet und referenziert werden, sind aber nicht Gegenstand der Prfung.
14.3
Praktische bungen
Praktische Arbeiten (kurze bungen) sollten bei allen Lerninhalten eingesetzt werden, bei denen die Kandidaten ihr Wissen anwenden sollen (Lernziele der Ebene K3 oder hher). Die Kursvortrge und
Version 2007
Seite 127 von 136
Januar 2010 20100131
bungen sollten auf den Lernzielen dieses Lehrplans sowie auf den im Lehrplan enthaltenen Beschreibungen der einzelnen Themen basieren.
Version 2007
Seite 128 von 136
Januar 2010 20100131
15. Anhang D Empfehlungen

Die folgenden Empfehlungen beziehen sich auf mehrere Kapitel dieses Lehrplans und wurden deshalb in einem Anhang zusammengefasst. Diese Empfehlungen sind prfungsrelevant. Die Liste enthlt eine Reihe hilfreicher Empfehlungen, wie sich die Herausforderungen beim Testen sich bewltigen lassen, und basiert auf den im Foundation-Level-Lehrplan eingefhrten sieben Grundstzen des Softwaretestens. Die nachfolgende Liste erhebt keinen Anspruch auf Vollstndigkeit, sondern ist gedacht als eine Auswahl gewonnener Erkenntnisse (lessons learned), die bercksichtigt wahl werden sollten. Ausbildungsanbieter whlen aus der Liste die Punkte aus, die fr das jeweilige Modul am ehesten relevant sind.
15.1
Empfehlungen fr die Industrialisierung
Beim Implementieren von Tests in einer industriellen Umgebung sind Tester mit verschiedenen Herausforderungen konfrontiert. Fortgeschrittene Tester sollten die verschiedenen Empfehlungen dieses Lehrplans im Kontext ihrer eigenen Organisation, Teams, Aufgaben und Softwarekomponenten anwenden knnen. Die folgende Liste beschreibt Aspekte, die sich bei der Durchfhrung von Testaufgaben immer wieder negativ ausgewirkt haben. Die Liste erhebt keinen Anspruch auf Vollstndigkeit. Testkonzepte werden mit dem Schwerpunkt auf funktionalen Tests erstellt. onzepte Fehlerzustnde sind nicht auf funktionale Aspekte beschrnkt, oder auf einen einzelnen Nutzer. Die Interaktion von mehreren Nutzern kann sich auf die zu prfende Software auswirken. Konfiguration wird nicht ausreichend getestet. guration Wenn mehrere Arten von Prozessoren, Betriebssystemen, virtuellen Maschinen, Browsern und diversen Peripheriegerten zu vielen unterschiedlichen Konfigurationen kombiniert werden knnen, knnen viele potenzielle Fehlerzustnde unentdeckt bleiben, wenn das Fehlerzustnde Testen auf einige wenige Konfigurationen begrenzt wird. Stress- und Lasttests werden auf den letzten Moment verschoben. Die Ergebnisse der Stress und Lasttests knnen groe nderungen in der Software Stresserforderlich machen (bis hin zur Grundarchitektur). Da dafr mglicherweise betrchtliche Ressourcen bentigt werden, kann es sich sehr negativ auf das Projekt auswirken, wenn die Tests erst kurz vor der geplanten Produktionseinfhrung erfolgen. Dokumentation wird nicht getestet. ht Nutzer erhalten Software und Dokumentation. Wenn die Dokumentation nicht zur Software passt, knnen die Nutzer das volle Potenzial der Software nicht ausschpfen, oder werden die Software mglicherweise gar nicht verwenden. Installationsprozedur wird nicht getestet. dur Installationsprozeduren, wie auch Backup und Wiederherstellungsprozeduren, werden nicht Backupoft durchgefhrt, sind aber kritischer als die Software. Wenn sich die Software nicht installieren lsst, wird sie berhaupt nicht verwendet. Es wird darauf bestanden, dass eine Testaufgabe vor Beginn der nchsten vollstndig abgeschlossen ist. Obwohl manche Softwarelebenszyklusmodelle die sequenzielle Durchfhrung der Aufgaben empfehlen, mssen in der Praxis oft einige Aufgaben (zumindest teilweise) gleichzeitig teilweise) ausgefhrt werden.
Version 2007
Seite 129 von 136
Januar 2010 20100131
Risikobereiche werden nicht korrekt identifiziert. Bereiche, die als riskant eingestuft wurden, werden grndlicher getestet. Fr Bereiche, die nur wenig oder gar nicht getestet wurden, kann sich das Risiko spter als hher herausstellen als als ursprnglich angenommen. Testeingaben und Testprozeduren werden zu genau spezifiziert. Lsst man Testern nicht gengend Freiraum fr eigene Initiative bei der Definition von Testeingaben und vorgehen, dann werden sie womglich vielversprechende Bereiche (mit vorgehen, mglicherweise vorhandenen, versteckten Fehlern) nicht nher untersuchen. Irrelevante Merkwrdigkeiten (Nebeneffekte) werden nicht bemerkt oder untersucht. Scheinbar irrelevante Beobachtungen oder Ergebnisse sind oft Hinweise auf mgliche Fehler, Hinweise die sich (wie Eisberge) unter der Oberflche verstecken. Es wird geprft, ob das Produkt tut, was es tun soll, aber nicht, ob es nicht tut, was es nicht tun soll. Wird nur getestet, was das Produkt knnen soll, werden mglicherweise Aspekte der Software mglicherweise bersehen, die sie nicht haben soll (beispielsweise zustzliche, unerwnschte Funktionen). Testsuiten sind nur fr ihre Eigentmer verstndlich. Wenn Tester zu anderen Zustndigkeitsbereichen wechseln, mssen andere Tester die spezifizierten Tests lesen und verstehen. Wenn keine nachvollziehbaren und verstndlichen ezifizierten Testspezifikationen vorhanden sind, kann sich das negativ auswirken. Testziele werden mglicherweise nicht verstanden, oder der Test wird ganz gestrichen. Es wird nur ber die fr die Nutzer sichtbare Schnittstelle getestet. Schnittstellen einer Software beschrnken sich nicht auf die Benutzerschnittstelle. Auch Kommunikation zwischen Prozessen, Batch Verarbeitung und andere Interrupts beeinflussen Batch-Verarbeitung die Software und knnen Fehlerwirkungen auslsen. nen Abweichungsberichte und Konfigurationsmanagement sind schlecht. Fehler-/Abweichungsmanagement und -berichte sowie das Konfigurationsmanagement sind /Abweichungsmanagement berichte auerordentlich wichtig fr den Erfolg des Gesamtprojekts (fr Entwicklung un Test). Die und Arbeit eines Testers ist dann erfolgreich, wenn gefundene Fehler korrigiert und behoben werden, nicht dann, wenn zwar viele Fehler gefunden, fr eine Korrektur aber nicht gut genug beschrieben werden. Es kommen nur Regressionstests hinzu. Testsuiten ber die Zeit zu entwickeln, beschrnkt sich nicht darauf zu prfen, ob tsuiten Regressionsfehler vorkommen. Der Programmcode wird sich im Laufe der Zeit weiterentwickeln, und es mssen zustzliche Tests implementiert werden, um diese neuen Funktionalitten abzudecken und mgliche Regressionen in anderen Bereichen der Software n zu prfen. Es werden keine Notizen fr kommende Testaufgaben gemacht. Die Testaufgaben sind nicht abgeschlossen, wenn die Software an die Nutzer bergeben wird oder auf den Markt kommt. Wahrscheinlich wird es eine neue Version oder Release geben, mt. deshalb sollte das entsprechende Wissen gesichert und an die Tester weitergegeben werden, die fr die nchsten Testaufgaben zustndig sind. Es wird versucht, Tests vollstndig zu automatisier automatisieren. Automatisierung kann sinnvoll erscheinen, ist aber ein eigenes Entwicklungsprojekt. Es sollten nicht alle Tests automatisiert werden, manche Tests lassen sich schneller manuell durchfhren als automatisieren. Es wird erwartet, dass alle manuellen Tes wiederholt werden. Tests Wenn die manuellen Tests wiederholt werden, ist es oft unrealistisch zu erwarten, dass alle wiederholt werden. Die Aufmerksamkeit der Tester wird schwanken, und sie werden sich, ob bewusst oder unbewusst, auf bestimmte Bereiche der S Software konzentrieren. Seite 130 von 136 Januar 2010 20100131
Version 2007
GUI-Automatisierungswerkzeuge werden eingesetzt, um die Testerstellungskosten zu Automatisierungswerkzeuge reduzieren. Ein GUI-Mitschnittwerkzeug Mitschnittwerkzeug (Capture/Replay-Werkzeug) (Capture/Replay Werkzeug) ist eine erhebliche Anfangsinvestition. Das Werkzeug sollte im Rahmen einer definierten Strategie eingesetzt und definierten alle damit verbundenen Kosten klar sein und bewertet werden. Es wird erwartet, dass Regressionstests einen hohen Anteil neuer Fehlerzustnde aufdecken. Regressionstests finden im Allgemeinen keinen hohen Anteil neuer Fehlerzust Fehlerzustnde, vor allem weil die Tests bereits einmal durchgefhrt wurden (beispielsweise bei einer frheren Version der Software). Die Fehlerzustnde sollten bereits zu diesem Zeitpunkt aufgedeckt worden sein. Das bedeutet nicht, dass Regressionstests ganz entfallen sollten. Ihre Effektivitt (die entfallen Fhigkeit neue Fehler zu finden) ist aber geringer als die anderer Testarten. Die Codeberdeckung begeistert allein wegen der schnen Zahlen. Codeberdeckungen und Metriken sind aus Sicht des Managements uerst interes interessant, weil sie Zahlen und Graphiken liefern. Zahlen sagen aber wenig aus ber Effektivitt oder Sachdienlichkeit eines Tests. Beispiel: 100% berdeckung ist zwar eine schne Zielsetzung berdeckung fr Codeberdeckung; ist dieses Ziel aber auch realistisch und geeignet (d.h., sollte es eine Anweisungs-, , eine BedingungsBedingungs oder eine modifizierte BedingungsBedingungs /Entscheidungsberdeckung sein)? berdeckung Tests werden aus einer Regressions Testsuite gestrichen, nur weil sie ein bestimmtes Regressions-Testsuite berdeckungsma nicht erhhen. In einer Regressions-Testsuite drfen (oder sollten) einige Tests gestrichen und andere Testsuite hinzugefgt werden. Die Entscheidung, bestimmte Tests zu streichen, sollte aber nicht nur davon abhngen, ob der Test ein einzelnes berdeckungsma erhht, weil der Testfall (oder die Art des Fehlers, die der Test aufdeckt) mglicherweise keinen Einfluss auf die betrachtete t Testberdeckung hat. Beispiel: Codeberdeckung ist nicht die einzige Art von berdeckung. Tests wurden mglicherweise aus anderen Grnden erstellt (beispielsweise fr spezifische Werte oder Ereignisketten). berdeckung dient als Kriterium fr die Leistung der Tester. berdeckungsgrad ist ein Ma fr die Vollstndigkeit, nicht fr Leistung oder Effizienz der Mitarbeiter. Fr die Bewertung der Testereffizienz im Kontext der Organisation oder des Projekts lassen sich andere Metriken definieren. Ihr Einsatz muss aber sehr sorgfltig berlegt werden, um unerwnschte, dysfunktionale Effekte zu vermeiden. Die berdeckung wird berhaupt nicht mehr gemessen. Es gibt unterschiedliche Arten von berdeckung (beispielsweise von Programmanweisungen, dliche Bedingungen, Modulen, Funktionen usw.), und der Arbeitsaufwand fr die Erhebung von geeigneten Metriken kann betrchtlich sein. Das ist aber kein Grund, auf berdeckungsmetriken ganz zu verzichten, weil sie fr die Testaufgabe sehr ntzlich sein knnen. Viele dieser Punkte werden in einzelnen Abschnitten dieses Lehrplans angesprochen. Wenn Testmanahmen und -praktiken in einem Unternehmen eingefhrt werden sollen, sollten nicht praktiken nur die oben aufgelisteten Punkte, sondern weitere Informationsquellen bercksichtigt werden, ben beispielsweise: Die ISTQB Lehrplne, Foundation und Advanced Level Im Kapitel Literatur dieses Lehrplans genannte Bcher Referenzmodelle, wie beispielsweise in Abschnitt 8.3 beschrieben. zmodelle,
Version 2007
Seite 131 von 136
Januar 2010 20100131
16. Index
Abschluss der Testaktivitten ........................35 Abweichungen Kommunikation................................ ..........................................93 Metriken.....................................................93 ..................... Abweichungsmanagement ............................91 adaptive Wartung ................................ ..........................................83 Allgemeines Gleichbehandlungsgesetz (AGG) ........................................................76 ........................ Analysewerkzeuge statische und dynamische .......................113 nderbarkeit ..................................................83 .................. Anforderungen der Betroffenen .....................61 Anhang A Hintergrundinformationen zum Lehrplan ..................................................124 .................. Anhang B Hinweise fr die Leser .............125 Anhang C Hinweise ise fr die Ausbildungsanbieter ..........................10, 126 Anhang D Empfehlungen .........................128 Anomalie ........................................................91 ........................ Anpassbarkeitstests ................................ ......................................85 Anti-Diskriminierungsgesetze ........................77 Anwendungsprofil ................................ ..........................................74 quivalenzklassenbildung .............................64 quivalenzklassentest ................................ 65 ................................... Art des Risikos ...............................................44 ............... Audit...............................................................86 ............................... Ausbildungsanbieter ............................125, 126 Austauschbarkeitstests................................ 85 .................................. Automatisierung Kosten, Nutzen, Risiken ..........................106 Automatisierungssprachen ..........................108 Barrierefreiheit ...............................................77 ............... bentigte Hardware ................................ .......................................62 bentigte Werkzeuge................................ 61 ..................................... Benutzbarkeitstest ................................ .........................................74 betrieblicher Abnahmetest .............................74 Capability Maturity Model ..............................94 Capability Maturity Model Integration ............94 ability checklistenbasiert ................................ ..........................................69 CMMI ...........................................................103 ........................... CTP.................................................. ..................98, 99, 102 Datenflussanalyse ................................ .........................................64 definierter Bedingungstest .............................67 Disability Discrimination Acts.........................77 ......................... Dokumentvorlagen ................................ ........................................47 Version 2007 Dynamik im Testteam ................................ 117 ................................. dynamische Analyse ................................ ..................................... 72 fehlerhafte Zeiger aufdecken .................... 73 Speicherengpsse aufdecken .................. 72 Systemleistung analysieren ...................... 73 berdeckung ................................ ............................................ 68 bersicht................................ ................................................... 72 EE-Pfad ......................................................... 64 ......................... Effizienztest ................................ ................................................... 74 Effizienztestspezifikation ............................... 83 einfacher Bedingungstest ............................. 67 Empfehlungen fr die Industrialisierung ..... 128 Entscheidungstabellen ................................ 65 .................................. Entscheidungsberdeckungstest .................. 67 berdeckungstest erfahrungsbasierte Testverfahren ................. 68 Erwartungen ................................ .................................................. 11 ethische Leitlinien ................................ ......................................... 34 explorativ ....................................................... 70 ....................... falsch positiv ................................ ............................................... 113 FDA ............................................................... 97 ............................... Fehler- und Abweichungsmanagement ........ 91 Fehlerangriff ................................ ............................................ 64, 70 fehlerbasierte Testverfahren ......................... 68 fehlerhafter Zeiger................................ ......................................... 64 Fehlerinjektions-Werkzeug ......................... 112 Fehlerlebenszyklus ................................ ....................................... 91 Fehler-Lebenszyklus Abweichungsfelder ................................ 92 ................................... Schritt 1: Erkennen ................................ 92 ................................... Schritt 2: Untersuchen .............................. 92 Schritt 3: Manahmen .............................. 92 Schritt 4: Schlieen ................................ 92 .................................. Fehlertaxonomie ................................ ........................................... 64 Fehlerzustand aufdecken ................................ ................................................. 91 FMEA ............................................................ 44 ............................ Anwendungsbereiche ............................... 58 Beschreibung ................................ ............................................ 58 Durchfhrung ................................ ............................................ 58 Kosten und Nutzen ................................ 58 ................................... FMEA (Fehler-Mglichkeits- und Einfluss EinflussAnalyse) .................................................... 58 .................... Funktionsinteraktionstest .............................. 30 Geschftswert des Testens .......................... 51 Grenzwertanalyse ................................ ......................................... 65 Januar 2010 20100131
Seite 132 von 136
grundlegende Aspekte Ethik-Kodex ...............................................34 ............... ethische Leitlinien ................................ ......................................34 Messung ....................................................33 .................... Metrik .........................................................33 ......................... Multisysteme ................................ .............................................31 sicherheitskritische Systeme .....................32 Software-Lebenszyklus .............................29 Gutachten und Befragungen .........................77 Hardware-Software Integrationstest ..............30 heuristische Evaluation............................74, 77 HSIA ..............................................................97 .............................. individuelle Fhigkeiten ...............................116 informelles Review ................................ ........................................86 Insourcing ......................................................51 ...................... Inspektion ......................................................86 ...................... Internationale Standards ...............................95 Interoperabilittstest ................................ ......................................74 intuitive Testfallermittlung ........................64, 69 ISO 9126........................................................38 ........................ Analysierbarkeit ................................ .........................................83 nderbarkeit ................................ ..............................................83 Portabilittstest ................................ ..........................................84 Klassifikationsbaumverfahren .................64, 66 Koexistenz .....................................................84 ..................... Kommunikationsaspekte ...............................62 Kommunizieren ................................ ............................................119 komplexe Systeme ................................ ........................................33 Konformitt ....................................................32 .................... Kontrollflussanalyse ................................ .......................................64 LCSAJ............................................................64 ............................ LCSAJ (Schleifentest) ................................ 67 ................................... Lebenszyklus agile Methoden ................................ 29, 30 .................................... evolutionre Methoden ..............................30 evolutionres Modell ................................ 29 ................................. iterativ ........................................................29 ........................ RAD .....................................................29, 30 ..................... Rapid Application Development ..........29, 30 V-Modell ....................................................29 .................... Wasserfall..................................................29 .................. Leiter einer Inspektion ................................ 86 ................................... Lernziele Technical Test Analysts ............................25 Test Analysts ................................ .............................................21 Testmanager ................................ .............................................14 Management-Review................................ 86 ..................................... Mastertestkonzept ................................ 44, 46 ................................... Mean Time Between Failures ........................80 Mean Time to Repair ................................ 80 ..................................... Version 2007
Mehrfachbedingungsberdeckungstest ........ 67 berdeckungstest metrics external (ISO 9126) ................................ 95 .................................. internal (ISO 9126) ................................ 95 ................................... quality ....................................................... 95 ....................... Metriken Abweichungen ................................ .......................................... 93 STEP ...................................................... 103 ...................... TPI .......................................................... 102 .......................... Metriken und Abweichungsmanagement Abweichungsmanagement...... 93 Metriken und Messung................................ 33 .................................. Moderator ...................................................... 86 ...................... Motivieren ................................................... 118 ................... MTBF ............................................................ 80 ............................ MTTR ............................................................ 80 ............................ Multisysteme ................................ ..................................... 31, 33, 60 Management und Testen.......................... 31 .......................... Merkmale ................................ .................................................. 32 Normen und Standards ................................ 94 ................................. organisatorische Aspekte ............................. 62 orthogonale Arrays ................................ ........................................ 66 Outsourcing ................................ ................................................... 51 paarweises Testen ................................ ........................................ 66 Pfadberdeckungstest ................................ 68 .................................. Phasentestplan ................................ ............................................. 44 Portabilittstest ................................ ............................................. 74 Produktintegrationstest beim Kunden ........... 30 Produktrisiko ................................ ................................................. 44 Projektrisiko ................................ .................................................. 44 Projekttestkonzept ................................ ........................................ 44 Prozessverbesserung Einfhrung ................................ ................................................ 98 mit TMM .................................................. 100 .................. Modelltypen ................................ .............................................. 99 Prfer ............................................................ 86 ............................ Prfungsinstitutionen ................................ 125 .................................. Prfungskandidaten ................................ 125 .................................... Qualittsmerkmale bei fachlichen Tests ................................ 74 .................................. Qualittsmerkmale bei technischen Tests .... 78 redundante Systeme ................................ ..................................... 81 Referenzen ................................ ................................................. 120 Literatur................................................... 121 ................... sonstige .................................................. 123 .................. Standards ................................ ............................................... 120 Reliablity Growth Model ................................ 80 Reviews ........................................................ 86 ........................ Arten ......................................................... 87 ......................... Audit.......................................................... 87 .......................... Einfhrung ................................ ................................................ 88 Januar 2010 20100131
Seite 133 von 136
Erfolgsfaktoren ................................ ..........................................89 formale Reviews ................................ ........................................88 Grundstze ................................................86 ................ Management-Review ................................87 technische .................................................86 ................. von bestimmten Arbeitsergebnissen .........88 Risikoanalyse ..........................................44, 54 .......... Risikobeherrschung ................................ .......................................55 Risikobeherrschung bzw. -steuerung ............44 steuerung Risikoidentifikation ................................ .........................................53 Risikoidentifizierung ................................ .......................................44 Risikomanagement ................................ 44, 53 .................................. Risikomanagement im Lebenszyklus ............57 risikoorientierter Test ................................ 44 ..................................... Risikoorientiertes Testen ...............................52 Risikostufe .....................................................44 ..................... Risikotyp ........................................................44 ........................ SBTM .......................................................39, 59 ....................... SCCFA...........................................................97 ........................... schlsselwortgetriebener Test .....................105 Section 508 ....................................................77 .................... Session Sheet ...............................................59 ............... session-based Testmanagement ..................44 SFMEA ..........................................................33 .......................... SFMECA ........................................................97 ........................ SFTA..............................................................97 .............................. Sicherheit der Daten ................................ ......................................62 sicherheitskritische Systeme .........................32 Komplexitt................................................33 ................ Konformitt ................................................60 ................ Sicherheitstest ...............................................74 ............... soziale Kompetenz ................................ ......................................116 Speicherengpass ................................ ...........................................64 spezifikationsorientierteTestverfahren ...........64 spezifische Systeme ................................ ......................................31 SQR ...............................................................98 ............................... SRET .............................................................80 ............................. Stabilitt .........................................................83 ......................... Standards allgemeine Aspekte ................................ 95 ................................... alphabetisch ................................ ............................................120 Avionik .......................................................96 ....................... branchenspezifische ................................ 96 ................................. BS 7925...............................................35, 64 ............... BS-7925-2 ..................................... .....41, 77, 96 CMM ..........................................................94 .......................... CMMI .........................................................94 ......................... CTP ...........................................................98 ........................... DO-178B .............................................39, 96 ............. ECSS .........................................................97 ......................... Version 2007
ED-12B ............................................... 39, 96 ............... FAA DO-178B/ED-12B ............................. 56 IEC 61508 ................................ ................................................. 56 IEEE.......................................................... 96 .......................... IEEE 1028................................ ........................................... 86, 96 IEEE 1044................................ ..................................... 91, 92, 96 IEEE 610................................ ................................................... 96 IEEE 829........................... 35, 38, 40, 91, 96 im Testverbesserungs-Prozess ................ 94 Prozess Internationale ................................ ............................................ 95 ISO ............................................................ 95 ............................ ISO 12207................................ ................................................. 95 ISO 15504................................ ................................................. 96 ISO 9126................................ ................................................... 83 Konsistenz und Konflikte .......................... 95 nach Kapiteln ................................ .......................................... 120 nationale ................................ ................................................... 96 Ntzlichkeit ................................ ............................................... 95 Quellen ..................................................... 95 ..................... Raumfahrt ................................ ................................................. 97 sonstige .................................................... 97 .................... STEP ........................................................ 98 ........................ TMM.......................................................... 94 .......................... TMMi ................................................... 94, 98 ................... TPI ...................................................... 94, 98 ...................... UML .......................................................... 77 .......................... statische Analyse Aufrufgraphen ................................ ........................................... 72 Datenflussanalyse ................................ 71 .................................... der Softwarearchitektur ............................ 71 des Programmcodes ................................ 71 einer Webseite ................................ .......................................... 71 Erzeugung von Codemetriken .................. 71 Konformitt mit Programmierkonventionen ............................................................. 71 ............................. Kontrollflussanalyse ................................ 71 .................................. STEP ............................................... 98, 99, 103 ............... strukturorientierte Testverfahren ................... 66 Stufentestkonzept ................................ 44, 47 ................................... SUMI ............................................................. 77 ............................. SUMI (Software Usability Measurement y Inventory) ................................ .................................................. 74 Systemintegrationstest................................ 30 .................................. Systemtest .................................................... 78 .................... Taxonomien ................................ .................................................. 69 Teamzusammensetzung ............................ 116 Test auf Richtigkeit ................................ ....................................... 74 Test der Softwareeigenschaften ................... 74 Analysierbarkeit ................................ ........................................ 83 Angemessenheit ................................ ....................................... 75 Januar 2010 20100131
Seite 134 von 136
Anpassbarkeitstest ................................ 85 .................................... Austauschbarkeitstest ...............................85 Benutzbarkeitstest ................................ 75 ..................................... Benutzbarkeitstests spezifizieren ..............76 dynamischer Wartbarkeitstest ...................83 Effizienztest ...............................................81 ............... funktionaler Sicherheitstest .......................75 Installierbarkeitstest ................................ 84 .................................. Interoperabilittstest ................................ 75 .................................. Koexistenz .................................................84 ................. korrektive Wartung ................................ 83 .................................... Lasttest ......................................................82 ...................... Performanztest ................................ ..........................................82 Portabilittstest ................................ ..........................................84 Ressourcennutzung ................................ 82 .................................. Robustheitstest................................ ..........................................80 Sicherheitstestspezifikation .......................79 Skalierbarkeitstest ................................ 82 ..................................... Stresstest ..................................................82 .................. technischer Sicherheitstest .......................78 Test auf Richtigkeit ................................ 75 .................................... Wartbarkeitstest ................................ ........................................83 Wiederherstellbarkeitstest .........................80 Zugnglichkeitstest ................................ 77 ................................... Zuverlssigkeitstest ................................ 80 ................................... Test Maturity Model ................................ .......................................94 Test Maturity Model Integrated ......................94 Test Process Improvement............................94 ............................ Testaktivitten abschlieen .....................42, 49 Testausfhrungswerkzeug Mitschnitt-Werkzeug ................................111 Testausfhrungs-Werkzeug Capture/Replay ................................ .......................................111 Testautomatisierung schlsselwortgetriebene ..........................114 Testbarkeit .....................................................83 ..................... Testbedingungen ................................ ...........................................35 Testbedingungen identifizieren .....................37 Testbericht .....................................................35 ..................... Test-Charta ..............................................59, 64 .............. Testdurchfhrung ................................ ..........................................35 Testen im Softwarelebenszyklus ...................29 Testen in der Organisationsstruktur etablieren.................................................117 ................. Testendekriterien ................................ ...........................................35 Testendekriterien auswerten, Berichte ..........41 tendekriterien Testentwurf ....................................................35 .................... Testfall ...........................................................35 ........................... Testkonzepte Dokumentvorlagen ................................ 47 .................................... Version 2007
Geschftswert ................................ ........................................... 51 risikoorientiertes Testen ........................... 52 Testfortschrittsberwachung und -steuerung ............................................................. 49 ............................. Testschtzung ................................ .......................................... 47 Verteiltes Testen, Outsourcing und Insourcing ................................ ............................................. 51 zeitliche Testplanung ................................ 49 Testmanagement ................................ .......................................... 44 bei ............................................................. 60 ............................. bei Multisystemen ................................ ..................................... 60 beim .......................................................... 59 .......................... Besonderheiten ................................ ........................................ 59 Dokumentation ................................ ......................................... 44 Mastertestkonzept ................................ 46 .................................... session-based ................................ .......................................... 59 sonstige Besonderheiten .......................... 61 Stufentestkonzept ................................ ..................................... 47 Testrichtlinie ................................ ............................................. 44 Teststrategie ................................ ............................................. 45 Testmanagementwerkzeuge ...................... 110 Testorakel ................................................... 105 ................... Testorakel ................................................... 108 ................... Testorakel ................................................... 108 ................... Testplanung ................................ .................................................. 35 Testprotokoll ................................ ................................................. 35 Testprozess Analyse und -entwurf ................................ 36 Modelle ..................................................... 35 ..................... Planung und -steuerung ........................... 36 Testdurchfhrung ................................ ..................................... 39 Testrealisierung ................................ ........................................ 38 Testprozess verbessern................................ 99 ................................ Capability Maturity Model Integra Integration ..... 103 mit CTP ................................................... 102 ................... mit STEP................................ ................................................. 103 mit TPI .................................................... 101 .................... Testprozesse ................................ ................................................ 35 Testpunktanalyse (TPA) ............................... 44 Testrealisierung ................................ ............................................ 35 Testrealisierung und Testdurchfhrung ........ 38 Testrichtlinie ................................ .................................................. 44 Testrichtlinie ................................ .................................................. 44 Testschtzmethode................................ ....................................... 44 Testschtzung ................................ ............................................... 47 Testskript ...................................................... 35 ...................... Teststeuerung ................................ ......................................... 35, 44 Teststrategie ................................ ................................................. 45 Teststufe ....................................................... 44 ....................... Testszenario ................................ ................................................. 35 Januar 2010 20100131
Seite 135 von 136
Testberwachung ................................ ..........................................44 Testverbesserungs-Prozess ..........................98 Testverfahren (einfacher) Bedingungsberdeckungstest 64 anforderungsbasierter Test .......................64 Anweisungsberdeckungstest ..................64 anwendungsfallbasierter Test ...................64 dynamische Analyse ................................ 64 ................................. Entscheidungstabellentest ........................64 Entscheidungs-berdeckungstest ............64 berdeckungstest erfahrungsbasierte ..............................64, 68 exploratives Testen ................................ 64 ................................... fehlerbasierte................................ .......................................64, 68 Grenzwertanalyse ................................ 64 ..................................... Mehrfachbedingungs-berdeckungstest ..64 berdeckungstest Pfadberdeckungstest ..............................64 spezifikationsorientiert ...............................64 statische Analyse ................................64, 70 strukturbasierte................................ ..........................................64 zustandsbasierter Test ..............................64 Zweigtest ...................................................64 ................... Testverfahren ................................................64 ................ Testvorgehen .................................................35 ................. Testvorgehensweise ................................ ......................................44 Testvorgehensweise ................................ ......................................45 Testwerkzeug Analysewerkzeug ................................ 113 .................................... Automatisierungssprachen......................108 Debugging ...............................................112 ............... Emulator ..................................................113 .................. Fehleranalysewerkzeug ..........................112 Fehlereinpflanzung ................................ 112 .................................. Fehlerinjektion ................................ .........................................112 Hyperlink-Testwerkzeug ..........................115 Inbetriebnahme ................................ .......................................108 Integration und Informationsaustausch ...107 klassifizieren ................................ ............................................110 Konzepte .................................................105 ................. Mutationstest ................................ ...........................................112 Open Source ................................ ...........................................109 Performanztest ................................ ........................................114 selbst entwickeln ................................ 109 ..................................... Simulator .................................................113 ................. Skripte, Skriptsprache .............................108 Strategien ................................................107 ................ Testausfhrungswerkzeug ......................111 Testautomatisierung ................................114
.................................... Testmanagement................................ 110 Testwerkzeuge Kosten, Nutzen, Risiken ......................... 106 Testwerkzeuge und Automatisierung ......... 105 TIM ................................................................ 98 ................................ TMM ...................................................... 98, 100 ...................... TMMI ............................................................. 99 ............................. TOM .............................................................. 98 .............................. TPI................................................... 98, 99, 101 ................... Ursache-Wirkungs-Graph ............................. 65 verteiltes Testen................................ ............................................ 51 Walkthrough ................................ .................................................. 86 WAMMI ......................................................... 77 ......................... Wartbarkeitstest ................................ ............................................ 74 adaptive Wartung ................................ ..................................... 83 Analysierbarkeit ................................ ........................................ 83 nderbarkeit ................................ ............................................. 83 dynamisch................................ ................................................. 83 korrektive Wartung ................................ 83 ................................... Stabilitt .................................................... 83 .................... Testbarkeit ................................ ................................................ 83 Werkzeug Debuggingwerkzeug ............................... 105 dynamisches Analysewerkzeug ............. 105 Emulator ................................ ................................................. 105 Fehlereinpflanzungswerkzeug ................ 105 werkzeug Hyperlink-Werkzeug ............................... 105 Lasttestwerkzeug ................................ 105 .................................... Simulator................................ ................................................. 105 statischer Analysator .............................. 105 Testausfhrungswerkzeug ..................... 105 Testmanagementwerkzeug .................... 105 Wideband Delphi................................ ........................................... 44 Wiederherstellbarkeitstest ............................ 74 Backup- und Wiederherstellungstest ........ 80 Failover Test ................................ ............................................. 80 wilder Zeiger ................................ ................................................. 64 zeitliche Testplanung .............................. 44, 49 Ziele fr die Advanced Level Zertifizierung und Qualifizierung ................................ 124 ................................... Zugnglichkeitstest ................................ ....................................... 74 Zulassungsanforderungen .......................... 124 zustandsbasiertes Testen ............................. 65 Zuverlssigkeitstest ................................ ...................................... 74 Zuverlssigkeitstest-Spezifikation................. 81 Spezifikation Zuverlssigkeitswachstumsmodell ............... 74 Zweigberdeckungstest ................................ 67
Version 2007
Seite 136 von 136
Januar 2010 20100131

Istqb Ctal Lehrplan v2007

Hochgeladen von

Dokumentinformationen

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Istqb Ctal Lehrplan v2007

Hochgeladen von

Copyright:

Verfügbare Formate

CERTIFIED TESTER Advanced Level Syllabus

International Software Testing Qualifications Board

German Testing Board e.V.

Certified Tester Advanced Level Syllabus (Deutschsprachige Ausgabe)

Seite 2 von 136

Januar 2010 20100131

International Software Testing Qualifications Board

Certified Tester Advanced Level Syllabus (Deutschsprachige Ausgabe)

nderungsbersicht der deutschsprachigen Ausgabe

Seite 3 von 136

Januar 2010 20100131

International Software Testing Qualifications Board

Certified Tester Advanced Level Syllabus (Deutschsprachige Ausgabe)

Certified Tester Advanced Level Syllabus (Deutschsprachige Ausgabe)

Certified Tester Advanced Level Syllabus (Deutschsprachige Ausgabe)

Certified Tester Advanced Level Syllabus (Deutschsprachige Ausgabe)

Seite 7 von 136

Januar 2010 20100131

International Software Testing Qualifications Board

Certified Tester Advanced Level Syllabus (Deutschsprachige Ausgabe)

Seite 8 von 136

Januar 2010 20100131

International Software Testing Qualifications Board

Certified Tester Advanced Level Syllabus (Deutschsprachige Ausgabe)

0. Einfhrung in den Lehrplan

Zweck dieses Dokuments

Certified Tester Advanced Level im Bereich Softwaretesten

Seite 9 von 136

Januar 2010 20100131

International Software Testing Qualifications Board

Certified Tester Advanced Level Syllabus (Deutschsprachige Ausgabe)

Seite 10 von 136

Januar 2010 20100131

International Software Testing Qualifications Board

Certified Tester Advanced Level Syllabus (Deutschsprachige Ausgabe)

Aufbau des Lehrplans

Begriffe und Definitionen

0.2.1 Testmanager Advanced Level

Seite 11 von 136

Januar 2010 20100131

International Software Testing Qualifications Board

Certified Tester Advanced Level Syllabus (Deutschsprachige Ausgabe)

getroffene Entscheidungen begrnden und, gegebenenfalls, geeignete Berichtsunterlagen , erstellen knnen.

0.2.2 Test Analyst Advanced Level

0.2.3 Technical Test Analyst Advanced Level

Seite 12 von 136

Januar 2010 20100131

International Software Testing Qualifications Board

Certified Tester Advanced Level Syllabus (Deutschsprachige Ausgabe)

0.3 Lernziele/Kognitive Ebenen des Wissens

Seite 13 von 136

Januar 2010 20100131

International Software Testing Qualifications Board

Certified Tester Advanced Level Syllabus (Deutschsprachige Ausgabe)

0.4 Lernziele fr Testmanager

Certified Tester Advanced Level Syllabus (Deutschsprachige Ausgabe)

LO-2.5.3 (K2) LO-2.5.4 (K2)

Seite 15 von 136

Januar 2010 20100131

International Software Testing Qualifications Board

Certified Tester Advanced Level Syllabus (Deutschsprachige Ausgabe)

Seite 16 von 136

Januar 2010 20100131

International Software Testing Qualifications Board