Umfrage 2011: Softwaretest in der Praxis - Anecon
Umfrage 2011: Softwaretest in der Praxis - Anecon
Umfrage 2011: Softwaretest in der Praxis - Anecon
Erfolgreiche ePaper selbst erstellen
Machen Sie aus Ihren PDF Publikationen ein blätterbares Flipbook mit unserer einzigartigen Google optimierten e-Paper Software.
In Kooperation mit<br />
den Hochschulen Bremen und Bremerhaven, <strong>der</strong> Fachhochschule Köln,<br />
ANECON Software Design und Beratung G.m.b.H.,<br />
dem German Test<strong>in</strong>g Board und dem Swiss Test<strong>in</strong>g Board<br />
STB<br />
Swiss Test<strong>in</strong>g Board<br />
dpunkt. verlag
Autoren<br />
Peter Haberl verantwortet bei <strong>der</strong> ANECON Software Design & Beratung G.m.b.H.<br />
als Geschäftsführer die Dienstleistungen und Kundenbeziehungen <strong>in</strong> Deutschland.<br />
Prof. Dr. Andreas Spillner ist Hochschullehrer für Software Eng<strong>in</strong>eer<strong>in</strong>g und Qualitätssicherung<br />
an <strong>der</strong> HS Bremen. Er war Gründungsmitglied und ist nun Ehrenmitglied<br />
des German Test<strong>in</strong>g Board (GTB e.V.). Er war Gründungssprecher <strong>der</strong> FG TAV <strong>der</strong><br />
GI. Seit 2007 ist er Fellow <strong>der</strong> GI.<br />
Prof. Dr. Kar<strong>in</strong> Vosseberg ist Hochschullehrer<strong>in</strong> an <strong>der</strong> HS Bremerhaven mit den<br />
Schwerpunkten System<strong>in</strong>tegration und Qualitätssicherung.<br />
Prof. Dr. Mario W<strong>in</strong>ter ist Hochschullehrer an <strong>der</strong> FH Köln mit den Lehr- und Forschungsgebieten<br />
Softwareentwicklung und Projektmanagement. Er ist Gründungsmitglied<br />
im GTB e.V. und war Sprecher <strong>der</strong> FG TAV <strong>der</strong> GI.<br />
, überarb.<br />
Herstellung: Nad<strong>in</strong>e Thiele<br />
Umschlaggestaltung: Helmut Kraus, www.exclam.de<br />
Druck: Wörmann PRODUCTION CONSULT, Heidelberg<br />
Artikelnummer: 077.95734<br />
Copyright © 2012 dpunkt.verlag GmbH<br />
R<strong>in</strong>gstraße 19 b<br />
69115 Heidelberg<br />
Die vorliegende Publikation ist urheberrechtlich geschützt. Alle Rechte vorbehalten.<br />
Die Verwendung <strong>der</strong> Texte und Abbildungen, auch auszugsweise, ist ohne die<br />
schriftliche Zustimmung des Verlags urheberrechtswidrig und daher strafbar. Dies<br />
gilt <strong>in</strong>sbeson<strong>der</strong>e für die Vervielfältigung, Übersetzung o<strong>der</strong> die Verwendung <strong>in</strong><br />
elektronischen Systemen.<br />
Es wird darauf h<strong>in</strong>gewiesen, dass die im Buch verwendeten Soft- und Hardware-<br />
Bezeichnungen sowie Markennamen und Produktbezeichnungen <strong>der</strong> jeweiligen<br />
Firmen im Allgeme<strong>in</strong>en warenzeichen-, marken- o<strong>der</strong> patentrechtlichem Schutz<br />
unterliegen.<br />
Alle Angaben und Programme <strong>in</strong> diesem Buch wurden mit größter Sorgfalt kontrolliert.<br />
We<strong>der</strong> Autor noch Verlag können jedoch für Schäden haftbar gemacht werden,<br />
die <strong>in</strong> Zusammenhang mit <strong>der</strong> Verwendung dieses Buches stehen.<br />
5 4 3 2 1 0
<strong>Umfrage</strong> <strong>2011</strong>:<br />
»<strong>Softwaretest</strong> <strong>in</strong> <strong>der</strong> <strong>Praxis</strong>«<br />
<strong>in</strong> Kooperation durchgeführt von<br />
Hochschule Bremen<br />
Hochschule Bremerhaven<br />
Fachhochschule Köln<br />
ANECON Software Design & Beratung G.m.b.H.<br />
German Test<strong>in</strong>g Board e.V.<br />
Swiss Test<strong>in</strong>g Board<br />
unterstützt durch<br />
ASQF e.V., Austrian Test<strong>in</strong>g Board, dpunkt Verlag GmbH,<br />
Softwareforen Leipzig GmbH, Fachgruppe TAV - GI e.V.
2<br />
Ausgangssituation<br />
Ausgangssituation<br />
In den letzten Jahren gab es im Bereich Qualitätssicherung und Testen<br />
viele neue Trends wie z.B. Test-Driven Development, exploratives Testen,<br />
modellbasiertes Testen o<strong>der</strong> auch die agilen Vorgehensmodelle. Diese<br />
Trends bieten Chancen als auch Herausfor<strong>der</strong>ungen <strong>in</strong> Test und Qualitätssicherung.<br />
Was davon hat bereits E<strong>in</strong>zug <strong>in</strong> den Test-Alltag gehalten? Hat<br />
sich <strong>in</strong> den letzten Jahren etwas verän<strong>der</strong>t? Wie sieht <strong>der</strong> Test-Alltag heute<br />
<strong>in</strong> den Unternehmen überhaupt aus? Diese und weitere Fragen waren<br />
Grundlage für die <strong>Umfrage</strong> <strong>2011</strong> »<strong>Softwaretest</strong> <strong>in</strong> <strong>der</strong> <strong>Praxis</strong>« [Umf11].<br />
Im Mai <strong>2011</strong> wurde <strong>in</strong> Kooperation <strong>der</strong> Hochschulen Bremen und<br />
Bremerhaven, <strong>der</strong> Fachhochschule Köln, <strong>der</strong> ANECON Software Design<br />
und Beratung G.m.b.H., dem German Test<strong>in</strong>g Board e.V. (GTB) und dem<br />
Swiss Test<strong>in</strong>g Board (STB) e<strong>in</strong>e anonyme Onl<strong>in</strong>e-<strong>Umfrage</strong> zum Thema<br />
» <strong>Softwaretest</strong> <strong>in</strong> <strong>der</strong> <strong>Praxis</strong>« im deutschsprachigen Raum durchgeführt. E<strong>in</strong><br />
Teil <strong>der</strong> Fragen wurde aus e<strong>in</strong>er <strong>Umfrage</strong> aus dem Jahr 1997 (»Prüf- und<br />
Testprozesse <strong>in</strong> <strong>der</strong> Softwareentwicklung«, [Mül98]) übernommen, um Verän<strong>der</strong>ungen<br />
und neue Trends im Bereich <strong>der</strong> Qualitätssicherung bei <strong>der</strong><br />
Softwareentwicklung aufzuzeigen.<br />
Die <strong>Umfrage</strong> hat e<strong>in</strong>e rege Teilnahme erfahren, was e<strong>in</strong>mal mehr die<br />
Aktualität und Wichtigkeit <strong>der</strong> Softwarequalitätssicherung untermauert.<br />
Unterschiedliche Personenkreise (Entwickler, Tester und Manager) wurden<br />
<strong>in</strong> <strong>der</strong> <strong>Umfrage</strong> zu verschiedenen Schwerpunkten befragt, die Antworten<br />
lassen so rollenspezifische Sichtweisen auf den <strong>Softwaretest</strong> zu. Erfreulich<br />
war ebenfalls die Erreichung e<strong>in</strong>es sehr breiten Mix an Firmengrößen und<br />
Branchen mit e<strong>in</strong>em leichten Schwerpunkt aus den Bereichen Automotive,<br />
Telekommunikation und Banken. Sowohl Mitarbeiter aus kle<strong>in</strong>- und mittelständischen<br />
Unternehmen als auch Großunternehmen haben an <strong>der</strong><br />
<strong>Umfrage</strong> teilgenommen, wobei die Teilnahme aus mittelständischen Unternehmen<br />
(101–1.000 Mitarbeiter) leicht überwiegt. Der Bereich Forschung ist<br />
mit ca. 10% relativ ger<strong>in</strong>g vertreten und verdeutlicht damit die <strong>Praxis</strong>nähe<br />
<strong>der</strong> Studienergebnisse.
Die <strong>Umfrage</strong><br />
Die <strong>Umfrage</strong> 3<br />
Die Befragung wurde onl<strong>in</strong>e über das Open-Source-Werkzeug Ilias [Ilias11]<br />
an <strong>der</strong> Hochschule Bremen <strong>in</strong> Form von drei rollenspezifischen Fragebogen<br />
realisiert. Ziel <strong>der</strong> <strong>Umfrage</strong> war neben <strong>der</strong> Feststellung <strong>der</strong> Verän<strong>der</strong>ungen<br />
zur <strong>Umfrage</strong> von 1997 e<strong>in</strong>erseits die Ermittlung des aktuellen Stands <strong>der</strong><br />
Qualitäts- und Testaktivitäten <strong>in</strong> <strong>der</strong> <strong>Praxis</strong>, an<strong>der</strong>erseits sollte <strong>der</strong> Handlungsbedarf<br />
für Forschung, Ausbildung und Beratung im Testen analysiert<br />
werden. Folgende Thesen sollen mit <strong>der</strong> <strong>Umfrage</strong> verifiziert o<strong>der</strong> falsifiziert<br />
werden:<br />
1. Hat das Qualitätsbewusstse<strong>in</strong> zugenommen und wird die Qualitätssicherung<br />
frühzeitig <strong>in</strong> den Softwareentwicklungsprozess <strong>in</strong>tegriert?<br />
2. Welchen E<strong>in</strong>fluss haben agile Vorgehensmodelle auf Test- und Qualitätsaktivitäten?<br />
3. Wie werden die Tester gesehen und wird <strong>der</strong> Wertbeitrag <strong>der</strong> Qualitätssicherung<br />
anerkannt?<br />
4. Wird Testautomation im Abnahme-, System- und Unittest systematisch<br />
und methodisch vorangetrieben?<br />
5. Werden repetitives Testen und e<strong>in</strong>fache Testdurchführung <strong>in</strong> (Onshore-,<br />
Nearshore- o<strong>der</strong> Offshore-)Unternehmen ausgelagert?<br />
E<strong>in</strong>e Auswertung aller Fragen ist im Internet verfügbar unter:<br />
http://www.softwaretest-umfrage.de<br />
Statistik zu den Teilnehmern <strong>der</strong> <strong>Umfrage</strong><br />
Insgesamt haben 1.623 Personen die <strong>Umfrage</strong> begonnen und mehr als<br />
die Hälfte hat den umfangreichen Fragebogen bis zum Ende bearbeitet.<br />
Der Inhalt war <strong>in</strong> 6–7 Fragekomplexe mit bis zu 100 Fragen (je nach Rolle)<br />
geglie<strong>der</strong>t und die hohe Anzahl <strong>der</strong> Antworten lässt fundierte Aussagen zu.<br />
Sehr erfreulich waren die zahlreiche Beteiligung <strong>der</strong> drei adressierten Gruppen<br />
(Entwickler, Tester und Management) und das große Engagement <strong>der</strong><br />
Teilnehmer bei <strong>der</strong> umfassenden Fragenbeantwortung.
4<br />
Die <strong>Umfrage</strong><br />
Die überwiegende Mehrzahl <strong>der</strong> Teilnehmer kam aus Deutschland<br />
(77%), gefolgt von <strong>der</strong> Schweiz (13%) und Österreich (10%). Um e<strong>in</strong>e gute<br />
Aussagefähigkeit über die <strong>Praxis</strong> des Testens zu erreichen, war es notwendig,<br />
möglichst viele Branchen und erfahrene Teilnehmer zu gew<strong>in</strong>nen. Beide<br />
Ziele wurden zur Gänze erfüllt. Mehr als 15 Branchen waren vertreten: vom<br />
öffentlichen Sektor über Leicht- und Schwer<strong>in</strong>dustrie bis h<strong>in</strong> zur Dienstleistungs-<br />
und F<strong>in</strong>anzbranche.<br />
Auch bei <strong>der</strong> Firmengröße lässt sich e<strong>in</strong>e repräsentative Stichprobe<br />
ermitteln (Abb. 1). Fast e<strong>in</strong> Drittel <strong>der</strong> Teilnehmer arbeitet <strong>in</strong> mittelgroßen<br />
Firmen mit 101-1.000 Mitarbeitern, aber auch kle<strong>in</strong>e Firmen (11-100 Mitarbeiter)<br />
s<strong>in</strong>d mit e<strong>in</strong>em Viertel <strong>der</strong> Teilnehmer sehr gut vertreten. Große und<br />
sehr große Unternehmen nahmen mit ca. 8% bzw. 13% an <strong>der</strong> <strong>Umfrage</strong> teil.<br />
Abb. 1<br />
> 50.000<br />
10.001-50.000<br />
1.001-10.000<br />
101-1.000<br />
51-100<br />
11-50<br />
1-10<br />
Wie viele Mitarbeiter beschäftigt Ihr Unternehmen <strong>in</strong>sgesamt?<br />
5,4%<br />
7,8%<br />
12,5%<br />
12,3%<br />
12,7%<br />
17,3%<br />
© <strong>Softwaretest</strong>umfrage <strong>2011</strong>: HS Bremen, HS Bremerhaven, FH Köln, ANECON, GTB, STB<br />
Größe <strong>der</strong> Unternehmen<br />
32,0%<br />
Bei <strong>der</strong> Ausbildung gaben mehr als 70% <strong>der</strong> <strong>Umfrage</strong>teilnehmer an, e<strong>in</strong><br />
Diplom-, Bachelor- o<strong>der</strong> Masterstudium absolviert zu haben, mehr als 8%<br />
sogar e<strong>in</strong>e Promotion. Die <strong>in</strong> <strong>der</strong> Studie repräsentierte Berufserfahrung war<br />
bee<strong>in</strong>druckend: E<strong>in</strong> Viertel <strong>der</strong> Teilnehmer gab an, 5-10 Jahre Berufserfahrung<br />
<strong>in</strong> <strong>der</strong> IT zu haben, 40% verfügen über 10-20 Jahre und e<strong>in</strong> Fünftel<br />
sogar über mehr als 20 Jahre Erfahrung. Die Domäne ist erwartungsgemäß<br />
männlich, nur 14% <strong>der</strong> Befragten waren Frauen.
Aufbau <strong>der</strong> <strong>Umfrage</strong><br />
Die <strong>Umfrage</strong> 5<br />
Die <strong>Umfrage</strong> ist rollenspezifisch aufgebaut. Folgende drei Gruppen von Rollen<br />
im Unternehmen wurden für die unterschiedlichen Fragebogen zusammengefasst:<br />
Q Projektleiter, Qualitätssicherungsbeauftragte, Testmanager und Tester<br />
(Gruppe Tester)<br />
Q Bus<strong>in</strong>ess Analysts, Entwickler, Mitarbeiter aus Betrieb & Support und an<strong>der</strong>e<br />
Mitarbeiter (Gruppe Entwickler)<br />
Q Executive und mittleres Management (Gruppe Management)<br />
Tester/Test<strong>in</strong>genieur<br />
23,1%<br />
Testmanager<br />
21,3%<br />
Entwickler/Software Eng<strong>in</strong>eer<br />
18,9%<br />
Projektleiter/Teamleiter<br />
11,9%<br />
Mittleres Management<br />
9,9%<br />
Qualitätssicherungsbeauftragter<br />
5,9%<br />
Executive Management<br />
3,7%<br />
Bus<strong>in</strong>ess Analyst/Requirements Eng<strong>in</strong>eer 2,1%<br />
Betrieb/Support 1,6%<br />
An<strong>der</strong>e 1,6%<br />
© <strong>Softwaretest</strong>umfrage <strong>2011</strong>: HS Bremen, HS Bremerhaven, FH Köln, ANECON, GTB, STB<br />
Abb. 2<br />
Welcher Rolle ordnen Sie sich mit Ihren Hauptaufgaben zu?<br />
Rollen im Unternehmen<br />
E<strong>in</strong>ige Fragen wurden an alle drei Gruppen gestellt, an<strong>der</strong>e wie<strong>der</strong>um waren<br />
auf die jeweiligen Rollen bezogen, um spezifische Aspekte zu erfragen. Die<br />
Beantwortung <strong>der</strong> Fragen war optional, es konnte also zur nächsten Frage<br />
weiter gegangen werden, ohne diese zu beantworten. Über alle Gruppen<br />
gleich verteilt haben 50% den sehr umfangreichen Fragebogen vollständig<br />
ausgefüllt. Mit <strong>der</strong> vorliegenden Verteilung auf die e<strong>in</strong>zelnen Rollen <strong>in</strong> dem<br />
Unternehmen (Abb. 2) konnte im Wesentlichen die Zielgruppe Praktiker mit<br />
unterschiedlichen Blickw<strong>in</strong>keln auf die Qualitätssicherung (QS) sowie e<strong>in</strong>e<br />
gute Datenbasis für die Auswertung erreicht werden. Um e<strong>in</strong>e Verfälschung<br />
<strong>der</strong> Ergebnisse durch unterschiedliche Interpretation <strong>der</strong> Fachbegriffe zu
6<br />
Die <strong>Umfrage</strong><br />
verh<strong>in</strong><strong>der</strong>n, wurden bei fast je<strong>der</strong> Frage die verwendeten Begriffe mit e<strong>in</strong>er<br />
Def<strong>in</strong>ition nach dem ISTQB ® (International Software Test<strong>in</strong>g Qualifications<br />
Board)-Glossar [ISTQB10] h<strong>in</strong>terlegt.<br />
Durchführung des Risikomanagements<br />
Fast 70% <strong>der</strong> Teilnehmer gaben an, <strong>in</strong> den Projekten Risikomanagement<br />
durchzuführen. Am häufigsten wurde hierbei genannt, Risiken mehrmals<br />
bei Bedarf (38%) o<strong>der</strong> vorab geplant bei wichtigen Projektereignissen (28%)<br />
zu überprüfen. Regelmäßig wöchentlich o<strong>der</strong> monatlich wird nur bei 7%<br />
bzw. 16% <strong>der</strong> Teilnehmer e<strong>in</strong>e Risikoüberprüfung vorgenommen. Dies lässt<br />
den Schluss zu, dass die Risiken durch Projektereignisse (wie Steer<strong>in</strong>g Committee<br />
Meet<strong>in</strong>g, Phasenwechsel etc.) o<strong>der</strong> auf Nachfrage durch den Projektmanager<br />
bzw. L<strong>in</strong>ienverantwortlichen zu e<strong>in</strong>er Neubewertung gebracht<br />
werden.<br />
Abb. 3<br />
Fehlendes Methodenwissen<br />
Zu wenig Ressourcen<br />
Ke<strong>in</strong>e Notwendigkeit<br />
Ke<strong>in</strong>e Zeit<br />
An<strong>der</strong>es<br />
Warum wird ke<strong>in</strong>e Risikoanalyse erstellt?<br />
10,8%<br />
15,0%<br />
17,4%<br />
24,5%<br />
© <strong>Softwaretest</strong>umfrage <strong>2011</strong>: HS Bremen, HS Bremerhaven, FH Köln, ANECON, GTB, STB<br />
Gründe gegen e<strong>in</strong>e Risikobetrachtung<br />
Fragt man die Teilnehmer, die ke<strong>in</strong> Risikomanagement durchführen, nach<br />
dem Grund, so werden häufig fehlendes methodisches Wissen und zu wenige<br />
Ressourcen genannt (Abb. 3). Hier sollten die Unternehmen noch mehr<br />
<strong>in</strong> die Ausbildung <strong>in</strong>vestieren.<br />
32,3%
Vorgehensmodelle <strong>in</strong> <strong>der</strong> <strong>Praxis</strong><br />
Die <strong>Umfrage</strong> 7<br />
Seitdem die Softwareentwicklung mehr und mehr zu e<strong>in</strong>er <strong>in</strong>genieur mäßigen<br />
Diszipl<strong>in</strong> geworden ist und heute oft <strong>in</strong>dustriell und arbeitsteilig <strong>in</strong><br />
verteilten Teams durchgeführt wird, haben sich auch die Methoden und<br />
Vorgehensmodelle weiterentwickelt. Die Notwendigkeit <strong>der</strong> effizienten und<br />
kostengünstigen Softwareproduktion hat auch den <strong>Softwaretest</strong> erreicht.<br />
Wie aber wird <strong>der</strong> <strong>Softwaretest</strong> <strong>in</strong> den Unternehmen methodisch umgesetzt?<br />
Allgeme<strong>in</strong>es V-Modell<br />
Eigenes / angepasstes Phasenmodell<br />
22,9%<br />
W-Modell (Entwicklungs- und Testprozess parallel)<br />
13,8%<br />
Wasserfallmodell<br />
10,0%<br />
V-Modell XT (Modell des Bundes und <strong>der</strong> Län<strong>der</strong>)<br />
8,7%<br />
UP (Unified Process) / RUP (Rational Unified Process) 4,2%<br />
Rapid Prototyp<strong>in</strong>g / Rapid Application Development 0,9%<br />
An<strong>der</strong>es Modell 3,0%<br />
© <strong>Softwaretest</strong>umfrage <strong>2011</strong>: HS Bremen, HS Bremerhaven, FH Köln, ANECON, GTB, STB<br />
Abb. 4<br />
An welchem phasenorientierten Modell zur Softwareentwicklung orientieren Sie sich <strong>in</strong><br />
Ihren Projekten?<br />
Phasenorientierte Vorgehensmodelle<br />
36,5%<br />
Die Mehrheit <strong>der</strong> Teilnehmer (54%) entwickelt nach e<strong>in</strong>em phasenorientierten<br />
Vorgehensmodell. Hiervon orientiert sich mehr als e<strong>in</strong> Drittel an dem<br />
allgeme<strong>in</strong>en V-Modell, UP und RUP spielen ke<strong>in</strong>e große Rolle (Abb. 4). Das<br />
V-Modell XT wird wie zu erwarten <strong>in</strong> den Branchen Kommunen, Rüstung<br />
und Verteidigung häufiger genutzt (ca. 12%), h<strong>in</strong>gegen ist es <strong>in</strong> <strong>der</strong> Forschung<br />
mit e<strong>in</strong>er Nutzung von 2% fast nicht existent.<br />
Die Ergebnisse haben gezeigt, dass <strong>in</strong> e<strong>in</strong>er Umgebung mit phasenorientierten<br />
Vorgehensmodellen die Qualitätssicherungsmaßnahmen <strong>in</strong><br />
den frühen Phasen im Vergleich zur <strong>Umfrage</strong> 1997 zugenommen haben,<br />
aber nach wie vor auf die späten Phasen <strong>in</strong> <strong>der</strong> Softwareentwicklung konzentriert<br />
s<strong>in</strong>d (Abb. 5). Dieser erfreuliche Trend ist aber bei genauerer Betrachtung<br />
noch nicht ausreichend, da <strong>in</strong>sbeson<strong>der</strong>e die Qualitätssicherung<br />
<strong>in</strong> <strong>der</strong> Vorstudie noch nicht umfassend genug e<strong>in</strong>gesetzt wird.
8<br />
Die <strong>Umfrage</strong><br />
Abb. 5<br />
In welchen Phasen werden QS-Maßnahmen e<strong>in</strong>gesetzt?<br />
Vorstudie<br />
Fachkonzept<br />
Systementwurf<br />
Realisierung<br />
Integration<br />
Abnahme<br />
5,1%<br />
3,3%<br />
3,5%<br />
16,0%<br />
13,8%<br />
39,5%<br />
38,7%<br />
58,8%<br />
60,7%<br />
84,0%<br />
87,0%<br />
90,1%<br />
Zustimmung Ablehnung<br />
© <strong>Softwaretest</strong>umfrage <strong>2011</strong>: HS Bremen, HS Bremerhaven, FH Köln, ANECON, GTB, STB<br />
Qualitätssicherung <strong>in</strong> phasenorientierten Vorgehensmodellen<br />
Mehr als e<strong>in</strong> Drittel <strong>der</strong> Befragten stimmte zu, QS-Maßnahmen bereits <strong>in</strong><br />
<strong>der</strong> Vorstudie e<strong>in</strong>zusetzen, dies war 1997 noch bei nur e<strong>in</strong>em Viertel <strong>der</strong><br />
Fall. Jedoch ist <strong>der</strong> Anteil jener, die Qualitätssicherung <strong>in</strong> dieser Phase eher<br />
nicht e<strong>in</strong>setzen, mit ca. 39% etwa gleich groß wie die Zustimmung. Auch bei<br />
dem Fachkonzept geben heute fast 60% (1997: 45%) an, QS-Maßnahmen<br />
anzuwenden. Ab <strong>der</strong> Phase Realisierung ist – über alle Branchen h<strong>in</strong>weg<br />
– die Qualitätssicherung gesetzt. Vergleicht man die Branchen Automotive,<br />
Banken und Luft-/Raumfahrt, zeigen sich Unterschiede: So werden <strong>in</strong><br />
<strong>der</strong> Luft- und Raumfahrt QS-Maßnahmen sehr viel häufiger <strong>in</strong> den frühen<br />
Phasen e<strong>in</strong>gesetzt als <strong>in</strong> an<strong>der</strong>en Branchen. In <strong>der</strong> Automobilbranche setzt<br />
die Qualitätssicherung meist etwas später e<strong>in</strong>, liegt aber diesbezüglich<br />
noch vor den Banken, die sich im Mittelfeld bef<strong>in</strong>den. Insgesamt ist dieses<br />
Ergebnis nicht überraschend und e<strong>in</strong> Trend zum frühzeitigen E<strong>in</strong>satz von<br />
QS-Maßnahmen ist erkennbar.<br />
Test und Qualitätssicherung <strong>in</strong> agilen Projekten<br />
Die agilen Vorgehensmodelle s<strong>in</strong>d <strong>in</strong> <strong>der</strong> <strong>Umfrage</strong> bereits mit e<strong>in</strong>em Viertel<br />
vertreten, wobei hier Scrum mit etwa 57% klarer Favorit ist. Kanban und XP<br />
nehmen nur e<strong>in</strong>en kle<strong>in</strong>en Anteil e<strong>in</strong>, dafür nutzt e<strong>in</strong> Viertel <strong>der</strong> Anwen<strong>der</strong>
Die <strong>Umfrage</strong> 9<br />
eigene agile Vorgehensmodelle (Abb. 6). Arbeitet knapp über die Hälfte <strong>der</strong><br />
Teilnehmer noch nach wie vor mit e<strong>in</strong>em sequenziellen Phasenmodell, so<br />
überrascht doch die hohe Anzahl von 17%, die gar ke<strong>in</strong> explizites Vorgehensmodell<br />
verwenden.<br />
Abb. 6<br />
An welchem agilen Vorgehensmodell zur Softwareentwicklung orientieren Sie sich <strong>in</strong><br />
Ihren Projekten?<br />
Scrum<br />
Eigenes / angepasstes Modell<br />
Feature Driven Development (FDD)<br />
eXtreme Programm<strong>in</strong>g (XP)<br />
Kanban<br />
Crystal<br />
An<strong>der</strong>es Modell<br />
2,4%<br />
0,4%<br />
5,2%<br />
4,0%<br />
4,0%<br />
27,0%<br />
© <strong>Softwaretest</strong>umfrage <strong>2011</strong>: HS Bremen, HS Bremerhaven, FH Köln, ANECON, GTB, STB<br />
Agile Vorgehensmodelle<br />
Unterschiede h<strong>in</strong>sichtlich Branchen und Firmengröße<br />
57,0%<br />
Wenig überraschend war, dass die Branchen Rüstung und Verteidigung am<br />
wenigsten agile Projekte e<strong>in</strong>setzen, wo h<strong>in</strong>gegen Kommunen immerh<strong>in</strong> zu<br />
fast e<strong>in</strong>em Drittel auf Agilität setzen. Die meisten agilen Projekte werden<br />
<strong>in</strong> <strong>der</strong> Medien-, Konsumgüter- und Unterhaltungsbranche durchgeführt<br />
(35%–38%).<br />
H<strong>in</strong>sichtlich <strong>der</strong> Firmengröße gibt es deutliche Unterschiede. So setzen<br />
kle<strong>in</strong>e bis sehr kle<strong>in</strong>e (1-100 Mitarbeiter) Unternehmen zu rund 40% auf<br />
agile Methoden, mittlere Unternehmen (101–1.000 Mitarbeiter) setzen<br />
immer h<strong>in</strong> noch zu ca. 30% auf Agilität. In großen und sehr großen Unternehmen<br />
(>1.001 Mitarbeiter) ist <strong>der</strong> Anteil <strong>der</strong> agilen Projekte noch ger<strong>in</strong>ger,<br />
hier s<strong>in</strong>d es zwischen 17% und 19% (Abb. 7).
10 Die <strong>Umfrage</strong><br />
Abb. 7<br />
Welche Vorgehensmodelle werden bei den unterschiedlichen Unternehmensgrößen e<strong>in</strong>gesetzt?<br />
> 50.000<br />
10.001 -50.000<br />
1.001 -10.000<br />
101 -1.000<br />
51 -100<br />
11 -50<br />
1-10<br />
1,9%<br />
0,8%<br />
1,3%<br />
0,9%<br />
1,7%<br />
1,9%<br />
1,2%<br />
3,4%<br />
2,6%<br />
2,6%<br />
5,4%<br />
5,0%<br />
5,5%<br />
4,0%<br />
4,9%<br />
3,6%<br />
5,5%<br />
8,4%<br />
9,3%<br />
12,2%<br />
Phasenorientiertes Vorgehensmodell Agiles Vorgehensmodell Gar ke<strong>in</strong> explizites Vorgehensmodell<br />
© <strong>Softwaretest</strong>umfrage <strong>2011</strong>: HS Bremen, HS Bremerhaven, FH Köln, ANECON, GTB, STB<br />
Größe des Unternehmens und Vorgehensmodelle<br />
Die Frage, ob im Unternehmen e<strong>in</strong>e selbstständige QS-Gruppe/Abteilung<br />
besteht, verne<strong>in</strong>ten agile Teilnehmer mit 37%, Anwen<strong>der</strong> von phasenorien<br />
tierten Methoden jedoch nur zu 28%. Allerd<strong>in</strong>gs muss diese Antwort<br />
auch mit <strong>der</strong> Firmengröße <strong>in</strong> Relation gesetzt werden, da gerade <strong>in</strong> kle<strong>in</strong>en<br />
Unternehmen, die <strong>in</strong> <strong>der</strong> Regel ke<strong>in</strong>e eigene Qualitätssicherungsabteilung<br />
unterhalten, agile Vorgehensmodelle favorisiert werden.<br />
E<strong>in</strong>b<strong>in</strong>dung des Kunden <strong>in</strong> agilen Projekten<br />
Die E<strong>in</strong>b<strong>in</strong>dung <strong>der</strong> Qualitätssicherung <strong>in</strong> agilen Projekten ist noch nicht abschließend<br />
geklärt. E<strong>in</strong>iges deutet jedoch darauf h<strong>in</strong>, dass zwar die re<strong>in</strong>en<br />
Entwicklungstätigkeiten nach agilen Richtl<strong>in</strong>ien durchgeführt werden, die<br />
QS jedoch noch nicht auf die agilen Methoden abgestimmt wurde.<br />
Es entsteht <strong>der</strong> E<strong>in</strong>druck, dass Agilität noch nicht richtig gelebt wird.<br />
E<strong>in</strong>er <strong>der</strong> Vorteile beim agilen Vorgehen ist die Nähe zum Kunden. So<br />
wäre zu erwarten gewesen, dass <strong>in</strong> agilen Projekten die Mitarbeiter <strong>der</strong><br />
Fachabteilungen besser <strong>in</strong> die QS-Maßnahmen e<strong>in</strong>bezogen werden als <strong>in</strong><br />
16,8%
Die <strong>Umfrage</strong> 11<br />
traditio nellen Projekten. Tatsächlich werden <strong>in</strong> den klassischen phasenorientierten<br />
Projekten die Fachbereiche beispielsweise zu fast 50% <strong>in</strong> die<br />
Test fall er stellung e<strong>in</strong>bezogen, <strong>in</strong> den agilen Projekten jedoch nur zu 33%.<br />
Auch Reviews werden <strong>in</strong> agilen Projekten nur <strong>in</strong> 57% <strong>der</strong> Antworten von<br />
den Fachabteilungen durchgeführt, während es bei den phasenorientierten<br />
Projekten immerh<strong>in</strong> 72% s<strong>in</strong>d. Das sche<strong>in</strong>t daran zu liegen, dass es noch<br />
ke<strong>in</strong> e<strong>in</strong>heitliches Rollenverständnis für den Product Owner gibt.<br />
Abb. 8<br />
Welche Praktiken agiler Vorgehensmodelle haben e<strong>in</strong>e hohe Bedeutung für Sie <strong>in</strong> H<strong>in</strong>blick auf<br />
Qualitätssicherung?<br />
Geme<strong>in</strong>same Aufwandschätzung<br />
Storycards (User Stories)<br />
Standup-Meet<strong>in</strong>g<br />
Testgetriebene Softwareentwicklung<br />
Product Backlog/Spr<strong>in</strong>t Backlog<br />
Retrospektive<br />
Refaktorisierung<br />
Pair Programm<strong>in</strong>g<br />
Auswertungen <strong>der</strong> Effektivität<br />
Zentrale Storyboards<br />
Timebox<strong>in</strong>g<br />
Collective Code Ownership<br />
An<strong>der</strong>e Praktiken<br />
29,8%<br />
26,4%<br />
24,4%<br />
22,5%<br />
22,1%<br />
20,2%<br />
39,9%<br />
50,4%<br />
50,4%<br />
49,2%<br />
46,9%<br />
46,1%<br />
© <strong>Softwaretest</strong>umfrage <strong>2011</strong>: HS Bremen, HS Bremerhaven, FH Köln, ANECON, GTB, STB<br />
Praktiken agiler Vorgehensmodelle<br />
Die Frage, welche Praktiken <strong>der</strong> agilen Vorgehensmodelle h<strong>in</strong>sichtlich <strong>der</strong><br />
QS e<strong>in</strong>e hohe Bedeutung haben, lieferte überraschende Antworten (Abb. 8).<br />
Nur etwa die Hälfte <strong>der</strong> Teilnehmer, die agiles Vorgehen nutzen, haben Test-<br />
Driven Development, Stand-up-Meet<strong>in</strong>gs, Retrospektiven o<strong>der</strong> User Stories<br />
als für die QS bedeutsame Praktiken genannt.<br />
Insofern s<strong>in</strong>d die Ergebnisse unerwartet, da e<strong>in</strong>e stärkere E<strong>in</strong>b<strong>in</strong>dung<br />
<strong>der</strong> Vorteile agiler Vorgehensmodelle, wie beispielsweise die Nähe zu den<br />
Fachbereichen bzw. Kunden o<strong>der</strong> das Erkennen guter Praktiken als QS-Maßnahme,<br />
erwartet wurde.<br />
In den agilen Projekten gaben 77% <strong>der</strong> Teilnehmer an, dass Unit-Tests<br />
Teil je<strong>der</strong> Iteration s<strong>in</strong>d. Nur wenig darunter liegt die Durchdr<strong>in</strong>gung je<strong>der</strong><br />
60,9%
12 Die <strong>Umfrage</strong><br />
Iteration mit Integrationstests. Hier wurden ebenfalls höhere Zustimmungswerte<br />
– bei Befolgung <strong>der</strong> re<strong>in</strong>en agilen Lehre – erwartet.<br />
Bei e<strong>in</strong>er genaueren Betrachtung e<strong>in</strong>es Werkzeuge<strong>in</strong>satzes werden auch<br />
Unterschiede bei den jeweiligen Vorgehensweisen deutlich. Liegt die werkzeugunterstützte<br />
Ausführung etwa gleich auf, so werden <strong>in</strong> agilen Projekten<br />
mit 38% deutlich weniger Werkzeuge für die Spezifikation von Testfällen als<br />
<strong>in</strong> klassisch phasenorientierten Projekten (53%) e<strong>in</strong>gesetzt.<br />
17% gaben an, ke<strong>in</strong>em für die Durchführung von Testaktivitäten festgelegten<br />
Prozess zu folgen, da sie agil entwickeln und die Testaktivitäten<br />
eher spontan bestimmen. Hier gibt es für die agilen Projekte noch Verbesserungspotenzial.<br />
Verantwortung für die Qualitätssicherung<br />
Fragt man die Teilnehmer, wer <strong>in</strong> den Projekten für die QS verantwortlich<br />
ist, so werden <strong>in</strong> den agilen Projekten die Entwickler sehr viel häufiger<br />
(50%) genannt, bei den phasenorientierten Projekten s<strong>in</strong>d dies nur 30%.<br />
Deutlich ist <strong>der</strong> Unterschied auch zu sehen, wenn man die Rollen Projektmanager,<br />
Testmanager und QS-Beauftragter betrachtet. Alle diese Rollen<br />
haben <strong>in</strong> agilen Projekten h<strong>in</strong>sichtlich <strong>der</strong> QS e<strong>in</strong>e ger<strong>in</strong>gere Bedeutung als<br />
<strong>in</strong> phasen orientierten Projekten. Dies ist nicht verwun<strong>der</strong>lich, da die agilen<br />
Projekte den Entwicklern hier e<strong>in</strong>e höhere Verantwortung auch h<strong>in</strong>sichtlich<br />
<strong>der</strong>er Arbeitsergebnisse zuspricht.<br />
Überraschend war jedoch, dass <strong>in</strong> den agilen Projekten die Tester deutlich<br />
häufiger (48%) als Verantwortliche für die QS genannt werden als <strong>in</strong><br />
phasenorientierten Projekten (36%). Die These, dass agile Projekte die Rolle<br />
des expliziten Testers überflüssig mache, kann somit nicht bestätigt werden.<br />
Agilität und Qualität<br />
Betrachtet man die Qualität unter dem Gesichtspunkt <strong>der</strong> Fehler im Betrieb,<br />
so gibt es kaum e<strong>in</strong>en Unterschied zwischen phasenorientierten und agilen<br />
Methoden (Abb. 9). Beide Ansätze führen zu gleichen Anteilen an, Auslieferungen<br />
ohne schwerwiegende Fehler o<strong>der</strong> mit nur wenigen Fehlern zu
Die <strong>Umfrage</strong> 13<br />
erreichen. Zu viele schwerwiegende Fehler treten bei beiden Methoden<br />
gleich bei unter 3% auf.<br />
Abb. 9<br />
zu viele schwerwiegende Fehler auf<br />
e<strong>in</strong>ige schwerwiegende Fehler auf<br />
wenige Fehler noch auf<br />
ke<strong>in</strong>e schwerwiegenden Fehler mehr auf<br />
ke<strong>in</strong>e E<strong>in</strong>schätzung möglich<br />
Nach Auslieferung treten ...<br />
2,9%<br />
2,5%<br />
5,2%<br />
2,6%<br />
5,3%<br />
10,5%<br />
13,2%<br />
18,1%<br />
20,3%<br />
26,9%<br />
28,8%<br />
27,6%<br />
46,9%<br />
45,8%<br />
43,4%<br />
Phasenorientiertes Vorgehensmodell Agiles Vorgehensmodell Gar ke<strong>in</strong> explizites Vorgehensmodell<br />
© <strong>Softwaretest</strong>umfrage <strong>2011</strong>: HS Bremen, HS Bremerhaven, FH Köln, ANECON, GTB, STB<br />
E<strong>in</strong>schätzung <strong>der</strong> Fehler nach Auslieferung<br />
Große Unterschiede zeigen sich aber, wenn man die Antworten <strong>der</strong>er, die<br />
we<strong>der</strong> e<strong>in</strong> phasenorientiertes noch agiles Vorgehensmodell nutzen, vergleicht.<br />
Hier s<strong>in</strong>d die Auslieferungen, die zu viele schwerwiegende Fehler<br />
enthalten, mit 13% doch wesentlich höher. Auch haben diese Projekte nur<br />
zu 10% Auslieferungen, die ke<strong>in</strong>e schwerwiegenden Fehler mehr enthalten,<br />
gegenüber knapp 20% bei den agilen und phasenorientierten Projekten.<br />
Festzuhalten ist also, dass we<strong>der</strong> das agile noch das phasenorientierte<br />
Modell e<strong>in</strong>en Vorsprung h<strong>in</strong>sichtlich <strong>der</strong> Auslieferungsqualität hat. Aber<br />
ohne e<strong>in</strong> explizites Vorgehensmodell ist die Qualität deutlich schlechter.
14 Die <strong>Umfrage</strong><br />
Organisation<br />
Wurde die Frage nach e<strong>in</strong>er eigenen Qualitätssicherungs-Organisationse<strong>in</strong>heit<br />
im Unternehmen 1997 nur von 31% <strong>der</strong> Teilnehmer bejaht, so fällt das<br />
<strong>in</strong> dieser <strong>Umfrage</strong> mit 66% deutlich positiver aus (Abb. 10).<br />
Abb. 10<br />
Ja<br />
Ne<strong>in</strong><br />
Existiert <strong>in</strong> Ihrem Unternehmen e<strong>in</strong>e selbständige<br />
Qualitätssicherungsgruppe/-abteilung?<br />
31,0%<br />
34,3%<br />
<strong>Umfrage</strong> 1997 <strong>Umfrage</strong> <strong>2011</strong><br />
© <strong>Softwaretest</strong>umfrage <strong>2011</strong>: HS Bremen, HS Bremerhaven, FH Köln, ANECON, GTB, STB<br />
63,0%<br />
Eigenständige Qualitätssicherungsabteilung (Vergleich 1997/<strong>2011</strong>)<br />
Bei 44% <strong>der</strong> Teilnehmer ist diese Gruppe dem Qualitätsmanagement zugeordnet,<br />
bei 21% <strong>der</strong> Softwareentwicklung und bei 12% den Fachabteilungen.<br />
Fragt man die Teilnehmer nach dem prozentualen Anteil <strong>der</strong> Personen<br />
<strong>in</strong> <strong>der</strong> Qualitätssicherung im Vergleich zu allen <strong>in</strong> <strong>der</strong> Softwareentwicklung<br />
beschäftigten Personen, so zeigen sich Unterschiede zu 1997.<br />
E<strong>in</strong> Viertel <strong>der</strong> Befragten gab an, dass 2–5% <strong>der</strong> Mitarbeiter <strong>der</strong> Softwareentwicklung<br />
mit Qualitätssicherungsaufgaben betraut s<strong>in</strong>d (1997:<br />
19%). Waren 1997 bei fast e<strong>in</strong>em Viertel <strong>der</strong> Teilnehmer zwischen 30–50%<br />
<strong>der</strong> Mitarbeiter <strong>der</strong> Softwareentwicklungsabteilungen <strong>in</strong> <strong>der</strong> QS beschäftigt,<br />
so s<strong>in</strong>d heute nur noch 8,2% gleicher Ansicht. Insgesamt hat sich <strong>der</strong><br />
Anteil leicht erhöht, wobei <strong>der</strong> Schwerpunkt bei 5–30% liegt (Abb. 11).<br />
65,7%
40-50%<br />
>30-40%<br />
>20-30%<br />
>10-20%<br />
>5-10%<br />
>2-5%<br />
0-2%<br />
Abb. 11<br />
Wie viel Prozent <strong>der</strong> Mitarbeiter <strong>der</strong> Softwareentwicklung s<strong>in</strong>d <strong>in</strong> <strong>der</strong> QS tätig?<br />
3,0%<br />
4,0%<br />
4,2%<br />
8,0%<br />
12,2%<br />
13,0%<br />
13,0%<br />
18,1%<br />
17,0%<br />
16,4%<br />
<strong>Umfrage</strong> 1997 <strong>Umfrage</strong> <strong>2011</strong><br />
19,0%<br />
21,0%<br />
21,2%<br />
Die <strong>Umfrage</strong> 15<br />
25,0%<br />
© <strong>Softwaretest</strong>umfrage <strong>2011</strong>: HS Bremen, HS Bremerhaven, FH Köln, ANECON, GTB, STB<br />
Mitarbeiter <strong>in</strong> <strong>der</strong> QS (Vergleich 1997/<strong>2011</strong>)<br />
In <strong>der</strong> <strong>Umfrage</strong> von 1997 wurde auch gefragt, wer die Tests auf den Teststufen<br />
durchführt. Damals haben hauptsächlich Entwickler die Tests durchgeführt<br />
und ausgebildete Tester spielten e<strong>in</strong>e untergeordnete Rolle. Wie sieht<br />
dies nun heute aus?<br />
Immer noch sehen 86% <strong>der</strong> Teilnehmer die Entwickler <strong>in</strong> <strong>der</strong> Testdurchführung,<br />
aber mit e<strong>in</strong>em großen Sprung von 26% auf 77% haben die ausgebildeten<br />
Tester deutlich aufgeholt (Abb. 12). Auch bei <strong>der</strong> Testfallerstellung<br />
s<strong>in</strong>d Verän<strong>der</strong>ungen zu beobachten. Die Testfälle werden bei 78% (1997:<br />
35%) <strong>der</strong> Befragten von Testern, zu 56% (1997: 60%) von Entwicklern und zu<br />
40% (1997: 54%) von Mitarbeitern <strong>der</strong> Fachabteilungen erstellt. Externe Berater<br />
werden hierzu nur von 7% (1997: 10%) <strong>der</strong> Unternehmen e<strong>in</strong>gesetzt.<br />
Dies zeigt deutlich, dass die methodische Testfallerstellung durch hierfür<br />
qualifizierte Tester zugenommen hat.<br />
E<strong>in</strong> e<strong>in</strong>deutiger Trend zum Outsourc<strong>in</strong>g hat sich nicht bestätigt. So setzen<br />
nur 15% externe Dienstleister für die Testdurchführung e<strong>in</strong>. Bei <strong>der</strong> Frage,<br />
wer für die Qualitätssicherung <strong>in</strong> den Projekten verantwortlich ist, gaben<br />
sogar nur 6% <strong>der</strong> Befragten an, dies an externe Unternehmen zu übergeben.<br />
Hier wurde e<strong>in</strong> erheblich höherer Anteil erwartet.
16 Die <strong>Umfrage</strong><br />
Abb. 12<br />
Folgende Personengruppen führen die Tests <strong>der</strong> Teststufen <strong>in</strong> den Projekten durch:<br />
Zukünftige Anwen<strong>der</strong>/Kunden<br />
Mitarbeiter aus den Fachabteilungen<br />
Externe Dienstleister<br />
Entwickler<br />
Ausgebildete Tester<br />
12,0%<br />
15,1%<br />
26,0%<br />
<strong>Umfrage</strong> 1997 <strong>Umfrage</strong> <strong>2011</strong><br />
45,0%<br />
48,3%<br />
51,0%<br />
60,5%<br />
© <strong>Softwaretest</strong>umfrage <strong>2011</strong>: HS Bremen, HS Bremerhaven, FH Köln, ANECON, GTB, STB<br />
Durchführung <strong>der</strong> Tests (Vergleich 1997/<strong>2011</strong>)<br />
Testprozess und Maßnahmen <strong>der</strong> Qualitätssicherung<br />
70,0%<br />
77,2%<br />
85,7%<br />
Mit dem ISTQB ® -Testprozess gibt es e<strong>in</strong>en fundamentalen und sehr gut<br />
beschriebenen Testprozess mit den Aktivitäten Planung und Steuerung,<br />
Analyse und Design, Realisierung und Durchführung, Bewertung und Berichterstattung<br />
sowie den Abschluss <strong>der</strong> Testaktivitäten. Wird dieser aber<br />
auch <strong>in</strong> <strong>der</strong> <strong>Praxis</strong> verwendet? 40% <strong>der</strong> Befragten gaben an, für die Durchführung<br />
von Testaktivitäten e<strong>in</strong>en eigenen Testprozess zu verwenden. Den<br />
ISTQB ® -Prozess verwenden 14%, den vom e<strong>in</strong>gesetzten Vorgehensmodell<br />
vorgeschriebenen Prozess 17%. Überraschend und erschreckend zugleich<br />
ist, dass rund 30% ke<strong>in</strong>em festgelegten Prozess folgen. E<strong>in</strong>em Audit unterziehen<br />
ca. 40% <strong>der</strong> Teilnehmer ihren Prozess. Hierbei werden TMMi ® mit 4%<br />
und TPI ® /TPI Next ® mit 17% genannt. E<strong>in</strong> an<strong>der</strong>es Referenzmodell wird von<br />
25% <strong>der</strong> Befragten bevorzugt. Insgesamt ist dies e<strong>in</strong> erfreuliches Ergebnis,<br />
da doch fast die Hälfte <strong>der</strong> Unternehmen, die e<strong>in</strong>en Testprozess haben, diesen<br />
auch auditieren.
Testfallerstellung<br />
Die <strong>Umfrage</strong> 17<br />
Die systematische Testfallerstellung und Testdatendef<strong>in</strong>ition ist weit verbreitet.<br />
Fast die Hälfte <strong>der</strong> Teilnehmer aus <strong>der</strong> Gruppe Tester gab an, dass zur<br />
Vorbereitung des Tests e<strong>in</strong> Review und e<strong>in</strong>e Analyse <strong>der</strong> Testbasis und des<br />
Testobjekts auf Testbarkeit durchgeführt werden. Mehr als 80% gaben an,<br />
Testfälle zu erstellen, und jeweils rund 60% gaben an, Testdatendef<strong>in</strong>ition<br />
und Testdatenerstellung durchzuführen.<br />
mit e<strong>in</strong>er<br />
formalen<br />
textuellen<br />
Sprache<br />
beschrieben<br />
mit Hilfe<br />
von<br />
standardisierten<br />
Formularen<br />
Abb. 13<br />
beschrieben<br />
frei verbal/<br />
textuell<br />
beschrieben<br />
<strong>Umfrage</strong> 1997<br />
<strong>Umfrage</strong> <strong>2011</strong><br />
<strong>Umfrage</strong> 1997<br />
<strong>Umfrage</strong> <strong>2011</strong><br />
<strong>Umfrage</strong> 1997<br />
<strong>Umfrage</strong> <strong>2011</strong><br />
13,0%<br />
14,9%<br />
Die Testfälle werden...<br />
30,0%<br />
37,8%<br />
53,0%<br />
49,9%<br />
63,0%<br />
61,7%<br />
40,0%<br />
36,9%<br />
15,0%<br />
22,5%<br />
Zustimmung Ablehnung<br />
© <strong>Softwaretest</strong>umfrage <strong>2011</strong>: HS Bremen, HS Bremerhaven, FH Köln, ANECON, GTB, STB<br />
Testfallbeschreibung (Vergleich 1997/<strong>2011</strong>)<br />
Die Testfälle werden immer noch zu knapp 50% frei verbal/textuell beschrieben<br />
(Abb. 13). Formale Sprachen werden auch heute noch nur zu 15%<br />
benutzt, hier haben sich diese Ansätze nicht <strong>in</strong> <strong>der</strong> <strong>Praxis</strong> etabliert. Fast 50%<br />
<strong>der</strong> Teilnehmer unterziehen die Testfälle e<strong>in</strong>em Review.<br />
Erwartete Testergebnisse stehen zu 72% vor <strong>der</strong> Testdurchführung zur<br />
Verfügung. Dieses Ergebnis ist e<strong>in</strong>e positive Überraschung, allerd<strong>in</strong>gs werden<br />
nur knapp 60% auch für spätere Tests bereitgestellt. Wie werden tatsächliche<br />
und erwartete Ergebnisse verglichen? Etwa 50% <strong>der</strong> Teilnehmer<br />
führen den Vergleich überwiegend manuell durch. Daneben geben 22%<br />
an, dass <strong>der</strong> Vergleich <strong>in</strong> <strong>der</strong> Regel mit Hilfe von Werkzeugen automatisiert<br />
durchgeführt wird. Allerd<strong>in</strong>gs lehnen 36% den automatischen Vergleich ab.
18 Die <strong>Umfrage</strong><br />
Die Effektivität <strong>der</strong> Testfälle schätzen 61% als hoch e<strong>in</strong>, da e<strong>in</strong> Großteil<br />
<strong>der</strong> Fehler im Test gefunden wird. Als sehr hoch (fast alle Fehler werden gefunden)<br />
schätzen 10% <strong>der</strong> Teilnehmer die Effektivität ihrer Testfälle e<strong>in</strong>, doppelt<br />
so viele (22%) schätzen sie als mittel (e<strong>in</strong>ige Fehler werden gefunden)<br />
e<strong>in</strong>. Nur 4% me<strong>in</strong>en, dass die Testfälle zu wenige Fehler f<strong>in</strong>den und daher die<br />
Effektivität schlecht sei.<br />
Testdaten<br />
Der Datenschutz muss heute von den Firmen sehr ernst genommen werden.<br />
Daher überrascht doch, dass immer noch 15% <strong>der</strong> Befragten angeben,<br />
mit den Orig<strong>in</strong>aldaten aus <strong>der</strong> Produktion zu testen (Abb. 14). E<strong>in</strong>e (anonymisierte)<br />
Kopie <strong>der</strong> Produktionsdaten nutzen 23% und von 30% <strong>der</strong> Befragten<br />
werden die Testdaten ausführlich dokumentiert. Auch geben mehr als<br />
die Hälfte (58%) <strong>der</strong> Befragten an, <strong>in</strong> den Projekten nicht explizit zwischen<br />
<strong>der</strong> Testfallerstellung und <strong>der</strong> Erstellung <strong>der</strong> zugehörigen Testdaten zu unterscheiden.<br />
Abb. 14<br />
werden <strong>in</strong> e<strong>in</strong>er Testdatenbibliothek<br />
zusammengefasst<br />
s<strong>in</strong>d die Orig<strong>in</strong>alproduktionsdaten<br />
s<strong>in</strong>d e<strong>in</strong>e (anonymisierte) Kopie <strong>der</strong><br />
Produktionsdaten<br />
werden mit standardisierten<br />
Formularen erfasst<br />
werden ausführlich dokumentiert<br />
Die Testdaten ...<br />
14,9%<br />
23,4%<br />
22,5%<br />
22,4%<br />
39,8%<br />
29,9%<br />
39,7%<br />
53,4%<br />
56,4%<br />
53,5%<br />
Zustimmung Ablehnung<br />
© <strong>Softwaretest</strong>umfrage <strong>2011</strong>: HS Bremen, HS Bremerhaven, FH Köln, ANECON, GTB, STB<br />
Testdatenmanagement
Testumgebung<br />
Die <strong>Umfrage</strong> 19<br />
Erfreulich ist, dass mehr als 80% e<strong>in</strong> geson<strong>der</strong>tes Testsystem e<strong>in</strong>setzen. Allerd<strong>in</strong>gs<br />
wird von mehr als <strong>der</strong> Hälfte das Entwicklungssystem und von 22%<br />
immer noch das Produktivsystem für das Testen e<strong>in</strong>gesetzt (Abb. 15).<br />
Abb. 15<br />
Produktivsystem<br />
Pre-Live-System<br />
Integrationssystem<br />
Entwicklungssystem<br />
Geson<strong>der</strong>tes Testsystem<br />
Welche Systemumgebungen setzen Sie <strong>in</strong> Ihren Projekten für das Testen e<strong>in</strong>?<br />
6,1%<br />
24,1%<br />
57,6%<br />
34,0%<br />
45,2%<br />
51,4%<br />
28,9%<br />
58,6%<br />
18,6%<br />
Zustimmung Ablehnung<br />
© <strong>Softwaretest</strong>umfrage <strong>2011</strong>: HS Bremen, HS Bremerhaven, FH Köln, ANECON, GTB, STB<br />
Testumgebung<br />
84,1%<br />
Für die Adm<strong>in</strong>istration <strong>der</strong> Testumgebung s<strong>in</strong>d unterschiedliche Personenkreise<br />
oft gleichzeitig zuständig (Abb. 16). Dabei werden Tester aus dem<br />
Projektteam, die zentrale Infrastruktur und die Entwickler aus dem Projektteam<br />
von jeweils ca. 50% <strong>der</strong> Befragten genannt. Hierbei wird <strong>in</strong> den Unternehmen<br />
vermutlich zwischen <strong>der</strong> Adm<strong>in</strong>istration <strong>der</strong> Testdaten, den Testobjekten<br />
und <strong>der</strong> Basiskomponenten (Hardware, Betriebssystem, Datenbank,<br />
Webserver etc.) unterschieden.
20 Die <strong>Umfrage</strong><br />
Zentrale Infrastruktur / IT-Management<br />
Abb. 16<br />
Testende<br />
Wer ist für die Adm<strong>in</strong>istration <strong>der</strong> Testumgebung zuständig?<br />
Tester aus dem Projektteam<br />
Entwickler aus dem Projektteam<br />
Mitarbeiter aus <strong>der</strong> QS-Abteilung<br />
Kunde / Fachabteilung<br />
Externer Dienstleister<br />
An<strong>der</strong>e<br />
4,5%<br />
11,5%<br />
9,2%<br />
25,4%<br />
© <strong>Softwaretest</strong>umfrage <strong>2011</strong>: HS Bremen, HS Bremerhaven, FH Köln, ANECON, GTB, STB<br />
Adm<strong>in</strong>istration <strong>der</strong> Testumgebung<br />
52,0%<br />
48,8%<br />
52,9%<br />
Kennzahlen wie Abdeckung <strong>der</strong> Anfor<strong>der</strong>ungen (75%), Durchführungsrate<br />
<strong>der</strong> Testfälle (60%) o<strong>der</strong> Codeabdeckung (25%) werden u.a. von den Teilnehmern<br />
zur Teststeuerung e<strong>in</strong>gesetzt. Hier lässt sich auch e<strong>in</strong>e Systematik erkennen<br />
und die Kriterien werden zu ca. 86% meist o<strong>der</strong> immer e<strong>in</strong>gehalten.<br />
Abb. 17<br />
Zur Beendigung <strong>der</strong> Tests werden folgende Kriterien verwendet ...<br />
Alle geplanten Testfälle s<strong>in</strong>d auszuführen<br />
Jede Anfor<strong>der</strong>ung wird m<strong>in</strong>destens e<strong>in</strong>mal getestet<br />
Der Auslieferungszeitpunkt ist erreicht<br />
Die gefor<strong>der</strong>ten Werte <strong>der</strong><br />
Kennzahlen/Metriken s<strong>in</strong>d erreicht<br />
Das vorgesehene Testbudget ist ausgeschöpft<br />
Für das Vertrauen <strong>in</strong> die Software s<strong>in</strong>d<br />
ausreichend Fehler gefunden worden<br />
13,9%<br />
19,0%<br />
26,1%<br />
22,5%<br />
39,7%<br />
33,9%<br />
56,4%<br />
58,9%<br />
65,9%<br />
70,0%<br />
Zustimmung Ablehnung<br />
© <strong>Softwaretest</strong>umfrage <strong>2011</strong>: HS Bremen, HS Bremerhaven, FH Köln, ANECON, GTB, STB<br />
Testendekriterien<br />
77,8%<br />
84,4%
Die <strong>Umfrage</strong> 21<br />
Lässt dies auf e<strong>in</strong>e gute Reife des Testprozesses schließen, so überrascht<br />
doch, dass immer noch mehr als die Hälfte <strong>der</strong> Teilnehmer die Tests beenden,<br />
wenn <strong>der</strong> Auslieferungszeitpunkt erreicht ist, und immerh<strong>in</strong> noch e<strong>in</strong><br />
Viertel, wenn das Testbudget ausgeschöpft ist (Abb. 17). Hier lässt sich erkennen,<br />
dass <strong>der</strong> Test nach wie vor als »Puffer« im Projekt geplant ist und bei<br />
Verzögerungen aus den vorherigen Phasen »geopfert« wird.<br />
Regeln <strong>der</strong> Qualitätssicherung<br />
Über die Maßnahmen zur Qualitätssicherung wird bei 40% <strong>der</strong> Teilnehmer<br />
durch Vorschriften/Richtl<strong>in</strong>ien entschieden (Abb. 18). Eigenverantwortlich<br />
von den Projekten werden die Maßnahmen bei 31% <strong>der</strong> Antwortenden festgelegt,<br />
gar nicht explizit geregelt ist es aber nur bei 7%.<br />
Durch Vorschriften/Richtl<strong>in</strong>ien grob geregelt<br />
Eigenverantwortlich von den Projekten<br />
Zw<strong>in</strong>gend nach Vorschriften/Richtl<strong>in</strong>ien durchgeführt<br />
Bis <strong>in</strong>s Detail als Handlungsanleitung beschrieben<br />
Gar nicht explizit geregelt<br />
Abb. 18<br />
Wie wird <strong>in</strong> <strong>der</strong> Regel über die Maßnahmen zur Qualitätssicherung entschieden?<br />
6,8%<br />
6,5%<br />
15,2%<br />
© <strong>Softwaretest</strong>umfrage <strong>2011</strong>: HS Bremen, HS Bremerhaven, FH Köln, ANECON, GTB, STB<br />
Regeln <strong>der</strong> Qualitätssicherung<br />
Die Aufgaben <strong>der</strong> QS s<strong>in</strong>d anerkannt, es steht dafür ausreichend Budget zur<br />
Verfügung. So wird im Durchschnitt 20% des Gesamtbudgets und ebenfalls<br />
20% <strong>der</strong> gesamten Zeit für Qualitätssicherung verwendet und vorab <strong>in</strong> gleicher<br />
Größenordnung pauschal geschätzt. Hier gibt es kaum Unterschiede<br />
zur <strong>Umfrage</strong> von 1997. Fast 60% gaben an, dass das Budget zusammen mit<br />
den an<strong>der</strong>en Aktivitäten <strong>der</strong> Softwareentwicklung <strong>in</strong> e<strong>in</strong>em Gesamtpaket<br />
geplant wird. Nur 7% <strong>der</strong> Teilnehmer planen ke<strong>in</strong> explizites Budget für die<br />
Qualitätssicherung e<strong>in</strong> (Abb. 19).<br />
31,2%<br />
40,3%
22 Die <strong>Umfrage</strong><br />
Abb. 19<br />
Der Aufwand (Budget und Zeit) <strong>der</strong> Qualitätssicherung wird <strong>in</strong> Ihren Projekten ...<br />
zusammen mit an<strong>der</strong>en Aktivitäten<br />
im Gesamtpaket geplant<br />
für die Durchführung <strong>der</strong><br />
Qualitätssicherung <strong>in</strong>sgesamt geplant<br />
für e<strong>in</strong>zelne Maßnahmen <strong>der</strong><br />
Qualitätssicherung geplant<br />
für jedes Dokument separat geplant<br />
an<strong>der</strong>s geplant<br />
nicht geplant<br />
1,7%<br />
3,8%<br />
7,3%<br />
12,0%<br />
16,3%<br />
© <strong>Softwaretest</strong>umfrage <strong>2011</strong>: HS Bremen, HS Bremerhaven, FH Köln, ANECON, GTB, STB<br />
Aufwand für QS<br />
58,9%<br />
40% <strong>der</strong> Teilnehmer gaben an, dass das geplante Budget und die geplante<br />
Zeit für die Qualitätssicherung im Mittel weitgehend e<strong>in</strong>gehalten werden.<br />
Allerd<strong>in</strong>gs gaben auch 18% an, dass das Budget mehr als 50% überschritten<br />
wird (fast e<strong>in</strong> Zehntel gibt sogar 50%–100% an).<br />
In <strong>der</strong> Aufwandschätzung wird an erster Stelle <strong>der</strong> Systemtest (mit 81%)<br />
als wichtiges Element geschätzt, gefolgt von Abnahme- und Integrationstest.<br />
Reviews werden von 23% und Last-/Performancetests von 17% <strong>in</strong> <strong>der</strong><br />
Aufwandsschätzung als unwichtig beurteilt.<br />
Behandlung <strong>der</strong> Fehler<br />
Hohe Zustimmung gab es bei <strong>der</strong> Frage, wie gefundene Fehler behandelt<br />
werden. In <strong>der</strong> Regel wird je<strong>der</strong> gefundene Fehler e<strong>in</strong>er Priorität zugeordnet<br />
und dann entsprechend <strong>der</strong> Fehlerpriorität behoben. Über 70% ordnen die<br />
Fehler Klassen zu. In <strong>der</strong> <strong>Umfrage</strong> von 1997 haben dies nur 55% getan, aber<br />
auch damals wurden die Fehler mit 81% entsprechend <strong>der</strong> Fehlerpriorität<br />
behoben (Abb. 20).
entsprechend se<strong>in</strong>er Priorität behoben<br />
Abb. 20<br />
e<strong>in</strong>er Priorität zugeordnet<br />
e<strong>in</strong>er Fehlerklasse zugeordnet<br />
In <strong>der</strong> Regel wird je<strong>der</strong> gefundene Fehler ….<br />
5,9%<br />
9,0%<br />
17,8%<br />
Zustimmung Ablehnung<br />
© <strong>Softwaretest</strong>umfrage <strong>2011</strong>: HS Bremen, HS Bremerhaven, FH Köln, ANECON, GTB, STB<br />
Fehlerbehandlung<br />
Die <strong>Umfrage</strong> 23<br />
73,9%<br />
71,9%<br />
80,5%<br />
Aufgetretene Fehler werden von 80% <strong>der</strong> Befragten e<strong>in</strong>em Fehlernachtest<br />
unterzogen. Hierbei werden von 70% <strong>der</strong> Teilnehmer nur die fehleraufdeckenden<br />
Testfälle wie<strong>der</strong>holt, von 43% zusätzlich weitere Testfälle aus dem<br />
Umfeld des Fehlers ausgeführt und 23% führen alle Testfälle durch (vollständiger<br />
Regressionstest).<br />
Spezielle Testarten<br />
Fragt man die Teilnehmer, welche speziellen Testarten <strong>in</strong> den Projekten<br />
e<strong>in</strong>gesetzt werden, so werden die Regressionstests an erster Stelle (80%),<br />
gefolgt von Smoke-Tests (60%) genannt. Während Last- und Performancetests<br />
mit knapp unter <strong>der</strong> Hälfte (47%) noch e<strong>in</strong>e große Rolle spielen, werden<br />
Sicherheits- und Penetrationstests nur von knapp e<strong>in</strong>em Viertel (26%)<br />
genannt (Abb. 21). Dies verwun<strong>der</strong>t <strong>in</strong>sofern, als immer wie<strong>der</strong> über Datenmissbrauch<br />
und -diebstahl berichtet wird, hier ist noch mehr Sicherheitsbewusstse<strong>in</strong><br />
angebracht.
24 Die <strong>Umfrage</strong><br />
Abb. 21<br />
Regressionstest<br />
Smoketest<br />
Last- /Performancetest<br />
Migrationstest<br />
Sicherheitstest/Penetrationstest<br />
Welche spezielle Testarten werden <strong>in</strong> Ihren Projekten e<strong>in</strong>gesetzt?<br />
5,8%<br />
18,7%<br />
21,1%<br />
25,1%<br />
26,1%<br />
39,8%<br />
42,5%<br />
47,0%<br />
59,5%<br />
Zustimmung Ablehnung<br />
© <strong>Softwaretest</strong>umfrage <strong>2011</strong>: HS Bremen, HS Bremerhaven, FH Köln, ANECON, GTB, STB<br />
Tests von verschiedenen Testarten<br />
Testwerkzeuge und Automatisierung<br />
80,1%<br />
Die Testwerkzeuge haben sich <strong>in</strong> den letzten Jahren sehr weiterentwickelt<br />
und durch Trendthemen wie Application Lifecycle Management und Agile<br />
Development erheblich an Bedeutung gewonnen. Neue Player s<strong>in</strong>d auf den<br />
Markt gekommen und die etablierten Toolanbieter werden von leistungsfähigen<br />
Open-Source-Werkzeugen herausgefor<strong>der</strong>t. Wie werden die Werkzeuge<br />
aber nun <strong>in</strong> <strong>der</strong> <strong>Praxis</strong> genutzt?<br />
Die Studie hat gezeigt, dass Testwerkzeuge am häufigsten (89%) zur<br />
Ausführung von Testfällen genutzt werden. Zum Vergleich <strong>der</strong> Testfälle mit<br />
den erwarteten Ergebnissen setzen 66% <strong>der</strong> Teilnehmer Werkzeuge e<strong>in</strong>. Das<br />
Spezifizieren <strong>der</strong> Testfälle unterstützt nicht ganz die Hälfte <strong>der</strong> Befragten<br />
mit Werkzeugen, ebenso wie das Aufsetzen e<strong>in</strong>es <strong>in</strong>itialen Zustands des<br />
Testobjekts vor <strong>der</strong> Testausführung. Das Generieren von Testdaten wird von<br />
37%, das Generieren von Testfällen immerh<strong>in</strong> von 32% mit Testwerkzeugen<br />
durchgeführt.<br />
Automation <strong>der</strong> Teststufen<br />
Die Ergebnisse belegen klar, dass die Testautomatisierung auf den Unit-Test<br />
fokussiert ist. S<strong>in</strong>d im Unit-Test über die Hälfte <strong>der</strong> Tests zu 70% und mehr<br />
automatisiert (26% <strong>der</strong> Befragten gaben sogar an, den Unit-Test zu 100%
Die <strong>Umfrage</strong> 25<br />
automatisiert zu haben), so wird <strong>der</strong> Integrationstest immerh<strong>in</strong> noch von<br />
30% <strong>der</strong> Teilnehmer mit 70% und mehr automatisiert. Der Abnahmetest ist<br />
am wenigsten automatisiert und wird von über 40% <strong>der</strong> Befragten vollständig<br />
manuell durchgeführt (Abb. 22).<br />
Abb. 22<br />
Unittest<br />
Integrationstest<br />
Systemtest<br />
Wie hoch ist <strong>der</strong> Grad <strong>der</strong> Automatisierung <strong>in</strong> den verschiedenen Teststufen im<br />
Vergleich zu manuellen Tests?<br />
7,3%<br />
5,1%<br />
25,4%<br />
22,7%<br />
21,4%<br />
Abnahmetest 3,1% 11,8% 9,1%<br />
14,2%<br />
30,7%<br />
16,7%<br />
34,2%<br />
12,1%<br />
41,9%<br />
37,1%<br />
20,5%<br />
41,8%<br />
100% 70/85% 50% 15/30% 0%<br />
© <strong>Softwaretest</strong>umfrage <strong>2011</strong>: HS Bremen, HS Bremerhaven, FH Köln, ANECON, GTB, STB<br />
Grad <strong>der</strong> Testautomatisierung<br />
11,3%<br />
16,2%<br />
17,4%<br />
Überraschend war das Ergebnis, dass auch <strong>in</strong> den agilen Projekten die Testautomation<br />
im Unit-Test nur zu 43% vollständig automatisiert ist. Hier wäre<br />
zu erwarten gewesen, dass fast100% <strong>der</strong> Unit-Tests auto matisiert s<strong>in</strong>d.<br />
Nutzung von Testwerkzeugen<br />
Beim E<strong>in</strong>satz von Testwerkzeugen gibt es kaum e<strong>in</strong>en Unterschied zwischen<br />
den Branchen, jedoch setzen die Entwickler signifikant weniger (51%) Testwerkzeuge<br />
e<strong>in</strong>, als dies bei Testern <strong>der</strong> Fall ist (70%) (Abb. 23). Bei den agilen<br />
Projekten ist <strong>der</strong> Anteil <strong>der</strong> Entwickler, die Testwerkzeuge benutzen, höher<br />
(71%), es wurde hier jedoch e<strong>in</strong> noch höheres Ergebnis erwartet.
26 Die <strong>Umfrage</strong><br />
Die Studie hat gezeigt, dass die Entwickler als potenzielle Zielgruppe<br />
von den Testwerkzeugherstellern noch zu wenig adressiert werden.<br />
Ja, <strong>in</strong> den meisten Projekten<br />
Abb. 23<br />
Ja, <strong>in</strong> jedem Projekt<br />
Ja, <strong>in</strong> manchen Projekten<br />
Werden <strong>in</strong> Ihrem Unternehmen Testwerkzeuge e<strong>in</strong>gesetzt?<br />
Ne<strong>in</strong><br />
9,9%<br />
21,1%<br />
20,8%<br />
20,7%<br />
32,7%<br />
30,0%<br />
28,2%<br />
Tester Entwickler<br />
© <strong>Softwaretest</strong>umfrage <strong>2011</strong>: HS Bremen, HS Bremerhaven, FH Köln, ANECON, GTB, STB<br />
E<strong>in</strong>satz von Testwerkeugen<br />
Prüf- und Testentwurfsverfahren<br />
36,6%<br />
Bei den statischen Testentwurfsverfahren führt <strong>der</strong> Schreibtischtest. Fast<br />
70% <strong>der</strong> Befragten gaben an, <strong>in</strong>formelle Reviews e<strong>in</strong>zusetzen. Technische<br />
Reviews des Dokuments/Programmcodes werden von 57% <strong>der</strong> Teilnehmer<br />
durchgeführt. Walkthrough und Peer-Review nutzen die Befragten zu über<br />
40%. Die Zahlen s<strong>in</strong>d konform zu den Erwartungen.<br />
Werkzeuggestützt werden vor allem Prüfungen auf Programmierkonventionen<br />
bzw. -standards/Codierungsregeln durchgeführt. Die Erzeugung<br />
von Codemetriken, statische Analysen <strong>der</strong> Softwarearchitektur und<br />
Kontroll fluss analysen werden mit rund 20% durchgeführt. Allerd<strong>in</strong>gs setzen<br />
auch fast 40% <strong>der</strong> Befragten überhaupt ke<strong>in</strong>e Werkzeuge zur statischen<br />
Analyse e<strong>in</strong> (Abb. 24).
Abb. 24<br />
Welche Verfahren <strong>der</strong> werkzeuggestützten statischen Analyse werden <strong>in</strong> Ihrem Unternehmen<br />
e<strong>in</strong>gesetzt?<br />
Prüfungen auf Programmierkonventionen<br />
bzw. -standards/Codierungsregeln<br />
Erzeugung von Codemetriken<br />
Statische Analysen <strong>der</strong> Softwarearchitektur<br />
Kontrollflussanalysen<br />
Datenflussanalysen<br />
Statische Analysen von Texten/Dokumenten<br />
Statische Analysen von Modellen<br />
An<strong>der</strong>e werkzeuggestützte Statische Analysen<br />
12,6%<br />
13,2%<br />
17,0%<br />
16,1%<br />
22,0%<br />
19,5%<br />
25,1%<br />
Ke<strong>in</strong>e werkzeuggestützte Statische Analyse<br />
37,9%<br />
© <strong>Softwaretest</strong>umfrage <strong>2011</strong>: HS Bremen, HS Bremerhaven, FH Köln, ANECON, GTB, STB<br />
Werkzeuggestützte statische Analyse<br />
Die <strong>Umfrage</strong> 27<br />
Vertiefende Fragen zu Testmethoden wurden nur noch an die Gruppe <strong>der</strong><br />
Tester gerichtet, bei denen dieses Know-how vermutet wurde. So setzt<br />
diese Gruppe bei den dynamischen Testentwurfsverfahren überwiegend<br />
spezi fikationsorientierte Testentwurfsverfahren (Black-Box) (92%) und<br />
erfahrungsbasierte Testentwurfsverfahren (82%) e<strong>in</strong>. Rund die Hälfte <strong>der</strong><br />
Befragten setzt strukturorientierte Testentwurfsverfahren (White-Box) e<strong>in</strong>.<br />
Knapp e<strong>in</strong> Drittel führt e<strong>in</strong>e werkzeuggestützt dynamische Fehleranalyse<br />
durch.<br />
Abb. 25<br />
Welche spezifikationsorientierten Testentwurfsverfahren (Black-Box) werden<br />
<strong>in</strong> Ihrem Unternehmen e<strong>in</strong>gesetzt?<br />
Funktionalitätstest bzw. Funktionsüberdeckung<br />
Anwendungsfallbasierter Test<br />
Grenzwertanalyse<br />
Äquivalenzklassenbildung<br />
Zufallstest<br />
Zustandsbasierter Test<br />
Entscheidungstabellentest<br />
Paarweises Testen (pairwise test<strong>in</strong>g)<br />
Klassifikationsbaumverfahren<br />
An<strong>der</strong>e spezifikationsorientierte Testverfahren<br />
Ke<strong>in</strong>e spezifikationsorientierte Testverfahren<br />
3,5%<br />
15,2%<br />
12,7%<br />
13,7%<br />
38,9%<br />
38,3%<br />
33,1%<br />
© <strong>Softwaretest</strong>umfrage <strong>2011</strong>: HS Bremen, HS Bremerhaven, FH Köln, ANECON, GTB, STB<br />
Spezifikationsorientierte Testentwurfsverfahren<br />
54,0%<br />
82,1%<br />
77,1%<br />
67,6%<br />
60,9%
28 Die <strong>Umfrage</strong><br />
Bei den Black-Box-Testentwurfsverfahren setzen 82% auf Funktionalitätstest<br />
bzw. Funktionsüberdeckung, gefolgt von anwendungsfallbasiertem Test,<br />
Grenzwertanalyse und Äquivalenzklassenbildung. E<strong>in</strong>en zustandsbasierten<br />
Test setzen nur 38%, den Entscheidungstabellentest nur 33% e<strong>in</strong> (Abb. 25).<br />
Anweisungstest und -überdeckung<br />
Entscheidungs-/Zweigtest und -überdeckung<br />
(E<strong>in</strong>facher) - Bed<strong>in</strong>gungsüberdeckungstest<br />
Pfadtest<br />
Mehrfach Bed<strong>in</strong>gungsüberdeckungstest<br />
Modifizierter -Bed<strong>in</strong>gungsüberdeckungstest<br />
An<strong>der</strong>e strukturorientierte Testverfahren<br />
Ke<strong>in</strong>e strukturorientierten Testverfahren<br />
Abb. 26<br />
Welche strukturorientierten Testentwurfsverfahren (White-Box) werden<br />
<strong>in</strong> Ihrem Unternehmen e<strong>in</strong>gesetzt?<br />
13,2%<br />
8,0%<br />
12,1%<br />
23,2%<br />
22,1%<br />
© <strong>Softwaretest</strong>umfrage <strong>2011</strong>: HS Bremen, HS Bremerhaven, FH Köln, ANECON, GTB, STB<br />
Strukturorientierte Testentwurfsverfahren<br />
Unter den White-Box-Testentwurfsverfahren wird <strong>der</strong> Anweisungstest/<br />
-überdeckung am häufigsten (42%) durchgeführt. Allerd<strong>in</strong>gs werden auch<br />
von fast ebenso vielen Teilnehmern gar ke<strong>in</strong>e strukturorientierten Testentwurfsverfahren<br />
e<strong>in</strong>gesetzt (Abb. 26).<br />
Abb. 27<br />
Welche erfahrungsbasierten Verfahren werden <strong>in</strong> Ihrem Unternehmen e<strong>in</strong>gesetzt<br />
Intuitive Testfallermittlung (error guess<strong>in</strong>g)<br />
Exploratives Testen (ohne Test-Charta /<br />
Testzielvorgaben, „Freies“ Testen)<br />
Exploratives Testen (mit Test-Charta /<br />
Testzielvorgaben)<br />
Fehlerangriff (fault attack) mit<br />
Fehlerzustands-Checklisten<br />
An<strong>der</strong>e erfahrungsbasierte Verfahren<br />
Ke<strong>in</strong>e erfahrungsbasierte Verfahren<br />
5,5%<br />
15,2%<br />
21,5%<br />
33,3%<br />
35,8%<br />
66,1%<br />
© <strong>Softwaretest</strong>umfrage <strong>2011</strong>: HS Bremen, HS Bremerhaven, FH Köln, ANECON, GTB, STB<br />
Erfahrungsbasierte Testentwurfsverfahren<br />
38,5%<br />
41,9%<br />
84,6%
Die <strong>Umfrage</strong> 29<br />
Werden erfahrungsbasierte Testentwurfsverfahren <strong>in</strong> dem Unternehmen<br />
e<strong>in</strong>gesetzt, so wird mit 85% die <strong>in</strong>tuitive Testfallermittlung (error guess<strong>in</strong>g)<br />
am häufigsten verwendet. Exploratives Testen (ohne Test-Charta/Testzielvorgaben,<br />
»freies« Testen) wird von zwei Dritteln genannt, gefolgt von explorativem<br />
Testen mit Test-Charta/Testzielvorgaben mit e<strong>in</strong>em Drittel (Abb.<br />
27). Interessant ist jedoch, dass die Ergebnisse des explorativen Testens<br />
nicht für die Erstellung <strong>der</strong> Testfälle genutzt wird. Während 18% zustimmen,<br />
ihre Testfälle durch e<strong>in</strong> exploratives Vorgehen zu erstellen, lehnen dies 43%<br />
sogar eher ab.<br />
Entwicklersicht auf den Test<br />
Im Vergleich zu <strong>der</strong> <strong>Umfrage</strong> von 1997 ist <strong>der</strong> Anteil <strong>der</strong> im Testen ausgebildeten<br />
Mitarbeiter erfreulicherweise deutlich gestiegen. Die Tester selbst<br />
nehmen ihre Bedeutung sehr <strong>in</strong>tensiv wahr und sie werden von den Entwicklern<br />
akzeptiert. So gaben immerh<strong>in</strong> 77% <strong>der</strong> Entwicklergruppe an, dass<br />
Tests von ausgebildeten Testern durchgeführt werden. Dies ist e<strong>in</strong> erwartetes<br />
und erhofftes Ergebnis.<br />
Nichtsdestotrotz sehen die verschiedenen Gruppen <strong>der</strong> Tester und<br />
Entwickler jeweils ihre eigene Gruppe als Hauptlastenträger <strong>der</strong> Qualitätssicherung.<br />
Dies wird beson<strong>der</strong>s deutlich an <strong>der</strong> Frage, wer für die QS <strong>in</strong> den<br />
Projekten verantwortlich ist. Sieht die Gruppe <strong>der</strong> Tester die Verantwortung<br />
im Wesentlichen bei den Projektmanagern, QS-Beauftragten und Testmanagern,<br />
so gibt die Gruppe <strong>der</strong> Entwickler mit Abstand (65%) ihre eigene Rolle<br />
als verantwortlich für die QS an. Testmanager und QS-Beauftragte werden<br />
von weniger als 30% genannt.<br />
Standards, Communities und Zertifikate im <strong>Softwaretest</strong><br />
Bei <strong>der</strong> Frage nach Qualifizierungsmaßnahmen im Bereich <strong>der</strong> QS beantwortet<br />
mehr als e<strong>in</strong> Drittel <strong>der</strong> Entwickler, dass sie ke<strong>in</strong>e Unterstützung<br />
hierfür erfahren (Abb. 28). Die Entwickler werden deutlich weniger durch<br />
unternehmensweite o<strong>der</strong> <strong>in</strong>dividuelle Qualifizierungsprogramme <strong>in</strong> <strong>der</strong><br />
Qualitätssicherung unterstützt als die Tester. Es ist bedenklich, dass Entwick-
30 Die <strong>Umfrage</strong><br />
ler sehr häufig Tests durchführen, diese aber ke<strong>in</strong>e adäquate Weiterbildung<br />
erhalten. Gerade h<strong>in</strong>sichtlich <strong>der</strong> agilen Vorgehensmodelle und durch steigende<br />
Anfor<strong>der</strong>ungen h<strong>in</strong>sichtlich Sicherheitslücken und Stabilität sollte<br />
hier e<strong>in</strong> Umdenken <strong>in</strong> den Unternehmen e<strong>in</strong>setzen und auch die Entwickler<br />
s<strong>in</strong>d <strong>in</strong> den formalen Testprozessen und Testwerkzeugen zu schulen.<br />
Abb. 28<br />
Wird <strong>in</strong> Ihrem Unternehmen die Weiterbildung im Bereich <strong>der</strong> Qualitätssicherung unterstützt?<br />
Ja, durch <strong>in</strong>dividuelle<br />
Qualifizierungsprogramme<br />
Ja, durch Freiräume zur<br />
<strong>in</strong>dividuellen Qualifizierung<br />
Ja, durch e<strong>in</strong> unternehmensweites<br />
Qualifizierungsprogramm<br />
Ja, durch projektweite<br />
Qualifizierungsprogramme<br />
Ne<strong>in</strong><br />
13,9%<br />
8,8%<br />
4,1%<br />
13,5%<br />
27,3%<br />
27,4%<br />
41,5%<br />
36,6%<br />
34,5%<br />
Tester Entwickler<br />
© <strong>Softwaretest</strong>umfrage <strong>2011</strong>: HS Bremen, HS Bremerhaven, FH Köln, ANECON, GTB, STB<br />
Qualifizierung im Unternehmen<br />
43,8%<br />
Das ISTQB ® -Ausbildungsschema ist nicht nur bei den Testern, son<strong>der</strong>n auch<br />
im Management zu 70% bekannt. In <strong>der</strong> Gruppe <strong>der</strong> Entwickler ist dies jedoch<br />
erst mit knapp 40% <strong>der</strong> Fall (Abb. 29). Die Tester nehmen dieses Ausbildungsangebot<br />
sehr gut an, so s<strong>in</strong>d 67% <strong>der</strong>jenigen Tester, die das ISTQB ® -<br />
Ausbildungsschema kennen, auf dem Foundation Level zertifiziert und 90%<br />
davon f<strong>in</strong>den diese Ausbildung hilfreich für ihre Tätig keiten.
Abb. 29<br />
Tester<br />
Management<br />
Entwickler<br />
Das ISTQB® (International Software Test<strong>in</strong>g Qualifications Board)-Ausbildungsschema<br />
ist mir bekannt ...<br />
10,4%<br />
29,8%<br />
39,0%<br />
Ja Ne<strong>in</strong><br />
61,0%<br />
70,2%<br />
© <strong>Softwaretest</strong>umfrage <strong>2011</strong>: HS Bremen, HS Bremerhaven, FH Köln, ANECON, GTB, STB<br />
ISTQB®-Ausbildungsschema<br />
Die <strong>Umfrage</strong> 31<br />
89,6%<br />
Für die persönliche Weiterbildung nutzt die Gruppe des Managements<br />
beson<strong>der</strong>s Veranstaltungen und Konferenzen. Deshalb ist es auch nicht<br />
verwun<strong>der</strong>lich, dass die Veranstaltungen von Fachgruppen und regionale<br />
Gruppen <strong>in</strong> <strong>der</strong> Test-Community <strong>in</strong> erster L<strong>in</strong>ie von den Befragten <strong>der</strong> Gruppe<br />
Management besucht werden, gefolgt von <strong>der</strong> Gruppe <strong>der</strong> Tester. Insgesamt<br />
wird dieses Angebot aber nur von wenigen angenommen.
32<br />
Fazit<br />
Das primäre Ziel <strong>der</strong> Qualitätssicherung wird <strong>in</strong> <strong>der</strong> Erhöhung <strong>der</strong> Leistungsfähigkeit<br />
gesehen. Erst an zweiter Stelle steht die Senkung <strong>der</strong> Kosten.<br />
Obwohl häufig <strong>der</strong> Ansche<strong>in</strong> vorhanden ist, dass die Kostensenkung im<br />
Vor<strong>der</strong>grund steht, bestätigt das Ergebnis <strong>der</strong> aktuellen <strong>Umfrage</strong> eher das<br />
Ergebnis <strong>der</strong> <strong>Umfrage</strong> von 1997. Auch hier wurde an erster Stelle die Erhöhung<br />
<strong>der</strong> Leistungsfähigkeit, gefolgt von <strong>der</strong> Senkung <strong>der</strong> Kosten genannt.<br />
Bemerkenswert war jedoch, dass diese Aussagen <strong>in</strong> hohem Maße kongruent<br />
von <strong>der</strong> Management- als auch von <strong>der</strong> Testgruppe gesehen werden.<br />
Hier zeigt sich, dass die Ziele <strong>der</strong> Tester mit den Zielen des Unternehmens<br />
sehr gut übere<strong>in</strong>stimmen.<br />
Über 40% <strong>der</strong> Unternehmen, die e<strong>in</strong>en Testprozess haben, lassen diesen<br />
auditieren. Dies zeigt deutlich, dass <strong>Softwaretest</strong> und Qualitätssicherung<br />
<strong>in</strong> <strong>der</strong> Softwareentwicklung professioneller werden. Auch werden häufig<br />
Kennzahlen wie »Abdeckung <strong>der</strong> Anfor<strong>der</strong>ungen«, »Durchführungsrate«<br />
o<strong>der</strong> »Fehlererkennungsrate« als Testendekriterien genannt. Auf <strong>der</strong> an<strong>der</strong>en<br />
Seite geben aber nach wie vor 56% <strong>der</strong> Befragten an, dass das Testen<br />
beendet wird, wenn <strong>der</strong> Auslieferungszeitpunkt erreicht ist – <strong>der</strong> Test also<br />
e<strong>in</strong>e Art »Puffer- o<strong>der</strong> Restaktivität« darstellt. Die Testendekriterien werden<br />
zu 86% fast bzw. immer e<strong>in</strong>gehalten, somit wird e<strong>in</strong>e Systematik erkannt<br />
und auch verfolgt.<br />
Insgesamt kann bestätigt werden, dass das Qualitätsbewusstse<strong>in</strong> zugenommen<br />
hat und die Qualitätssicherung frühzeitig <strong>in</strong> den Softwareentwicklungsprozess<br />
<strong>in</strong>tegriert wird.<br />
Nach <strong>der</strong> Auslieferung s<strong>in</strong>d bei e<strong>in</strong>em Drittel <strong>der</strong> Befragten noch schwerwiegende<br />
Fehler im System aufgetreten. H<strong>in</strong>sichtlich des Auftretens von<br />
Fehlern <strong>in</strong> <strong>der</strong> Produktion unterscheidet sich e<strong>in</strong> agiles Vorgehen nicht von<br />
e<strong>in</strong>em phasenorientierten Vorgehen, beide s<strong>in</strong>d aber wesentlich effektiver,<br />
als wenn ke<strong>in</strong> explizites Vorgehensmodell angewandt wird.<br />
Wurde die Frage nach e<strong>in</strong>er eigenen Qualitätssicherungsabteilung im<br />
Unternehmen 1997 nur von 31% <strong>der</strong> Teilnehmer bejaht, so fällt das <strong>in</strong> dieser<br />
<strong>Umfrage</strong> mit 66% deutlich positiver aus. Das Budget für QS und Test beträgt<br />
<strong>der</strong>zeit rund 20%, wird i.d.R. pauschal geschätzt und meist e<strong>in</strong>gehalten.<br />
Es ist erfreulich, dass die Tester sehr systematisch vorgehen und es für<br />
diese Gruppe selbstverständlich ist, <strong>in</strong> Teststufen methodisch zu arbeiten.
Fazit 33<br />
Im Management wird <strong>der</strong> Wertbeitrag des Tests erkannt. Jedoch ist das<br />
Management, im Gegensatz zu den Testern, etwas optimistischer, was die<br />
E<strong>in</strong>haltung des Qualitätssicherungsbudgets und die Wirksamkeit des Risikomanagements<br />
anbelangt. Positiv zu bemerken ist aber auch die große<br />
Übere<strong>in</strong>stimmung <strong>der</strong> diesbezüglichen E<strong>in</strong>schätzung durch Management<br />
und Tester. Tester werden im Vergleich zu 1997 zunehmend als wichtig und<br />
gleichberechtigt zu den Entwicklern gesehen und <strong>der</strong> Wertbeitrag <strong>der</strong> Qualitätssicherung<br />
wird anerkannt.<br />
Die Gruppe <strong>der</strong> Entwickler ist <strong>in</strong> gleichem Maße <strong>in</strong> Qualitätsmaßnahmen<br />
<strong>in</strong>volviert wie die Gruppe <strong>der</strong> Tester. Sieht man sich den Grad <strong>der</strong> Ausbildung<br />
an, gibt es aber klare Unterschiede. Die Entwickler haben weniger<br />
Qualifizierungsmöglichkeiten im Bereich des Tests. Sie s<strong>in</strong>d, was die Werkzeugnutzung<br />
und die Anwendung von Testprozessen angeht, noch besser<br />
zu unterstützen.<br />
Positiv ist, dass die Nutzung von eigenen Testumgebungen für die Tests<br />
sehr weit verbreitet ist (> 80%). Testautomation im Abnahme-, System- und<br />
Integrations-Test wird überraschen<strong>der</strong> Weise noch wenig e<strong>in</strong>gesetzt. Testautomation<br />
wird schwerpunktmäßig im Unit-Test genutzt, aber auch dieser<br />
ist noch weit von e<strong>in</strong>er vollständigen Automation entfernt. Abnahme- und<br />
Systemtests werden nur von e<strong>in</strong>er kle<strong>in</strong>en Gruppe weitestgehend automatisiert.<br />
E<strong>in</strong>en weitgehenden Trend zur Verlagerung von Testaktivitäten zu externen<br />
Dienstleistern lässt sich nicht erkennen. Nur zu ger<strong>in</strong>gen Teilen werden<br />
Berater und Anbieter von Testdienstleistungen mit <strong>der</strong> Durchführung von<br />
Tests betraut.<br />
Das ISTQB ® -Ausbildungsschema ist weit verbreitet und die Tester s<strong>in</strong>d<br />
über den Nutzen <strong>der</strong> ISTQB ® -Zertifizierung hoch zufrieden. Fachgruppen<br />
werden jedoch selten besucht und <strong>der</strong> Austausch <strong>in</strong> <strong>der</strong> Testcommunity ist<br />
ausbaubar.
34<br />
Literatur und L<strong>in</strong>ks<br />
[Umf11]<br />
<strong>Umfrage</strong> <strong>2011</strong> – <strong>Softwaretest</strong> <strong>in</strong> <strong>der</strong> <strong>Praxis</strong>, siehe:<br />
http://www.softwaretest-umfrage.de/<br />
[Mül98]<br />
U. Müller, T. Wiegmann, O. Avci, »State of the Practice« <strong>der</strong> Prüf- und Testprozesse<br />
<strong>in</strong> <strong>der</strong> Softwareentwicklung, Ergebnisse e<strong>in</strong>er empirischen Untersuchung<br />
bei deutschen Softwareunternehmen, <strong>in</strong>: W. Mellis, G. Herzwurm,<br />
D. Stelzer (Hrsg.), Studien zur Systementwicklung, Band 16, 1998, siehe:<br />
http://systementwicklung-archiv.bibliothek.<strong>in</strong>formatik.uni-koeln.de/28<br />
[Ilias11]<br />
Open Source e-Learn<strong>in</strong>g, siehe:<br />
http://www.ilias.de<br />
[ISTQB10]<br />
ISTQB ® /GTB-Standardglossar <strong>der</strong> Testbegriffe. Version 2.1, ISTQB ® /GTB e.V.<br />
2010. Als Download des German Test<strong>in</strong>g Board e.V., siehe:<br />
http://www.german-test<strong>in</strong>g-board.<strong>in</strong>fo/de/downloads.shtm<br />
Lesehilfe für die Grafiken<br />
In Grafiken ohne Legende haben wir folgende Farbsemantik verwendet:<br />
alle Teilnehmer wurden befragt<br />
nur Teilgruppen wurden befragt<br />
Bei Antworten entlang e<strong>in</strong>er Likert-Skala wurden Antworten wie immer und<br />
meist als Zustimmung, selten und nie als Ablehnung und teils/teils als neutral<br />
<strong>in</strong>terpretiert. Außerdem haben wir <strong>in</strong> <strong>der</strong> Darstellung nicht zwischen Multiple-<br />
und S<strong>in</strong>gle-Choice-Fragen unterschieden. Dies ist aus dem Kontext zu<br />
entnehmen.
Bücher für <strong>Softwaretest</strong>er bei dpunkt<br />
Andreas Spillner • Tilo L<strong>in</strong>z<br />
Aus- und Weiterbildung<br />
zum Certified Tester<br />
• Foundation Level<br />
• nach ISTQB-Standard<br />
dpunkt. dpunkt.verlag verlag<br />
Andreas Spillner, Tilo L<strong>in</strong>z<br />
Basiswissen<br />
<strong>Softwaretest</strong><br />
4., überarbeitete und<br />
aktualisierte Auflage<br />
2010, 308 Seiten<br />
e 39,90 (D)<br />
ISBN 978-3-89864-642-0<br />
Graham Bath, Judy McKay<br />
<strong>Praxis</strong>wissen<br />
<strong>Softwaretest</strong><br />
2., durchgesehene Auflage<br />
<strong>2011</strong>, 432 Seiten<br />
e 42,90 (D)<br />
ISBN 978-3-89864-735-9<br />
Sachar Paulus<br />
Basiswissen<br />
Sichere Software<br />
<strong>2011</strong>, 286 Seiten<br />
e 39,90 (D)<br />
ISBN 978-3-89864-726-7<br />
Frank Neugebauer<br />
Penetration Test<strong>in</strong>g<br />
mit Metasploit<br />
<strong>2011</strong>, 230 Seiten<br />
e 32,90 (D)<br />
ISBN 978-3-89864-739-7<br />
Vorschau<br />
Andreas Spillner, Thomas<br />
Roßner, Mario W<strong>in</strong>ter, Tilo L<strong>in</strong>z<br />
<strong>Praxis</strong>wissen <strong>Softwaretest</strong> –<br />
Testmanagement<br />
3., überarbeitete und erweiterte<br />
Auflage<br />
<strong>2011</strong>, 464 Seiten<br />
e 42,90 (D)<br />
ISBN 978-3-89864-746-5<br />
Thomas Roßner, Christian<br />
Brandes, Helmut Götz,<br />
Mario W<strong>in</strong>ter<br />
Basiswissen<br />
modellbasierter Test<br />
2010, 424 Seiten<br />
e 42,90 (D)<br />
ISBN 978-3-89864-589-8<br />
Richard Seidl,<br />
Manfred Baumgartner,<br />
Thomas Bucsics<br />
Basiswissen<br />
Testautomatisierung<br />
4. Quartal <strong>2011</strong>, ca. 250 Seiten<br />
ca. e 39,90 (D)<br />
ISBN 978-3-89864-724-3<br />
Alexan<strong>der</strong> van Ewijk,<br />
Bert L<strong>in</strong>ker, Marcel van<br />
Oosterwijk, Ben Visser,<br />
Gerrit de Vries, Loek<br />
Wilhelmus<br />
TPI NEXT®<br />
<strong>2011</strong>, 330 Seiten, 2-farbig<br />
e 39,90 (D)<br />
ISBN 978-3-89864-685-7<br />
dpunkt.verlag GmbH, R<strong>in</strong>gstraße 19 b, 69115 Heidelberg, www.dpunkt.de, hallo@dpunkt.de
FH Köln – Institut für Informatik<br />
Präsenzstudium<br />
� Allgeme<strong>in</strong>e Informatik (Bachelor)<br />
� Technische Informatik (Bachelor)<br />
� Wirtschafts<strong>in</strong>formatik (Bachelor)<br />
� Medien<strong>in</strong>formatik (Bachelor & Master)<br />
� Informatik (Master, Schwerpunkte SE+WI)<br />
Verbundstudium<br />
� Wirtschafts<strong>in</strong>formatik (Bachelor & Master)<br />
� Web Science (Master)<br />
Forschung und Transfer<br />
� Unterstützung bei Forschung und Entwicklung<br />
� Maßgeschnei<strong>der</strong>te Beratung<br />
� Kontakte zu Mitarbeiter(<strong>in</strong>nen) von morgen<br />
<strong>in</strong>formatiKKöln<br />
ln<br />
K Kö<br />
K<br />
Fachhochschule Köln<br />
Campus Gummersbach<br />
Institut für Informatik<br />
www.fh-koeln.de<br />
www.gm.fh-koeln.de<br />
www.<strong>in</strong>formatik-koeln.de
ISTQB ® Certified Tester<br />
Über 175.000 Certified Tester weltweit.<br />
Wann gehören Sie dazu?<br />
Manche Ausbildungen öffnen Wege, an<strong>der</strong>e e<strong>in</strong>e ganze Welt.<br />
Die Schulung zum ISTQB® Certified Tester führt zu e<strong>in</strong>em weltweit anerkannten und etablierten Zertifikat. Rund 20.000 Fachkräfte<br />
alle<strong>in</strong>e <strong>in</strong> Deutschland haben es schon. Und Zehntausende <strong>in</strong> weiteren 47 Län<strong>der</strong>n - von A wie Amerika bis V wie Vietnam.<br />
Der ISTQB® Certified Tester ermöglicht<br />
Karrieren - mit ihm liegt erstmals<br />
e<strong>in</strong> <strong>in</strong>ternationales und branchenübergreifendes<br />
Berufsprofil für<br />
Software-Tester vor.<br />
Anmelden ist e<strong>in</strong>fach.<br />
E<strong>in</strong> akkreditierter Tra<strong>in</strong><strong>in</strong>gsanbieter ist sicher auch <strong>in</strong> Ihrer Nähe:<br />
GTB Premium Partner<br />
ALTRAN GmbH & Co. KG<br />
andagon GmbH<br />
berner & mattner Systemtechnik GmbH<br />
corporate quality consult<strong>in</strong>g GmbH<br />
C1 SetCon GmbH<br />
EXCO GmbH<br />
Alle Tra<strong>in</strong><strong>in</strong>gsprovi<strong>der</strong> siehe www.german-test<strong>in</strong>g-board.<strong>in</strong>fo<br />
Autorisierte Zertifizierungsstellen<br />
Der ISTQB® Certified Tester macht<br />
die Arbeit leichter -Tester sprechen<br />
nun die gleiche Fachsprache,<br />
benutzen die gleichen Begriffe.<br />
imbus AG<br />
Knowledge Department GmbH & Co. KG<br />
Logica Deutschland GmbH & Co. KG<br />
MaibornWolff et al GmbH<br />
Method Park Software AG<br />
Philotech GmbH<br />
Cert-IT GmbH gasq Service GmbH iSQl GmbH<br />
Der ISTQB® Certified Tester hilft<br />
Kosten zu senken - Durch<br />
geschulte Tester werden Fehler<br />
bereits <strong>in</strong> frühen Phasen <strong>der</strong><br />
SW-Entwicklung entdeckt.<br />
qme Software GmbH<br />
sepp.med gmbh<br />
Software Quality Lab GmbH<br />
Sogeti Deutschland GmbH<br />
SQS AG<br />
T-Systems
Karrierechancen durch e<strong>in</strong> Studium<br />
<strong>der</strong> Elektrotechnik und Informatik<br />
Für alle, die Karriere als Ingenieur<strong>in</strong> bzw. Ingenieur machen wollen, bietet die Hochschule<br />
Bremen <strong>in</strong>teressante und zukunftsorientierte Bachelor- und Master-Studiengänge:<br />
Energietechnik B.Eng.<br />
Zukunftsfähige Energiesysteme M.Eng.<br />
Elektrotechnik B.Eng.<br />
(Studienprofile: Elektrische Energietechnik, Elektronik, Informationstechnik, Sensorsysteme,<br />
Lasertechnik, Mikrosystemtechnik)<br />
Internationaler Studiengang Technische und Angewandte Physik B.Sc.<br />
Electronics Eng<strong>in</strong>eer<strong>in</strong>g M.Sc.<br />
Dualer Studiengang Mechatronik B.Eng.<br />
Technische Informatik B.Sc.<br />
Internationaler Studiengang Technische Informatik B.Sc.<br />
Dualer Studiengang Informatik B.Sc.<br />
Internationaler Frauen-Studiengang Informatik B.Sc.<br />
Internationaler Studiengang Medien<strong>in</strong>formatik B.Sc.<br />
Informatik M.Sc. - Komplexe Softwaresysteme<br />
Abkürzungen:<br />
B.Eng.: Bachelor of Eng<strong>in</strong>eer<strong>in</strong>g<br />
B.Sc.: Bachelor of Science<br />
M.Eng.: Master of Eng<strong>in</strong>eer<strong>in</strong>g<br />
M.Sc.: Master of Science<br />
Nähere Informationen über Studien<strong>in</strong>halte und<br />
Zulassungsvoraussetzungen:<br />
Hochschule Bremen<br />
Studienberatung<br />
Neustadtswall 30<br />
D-28199 Bremen<br />
0421-5905-2022 | studienberatung@hs-bremen.de | www.studienberatung.hs-bremen.de
Swiss Test<strong>in</strong>g Board Board – Certified – Certified Tester Tester<br />
Das Swiss Test<strong>in</strong>g Board (STB) ist aktives Mitglied des ISTQB<br />
(International Software Test<strong>in</strong>gQualifications Board), vertritt<br />
die Interessen <strong>der</strong> Schweizer <strong>Softwaretest</strong>er und stellt sicher,<br />
dass die Ausbildungen den Vorgaben und Richtl<strong>in</strong>ien des<br />
ISTQB entsprechen.<br />
In Zusammenarbeit mit dem ISTQB zertifiziert die SAQ Swiss<br />
Associationfor Quality Software Tester auf den Stufen Foundation,<br />
Advanced sowie den Expert Level. Angesprochen s<strong>in</strong>d<br />
Personen, die Testaufgaben wahrnehmen o<strong>der</strong> übernehmen<br />
wollen, und sich als Anwen<strong>der</strong> von Software Test-Techniken<br />
auszeichnen möchten.<br />
„ISTQB ® Das Swiss Test<strong>in</strong>g Board (STB) ist aktives Mitglied des ISTQB (International<br />
Software Test<strong>in</strong>g Qualifications Board), vertritt die<br />
Interessen <strong>der</strong> Schweizer <strong>Softwaretest</strong>er und stellt sicher, dass<br />
die Ausbildungen den Vorgaben und Richtl<strong>in</strong>ien des ISTQB<br />
entsprechen.<br />
In Zusammenarbeit mit dem ISTQB zertifiziert die SAQ Swiss<br />
Association for Quality <strong>Softwaretest</strong>er auf den Stufen Foun dation,<br />
Advanced sowie den Expert Level. Angesprochen s<strong>in</strong>d<br />
Personen, die Testaufgaben wahrnehmen o<strong>der</strong> übernehmen<br />
wollen und sich als Anwen<strong>der</strong> von <strong>Softwaretest</strong>techniken auszeichnen<br />
möchten.<br />
»ISTQB®/SAQ /SAQ Certified Tester« Tester“ ist das ist das erste erste und und e<strong>in</strong>zige e<strong>in</strong>zige <strong>in</strong>ter<strong>in</strong>ternational anerkannte, standardisierte Aus- Aus- und und Weiterbildungsschema<br />
für für <strong>Softwaretest</strong>er.<br />
E<strong>in</strong>e modulare Ausbildung über 3 Stufen:<br />
E<strong>in</strong>e modulare Ausbildung über 3 Stufen:<br />
Basis Basis schaffen schaffen – Foundation – Foundation Level Level<br />
Wissen Wissen erweitern erweitern – Advanced – Advanced Level Level<br />
Wissen<br />
Wissen<br />
spezialisieren<br />
spezialisieren<br />
– Expert<br />
–<br />
Level<br />
Expert Level<br />
Die Zertifikate besche<strong>in</strong>igen, dass die Absolventen e<strong>in</strong> solides<br />
Wissen Die Zertifikate und e<strong>in</strong>e besche<strong>in</strong>igen, gute Anwendungspraxis dass die über Absolventen den gesamten e<strong>in</strong> soli-<br />
Testprozess des Wissen haben. und gute Anwendungs-<strong>Praxis</strong> über den gesamten<br />
Testprozesses haben.<br />
Informationen unter:<br />
www.saq.ch/zertifikate Informationen unter: und www.software-tester.ch<br />
www.saq.ch/zertifikate und www.software-tester.ch
Hochschule am Meer<br />
Ihr maritimes Profil ist für die Hochschule Bremerhaven<br />
charakteristisch. Dazu trägt nicht nur ihre geografische<br />
Lage direkt an <strong>der</strong> Wesermündung zur Nordsee bei,<br />
son<strong>der</strong>n auch ihre <strong>in</strong>novativen, mo<strong>der</strong>nen und maritim<br />
geprägten Studiengänge. In den 24 technischen, naturwissenschaftlichen<br />
und wirtschaftswissenschaftlichen<br />
Bachelor- und Masterstudiengängen <strong>der</strong> »Hochschule<br />
am Meer« studieren <strong>der</strong>zeit rund 3000 Studierende aus<br />
66 Nationen.<br />
www.hs-bremerhaven.de
Software Test<br />
unabhängig - professionell - umfassend<br />
ANECON - die Experten für Softwarequalität!<br />
Wir bieten e�zienten Software Test, hochwertige IT-Beratung<br />
und Softwarequalität. Unser Credo bei Projekten lautet:<br />
IN TIME, IN BUDGET & IN QUALITY.<br />
• Ganzheitliches Testmanagement,<br />
von <strong>der</strong> Strategie bis zur Umsetzung<br />
• Deutschsprachiges Testcenter<br />
SOFTWARE DESIGN UND BERATUNG<br />
o�ce@anecon.com<br />
Dresden: Tel. +49 351 272 1395 | Wien: Tel. +43 1 409 58 90-0<br />
Mit <strong>der</strong> umfangreichen Erfahrung des ANECON-Teams steht Ihnen e<strong>in</strong><br />
kompetenter Partner für jede Aufgabenstellung im Bereich Software-<br />
Test zur Verfügung.<br />
• Neue Wege im Qualitätsmanagement<br />
• Kostenvorteile durch Automatisierung<br />
Als akkreditierter Tra<strong>in</strong><strong>in</strong>gsanbieter <strong>in</strong> Deutschland und<br />
Österreich bieten wir ö�entliche und �rmen<strong>in</strong>terne<br />
ISTQB® Certi�ed Tester Tra<strong>in</strong><strong>in</strong>gs an.<br />
Unsere neue Schulungsserie Agile LIVE! bietet zusätzlich<br />
e<strong>in</strong> Rundum-Paket für die erfolgreiche Anwendung agiler<br />
Methoden.<br />
Weitere Informationen auf www.anecon.com/angebote/tra<strong>in</strong><strong>in</strong>gs<br />
ANECON. Software ist unsere Leidenschaft www.anecon.com
<strong>Umfrage</strong> <strong>2011</strong>: <strong>Softwaretest</strong> <strong>in</strong> <strong>der</strong> <strong>Praxis</strong><br />
In Kooperation mit den Hochschulen Bremen und Bremerhaven, <strong>der</strong><br />
Fachhochschule Köln, ANECON Software Design und Beratung G.m.b.H.,<br />
dem German Test<strong>in</strong>g Board und dem Swiss Test<strong>in</strong>g Board<br />
In den letzten Jahren gab es im Bereich Qualitätssicherung und Testen viele<br />
neue Trends wie z.B. Test-Driven Development, exploratives Testen, modellbasiertes<br />
Testen o<strong>der</strong> auch die agilen Vorgehensmodelle. Diese Trends bieten<br />
Chancen als auch Herausfor<strong>der</strong>ungen <strong>in</strong> Test und Qualitätssicherung. Was<br />
davon hat bereits E<strong>in</strong>zug <strong>in</strong> den Test-Alltag gehalten? Hat sich <strong>in</strong> den letzten<br />
Jahren etwas verän<strong>der</strong>t? Wie sieht <strong>der</strong> Test-Alltag heute <strong>in</strong> den Unternehmen<br />
überhaupt aus? Diese und weitere Fragen wurden mithilfe <strong>der</strong> detaillierten<br />
<strong>Umfrage</strong> »<strong>Softwaretest</strong> <strong>in</strong> <strong>der</strong> <strong>Praxis</strong>« beantwortet.<br />
Art.-Nr.: 077.95725<br />
www.dpunkt.de