i i i i - erni-consultants.com

TesTmanagemenT 1 

eRnI essenTIaLs 

TEST MANAGEMENT

enables & delivers 

maRCeL sTOOP 

marcel.stoop@erni.ch 

senior Consultant and 

Certified Testmanager 

bei eRnI schweiz ag 

vorworT 

Software gehört zu den komplexesten 

menschlichen Erzeugnissen. Durch 

die Vernetzung der Systeme wird ihre 

Komplexität weiter zunehmen. Dessen 

ungeachtet erhält das Testen in vielen Entwicklungsabteilungen 

einen untergeordneten 

Status, obwohl es vielfältige Gründe 

gibt, Software intensiv und systematisch 

zu testen. 

Ein zentraler Punkt des Testens ist die 

Überprüfung des tatsächlichen Verhaltens 

der Software gegenüber den definierten 

Anforderungen. Des Weiteren senkt das 

Testen das Risiko hoher Folgekosten. Denn 

je früher Fehler gefunden werden, desto 

billiger ist ihre Behebung. Das Testen ist 

in einem ersten Schritt die Beseitigung 

von Fehlern. Nutzt man die sich daraus 

ergebenden Möglichkeiten, ist das Testen 

ein mächtiges Controllinginstrument, das 

eine nachvollziehbare Qualitätskontrolle 

für den gesamten Entwicklungsprozess 

liefert. Meine Erfahrungen zeigen: Hochwertige 

Software lässt sich heute nur noch 

durch einen verzahnten Entwicklungsund 

Testprozess herstellen. 

eRnI – Innovation in Process and Technology 


1. vorworT 2 

2. EiNlEiTuNG 5 

3. SofTwArETESTS 7 

4. DiE ZEhN-PuNkTE-ChECkliSTE 11 

5. TESTPlANuNG 15 

6. v-MoDEll 19 

7. METhoDiSChE TESTfAllErSTElluNG 23 

8. koMbiNAToriSChE ExPloSioNEN vErMEiDEN! 27 

9. TESTfAllkATAloG 31 

10. TESTAuToMATiSiEruNG 37 

11. TESTProZESS 41 

12. ProfESSioNEllE TESTEr 45 

12.1 Testmanager 45 

12.2 Testarchitekt 47 

12.3 Testdesigner 48 

12.4 Testautomatisierer 49 

12.5 Tester 50 

13. DokuMENTvorlAGEN 53 

13.1 Testplan 53 

13.2 Testfallspezifikation 54 

13.3 Testbericht 55 

14. TESTwErkZEuGE 57 

15. wEiTErführENDE iNforMATioNEN 59 

15.1 Literatur 59 

15.2 normen und standards 61 

15.3 Weblinks 61

2. EiNlEiTuNG 


Software zu testen, ist extrem aufwändig und schwierig. 

Weshalb? 

• Wer das erste Mal versucht, Software systematisch zu testen, 

kapituliert vor den astronomisch vielen Testfällen. Sie ergeben 

sich aufgrund der kombinatorischen Explosion von Eingangsdaten 

und internen Softwarezuständen. 

• Oft bleibt für das Testen keine Zeit mehr, da die Entwicklung 

länger dauert als geplant und der Ausliefertermin drängt. 

• Testen wird als überflüssige und unattraktive Arbeit angesehen. 

• Das Testen von Software ist eine junge Disziplin des Software 

Engineerings, die die Hochschulen lange vernachlässigten. 

• Vielerorts versteht das Management das Testen ausschliesslich 

als Kostenfaktor, obwohl es ein wertschöpfender und 

qualitätssteigernder Teil der Produktionskette und des Controllingprozesses 

ist. 

Ungenügend qualifizierte Tester, der Drang, alles vollständig testen 

zu wollen, und die engen Rahmenbedingungen in Projekten 

führen dazu, dass software ungenügend getestet wird.


3. SofTwArETESTS: 

GESETZE, rEGElN uND PriNZiPiEN 

Vor dem Testbeginn hilft es, sich die folgenden Erfahrungswerte 

in Erinnerung zu rufen: 

• Die Testkosten machen 40 bis 60 Prozent des gesamten 

Projektaufwandes aus (Harry M. Sneed, Stefan Jungmayr: «Produkt- 

und Prozessmetriken für Softwaretest», in Informatik-Spektrum, 

Springer-Verlag, Bd. 29, Heft 1, Feb. 2006, S. 23–38). Je höher 

die geforderte Qualität, desto höher ist der Testaufwand. 

• Vor systematischen Tests enthält jede Software auf 1000 

Zeilen Code durchschnittlich 10 bis 30 Fehler (Umfrage 

unter Softwareentwicklern). 

• Die geforderte Qualität der Software bewegt sich je nach 

Anwendungsfeld zwischen 0,5 und 1,0 Fehlern pro 1000 

Programmzeilen. 

• Pro 1000 Zeilen zu testenden Code müssen die Tests 9,0 

bis 29,5 Fehler aufdecken. 

• Der Aufwand, um in gut getesteter Software weitere Fehler 

zu finden, steigt stark an. 

• Die Fehlerdichte in Softwaremodulen variiert stark. 

Im Durchschnitt enthalten 30 Prozent der Softwaremodule 

eines Systems 70 Prozent der Fehler. 

• Es ist kostengünstiger, Fehler in einem frühen Entwicklungsschritt 

zu beheben als in einem späten.

Fehlleistungskosten sind der bestimmende Faktor in den F&E- 

Kosten! Fehlerkosten wachsen exponentiell in der Zeitspanne 

zwischen ihrer Entstehung und ihrer Entdeckung beziehungsweise 

Behebung. 

Folgende Erfahrungswerte verdeutlichen diesen Zusammenhang: 

anforderungsspez. 

analyse/ 

Design 

Implementierung 

1 1 1 6 12 20 

= relative Fehlerkosten 

Intergrationstest 

systemtest 

Feld 

• Effektives Testen beginnt nicht erst am Schluss, sondern 

bereits mit der Erstellung und dem Review der Anforderungen. 

Im frühen Glied der Produktionskette sind die Fehlerbeseitigungskosten 

am geringsten, und der Nutzen ist am 

höchsten. Alle nachfolgenden Produktionsschritte profitieren 

von der höheren Anforderungsqualität. 

• Es gibt kein «bestes» Testverfahren. Am effektivsten ist eine 

Mischung aus Reviews, Entwicklertests und Tests durch eine 

unabhängige Testgruppe. 


ein kleines, spezialisiertes Testteam, das die Rollen Testmanager, 

Testdesigner und Tester professionell abdeckt, ist effizienter und 

effektiver als grosse ad-hoc-Testteams.


4. DiE ZEhN-PuNkTE-ChECkliSTE 

Folgende Checkliste unterstützt Testmanager, die ein Projekt 

ohne expliziten Testprozess übernehmen. Sie hilft, in kurzer Zeit 

objektiv messbare Fortschritte zu erzielen. 

1. Verschaffe dir einen Überblick über das zu testende System. 

Organisiere dir ein grosses Systemübersichtsbild. 

2. Bring beim wichtigsten Stakeholder das Businessziel für die 

Tests in Erfahrung. 

3. Wo sind die Anforderungen und Spezifikationen? 

Eine grobe, durchnummerierte Liste von zu testenden 

Punkten genügt (siehe Kapitel 9, Testfallkatalog). 

4. Priorisiere die Spezifikationspunkte, die Businessabläufe, 

die Datenübernahmen und die Systemteile gemäss einem 

nachvollziehbaren Raster (siehe Kapitel 9, Testfallkatalog). 

5. Definiere Teststufen (siehe Kapitel 6, V-Modell) und ordne 

jeder Stufe ein zuständiges Testteam zu. 

6. Erstelle die Testplanung. 

7. Sorge dafür, dass jedes Team mindestens ein Mitglied hat, 

das sich zu 100 Prozent den Tests widmet. Coache dieses 

Mitglied zum Erfolg. Zeig beispielsweise, wie man zielgerichtet 

und effizient Testfälle und Testdaten aus den 

Anforderungen ableitet. 

8. Miss die Testergebnisse. Visualisiere sie als Trend-Charts und 

mach sie regelmässig allen bekannt. Damit wird das Testen 

von allen als wirksamer Controllingprozess verstanden.

9. Sorge für einen angepassten Informationsaustausch. 

Bewährt haben sich tägliche Stand-up-Meetings mit den 

Testteams sowie moderierte wöchentliche Testkoordinationsmeetings 

mit dem Gesamtprojektleiter und allen Testteamleitern. 

10. Stimme dich als Testmanager mit dem Projektleiter in 

puncto Planung ab und hilf im Change Control Board mit, 

damit Changes priorisiert werden und in die Planung einfliessen. 

TesTmanagemenT 13


5. TESTPlANuNG: TESTS 

iTErATiv-iNkrEMENTEll PlANEN 

anforderungsspez. 

entwicklung 

Testdesign 

Testdurchführung 

Iterationsnummer 

BesT PRaCTICe 

Inkr. 1 

n – 2 

Inkr. 2 Inkr. 3 

Inkr. 1 Inkr. 2 Inkr. 3 

Inkr. 1 

n – 1 

Inkr. 2 Inkr. 3 

Inkr. 1 

Tests werden parallel zu anderen Disziplinen durchgeführt, 

nicht danach. Dazu eignet sich besonders das iterativ-inkrementelle 

Vorgehen. In jeder Iteration werden Tests für ein weiteres 

Inkrement vorbereitet respektive durchgeführt: 

• Erarbeitung der Tests nach der Erstellung eines Anforderungspakets. 

• Durchführung der Tests unmittelbar nach der Umsetzung 

der Anforderungen in der Software. 

RegeLn 

Beim iterativ-inkrementellen Vorgehen laufen Anforderungsdefinition, 

Entwicklung, Testdesign und Testdurchführung parallel 

ab. 

n 

Inkr. 2 

n + 1 

Inkr. 3 

n + 2

In jeder Iteration (n) … 

• erstellt das Anforderungsteam die Anforderungen für das 

nächste Inkrement (n + 1). 

• erstellt das Entwicklungsteam die Software für das aktuelle 

Inkrement (n). Das Testdesignteam erstellt die Testfälle dazu. 

• führt das Testteam die Testfälle für das vorhergehende Inkre- 

ment durch und meldet die Fehler. 

eRFOLgsFakTORen 

• Analysiere die Liste der funktionalen und nichtfunktionalen 

Anforderungen. 

• Gewinne eine Übersicht über die Architektur und die Abhän- 

gigkeiten der Komponenten. 

• Priorisiere die Anforderungen und die Komponenten 

(risikobasiert) aus Testsicht (siehe Kapitel 9, Testfallkatalog). 

• Definiere den Umfang der Inkremente so, dass jedes für sich 

getestet werden kann. 

nUTzen 

• Iteratives Testen schafft frühzeitig Vertrauen in die Qualität 

des Systems. 

• Laufende objektive Beurteilung des Projektfortschritts und 

der Softwarequalität. 

• Frühe Fehlererkennung führt zu Kosteneinsparungen. 

• Verhinderung eines Teststaus. Erfahrungsgemäss fehlt für 

dessen Abarbeitung am Ende des Projekts die Zeit. 

TesTmanagemenT 17


6. v-MoDEll: iN wElChEr rEihENfol- 

GE DiE TESTSTufEN DurChlAufEN 

wErDEN 

entwicklung 

systemanforderung/ 

-spezifikation 

architektur 

(Komponente/Subsystem) 

BesT PRaCTICe 

Unit/modul 

Code/Implementierung 

• Auf jeder Stufe des V-Modells sind Tests notwendig. Die 

Erstellung der Testfälle beginnt top-down, sobald die Anfor- 

derungen resp. die Spezifikationen vorhanden sind. Die 

Testerstellung beginnt mit den Systemtests. Danach folgen 

Integrationstests und zuletzt die Unit-Tests. 

Tests 

systemtest 

Integrationstest 

Unit-Test 

• Die Durchführung der Tests hingegen erfolgt bottom-up. 

Ist eine Unit/Komponente fertiggestellt, beginnen umge- 

hend die Unit-Tests. Danach folgen Integrations- und Systemtests. 

RegeLn 

• Planung und Erstellung der Testfälle erfolgen top-down,

das heisst, man entwirft zuerst die Systemtests. 

• Die Durchführung der Testfälle erfolgt bottom-up und 

beginnt mit den Unit-Tests. 

eRFOLgsFakTOR 

• Definiere Übergabekriterien zwischen den Teststufen. 

In der Regel definiert man einen Satz von Testfällen, die 

fehlerlos ablaufen müssen, bevor das Testobjekt an die 

nächste Teststufe übergeben wird. Diese Testfälle heissen im 

Fachjargon Smoke Tests, Basic Sanity Tests, Basic Operation 

Tests oder Quick Tests. 

nUTzen 

• Mit der Testfallerstellung auf Systemebene kann früh im 

Projekt begonnen werden. Dies stellt sicher, dass in der zeitkritischen 

Schlusstestphase alle durchzuführenden Tests 

fertig dokumentiert vorliegen. 

• Durch die Regelung der Übergabekriterien erhöht sich die 

Zuverlässigkeit der späteren Teststufen. Dadurch läuft das 

Testobjekt stabil, und die Mehrzahl der Tests liefert aussagekräftige 

Ergebnisse. 

TesTmanagemenT 21


7. METhoDiSChE TESTfAllErSTElluNG: 

wiE MAN AuS ANforDEruNGEN 

TESTfällE AblEiTET 

BesT PRaCTICe 

Leite für jede funktionale (Use Case) und jede nichtfunktionale 

Anforderung (NFA) einen oder mehrere Testfälle ab. 

• Leite für jeden Use Case (UC) 1 bis n Test Cases (TC) ab: 

1 UC -> n TCs 

• Leite für jede nichtfunktionale Anforderung 1 bis n Test 

Cases ab: 1 NFA -> n TCs 

RegeLn 

Funktionale anforderung 

(Use Case) 

1...n 

3 

Testfall (Test Case) 

Regeln zur Ableitung von Testfällen für funktionale Anforderungen: 

• Formuliere für jede funktionale Anforderung mindestens 

einen Testfall, der den Normalfall überprüft. 

 

nichtfunktionale anforderung 

(NFA) 

1...n 

Durchsatz, Reaktionszeit,Verfügbarkeit, 

sicherheit etc.

• Je nach Komplexität sind weitere Testfälle notwendig, 

um das korrekte Verhalten für alternative Abläufe zu 

überprüfen. 

Regeln zur Ableitung von Testfällen für nichtfunktionale 

Anforderungen: 

• Formuliere für jede nichtfunktionale Anforderung mindestens 

einen Testfall, der die Einhaltung der geforderten 

Leistungs- oder Qualitätsangaben garantiert. 

• Je nach Komplexität sind weitere Testfälle notwendig, um 

das korrekte Verhalten unter verschiedenen Bedingungen zu 

überprüfen (Datenvolumen, Zugriffsrate, Umgebungsbedingungen, 

Konfiguration). 


Bessere Schätzwerte erhält man, wenn für eine repräsentative 

Gruppe von Anforderungen je nach Komplexität exemplarisch 

die Anzahl Testfälle bestimmt wird. 

Beispielsweise so: 

• 1 Testfall für nichtkomplexe Anforderungen, 

• 3–5 Testfälle für mittelkomplexe und 

• 10–20 Testfälle für sehr komplexe Anforderungen. 

nUTzen 

• Einheitliches Vorgehen für alle Arten von Anforderungen. 

• Aus der Liste der funktionalen und nichtfunktionalen 

Anforderungen lassen sich der grobe Testumfang und 

der Aufwand leicht abschätzen. 

TesTmanagemenT 25


8. koMbiNAToriSChE ExPloSioNEN 

vErMEiDEN! wiE viElE TESTfällE 

Pro uSE CASE NöTiG SiND 

1. karte einschieben ungültig 

2. PIn-Code eingeben 

3. Betrag eingeben 

anzahl Testfälle 

BesT PRaCTICe 

falsche PIn 

Ist es notwendig, für jede denkbare Kombination von Alternati- 

ven einen Testfall zu definieren? Nein, denn in der Praxis schliessen 

sich Alternativen häufig aus. Im dargestellten Beispiel eines 

Bancomaten schliessen sich «abgelaufene Karte» und «falscher 

PIN-Code» aus, weil eine abgelaufene Karte entweder eingezogen 

oder zurückgewiesen wird. Es gibt nur 9 mögliche Testfälle 

und nicht 24. 

RegeLn 

• Erste Priorität: Teste den Normalablauf. 

• Zweite Priorität: Teste die alternativen Abläufe. 

… 

gesperrt 

4 + 2 + 3 = 9 4 x 2 x 3 = 24 

abgelaufen

• Dritte Priorität: Teste die in der Praxis möglichen Kombinati- 

onen von alternativen Abläufen. 


• Teste zuerst den Normalablauf der Use Cases und stelle 

sicher, dass keine «show-stopper» auftreten. 

• Teste danach die alternativen Abläufe und ihre möglichen 

Kombinationen durch. 

nUTzen 

• Mit dieser Regel ist die Anzahl Testfälle nur proportional und 

nicht exponentiell zur Anzahl alternativer Abläufe. 

TesTmanagemenT 29


9. TESTfAllkATAloG: wiE TESTS 

riSikobASiErT PrioriSiErT wErDEN 

BesT PRaCTICe 

Businessrelevanz 

(B) 

komplexität 

(K) 

nichtentdeckbarkeit 

(N) 

zu testender Punkt 1–5 1–5 1–5 1–125 

kundenanforderungen 

• Vertrag erstellen 5 4 2 40 

• Prämie verbuchen 5 2 4 40 

• Schaden eröffnen 5 3 4 60 

schnittstellen 

• FTP 2 3 2 12 

• Webservice 5 5 5 125 

Potenzielle Fehlerquellen 

• Verwechslung des 

kunden 

5 4 5 100 

Es ist aus Qualitätssicht sinnvoll, die Testintensität nach dem 

Risiko eines fehlerhaften Verhaltens zu richten. 

Risiko 

(R = B x K x N) 

Man sollte intensiv testen, wo ein Fehler grossen Schaden 

anrichten und mit hoher Wahrscheinlichkeit auftreten könnte.

Eine bewährte Formel zur Einschätzung des Risikos lautet: 

R = B x K x N 

Dabei bedeutet 

R = Risiko 

B = Businessrelevanz 

K = Komplexität, d.h. Fehlerwahrscheinlichkeit 

N = Nicht-Entdeckbarkeit eines Fehlers ohne gezielte 

Testvorkehrungen 

RegeLn 

Der Testfallkatalog besteht aus einer gewichteten Liste von zu 

testenden Punkten und legt fest, wie viele Tests nötig sind und 

wie detailliert sie zu spezifizieren sind. 

1. Erstelle eine strukturierte Liste von 

• Kundenanforderungen 

(funktionale sowie Leistungs- und Qualitätsanforderungen) 

• Gesetzen, Vorschriften, Normen 

• technischen Spezifikationen 

(funktionale und nicht funktionale) 

• Schnittstellen 

• Daten 

• potenziellen Fehlerquellen 

• Gefahren aus Sicht Betrieb, Unternehmen (Finanzen) und 

Endanwender 


2. Lass die einzelnen Risikofaktoren von den Vertretern aus 

den verschiedenen Abteilungen bewerten und reviewen: 

• Businessrelevanz aus Sicht Business 

• Komplexität aus Sicht Entwicklung 

• Nicht-Entdeckbarkeit aus Sicht Testmanagement 

3. Sortiere die Listen nach Risiko und definiere, für welche 

Risikohöhe wie viele Tests in welchem Detaillierungsgrad 

zu definieren und durchzuführen sind. Beispielsweise: 

• Hohe Risiken: 10–20 Testfallspezifikationen mit detaillierter 

Beschreibung der einzelnen Testschritte 

• Mittlere Risiken: 3–5 Testfallspezifikationen mit grober 

Beschreibung des Testablaufs 

• Tiefe Risiken: 1 Testfall mit Beschreibung des Testziels 


• Falls kein Testmanagementtool vorhanden ist, genügt eine 

Excel-Liste mit separaten Arbeitsblättern für jede Gruppe. 

• Lass die Liste von verschiedenen Abteilungen reviewen. 

• Lass die Punkte von denjenigen bewerten, die das höchste 

Fach-Know-how haben. 

• Verwalte die Testfälle mit den zugehörigen Testfallspezifikationen 

in Excel oder einem Testmanagementtool (siehe Kapitel 14, 

Testwerkzeuge).

nUTzen 

• Ein Testfallkatalog macht den Umfang der Tests fassbar und 

managebar. 

• Der Begriff «Testabdeckung» ist einheitlich definiert. 100 Pro- 

zent Testabdeckung bedeutet: Alle zu testenden Punkte sind 

getestet. 

• Der Aufwand pro zu testendem Punkt ist transparent, planbar 

und steuerbar. 

• Alle Abteilungen werden berücksichtigt. Sie geben an, welche 

Tests für sie wichtig und sinnvoll sind. 

TesTmanagemenT 35

10. TESTAuToMATiSiEruNG: 

EffiZiENZSTEiGEruNG bEi 

rEGrESSioNSTESTS 

einspeisen von 

autom. Testscripts 

HW 

BesT PRaCTICe 

Die Testautomatisierung … 

(Web-)Client 

server 


«gateway» 

zu Umsystem 

server 

• erhöht die Anzahl durchgeführter Tests pro Iteration/Release 

drastisch. Dies führt zu einer höheren Qualität bei weniger 

Testaufwand. Die Testeffizienz steigt. 

• ist wichtig bei zahlreichen erwarteten Änderungen (Hotfixes, 

Patches oder Releases), die nacheinander in sehr kurzer Zeit zu 

testen sind. 

• kommt vor allem bei Regressionstests zum Einsatz. Diese 

Tests stellen die kontinuierliche Systemstabilität und -funktionalität 

nach Änderungen sicher. 

DB

RegeLn 

Die Testautomatisierung beinhaltet folgende Hauptschritte: 

• Testfallspezifikationen erstellen und die manuelle Durch- 

führung mit einem «capture & replay tool» aufzeichnen, 

das automatisch Testscripts erstellt. 

• Testscripts programmtechnisch mit Eingangsdaten und Konfigurationsangaben 

für verschiedene Testumgebungen ergänzen. 

• Testmetriken generieren: Anzahl durchgeführter Testfälle, 

Anzahl «pass/fail» pro Schweregrad, Empfehlung. 


• Testautomatisierung setzt Programmierkenntnisse voraus 

und muss wie ein Softwareentwicklungsprojekt abgewickelt 

werden. 

• Der Erfolgsfaktor liegt in der kontinuierlichen und wirtschaftlichen 

Pflege der automatisierten Testfälle während der 

ganzen Lebensdauer der zu testenden Software. 

• Die Verwaltung der Testscripts in einem Versionsverwaltungstool 

und die kontinuierliche Anpassung an ändernde 

Anforderungen und Spezifikationen sind eine andauernde 

Tätigkeit. 

nUTzen 

• Automatisierte Tests dienen der Testeffizienzsteigerung und 

garantieren eine einheitliche Qualitätskontrolle. 

• Testautomatisierung erfordert eine grosse Investition in Testwerkzeuge 

und automatisierte Testscripts. Dieser Aufwand 

rechnet sich nur für die risikoreichsten Tests (siehe Kapitel 9, 

Testfallkatalog), die häufig und rasch durchzuführen sind. 

TesTmanagemenT 39


11. TESTProZESS: wiE rollEN, 

PhASEN, TäTiGkEiTEN uND 

DokuMENTE ZuSAMMENwirkEN 

BesT PRaCTICe 

Der Testprozess gliedert sich in vier Phasen, die auf jeder Test- 

stufe dieselben sind: 

• Testplanung 

• Testdesign 

• Testdurchführung 

• Testauswertung 

Zumindest auf der Systemteststufe sind folgende Dokumente 

zu erstellen: 

• Testplan 

• Testfallspezifikation 

• Testprotokoll und Fehlermeldungen 

• Testbericht 

RegeLn 

Die vier Phasen bestehen aus folgenden Tätigkeiten: 

• Testplanung 

Der Testmanager erstellt den Testplan und definiert das Testvorgehen 

(Teststufen, Testziele Automatisierung). 

• Testdesign 

Die Testdesigner entwerfen die Testfallspezifikationen für die 

Anforderungen resp. die identifizierten Testfälle. 

• Testdurchführung 

Die Tester führen die Tests gemäss den Testfallspezifikationen

durch und vergleichen die tatsächlichen Resultate mit den 

im Testfall formulierten erwarteten Resultaten. Sie protokollieren 

die Umstände der Durchführung und die Ergebnisse in 

einem Testprotokoll. Bei Abweichungen verfassen sie eine 

Fehlermeldung. 

• Testauswertung 

Der Testmanager wertet die Testprotokolle und die Fehlermeldungen 

aus und fasst sie in einem Testbericht zusammen. 

Dieser enthält zudem seine Empfehlung für oder gegen eine 

Freigabe des Testobjekts. 


• Besetze die Rollen mit Testspezialisten (siehe Kapitel 12, Professionelle 

Tester). 

• Verfasse für jede Stufe einen Testplan. Diese Pläne können je 

ein separates Dokument sein oder für alle Stufen in einem 

Mastertestplan zusammengefasst werden. 

• Stelle Vorlagen für die Testdokumente zur Verfügung. 

• Definiere, was die Fehlermeldungen enthalten müssen, damit 

die Entwickler den Fehler reproduzieren und seine Ursache 

finden können. 

nUTzen 

Die Einhaltung des Prozesses führt zu vier Hauptvorteilen: 

• Nachvollziehbare Testergebnisse. 

• Die Tests erfolgen gegenüber dem Qualitätsmassstab der Anforderungen 

und nicht intuitiv aufgrund des Wissens von Testern. 

• Entwickler können die Fehler reproduzieren und beheben, 

ohne die Tester zeitlich zu belasten. 


• Abteilungsübergreifende Change-Management-Meetings er- 

möglichen die Beurteilung jedes einzelnen Fehlers. Das Team 

fällt die Entscheidung, den Fehler zu korrigieren oder erneut 

zu testen. 

(Siehe grafische Darstellung «Testprozess» auf der letzten Umschlagseite)


12. ProfESSioNEllE TESTEr: 

SPEZifiSChES ANforDEruNGSProfil 

für jEDE TESTrollE 

Ein professionelles Testteam deckt die Rollen Testmanager, Testdesigner 

und Tester ab. Dieses Kapitel listet die Aufgaben und 

Anforderungen an diese Rollen in Form von Checklisten auf. Die 

Listen helfen, geeignete Kandidaten zu finden und in die Rollen 

einzuweisen. 

12.1 TESTMANAGEr 

Führt, organisiert und entscheidet. 

Der Testmanager leitet das Testteam, ist entscheidungsstark und 

bringt Erfahrung im Testen mit. 

aUFgaBen 

• Passt den Testprozess den Erfordernissen des Projekts an. 

• Plant Testvorbereitung und -durchführung, stimmt den Plan 

mit dem Gesamtprojektleiter und dem Release-Manager ab 

und budgetiert die Testaufwände. 

• Organisiert und leitet das Team von Testdesignern und 

Testern. 

• Koordiniert die Planung mit dem Anforderungsteam und 

stellt sicher, dass die Anforderungen reviewt werden. 

• Beauftragt die Testdesigner mit der Erstellung der Testfälle 

und stellt deren Qualität durch Reviews sicher. 

• Verwaltet die Testfälle in einem Testverwaltungswerkzeug

und stellt ihren Bezug zu den Anforderungen her. 

• Nimmt Teil an Change-Management-Meetings. Beurteilt die 

Auswirkungen von Fehlern, Anforderungsänderungen und 

Softwareanpassungen in Bezug auf den Aufwand, um Testfälle 

neu zu erstellen oder anzupassen und Tests zu wiederholen 

oder neu durchzuführen. 

• Beauftragt die Tester mit der Durchführung von Tests und 

überwacht ihre Arbeit. 

• Organisiert die Testinfrastruktur 

(Testwerkzeuge, Testsysteme, Testaufbau). 

• Weist instabile und ungenügend vorgetestete Software 

zurück. 

• Überwacht und rapportiert Testfortschritt, Qualität und aufgelaufene 

Kosten. 

• Fasst Testergebnisse im Testprotokoll zusammen, interpretiert 

die Resultate und erstellt den Testbericht mit Empfehlung 

für Freigabe oder Nachbessern der Software. 

anFORDeRUngsPROFIL 

• Idealerweise ISTQB/ASQF-Certified Tester Advanced Level 

(Testmanager). 

• Ist entscheidungsstark und verhandlungsgeschickt. 

• Hat Erfahrung als Testdesigner, evtl. als Anforderungsspezialist 

oder als Entwickler. 

• Kommuniziert gut und wird akzeptiert auf Stufe SW-/IT-Entwicklungsleiter, 

Projektleiter, Projektmanagement und 

Qualitätsmanagement. 

12.2 TESTArChiTEkT 


Optimiert die Testkosten für mehrere Produkte. 

Der Testarchitekt berät den Testmanager in fachlicher Hinsicht. 

Er analysiert die Anforderungen, kennt sich mit den Softwarearchitekturen 

der entwickelten Systeme aus und gibt den 

Testdesignern und -automatisierern die fachlichen Vorgaben. 

aUFgaBen 

• Stellt kommerzielle Überlegungen hinsichtlich Testsynergien 

zwischen verschiedenen Produktlinien an. 

• Führt eine Kosten-Nutzen-Analyse für verschiedene Teststrategien 

durch. 

• Definiert den fachtechnischen Teil der Testpläne (Testkonzept). 

• Erstellt auf ökonomischer Basis eine Triage, welche Tests 

inhouse, welche bei Softwarepartnern und welche in spezialisierten 

Testzentren durchgeführt werden. 

• Stellt sicher, dass die Testdesigner bewährte Testpatterns wiederverwenden. 


• Idealerweise ISTQB/ASQF-Certified Tester Advanced Level 

(Testmanager). 

• Denkt analytisch und unternehmerisch. 

• Hat Überblick über die Produktpalette der Firma. 

• Hat Erfahrung als Testdesigner, Anforderungsspezialist und 

Softwarearchitekt. 

• Kommuniziert gut und wird akzeptiert von Softwarearchitekt, 

Leiter der Anforderungsspezialisten, dem SW-/IT-Entwicklungsleiter 

und dem Management.

12.3 TESTDESiGNEr 

Entwirft wirksame Testfälle. 

Testdesigner können Anforderungen rasch erfassen. Sie erstellen 

methodisch strukturierte Testfälle und kommunizieren Abweichungen 

sachlich und nachvollziehbar. 

aUFgaBen 

• Analysiert Produktanforderungen, technische Spezifikationen 

und den Aufbau des Systems. 

• Leitet Testfälle von den funktionalen und nichtfunktionalen Anforderungen 

ab und beschreibt sie so, dass sie von Testern und 

Entwicklern einfach verstanden und ausgeführt werden können. 

• Entwickelt automatisierte Integrations- und Systemtests (evtl. 

separate Rolle Testautomatisierer). 

• Erstellt bzw. beschafft die notwendigen Testdaten. 

• Kommuniziert gut mit den Anforderungsspezialisten und 

den Softwareentwicklern. 

• Analysiert die entdeckten Fehler und hilft, die Fehlerauswirkungen 

und -ursachen zu beurteilen. 


• Idealerweise ISTQB/ASQF-Certified Tester Foundation Level. 

• Hochschulstudium als Informatiker respektive Ingenieur. 

• Findet sich mit komplexen Systemen und Anforderungen zurecht. 

• Hat Erfahrung in der Anforderungsanalyse. 

• Hat Erfahrung in Softwareentwicklung. 

• Verfügt über präzise schriftliche Ausdrucksweise. 

• Akzeptanz bei den Softwareentwicklern und Anforderungsspezialisten. 

12.4 TESTAuToMATiSiErEr 


Automatisiert wiederkehrende Testfälle. 

Testautomatisierer können die wichtigsten Bedienungsabläufe 

eines Systems sowie die Steuerung von Umsystemen (Testtreiber 

und Stubs) rasch in einem Testautomatisierungswerkzeug erfassen, 

wiederkehrende Testfälle anhand dieser Abläufe automatisieren, 

fehlerhafte Abläufe analysieren sowie Fehler sachlich und 

nachvollziehbar kommunizieren. 

aUFgaBen 

• Analysiert Anforderungen ans automatisierte Testen, plant den 

Einsatz der Testautomatisierungswerkzeuge und setzt sie auf. 

• Erstellt ein Framework der wichtigsten Bedienungsabläufe 

des Systems sowie der Steuerung von Umsystemen. 

• Automatisiert und unterhält Testfälle und führt sie aus. 

• Kommuniziert gut mit den Anforderungsspezialisten und 

den Softwareentwicklern. 

• Analysiert die entdeckten Fehler und hilft, die Fehlerauswirkungen 

und -ursachen zu beurteilen. 


• Idealerweise ISTQB/ASQF-Certified Tester Foundation Level. 

• Hat Erfahrung in Softwareentwicklung. 

• Findet sich in komplexen Systemen und Anforderungen 

zurecht. 

• Hat Kenntnisse in der Anforderungsanalyse. 

• Verfügt über präzise schriftliche Ausdrucksweise. 

• Akzeptanz bei den Softwareentwicklern.

12.5 TESTEr 

Arbeitet zuverlässig und exakt. 

Tester führen Tests gemäss Testfallspezifikation gewissenhaft 

und zuverlässig aus und rapportieren Abweichungen in einem 

entsprechenden Tool. 

aUFgaBen 

• Orientiert sich über die durchzuführenden Tests anhand der 

Testspezifikationen (Testfälle, Testdaten). 

• Bereitet das System für die Testdurchführung vor. 

• Stellt die notwendigen Testdaten bereit. 

• Führt die einzelnen Testschritte gemäss Testfallspezifikation 

durch und beobachtet das Verhalten des Systems. 

• Protokolliert Durchführung und beobachtete Resultate. 

• Bewertet jedes Testresultat danach, ob es erfüllt oder nicht erfüllt 

ist. 

• Trägt Fehler in die Fehlerdatenbank ein. 

• Unterstützt Entwickler beim Reproduzieren der Fehler. 


• Hat Erfahrung im Umgang mit dem zu testenden System, 

z.B. als Anwender. 

• Geht gewissenhaft vor. 

• Ist zuverlässig bei der Protokollierung und der Eintragung in 

der Fehlerdatenbank. 

• Akzeptanz bei den Softwareentwicklern und Anforderungsspezialisten. 

TesTmanagemenT 51


13. DokuMENTvorlAGEN: wElChE 

GliEDEruNGEN SiCh iN DEr 

PrAxiS bEwährEN 

Jedes Unternehmen, jeder Entwicklungsprozess, jedes Qualitätsmanagementsystem 

und jeder Referenzprozess hat eigene Dokumentvorlagen. 

Die nachfolgenden Vorschläge für Inhaltsverzeichnisse 

zeigen, wie die Vielzahl von Informationen systematisch 

eingeordnet und wieder aufgefunden werden kann. 

13.1 TESTPlAN 

1. Einführung, Allgemeines 

2. Testziele (aus Businesssicht) 

3. Strategie zur Zielerreichung, Teststrategie 

3.1 Teststufen und ihre Testziele 

3.2 Testtools 

4. Identifikation der Testobjekte bzw. der zu testenden 

Anforderungen 

5. Testdurchführung, Testaufträge 

5.1 Zusammenstellung der Testaufgaben 

5.1.1 Allgemeine Vorgaben 

5.1.2 Testaktivitäten und evtl. spezifische Testziele 

5.1.3 Weitere wichtige Aktivitäten 

5.2 Investitionen für Testinfrastruktur 

5.3 Testorganisation 

5.4 Beurteilung der Testaufwände 

5.5 Koordination und Absprachen

5.6 Zeitliche Abhängigkeiten, Meilensteine 

6. Berichterstattung, Testdokumentation 

6.1 Fehlererfassung 

6.2 Testberichte 

6.3 Testdokumentation 

7. Kennzahlen 

8. Risikobetrachtung 

13.2 TESTfAllSPEZifikATioN 

1. Einführung, Allgemeines 

2. Testüberblick 

2.1 Teststrategie für die zu testende Einheit 

2.2 Spezielle Eigenschaften der zu testenden Einheit 

2.3 Kritikalität der zu testenden Einheit 

3. Testumgebung 

3.1 Tools 

3.2 Testdaten 

3.3 Testkonfiguration 

4. Generelles Vorgehen bei der Testdurchführung 

4.1 Vorbereitung 

4.2 Durchführung, Fehlererfassung 

4.3 Auswertung, Aufzeichnung 

5. Testfälle 

5.1 Titel der zu testenden Anforderung, Funktion, Use Case etc. 

5.2 Vorbedingung 

5.3 Beschreibung der einzelnen Testschritte 

in Tabellenform 


5.4 Nachbereitung 

(Aktionen, um das System evtl. wieder in den Anfangszustand 

zurückzusetzen) 

no. Testschrittbeschreibung/ 

Input 

1 

2 

... 

13.3 TESTbEriChT 

erwartetes 

Resultat 

Tatsächliches 

Resultat 

Beurteilung 

(erfüllt/nicht 

erfüllt) 

1. Identifikation des Testobjekts 

2. Zusammenfassende Beurteilung der Testendkriterien, 

Freigabeempfehlung 

3. Begründung der Freigabeempfehlung 

3.1 Kennzahlen und ihre Interpretation 

3.2 Testzyklen, Testergebnisse, Testaufwände 

3.3 Abschätzung Restfehlerrate 

4. Beurteilung der Zielerreichung 

4.1 Testziel 

4.2 Kosten, Termine 

4.3 Abweichung vom Testplan 

5. Nicht getestet, offene Punkte, Massnahmen


14. TESTwErkZEuGE: wElChES Tool 

SiCh wofür EiGNET 

Die folgende Liste gibt einen Überblick über ein paar der bekannteren 

Tools. Sie ist bei weitem nicht abschliessend. Auf dem Internet 

finden sich aktuelle und kommentierte Zusammenstellungen 

von weiteren Testtools. 

einsatzgebiet Hersteller: Produktname 

Testverwaltung • IBM Rational: TestManager 

• Mercury: TestDirector 

• Microsoft: Excel, Word 

systemtestautomatisierung • IBM Rational: Robot, 

FunctionalTester (.Net) 

• Mercury: Winrunner, 

Quicktest (.Net) 

Integrationstestautomatisierung • IBM Rational: Test RealTime 

Unit-Testtools • IPL: Cantata, Cantata++ 

• JUnit, CppUnit, NUnit


15. wEiTErführENDE iNforMATio- 

NEN: wo SiCh DAS NAChSChlAGEN 

lohNT 

15.1 liTErATur 

«Basiswissen Softwaretest: Aus- und Weiterbildung zum Certified 

Tester, Foundation Level nach ASQF- und ISTQB-Standard», 

von Andreas Spillner, Tilo Linz, dpunkt.verlag, 3. überarbeitete 

Auflage 2005, ISBN 3-89864-358-1 

• Ideal, um sich auf die Prüfung «Certified Tester Foundation 

Level» vorzubereiten. 

• Verbindet Theorie und Praxis des Softwaretestens. Richtet 

sich an Softwaretestmanager und -designer. Enthält keine 

Dokumentvorlagen oder Inhaltsverzeichnisse. 

«Lehrbuch der Software-Technik, Band 2: Software-Management, 

Software-Qualitätssicherung, Unternehmensmodellierung», 

von Helmut Balzert, Verlag Spektrum der Wissenschaft 

2000, 2. Auflage, ISBN 3827403014 

«Vademekum des Software-Testens, SAQ-Leitfaden für die 

Planung der Software-Qualitätssicherung», von Daniel Baumann, 

Thomas Hofmann, Donat Hutter, Ruedi Jäggin, Doron 

Moritz und Markus Pfister; SAQ, Schweizerische Arbeitsgemeinschaft 

für Qualitätssicherung, 2000 

• Ein dünnes A4-Büchlein von Prozess- und Qualitätsingenieuren 

aus der Schweizer Industrie. Behandelt alle Aspekte des Tes-

tens, wie Testprozess, Testrollen, Testmetriken, Dokumenvorlagen. 

Fasst wichtige Bücher und Normen zum Testen zusammen. 

«Software-Prüfung. Eine Anleitung zum Test und zur Inspektion», 

von Karol Frühauf, Jochen Ludewig und Helmut Sandmayr, 

vdf Hochschulverlag AG an der ETH Zürich, 5. Auflage 

2004, ISBN 3 7281 2906 2 

«Methodisches Testen von Programmen» von G. J. Myers, 

Verlag R. Oldenbourg, 6. Auflage 1999, ISBN 3-486-25056-6 

• Das meistzitierte Buch zum Testen. Auch heute noch ein 

Genuss für jeden interessierten Tester, Testdesigner, Testmanger 

oder Testprozessgestalter. 

«Management und Optimierung des Testprozesses (mit TPI 

und TMap)», von Martin Pol, Tim Koomen und Andreas Spillner, 

dpunkt.verlag, 2000, ISBN 3-932588-65-7 

• Hilft, den Testprozess in einem Unternehmen systematisch 

zu optimieren. 

«Testing Embedded Software» von Bart Broekman und Edwin 

Notenboom, Addison-Wesley, 2003, ISBN 0 321 15986 

• Gute Vorgehenspraktiken, beispielsweise auch für Sicherheitsanalysen 

(Safety). Viele tabellenartige Instrumente. 

«Software Testing: Tests, Verfahren, Werkzeuge; Die Praxis 

des Rapid Application Testings; Agiles 

Qualitätsmanagement», von Manfred Rätzmann, Galileo Press, 


2002, ISBN3-89842-271-2 

«Lessons Learned in Software Testing: A Context-Driven 

Approach», von Cem Kaner, James Bach und Bret Pettichord, 

Wiley, 2002, ISBN 0-471-08112-4 

• Richtet sich vor allem an Tester. Zeigt Vor- und Nachteile des 

IEEE-Standardtemplates für Softwaretestpläne. 

«Software automatisch testen», von Elfriede Dustin, Jeff Raschka 

und John Paul, Springer-Verlag, 2001, ISBN 3-540-67639-2 

15.2 NorMEN uND STANDArDS 

• IEEE Std 829-1998, IEEE Standard for Software Test Documentation 

• IEEE Std 1008-1987, IEEE Standard for Software Unit Testing 

• IEEE SWEBOK «Guide to the Software Engineering Body of 

Knowledge», Chapter 5 «Software Testing» 

• FDA «General Principles of Software Validation; Final 

Guidance for Industry and FDA Staff», January 11, 2002 

15.3 wEbliNkS 

• Swiss Testing Board 

http://www.swiss-testing-board.ch 

• Website zum Buch «Basiswissen Softwaretest» 

http://www.dpunkt.de/certified-tester 

• «The Economic Impacts of Inadequate Infrastructure for

Software Testing», National Institute of Standards & 

Technology, USA, May 2002 

http://www.nist.gov/director/prog-ofc/report02-3.pdf 

• ERNI Experiences über Testen 

http://www.erni.ch/experience 

TesTmanagemenT 63

TESTProZESS: wiE rollEN, PhASEN, 

TäTiGkEiTEN uND DokuMENTE 

ZuSAMMENwirkEN 

Projektplan 

 

 

anforde- 

rungsliste 

sysTem 

TesT 

InTegRa- 

TIOn TesT 

UnIT 

/mODULe TesT 

TesT- 

PLanUng 

i i 

i i 

Testmanager 

Testfallkatalog 

 

anforderungen 

TesT- 

DesIgn 

TesT- 

DURCHFüHRUng 

Testdesigner Testfallspezifikation Tester Testprotokoll 

 

Fehlermeldungen 


TesT- 

aUsWeRTUng 

Testmanager 

Testbericht 

 

Planning Development execution evaluation 

The test process consists of the same four activities at each stage of testing: 

planning, developing, executing and evaluating tests. The test manager is 

responsible for planning and evaluating the tests. The test designer develops 

the test cases, while the testers are responsible for executing the tests.

enables & delivers 

www.erni-consultants.com

i i i i - erni-consultants.com

Erfolgreiche ePaper selbst erstellen

Template löschen?

Als Template speichern?