i i i i - erni-consultants.com
i i i i - erni-consultants.com
i i i i - erni-consultants.com
Erfolgreiche ePaper selbst erstellen
Machen Sie aus Ihren PDF Publikationen ein blätterbares Flipbook mit unserer einzigartigen Google optimierten e-Paper Software.
TesTmanagemenT 1<br />
eRnI essenTIaLs<br />
TEST MANAGEMENT
enables & delivers<br />
maRCeL sTOOP<br />
marcel.stoop@<strong>erni</strong>.ch<br />
senior Consultant and<br />
Certified Testmanager<br />
bei eRnI schweiz ag<br />
vorworT<br />
Software gehört zu den komplexesten<br />
menschlichen Erzeugnissen. Durch<br />
die Vernetzung der Systeme wird ihre<br />
Komplexität weiter zunehmen. Dessen<br />
ungeachtet erhält das Testen in vielen Entwicklungsabteilungen<br />
einen untergeordneten<br />
Status, obwohl es vielfältige Gründe<br />
gibt, Software intensiv und systematisch<br />
zu testen.<br />
Ein zentraler Punkt des Testens ist die<br />
Überprüfung des tatsächlichen Verhaltens<br />
der Software gegenüber den definierten<br />
Anforderungen. Des Weiteren senkt das<br />
Testen das Risiko hoher Folgekosten. Denn<br />
je früher Fehler gefunden werden, desto<br />
billiger ist ihre Behebung. Das Testen ist<br />
in einem ersten Schritt die Beseitigung<br />
von Fehlern. Nutzt man die sich daraus<br />
ergebenden Möglichkeiten, ist das Testen<br />
ein mächtiges Controllinginstrument, das<br />
eine nachvollziehbare Qualitätskontrolle<br />
für den gesamten Entwicklungsprozess<br />
liefert. Meine Erfahrungen zeigen: Hochwertige<br />
Software lässt sich heute nur noch<br />
durch einen verzahnten Entwicklungsund<br />
Testprozess herstellen.<br />
eRnI – Innovation in Process and Technology<br />
TesTmanagemenT 3<br />
1. vorworT 2<br />
2. EiNlEiTuNG 5<br />
3. SofTwArETESTS 7<br />
4. DiE ZEhN-PuNkTE-ChECkliSTE 11<br />
5. TESTPlANuNG 15<br />
6. v-MoDEll 19<br />
7. METhoDiSChE TESTfAllErSTElluNG 23<br />
8. koMbiNAToriSChE ExPloSioNEN vErMEiDEN! 27<br />
9. TESTfAllkATAloG 31<br />
10. TESTAuToMATiSiEruNG 37<br />
11. TESTProZESS 41<br />
12. ProfESSioNEllE TESTEr 45<br />
12.1 Testmanager 45<br />
12.2 Testarchitekt 47<br />
12.3 Testdesigner 48<br />
12.4 Testautomatisierer 49<br />
12.5 Tester 50<br />
13. DokuMENTvorlAGEN 53<br />
13.1 Testplan 53<br />
13.2 Testfallspezifikation 54<br />
13.3 Testbericht 55<br />
14. TESTwErkZEuGE 57<br />
15. wEiTErführENDE iNforMATioNEN 59<br />
15.1 Literatur 59<br />
15.2 normen und standards 61<br />
15.3 Weblinks 61
2. EiNlEiTuNG<br />
TesTmanagemenT 5<br />
Software zu testen, ist extrem aufwändig und schwierig.<br />
Weshalb?<br />
• Wer das erste Mal versucht, Software systematisch zu testen,<br />
kapituliert vor den astronomisch vielen Testfällen. Sie ergeben<br />
sich aufgrund der kombinatorischen Explosion von Eingangsdaten<br />
und internen Softwarezuständen.<br />
• Oft bleibt für das Testen keine Zeit mehr, da die Entwicklung<br />
länger dauert als geplant und der Ausliefertermin drängt.<br />
• Testen wird als überflüssige und unattraktive Arbeit angesehen.<br />
• Das Testen von Software ist eine junge Disziplin des Software<br />
Engineerings, die die Hochschulen lange vernachlässigten.<br />
• Vielerorts versteht das Management das Testen ausschliesslich<br />
als Kostenfaktor, obwohl es ein wertschöpfender und<br />
qualitätssteigernder Teil der Produktionskette und des Controllingprozesses<br />
ist.<br />
Ungenügend qualifizierte Tester, der Drang, alles vollständig testen<br />
zu wollen, und die engen Rahmenbedingungen in Projekten<br />
führen dazu, dass software ungenügend getestet wird.
TesTmanagemenT 7<br />
3. SofTwArETESTS:<br />
GESETZE, rEGElN uND PriNZiPiEN<br />
Vor dem Testbeginn hilft es, sich die folgenden Erfahrungswerte<br />
in Erinnerung zu rufen:<br />
• Die Testkosten machen 40 bis 60 Prozent des gesamten<br />
Projektaufwandes aus (Harry M. Sneed, Stefan Jungmayr: «Produkt-<br />
und Prozessmetriken für Softwaretest», in Informatik-Spektrum,<br />
Springer-Verlag, Bd. 29, Heft 1, Feb. 2006, S. 23–38). Je höher<br />
die geforderte Qualität, desto höher ist der Testaufwand.<br />
• Vor systematischen Tests enthält jede Software auf 1000<br />
Zeilen Code durchschnittlich 10 bis 30 Fehler (Umfrage<br />
unter Softwareentwicklern).<br />
• Die geforderte Qualität der Software bewegt sich je nach<br />
Anwendungsfeld zwischen 0,5 und 1,0 Fehlern pro 1000<br />
Programmzeilen.<br />
• Pro 1000 Zeilen zu testenden Code müssen die Tests 9,0<br />
bis 29,5 Fehler aufdecken.<br />
• Der Aufwand, um in gut getesteter Software weitere Fehler<br />
zu finden, steigt stark an.<br />
• Die Fehlerdichte in Softwaremodulen variiert stark.<br />
Im Durchschnitt enthalten 30 Prozent der Softwaremodule<br />
eines Systems 70 Prozent der Fehler.<br />
• Es ist kostengünstiger, Fehler in einem frühen Entwicklungsschritt<br />
zu beheben als in einem späten.
Fehlleistungskosten sind der bestimmende Faktor in den F&E-<br />
Kosten! Fehlerkosten wachsen exponentiell in der Zeitspanne<br />
zwischen ihrer Entstehung und ihrer Entdeckung beziehungsweise<br />
Behebung.<br />
Folgende Erfahrungswerte verdeutlichen diesen Zusammenhang:<br />
anforderungsspez.<br />
analyse/<br />
Design<br />
Implementierung<br />
1 1 1 6 12 20<br />
= relative Fehlerkosten<br />
Intergrationstest<br />
systemtest<br />
Feld<br />
• Effektives Testen beginnt nicht erst am Schluss, sondern<br />
bereits mit der Erstellung und dem Review der Anforderungen.<br />
Im frühen Glied der Produktionskette sind die Fehlerbeseitigungskosten<br />
am geringsten, und der Nutzen ist am<br />
höchsten. Alle nachfolgenden Produktionsschritte profitieren<br />
von der höheren Anforderungsqualität.<br />
• Es gibt kein «bestes» Testverfahren. Am effektivsten ist eine<br />
Mischung aus Reviews, Entwicklertests und Tests durch eine<br />
unabhängige Testgruppe.<br />
TesTmanagemenT 9<br />
ein kleines, spezialisiertes Testteam, das die Rollen Testmanager,<br />
Testdesigner und Tester professionell abdeckt, ist effizienter und<br />
effektiver als grosse ad-hoc-Testteams.
TesTmanagemenT 11<br />
4. DiE ZEhN-PuNkTE-ChECkliSTE<br />
Folgende Checkliste unterstützt Testmanager, die ein Projekt<br />
ohne expliziten Testprozess übernehmen. Sie hilft, in kurzer Zeit<br />
objektiv messbare Fortschritte zu erzielen.<br />
1. Verschaffe dir einen Überblick über das zu testende System.<br />
Organisiere dir ein grosses Systemübersichtsbild.<br />
2. Bring beim wichtigsten Stakeholder das Businessziel für die<br />
Tests in Erfahrung.<br />
3. Wo sind die Anforderungen und Spezifikationen?<br />
Eine grobe, durchnummerierte Liste von zu testenden<br />
Punkten genügt (siehe Kapitel 9, Testfallkatalog).<br />
4. Priorisiere die Spezifikationspunkte, die Businessabläufe,<br />
die Datenübernahmen und die Systemteile gemäss einem<br />
nachvollziehbaren Raster (siehe Kapitel 9, Testfallkatalog).<br />
5. Definiere Teststufen (siehe Kapitel 6, V-Modell) und ordne<br />
jeder Stufe ein zuständiges Testteam zu.<br />
6. Erstelle die Testplanung.<br />
7. Sorge dafür, dass jedes Team mindestens ein Mitglied hat,<br />
das sich zu 100 Prozent den Tests widmet. Coache dieses<br />
Mitglied zum Erfolg. Zeig beispielsweise, wie man zielgerichtet<br />
und effizient Testfälle und Testdaten aus den<br />
Anforderungen ableitet.<br />
8. Miss die Testergebnisse. Visualisiere sie als Trend-Charts und<br />
mach sie regelmässig allen bekannt. Damit wird das Testen<br />
von allen als wirksamer Controllingprozess verstanden.
9. Sorge für einen angepassten Informationsaustausch.<br />
Bewährt haben sich tägliche Stand-up-Meetings mit den<br />
Testteams sowie moderierte wöchentliche Testkoordinationsmeetings<br />
mit dem Gesamtprojektleiter und allen Testteamleitern.<br />
10. Stimme dich als Testmanager mit dem Projektleiter in<br />
puncto Planung ab und hilf im Change Control Board mit,<br />
damit Changes priorisiert werden und in die Planung einfliessen.<br />
TesTmanagemenT 13
TesTmanagemenT 15<br />
5. TESTPlANuNG: TESTS<br />
iTErATiv-iNkrEMENTEll PlANEN<br />
anforderungsspez.<br />
entwicklung<br />
Testdesign<br />
Testdurchführung<br />
Iterationsnummer<br />
BesT PRaCTICe<br />
Inkr. 1<br />
n – 2<br />
Inkr. 2 Inkr. 3<br />
Inkr. 1 Inkr. 2 Inkr. 3<br />
Inkr. 1<br />
n – 1<br />
Inkr. 2 Inkr. 3<br />
Inkr. 1<br />
Tests werden parallel zu anderen Disziplinen durchgeführt,<br />
nicht danach. Dazu eignet sich besonders das iterativ-inkrementelle<br />
Vorgehen. In jeder Iteration werden Tests für ein weiteres<br />
Inkrement vorbereitet respektive durchgeführt:<br />
• Erarbeitung der Tests nach der Erstellung eines Anforderungspakets.<br />
• Durchführung der Tests unmittelbar nach der Umsetzung<br />
der Anforderungen in der Software.<br />
RegeLn<br />
Beim iterativ-inkrementellen Vorgehen laufen Anforderungsdefinition,<br />
Entwicklung, Testdesign und Testdurchführung parallel<br />
ab.<br />
n<br />
Inkr. 2<br />
n + 1<br />
Inkr. 3<br />
n + 2
In jeder Iteration (n) …<br />
• erstellt das Anforderungsteam die Anforderungen für das<br />
nächste Inkrement (n + 1).<br />
• erstellt das Entwicklungsteam die Software für das aktuelle<br />
Inkrement (n). Das Testdesignteam erstellt die Testfälle dazu.<br />
• führt das Testteam die Testfälle für das vorhergehende Inkre-<br />
ment durch und meldet die Fehler.<br />
eRFOLgsFakTORen<br />
• Analysiere die Liste der funktionalen und nichtfunktionalen<br />
Anforderungen.<br />
• Gewinne eine Übersicht über die Architektur und die Abhän-<br />
gigkeiten der Komponenten.<br />
• Priorisiere die Anforderungen und die Komponenten<br />
(risikobasiert) aus Testsicht (siehe Kapitel 9, Testfallkatalog).<br />
• Definiere den Umfang der Inkremente so, dass jedes für sich<br />
getestet werden kann.<br />
nUTzen<br />
• Iteratives Testen schafft frühzeitig Vertrauen in die Qualität<br />
des Systems.<br />
• Laufende objektive Beurteilung des Projektfortschritts und<br />
der Softwarequalität.<br />
• Frühe Fehlererkennung führt zu Kosteneinsparungen.<br />
• Verhinderung eines Teststaus. Erfahrungsgemäss fehlt für<br />
dessen Abarbeitung am Ende des Projekts die Zeit.<br />
TesTmanagemenT 17
TesTmanagemenT 19<br />
6. v-MoDEll: iN wElChEr rEihENfol-<br />
GE DiE TESTSTufEN DurChlAufEN<br />
wErDEN<br />
entwicklung<br />
systemanforderung/<br />
-spezifikation<br />
architektur<br />
(Komponente/Subsystem)<br />
BesT PRaCTICe<br />
Unit/modul<br />
Code/Implementierung<br />
• Auf jeder Stufe des V-Modells sind Tests notwendig. Die<br />
Erstellung der Testfälle beginnt top-down, sobald die Anfor-<br />
derungen resp. die Spezifikationen vorhanden sind. Die<br />
Testerstellung beginnt mit den Systemtests. Danach folgen<br />
Integrationstests und zuletzt die Unit-Tests.<br />
Tests<br />
systemtest<br />
Integrationstest<br />
Unit-Test<br />
• Die Durchführung der Tests hingegen erfolgt bottom-up.<br />
Ist eine Unit/Komponente fertiggestellt, beginnen umge-<br />
hend die Unit-Tests. Danach folgen Integrations- und Systemtests.<br />
RegeLn<br />
• Planung und Erstellung der Testfälle erfolgen top-down,
das heisst, man entwirft zuerst die Systemtests.<br />
• Die Durchführung der Testfälle erfolgt bottom-up und<br />
beginnt mit den Unit-Tests.<br />
eRFOLgsFakTOR<br />
• Definiere Übergabekriterien zwischen den Teststufen.<br />
In der Regel definiert man einen Satz von Testfällen, die<br />
fehlerlos ablaufen müssen, bevor das Testobjekt an die<br />
nächste Teststufe übergeben wird. Diese Testfälle heissen im<br />
Fachjargon Smoke Tests, Basic Sanity Tests, Basic Operation<br />
Tests oder Quick Tests.<br />
nUTzen<br />
• Mit der Testfallerstellung auf Systemebene kann früh im<br />
Projekt begonnen werden. Dies stellt sicher, dass in der zeitkritischen<br />
Schlusstestphase alle durchzuführenden Tests<br />
fertig dokumentiert vorliegen.<br />
• Durch die Regelung der Übergabekriterien erhöht sich die<br />
Zuverlässigkeit der späteren Teststufen. Dadurch läuft das<br />
Testobjekt stabil, und die Mehrzahl der Tests liefert aussagekräftige<br />
Ergebnisse.<br />
TesTmanagemenT 21
TesTmanagemenT 23<br />
7. METhoDiSChE TESTfAllErSTElluNG:<br />
wiE MAN AuS ANforDEruNGEN<br />
TESTfällE AblEiTET<br />
BesT PRaCTICe<br />
Leite für jede funktionale (Use Case) und jede nichtfunktionale<br />
Anforderung (NFA) einen oder mehrere Testfälle ab.<br />
• Leite für jeden Use Case (UC) 1 bis n Test Cases (TC) ab:<br />
1 UC -> n TCs<br />
• Leite für jede nichtfunktionale Anforderung 1 bis n Test<br />
Cases ab: 1 NFA -> n TCs<br />
RegeLn<br />
Funktionale anforderung<br />
(Use Case)<br />
1...n<br />
3<br />
Testfall (Test Case)<br />
Regeln zur Ableitung von Testfällen für funktionale Anforderungen:<br />
• Formuliere für jede funktionale Anforderung mindestens<br />
einen Testfall, der den Normalfall überprüft.<br />
<br />
nichtfunktionale anforderung<br />
(NFA)<br />
1...n<br />
Durchsatz, Reaktionszeit,Verfügbarkeit,<br />
sicherheit etc.
• Je nach Komplexität sind weitere Testfälle notwendig,<br />
um das korrekte Verhalten für alternative Abläufe zu<br />
überprüfen.<br />
Regeln zur Ableitung von Testfällen für nichtfunktionale<br />
Anforderungen:<br />
• Formuliere für jede nichtfunktionale Anforderung mindestens<br />
einen Testfall, der die Einhaltung der geforderten<br />
Leistungs- oder Qualitätsangaben garantiert.<br />
• Je nach Komplexität sind weitere Testfälle notwendig, um<br />
das korrekte Verhalten unter verschiedenen Bedingungen zu<br />
überprüfen (Datenvolumen, Zugriffsrate, Umgebungsbedingungen,<br />
Konfiguration).<br />
eRFOLgsFakTORen<br />
Bessere Schätzwerte erhält man, wenn für eine repräsentative<br />
Gruppe von Anforderungen je nach Komplexität exemplarisch<br />
die Anzahl Testfälle bestimmt wird.<br />
Beispielsweise so:<br />
• 1 Testfall für nichtkomplexe Anforderungen,<br />
• 3–5 Testfälle für mittelkomplexe und<br />
• 10–20 Testfälle für sehr komplexe Anforderungen.<br />
nUTzen<br />
• Einheitliches Vorgehen für alle Arten von Anforderungen.<br />
• Aus der Liste der funktionalen und nichtfunktionalen<br />
Anforderungen lassen sich der grobe Testumfang und<br />
der Aufwand leicht abschätzen.<br />
TesTmanagemenT 25
TesTmanagemenT 27<br />
8. koMbiNAToriSChE ExPloSioNEN<br />
vErMEiDEN! wiE viElE TESTfällE<br />
Pro uSE CASE NöTiG SiND<br />
1. karte einschieben ungültig<br />
2. PIn-Code eingeben<br />
3. Betrag eingeben<br />
anzahl Testfälle<br />
BesT PRaCTICe<br />
falsche PIn<br />
Ist es notwendig, für jede denkbare Kombination von Alternati-<br />
ven einen Testfall zu definieren? Nein, denn in der Praxis schliessen<br />
sich Alternativen häufig aus. Im dargestellten Beispiel eines<br />
Ban<strong>com</strong>aten schliessen sich «abgelaufene Karte» und «falscher<br />
PIN-Code» aus, weil eine abgelaufene Karte entweder eingezogen<br />
oder zurückgewiesen wird. Es gibt nur 9 mögliche Testfälle<br />
und nicht 24.<br />
RegeLn<br />
• Erste Priorität: Teste den Normalablauf.<br />
• Zweite Priorität: Teste die alternativen Abläufe.<br />
…<br />
gesperrt<br />
4 + 2 + 3 = 9 4 x 2 x 3 = 24<br />
abgelaufen
• Dritte Priorität: Teste die in der Praxis möglichen Kombinati-<br />
onen von alternativen Abläufen.<br />
eRFOLgsFakTORen<br />
• Teste zuerst den Normalablauf der Use Cases und stelle<br />
sicher, dass keine «show-stopper» auftreten.<br />
• Teste danach die alternativen Abläufe und ihre möglichen<br />
Kombinationen durch.<br />
nUTzen<br />
• Mit dieser Regel ist die Anzahl Testfälle nur proportional und<br />
nicht exponentiell zur Anzahl alternativer Abläufe.<br />
TesTmanagemenT 29
TesTmanagemenT 31<br />
9. TESTfAllkATAloG: wiE TESTS<br />
riSikobASiErT PrioriSiErT wErDEN<br />
BesT PRaCTICe<br />
Businessrelevanz<br />
(B)<br />
komplexität<br />
(K)<br />
nichtentdeckbarkeit<br />
(N)<br />
zu testender Punkt 1–5 1–5 1–5 1–125<br />
kundenanforderungen<br />
• Vertrag erstellen 5 4 2 40<br />
• Prämie verbuchen 5 2 4 40<br />
• Schaden eröffnen 5 3 4 60<br />
schnittstellen<br />
• FTP 2 3 2 12<br />
• Webservice 5 5 5 125<br />
Potenzielle Fehlerquellen<br />
• Verwechslung des<br />
kunden<br />
5 4 5 100<br />
Es ist aus Qualitätssicht sinnvoll, die Testintensität nach dem<br />
Risiko eines fehlerhaften Verhaltens zu richten.<br />
Risiko<br />
(R = B x K x N)<br />
Man sollte intensiv testen, wo ein Fehler grossen Schaden<br />
anrichten und mit hoher Wahrscheinlichkeit auftreten könnte.
Eine bewährte Formel zur Einschätzung des Risikos lautet:<br />
R = B x K x N<br />
Dabei bedeutet<br />
R = Risiko<br />
B = Businessrelevanz<br />
K = Komplexität, d.h. Fehlerwahrscheinlichkeit<br />
N = Nicht-Entdeckbarkeit eines Fehlers ohne gezielte<br />
Testvorkehrungen<br />
RegeLn<br />
Der Testfallkatalog besteht aus einer gewichteten Liste von zu<br />
testenden Punkten und legt fest, wie viele Tests nötig sind und<br />
wie detailliert sie zu spezifizieren sind.<br />
1. Erstelle eine strukturierte Liste von<br />
• Kundenanforderungen<br />
(funktionale sowie Leistungs- und Qualitätsanforderungen)<br />
• Gesetzen, Vorschriften, Normen<br />
• technischen Spezifikationen<br />
(funktionale und nicht funktionale)<br />
• Schnittstellen<br />
• Daten<br />
• potenziellen Fehlerquellen<br />
• Gefahren aus Sicht Betrieb, Unternehmen (Finanzen) und<br />
Endanwender<br />
TesTmanagemenT 33<br />
2. Lass die einzelnen Risikofaktoren von den Vertretern aus<br />
den verschiedenen Abteilungen bewerten und reviewen:<br />
• Businessrelevanz aus Sicht Business<br />
• Komplexität aus Sicht Entwicklung<br />
• Nicht-Entdeckbarkeit aus Sicht Testmanagement<br />
3. Sortiere die Listen nach Risiko und definiere, für welche<br />
Risikohöhe wie viele Tests in welchem Detaillierungsgrad<br />
zu definieren und durchzuführen sind. Beispielsweise:<br />
• Hohe Risiken: 10–20 Testfallspezifikationen mit detaillierter<br />
Beschreibung der einzelnen Testschritte<br />
• Mittlere Risiken: 3–5 Testfallspezifikationen mit grober<br />
Beschreibung des Testablaufs<br />
• Tiefe Risiken: 1 Testfall mit Beschreibung des Testziels<br />
eRFOLgsFakTORen<br />
• Falls kein Testmanagementtool vorhanden ist, genügt eine<br />
Excel-Liste mit separaten Arbeitsblättern für jede Gruppe.<br />
• Lass die Liste von verschiedenen Abteilungen reviewen.<br />
• Lass die Punkte von denjenigen bewerten, die das höchste<br />
Fach-Know-how haben.<br />
• Verwalte die Testfälle mit den zugehörigen Testfallspezifikationen<br />
in Excel oder einem Testmanagementtool (siehe Kapitel 14,<br />
Testwerkzeuge).
nUTzen<br />
• Ein Testfallkatalog macht den Umfang der Tests fassbar und<br />
managebar.<br />
• Der Begriff «Testabdeckung» ist einheitlich definiert. 100 Pro-<br />
zent Testabdeckung bedeutet: Alle zu testenden Punkte sind<br />
getestet.<br />
• Der Aufwand pro zu testendem Punkt ist transparent, planbar<br />
und steuerbar.<br />
• Alle Abteilungen werden berücksichtigt. Sie geben an, welche<br />
Tests für sie wichtig und sinnvoll sind.<br />
TesTmanagemenT 35
10. TESTAuToMATiSiEruNG:<br />
EffiZiENZSTEiGEruNG bEi<br />
rEGrESSioNSTESTS<br />
einspeisen von<br />
autom. Testscripts<br />
HW<br />
BesT PRaCTICe<br />
Die Testautomatisierung …<br />
(Web-)Client<br />
server<br />
TesTmanagemenT 37<br />
«gateway»<br />
zu Umsystem<br />
server<br />
• erhöht die Anzahl durchgeführter Tests pro Iteration/Release<br />
drastisch. Dies führt zu einer höheren Qualität bei weniger<br />
Testaufwand. Die Testeffizienz steigt.<br />
• ist wichtig bei zahlreichen erwarteten Änderungen (Hotfixes,<br />
Patches oder Releases), die nacheinander in sehr kurzer Zeit zu<br />
testen sind.<br />
• kommt vor allem bei Regressionstests zum Einsatz. Diese<br />
Tests stellen die kontinuierliche Systemstabilität und -funktionalität<br />
nach Änderungen sicher.<br />
DB
RegeLn<br />
Die Testautomatisierung beinhaltet folgende Hauptschritte:<br />
• Testfallspezifikationen erstellen und die manuelle Durch-<br />
führung mit einem «capture & replay tool» aufzeichnen,<br />
das automatisch Testscripts erstellt.<br />
• Testscripts programmtechnisch mit Eingangsdaten und Konfigurationsangaben<br />
für verschiedene Testumgebungen ergänzen.<br />
• Testmetriken generieren: Anzahl durchgeführter Testfälle,<br />
Anzahl «pass/fail» pro Schweregrad, Empfehlung.<br />
eRFOLgsFakTORen<br />
• Testautomatisierung setzt Programmierkenntnisse voraus<br />
und muss wie ein Softwareentwicklungsprojekt abgewickelt<br />
werden.<br />
• Der Erfolgsfaktor liegt in der kontinuierlichen und wirtschaftlichen<br />
Pflege der automatisierten Testfälle während der<br />
ganzen Lebensdauer der zu testenden Software.<br />
• Die Verwaltung der Testscripts in einem Versionsverwaltungstool<br />
und die kontinuierliche Anpassung an ändernde<br />
Anforderungen und Spezifikationen sind eine andauernde<br />
Tätigkeit.<br />
nUTzen<br />
• Automatisierte Tests dienen der Testeffizienzsteigerung und<br />
garantieren eine einheitliche Qualitätskontrolle.<br />
• Testautomatisierung erfordert eine grosse Investition in Testwerkzeuge<br />
und automatisierte Testscripts. Dieser Aufwand<br />
rechnet sich nur für die risikoreichsten Tests (siehe Kapitel 9,<br />
Testfallkatalog), die häufig und rasch durchzuführen sind.<br />
TesTmanagemenT 39
TesTmanagemenT 41<br />
11. TESTProZESS: wiE rollEN,<br />
PhASEN, TäTiGkEiTEN uND<br />
DokuMENTE ZuSAMMENwirkEN<br />
BesT PRaCTICe<br />
Der Testprozess gliedert sich in vier Phasen, die auf jeder Test-<br />
stufe dieselben sind:<br />
• Testplanung<br />
• Testdesign<br />
• Testdurchführung<br />
• Testauswertung<br />
Zumindest auf der Systemteststufe sind folgende Dokumente<br />
zu erstellen:<br />
• Testplan<br />
• Testfallspezifikation<br />
• Testprotokoll und Fehlermeldungen<br />
• Testbericht<br />
RegeLn<br />
Die vier Phasen bestehen aus folgenden Tätigkeiten:<br />
• Testplanung<br />
Der Testmanager erstellt den Testplan und definiert das Testvorgehen<br />
(Teststufen, Testziele Automatisierung).<br />
• Testdesign<br />
Die Testdesigner entwerfen die Testfallspezifikationen für die<br />
Anforderungen resp. die identifizierten Testfälle.<br />
• Testdurchführung<br />
Die Tester führen die Tests gemäss den Testfallspezifikationen
durch und vergleichen die tatsächlichen Resultate mit den<br />
im Testfall formulierten erwarteten Resultaten. Sie protokollieren<br />
die Umstände der Durchführung und die Ergebnisse in<br />
einem Testprotokoll. Bei Abweichungen verfassen sie eine<br />
Fehlermeldung.<br />
• Testauswertung<br />
Der Testmanager wertet die Testprotokolle und die Fehlermeldungen<br />
aus und fasst sie in einem Testbericht zusammen.<br />
Dieser enthält zudem seine Empfehlung für oder gegen eine<br />
Freigabe des Testobjekts.<br />
eRFOLgsFakTORen<br />
• Besetze die Rollen mit Testspezialisten (siehe Kapitel 12, Professionelle<br />
Tester).<br />
• Verfasse für jede Stufe einen Testplan. Diese Pläne können je<br />
ein separates Dokument sein oder für alle Stufen in einem<br />
Mastertestplan zusammengefasst werden.<br />
• Stelle Vorlagen für die Testdokumente zur Verfügung.<br />
• Definiere, was die Fehlermeldungen enthalten müssen, damit<br />
die Entwickler den Fehler reproduzieren und seine Ursache<br />
finden können.<br />
nUTzen<br />
Die Einhaltung des Prozesses führt zu vier Hauptvorteilen:<br />
• Nachvollziehbare Testergebnisse.<br />
• Die Tests erfolgen gegenüber dem Qualitätsmassstab der Anforderungen<br />
und nicht intuitiv aufgrund des Wissens von Testern.<br />
• Entwickler können die Fehler reproduzieren und beheben,<br />
ohne die Tester zeitlich zu belasten.<br />
TesTmanagemenT 43<br />
• Abteilungsübergreifende Change-Management-Meetings er-<br />
möglichen die Beurteilung jedes einzelnen Fehlers. Das Team<br />
fällt die Entscheidung, den Fehler zu korrigieren oder erneut<br />
zu testen.<br />
(Siehe grafische Darstellung «Testprozess» auf der letzten Umschlagseite)
TesTmanagemenT 45<br />
12. ProfESSioNEllE TESTEr:<br />
SPEZifiSChES ANforDEruNGSProfil<br />
für jEDE TESTrollE<br />
Ein professionelles Testteam deckt die Rollen Testmanager, Testdesigner<br />
und Tester ab. Dieses Kapitel listet die Aufgaben und<br />
Anforderungen an diese Rollen in Form von Checklisten auf. Die<br />
Listen helfen, geeignete Kandidaten zu finden und in die Rollen<br />
einzuweisen.<br />
12.1 TESTMANAGEr<br />
Führt, organisiert und entscheidet.<br />
Der Testmanager leitet das Testteam, ist entscheidungsstark und<br />
bringt Erfahrung im Testen mit.<br />
aUFgaBen<br />
• Passt den Testprozess den Erford<strong>erni</strong>ssen des Projekts an.<br />
• Plant Testvorbereitung und -durchführung, stimmt den Plan<br />
mit dem Gesamtprojektleiter und dem Release-Manager ab<br />
und budgetiert die Testaufwände.<br />
• Organisiert und leitet das Team von Testdesignern und<br />
Testern.<br />
• Koordiniert die Planung mit dem Anforderungsteam und<br />
stellt sicher, dass die Anforderungen reviewt werden.<br />
• Beauftragt die Testdesigner mit der Erstellung der Testfälle<br />
und stellt deren Qualität durch Reviews sicher.<br />
• Verwaltet die Testfälle in einem Testverwaltungswerkzeug
und stellt ihren Bezug zu den Anforderungen her.<br />
• Nimmt Teil an Change-Management-Meetings. Beurteilt die<br />
Auswirkungen von Fehlern, Anforderungsänderungen und<br />
Softwareanpassungen in Bezug auf den Aufwand, um Testfälle<br />
neu zu erstellen oder anzupassen und Tests zu wiederholen<br />
oder neu durchzuführen.<br />
• Beauftragt die Tester mit der Durchführung von Tests und<br />
überwacht ihre Arbeit.<br />
• Organisiert die Testinfrastruktur<br />
(Testwerkzeuge, Testsysteme, Testaufbau).<br />
• Weist instabile und ungenügend vorgetestete Software<br />
zurück.<br />
• Überwacht und rapportiert Testfortschritt, Qualität und aufgelaufene<br />
Kosten.<br />
• Fasst Testergebnisse im Testprotokoll zusammen, interpretiert<br />
die Resultate und erstellt den Testbericht mit Empfehlung<br />
für Freigabe oder Nachbessern der Software.<br />
anFORDeRUngsPROFIL<br />
• Idealerweise ISTQB/ASQF-Certified Tester Advanced Level<br />
(Testmanager).<br />
• Ist entscheidungsstark und verhandlungsgeschickt.<br />
• Hat Erfahrung als Testdesigner, evtl. als Anforderungsspezialist<br />
oder als Entwickler.<br />
• Kommuniziert gut und wird akzeptiert auf Stufe SW-/IT-Entwicklungsleiter,<br />
Projektleiter, Projektmanagement und<br />
Qualitätsmanagement.<br />
12.2 TESTArChiTEkT<br />
TesTmanagemenT 47<br />
Optimiert die Testkosten für mehrere Produkte.<br />
Der Testarchitekt berät den Testmanager in fachlicher Hinsicht.<br />
Er analysiert die Anforderungen, kennt sich mit den Softwarearchitekturen<br />
der entwickelten Systeme aus und gibt den<br />
Testdesignern und -automatisierern die fachlichen Vorgaben.<br />
aUFgaBen<br />
• Stellt kommerzielle Überlegungen hinsichtlich Testsynergien<br />
zwischen verschiedenen Produktlinien an.<br />
• Führt eine Kosten-Nutzen-Analyse für verschiedene Teststrategien<br />
durch.<br />
• Definiert den fachtechnischen Teil der Testpläne (Testkonzept).<br />
• Erstellt auf ökonomischer Basis eine Triage, welche Tests<br />
inhouse, welche bei Softwarepartnern und welche in spezialisierten<br />
Testzentren durchgeführt werden.<br />
• Stellt sicher, dass die Testdesigner bewährte Testpatterns wiederverwenden.<br />
anFORDeRUngsPROFIL<br />
• Idealerweise ISTQB/ASQF-Certified Tester Advanced Level<br />
(Testmanager).<br />
• Denkt analytisch und unternehmerisch.<br />
• Hat Überblick über die Produktpalette der Firma.<br />
• Hat Erfahrung als Testdesigner, Anforderungsspezialist und<br />
Softwarearchitekt.<br />
• Kommuniziert gut und wird akzeptiert von Softwarearchitekt,<br />
Leiter der Anforderungsspezialisten, dem SW-/IT-Entwicklungsleiter<br />
und dem Management.
12.3 TESTDESiGNEr<br />
Entwirft wirksame Testfälle.<br />
Testdesigner können Anforderungen rasch erfassen. Sie erstellen<br />
methodisch strukturierte Testfälle und kommunizieren Abweichungen<br />
sachlich und nachvollziehbar.<br />
aUFgaBen<br />
• Analysiert Produktanforderungen, technische Spezifikationen<br />
und den Aufbau des Systems.<br />
• Leitet Testfälle von den funktionalen und nichtfunktionalen Anforderungen<br />
ab und beschreibt sie so, dass sie von Testern und<br />
Entwicklern einfach verstanden und ausgeführt werden können.<br />
• Entwickelt automatisierte Integrations- und Systemtests (evtl.<br />
separate Rolle Testautomatisierer).<br />
• Erstellt bzw. beschafft die notwendigen Testdaten.<br />
• Kommuniziert gut mit den Anforderungsspezialisten und<br />
den Softwareentwicklern.<br />
• Analysiert die entdeckten Fehler und hilft, die Fehlerauswirkungen<br />
und -ursachen zu beurteilen.<br />
anFORDeRUngsPROFIL<br />
• Idealerweise ISTQB/ASQF-Certified Tester Foundation Level.<br />
• Hochschulstudium als Informatiker respektive Ingenieur.<br />
• Findet sich mit komplexen Systemen und Anforderungen zurecht.<br />
• Hat Erfahrung in der Anforderungsanalyse.<br />
• Hat Erfahrung in Softwareentwicklung.<br />
• Verfügt über präzise schriftliche Ausdrucksweise.<br />
• Akzeptanz bei den Softwareentwicklern und Anforderungsspezialisten.<br />
12.4 TESTAuToMATiSiErEr<br />
TesTmanagemenT 49<br />
Automatisiert wiederkehrende Testfälle.<br />
Testautomatisierer können die wichtigsten Bedienungsabläufe<br />
eines Systems sowie die Steuerung von Umsystemen (Testtreiber<br />
und Stubs) rasch in einem Testautomatisierungswerkzeug erfassen,<br />
wiederkehrende Testfälle anhand dieser Abläufe automatisieren,<br />
fehlerhafte Abläufe analysieren sowie Fehler sachlich und<br />
nachvollziehbar kommunizieren.<br />
aUFgaBen<br />
• Analysiert Anforderungen ans automatisierte Testen, plant den<br />
Einsatz der Testautomatisierungswerkzeuge und setzt sie auf.<br />
• Erstellt ein Framework der wichtigsten Bedienungsabläufe<br />
des Systems sowie der Steuerung von Umsystemen.<br />
• Automatisiert und unterhält Testfälle und führt sie aus.<br />
• Kommuniziert gut mit den Anforderungsspezialisten und<br />
den Softwareentwicklern.<br />
• Analysiert die entdeckten Fehler und hilft, die Fehlerauswirkungen<br />
und -ursachen zu beurteilen.<br />
anFORDeRUngsPROFIL<br />
• Idealerweise ISTQB/ASQF-Certified Tester Foundation Level.<br />
• Hat Erfahrung in Softwareentwicklung.<br />
• Findet sich in komplexen Systemen und Anforderungen<br />
zurecht.<br />
• Hat Kenntnisse in der Anforderungsanalyse.<br />
• Verfügt über präzise schriftliche Ausdrucksweise.<br />
• Akzeptanz bei den Softwareentwicklern.
12.5 TESTEr<br />
Arbeitet zuverlässig und exakt.<br />
Tester führen Tests gemäss Testfallspezifikation gewissenhaft<br />
und zuverlässig aus und rapportieren Abweichungen in einem<br />
entsprechenden Tool.<br />
aUFgaBen<br />
• Orientiert sich über die durchzuführenden Tests anhand der<br />
Testspezifikationen (Testfälle, Testdaten).<br />
• Bereitet das System für die Testdurchführung vor.<br />
• Stellt die notwendigen Testdaten bereit.<br />
• Führt die einzelnen Testschritte gemäss Testfallspezifikation<br />
durch und beobachtet das Verhalten des Systems.<br />
• Protokolliert Durchführung und beobachtete Resultate.<br />
• Bewertet jedes Testresultat danach, ob es erfüllt oder nicht erfüllt<br />
ist.<br />
• Trägt Fehler in die Fehlerdatenbank ein.<br />
• Unterstützt Entwickler beim Reproduzieren der Fehler.<br />
anFORDeRUngsPROFIL<br />
• Hat Erfahrung im Umgang mit dem zu testenden System,<br />
z.B. als Anwender.<br />
• Geht gewissenhaft vor.<br />
• Ist zuverlässig bei der Protokollierung und der Eintragung in<br />
der Fehlerdatenbank.<br />
• Akzeptanz bei den Softwareentwicklern und Anforderungsspezialisten.<br />
TesTmanagemenT 51
TesTmanagemenT 53<br />
13. DokuMENTvorlAGEN: wElChE<br />
GliEDEruNGEN SiCh iN DEr<br />
PrAxiS bEwährEN<br />
Jedes Unternehmen, jeder Entwicklungsprozess, jedes Qualitätsmanagementsystem<br />
und jeder Referenzprozess hat eigene Dokumentvorlagen.<br />
Die nachfolgenden Vorschläge für Inhaltsverzeichnisse<br />
zeigen, wie die Vielzahl von Informationen systematisch<br />
eingeordnet und wieder aufgefunden werden kann.<br />
13.1 TESTPlAN<br />
1. Einführung, Allgemeines<br />
2. Testziele (aus Businesssicht)<br />
3. Strategie zur Zielerreichung, Teststrategie<br />
3.1 Teststufen und ihre Testziele<br />
3.2 Testtools<br />
4. Identifikation der Testobjekte bzw. der zu testenden<br />
Anforderungen<br />
5. Testdurchführung, Testaufträge<br />
5.1 Zusammenstellung der Testaufgaben<br />
5.1.1 Allgemeine Vorgaben<br />
5.1.2 Testaktivitäten und evtl. spezifische Testziele<br />
5.1.3 Weitere wichtige Aktivitäten<br />
5.2 Investitionen für Testinfrastruktur<br />
5.3 Testorganisation<br />
5.4 Beurteilung der Testaufwände<br />
5.5 Koordination und Absprachen
5.6 Zeitliche Abhängigkeiten, Meilensteine<br />
6. Berichterstattung, Testdokumentation<br />
6.1 Fehlererfassung<br />
6.2 Testberichte<br />
6.3 Testdokumentation<br />
7. Kennzahlen<br />
8. Risikobetrachtung<br />
13.2 TESTfAllSPEZifikATioN<br />
1. Einführung, Allgemeines<br />
2. Testüberblick<br />
2.1 Teststrategie für die zu testende Einheit<br />
2.2 Spezielle Eigenschaften der zu testenden Einheit<br />
2.3 Kritikalität der zu testenden Einheit<br />
3. Testumgebung<br />
3.1 Tools<br />
3.2 Testdaten<br />
3.3 Testkonfiguration<br />
4. Generelles Vorgehen bei der Testdurchführung<br />
4.1 Vorbereitung<br />
4.2 Durchführung, Fehlererfassung<br />
4.3 Auswertung, Aufzeichnung<br />
5. Testfälle<br />
5.1 Titel der zu testenden Anforderung, Funktion, Use Case etc.<br />
5.2 Vorbedingung<br />
5.3 Beschreibung der einzelnen Testschritte<br />
in Tabellenform<br />
TesTmanagemenT 55<br />
5.4 Nachbereitung<br />
(Aktionen, um das System evtl. wieder in den Anfangszustand<br />
zurückzusetzen)<br />
no. Testschrittbeschreibung/<br />
Input<br />
1<br />
2<br />
...<br />
13.3 TESTbEriChT<br />
erwartetes<br />
Resultat<br />
Tatsächliches<br />
Resultat<br />
Beurteilung<br />
(erfüllt/nicht<br />
erfüllt)<br />
1. Identifikation des Testobjekts<br />
2. Zusammenfassende Beurteilung der Testendkriterien,<br />
Freigabeempfehlung<br />
3. Begründung der Freigabeempfehlung<br />
3.1 Kennzahlen und ihre Interpretation<br />
3.2 Testzyklen, Testergebnisse, Testaufwände<br />
3.3 Abschätzung Restfehlerrate<br />
4. Beurteilung der Zielerreichung<br />
4.1 Testziel<br />
4.2 Kosten, Termine<br />
4.3 Abweichung vom Testplan<br />
5. Nicht getestet, offene Punkte, Massnahmen
TesTmanagemenT 57<br />
14. TESTwErkZEuGE: wElChES Tool<br />
SiCh wofür EiGNET<br />
Die folgende Liste gibt einen Überblick über ein paar der bekannteren<br />
Tools. Sie ist bei weitem nicht abschliessend. Auf dem Internet<br />
finden sich aktuelle und kommentierte Zusammenstellungen<br />
von weiteren Testtools.<br />
einsatzgebiet Hersteller: Produktname<br />
Testverwaltung • IBM Rational: TestManager<br />
• Mercury: TestDirector<br />
• Microsoft: Excel, Word<br />
systemtestautomatisierung • IBM Rational: Robot,<br />
FunctionalTester (.Net)<br />
• Mercury: Winrunner,<br />
Quicktest (.Net)<br />
Integrationstestautomatisierung • IBM Rational: Test RealTime<br />
Unit-Testtools • IPL: Cantata, Cantata++<br />
• JUnit, CppUnit, NUnit
TesTmanagemenT 59<br />
15. wEiTErführENDE iNforMATio-<br />
NEN: wo SiCh DAS NAChSChlAGEN<br />
lohNT<br />
15.1 liTErATur<br />
«Basiswissen Softwaretest: Aus- und Weiterbildung zum Certified<br />
Tester, Foundation Level nach ASQF- und ISTQB-Standard»,<br />
von Andreas Spillner, Tilo Linz, dpunkt.verlag, 3. überarbeitete<br />
Auflage 2005, ISBN 3-89864-358-1<br />
• Ideal, um sich auf die Prüfung «Certified Tester Foundation<br />
Level» vorzubereiten.<br />
• Verbindet Theorie und Praxis des Softwaretestens. Richtet<br />
sich an Softwaretestmanager und -designer. Enthält keine<br />
Dokumentvorlagen oder Inhaltsverzeichnisse.<br />
«Lehrbuch der Software-Technik, Band 2: Software-Management,<br />
Software-Qualitätssicherung, Unternehmensmodellierung»,<br />
von Helmut Balzert, Verlag Spektrum der Wissenschaft<br />
2000, 2. Auflage, ISBN 3827403014<br />
«Vademekum des Software-Testens, SAQ-Leitfaden für die<br />
Planung der Software-Qualitätssicherung», von Daniel Baumann,<br />
Thomas Hofmann, Donat Hutter, Ruedi Jäggin, Doron<br />
Moritz und Markus Pfister; SAQ, Schweizerische Arbeitsgemeinschaft<br />
für Qualitätssicherung, 2000<br />
• Ein dünnes A4-Büchlein von Prozess- und Qualitätsingenieuren<br />
aus der Schweizer Industrie. Behandelt alle Aspekte des Tes-
tens, wie Testprozess, Testrollen, Testmetriken, Dokumenvorlagen.<br />
Fasst wichtige Bücher und Normen zum Testen zusammen.<br />
«Software-Prüfung. Eine Anleitung zum Test und zur Inspektion»,<br />
von Karol Frühauf, Jochen Ludewig und Helmut Sandmayr,<br />
vdf Hochschulverlag AG an der ETH Zürich, 5. Auflage<br />
2004, ISBN 3 7281 2906 2<br />
«Methodisches Testen von Programmen» von G. J. Myers,<br />
Verlag R. Oldenbourg, 6. Auflage 1999, ISBN 3-486-25056-6<br />
• Das meistzitierte Buch zum Testen. Auch heute noch ein<br />
Genuss für jeden interessierten Tester, Testdesigner, Testmanger<br />
oder Testprozessgestalter.<br />
«Management und Optimierung des Testprozesses (mit TPI<br />
und TMap)», von Martin Pol, Tim Koomen und Andreas Spillner,<br />
dpunkt.verlag, 2000, ISBN 3-932588-65-7<br />
• Hilft, den Testprozess in einem Unternehmen systematisch<br />
zu optimieren.<br />
«Testing Embedded Software» von Bart Broekman und Edwin<br />
Notenboom, Addison-Wesley, 2003, ISBN 0 321 15986<br />
• Gute Vorgehenspraktiken, beispielsweise auch für Sicherheitsanalysen<br />
(Safety). Viele tabellenartige Instrumente.<br />
«Software Testing: Tests, Verfahren, Werkzeuge; Die Praxis<br />
des Rapid Application Testings; Agiles<br />
Qualitätsmanagement», von Manfred Rätzmann, Galileo Press,<br />
TesTmanagemenT 61<br />
2002, ISBN3-89842-271-2<br />
«Lessons Learned in Software Testing: A Context-Driven<br />
Approach», von Cem Kaner, James Bach und Bret Pettichord,<br />
Wiley, 2002, ISBN 0-471-08112-4<br />
• Richtet sich vor allem an Tester. Zeigt Vor- und Nachteile des<br />
IEEE-Standardtemplates für Softwaretestpläne.<br />
«Software automatisch testen», von Elfriede Dustin, Jeff Raschka<br />
und John Paul, Springer-Verlag, 2001, ISBN 3-540-67639-2<br />
15.2 NorMEN uND STANDArDS<br />
• IEEE Std 829-1998, IEEE Standard for Software Test Documentation<br />
• IEEE Std 1008-1987, IEEE Standard for Software Unit Testing<br />
• IEEE SWEBOK «Guide to the Software Engineering Body of<br />
Knowledge», Chapter 5 «Software Testing»<br />
• FDA «General Principles of Software Validation; Final<br />
Guidance for Industry and FDA Staff», January 11, 2002<br />
15.3 wEbliNkS<br />
• Swiss Testing Board<br />
http://www.swiss-testing-board.ch<br />
• Website zum Buch «Basiswissen Softwaretest»<br />
http://www.dpunkt.de/certified-tester<br />
• «The Economic Impacts of Inadequate Infrastructure for
Software Testing», National Institute of Standards &<br />
Technology, USA, May 2002<br />
http://www.nist.gov/director/prog-ofc/report02-3.pdf<br />
• ERNI Experiences über Testen<br />
http://www.<strong>erni</strong>.ch/experience<br />
TesTmanagemenT 63
TESTProZESS: wiE rollEN, PhASEN,<br />
TäTiGkEiTEN uND DokuMENTE<br />
ZuSAMMENwirkEN<br />
Projektplan<br />
<br />
<br />
anforde-<br />
rungsliste<br />
sysTem<br />
TesT<br />
InTegRa-<br />
TIOn TesT<br />
UnIT<br />
/mODULe TesT<br />
TesT-<br />
PLanUng<br />
i i<br />
i i<br />
Testmanager<br />
Testfallkatalog<br />
<br />
anforderungen<br />
TesT-<br />
DesIgn<br />
TesT-<br />
DURCHFüHRUng<br />
Testdesigner Testfallspezifikation Tester Testprotokoll<br />
<br />
Fehlermeldungen<br />
TesTmanagemenT 65<br />
TesT-<br />
aUsWeRTUng<br />
Testmanager<br />
Testbericht<br />
<br />
Planning Development execution evaluation<br />
The test process consists of the same four activities at each stage of testing:<br />
planning, developing, executing and evaluating tests. The test manager is<br />
responsible for planning and evaluating the tests. The test designer develops<br />
the test cases, while the testers are responsible for executing the tests.
enables & delivers<br />
www.<strong>erni</strong>-<strong>consultants</strong>.<strong>com</strong>