Arbeitskreis Software-Qualität und -Fortbildung e.V ... · Software Testanalyst (w/m) Océ...

Ausgabe 27 | Juni 2013

Arbeitskreis Software-Qualität und -Fortbildung e.V.

Arbeitskreis Software-Qualität und -Fortbildung e.V.

TRADITIONELL VS.

AGIL

Im GesprächInterview mit Chris CarterSeite 8

Standard NEWSNachwuchs bei den „Certified’s“Seite 30

ASQF-Umfrage 2013IT-Branche bleibt zuversichtlichSeite 39

Am 1. Juli feiert die Díaz & Hilter-scheid GmbH ihr 15-jähriges Fir-menjubiläum! Daher laden wir Sie in unsere Büroräume zum Lernen und Feiern ein. Vom 1. bis 3. Juli findet bei uns am Kurfürstendamm in Berlin ein „ISTQB Certified Tester Foundation Level – Kompaktkurs“ statt.

Wir reservieren für Sie einen kos-tenfreien Platz im oben genannten Kurs! Sie buchen hierzu lediglich zwei weitere Teilnehmer für un-sere Kurse im laufenden Kalen-derjahr. Für weitere Informatio-nen und die Onlineanmeldung zu unseren Kursen besuchen Sie training.diazhilterscheid.de.

• Dieses Angebot gilt ausschließlich für die Trainingsgebühr unseres Seminars zum ISTQB Certified Tester Foundation Level 01.–03. Juli 2013. Die Prüfungsgebühr ist selbst zu entrichten.

• Die Kursanmeldung erfolgt über unsere Website (www.diazhilterscheid.de) mit dem Kennwort BERLIN100.

• Der Kurs kann nur ab einer Teilnehmerzahl von 4 stattfinden.

• Der Sonderrabatt wird nur gewährt, falls in-nerhalb von 24 Stunden zwei weitere kosten-pflichtige Anmeldungen von Mitarbeitern desselben Unternehmens zu unseren ISTQB, CPRE oder CAT Kursen im Kalenderjahr 2013 eingehen. Bitte verweisen Sie im Kommen-tarfeld der Onlineanmeldung auf die weite-ren Teilnehmer aus Ihrem Unternehmen.

• Für die zwei zusätzlichen Anmeldungen sind keine Stornierungen möglich. Allerdings kann nach Verfügbarkeit der Teilnahmeter-min bis zum Ende des Jahres 2013 verscho-ben werden oder ein anderer Mitarbeiter die Teilnahme am Kurs übernehmen.

• Dieser Sonderrabatt ist nicht mit anderen Sonderaktionen kombinierbar.

Kostenlos* zum ISTQB Certified Tester!

Wie ist das möglich?

* Bitte beachten Sie folgende Hinweise:

training.diazhilterscheid.de

Am 1. Juli feiert die Díaz & Hilter-scheid GmbH ihr 15-jähriges Fir-menjubiläum! Daher laden wir Sie in unsere Büroräume zum Lernen und Feiern ein. Vom 1. bis 3. Juli findet bei uns am Kurfürstendamm in Berlin ein „ISTQB Certified Tester Foundation Level – Kompaktkurs“ statt.

Wir reservieren für Sie einen kos-tenfreien Platz im oben genannten Kurs! Sie buchen hierzu lediglich zwei weitere Teilnehmer für un-sere Kurse im laufenden Kalen-derjahr. Für weitere Informatio-nen und die Onlineanmeldung zu unseren Kursen besuchen Sie training.diazhilterscheid.de.

• Dieses Angebot gilt ausschließlich für die Trainingsgebühr unseres Seminars zum ISTQB Certified Tester Foundation Level 01.–03. Juli 2013. Die Prüfungsgebühr ist selbst zu entrichten.

• Die Kursanmeldung erfolgt über unsere Website (www.diazhilterscheid.de) mit dem Kennwort BERLIN100.

• Der Kurs kann nur ab einer Teilnehmerzahl von 4 stattfinden.

• Der Sonderrabatt wird nur gewährt, falls in-nerhalb von 24 Stunden zwei weitere kosten-pflichtige Anmeldungen von Mitarbeitern desselben Unternehmens zu unseren ISTQB, CPRE oder CAT Kursen im Kalenderjahr 2013 eingehen. Bitte verweisen Sie im Kommen-tarfeld der Onlineanmeldung auf die weite-ren Teilnehmer aus Ihrem Unternehmen.

• Für die zwei zusätzlichen Anmeldungen sind keine Stornierungen möglich. Allerdings kann nach Verfügbarkeit der Teilnahmeter-min bis zum Ende des Jahres 2013 verscho-ben werden oder ein anderer Mitarbeiter die Teilnahme am Kurs übernehmen.

• Dieser Sonderrabatt ist nicht mit anderen Sonderaktionen kombinierbar.

Kostenlos* zum ISTQB Certified Tester!

Wie ist das möglich?

* Bitte beachten Sie folgende Hinweise:

training.diazhilterscheid.de

Deutschland steht vor wichtigen Wahlen im September und damit kün-digt sich für unser Land eine Richtungsentscheidung an.

Entscheidende Wahlen haben in den letzten Wochen auch in unserer Bran-che stattgefunden: Das ISTQB wählte mit Chris Carter einen neuen Präsi-denten (siehe S.9 ), der vorher 4 Jahre lang bereits als Vice President wirkte.

Der ASQF hat ein neues Präsidium mit Rudolf van Megen an der Spitze, der schon Vizepräsident war und auch unsere Partner vom German Testing Board haben personelle Veränderungen vollzogen. Mit Horst Pohlmann hat das GTB e.V. den langjährigen Vize zum Vorsitzenden gewählt.

Man könnte also meinen, allgemein würde auf Kontinuität gesetzt. Ein richtiges Zeichen in der Krise? Ja und Nein wäre meine Antwort. Sicher-lich falsch wäre es, wenn einer personellen Kontinuität ein inhaltliches

„Weiter so!“ folgen würde. Hat das ISTQB offenbar in den letzten Jahren versäumt, inhaltlich auf die tatsächlichen Trends und Anforderungen der Branche zu reagieren, wird es nun die Aufgabe sein, aus den Fehlern zu lernen und schneller zu reagieren. Das GTB ist im ISTQB hier eine trei-bende Kraft für Innovationen. Vor allem aber muss das Ohr wieder mehr am Markt sein. Ein Vorwurf, den der ASQF sich sicher nicht machen las-sen muss, ist er doch mit seinen Fachgruppen und regionalen Fachgrup-pen deutschlandweit präsent. Für den Verein heißt es, in verantwortlicher Weise weiter zu wachsen und inhaltlich das Thema Software Qualität durch Qualifizierung weiter voran zu treiben. In Zeiten großer Blamagen durch gescheiterte Großprojekte braucht es mehr denn je eine Branchen-vertretung, die sich für das „Made in Germany“ einsetzt. Dem GTB, seit Jahren eines der erfolgreichsten Mitglieder des ISTQB, möchte man ins Stammbuch schreiben, seiner Bedeutung bei der Durchsetzung unserer Interessen gerecht zu werden: Nicht der Schwächste darf den Takt be-stimmen, sondern von vorn führt man. Das gilt auch in der Entwicklung von Standards bei der Ausbildung von Fachpersonal.

ASQF und iSQI werden auch unter neuer personeller Konstellation kon-tinuierlich an unserem gemeinsamen Ziel arbeiten. Denn Bildung macht nicht den besseren Menschen, aber es schafft Vertrauen.

In diesem Sinne wünsche ich uns allen einen erfolgreichen Sommer,

Stephan Goericke

Stephan Goericke,

Hauptgeschäftsführer ASQF e.V.

Liebe Freunde,

Editorial3 Ausgabe 27 | Juni 2013

3 EDITORIAL

6 ASQF-NEWS

Die ASQF-Days: Leuchttürme im Knowhow-Transfer //

Einreichung: Deutscher Preis für Software-Qualität // Zu-

wachs: Neue Mitglieder // Günstiges Fachwissen: Partner-

konferenzen mit ASQF-Rabatt // Sommeraktion: Mitglied

werben und Prämie sichern // Neu: Fachgruppenleiter

8 IM GESPRÄCH

8 Interview mit Chris Carter,

der neue Präsident des ISTQB

35 Interview mit Horst Pohlmann

der neue Vorsitzende des GTB e.V.

10 IM FOKUS - TRADITIONELL VS. AGIL

10 Warum Glaubenskriege?

14 Agiles Projekt-Management vs. IT-Service-

Management (Zielstellungen des DevOps-Ansatzes)

18 Testende Entwickler und entwickelnde Tester:

Eine Win-Win-Konstellation

20 Klassisches Konzert mit agilen Partituren

22 Modellierung – agil versus traditionell

32 Traditionell cum Agil -

Am Beispiel Test-Driven Development

36 Die Rolle des agilen Testers im Kampf

gegen technische Schulden

42 SpezifikatiKundenanforderungen erfassen und mit

den richtigen Werkzeugen in ausführbare Tests

umwandeln

44 SCRUM: Untergang der Test Center?

46 Testen mobiler Apps:

ein Paradebeispiel für agiles Vorgehen

12 ISQI-NEWS

Ain’t no mountain high enough! – Das iSQI zertifiziert nun auch

in der Schweiz // Produktvorstellung auf der iqnite Düsseldorf //

Dutch Testing Days: Lange Schlangen vor “Agile”-Vorträgen //

develoPPP.de Entwicklungspartnerschaft: Fachkräftequalifizie-

rung in Israel und Palästina // Alles auf „Agile“ // iSQI on tour

25 SCHULUNGEN UND SEMINARE 2013

30 STANDARD NEWS

30 Nachwuchs bei den „Certified“s

39 UMFRAGE

39 ASQF-Umfrage 2013:

IT-Branche bleibt zuversichtlich

40 GASTKOMMENTAR

40 ISTQB® Partner Program – Appreciating Scheme Adaptors

42 MITGLIEDER

42 Auf zur nächsten Etappe: Neues ASQF-Präsidium gewählt.

8 Interview mit Chris Carter

Ausgabe 27 | Juni 2013 4Inhalt

Das ASQF KarriereportalWir haben den passenden JOB für Sie.

www.asqf.de/stellenangebote.htmlDie ausführlichen Stellenangebote finden Sie auf

Load & Performance Test Analysts (m/w)Atos IT Solutions and Services GmbH, München

Testconsultant (m/w)Atos IT Solutions and Services GmbH, München

Test Analysts (m/w) Atos IT Solutions and Services GmbH, München

(Senior) Product Manager / Product Owner (m/w)hotel.de AG, Nürnberg

Senior Consultant im Bereich Funct. Testing/Testautomatisierung profi.com AG, Berlin

Berater Funktionale Sicherheit (w/m)SynSpace GmbH, Freiburg

Testspezialisten (m/w) ckc group, Braunschweig

Testmanager m/w für den bundesweiten EinsatzSepp.med GmbH, Röttenbach

Softwarearchitekten m/w Sepp.med GmbH, Röttenbach

Softwareentwickler für embedded Systeme m/wSepp.med GmbH, Röttenbach

C# Softwareentwickler m/w Sepp.med GmbH, Röttenbach

IT Berater (HP) m/w für den bundesweiten EinsatzSepp.med GmbH, Röttenbach

C# Softwareentwickler m/w Sepp.med GmbH, Röttenbach

Software Quality Engineer (w/m) CAS Software AG, Karlsruhe

Testmanager (m/w) BITMARCK Holding GmbH, Hamburg

Teamleiter (m/w) - TestarchitekturBITMARCK Holding GmbH, Hamburg

Testmanager (w/m) mit bankfachlichem HintergrundISMC Information System Management & Consulting GmbH, Waldbronn

Softwaretester/Testautomatisierer (w/m)ISMC Information System Management & Consulting GmbH, Waldbronn

Test-Analyst / Tester (m/w) für Soft- und Firmware-tests GETEMED Medizin- und Informationstechnik AG, Teltow

Softwaretester/Mitarbeiter IT Qualitätssicherung (m/w) affilinet GmbH, Hannover

Consultants m/w für modellbasierte Softwareentwicklung MID GmbH, Köln; Nürnberg, Stuttgart

Entwicklungsingenieur (m/w) in Vollzeittecmata GmbH, Wiesbaden

Consultants m/w für modellbasierte Softwareentwicklung MID GmbH, Stuttgart

Consultants m/w für modellbasierte Softwareentwicklung MID GmbH, Nürnberg

Erfahrene Experten und engagierte Young Professionals SQS AG, Köln

Junior Test Manager (m/w) Finance und BankingIT Talentschmiede.com, Rhein-Main Gebiet

Software Test Engineer (m/w)BDC EDV-Consulting GmbH, Wien

Softwareentwickler Webanwendungen CONTACT Software GmbH, Bremen

Softwareentwickler/inGFB EDV Consulting und Services GmbH, Oberursel

Software-Tester (m/w) für die QualitätssicherungGFB Softwareentwicklungsgesellschaft mbH - Q-up, Oberursel

Consultant Testdatenmanagement (m/w)GFB Softwareentwicklungsgesellschaft mbH - Q-up, Oberursel

Tester/Testdesigner (m/w)T-Systems Multimedia Solutions GmbH, Dresden oder Rostock

SOFTWARE-BERATER (m/w)F+S Fleckner und Simon Informationstechnik GmbH, Limburg

SOFTWARE-ENTWICKLER (m/w)F+S Fleckner und Simon Informationstechnik GmbH, Limburg

Web-Anwendungsentwickler (m/w)ReliaTec GmbH, Garching

Software Tester - Testautomatisierung (m/w)DEMIRTAG Consulting GmbH, München

Softwaretester – ISTQB Certified Tester (m/w)DEMIRTAG Consulting GmbH, München

Trainer/in DEMIRTAG Consulting GmbH, Augsburg

Software Tester - Mobile Applikationen (m/w)SOGETI Deutschland GmbH, Hamburg, Düsseldorf, Frankfurt, Stuttgart und München

Software-/ System-Tester – Automotive (m/w)SOGETI Deutschland GmbH, Hamburg, Düsseldorf, Frankfurt, Stuttgart und München

Helden und Heldinnen der C# - EntwicklungCLEAR IT GmbH, Erlangen

Spürnase auf der Suche nach Softwarefehlern (m/w)CLEAR IT GmbH, Erlangen

Barista für einen formvollendeten Java Code (m/w)CLEAR IT GmbH, Erlangen

Mitarbeiter (m/w) im Bereich fachlicher Systemtest Accenture GmbH, Kronberg im Taunus

Testingenieur (w/m) Stryker Leibinger GmbH & Co. KG, Freiburg

Software Testanalyst (w/m) Océ Printing Systems GmbH, Poing

ASQF NEWS

19.06.2013: Rhein-Main Testing Day in Frankfurt am Main

„Open Space“ lautet auch in diesem Jahr wieder der Ansatz der bekannten Reihe aus dem ASQF. Mit seinem offenen Diskussions-Konzept dient der Rhein-Main Testing Day vor allem dem Austausch von Erfahrungen und Best Practices beim Testen. Das Ganze wie gewohnt „aus der Praxis für die Praxis“: Denn bei „Open Space“ sind Sie Vortragender, Mitdiskutierender und Zuhörer gleichzeitig.

PROGRAMM UND ANMELDUNG UNTER: https://www.asqf.de/fachgruppentermine-anzeige/events/id-19062013-7-

rhein-main-testing-day.html.

20.06.2013: MEDICAL DEVICE DAY in Erlangen

Mit dem Leitthema “Klini-sche Bewertungen und Va-lidierung von Software“ fin-det am 20.06.2013 der 4. Medical Device Day in Er-langen statt. Der ASQF-Day wird wieder zusammen mit dem Spitzencluster Medical Valley EMN e.V. und dem Zentralinstitut für Medizintechnik veranstaltet. Die Teilnehmer erwarten Methoden-Vorträge und Erfahrungsberichte, die bewährte als auch innovative Vorgehensweisen bei klinischen Bewertungen, Prüfungen und den unterschiedlichen Validierungs-Szenarien praxis-nah und verständlich erläutern.

PROGRAMM UND ANMELDUNG UNTER:https://www.asqf.de/fachgruppentermine-anzeige/events/id-

20062013-4-medical-device-day-franken-ganztagesveranstaltung.html

Die ASQF-Days: Leuchttürme im Knowhow-Transfer

Ausgabe 27 | Juni 2013 6

10.07.2013: Automation DAY in Nürnberg

Klassisch ist die Automati-sierung zweigeteilt in Em-bedded Steuerungen (prop-rietär) und Tools (Windows). Neu ist der Trend, einen Teil der Tools auf „irgendeinem“ Gerät – sei es ein Smart-Phone, iPad, TabletPC – haben zu wollen und zu können. Wenn ich meinen Kontostand abfragen kann, warum dann nicht auch die Drehzahl meiner Maschine? Die neuen Mög-lichkeiten werfen eine Menge Fragen auf und bieten Vorteile. Doch was gibt es zu beachten und was sind die wirklich rele-vanten Vorteile? „Web-Technologien in der Automatisierung“ lautet daher das Thema des 22. Automation Day.

PROGRAMM UND ANMELDUNG UNTER: www.automationday.de

24.09.2013: Testing-Day Franken in Erlangen

Zum 10-jährigen Jubiläum veranstaltet die ASQF-Fachgruppe Software-Test Franken den „3. Tes-ting Day Franken“ in Erlangen. Unter dem Leit-thema „Testen im innovati-ven Umfeld“ wird ein zweigliedriges Vortragsprogramm ange-boten, das sich ausführlich und vor allem branchenübergreifend mit Business Best Practices und aktuellen Methoden aus dem Bereich Software-Test beschäftigt. Das Themenspektrum reicht von „agilem Testen“ bis hin zu neuen Testautomatisie-rungsmethoden.

PROGRAMM UND ANMELDUNG ZEITNAH UNTER:www.testing-day-franken.de

Im Rahmen der gemeinnützigen Arbeit des ASQF nehmen die ASQF Days einen be-sonderen Stellenwert ein. Sie sind die Leuchttürme, die die Fachkompetenz der ASQF-Themenbereiche in sich bündeln. Die Teilnehmer bringen sich auf den neuesten Stand der Entwicklung und nehmen dabei gleichzeitig praktisches Rüstzeug für den Alltag mit. Alle ASQF-Days werden von einer Fachausstellung begleitet. Für das leibliche Wohl ist jeweils gesorgt.

WWW.TESTING-DAY-FRANKEN.DE24/09/2013

TESTING DAYFRANKENERLANGEN

WWW.AUTOMATIONDAY.DE10/07/2013WWW.ASQF.DE

19/06/2013

TESTING DAYRHEIN-MAINFRANKFURT a.M.

WWW.ASQF.DE20/06/2013ERLANGEN

MEDICAL DEVICE

ASQF NEWS

ASQF-Mitglied sein lohnt sich. Neben den zahlreichen kostenlosen Wissens-angeboten des ASQF erhalten Mitglie-der auf vielen anerkannten Fachkonfe-renzen V o r z u g s p r e i s e auf die Teilnahmegebühren. Aktuell gibt es für folgende Veranstaltungen Vorzugs-preise:

- systems.camp 2013, Köln:

06. Juli 2013 - iqnite Österreich, Wien

12. Juni 2013- iqnite Schweiz,Genf:

25. Juni 2013- ASQT 2013, Graz:

19. - 20. September 2013- iqnite Schweiz, Zürich

24. September 2013- 3. Symposium Software-Architektur,

Ostfildern/Stuttgart:

26. September 2013- agile testing day, Potsdam

28. - 31. Oktober 2013

Günstiges Fach-wissen: Partner-konferenzen mit ASQF-Rabatt+ abilex GmbH, Stuttgart,

www.abilex.de

+ Control€xpert GmbH, Langenfeld,

www.controlexpert.com

+ Macros Consult GmbH, Ottobrunn,

www.macros.de

…und zahlreiche neue persönliche Mitglieder.

www.asqf.de/mitgliedschaft-vorteile.html

Zuwachs: Neue Mitglieder

Einreichung: Deutscher Preis für Software-Qualität

7 Ausgabe 27 | Juni 2013

Der ASQF ruft zu Einreichung für die Verleihung des „Deutschen Preis für Software Qualität“ 2013 auf. Mit dem 2011 erstmals vergeben Preis werden alljährlich diejenigen Personen, Firmen, Initiativen oder Institutionen geehrt, die sich in besonderer Weise dem Erhalt, der Weiterentwicklung oder der For-schung auf dem Gebiet der Software-Qualität verdient gemacht haben. 2011 wurde der Deutsche Preis für Soft-ware-Qualität an Harry M. Sneed ver-geben. 2012 wurde Rudolf van Megen mit dem Preis für sein Lebenswerk ge-ehrt. Der Vorschlag ist in schriftlicher Form (auch elektronisch) als maximal zweiseitiges Dokument an die Ge-schäftsstelle des ASQF in Erlangen (an [email protected]) zu stellen. Er beinhaltet eine klare Begründung des Vorschlages und gibt Referenzen zur Überprüfung der Empfehlung und Leistungen an. Einsendeschluss für Einreichungen ist der 31. August 2013. www.asqf.de/nominierung.html

Ralf Bongard, ISARTALakademie GmbH, zuvor stellvertretender Fach-gruppenleiter, übernimmt sowohl die regionale Fachgruppenleitung Requi-rements Engineering SüdBayern, als auch die Stellvertreterfunktion der gesamten Fachgruppe RE. Gesamt-fachgruppenleiter ist Jens Palluch von der Method Park Software AG. In der regionalen FG Requirements En-gineering in NRW übernimmt Peter Joost, Honeywell, die bisher vakante Position des Stellvertreters.

Neu: Fachgruppenleiter

RICHTIGSTELLUNG: In der Ausgabe März 2013 wurden zum neuen Firmenmitglied GETEMED AG bedauerlicherweise falsche Informationen abgedruckt. Richtig ist: GETEMED AG, Teltow, www.getemed.net.

Sie werben ein persönliches Mitglied und erhalten als Dankeschön das exklusive ASQF-Kochbuch.

Sie werben drei persönliche Mitglieder oder ein Firmen-mitglied. Als Dankeschön können Sie sich ein Buch Ihrer Wahl aus dem dpunkt-Verlag aussuchen.

Werben Sie zehn persönliche Mitglieder oder sogar drei Firmenmitglieder für den ASQF e.V., erhalten Sie als be-sonderes Dankeschön ein iSQI Examen Ihrer Wahl. Wir übernehmen die Prüfungsgebühr für Sie!

Sobald Sie auf dem Mitgliedsantrag eines Neumitgliedes als Werber ge-

nannt werden, nehmen wir Sie auf die Prämienliste auf. Am Ende der Som-

meraktion bekommen Sie vom ASQF e.V. Ihre Prämie entsprechend der

Anzahl der von Ihnen geworben Neumitglieder zugesandt.

www.asqf.de/mitglieder-werben-mitglieder.html

Sommeraktion: Mitglied werben und Prämie sichern

Werden auch Sie Mitglied im ASQF!

Die regionale Fachgruppe Projektmanagement wird ab sofort von Jürgen Andert, Infoteam Software AG und Dr. Wolfram Esser, Method Park Software AG geführt.

www.asqf.de/ansprechpartner.html

Jürgen Andert

Dr. Wolfram Esser

Im Gespräch Ausgabe 27 | Juni 2013 8

Chris Carter is ISTQB president and founder of Planit, one of the biggest testing con-sultancy companies in the world. As a Board Member of the ISTQB and ANZTB, Chris Carter has been a major driver in advancing the Australian and New Zealand testing industries.

Im Gespräch

Stephan Goericke: First of all, congratulations on your presidency. You have got unanimous support from all ISTQB board members. Could you describe where you see the ISTQB now? What is its initial position and its position within the market next to other qualification schemes in the testing field?

Chris Carter: Over the past ten years since establishment, the ISTQB has matured significantly in the market, reaching a level of recognition where it has become the ‘go to’ ac-creditation for anyone who is serious about getting certi-fied in the software testing profession.

The scheme has benefited from the recent release of the 2012 Advanced syllabus updates and the launch of the first two Expert modules, now providing Foundation, Advanced and Expert certificates. It is safe to say that we provide a fairly complete certification program for testers with any level of experience.

Stephan Goericke: Would you say that the ISTQB is a leading standard in the qualification industry and why would you say so?

Chris Carter: I think the numbers speak for themselves. According to our latest reports, we have issued over 280,000 certificates up to the end of 2012. The majority of those are at the Foundation level but we are seeing an increase in progression to Advanced level certification. I’m not fully aware of the latest numbers registered by com-peting or alternative schemes, but our marketing working group tell us that we have a significantly lead not only in terms of numbers but also in terms of the quality and rele-vance of the certifications we offer.

Stephan Goericke: Looking to the future, surveys that have been conducted showed a slight decrease of the ISTQB qualification and the demand in the market. Do you agree on this or where would you see the ISTQB in the next two years and what is the trend in the market?

Chris Carter: I’ve heard comments that the ISTQB is dimi-nishing in terms of its appeal but quite frankly the reality is completely the opposite. In fact, I see the momentum in-creasing having registered a record number of certificates issued in our most recent quarter.

Indications globally are also very encouraging. The ISTQB is an international scheme with 47 member boards of dif-ferent levels of maturity that have been operating for diffe-rent periods of time. Many of the more recently established

boards are showing a huge upturn in the number of people that are adopting the ISTQB in their markets, driving signi-ficant growth globally. So I see this trend only continuing.

There is a demand in the market place among employers and employees alike. So we appeal to both those who are looking for skilled software testers and those who are loo-king to be software testers..

Stephan Goericke: If you, as president, set up three mi-lestones for the next years, what will come next and what are the main topics?

Chris Carter: Although I may be new to the Presidency this will be my fourth term elected to the ISTQB executive, so I am aware of the strategic direction and will continue to drive it forward. We held a strategy meeting in 2012 where we identified the three key areas we wanted to address. This includes product development as we look to introduce new and increasingly relevant certifications to the market. We will also look to implement improvements to the ways in which the ISTQB works as an organisation to release high-end products more efficiently. Finally, we will look to improve engagement with the our clients at both the indivi-dual and organisational level. So the three areas that we’re certainly looking at are the testing community, the ISTQB product base and the ISTQB organisation.

Stephan Goericke: You´re also running one of the big-gest testing consultancy companies in the world, if somebody ask you to give him three reasons why to get employees certified with the ISTQB, which three rea-sons would you mention?

Chris Carter: First thing is the relevance of the ISTQB - it is a global scheme that encourages international standardi-sation of skills, advocating testing best practice. Secondly, if you are an organisation, employing certified people gives you a certain degree of assurance that the people you are engaging have achieved a measurable level of competency within the discipline of software testing. Thirdly, if you are an individual and you want to work in software testing, the ISTQB framework sets you in the right direction for your career, building the foundations in testing and provding a strong career path going forward.

Stephan Goericke: Thank you!

Mit dem neuen Präsidenten des ISTQB sprach Stephan Goericke.

Interview mit Chris Carter, der neue Präsident des ISTQB


In der letzten Zeit ist man oft mit den verhärteten Stand-punkten in Bezug auf die Auswahl der Software-Entwick-lungsmodelle konfrontiert. Es wird sehr gerne das eine oder andere Software-Entwicklungsmodell als Allheilmit-tel dargestellt. Oft hört man von den Anhängern der klas-sischen Entwicklungsmodelle, dass die agilen Methoden nur zur Chaos führen. Umgekehrt vernimmt man von An-hängern der agilen Vorgehensmodelle oft: „Seitdem ich mit agiler Methode gearbeitet habe, möchte nicht mehr nach einem klassischen Modell arbeiten“. Es herrschen teilweise „Religionskriege“, ideologische Diskussionen und eine ri-gide Entweder-oder-Sichtweise in Bezug auf die Wahl des Entwicklungsmodells.

Woher kommen diese extremen Einstellungen?

Es gibt leider keine Anwender-Altersstatistik der verschie-denen Entwicklungsmodelle im deutschsprachigen Raum. Auch existiert keine Statistik bezüglich des Bestehensal-ters der Unternehmen und der bei ihnen eingesetzten Ent-wicklungsmodelle. Diese beiden Aspekte wurden bei der Testumfrage vom Jahr 2011 [1], die im letzten Jahr durch-geführt wurde, nicht berücksichtigt. Da es keine fundierten Informationen bezüglich der Alters-gruppe der Anwender verschiedener Entwicklungsmodelle gibt, kann daher nicht von einer eindeutigen Korrelation der eingesetzten Entwicklungsmodelle mit dem Alter der Anwender ausgegangen werden. Auch lassen sich keine Trends für die Zukunft prognostizieren.

Allerdings ist es eine bewiesene Tatsache, dass generell bei vielen Menschen im höheren Alter die Bereitschaft, Neues zu lernen abnimmt [2]. Im Allgemeinen hat die ältere Generation auch in der IT-Branche eine weniger motivierte Haltung für den Einsatz neuer Modelle oder Technologien. Einer von vielen möglichen Gründen, warum Traditiona-listen meinen könnten, dass sie einen besseren Glauben oder eine Schule als die Agilisten besitzen, könnte darin liegen, dass sie zu jener Generation gehören, die außer klassischen Phasenmodellen keine andere Modelle kennen oder sich nicht richtig mit dem agilen Modell auseinander-gesetzt haben.Auf der anderen Seite ist im Manifest für „Agile Software-entwicklung“ festgehalten: „Wir erschließen bessere Wege, Software zu entwickeln, indem wir es selbst tun und ande-ren dabei helfen“ [3]. Die Einstellung, mit agilen Modellen die „besseren Wege“ zu bestreiten, behält sich den An-spruch, das bessere Entwicklungsmodell zu sein vor. Dies könnte auch ein Grund dafür sein, dass die Agilisten glau-ben, eine bessere Schule als Traditionalisten zu haben.

Die Extreme auf der theoretischen oder praktischen Ebe-ne bei der Auswahl eines Modells zur Abwicklung eines Software-Entwicklungsprojekts (inklusiver Behandlung von Testthemen und –aktivitäten) können sicher nicht ziel-führend und nützlich sein.

Situationsbezogenes Vorgehen

Das Teilen des gesamten Entwicklungsvorhabens in Pha-sen oder Iterationen (und Inkrementen) muss wohlüberlegt und ausgeführt werden. Es soll je nach aufgestellten Be-dürfnissen und Anforderungen sowie dem Vorhandensein bestimmter Rahmenbedingungen das geeignete Modell für eine spezifische Situation ausgewählt werden. Die Vorge-hendmodelle sollen wertfrei beobachtet werden. Es muss für jede Situation evaluiert werden, welches Modell den gestellten Anforderungen besser gerecht werden und die vorherrschenden Rahmenbedingungen am geeignetsten bewältigen kann. Daher schlägt der Autor das situations-bezogene Vorgehen vor. Es gibt kein Rezept, das immer und überall einzusetzen und gültig wäre. Prof. M. Broy (TU-München) meint in diesem Zusammenhang „Wenn ich Software für den Eurofighter erstellen soll, würde ich die nicht agil entwickeln. Aber für eine Internet-Anwendung, die noch sehr viele Fragen offen lässt, würde ich wahr-scheinlich sehr agil vorgehen, erst einen Prototyp einführen und die Dinge ausprobieren.“ [4]

Tailoring

Ein weiterer wichtiger Punkt ist das Tailoring des bereits situationsbezogen gewählten Modells, um dieses optimal an die gegebenen Bedürfnisse anzupassen und damit die größte Effizienz bei dem Entwicklungsvorhaben herauszu-holen. Es sind gewisse Praktiken bei beiden Entwick-lungsmodellrichtungen, die bestimmte Aspekte bei der Software-Entwicklung besonders betonen und behandeln. Tailoring ist ein sinnvoller Weg für die effiziente Abwicklung von Projekten, statt ideologische Kriege zu führen und un-flexibel Entscheidungen zu treffen. Die folgenden Praktiken könnten situationsbezogen von agilen oder klassischen Modellen jeweils in das andere Modell übernommen wer-den. Die folgenden Praktiken beziehen sich hauptsächlich auf das V-Modell und Scrum.

Agile Praktiken, die in ein klassisches Phasenmodell integriert werden können:

Daily Stand-up-Meeting: Diese Praktik ist bei einem Scrum-Team mit der Teilnahme des gesamten interdiszi-plinär besetzten Teams mit Scrum-Master durchzuführen.

Warum Glaubenskriege?

Im Fokus

Dr. Mohsen Ekssir


Um die Kommunikation zu verstärken, kann aber diese Praktik ohne weiteres bei einem z. B. nach dem V-Modell entwickelten Softwareprojekt eingesetzt werden. Da die Entwickler und Tester generell nicht im selben geographi-schen Raum arbeiten, kann diese Praktik separat für das Entwickler- und/oder Testteam durchgeführt werden.

Schnelles Feedback: Bei diesem Grundpfeiler des agi-len Entwicklungsmodells geht es darum, schnelles Feed-back zu erreichen. Mit schnellem Feedback ist es mög-lich, rasch auf die neuen Bedürfnisse oder Veränderungen seitens der Kunden oder auch auf Qualitätsprobleme zu reagieren. Schnelles Feedback ist ein guter Mechanismus, der auch bei sequentiellen Entwicklungsmodellen aufge-nommen werden kann. Schnelles Feedback kann mit der Durchführung des explorativen Tests (z. B. durch einen Fachbereichsmitarbeiter) vor dem tatsächlichen struktu-rierten Test (vor jeder Teststufe oder sogar vor jedem Test-zyklus) geliefert werden. Der explorative Test kann nach einem erfolgreichen Smoke-Test (als Eingangskriterium) durchgeführt werden.

Klassische Praktiken, die in ein agiles Modell integriert werden können:

Rollen: Agile Teams sind interdisziplinär besetzt und ha-ben keine formalen Rollen. Hinsichtlich des Qualitätsma-nagements arbeiten die Teams nach agiler Vorgehenswei-se bottom-up, im Gegensatz zu den klassischen Modellen, die top-down arbeiten. Besonders bei der Umstellung vom klassischen Vorgehen auf eine agile Organisationsweise kann die organisatorische Verankerung der Qualitätssiche-rung (QS) verloren gehen. Dies würde bei agilen Projekten nach ein paar Sprints zu massiven Qualitätsproblemen führen [5]. Abhilfe kann dabei geschaffen werden, indem bestimmte Rollen für QS wie die Rolle Test-Designer (für die Bestimmung der abstrakten Testszenarien und Erstel-lung der präzisen Akzeptanzkriterien) mit einer eindeutigen Personenzuordnung definiert werden.

Rückverfolgbarkeit: Die Rückverfolgbarkeit bei den agilen Projekten kann eine Herausforderung darstellen. Denn bei der agilen Vorgehensweise sind Änderungen willkommen und können sehr häufig passieren. Allerdings muss bei kritischen Softwaresystemen die Rückverfolg-barkeit von Anforderungen über Implementierungen bis hin zu Testergebnissen möglich und zu jeder Zeit gegeben sein. Daher ist es zum Teil erforderlich, werkzeuggestützt jede Änderung ausgehend vom Anlass der Änderung über das Ergebnis der Impact-Analyse bis zum Ergebnis der Änderung rückverfolgbar zu gestalten und zu dokumen-tieren. Bei der Dokumentation muss überlegt werden, wie granular diese zu erstellen ist, damit es kein unnötiger bü-rokratischer Buchführungsaufwand generiert wird [5].

Traditionell vs. Agil

Dr. Mohsen Ekssir ist Bereichsleiter Software Test

und Qualitätssicherung bei BDC EDV-Consulting.

Er ist sowohl ISTQB® Certified Tester (Full Advan-

ced Level) als auch Certified Agile Tester (CAT®).

Fazit

Der Expressionismus und der Impressionismus waren zwei Malereirichtungen in der bildenden Kunst des 19. und 20. Jahrhunderts, die ziemlich zeitgleich entstanden und nebeneinander von den Künstlern für den Ausdruck ihrer Erlebnisse oder individuell wahrgenommener Sin-neseindrücke benutzt wurden, ohne das Wesen und Da-sein des anderen in Frage zu stellen. Warum sollen die agile und klassische Vorgehensweise sich nicht auch so verhalten können?Ob ein Softwareentwicklungsprojekt nach einer agilen oder klassischen Vorgehensweise abzuwickeln ist, da-rüber sollte situationsbezogen entschieden werden. Das Tailoring des ausgewählten Modelles kann noch zur Effi-zienzsteigerung des Abwicklungsprozesses führen. Dabei können einige Praktiken der agilen Vorgehensweise in das klassische Phasenmodell übernommen werden und vice versa.


L ITER ATUR : [1]Umfrage 2011: Software Test in der Praxis, dpunkt.verlag, 2012 [2] Rosemarie Kurz, Lebens langes Lernen als Chance und Herausforderung für ältere Menschen - http://generationen.oehunigraz.at/files/2012/07/Munition-Bildung.pdf – 23.04.2013 [3] Manifest für Agile Softwareent-wicklung: http://agilemanifesto.org/iso/de/ - 17.04.2013 [4] Richard Sietmann, c’t magazin - http://www.heise.de/ct/artikel/Extrem-massgeschneidert-289778.html - 17.04.2013 [5] Tilo Linz, Testen in Scrum-Projekten, dpunkt.verlag, 2013

iSQI NEWS

Seit dem 01.04.2013 haben Schweizer Software-Tester die Möglichkeit, die ISTQB® Certified Tester Foundation und Advanced Level Prüfung beim iSQI abzulegen. Damit öffnet das Swiss Testing Board (STB) den Markt für eine weitere Zertifizierungsstelle. Das iSQI freut sich auf die Zusammenarbeit mit dem STB und den akkreditierten Trai-ningsanbietern. In der Zusammenarbeit mit dem iSQI können die Trainingsanbieter Foundation Level Prüfungen papierba-siert in Deutsch, Englisch und Französisch sowie Advanced Level Prüfungen in Deutsch und Englisch anbieten.

Seit Mitte April besteht die Möglichkeit, die Prüfungen auch als E-Examen in einem der 30 Schweizer Test Center des iSQI-Partners Pearson Vue abzulegen.

WEITERE INFORMATIONEN UNTER: www.pearsonvue.com/isqi

Zwei neue Produkte stellte das iSQI auf der diesjährigen iqnite in Düsseldorf vor. Zum einen das Agile Essentials Weiterbildungs- und Zertifizierungsprogramm, welches al-len Projetteilnehmern im agilen Umfeld einen komprimierten Einblick in das agile Arbeiten gibt. Das interessierte vor Ort besonders Projekt- und Qualitätsmanager sowie Berater und Entwickler. Im Bereich Testen bringt das iSQI gemeinsam mit der Spe-cial Interest Group „Model Based Testing“ (SIG MBT) den Certified Model Based Tester auf den Markt. Interessier-te Trainingsprovider konnten bereits am Mittwoch auf der iqnite beim “Meet the Expert“ Event ihre Fragen an Dr. Armin Metzger, SIG MBT, richten.

Mit iSQI näher ans Ziel – das konnten wir in den drei Tagen den Besuchern unseres Standes auf der iqnite erfolgreich vermitteln. Die Nachfrage nach Spezialisierungen in der Wei-terbildung ist groß. iSQI kommt dieser Entwicklung mit dem Agile Essentials und dem MBT Kurs nach.

Über 200 Teilnehmer besuchten am 17. April die Dutch Tes-ting Confrence in Bussum, Niederlanden. Das Programm enthielt exzellente Keynotes zum Branchenthema Nr. 1 „Agi-le“ sowie aus Schlüsselbereichen zwischen Testen und Busi-ness. Die Vortragsthemen fokussierten sich auf Agile, Test Automatisierung, Cloud und Test Center of Excellence, wo-bei sich gerade vor den „Agile“ Vorträgen lange Schlangen bildeten. Die Dutch Testing Days belegten die große Rele-vanz des Niederländischen Marktes und gaben dem iSQI die Chance Kunden zu treffen und sich über die neusten Trends im Bereich Software Testing und „Agile“ auszutauschen.

Ain’t no mountain high enough! – Das iSQI zertifiziert nun auch in der Schweiz

Produktvorstellung auf der iqnite Düsseldorf

Dutch Testing Days: Lange Schlangen vor „Agile“-Vorträgen


iSQI NEWS

develoPPP.de Entwicklungspartnerschaft: Fachkräftequalifizierung in Israel und Palästina

Ende April reiste Geschäftsführer Stephan Goericke ge-meinsam mit einer Unternehmerdelegation aus Potsdam nach Israel und Palästina. Als Mitglied der Entwicklungs-partnerschaft des develoPPP.de Programms der DEG - Deutsche Investitions- und Entwicklungsgesellschaft mbH trieb Goericke die Entwicklungen des im letzten Jahr ange-stoßenen Qualifizierungsprojektes voran. Bereits 2012 un-terstützte das iSQI in Zusammenarbeit mit der Deutschen Gesellschaft für Internationale Zusammenarbeit (GIZ) GmbH palästinensische Trainingsanbieter bei der Akkreditierung für das Ausbildungsschema ISTQB® Certified Tester.

Dieses Mal beriet Goericke lokale Unternehmen zum Thema Fachkräftequalifizierung im IT-Bereich und unterstützte den ersten „ISTQB® CTFL Train the Trainer“-Kurs mit 14 Teil-nehmern neuer Partner-Unternehmen. Der Kurs fand vom 28.04.2013 bis 02.05.2013 an der Birzeit University, Paläs-tina statt. Durch die Kurse werden lokale IT-Fachkräfte zu Trainern ausgebildet. Langfristig wollen wir in unser Zusam-

JUNI

05.-07.06.2013| iSQI @ Nordic Testing Days | Tallin, Estland

12.06.2013| iSQI @ iqnite | Wien, Österreich

25.06.2013| iSQI @ iqnite | Genf, Schweiz

JULI

25.-27.07.2013| iSQI @ EuroSPI | Dundalk, Irland

AUGUST

23.08.2013| iSQI @ ISTQB® Hauptversammlung | Helsinki, Finnland

iSQI on tour


Das zweitägige Training „Agile Essentials“ folgt dem seit 2011 erfolgreich laufenden „CAT – Certified Agile Tester“ und wendet sich an alle, die im Bereich Software Engineer-ing involviert sind und sich mit dem agilen Umfeld vertraut machen möchten. Zu dieser breiten Zielgruppe gehören Projekt- und Qualitätsmanager, Software Development Managers, Businessanalysten, Entwickler und Tester. Auch im gehobenen Projektmanagement Tätige, wie zum Beispiel Projektmanager und IT-Leiter, profitieren von die-

Alles auf „Agile“

menarbeit helfen eine gute Qualifizierung der Fachkräfte zu gewährleisten. So stehen die Chancen gut, Palästina zu einer attraktiveren Out-Sourcing Region zu machen.WEITERE INFORMATIONEN UNTER [email protected]

sem Kurs, in dem sie ein fundamentales Verständnis der agilen Techniken erhalten. Der Erfolg eines Projekts, das ei-nem agile Ansatz folgt, hängt nicht nur von den Fähigkeiten und Erfahrungen der Teammitglieder ab, sondern auch von dem Verständnis und dem Bewusstsein über Agilität aller an dem Projekt Beteiligten wie den Mitgliedern des Projekt-teams und der Nutzergruppe, dem Management und den Stakeholdern. Die Entscheidung, mit agilen Methoden zu arbeiten, wirkt sich auf das Projekt und dessen Manage-ment wie auch auf deren Umfeld aus. „Agile“ ist weltweit auf dem Vormarsch und da noch rela-tiv neu, gibt es aktuell im Verhältnis wenige Fachkräfte mit praktischer Erfahrung. Um die Nachfrage nach agilen Spe-zialisten zu decken und ein einheitliches Verständnis für die Methoden wie auch Begrifflichkeiten und Terminologien aller im Projekt oder in einer Organisation Beteiligten zu entwick-eln, sind Schulungen gefragt, in denen die entsprechenden Fähigkeiten ausgebildet werden und ein Konsens entstehen kann. Das neue Agile-Essentials-Training zielt darauf ab, die Kenntnisse und Einsichten zu vermitteln, die für diese weiter gefasste Gruppe aller Beteiligten im Zusammenhang mit dem Projekt erforderlich sind. Agile Essentials bietet daher einen hervorragenden Überblick über die grundlegenden Konzepte von Agilität.

WEITERE INFORMATIONEN ZU KURSINHALTEN UND TRAININGSANBIETERN UNTER www.agileessentials.org

Foto: © T. B

raune

Motivation

Agile Methoden zur Softwareentwicklung haben sich ins-besondere für die Entwicklung moderner Anwendungen, wie z.B. webgestützte Systeme oder aber bei „Apps“ für mobile Endgeräte durchsetzen können. Weite Verbreitung haben die Methoden Scrum und eXtreme Programming (XP) gefunden. Es stellt sich die Frage, wie unter agilen Bedingungen ein Übergang von der Entwicklung zum Wirkbetrieb gestaltet werden kann. Eine sehr kritische Betrachtung dieser Herausforderung findet sich unter [Stoll 2008]:„Traditionelle IT-Prozesse bremsen die agile Entwicklung, und zwar gewaltig. Starre Rollen und Prozessmodelle, wie sie mit ITIL Einzug in die Unternehmen gefunden haben, passen nicht zu Scrum: Sie schaffen komplexe, schwerfäl-lige Strukturen und Abläufe, wo Unternehmen auf flexible, verantwortliche Zusammenarbeit angewiesen sind.“Lange wurde eine hohe Prozessreife innerhalb des IT-Le-benszyklus mit qualitativ hochwertigen IT-Services gleich-gesetzt, die auch aus wirtschaftlicher Sicht determinierbar erschienen. Sowohl für die Softwareentwicklung als auch für die betrieblichen Aufgabenstellungen des IT-Service-Managements entstanden daher komplexe Prozessbe-schreibungen, die für sich einen „best practice“-Ansatz beanspruchen. Trotz der zunehmenden Prozessreife exi-stieren nach wie vor Probleme bei der Bereitstellung von IT-Lösungen, die nicht selten an der Schnittstelle zwischen Entwicklung und Betrieb entstehen (vgl. [Kim 2013]).

Ausgangssituation und Abgrenzung

Agile Softwareentwicklung

Der Agilitätsbegriff wird mit einer schnellen, kostengün-stigen und qualitativ hochwertigen Implementierung von Software in Verbindung gebracht. In diesem Zusammen-hang wird auch von einer Entbürokratisierung der Soft-wareentwicklung und dem Verzicht einer dokumenten-getriebenen Vorgehensweise gesprochen. Durch die Annnahme einer flachen Aufwandskurve ist der Aufwand für umzusetzende Anforderungen unabhängig vom Zeit-punkt ihres Eintreffens. Diese Annahme kann allerdings nur mit Hilfe einer aus Sicht der Wartung guten Software-architektur gewährleistet werden. Die folgenden Praktiken sind allen agilen Vorgehensweisen gemein:- Iterative bzw. zyklische Vorgehensweisen mit einem

Wechselspiel kurzer Planungs- und Entwicklungsphasen

- Berücksichtigung eines zeitnahen und, wenn möglich, unmittelbaren Feedbacks durch den frühzeitigen Syste-meinsatz.

Fragen des späteren Wirkbetriebs (speziell IT-Service-Ma-nagement) berücksichtigen Publikationen im Kontext der agilen Softwareentwicklung zumeist nur am Rande. [Röps-dorf 2012] geht in diesem Zusammenhang auf einen nicht unumstrittenen „Release-Sprint“ ein. Ziel dieses speziellen Sprints ist es, alle für die Operativstellung des Releases noch offenen Fragen zu klären. Genannt werden z.B. benö-tigte Gesamtintegrationstests, benötigte Datenmigrationen, Fragen der Softwareverteilung und konfiguration oder aber Aufgaben des organisatorischen Veränderungsprozesses.

IT-Service-Management

Im Mittelpunkt des IT-Service-Managements steht die sta-bile und qualitativ nachhaltige Bereitstellung kundenwirk-samer IT-Services unter Berücksichtigung der zur Verfü-gung stehenden Ressourcen bzw. vertraglich zugesicherter Serviceeigenschaften. Um diese Zielstellung zu erreichen, bedarf es effizienter Prozessabläufe mit klaren Verantwort-lichkeiten. Mit ITIL (Information Technology Infrastructure Library - Urheber: IT Service Management Forum) findet sich ein weltweit akzeptierter Ansatz zur Strukturierung der dafür benötigten Prozesse und Aktivitäten. Dabei wird auch auf organisatorische Aspekte bzw. verwendbare Methoden, Techniken und Tools eingegangen. [ITIL 2008]Aus den praktischen Erfahrungen des Autors existiert eine Reihe von Problemen in der Verwendung des ITIL-Ansatzes:- Ungenügende Orientierung auf die Unternehmensziele- Falsch verstandener Perfektionismus- Werkzeuggetriebene Betrachtung- Mächtigkeit der ITIL-Prozesse behindert Kreativität - ITIL als marketingorientierter Selbstzweck- Zertifizierungswahn beteiligter Spezialisten.

[Spiegelhoff 2011] fasst die aufgeführte Kritik sehr ge-lungen zusammen: „Welche Methode letztendlich auch für die Einführung gewählt wird, ich halte es für wichtig, dass nicht die Einführung von ITIL zum Hauptziel mutiert. Statt-dessen sollte auf die Themen geschaut werden, wegen de-rer man ITIL einführen möchte.“

Es sei darauf hingewiesen, dass die Verfasser des ITIL-Frameworks keinesfalls eine Berücksichtigung aller „good practices“ einfordern. Erfolgreiche Unternehmen benutzen

Agiles Projekt-Management vs. IT-Service-Management (Zielstellungen des DevOps-Ansatzes)

Im Fokus

Andreas Schmietendorf


dieses Framework eher als Diskussionsgrundlage für die bereits seit langen etablierten Vorgehensweisen und nicht als „Blaupause“ für die Etablierung einer ITIL-konformen Organisation. Der letzt genannte Aspekt war auch die Ursa-che dafür, dass Zertifizierungen ausschließlich für natürliche Personen (keine Organisationen) vorgesehen werden.

Hintergründe zu DevOps

Die Idee zur wechselseitigen Berücksichtigung entwick-lungs- und betriebseitiger Belange kann auf eine lange Hi-storie zurückblicken. Firmenspezifische Vorgehensmodelle betrachteten schon zum Anfang der 90-er Jahre den ge-samten Lebenszyklus eines Softwaresystems. Die organi-satorische Separierung entwicklungs- und betriebsseitiger Aufgabenstellungen war insbesondere den steigenden Anforderungen einer wirtschaftlichen Transparenz und zu-nehmenden Industrialisierung der IT geschuldet. Die an-bieterseitige Diversifikation der verwendeten IT-Lösungen (z.B. Einsatz von Cloud Services) verschärft die benötigten Abstimmungen zwischen Entwicklung und Betrieb. Darüber hinaus können extrem kurze Bereitstellungszeiten (2-3 Wo-chen) bei mobilen Anwendungen (Apps) beobachtet wer-den, auch hier ist die parallele Berücksichtigung entwick-lungsseitiger und betrieblicher Anforderungen unerlässlich.

Eine treffende Problembeschreibung zur Lücke zwi-schen Entwicklung und Betrieb findet sich unter [App-leton 2010]: „Until it is released (in the hands of end-users), new developments are “inventory”, to use the lean software term – you have invested time, effort and resources in ma-king changes, but no value is realised for the organisation until any development is actually released and being used by the end-users.” Die DevOps-Bewegung („Developers & Operations“) ver-sucht diese Lücke zu schließen. Im Sinne agiler Projekt-managementansätze sollen in die IT-Leistungserbringung involvierte Organisationen motiviert werden, miteinander zu kommunizieren. Darüber hinaus sollten Entwicklungs- und Einführungsprojekte mit demselben Kundenbezug koope-rativ bearbeitet und betriebliche Belange frühzeitig berück-sichtigt werden.In Anlehnung an [Peschlow 2012] bzw. [Appleton 2010] lassen sich folgende Aufgaben zur Ausgestaltung von DevOps-Beziehungen identifizieren:- Kundenorientierte Positionierung der gesamten IT-Lösung- Gestaltung der Schnittstelle zwischen Entwicklung und

Betrieb- Gewährleistung einer konstruktiven und analytischen

Qualitätssicherung- Automatisierung benötigter Softwaretests- Automatisierung von Deployment- und Integrations-Pro-

zessen- Identifikation betroffener Prozesse (kein ITIL-Zwang!)- Analyse von Chancen und Risiken agiler Vorgehensweisen.


Andreas Schmietendorf arbeitet als Professor für

Wirtschaftsinformatik an der HWR Berlin und

als Privatdozent (Software-Engineering) an der

OvG-Universität Magdeburg. Die Industrie berät er

zu Fragen der Softwarequalität, komplexen Inte-

grationsarchitekturen und zum Cloud-Paradigma.

Im Jahr 2006 rief er die durch die ASQF, ceCMG,

DASMA und GI unterstützte BSOA-Initiative (Be-

wertungsaspekte serviceorientierter Architektu-

ren) ins Leben.


Im Fokus

Die erreichbare Agilität innerhalb des IT Service-Manage-ments hängt insbesondere von der Komplexität beste-hender Hard- und Softwarearchitekturen ab. Nicht selten führen eng gekoppelte Systeme bzw. die Nutzung pro-prietärer Leistungsmerkmale (z.B. herstellerspezifische Funktionalitäten mobiler Endgeräte) zur Erhöhung der Zeiten für die Einführung einer neuen Softwareversion.

Anwendbarkeit agiler Methoden

Grundlegende Überlegungen

Der Vergleich agiler und klassischer Methoden zur Soft-wareentwicklung bedarf einer Versachlichung. Noch im-mer existiert bei Banken und Versicherungen eine Vielzahl von Altsystemen, die sich dem Einsatz agiler Methoden weitgehend entziehen. Gründe, die dort gegen den Ein-satz agiler Ansätze sprechen, liegen z.B. bei erfolgreich eingespielten Softwareproduktionsumgebungen, hoch komplexen Anwendungsarchitekturen oder aber bei der Komplexität bzw. erreichbaren Effizienz des Build-Pro-zesses. Darüber hinaus spielen auch die Sensibilität einer Anwendung, Fragen der Compliance oder sicherheits-technische Erwägungen eine Rolle für die Auswahl einer Vorgehensweise.

Abbildung 1: Präferenzen zum Einsatz agiler und klassischer Methoden

In Umfragen (vgl. [Komus 2012]) zur Verbreitung agiler Me-thoden kann zumeist eine Mischform beider Ansätze be-obachtet werden. Während agile Methoden insbesondere bei der Implementierung benutzerorientierter Lösungen (Front-End) ihren Schwerpunkt haben, kann bei transak-tions- bzw. geschäftskritischen Systemen (Back-End) eher der Einsatz klassischer Methoden ausgemacht werden (vgl. Abbildung 1).

Bedarf eines agilen Service Designs

Aus Sicht des Autors wird ein agiles und risikogetriebenes Service Design benötigt, welches aus fachlicher Sicht ent-lang des Wertes und der Kritikalität eines IT-Services zu steuern ist. Zur häufigen Einführung von Softwareversionen (Releases) bedarf es der organisatorischen und technolo-gischen Schnittstellengestaltung zwischen Entwicklung und Betrieb. Im Mittelpunkt stehen dabei Aufgaben wie ein agi-les Testen (vgl. Certified Agile Tester der ASQF), die kontinu-ierliche Integration entsprechender Softwareversionen oder aber eine automatisierte Anpassung der einhergehenden Service-Managementprozesse.

Abbildung 2: DevOps – Vermittler zwischen Agilität und Stabilität

Zusammenfassung

Der fachliche Kunde bzw. Nutzer eines IT-Service interes-siert sich nur für den wirtschaftlichen Impact, nicht aber für Details der dahinter liegenden Lieferantenkette. Aus Sicht des Autors hängt die erreichbare Agilität zur Bereitstellung von IT-Services maßgeblich vom Selbstverständnis des IT-Managements (speziell Architekturmanagement) ab, da dort sämtliche Aufgabenstellungen der informationstechnischen Versorgung eines Unternehmens verantwortet werden. Die Verantwortung dafür kann nicht an einen externen Anbie-ter vergeben werden, sehr wohl aber die Erbringung der dafür benötigten Leistungen. Damit einher sollte auch die Forderung für eine agile Prozessgestaltung für Entwickler- und Betreiberseiten gehen. Für erfolgreiche IT-Projekte ist es entscheidend, inwieweit eine integrierte Betrachtung der Belange entwicklungs-, integrations- und betriebsseitigen Aufgabenstellungen im Kontext eines PDCA-Ansatzes (Plan – Do – Check – Act) erfolgen kann.

VERWENDETE QUELLEN [Appleton 2010] Appleton, B.; Berczuk, S.; Cowham, R.: Agility Throug-hout the LifeCycle: The Rise of DevOps, CM Crossroads, October 19, 2010 [ITIL 2008] IT Service Management basierend auf ITIL V3, ITSM Library, Van Haren Publishing, Zaltbommel/NL, August 2008[Kim 2013] Kim, G.; Behr, K.; Spafford, G.: The Phoenix Project – A Novel About IT, DevOps, and Hel-ping Your Business Win [Komus 2012] Komus, A.: Studie: Status Quo Agile - Verbreitung und Nutzen agiler Methoden, BPM-Labors der HS Koblenz, www.status-quo-agile.de, Abruf April 2013 [Peschlow 2012] Peschlow, P.: Die DevOps-Bewegung – Was ist das eigentlich und was bedeutet es für uns?, Ja-vamagazin 1.2012 [Röpsdorf 2012] Röpsdorf, S.; Wiechmann, R.: Scrum in der Praxis – Erfahrungen, Problemfelder und Erfolgsfaktoren, dpunkt.verlag, Heidelberg 2012 [Spiegelhoff 2011] Spiegelhoff, J.: Kann Agilität bei der ITIL Einführung helfen?, August 9, 2011 http://blog.codecentric.de/2011/08/kann-agilitat-bei-der-itil-einfuhrung-helfen [Stoll 2008] Stoll, D.: Entwicklungsfalle - Traditionelle IT bremst agile Teams in der Software-Entwicklung, http://aliando.com, Abruf April 2013


Back-End Orientiert

Mainframe

Front-End Orientiert

Laptop

AgileMethoden

Klassische

Methoden

Stabilität

Flexibilität

StabilitätAgilitätQualitätssicherung

Agiles TestenKonfiguration-Management

Fehler-ToleranzKontinuierliche Integration

Änderungen alsHerausforderung

Änderungen alsBedrohung

SW-Entwicklung IT-Betrieb

Architekturmanagement

fachlicher Nutzen - Business

Prozesse, Daten, Integration, Service

HäufigeReleases

Advertorial17 Ausgabe 27 | Juni 2013

Testen im SAP UmfeldNichts Besonderes und doch irgendwie anders

Auswahl der TestdatenFür funktionale Tests ist die Auswahl der richtigen Testdaten schwie-

rig und von Teststufe und -fokus abhängig. Künstliche Daten können

sinnvoll für einen automatisierten Regressionstest sein und gleichzeitig

unbrauchbar für den Test von Jahresabschlüssen, bei denen Bestands-

daten notwendig sind. Zudem stellt sich bei der Nutzung von Produkti-

onsabzügen die Frage, ob ein Komplettabzug benötigt wird, ein Teilabzug

ausreichend ist oder ob sogar speziell definierte Datenabzüge genügen.

Ebenso muss beachtet werden, wie die Datenabzüge aktuell gehalten

und zurückgesetzt werden können.

Auswahl geeigneter Selektionskriterien für den Aufruf von TransaktionenFunktionalität und Komplexität von SAP Transaktionen ist unterschiedlich.

Das geht z.B. von der Anzeige von Daten im Displaymodus bis zum Aus-

führen von Massenläufen. So ist es beim Ausführen von Transaktionen

entscheidend, wie die in SAP zur Verfügung stehenden Selektionskriterien

geschickt so genutzt werden, dass durch die Einschränkung die richtigen

Testdaten benutzt und das erwartete Ergebnis geprüft werden kann. Denn

ein Massenlauf über das Komplettsystem kann die Testdaten empfindlich

verändern und im schlimmsten Fall für weitere Tests unbrauchbar machen.

Zudem kann es beispielsweise beim Aufruf von Reports zu frustrierenden

und unnötigen Wartezeiten für den Tester kommen.

Auswahl / Anlegen von Test-UsernSAP hat ein umfangreiches Berechtigungskonzept. Im Vorfeld ist es da-

her wichtig zu klären, welcher User welche Geschäftsprozesse ausführt

bzw. welche Transaktionen prüft. Meist ist es nicht sinnvoll mit umfas-

senden Berechtigungen zu testen sondern alle Test-User entsprechend

den Nutzern des Produktivsystems einzurichten. Damit können dann auch

Negativ-Tests, wie gesperrte Transaktionen für bestimmte User oder ein

Vier-Augen-Prinzip zur Freigabe von Zahlungen, überprüft werden.

Auswahl des TestwerkzeugsNicht immer sind die SAP-Standardwerkzeuge die erste Wahl. So ist

es z.B. bei Testautomation wichtig, dass das Werkzeug optimal auf das

Projekt abgestimmt ist und nicht nur aus Bequemlichkeit auf den eCatt

zurückgegriffen wird. Mitzutestende Randsysteme können den Bedarf

ganz anders gestalten, als der Test eines einzelnen SAP-Moduls. Auch

der Einsatz des Solution Managers ist im jeweiligen Projektkontext zu

betrachten. Durch den Solution Manager ist eine leichte Anbindung an

existierende Business Blue Prints und die Verwendung von SAP-Stan-

dardtestfällen möglich. Dennoch dürfen auch Pflegeaufwand und Be-

nutzbarkeit nicht außer Acht gelassen werden.

Auswahl des Testansatzes Von Customizing, über komplette Geschäftsprozesse, bis zum End-to-

End Test mit verschiedenen Systemen und internen & externen Schnitt-

stellen gibt es in SAP viele Möglichkeiten mit dem Test zu beginnen.

Auch hier bestimmen Teststufe und –fokus die Ausführlichkeit des Tests.

Es kann für einen Sanity Check ausreichen, Customizing Änderungen

in der entsprechenden Tabelle zu prüfen. Für einen Integrationstest mit

externen Systemen und Schnittstellen kann das Prüfen der Tabellenein-

träge der Testbeginn sein, um dann mit einem End-to-end Test über die

komplette Systemlandschaft zu enden.

Informieren Sie sich bei den Testexperten von ANECON und vereinbaren Sie ein Beratungsgespräch! www.anecon.com oder +49/ 351/ 272 13 95

„Aufgrund der vielen

Customizing Möglichkeiten

die SAP bietet, gibt es

immer wieder neue, span-

nende Herausforderungen

beim Test im SAP Umfeld.“

Claudia Blankschein /

Testconsultant, ANECON

claudia.blankschein@

anecon.com

Durch die gebotenen Anpassungs- und Änderungsmög-lichkeiten entsteht aus der Standardsoftware SAP sehr schnell eine individuelle Softwarelösung. Die Folgen? Durch falsch vorgenommene Anpassungen und uner-wünschte, von Änderungen ausgelöste, Seiteneffekte, kann eine Beeinflussung der vorhandenen Funktionali-tät vorkommen. Deshalb ist der Test von SAP Systemen wichtig und folgende 5 Schritte können wesentlich zu einem erfolgreichen Test eines SAP-Release betragen:

Advertorial

Im Fokus

Auch wenn der Großteil der heutigen IT-Projekte immer noch nach klassisch phasenorientierten und iterativen Vorgehen entwickelt wird (vgl. z.B. www.softwaretest-um-frage.de), hat sich die agile Software-Entwicklung als an-gesehenes Entwicklungsparadigma mittlerweile in vielen Unternehmen etabliert. Die Vorteile liegen auf der Hand.

Welche Auswirkungen hat Agilität aber auf das Testen und insbesondere auf das ISTQB®-Schema? Sind die Zeiten dedizierter, intensiv geschulter und sogar zertifizierter Te-ster nun vorbei, da jetzt jeder im agilen Team testet und entwickelt? Müssen also alle ISTQB Syllabi umgeschrie-ben werden? Für die Analyse der Auswirkungen von Agilität auf Testen hilft eine modifizierte agile Testmatrix (Original von Brian Marick):

- Die Y-Achse adressiert die Frage, was mit der Software passiert. Sie spannt ein Kontinuum von der Entwicklung der Software bis zur Nutzung auf. Jeder Wert korrespon-diert dabei aus Testsicht mit spezifischen Testobjekten und Testkriterien: Die naturgemäße White-Box-Sicht der Softwareerstellung orientiert sich an Kontrollflüs-sen, Datenabhängigkeiten, Klassen, Funktionen und so weiter. Die Nutzungssicht orientiert sich eher an Busi-ness-Prozessen, Risiken, Interoperabilitäten zwischen Systemen, Rollenkonzepten und so weiter.

- Die X-Achse adressiert die Frage, welche Aufgaben das System erfüllen muss. Sie spannt ein Kontinuum auf zwischen den fachlichen und den technischen Auf-gaben. Fachliche Aufgaben orientieren sich dabei am Business, in dem das Software-System helfen soll (z.B. Kundenverwaltung, Archivierung oder Drucken). Die technischen Aufgaben orientieren sich an Aufgaben, die es technisch realisiert (z.B. Exception-Handling, Spei-chermanagement oder Threadverwaltung).

Die so aufgespannte Matrix kann damit wie folgt darge-stellt werden und erlaubt die Positionierung des klas-sischen Nutzers oben rechts und des klassischen Ent-wicklers unten links (Abb. 1)

Jeder der Quadranten dieser Testmatrix hat entsprechend seine eigenen Testmethoden: Links unten gibt es z.B. den Unit- und Code-Coverage-Test, oben links den Integra-tions- und den Funktionstest, unten rechts den Pene-trations- und Performance-Test und oben rechts gibt es beispielsweise den Systemabnahme- und Usability-Test.

Testende Entwickler und entwickelnde Tester: Eine Win-Win-KonstellationFrank Simon

Bzgl. der ISTQB®-Syllabi kann interessanterweise fol-gendes festgestellt werden: Auch wenn der Technical Test Analyst eher die linken unteren Bereiche und der Test Analyst eher die rechten oberen Bereiche abdeckt, so werden diese Quadranten zwar nicht explizit genannt, die ISTQB®-Syllabi decken aber dennoch mit ihrem Me-thodenkasten alle Quadranten vollständig ab! Auch agile Entwickler haben bekannte Testobjekte und Testkriterien, selbst wenn sie dieses „Wording“ vielleicht nicht direkt verwenden. Sämtliches Testwissen der ISTQB®-Syllabi wird unabhängig vom jeweiligen Entwicklungsprozess geschult und bedarf daher in jedem Projekt der entspre-chenden Anpassung, so dass die Anwendung in agilen Projekten ebenfalls grundsätzlich möglich ist.

Interessant sind nun aber besonders die üblichen Rollen in Scrum-Teams: Es gibt für agile Teams keine explizite Forderung nach dedizierten Testern. Die im agilen Kon-text häufig geforderten sogenannten „T-Shaped-Skills“ der Mitarbeiter verlangen vielmehr, dass alle Mitarbeiter ein grundsätzliches Grundverständnis aller Bereiche besitzen und so eben auch testen können. In agilen Teams dominie-ren damit heute die testenden Entwickler und damit die lin-ken unteren Quadranten der Matrix: Die positive Nachricht hierbei ist, dass die technischen, eher für die Erstellung des Systems intendierten Tests hierdurch eine enorm breite Anwendung finden und so eine hohe Entwicklungseffizienz und –effektivität ermöglichen. Die rechten oberen Bereiche der Matrix sind allerdings meist unterrepräsentiert, da es keine unabhängige Instanz der Fachseite gibt, die professi-onell aus Sicht der Anwender testet.


Abb 1: Agile Testmatrix mit den beiden Rollen Nutzer und Entwickler


In klassisch entwickelten Systemen findet sich dagegen häufig genau die umgekehrte Situation: Viele dedizierte Tester decken den oberen, rechten Bereich gut ab, mei-den aber die technischeren Tests. Die jeweiligen Stärken beider Testschwerpunkte sind in der folgenden Abbil-dung noch einmal dargestellt:

Abb 2: Stärken-Schwächen-Sicht für agile Entwickler und klassische Tester

Und genau hier liegt die Win-Win-Konstellation für gut getestete und agil entwickelte Systeme: Erst die Kom-bination aus agilen Entwicklern und klassischen Testern ermöglicht eine wirklich effiziente und effektive Soft-ware-Erstellung, bei der alle möglichen Fehlerquellen (technische und fachliche) so früh wie möglich gefunden werden. An der Schnittmenge treffen dann testende Ent-wickler und entwickelnde Tester zusammen (vgl. Abbil-dung 2).

An ein solches Win-Win-Team können heute folgende An-forderungen gestellt werden:

- Jedes Team-Mitglied sollte ein Grundverständnis vom Testen haben. Dies ist für ein konsistentes Testvokabu-lar im Team unabdingbar. Der ISQB®-Foundation Level bietet hierfür eine solide Ausgangsbasis.

- In jedem agilen Team gibt es einen dedizierten Testex-perten. Als normales Mitglied des Teams sollte er aller-dings die Technik-Sicht kennen, also idealerweise den ISTQB®-Technical-Test-Analyst absolviert haben.

Der ISTQB®-Syllabus ist also bereits heute geeignet, sol-che Win-Win-Teams aufzubauen. Es wird Zeit, diese Vor-teile für die agile Software-Entwicklung zu nutzen!

Dr. Frank Simon hat Informatik studiert und im

Bereich der Qualitätssicherung großer IT-Systeme

promoviert. Er hat im Consulting-Bereich alle

etablierten Facetten des Testens und des Quali-

tätsmanagements kennengelernt bevor er für die

industrielle Forschung innovative Ansätze für ein

qualitativ hochwertiges Software-Engineering

erarbeitet hat. Heute innoviert er als Head of

Business Development das Leistungsportfolio der

BLUECARAT AG. Er ist im Vorstand des German

Testing Boards und leitet innerhalb des BITKOM

den Arbeitskreis Software-Engineering.


Mit wachsenden organisatorischen und technischen Ab-hängigkeiten führt am Traditionell Testing kein Weg vorbei. Aber auch in einem traditionellen Umfeld können agile Me-thoden ihre Effizienzvorteile ausspielen.

Bei IT Projekten, in denen fachliche, technische oder or-ganisatorische Abhängigkeiten in einem hohen Maß zu berücksichtigen sind, greifen agile Methoden alleine zu kurz. Um diese Abhängigkeiten zu bewerten und im Test-management zu berücksichtigen braucht es Vorlauf. Aller-dings gibt es auch Bereiche, wo sich der Einsatz von agilen Ansätzen auch in einem traditionellen Kontext anbietet. Speziell bei Anwendungen, die nach Scrum entwickelt wer-den, wirken die traditionellen Testansätze häufig sehr starr. Hier sind agile Test-Methoden klar im Vorteil.

Von Anfang an dabei

Mit dem Aufsetzen des IT-Projekts beginnt auch das Test-management. Sobald Architektur Entscheidungen getrof-fen sind (was wird in welchem System realisiert, in welchem Umfang werden Oberflächen, Workflows und Datenbanken weiter entwickelt), lassen sich die Anforderungen an den Testprozess skizzieren. Erste Ideen für das Testvorgehen werden entwickelt und parallel zur (Fach-) Konzeptphase konkretisiert. Die Beteiligung der Testmanager an den Kon-zeptreviews sorgt dafür, dass erste Fehler erkannt werden, bevor sie programmiert werden. Billiger kann Fehlerbehe-bung nicht sein.

Neben den fachlichen und technischen Test-Requirements müssen auch die Anforderungen an den Testprozess recht-zeitig klar sein, damit noch hinreichend Zeit bleibt, um den Testprozess für die kommenden Anforderungen weiter zu entwickeln bevor die eigentlichen Tests starten (vgl. Abbil-dung (a)): - für neue Schnittstellen muss Testinfrastruktur erweitert

und / oder Simulatoren gebaut werden - für Framework Änderungen sind in der Regel Scripts von

Automatisierungswerkzeugen anzupassen. Solche Anforderungen sollten tunlichst nicht erst auffallen, wenn die Tests starten.

Testmanager ist nicht gleich Testmanager

Bei überschaubaren Änderungen übernimmt der Testma-nager häufig alle Aufgaben in Personalunion. Er schreibt die Testfälle, kümmert sich um Testdaten, konfiguriert sei-

ne Tools und sorgt auch für das Reporting. Hier kommen die Effizienzvorteile des agilen Testings zum Tragen: Wenn Tester und Entwickler eng zusammen arbeiten, kann Ein-fluss auf die Entwicklung genommen werden (test driven developement), so dass auch frühzeitig mit Testautomati-sierung begonnen werden kann.

In größeren Arbeitspakten hingegen wirkt ein Testmanager eher als Moderator und Übersetzer zwischen den Fach-bereichen und der IT. Insbesondere sorgt er dafür, dass Testfälle verständlich sind und Fehler derart dokumentiert werden, dass diese für die Entwickler nachvollziehbar und reproduzierbar sind.

Ab einer bestimmten Größe ist der Test wie ein Projekt im Projekt zu organisieren. Termine für den Produktionsein-satz sind im Allgemeinen bereits kommuniziert, folglich ist konsequente Steuerung gefragt.

Prozessentwicklung (a) und Releasetests (b)

Projekt- und Release-Testmanagement

Da in der Regel Projekte ihre Anforderungen in mehreren Systemen implementieren, ist die Projekt-Testplanung mit den Testplanungen der Releases aller relevanten Anwen-dungen zu harmonisieren. (vgl. Abbildung (b))

Für den End to End Test müssen Installationstermine aufei-nander abgestimmt werden. Desweiteren sind für Produk-tionseinsätze entsprechende Vorlaufzeiten zu berücksich-tigen. Daraus ergeben sich in der Regel unterschiedliche Termine für das Testende der jeweiligen Applikationen. Hier stoßen agile Methoden an ihre Grenzen.

Insbesondere wenn die Installation und der Betrieb von (Produktions-) Umgebungen durch Dritte erfolgt, ergeben sich nicht selten längere Vorlaufzeiten. Entsprechend früh-zeitig sind die Releasetests und damit auch die Projekt-tests auf diesen Anwendungen abzuschließen.

Klassisches Konzert mit agilen Partituren

Im Fokus

Johannes Helders


Projektmanagement-kompetenzen sind gefragt

Liegt im Agile Testing der Fokus eher auf Test, so steht beim Traditional Testing das Management im Vordergrund.

Test ist Karriere: vom Tester zum Projektleiter

Bei überschaubaren Themen ist ein Testmanager noch sehr stark operativ unterwegs, in Großprojekten hingegen sind mehr und mehr Projektmanagement Skills erforderlich. Ins-besondere dann wenn Produktionstermine gefährdet sind, weil die Qualität nicht passt oder die Testressourcen nicht zur Verfügung stehen. Jetzt sind Risikomanagement und adressatengerechtes Reporting gefragt. Bei der Mitarbeiter-entwicklung sollte daher nicht alleine auf dem Erwerb von Testzertifikaten und der Kenntnis von Tools Wert gelegt wer-den. Mindestens genauso wichtig sind Kompetenzen in Mo-deration, Planung, Steuerung und Führung. Genau diese be-fähigen einen erfahrenen Testmanager auch als Projektleiter.


Johannes Helders verantwortet seit 2001 den Test-

prozess bei der Deutschen Bank Bauspar AG und

hat das Testmanagement als feste Größe innerhalb

des Software Entwicklungsprozesses etabliert. Seit

2006 tritt er regelmäßig als Referent auf Kongres-

sen auf.


Prozesse sind das A und O

Saubere Prozesse mit klar definierten Rollen und Verant-wortungen, eine stabile Testinfrastruktur und motivierte Mitarbeiter, dies sind die Zutaten für einen dauerhaft ef-fizienten und effektiven Testprozess. Dies gilt sowohl für den traditionellen als auch für den agilen Testansatz. Wenn es gelingt, diese Komponenten sauber aufeinander abzu-stimmen, behalten Sie den Überblick über Ihre Systeme, Projekte und Releases und haben im Ziel die Nase vorn.

Genereller Einsatz von Modellierung

Eine wesentliche Eigenschaft eines jeden Modells ist, dass es immer nur einen Teil der Wirklichkeit abbildet, indem es ausgewählte Aspekte darstellt, andere jedoch gänzlich weglässt. Diese Eigenschaft hilft uns dabei, mit Modellen gezielter kommunizieren zu können und durch bewusstes Weglassen bzw. Darstellen von Aspekten den Überblick zu behalten. Abhängig vom Formalisierungsgrad und der Abstrak-tionsebene können wir Modelle mit unterschiedlichen Zielsetzungen einsetzen. Unterschiedliche Abstraktions-ebenen ermöglichen es uns, sowohl den Überblick zu be-halten, als auch dabei, den Problemraum vom Lösungs-raum – das Was und Warum vom Wie – zu trennen.

Gibt es überhaupt eine Agile Modellierung?

Um diese Frage zu beantworten, ist es unerlässlich, ei-nen Blick in das agile Manifest zu werfen. Hier sind Werte und Prinzipien beschrieben, die bei agilem Vorgehen zu beachten sind. Ein genaues Vorgehensmodell oder eine Beschreibung, wie diese Werte und Prinzipien erreicht und eingehalten werden können, finden wir dort nicht. Etabliert haben sich Praktiken wie z.B. Scrum, die agi-ler Entwicklung einen Rahmen geben. Aber auch dort ist das konkrete „Wie“ bewusst offen gehalten. Sowohl das agile Manifest als auch Scrum treffen keine Aussage zu Modellierung, lassen diese dadurch natürlich implizit zu.An dieser Stelle möchten wir beispielhaft einige Prin-zipien des agilen Manifests herausgreifen, die durch Mo-dellierung sinnvoll unterstützt werden können.

Kommunikation und Konversation – ein Bild sagt mehr als tausend Worte

„Die effizienteste und effektivste Methode, Informationen an und innerhalb eines Entwicklungsteams zu übermit-teln, ist im Gespräch von Angesicht zu Angesicht (Agiles Manifest).“ Agile Entwicklung versucht auf umfassende schriftliche Vorabspezifikationen zugunsten von Konver-sation und schnellem Feedback zu verzichten.

Dieses Prinzip basiert also auf dem persönlichen Ge-spräch zwischen Fachbereich/Kunde und Entwicklung, um das Problem genau zu erfassen (das „Was“) und ebenso auf persönlicher Kommunikation innerhalb der Entwicklung, um das Software-Design (das „Wie“) als

Basis der Implementierung zu erarbeiten. Modelle kön-nen, je nach Zielsetzung, mit unterschiedlichen Forma-lisierungsgraden eingesetzt werden. Für Kommunikation und Konversation bietet es sich an, Modelle gemeinsam in Form einer Skizze am Flipchart zu entwerfen, um ein einheitliches Verständnis zu erzielen.

Existieren bereits Modelle, so können die betroffenen As-pekte ausgedruckt und ebenfalls gemeinsam verändert und erweitert werden. Dieses Vorgehen eignet sich für Analyse- und Design-Aufgaben gleichermaßen.

Mit den erstellten Skizzen kann nun je nach Kontext un-terschiedlich verfahren werden:

- Sie werden entsorgt, nachdem das gemeinsame Ver-ständnis erzielt wurde

- Sie werden in eine elektronische Form übertragen (z.B. in ein Modellierungswerkzeug), die eine weitere Bear-beitung der Modelle zulässt:- Auswirkungsanalyse der betrachteten Teilaspekte

auf das Gesamtsystem (falls dieses bereits als Mo-dell repräsentiert vorliegt)

- Ableitung des Software-Designs durch das Entwick-lungsteam

- Implementierungsvorgabe für modellbasierten Code- Verfeinerung und Aktualisierung als Systemdoku-

mentation vor/während/nach der Implementierung

Weniger ist mehr - Das Richtige richtig tun

„Einfachheit -- die Kunst, die Menge nicht getaner Arbeit zu maximieren -- ist essenziell (Agiles Manifest).“Dieses Prinzip schreit geradezu nach Modellierung. Mo-dellgetriebene Vorgehensweise hilft dabei Routinear-beiten zu sparen durch:- Code-Generierung aus Design-Modellen- Dokumentations-Generierung aus allen Modellen- Erstellung von Benutzerdokumentation aus ausgewähl-

ten Modellen- modellbasiertes Testen

In Verbindung dazu sind auch die folgenden beiden Prin-zipien zu sehen:„Unsere höchste Priorität ist es, den Kunden durch frühe und kontinuierliche Auslieferung wertvoller Software zu-frieden zu stellen (Agiles Manifest).“„Liefere funktionierende Software regelmäßig innerhalb weniger Wochen oder Monate und bevorzuge dabei die kürzere Zeitspanne. (Agiles Manifest).“

Modellierung – agil versus traditionell

Im Fokus

Andreas Ditze, Susanne Mühlbauer, Philip Stolz


Diese beiden Forderungen lassen sich nur erfüllen, wenn sich die Entwicklung auf die wirkliche Entwicklungslei-stung und Innovation konzentrieren kann und Ände-rungen am Gesamtsystem jederzeit schnell und ohne riskante, unvorhersehbare Auswirkungen durchgeführt werden können.

Was haben wir Entwickler davon?

Ein letztes der Prinzipien möchten wir gerne herausgreifen:„Die besten Architekturen, Anforderungen und Entwürfe entstehen durch selbstorganisierte Teams (Agiles Mani-fest).“In der Praxis sehen wir leider, dass agile Teams kaum mit Modellierung arbeiten. Sie erkennen häufig den Nut-zen nicht, der Ihnen durch Modellierung entstehen kann – Modellierung wird als Aufwand, nicht als Entlastung angesehen. Die Erklärungsversuche hierfür sind unter-schiedlich:- Für die Modellierung gibt es eine eigene Abteilung,

es findet keine unmittelbare Zusammenarbeit mit den Teams statt

- Die existierenden Modelle sind veraltet und bilden nicht den realen Stand des Systems ab

- Die Tools sind nicht nahe genug an der Entwicklungs-umgebung

- Es ist zu wenig Modellierungs-Know-how im Team vor-handen

- Modellierung wird als kompliziert empfunden, da im-mer der höchste Formalisierungsgrad angestrebt wird

Abschließend betrachtet, sind Methoden und Tools zur Modellierung also auch in einem agilen Umfeld sinnvoll einsetzbar. Es gibt daher keine „agile Modellierung“ im eigentlichen Sinne, sondern vielmehr eine agile Verwen-dung von Modellierung unter Berücksichtigung agiler Prinzipien und agiler Werte.

Was macht traditionelle Modellierung traditionell?

Prinzipiell unterscheiden wir im Folgenden die Phasen Analyse, Design und Implementierung. In der Analyse-phase machen wir uns Gedanken, Was getan werden muss und Warum (Ziel), in der Phase Design legen wir fest, Wie wir das Ziel erreichen und in der Phase Imple-mentierung erfolgt die eigentliche Umsetzung.

Bei eher traditionellen, phasenorientierten Vorgehens-weisen werden die einzelnen Phasen sequentiell bear-beitet (siehe Abbildung 1), wobei auch hier ein iterativer Ansatz natürlich nicht ausgeschlossen ist. Auch die Mo-dellierungsaktivitäten richten sich dann nach diesen Pha-sen, wir unterscheiden zum Beispiel nach objektorien-


Andreas Ditze ist Ge-

schäftsführer bei der

MID GmbH. Er ist Leiter

der Fachgruppe Model-

lierung im ASQF.


Susanne Mühlbauer ist

Senior Consultant, Trai-

ner und Coach bei der

HOOD Group.

Philip Stolz ist Senior

Consultant, Trainer und

Coach bei der HOOD

Group.

Im Fokus

tierter Analyse (OOA) und objektorientiertem Design (OOD). Modellierungsnotationen wie die UML sind universell für alle Phasen und Abstraktionsebenen einsetzbar oder be-ziehen sich auf die Beschreibung konkreter Artefakte, wie die BPMN für Geschäftsprozesse und Workflows.

Agiles Vorgehen ist iterativ und inkrementell. Analyse, De-sign und Implementierung sind keine Phasen, sondern Aktivitäten, die laufend stattfinden. Das Ergebnis jeder Ite-ration (hier Sprint) ist jeweils ein potentiell lieferbares Pro-duktinkrement. Im Rahmen der Sprintplanungsmeetings am Anfang jeden Sprints erfolgt Analyse und Design für die im aktuellen Sprint umzusetzenden Anforderungen. Wäh-rend des Sprints erfolgen Analyse- und Designaktivitäten für künftige Sprints im Rahmen des Backlog Groomings.

Die Wahl der Modellierungsnotation ist hier also nicht abhängig von der Phase, sondern vielmehr von Aktivität, Einsatzzweck und erforderlichem Formalisierungsgrad. Abbildung 1 stellt den Unterschied zwischen agiler und tra-ditioneller Vorgehensweise als Prinzipdarstellung gegen-über. Der Vollständigkeit halber haben wir die Abbildung um die Phase bzw. Aktivität Testen erweitert.

Fazit

Für uns – und wir hoffen, wir konnten unsere Gedanken-gänge nachvollziehbar darstellen – sind Modellierungs-kenntnisse für die professionelle Software-Entwicklung unabdingbar. Unabhängig davon, ob Sie agil oder traditio-nell vorgehen bietet Modellierung ausgezeichnete Möglich-keiten, um unter anderem

- ein gemeinsames Verständnis zu schaffen- Problem- und Lösungsdarstellungen voneinander zu

trennen- Komplexität sichtbar und beherrschbar zu machen- Routinetätigkeiten zu Automatisieren (Code-Generie-

rung)- Analyse-/Design-Entscheidungen und die erstellte Im-

plementierung zu dokumentieren.

Für den Einsatz von Modellierung ist es dabei vollkom-men unerheblich, welches Vorgehensmodell für die Sys-tementwicklung gewählt wird.

In allen Phasen eines Produktlebenszyklusses kann Mo-dellierung eingesetzt werden. Wie viel und mit welchen Notationen modelliert wird, ist vielmehr abhängig vom Kontext und vom Einsatzzweck.

Heute kommen überwiegend Stift und Flipchart zum Einsatz, wenn es um das Thema Modellierung in agilen Projekten geht. Dies dient dem Schaffen eines Verständ-nisses im Team, hat jedoch den Nachteil, dass viele Po-tentiale der Modellierung ungenutzt bleiben. In traditio-nell durchgeführten Projekten dagegen dominiert das Modell als Nachdokumentation der Implementierung. Besonders in agilen Projekten ist zu erwarten, dass sich werkzeuggestützte Modellierung erst dann durchsetzt, wenn Modellierungswerkzeuge und Entwicklungsumge-bung derart integriert sind, dass Modell und Code zu je-dem Zeitpunkt weiterentwickelt werden können und da-bei automatisch konsistent zueinander bleiben.


Abbildung 1: Gegenüberstellung agiler und traditioneller Ansätze

International Software Quality Institute


Schulungen 2013Juni 2013 bis August 2013Certified Schulungen werden ausschließlich von akkreditierten Unternehmen durchgeführt. Das iSQI fungiert hier als Vermittler. Anmeldeformular und Preise unter www.isqi.org.

Schulungstitel/Seminartitel Ort Datum (Start) Dauer Anbieter

AGILE ESSENTIALS

Agile Essentials Berlin 24.06.13 2 Tage Diaz & Hilterscheid Unternehmensberatung GmbH

Agile Essentials Frankfurt/M 08.07.13 2 Tage Diaz & Hilterscheid Unternehmensberatung GmbH

Agile Essentials Röttenbach 25.07.13 2 Tage sepp.med gmbh

Agile Essentials Nürnberg 29.07.13 2 Tage Diaz & Hilterscheid Unternehmensberatung GmbH

Agile Essentials Köln 19.08.13 2 Tage Diaz & Hilterscheid Unternehmensberatung GmbH

CERTIFIED AGILE TESTER®

CAT® - Certified Agile Tester Berlin 10.06.13 5 Tage Diaz & Hilterscheid Unternehmensberatung GmbH

CAT® - Certified Agile Tester Wien 10.06.13 4 Tage Software Quality Lab GmbH

CAT® - Certified Agile Tester Frankfurt a. M. 17.06.13 5 Tage Avenqo GmbH

CAT® - Certified Agile Tester Berlin 17.06.13 5 Tage Loyal Team GmbH

CAT® - Certified Agile Tester Frankfurt 17.06.13 5 Tage SQS AG

CAT® - Certified Agile Tester Köln/Düsseldorf 24.06.13 5 Tage Diaz & Hilterscheid Unternehmensberatung GmbH

CAT® - Certified Agile Tester München 24.06.13 4 Tage Software Quality Lab GmbH

CAT® - Certified Agile Tester Frankfurt 24.06.13 5 Tage Sogeti Deutschland GmbH

CAT® - Certified Agile Tester München 22.07.13 5 Tage Diaz & Hilterscheid Unternehmensberatung GmbH

CAT® - Certified Agile Tester Berlin 12.08.13 5 Tage Diaz & Hilterscheid Unternehmensberatung GmbH

CAT® - Certified Agile Tester Amsterdam 26.08.13 5 Tage Diaz & Hilterscheid Unternehmensberatung GmbH

ISTQB® CERTIFIED TESTER FOUNDATION LEVEL

ISTQB® Certified Tester - Foundation Level Wien 04.06.13 3,5 Tage OBJENTIS Software Integration GmbH

ISTQB® Certified Tester - Foundation Level Hamburg (Buxtehude) 04.06.13 3 Tage Philotech GmbH

ISTQB® Certified Tester - Foundation Level Frankfurt 04.06.13 4 Tage Sogeti Deutschland GmbH

ISTQB® Certified Tester - Foundation Level Zürich06.-07.06. + 13.-14.06.13

2x2 Tage

SynSpace AG

ISTQB® Certified Tester - Foundation Level Köln 10.06.13 4 Tage andagon GmbH

ISTQB® Certified Tester - Foundation Level München 10.06.13 4 Tage ISARTAL akademie GmbH

ISTQB® Certified Tester - Foundation Level Hamburg 10.06.13 4 Tage SQS AG

ISTQB® Certified Tester - Foundation Level - Kompaktkurs Mödling 11.06.13 3 Tage Diaz & Hilterscheid Unternehmensberatung GmbH

ISTQB® Certified Tester - Foundation Level Cottbus 11.06.13 3 Tage Philotech GmbH

ISTQB® Certified Tester - Foundation Level München 12.06.13 3 Tage Loyal Team GmbH

ISTQB® Certified Tester - Foundation Level - Kompaktkurs Stuttgart/Karlsruhe 17.06.13 3 Tage Diaz & Hilterscheid Unternehmensberatung GmbH

ISTQB® Certified Tester - Foundation Level Frankfurt 17.06.13 4 Tage Diaz & Hilterscheid Unternehmensberatung GmbH

ISTQB® Certified Tester - Foundation Level München 17.06.13 4 Tage Sogeti Deutschland GmbH

ISTQB® Certified Tester - Foundation Level Wiesbaden 18.06.13 3,5 Tage G. Muth Partners GmbH

ISTQB® Certified Tester - Foundation Level Berlin 19.06.13 3 Tage Loyal Team GmbH

ISTQB® Certified Tester - Foundation Level Wien 24.06.13 4 Tage BDC EDV-Consulting GmbH

ISTQB® Certified Tester - Foundation Level Frankfurt 24.06.13 4 Tage Logica Deutschland GmbH & Co. KG

ISTQB® Certified Tester - Foundation Level Frankfurt 24.06.13 4 Tage SQS AG

ISTQB® Certified Tester - Foundation Level München (Ottobrunn) 25.06.13 3 Tage Philotech GmbH

ISTQB® Certified Tester - Foundation Level Röttenbach 26.06.13 3 Tage sepp.med gmbh

ISTQB® Certified Tester - Foundation Level - Kompaktkurs Berlin 01.07.13 3 Tage Diaz & Hilterscheid Unternehmensberatung GmbH

ISTQB® Certified Tester - Foundation Level Graz 01.07.13 4 Tage Software Quality Lab GmbH

ISTQB® Certified Tester - Foundation Level Linz 01.07.13 4 Tage Software Quality Lab GmbH

ISTQB® Certified Tester - Foundation Level Wien 01.07.13 4 Tage Software Quality Lab GmbH

Termine to goeinfach aus der Heftmitte heraustrennen

STA

ND

: Jun

i 201

3

Mehr als 100 weitere Termine finden Sie unter: www.isqi.org/de/schulungen-liste-op.html

SECUR IT Y ANDERE

PR OJECTMANAGEMENT SP I

MED ICAL

SOF T WARE T E ST

ISTQB® Certified Tester - Foundation Level Zürich01.-02.07.13 + 08.-09.07.13

4 Tage SynSpace AG

ISTQB® Certified Tester - Foundation Level - Kompaktkurs Leipzig 08.07.13 3 Tage Diaz & Hilterscheid Unternehmensberatung GmbH


ISTQB® Certified Tester - Foundation Level Lustenau 08.07.13 4 Tage Software Quality Lab GmbH

ISTQB® Certified Tester - Foundation Level München 08.07.13 4 Tage Software Quality Lab GmbH

ISTQB® Certified Tester - Foundation Level Stuttgart 08.07.13 4 Tage Sogeti Deutschland GmbH


ISTQB® Certified Tester - Foundation Level München 10.07.13 3 Tage sepp.med gmbh

ISTQB® Certified Tester - Foundation Level München 15.07.13 4 Tage Diaz & Hilterscheid Unternehmensberatung GmbH

ISTQB® Certified Tester - Foundation Level München 15.07.13 4 Tage Sogeti Deutschland GmbH

ISTQB® Certified Tester - Foundation Level München 15.07.13 4 Tage SQS AG

ISTQB® Certified Tester - Foundation Level München 22.07.13 4 Tage ISARTAL akademie GmbH

ISTQB® Certified Tester - Foundation Level Hamburg 22.07.13 4 Tage Logica Deutschland GmbH & Co. KG

ISTQB® Certified Tester - Foundation Level Köln 22.07.13 4 Tage SQS AG

ISTQB® Certified Tester - Foundation Level Berlin 05.08.13 4 Tage Diaz & Hilterscheid Unternehmensberatung GmbH

ISTQB® Certified Tester - Foundation Level Hamburg 05.08.13 4 Tage Sogeti Deutschland GmbH


ISTQB® Certified Tester - Foundation Level Stuttgart 12.08.13 4 Tage Logica Deutschland GmbH & Co. KG


ISTQB® Certified Tester - Foundation Level - Kompaktkurs Karlsruhe 19.08.13 3 Tage Diaz & Hilterscheid Unternehmensberatung GmbH

ISTQB® Certified Tester - Foundation Level Basel19.-20.08.13 + 26.-27.08.13

4 Tage SynSpace AG

ISTQB® Certified Tester - Foundation Level Frankfurt/Main 26.08.13 4 Tage Diaz & Hilterscheid Unternehmensberatung GmbH

ISTQB® CERTIFIED TESTER ADVANCED LEVEL - TEST MANAGER

ISTQB® Certified Tester - Advanced Level Test Manager Basel27.-28.05.13 + 03.-05.06.13

5 Tage SynSpace AG

ISTQB® Certified Tester - Advanced Level Test Manager Frankfurt 03.06.13 5 Tage Diaz & Hilterscheid Unternehmensberatung GmbH

ISTQB® Certified Tester - Advanced Level Test Manager Erlangen 10.06.13 5 Tage Method Park Software AG

ISTQB® Certified Tester - Advanced Level Test Manager Wiesbaden 10.06.13 5 Tage G. Muth Partners GmbH

ISTQB® Certified Tester - Advanced Level Test Manager Braunschweig 10.06.13 5 Tage G. Muth Partners GmbH

ISTQB® Certified Tester - Advanced Level Test Manager München 10.06.13 5 Tage sepp.med gmbh

ISTQB® Certified Tester - Advanced Level Test Manager Frankfurt 10.06.13 5 Tage SQS AG

ISTQB® Certified Tester - Advanced Level Test Manager Hamburg 17.06.13 5 Tage SQS AG

ISTQB® Certified Tester - Advanced Level Test Manager Frankenthal 17.06.13 5 Tage EXCO GmbH

ISTQB® Certified Tester - Advanced Level Test Manager Stuttgart 01.07.13 5 Tage Diaz & Hilterscheid Unternehmensberatung GmbH

ISTQB® Certified Tester - Advanced Level Test Manager Stuttgart 01.07.13 5 Tage Logica Deutschland GmbH & Co. KG

ISTQB® Certified Tester - Advanced Level Test Manager Düsseldorf 01.07.13 5 Tage Sogeti Deutschland GmbH

ISTQB® Certified Tester - Advanced Level Test Manager München 08.07.13 5 Tage SQS AG

ISTQB® Certified Tester, Advanced Level, Test Manager Ringhotel Adler/Stuttgart 15.07.13 5 Tage Method Park Software AG

ISTQB® Certified Tester - Advanced Level Test Manager Wien 22.07.13 5 Tage Software Quality Lab GmbH

ISTQB® Certified Tester - Advanced Level Test Manager München 22.07.13 5 Tage Software Quality Lab GmbH

ISTQB® Certified Tester - Advanced Level Test Manager Köln 19.08.13 5 Tage Logica Deutschland GmbH & Co. KG

ISTQB® Certified Tester - Advanced Level Test Manager Frankfurt 26.08.13 5 Tage Sogeti Deutschland GmbH

ISTQB® Certified Tester - Advanced Level Test Manager Köln 26.08.13 5 Tage SQS AG

ISTQB® CERTIFIED TESTER ADVANCED LEVEL - TEST ANALYST

ISTQB® Certified Tester Advanced Level Test Analyst Bern10.-11.06.13 + 17.-18.06.13

4 Tage SynSpace AG

ISTQB® Certified Tester Advanced Level Test Analyst Mödling/Österreich 17.06.13 5 Tage Diaz & Hilterscheid Unternehmensberatung GmbH

ISTQB® Certified Tester Advanced Level Test Analyst Berlin 24.06.13 5 Tage Diaz & Hilterscheid Unternehmensberatung GmbH

ISTQB® Certified Tester Advanced Level Test Analyst Erlangen 24.06.13 5 Tage Method Park Software AG

ISTQB® Certified Tester Advanced Level Test Analyst München 24.06.13 5 Tage SQS AG

ISTQB® Certified Tester Advanced Level Test Analyst Hamburg 12.08.13 5 Tage SQS AG

ISTQB® Certified Tester Advanced Level Test Analyst München 08.07.13 5 Tage Logica Deutschland GmbH & Co. KG

ISTQB® Certified Tester Advanced Level Test Analyst Berlin 29.07.13 4 Tage Diaz & Hilterscheid Unternehmensberatung GmbH

Das iSQI fungiert hier als Vermittler.Ausführliche Seminarbeschreibungen, Preise und Anmeldeformular: www.isqi.org

STA

ND

: Jun

i 201

3



Seminartitel Ort Datum (Start) Dauer Anbieter

AGILE / SCRUM

Agile Developer - Practitioner Wien 12.06.13 3 Tage ANECON Software Design und Beratung GmbH

Agiles Software-Projektmanagement Hamburg 17.06.13 5 Tage oose Innovative Informatik GmbH

Agile Testing In A Nutshell Wien 17.06.13 1 Tag ANECON Software Design und Beratung GmbH

Kombinationsangebot "Professional Scrum Training" mit Vertiefung "Führen als Scrum Master"

Hamburg 24.06.13 5 Tage oose Innovative Informatik GmbH

Kombinationsangebot "Professional Scrum Training" mit Vertiefung "Führen als Scrum Master"

Hamburg 19.08.13 5 Tage oose Innovative Informatik GmbH

SCRUM Berlin 10.06.13 2 Tage Avenqo GmbH

CMMI

Einführung in CMMI® for Development V1.3 Kornwestheim 11.06.13 3 Tage KUGLER MAAG CIE GmbH

Einführung in CMMI für Produktentwicklung (CMMI-DEV v1.3) Zürich 18.06.13 3 Tage Anywhere. 24 GmbH

Einführung in CMMI für Produktentwicklung (CMMI-DEV v1.3) München 01.07.13 3 Tage Anywhere. 24 GmbH

TEST

Testmanagement auf Basis von HP Quality Center Berlin 06.06.13 2 Tage QMETHODS - Business & IT Consulting GmbH

Testautomation auf Basis von HP QuickTest Professional Berlin 20.06.13 2 Tage QMETHODS - Business & IT Consulting GmbH

TMap NEXT® Test Engineer (TMPTE) Hamburg 10.06.13 5 Tage Sogeti Deutschland GmbH

TMap NEXT® Test Engineer (TMPTE) Frankfurt 10.06.13 5 Tage Sogeti Deutschland GmbH

TMap NEXT® Test Engineer (TMPTE) Stuttgart 08.07.13 5 Tage Sogeti Deutschland GmbH

TMap NEXT® Test Engineer (TMPTE) München 22.07.13 5 Tage Sogeti Deutschland GmbH

TMap NEXT® Test Manager (TMPTM) Düsseldorf 24.06.13 5 Tage Sogeti Deutschland GmbH

TMap NEXT® Test Manager (TMPTM) München 01.07.13 5 Tage Sogeti Deutschland GmbH

TMap NEXT® Test Manager (TMPTM) Frankfurt 22.07.13 5 Tage Sogeti Deutschland GmbH

TOSCA Certified Administrator (TCA) Wien 20.06.13 2 Tage TRICENTIS Technology & Consulting GmbH

TOSCA Certified Quality Designer (TCQD) Wien 16.07.13 3 Tage TRICENTIS

TOSCA Certified User Advanced Level (TCUAL) Wien 24.06.13 3 Tage TRICENTIS

TOSCA Certified User Foundation Level (TCUFL) München 11.06.13 3 Tage TRICENTIS Technology & Consulting GmbH

TOSCA Certified User Foundation Level (TCUFL) Zürich 17.06.13 3 Tage TRICENTIS Technology & Consulting GmbH

Seminare 2013Juni 2013 bis August 2013

Mehr als 100 weitere Termine finden Sie unter: www.isqi.org/de/seminare.html

ISTQB® CERTIFIED TESTER ADVANCED LEVEL - TECHNICAL TEST ANALYST

ISTQB® Certified Tester Advanced Level Technical Test Analyst Berlin 03.06.13 5 Tage Diaz & Hilterscheid Unternehmensberatung GmbH

ISTQB® Certified Tester Advanced Level Technical Test Analyst München 10.06.13 5 Tage Software Quality Lab GmbH

ISTQB® Certified Tester Advanced Level Technical Test Analyst Frankfurt 17.06.13 5 Tage Logica Deutschland GmbH & Co. KG

ISTQB® Certified Tester Advanced Level Technical Test Analyst Wien 17.06.13 5 Tage Software Quality Lab GmbH

ISTQB® Certified Tester Advanced Level Technical Test Analyst Hamburg 12.08.13 3 Tage Diaz & Hilterscheid Unternehmensberatung GmbH

ISTQB® Certified Tester Advanced Level Technical Test Analyst Basel 12.08.13 3 Tage SynSpace AG

ISQI® CERTIFIED PROFESSIONAL FOR PROJECT MANAGEMENT

iSQI® Certified Pfofessional for Project Management Erlangen 03.06.13 4 Tage Method Park Software AG

iSQI® Certified Pfofessional for Project Management Röttenbach 11.06.13 4 Tage sepp.med gmbh

CPMS® CERTIFIED PROFESSIONAL FOR MEDICAL SOFTWARE – FOUNDATION LEVEL

CPMS® Certified Professional for Medical Software – Foundation Level Röttenbach 11.06.13 4 Tage sepp.med gmbh

INTACSTM – CERTIFIED ASSESSOR ISO/IEC 15504

Automotive SPICE® Training - iNTACS™ zertifizierter Provisional Assessor Kornwestheim 03.06.13 5 Tage KUGLER MAAG CIE GmbH

Zusätzliche Schulungs- und Seminartermine finden Sie auf www.isqi.org!

Ansprechpartner:Anett McAulayTrainings and SeminarsTel.: +49 331 [email protected]

Irrtümer, Termin- und Preisänderungen vorbehalten. Es gelten die allgemeinen Geschäfts- und Preisbedingungen des jeweiligen Veranstalters.

SIE WOLLEN IHR SEMINAR AUCH IM NÄCHSTEN SQ-MAGAZIN BEWERBEN? Wir freuen uns über eine Nachricht.

Henkestr. 91, Haus 8, 3. OG 91052 ErlangenTel +49 9131 91910-0Fax +49 9131 91910-10

David-Gilly-Straße 1 14469 PotsdamTel +49 331 231810-0Fax +49 331 231810-10

iSQI GmbH | www.isqi.org

AG ILE / SCRUM

AU TO MOT IV E

CM MI

TEST

V-MODELL XT

ISO 26262

SOFTWARE ARCH ITECTUR

UML

WE ITERE SEMINARE

TOSCA Certified User Foundation Level (TCUFL) Wien 09.07.13 3 Tage TRICENTIS

TOSCA Technical Training (TTT) Wien 04.06.13 3 Tage TRICENTIS Technology & Consulting GmbH

TPI NEXT® für Testmanager und Projektleiter München 10.06.13 2 Tage Sogeti Deutschland GmbH

TPI NEXT® für Testmanager und Projektleiter Frankfurt 01.07.13 2 Tage Sogeti Deutschland GmbH

TPI NEXT® für Testmanager und Projektleiter Düsseldorf 08.07.13 2 Tage Sogeti Deutschland GmbH

TPI NEXT® für Testmanager und Projektleiter Hamburg 26.08.13 2 Tage Sogeti Deutschland GmbH

Unit Testing Graz 04.06.13 3 Tage Software Quality Lab GmbH

Unit Testing Linz 04.06.13 3 Tage Software Quality Lab GmbH

Unit Testing Wien 04.06.13 3 Tage Software Quality Lab GmbH

Software Quality Breakfast zum Thema Unit Testing Lustenau 05.06.13 ½ Tag Software Quality Lab GmbH

Unit Testing Lustenau 18.06.13 3 Tage Software Quality Lab GmbH

Unit Testing München 18.06.13 3 Tage Software Quality Lab GmbH

UML

Objektorientierte Analyse und Design mit UML inkl. UML-Zertifizierung OCUP-F Hamburg 08.07.13 5 Tage oose Innovative Informatik GmbH

Objektorientierte Analyse und Design mit UML inkl. UML-Zertifizierung OCUP-F Hamburg 19.08.13 5 Tage oose Innovative Informatik GmbH

WEITERE SEMINARE

Anforderungsmanagement Berlin 23.08.13 1 Tag Diaz & Hilterscheid Unternehmensberatung GmbH

Erfolgreich im Reviewteam mitarbeiten - E-Learning online 28.08.13 1 Wo Maud Schlich THE QUALITEERS

FMEA Frankfurt 17.06.13 2 Tage Engineers Consulting GmbH

FTA Frankfurt 19.06.13 1 Tag Engineers Consulting GmbH

HP Quality Center Berlin 10.06.13 2 Tage Diaz & Hilterscheid Unternehmensberatung GmbH

HP Quality Center Berlin 19.08.13 2 Tage Diaz & Hilterscheid Unternehmensberatung GmbH

HP Quicktest Professional Berlin 12.06.13 2 Tage Diaz & Hilterscheid Unternehmensberatung GmbH

Java für Anwendungsentwickler Hamburg 24.06.13 5 Tage oose Innovative Informatik GmbH

Prozesse visualisieren und zum Leben erwecken - E-Learning online 19.08.13 2 Wo Maud Schlich THE QUALITEERS

Requirements Engineering - Anforderungen mit Prosa und Modellen clever erheben und dokumentieren

Düsseldorf 04.06.13 2 Tage SOPHIST GmbH

Requirements Engineering in der Praxis: Anforderungen mit Prosa und Modellen clever erheben und dokumentieren

Nürnberg 15.07.13 2 Tage SOPHIST GmbH

Requirements Engineering und Management inkl. CPRE-Aufbaukurs Hamburg 17.06.13 5 Tage oose Innovative Informatik GmbH

Requirements Engineering und Management inkl. CPRE-Aufbaukurs Hamburg 12.08.13 5 Tage oose Innovative Informatik GmbH

Requirements Management - Anforderungen verwalten, professionell domptieren und geschickt kategorisieren

Nürnberg 10.06.13 1 Tag SOPHIST GmbH

Service Desk und Change Request Management auf Basis des SAP Solution Manager 7.0

Berlin 13.06.13 2 Tage QMETHODS - Business & IT Consulting GmbH

Alle Themen auch als Inhouse-Angebot buchbar!

Im Fokus

-

ÜberschriftFrank Simon

Impressum

Method Park - Agilität auch im schwierigen Umfeld sicher einführen!

Schulung zum Certified Agile Tester

®

Unterstützung von agilen Methoden in der Medizintechnik

SPICE konforme Migration von Projekten

www.methodpark.de

Beratung zu agiler Entwicklung nach ISO 26262

HERAUSGEBER

ASQF e.V.

Henkestraße 91, 91052 Erlangen

Tel +49 9131 91910-0

Fax +49 9131 91910-10

[email protected], www.asqf.de

David-Gilly-Str. 1, 14469 Potsdam

Tel +49 331 231810-0

Fax +49 331 231810-10

[email protected], www.isqi.org

REDAKTION

V.i.S.d.P.:

Stephan Goericke (Hauptgeschäftsführer)

Redaktion:

Felix Winter (Geschäftsführer)

Isabel von Gustedt

[email protected]

[email protected]

SATZ / LAYOUT

Frenkelson Werbeagentur, Potsdam

www.frenkelson.de

FOTOS

ASQF e.V. und iSQI GmbH

Titelbild: © ollyy - Shutterstock.com

Alle Portraits und Grafiken mit

freundlicher Genehmigung der

Autoren.

DRUCK

PRINTEC OFFSET, Kassel

DRUCKAUFLAGE

3.000 Stück

SQ-Magazin Nr. 28 erscheint im September 2013

Thema: SoftskillsAnzeigenschluss: 17.07.2013Druckunterlagenschluss: 24.07.2013

INTERNETAUSGABE

www.asqf.de/mitgliedermagazin-sq-magazin.html

MEDIADATEN

Gern senden wir Ihnen unsere Mediadaten zu. Richten Sie Ihre

Anfrage an [email protected]. Weitergabe und Vervielfäl-

tigung, auch auszugsweise, ist unter vollständiger Angabe der

Quelle erlaubt.

Haben Sie Anregungen zu den Inhalten des SQ-Magazins, dann

schreiben Sie an: [email protected] oder [email protected]

Namentlich gekennzeichnete Beiträge müssen nicht mit der

Meinung der Redaktion übereinstimmen. Die Redaktion behält

sich das Recht auf sinngerechte Kürzung und Bearbeitung ein-

gereichter Manuskripte vor. Wir machen darauf aufmerksam,

dass Daten nicht an Dritte weitergegeben und ausschließlich zur

internen Auswertung herangezogen werden können.


Anzeige

Standard NEWS

Doch zurück zu den Anfängen. 2010 hat sich eine Grup-pe überzeugter Verfechter des modellbasierten Testens zusammen gefunden und im Rahmen des ASQF die „Special Interest Group MBT“ (SIG MBT) gegründet. Er-klärtes Ziel dieser Interessensgemeinschaft ist es, den industriellen Einsatz der Methode zu fördern. Dazu muss jedoch erst einmal ein einheitliches Verständnis geschaf-fen werden, was modellbasiertes Testen überhaupt ist. Wir haben es hier mit einer neuen, aufstrebenden Tech-nologie zu tun. Doch wie so oft, wenn sich etwas ändern soll, beobachten wir Ressentiments. Dem modellbasier-ten Testen haftet im Speziellen ein Ruf vermeintlicher Komplexität an, der sich negativ auf die Akzeptanz durch potentielle Anwender auswirkt. Dies beeinflusst auch die Einschätzung, ob die Methode mit wirtschaftlich vertret-barem Aufwand effizient eingeführt und gelebt werden kann. Aus Sicht der SIG MBT sind diese Bedenken nicht begründet – im Gegenteil: Komplexität und Aufwand zu vermindern und Qualität zu erhöhen sind gerade die Stär-ken des modellbasierten Testens.

Schließlich starten wir ja nicht von der grünen Wiese. In den letzten Jahren haben sich durchaus Quasi-Stan-dards und Best Practices entwickelt. Es gibt eine Vielzahl von Ansätzen, die sich jeweils in ihrem Kontext bewährt haben, untereinander jedoch nur schwer vergleichbar sind. Hier Klarheit darüber zu schaffen, wo die Gemein-samkeiten und Unterschiede liegen, ist schon ein erster Schritt zum Ziel. Nur wer ein klares und strukturiertes Verständnis der Grundlagen und Konzepte des modell-basierten Testens besitzt, kann von den enormen Vortei-len der Methodik bezüglich Verbesserung der Wirtschaft-lichkeit und Qualität der Testprozesse im industriellen Einsatz profitieren.

Insbesondere benötigen wir eine Standardisierung des Vokabulars und eine Klassifizierung der verschiedenen Ansätze, um besser innerhalb der MBT-Community kom-munizieren zu können. Hinsichtlich einer Taxonomie ha-ben [Sch2007], [Roß2010] und [Utt2011] bereits Vorschlä-ge gemacht, während das European Telecommunications Standards Institute in seinem Standard ETSI ES 202 951 [ETSI2011] die Grundlagen für ein Glossar gelegt hat.

All diese Ansätze hat die SIG MBT nun in einen neuen Ausbildungsstandard für eine zertifizierende Schulung

zum modellbasierten Tester gegossen, den CMBT. Die neue Schulung ist als Ergänzung zum Certified Tester – Foundation Level (CTFL) gedacht. Das Trainingsmaterial ist auf Englisch, die Schulung dauert zwei Tage und en-det mit einer Prüfung. Wer die Prüfung besteht, erhält ein Zertifikat und die nötige Expertise, das Gelernte in der täglichen Arbeit umzusetzen.

In Anlehnung an moderne Akkreditierungskonzepte stellt die SIG MBT einen Satz Schulungsunterlagen für die Schulungsdurchführung zur Verfügung. Das Internatio-nal Software Quality Institute iSQI ® bietet interessierten Trainingsanbietern die Möglichkeit, eine CMBT Train-the-Trainer-Schulung zu absolvieren und lizensiert die Ver-wendungsrechte an den Unterlagen. Dadurch wird der Akkreditierungsprozess vereinfacht. Die Kosten einer Ak-kreditierung werden nicht im Voraus fällig, sondern rich-ten sich nach dem individuellen Trainingsvolumen des Anbieters.

Inhaltlich gliedert sich der CMBT in vier Module auf:1. Grundlagen des modellbasierten Testens2. Modelle in der Entwicklung3. Testmodelle4. Modellbasierte Testprozesse

In den Grundlagen wird aufgezeigt, wo und wie Modelle im Test helfen können und mit welchen Schwierigkeiten möglicherweise gerechnet werden muss. Die Schu-lungsteilnehmer sollen realistisch einschätzen lernen, welche Möglichkeiten MBT bietet, damit sie sich später nicht enttäuscht abwenden, nachdem sie vergeblich die falschen Ziele angestrebt haben. Schließlich bestimmt – wie bei jeder methodischen Änderung – die richtige, auf konkrete Projektziele ausgerichtete Einsatzplanung den Erfolg. Im zweiten Modul werden verschiedene Modelltypen und Notationen erläutert. Dabei handelt es sich nicht um einen Crashkurs in UML, sondern um eine strukturierte Übersicht, welche Notationsform sich für welchen Fokus eignet. Im dritten Modul wird es ganz konkret. Die Teilnehmer lernen, wie man von der Testidee zum Testmodelle und von dort weiter zu abstrakten oder konkreten Testfällen gelangt. Neben vielen praktischen Beispielen bekommen sie eine Reihe von Best Practices an die Hand, wie sie z.B. das leidige Thema der Test-fallexplosion in den Griff bekommen können. Dadurch

Nachwuchs bei den „Certified’s“Anne Kramer & Armin Metzger

Bald ist es soweit: Die Certified Familie des iSQI bekommt ein neues Geschwisterchen. Im Mai diesen Jahres fand der Pilot des „Certified Model-Based Tester“ (kurz: CMBT) statt. Danach gehen die ersten Anbieter an den Start.


Standard NEWS

Dr. Anne Kramer ist

seit 2001 Projektleiterin,

Prozessberaterin und

Trainerin für die

sepp.med GmbH.

Dr. Armin Metzger ist

als Abteilungsleiter bei

sepp.med GmbH ver-

antwortlich für IT-Mul-

tiprojekte in komplexen

und sicherheitskritischen

Branchen.

erwerben die Schulungsteilnehmer die nötige Expertise und erforderliche Sicherheit im praktischen Umgang mit MBT. Dieser Abschnitt entspricht knapp 40% der gesam-ten Schulung. Im letzten Modul wird der Stoff abgerundet durch die Darstellung, wie sich MBT in den Testprozess einfügt, bzw. einführen lässt.

In einer Reihe von Übungen werden die Inhalte bis zur kognitive Stufe K3 (anwenden), streckenweise sogar bis K4 (analysieren), vermittelt.

INTERESSIERT? WEITERE INFORMATIONEN UNTERmodel-based.isqi.org

REFERENZEN [ETSI2011] ETSI ES 202 951 V1.1.1 (2011-07), “Requirements for Modeling Nota-tions”, 2011 [Roß2010] T. Roßner, C. Brandes, H. Götz, M. Winter. „Basiswissen Modelbasierter Test“, dpunkt.verlag Heidelberg, 2010 [Sch2007] I. Schieferdecker, “Modellbasiertes Testen”, in: OBJEKT-Spektrum 3/07, 2007, 39-45 [Utt2011] M. Utting, A. Pretschner, B. Legeard, “A taxonomy of model-ba-sed testing approaches”, in: Software Testing, Verification and Reliability, John Wiley & Sons, Ltd., 2011.


Vielfalt unter dem Konferenzmotto

„ More for Less – Maximale Ergebnisse mit geringstem Einsatz “

www.iqnite-conferences.com/ch

Die Konferenz für Software-Qualität und -Testen

24. September 2013 | Zürich, Schweiz

Qualitätsmanagement

agil

Best

Pra

ctic

e

Clo

ud

etab

liert

Podi

umsd

isku

ssio

nA

usbi

ldun

g

Erfahrungsaustausch

Risk

Man

agem

ent

Proz

esse

TrendsStandards

unabhängig

inno

vati

vinteraktivKeynotes

Networkingpraxisrelevant

Test

man

agem

ent

Managed Services

Ausstellung

Out

sour

cing

inspirierend

Security

Recr

uiti

ng

Mob

ile C

ompu

ting

Offshoring

Requirements

Services

Testautomation

Qua

lität

ssic

heru

ng

Metriken

Workshops

Impu

lse

inte

rakt

iv

Busi

ness

-Sol

utio

ns

Compliance

Prog

ram

mko

mit

ee

Erfa

hrun

gsbe

rich

te

Quality SpotlightsMethoden

Zertifi zierung

interdisziplinärfokussiert

Zür

ich

Nearshoring

ISTQ

B

Performance Ideen

informativ

Last

test

Hom

esho

ring

Proz

essm

odel

le

Tools

15 % Rabatt

für Leser des SQ-Magazins

Aktionscode: CHSQ15

(Gültig bis 15.8.)

Anzeige SQ-Magazin 210x136_April_2013_rz.indd 1 17.04.2013 17:40:42

Anzeige

Vielfalt unter dem Konferenzmotto

„ More for Less – Maximale Ergebnisse mit geringstem Einsatz “

www.iqnite-conferences.com/ch

Die Konferenz für Software-Qualität und -Testen

24. September 2013 | Zürich, Schweiz

Qualitätsmanagement

agil

Best

Pra

ctic

e

Clo

ud

etab

liert

Podi

umsd

isku

ssio

nA

usbi

ldun

g

Erfahrungsaustausch

Risk

Man

agem

ent

Proz

esse

TrendsStandards

unabhängig

inno

vati

vinteraktivKeynotes

Networkingpraxisrelevant

Test

man

agem

ent

Managed Services

Ausstellung

Out

sour

cing

inspirierend

Security

Recr

uiti

ng

Mob

ile C

ompu

ting

Offshoring

Requirements

Services

Testautomation

Qua

lität

ssic

heru

ng

Metriken

Workshops

Impu

lse

inte

rakt

iv

Busi

ness

-Sol

utio

ns

Compliance

Prog

ram

mko

mit

ee

Erfa

hrun

gsbe

rich

te

Quality SpotlightsMethoden

Zertifi zierung

interdisziplinärfokussiert

Zür

ich

Nearshoring

ISTQ

B

Performance Ideen

informativ

Last

test

Hom

esho

ring

Proz

essm

odel

le

Tools

15 % Rabatt

für Leser des SQ-Magazins

Aktionscode: CHSQ15

(Gültig bis 15.8.)

Anzeige SQ-Magazin 210x136_April_2013_rz.indd 1 17.04.2013 17:40:42

Bewährtes erhalten und mit Neuem verbinden

In den zurückliegenden Jahrzehnten wurden viele Metho-den, Vorgehensmodelle und auch Praktiken propagiert, mit deren Hilfe sich die Entwicklung von Softwaresyste-men als einfach und im Vergleich zu vorher qualitätsver-bessernd ergeben soll. Leider wird der Erfolg oft nur dann versprochen, wenn ein kompletter Umstieg auf die neuen Ideen vollzogen wird. In dem Beitrag möchten wir am Bei-spiel Test-Driven Development zeigen, wie ein Umstieg un-ter Beibehaltung von Bewährtem möglich ist und welche Vorteile sich ergeben.

Test-Driven Development

Die Diskussion über testgetriebene Softwareentwicklung (Test-Driven Development TDD) hat dem Testen einen enormen Vorschub gegeben und das Thema in den Fokus der Softwareentwickler gebracht. Testen wird nicht länger als lästige Aktivität am Ende eines langen Projekts gese-hen, sondern von Beginn an in die Iterationen agiler Pro-jekte integriert. Protagonisten wie beispielsweise Robert Martin sehen jedoch in diesem Ansatz eher eine Aktivität der Spezifikation und erst in zweiter Linie eine Aktivität des Testens als qualitäts-prüfende Maßnahme [Mar06].

Example-Driven Development

Der Ansatz erst einen Testfall zu spezifizieren und anschlie-ßend die geforderte Funktionalität umzusetzen, die dann mit dem implementierten Testfall überprüft wird, führt zu einem sehr schnellen Feedback. Die Testfälle sind dabei illustrierende Beispiele, die insbesondere in der Kommu-nikation mit dem Kunden genutzt werden können. Bereits vor 10 Jahren schrieb Brian Marick: „You write a test to help you clarify your thinking about a problem. You use it as an illustrative example of the way the code ought to behave. It is, fortunately, an example that actively checks the code, which is reassuring. These tests also find bugs, but that is a secondary purpose.“ Er schlägt vor, für diese Beispiele nicht den Begriff Tests zu verwenden, sondern „checked examples“ [Mar03]. »Beispielgetriebene Soft-wareentwicklung« beschreibt das Vorgehen treffender.

Der Begriff testgetriebene Softwareentwicklung suggeriert als Ergebnis ein nach dem Stand der Kunst getestetes Softwaresystem. Aber wichtige Aspekte fehlen, die im fol-genden näher erläutert werden.

Komponenten- und Akzeptanztest

Zwei Abstraktionsebenen sind beim TDD vorgesehen: Komponententest durch die Entwickler und Akzeptanztest durch den Kunden oder Anwender. Ein Integrationstests als Verbindung zwischen den beiden Ebenen wird ausge-klammert und nicht explizit betrachtet. Allerdings erhö-hen Testfälle auf verschiedenen Abstraktionsebenen die Chance Fehler frühzeitig aufzudecken. Die Summe aller Komponententests im Rahmen eines „Daily Builds“ reicht als Ersatz nicht aus. Auf der anderen Seite greifen Akzep-tanztests häufig komplexe Geschäftsprozesse aus Sicht des Anwenders auf und maskieren eventuell vorhandene Integrationsfehler. Zusätzliche (Integrations-)Testfälle sind notwendig, die im Rahmen der kontinuierlichen Integrati-on das direkte Einsatzumfeld einer Komponente und die Schnittstellen zwischen Komponenten untersuchen. Darü-ber hinaus gibt es Fehler, die nur beim Integrationstest auf-gedeckt werden können [Win12]. Jede Teststufe benötigt somit ihre eigenen Testfälle.

Abb. 1: Testgetriebenes Vorgehen ([Amb])

Von beispielgetrieben zu testgetriebenen

Im Kontext der Diskussion testgetriebener Softwareent-wicklung spielen Testentwurfsverfahen eine untergeord-nete Rolle. Vordergründig wird eher die Testautomatisie-

Traditionell cum Agil Am Beispiel Test-Driven Development

Im Fokus

Karin Vosseberg & Andreas Spillner


rung als das Allheilmittel für bessere Tests diskutiert. Ein hoher Abdeckungsgrad in der Testautomatisierung allein wird jedoch nicht zu dem gewünschten Ergebnis führen, die Effektivität der Tests zu steigern. Was fehlt ist ein sys-tematischer Ansatz zur Testfallermittlung.

Abb. 2: Systematisches Testgetriebenes Vorgehen

Damit TESTgetriebene Softwareentwicklung den Namen verdient, müssen die erstellten Testfälle weniger dem Zufall und dem individuellen Einfallsreichtum des Entwicklers bzw. des Kunden überlassen, sondern systematisch entwickelt werden. Auch das beschriebene Testendekriterium einer testgetriebenen Softwareentwicklung ist wenig hilfreich, denn Testfälle werden spezifiziert „ ... bis die gewünschte Funktionalität erreicht oder der bekannte Fehler bereinigt ist und dem Entwickler keine sinnvollen weiteren Tests mehr einfallen, die vielleicht noch scheitern könnten“ [Wiki].

Bereits beim Komponententest sind geeignete Teststrate-gien zu entwickeln, die mit den Iterationen der Softwareent-wicklung fortgeschrieben werden. In Anlehnung an die Ab-laufbeschreibung für testgetriebene Softwareentwicklung von Scott Ambler [Amb] (Abb. 1) werden die notwendigen Aktivitäten einer systematischen Testfallermittlung (Abb. 2) deutlich.

Eine geeignete Teststrategie ist auszuwählen, welche die passenden Testentwurfsverfahren und deren Intensität bestimmt. Die aus der Strategie resultierenden Testfäl-le werden zu den bisherigen Testfällen hinzugefügt und


Prof. Dr. Karin Vosseberg ist Hochschullehrerin an

der Hochschule Bremerhaven mit den Schwerpunk-

ten Systemintegration und Qualitätssicherung.

Prof. Dr. Andreas Spillner ist Hochschullehrer für

Software Engineering und Qualitätssicherung an

der Hochschule Bremen. Er ist Mitglied im ASQF-

Beirat, war Gründungsmitglied und ist nun Ehren-

mitglied des German Testing Boards.


Im Fokus

qualitätsgesichert, um fehlerhafte oder unnötige Testfälle zu vermeiden. Sind die festgelegten Anforderungen der Strategie erfüllt, kann die Testsuite ausgeführt werden. Sie muss fehlschlagen, weil ja noch keine Implementie-rung vorhanden ist. Schlägt sie nicht fehl, ist die Testsuite nicht passend zur Strategie und der zu implementierenden Funktionalität erweitert worden oder die »neue« Funktio-nalität ist bereits implementiert.

Die Funktionalität wird programmiert und die Testsuite er-neut ausgeführt. Das Programmstück wird solange korri-giert, bis keine Fehler auftreten. Dann ist zu entscheiden, ob die Teststrategie ausreichend umgesetzt wurde oder ob ein weiterer Durchlauf mit ergänzenden Testfällen notwendig ist. Das ist ein nachvollziehbares Kriterium für das Ende der Testaktivitäten einer Iteration. Die nächste Iteration/Funkti-on beginnt mit der Festlegung (oder ggf. Erweiterung) der Teststrategie.

Beim systematischen testbetriebenen Vorgehen wird ein Testfall nicht als ein Beispiel geschrieben, um dann den kleinen Teil der geforderte Funktionalität, der den Testfall abdeckt, zu implementieren. Es werden alle Testfälle ent-wickelt, die der geforderten Funktionalität und der dazu entwickelten Teststrategie zuzuordnen sind. Dabei ist die zu entwickelnde Teststrategie und die Granularität der zu implementierenden Funktionalität auf die jeweiligen Anfor-derungen einer Iteration im Projekt anzupassen, um nicht wieder in starre Verhaltensmuster traditioneller Vorgehens-modelle zu verfallen.

Der beschriebene Ansatz ist über die Entwicklung der Kom-ponenten hinaus auf die gesamte Systementwicklung an-zuwenden. Integrations- und Akzeptanztests lassen sich in gleicher Weise durchführen.

Integration des Testprozesses

Die Diskussion in der Welt der Qualitätssicherung ist stark geprägt durch die Aufgaben eines systematischen Testpro-zesses [Spi12]. Um die Akzeptanz des generischen ISTQBⓇ Testprozesses in der agilen Welt der Entwickler zu etab-lieren, müssen die Aufgaben in die Entwicklung integriert werden. In einem systematischen testgetriebenen Vorgehen sind die Aufgaben des Testprozess bei jeder Iteration, wie vorab beschrieben, durchzuführen. Abb. 3 verdeutlicht die Zuordnung der Testprozessaufgaben zu den einzelnen Ak-tivitäten.

Fazit

Um von einer beispielgetriebenen zu einer testgetriebenen Softwareentwicklung in agilen Projekten zu kommen, brau-chen wir keine neuen Testentwurfsverfahren. Es ist vielmehr sinnvoll die existierenden Verfahren in den agilen Projektall-

tag zu integrieren. Dafür müssen die ergänzenden Aktivitä-ten in den einzelnen Iterationen der Softwareentwicklung explizit eingeplant und auch bei Prüfung der Ergebnisse, beispielsweise in Form von Reviews, ihren Platz bekom-men. Dies verdeutlicht den Mehrwert testgetriebener Soft-wareentwicklung als qualitätssichernde Maßnahme (s.a. [Lin13]).

Die Diskussionen in den unterschiedlichen Welten über Agilität und systematischer Qualitätssicherung können sich gegenseitig bereichern und zu einer besseren Qualität der entwickelten Softwareprodukte führen. Am Beispiel der testgetriebenen Softwareentwicklung wurde aufgezeigt, wie agile Praktiken mit systematischen Ansätzen der Qualitäts-sicherung erweitert werden können. Dies wird dazu beitra-gen die Kluft zwischen Entwicklern und Testern weiter abzu-bauen und zu einem Miteinander in der Qualitätssteigerung der Softwareprodukte führen.

LITERATUR UND LINKS [Amb] Scott W. Ambler: Introduction to Test Driven Development. www.agiledata.org/essays/tdd.html (Stand: 29.03.2013) [Lin13] Tilo Linz: Testen in Scrum-Projekten - Leitfaden für Softwarequalität in der agilen Welt, dpunkt-Verlag, 2013 [Mar03] Brian Marick: Agile testing directions: tests and examples, 2003, www.exampler.com/old-blog/2003/08/22/ (Stand: 29.03.2013) [Mar06] Robert C. Martin, Micah Martin: Agile Principles, Patterns, and Practices in C#. Prentice Hall, 2006 [Spi12] Andreas Spillner, Tilo Linz: Basiswissen Softwaretest. dpunkt-Verlag, 5. Aufl. 2012 [Wiki] de.wikipedia.org/wiki/Testgetriebene_Entwicklung (Stand: 29.03.2013) [Win12] Mario Winter, Mohsen Ekssir-Monfared, Harry M. Sneed, Richard Seidl, Lars Borner: Der Integrationstest: Von Entwurf und Architektur zur Kompo-nenten- und Systemintegration, Hanser Verlag, 2012


Abb. 3: Integration der Testprozessaktivitäten

SAG WAS Studentische AusbildunG und berufliche Weiterbildung in Agiler Softwareentwicklung

WORKSHOP WÄHREND DER GI-JAHRESTAGUNG AM 19. SEPTEMBER 2013

Prof. Dr. Karin Vosseberg, Hochschule Bremerhaven, [email protected]

Dr. Michael Mlynarski, QualityMinds GmbH, [email protected]

ANSPRECHPARTNER: Prof. Dr. Andreas Spillner, Hochschule Bremen, [email protected]

WEITERE INFOS UNTER www.informatik2013.de/workshops_de.html

Im Gespräch35 Ausgabe 27 | Juni 2013

Sie wurden kürzlich zum Vorsitzenden des German Te-sting Boards (GTB e.V.) gewählt. Zunächst unseren herz-lichen Glückwunsch dazu. Können Sie kurz unseren Le-sern erklären, was das GTB ist und was es für Aufgaben wahrnimmt?

Danke.

Das German Testing Board ist bekanntermaßen ein Zusam-menschluss von Fachexperten auf dem Gebiet „Test von Software und softwarebasierten Systemen“. In Deutschland verantwortet das GTB als Gründungsmitglied des Interna-tional Software Testing Qualifications Boards (ISTQB) das Certified-Tester- Schema zur Qualifizierung und Prüfung von Software-Testern. Das GTB kümmert sich um die Weiterent-wicklung und Lokalisierung des Glossars, der Lehrpläne, der entsprechenden Prüfungsfragen und die Akkreditierung der Trainingsprovider. Es sorgt somit für eine gleichbleibend hohe Qualität der Tester-Ausbildung in Deutschland.

30.000 zertifizierte Personen in Deutschland - das ist eine beeindruckende Zahl. Was ist das Erfolgsgeheim-nis?

Einer der Erfolgsfaktoren ist sicherlich, dass durch die per-sönlichen Mitglieder des GTB die Bereiche Industrie, Trai-ningsanbieter und Hochschulen gleichermaßen repräsen-tiert sind.

Ein anderer Erfolgsfaktor war und ist sicherlich, dass wir zum richtigen Zeitpunkt die Weichen für die Etablierung des Certified-Tester-Schemas in Deutschland und seiner Inter-nationalisierung weltweit gestellt haben.

Stellen Sie sich vor, Sie arbeiten heute in einem Automotive Projekt zur Entwicklung eines Steuergerätes. In einem sol-chen Projekt ist es nicht ungewöhnlich, dass Entwickler und Tester aus verschiedenen Kontinenten und Kulturkreisen (z.B. Europa, Indien und Nordamerika) an ein und derselben Aufgabe zusammenarbeiten. Da ist es hilfreich und notwen-dig, dass alle Beteiligten die gleiche Sprache sprechen und die gleiche Methoden und Verfahren mindestens bis zu ei-ner gewissen Ebene beherrschen.

Des Weiteren haben wir durch die Umsetzung einer qua-litätsorientierten Wachstumsstrategie eine hohe Marktak-zeptanz erreicht. Konkret dazu: Seit einigen Jahren finden Sie an jedem Wochenende bei einer Suche nach „ISTQB“ in den bekannten Online-Stellenbörsen konstant weit mehr als 100 Stellenangebote für einen ISTQB® Certified Tester aus dem deutschsprachigen Raum.

Ihr Amtszeit beträgt 2 Jahre. Welche Ziele haben Sie sich denn gestellt? Was wollen Sie mit dem GTB e.V. errei-chen?

Ich war stellvertretender Vorsitzender des GTB seit diese Rolle in 2004 geschaffen wurde. Ich werde nun als Vorsit-zender nicht alles anders machen, sondern den Spagat ver-suchen, auf der einen Seite das Bestehende zu bewahren, und auf der anderen Seite Innovationen voran zu treiben, das Aufgreifen aktueller Trends zu initiieren und zu unterstützen, um das Bestehende nach den Bedürfnissen des Marktes zu ergänzen. Als Beispiel möchte ich hier domänenspezifische Ergänzungen nennen, die wir gerade gemeinsam mit unse-ren Partnern den Zertifizierungsstellen und der Technical Advisory Group (TAG) in Vorbereitung bzw. auf den Weg ge-bracht haben. Dabei setzen wir auf unsere Grundprinzipien wie Neutralität, Fairness, Offenheit und Transparenz. Eben-so pflegen wir weiterhin klare und regelmäßige Kommunika-tion mit unseren Partnern: der Industrie, den Trainingsanbie-tern und den Hochschulen.

Als konkrete umsetzbare Ziele sehe ich die Anpassung der Organisationsstruktur des GTB e.V.; die partielle Öffnung des GTB für die Mitarbeit von Fachexperten als Nicht-Mitglieder sowie die Anbindung der IT-Industrie und der IT-Dienstleister über eine fördernde Mitgliedschaft, um das Ziel: „50.000 GTB-autorisierte Certified Tester Prüfungen“ in zwei Jahren zu erreichen.

GTB e.V. und ASQF e.V. blicken auf eine lange gemein-same Geschichte zurück und haben die gleichen Wur-zeln. Welche Bedeutung messen Sie als GTB-Vorsitzen-der heute dem ASQF e.V. bei?

Es ist unbestritten, dass die Wurzeln des GTB e.V. im ASQF liegen. Während sich GTB e.V. als Fachexpertengremium aktuell nur um das Testen von Software und softwareba-sierten Systemen kümmert, deckt der ASQF ein viel breite-res Spektrum mit all seinen Facetten ab. Ich sehe den ASQF deshalb als eine komplementäre Ergänzung und einen Part-ner des GTB.

Horst Pohlmann ist Leiter

Prozesse, Methoden und

Tools bei Lemförder Elec-

tronic. Seit 2010 ist er Lehr-

beauftragter für Software

Qualitätsmanagement an

der Hochschule Ostwest-

falen-Lippe.

Interview mitHorst Pohlmann

Das Interview mit dem neuen Präsidenten des GTB führte Stephan Goericke

Als Teil eines agilen Entwicklungsteams haben Tester eine besondere Verantwortung. Sie müssen unter anderem ver-hindern, dass die technischen Schulden (Technical Debt) ausufern.

Technical Debt

„Technical Debt“ ist ein Begriff für mangelhafte Software. Er soll die Problematik unzulänglicher Softwarequalität in betriebswirtschaftlichen Kategorien zum Ausdruck brin-gen [1]. Managern soll damit gezeigt werden, dass Ver-säumnisse in der Software Entwicklung negative Folgen haben, die ihnen später Kosten verursachen. Der Begriff debt erinnert daran, dass man sie irgendwann abzuzahlen hat. Die Höhe der Software Schulden eines Projektes ist messbar. Sie kann als absolute Kostenzahl oder relativ zu den Entwicklungskosten des jeweiligen Projektes ausge-drückt werden. Der Begriff wurde von Ward Cunningham auf der OOPSLA Tagung in 1992 geprägt. „Technical Dept“ ist im originalen Sinne von Cunningham „all the not quite right code which we postpone making it right“ [2].

Eine Formel für die Kalkulation der Schulden haben Mitar-beiter der CAST Software Limited in Texas vorgeschlagen. Diese Formel verbindet Problemarten mit Aufwand und Auf-wand mit Geld. Die Basisformel ist eine Erfahrungsdaten-bank zahlreicher Projekte, aus der der mittlere Aufwand zur Beseitigung von Softwaremängeln hervorgeht [3]. Das Ref-actoring einer Methode kann z.B. einen halben Tag kosten. Bei einem Stundensatz von US$ 70 sind das $ 280. Eine fehlende Ausnahmebehandlung einzubauen kostet viel-

Die Rolle des agilen Testers im Kampf gegen technische Schulden

Im Fokus

Harry M. Sneed & Richard Seidl


leicht nur eine Stunde, aber die Implementierung erforder-licher Sicherheitsprüfungen in einer Komponente könnte mehrere Tage dauern. Der Verdienst der Texaner liegt da-rin, dass sie etliche Mangelarten identifiziert, klassifiziert und mit Aufwandszahlen versehen haben.

Beispiele für die Mangelarten sind:- eingebaute SQL-Abfragen- leere Catch-Blöcke- zu komplexe Bedingungen- fehlende Kommentare- redundante Codeblöcke- uneinheitliche Namensvergebung- Schleifen ohne Notbremse- zu tief verschachtelter Code

Die Schulden für solche Codemängel sind die Anzahl der Mängelvorkommnisse multipliziert mit den Stunden der Behebung mal die Stundenkosten.

Zu diesen statisch erkennbaren Mängeln kommen noch die ausgerechneten Fehler, die beim Test gelegentlich auf-treten. Aus Zeitgründen werden nicht alle Fehler in einem Release beseitigt, sofern sie nicht die Lauffähigkeit der Software beeinträchtigen. Dazu zählen Fehler in den Aus-gaben, z.B. falsch berechnete Beträge und verschobene Texte, sowie Fehler in der Eingabeprüfung. Hinzu kom-men Performanzprobleme wie zu lange Antwortzeiten und Time-Out-Unterbrechungen. Die Benutzer können vorü-bergehend mit solchen Mängeln leben, aber irgendwann stören sie und bis zur endgültigen Freigabe müssen sie be-hoben sein. Der Aufwand für deren Behebung zählt zu den Projektschulden, die aufgrund des Aufwandes errechnet werden können. Bill Curtis schätzt den mittleren Schulden-

Traditionell vs. Agil37 Ausgabe 27 | Juni 2013

stand für agile Projekte auf $ 3,61 pro Anweisung [4]. Dies ist das absolute Maß der Schulden. Es ist auch möglich, technische Schulden relativ zu den Kosten der Entwicklung zu messen.

Rechtzeitige Problemaufdeckung zur Vermeidung von technical depts

Ein Vorteil von agilen Teams ist das ständige Feedback. Deshalb sind Tester mit im Team. Wenn es darum geht, einen Qualitätsverfall zu vermeiden, haben die Tester in einem agilen Team mehr zu tun als nur zu testen. Sie si-chern die Qualität des Produktes während seiner Entste-hung an Ort und Stelle. Dies geschieht durch eine Reihe rechtzeitiger Kontrollmaßnahmen. Dazu gehören Reviews der User Stories, die Prüfung des Codes, die Abnahme der Unit-Testergebnisse und einen fortdauernden Integrations-test [5].

Beim Review der Stories geht es darum, die Story-Texte zu analysieren, zu ergänzen und notfalls nachzubessern. Oft wird der Product Owner etwas übersehen oder unzu-reichend erklären. Die Tester sollen ihn darauf aufmerk-sam machen und mit ihm zusammen die fehlenden Punkte nachholen und die unzureichenden Passagen klären. Bei der Prüfung des Codes können die Tester die Konfor-mität mit den Codierregeln, die Einhaltung der Architektur-richtlinien und die Gestaltung des Codes bewerten. Viele Versäumnisse wie fehlende Sicherheitsprüfungen und mangelnde Fehlerbehandlung lassen sich nur im Code erkennen. Eine automatisierte Codeanalyse ist eine gute Möglichkeit diese schnelle Rückkopplung zu verwirklichen. Bei der Abnahme der Unit-Testergebnisse haben die Tester darauf zu achten, dass es genügend und qualitativ gute Testfälle gibt und eine ausreichende Modultestüberde-ckung erreichen. Es ist nicht unbedingt ihre Aufgabe, den Unit-Test selber zu machen, obwohl es agile Projekte gibt, wo dies geschieht. Die agilen Tester sollten bemüht sein, den Entwicklern im-mer rasch Feedback geben zu können [6]. „Continuous Integration“ macht dies möglich [7]. Der Tester hat einen Integrationstestrahmen, in den er die neuen Komponen-ten hineinsteckt. Die bisherigen Komponenten sind bereits vorhanden. Sie werden täglich mit den neuen ergänzt. Na-türlich spielt hier die Testautomation eine entscheidende Rolle. Mit den Testwerkzeugen ist es möglich, den Regres-sionstest täglich zu wiederholen und dabei auch noch den Funktionstest der neuesten Komponenten zu fahren. Pro-bleme, die auftreten, können dann sofort an die Entwick-ler zurückgemeldet werden. Dies ist der entscheidende Vorteil gegenüber der konventionellen, bürokratischen Qualitätssicherung, bei der es oft Wochen dauert, bis die Fehlermeldungen und Mängelberichte an die Entwickler zurückgemeldet werden konnten. So gingen wertvolle Ent-wicklerstunden verloren.

Harry M. Sneed ist Tester und Berater der

ANECON GmbH. Zudem unterrichtet er Soft-

wareentwicklung an der Universität von Regens-

burg und erhielt 2011 den Deutschen Preis für

Software-Qualität.

Richard Seidl ist Testspezialist der GETEMED

Medizin- und Informationstechnik AG. Er ist für

die Integrations- und Systemtests der Soft-, Firm-

und Hardware verantwortlich.

Im Fokus Ausgabe 27 | Juni 2013 38

Funktionen der Software getestet hat. Wie gut der Code ist, kann man erst beurteilen, wenn man den Code ausführ-lich analysiert hat, und wie gut das Gesamtsystem ist, kann man erst beurteilen, wenn man es eine Weile verwendet hat. Die besten Indikatoren für die Qualität der Software ist die Anzahl der bisher gefundenen Fehler relativ zur funkti-onalen Testüberdeckung und die Anzahl der Codemängel relativ zur Anzahl der geprüften Code-Anweisungen. Für beide Maße sollte es Sollwerte geben, welche die Tester vorschlagen und mit den anderen Teammitgliedern abstim-men. Damit wird die Position der einzelnen Komponente am Kanban-Brett fixierbar und der Abstand des Istzustandes vom Sollzustand für alle im Team erkennbar.

Lisa Crispin weist darauf hin, dass die Softwarequalität das endgültige Maß für die agile Entwicklung ist [10]. Der funk-tionale Fortschritt darf nicht auf Kosten der Softwarequa-lität gewonnen werden. Nach jedem Release – alle 2 bis 4 Wochen – soll die Qualität wieder gemessen werden. Wenn sie nicht ausreichend ist, kann sie im Laufe des nächsten Releases neben der funktionalen Weiterentwicklung nach-gebessert werden. Wenn sie allzu schlecht ist, muss das nächste Release ein Überarbeitungs-Release sein, bei dem die Fehler entfernt werden und die Software refak-toriert wird. Crispin räumt sogar ein separates Qualitäts-sicherungs-Team ein, welches neben dem Entwicklungs-team daran arbeitet, die Qualität der erstellten Software zu verfolgen und an das Entwicklungsteam zu berichten. Damit wäre die alte Trennung zwischen Entwicklung und Test wieder da.

Johanna Rothman meint, die Tester müssen mitbestim-men, was „done“ bedeutet, und das vom Anfang des Pro-jektes an. „To be done also means that the quality criteria set by the team are met“. Dies hat zur Folge, dass diese Kriterien von allen Beteiligten akzeptiert und praktiziert werden. Jeder im Team muss sich seiner Verantwortung für die Qualität bewusst sein und seinen Teil dazu beitra-gen. „Everybody in the team needs to take responsibility for quality and for keeping technical debt at a manageable level. The whole team has to make a meaningful commit-ment to quality“. Die Qualität der Software ist zwar eine Angelegenheit des Teams in seiner Gesamtheit, aber die Tester im Team haben eine besondere Verantwortung. Sie müssen dafür sorgen, dass die technischen Schulden ein-gegrenzt und abgebaut werden.

L ITER ATURHINWEISE [1] Kruchten, P. /Nord, R.: „Technical Debt – from Metaphor to Theory and Practice“. IEEE Software, Dez. 2012, S. 18 [2] Cunningham, W.: “The WyCash Portfolio Management System” Proc. of ACM Object-Oriented Programming Systems, Languages and Applications – DOPSLA, New Orleans, 1992, S.29 [3] Curtis, B. / Sappidi, J. / Szynkarski, A.: “Estimating the Principle of an Application’s Technical Debt”, IEEE Software, Dez. 2012, S. 34 [4] Wendehost, T. “Der Source Code birgt eine Kostenfalle” in Computerwoche, Nr. 10, 2013, S. 34 [5] Janzen, D., Hossein, S.: “Test-Driven Development – Concepts, Taxonomy and Future Direction”, IEEE Computer, Sept. 2005, S. 43 [6] Bloch, U.: „Wenn Integration mit Agilität nicht Schritt hält“, Computerwoche, Nr. 24, Juni 2011, S. 22 [7] Du-vall, P. /Matyas, S. /Glover, A.: Continuous Integration – Improving Software Quality and reducing Risk, Addison-Wesley, Reading Ma., 2007 [8] Cockburn, A.: Agile Software Development, Addison-Wesley, Reading, Ma., 2002 [9] Bavani, R.: “Distributed Agile Testing and Technical Debt”, IEEE Software, Dez. 2012, S. 28 [10] Crispin, L. / Gregory, J.: Agile Testing – A practical Guide for Testers and agile Teams, Addison-Wesley-Longman, Amsterdam, 2009

In der agilen Entwicklung ist dies nicht mehr der Fall. Es gibt keine derartigen Leerzeiten mehr. Dafür müssen die Tester ständig hinter den Entwicklern herlaufen, um das gleiche Tempo zu bewahren, wie die Entwickler selbst. Dies hat zur Folge, dass Tester sich in der Entwicklungsumgebung gut auskennen, über leistungsfähige Werkzeuge verfügen und ein gutes Verhältnis zu den Entwicklern haben müssen.Wenn diese drei Bedingungen nicht erfüllt sind, dann kön-nen die Tester nicht den von ihnen erwarteten Nutzen er-bringen, egal, wie gut sie die Testtechnologie beherrschen. Der agile Test verlangt eben mehr von den Testern, als dies bisher der Fall war.Die rechtzeitige Aufdeckung von Problemen und die schnel-le Rückkopplung zu den Entwicklern sind der Hauptnutzen eines agilen Tests [8]. Sie müssen gewährleistet werden. Sie sind auch der Grund, warum die Tester mit den Ent-wicklern zusammen sein sollten. Ob sie wirklich physisch präsent sein müssen, ist eine andere Frage. Hier scheiden sich die Geister [9].

Was ist „done“?

Auf den Belgium Testing Days im Jahre 2012 sind Johanna Rothman und Lisa Crispin auf diese Problematik eingegan-gen. Die Frage ist, was ist „done“. Nach Johanna Rothman ist das eine Frage, die das ganze Team beantworten muss. Die Tester sollen jedoch die Diskussion auslösen und vo-rantreiben. Sie sollen auch die Diskussion mit Argumenten für mehr Qualität füttern. Rothman behauptet „you have to get the team thinking about what is done. Does it mean partially done, as in it is ready for testing or fully done, as in it is ready for release?” Ein gewisser Qualitätsstand ist er-forderlich, um ein vorübergehendes Release freizugeben. Ein ganz anderer Qualitätsstand ist erforderlich, um das Produkt endgültig fertig zu deklarieren. Zwischen diesen beiden Zuständen liegt ein weiter Weg. Die Tester müssen dafür sorgen, dass die Entwicklung weitergeht, bis der Sollzustand erreicht ist. Sie müssen den Product Owner davon überzeugen, dass dies erforderlich ist. Sonst ver-schiebt man die Probleme nur auf die Wartung, wie es frü-her bei konventionellen Entwicklungsprojekten der Fall war. Rothman schlägt deshalb vor, Kanban Fortschrittsbretter zu verwenden, um den relativen Qualitätsstand einzelner Komponenten darzustellen. Damit kann jeder sehen, wie weit die Komponenten vom gewünschten Qualitätsstand entfernt sind. Eigentlich braucht das Team zwei Fort-schrittsbretter, eins für den Funktionenstand und eins für den Qualitätsstand. Der funktionale Stand eines Software-Produktes ist leich-ter zu beurteilen, als der qualitative. Es ist sichtbar, ob eine Funktion vorhanden ist oder nicht. Der Qualitätsstand ist nicht so ohne weiteres sichtbar. Wie viele Fehler noch in der Software stecken, kann man erst wissen, wenn man alle

Umfrage39 Ausgabe 27 | Juni 2013

ASQF-Mitglieder, Partner und Kunden des iSQI waren von März bis Mai auf-gerufen, sich an der aktuellen ASQF-Umfrage 2013 zu beteiligen. Erneut sind über 100 Teilnehmer, 3/4 davon ASQF-Mitglieder, diesem Aufruf gefolgt und haben ihr Urteil über aktuelle Trends und Entwicklungen in der deutschspra-chigen IT-Landschaft und zur wirtschaftlichen Leistungsfähigkeit abgegeben.

Wie auch im Vorjahr zeigt sich die IT-Branche und die Software-Qualitätsbran-che im speziellen wieder sehr optimistisch. Über 70% empfinden die aktuelle gesamtwirtschaftliche Lage als gut bis sehr gut und halten diese auch für sta-bil, sodass über ¾ auch in 2014 mit einem gesamtwirtschaftlichen Wachstum rechnen. Nahezu identisch positiv sieht die Einschätzung bei der eigenen, ak-tuellen Lage und zukünftigen Entwicklung aus. Das wirkt sich auch auf die In-vestitionen in Weiterbildung aus: Über 2/3 behalten das hohe Niveau von 2012 bei, 10% sehen sogar zusätzliche Investitionen in Weiterbildung vor.

Dem Fachkräftemangel wollen nur 11% mit der Anwerbung ausländischer Fachkräfte entgegenwirken. 2/3 der Befragten setzen weiterhin auf die kon-sequente Aus- und Weiterbildung der vorhandenen Mitarbeiter. Fast 40% ver-stärken ihre Marketingmaßnahmen an Hochschulen. Noch scheint sich der Fachkräftemangel nicht gravierend auf die Projektlage durchgeschlagen zu haben. Lediglich ein Drittel der Befragten gaben an, überhaupt und wenn dann nur vereinzelte Projekte aufgrund fehlender Mitarbeiter absagen zu müssen. Gegenüber 2012 ist dies sogar eine Verbesserung um über 10%. Wenn ex-terne Mitarbeiter für Projekte gewonnen werden, sind meist der Preis und die Nachweisbarkeit des Fachwissens über international anerkannte Zertifikate die ausschlaggebenden Kriterien der Auswahl.

Lebenslanges Lernen, da sind sich die Teilnehmer einig, ist in der IT-Branche unerlässlich. Für die entsprechende kontinuierliche Weiterbildung werden meist Seminare mit einer Dauer von 2 bis 3 Tagen, eintägige Konferenzen oder 1-Tages-Workshops gewählt. E-Learning-Angebote werden trotz der zuneh-menden technischen Möglichkeiten von nicht einmal 1/3 der Befragten ange-nommen. Gegenüber 2012 eine Verschlechterung um ca. 4%.

Der ASQF bedankt sich bei den Teilnehmern der Umfrage. Alle Ergebnisse können grafisch aufbe-

reitet unter www.asqf.de/mitglieder-umfragen.html abgerufen werden.

ASQF-Umfrage 2013: IT-Branche bleibt zuversichtlich

0

Welche Art von Weiterbildung bevorzugen Sie?

20

40

60

80

Wor

ksho

p / T

utor

ial (

1 Ta

g)

Sem

inar

(2-3

Tag

e) Sem

inar

(übe

r 3 T

age)

E-Le

arni

ng

Fach

konf

eren

z (ü

ber 1

Tag

)

ASQ

F-Fa

chgr

uppe

ntre

ffen

/ AS

QF

Days So

nstig

es

www.dpunkt.de

Ringstraße 19 B · D-69115 Heidelberg fon: 0 62 21 / 14 83 40 · fax: 14 83 99e-mail: [email protected]

Tilo Linz

Testen in Scrum-Projekten 2013, 248 SeitenE 34,90 (D) ISBN 978-3-89864-799-1

Markus Gärtner

ATDD in der Praxis

2013, 224 SeitenE 32,90 (D)ISBN 978-3-86490-046-4

Andreas Spillner, Tilo Linz

Basiswissen Softwaretest5. Auflage

2012, 312 SeitenE 39,90 (D)ISBN 978-3-86490-024-2

Heinz Hellerer

Soft Skills für Softwaretester und Testmanager

2013, 184 SeitenE 29,90 (D)ISBN 978-3-89864-831-8

Bücher für Tester und Testmanager

Stephan Grünfelder

Software-Test für Embedded Systems

2013, 390 SeitenE 42,90 (D)ISBN 978-3-86490-048-8

NEU

www.dpunkt.de

Ringstraße 19 B · D-69115 Heidelberg fon: 0 62 21 / 14 83 40 · fax: 14 83 99e-mail: [email protected]

Tilo Linz

Testen in Scrum-Projekten 2013, 248 SeitenE 34,90 (D) ISBN 978-3-89864-799-1

Markus Gärtner

ATDD in der Praxis

2013, 224 SeitenE 32,90 (D)ISBN 978-3-86490-046-4

Andreas Spillner, Tilo Linz

Basiswissen Softwaretest5. Auflage

2012, 312 SeitenE 39,90 (D)ISBN 978-3-86490-024-2

Heinz Hellerer

Soft Skills für Softwaretester und Testmanager

2013, 184 SeitenE 29,90 (D)ISBN 978-3-89864-831-8

Bücher für Tester und Testmanager

Stephan Grünfelder

Software-Test für Embedded Systems

2013, 390 SeitenE 42,90 (D)ISBN 978-3-86490-048-8

NEU

Gastkommentar Ausgabe 27 | Juni 2013 40

ISTQB® Partner Program – Appreciating Scheme AdaptorsAlon Linetzki,

For the last ten years, the ISTQB® scheme has grown to be one of the most successful testing certification schemes in the world, with more than 70 countries adopting it, from Foundation level to Advanced level, and now anticipating Expert level in the coming years.

Many big organizations, have adopted the scheme, and are investing efforts, thought, and much of their training bud-get in the scheme worldwide. For those organizations, and with appreciation to their efforts – ISTQB® have initiated the ISTQB® Partner Program in 2012.

Partner Program in a Nutshell

The ISTQB® Partner Program is designed to recognized companies around the world that have been investing in the ISTQB® certification, sending their testers to the certifica-tion exams on the different certification scheme levels, and would like to get acknowledged for doing so. It is in the IST-QB® best interests to further develop the relationship with such companies, providing a partnership scheme to further develop the co-operation with a win-win approach.

The basis of the program is the partnership leveling sys-tem, in which companies can get acknowledged for their contribution as: Silver, Gold, Platinum or Global partners. The calculation for eligibility is based on a point’s accumu-lation mechanism.Eligibility rules and points for acquiring all levels can be found in the ISTQB® website, under Partner Program (download of the information required to become a Partner, renew partnership, etc.).

What benefits Partners get?

As ISTQB® wants to appreciate the companies adopting the ISTQB® scheme, a few benefits were defined for the Partners. Those are included in two levels: International le-vel and a local level.

On the international level the main benefits that the ISTQB® Partner Program offers are:- Permission to use the ISTQB® Partnership Program LOGO

(and other allowed marketing material) on company’s website and other marketing material - Unique recogniti-

The branding logo of the program is given to the Partner according to their level

41 Ausgabe 27 | Juni 2013 Gastkommentar

Alon is a testing expert, coach and consultant

with 18 years in testing and over 28 years in IT.

He is the author of multiple testing workshops,

and trained and coached companies in both Agile

and traditional methodologies. Alon is a popular

speaker at international testing conferences since

1995, cofounder of the Israeli Testing Certifica-

tion Board (www.itcb.org.il), and the founder and

chair of SIGiST Israel (www.sigist.org.il). He is

also a member of the marketing WG of ISTQB®

leading the Partner Program, and ITCB vice pre-

sident.

on of the investments made in the certification of testing resources;

- Specific RECOGNITION letter, indicating identity/loca-tion, validity and level;

- Listing of the partner company in ISTQB® worldwide WEBSITE;

- Access to ISTQB® ‘Conference Network’ events at spe-cial conditions (depending on local considerations);

- Ability to receive new Syllabi in Alpha Versions of ISTQB® published certifications with the opportunity to contri-bute to their review;

- Participation to the ‘ISTQB® Partner Forum’ that will be established to provide Partners with highlights on the ISTQB® Roadmap and news.

On the Local level, Boards and Exam providers that have initiated the Partner process with companies might offer them listing of the partner company on the Local Mem-ber Board or Exam Provider WEBSITE; discounts of many kinds; and other benefits that fit their local market.

Being a Partner also sends a statement to the world: ‘…we are leaders in our employee’s professional development and we care for our employees. We are taking care of their career path development using the best known scheme worldwide today’.

Achieving global recognition to our Partners is the key for us to make a stand as an organization, and to further en-hance our commitment to the market with new certifica-tion schemes. A new certification add-on to Foundation, is being planned today: ‘Agile Testing’, which involves many professionals worldwide contributing to the content. Part-ners joining, will be able to get an Alpha version of that syllabus before it hits the market.

In order to further promote the Program and to provide greater exposure to our Partners, we are collecting now together with our Platinum Partners, testimonials – suc-cess case stories – so that those Partners will present their unique implementation story, how well the ISTQB® scheme is adopted and how ISTQB® is cooperating with them. Some of those are cooperating with ISTQB® worldwide as well.

FOR FURTHER INFORMATION, TURN TO THE ISTQB® WEBSITE OR YOUR LOCAL BOARD AND EXAM PROVI-DERS.

Die Mitgliedschaft im ISTQB® Partner Programm können interessierte Unternehmen einfach und unkompliziert über das iSQI beantragen. Bei Interesse wenden Sie sich bitte an: [email protected]

Acceptance Test-Driven Development verbindet die Les-barkeit natürlichsprachlicher Spezifikationen mit der Auto-matisierbarkeit formaler Tests. Automatisiertes Testen ist inzwischen ein fester Bestandteil jedes qualitätsorientierten Entwicklungsprozesses. Entwickler erstellen automatisier-te Tests um das Erfüllen fachlicher Anforderungen für eine Anwendung kontinuierlich sicher zu stellen. Da Tests meist in einer Programmiersprache (z.B. Java) implementiert, An-forderungen aber normalerweise natürlichsprachlich erfasst werden ergibt sich zwangsläufig eine Lücke zwischen den eigentlichen Anforderungen und dem Testcode, der die An-forderungen prüft. Acceptance Test-Driven Development (ATDD) schließt diese Lücke, indem natürlichsprachliche Anforderungen automatisiert in ausführbare Testspezifikati-onen übersetzt werden. Im vorliegenden Artikel werden die grundlegenden Prinzipien von ATDD eingeführt, sowie eini-ge Werkzeuge vorgestellt, die diesen Ansatz unterstützen.

Klassische Testmethoden setzen zur Automatisierung von Tests auf Frameworks, wie z.B. JUnit [1] oder TestNG [2]. Man erzeugt zuerst eine passende Umgebung für den Test (z.B. eine initialisierte Testdatenbank), dann wird eine be-stimmte Funktionalität der Anwendung aufgerufen (z.B. die Buchung eines Flugs) und danach werden die erwarteten Nachbedingungen geprüft (z.B. ob ein gültiges Ticket aus-gestellt wurde). Dieses prinzipielle Vorgehen ist mittlerweile etabliert, dennoch stellt sich die Frage, wie man zu guten und aussagekräftigen Testfällen kommt. Um diese Frage zu beantworten muss man zunächst hin-terfragen warum wir Anwendungen testen und woher die eigentlichen Inhalte für Tests stammen: Man nutzt Tests, um sicher zu stellen, dass alle Kundenanforderungen vollstän-dig und erwartungskonform von der implementierenden Anwendung umgesetzt werden. Eine ideale Grundlage für Testfälle und Testdaten stellen daher die fachlichen Anfor-derungen des Kunden dar. Entsprechend ist es das Ziel von Acceptance Test-Driven Development die Brücke zwischen diesen fachlichen Anforderungen auf der einen Seite und der automatisierten Überprüfung der Anforderungen (wie sie ein Entwickler in einem Test realisiert) zu schlagen.Wichtigstes methodisches Prinzip von ATDD ist es, alle an der Erstellung einer Anwendung Beteiligten (Kunden, Fach-experten, Programmierer und Tester) näher zusammen zu bringen. Der Austausch über die Anforderungen soll inten-siviert und vereinfacht werden. So ist es üblich [3], dass die Beteiligten in Workshops gemeinsam einen Katalog beispielhafter Nutzungsszenarien entwickeln, welche die Anforderungen an die zu entwickelnde Anwendung illustrie-ren. Durch die systematische Diskussion dieser Szenarien für alle Anwendungsfälle, durch das Hinterfragen von Aus-

nahmefällen und durch gezieltes Alternieren der im Szenario verwendeten Eingabedaten gelangt man schnell und ein-fach zu einer umfassenden Menge von Szenarien, die alle relevanten Anwendungsfunktionen inklusive der verschie-denen Verhaltenspfade abdecken.

Zugunsten einer verständlichen und klaren Kommunikation ist natürliche Sprache das Mittel der Wahl zur Dokumenta-tion des Szenarienkatalogs. Möchte man beispielsweise die Anforderungen an ein Buchungssystem für Flüge erfassen, so könnte die Beschreibung eines Szenarios wie folgt lau-ten: „Versucht der Passagier Max Mustermann einen Platz auf dem Flug LH-1234 zu buchen, so erhält er ein gültiges Ticket“.

Nicht nur während der Anforderungsanalyse, sondern über die gesamte Projektlaufzeit hinweg bleibt der Szenarienka-talog das zentrale Medium zur interdisziplinären Kommu-nikation und Dokumentation von Anforderungen, Design-Entscheidungen und Anpassungswünschen.

Im Vergleich zu klassischen Werkzeugen zur Anforde-rungsanalyse dient der erfasste Szenarienkatalog nicht ausschließlich der Kommunikation zwischen den verschie-denen Parteien. Bei ATDD geht es darum Anforderungen so zu erfassen, dass diese später direkt für die Qualitäts-sicherung, d.h. den Test der Anwendung, genutzt werden können. Genau hier setzen ATDD Werkzeuge an. Sie erlau-ben es, die natürlichsprachlichen Szenariobeschreibungen automatisiert auszuführen und so direkt zur Qualitätssiche-rung einzusetzen. Mit Hilfe von Übersetzungsmustern wer-den einzelne Sätze der Szenarioberschreibung durch den Tester auf den ausführbaren Testcode abgebildet. Ein Über-setzungsmuster verbindet dabei die Testspezifikation mit dem zugehörigen Testcode. Beispielsweise kann folgendes Muster definiert werden, um die oben aufgeführte Testspe-zifikation ausführbar zu machen:

Muster für Szenariobeschreibung „Versucht der Passagier #passenger einen Platz auf dem Flug #flight zu buchen, so erhält er ein gültiges Ticket“.

Platzhalter im Muster für die Szenariobeschreibung wie #passenger und #flight können in konkreten Spezifikati-

Kundenanforderungen erfassen und mit den richtigen Werkzeugen in ausführbare Tests umwandeln

Im Fokus

Christian Wende, Mirko Seifert und Florian Heidenreich


onen durch beliebige Werte ersetzt werden. Dadurch wird es möglich mit einem Muster mehrere Szenariobeschrei-bungen zu übersetzen. Außerdem können so konkrete Daten aus der Szenariobeschreibung direkt in den automatisierten Test übertragen werden. So wird es möglich Testmuster in verschiedenen Szenarien und sogar unterschiedlichen Sys-temteilen oder Projekten flexibel wiederzuverwenden.

Eines der frühesten und bekanntesten ATDD Werkzeuge ist Cucumber [4]. Jede Szenariobeschreibung in Cucumber folgt einer streng vorgegebenen Struktur – der sogenannten Gherkin Syntax. Diese definiert verschiedene Schlüssel-worte wie z.B. „Given“ um Eingabedaten anzugeben oder „Then“ um Systemausgaben vorzugeben. Cucumber ist ein Kommandozeilenwerkzeug, das Testfälle aus normalen Textfiles einliest und diese dann interpretiert. Das Werkzeug Jnario [5] geht darüber hinaus und stellt einen Editor für die Entwicklungsumgebung Eclipse bereit, was die Erstellung von Szenarios enorm erleichtert. Ein weiterer Unterschied zu Cucumber ist, das es in Jnario keine Übersetzungs-muster gibt. Stattdessen wird der Testcode direkt in die Szenariobeschreibung eingebettet kann aber bei Bedarf – während der Diskussion mit einem Kunden - ausgeblendet werden. Das Werkzeug NatSpec [6] geht noch einen Schritt weiter. Es folgt der Maßgabe, dass Testfälle nicht nur natür-lichsprachlich festgehalten werden können, sondern auch so einfach und flexibel wie irgend möglich gestaltet werden sollten. Anders als bei Cucumber und Jnario müssen Sze-narien in NatSpec keiner vorgegebenen Grundstruktur fol-gen - vom Werkzeug selbst werden weder feste Schlüssel-worte noch andere Konventionen vorgegeben. Der NatSpec Editor stellt für das Schreiben von Szenarien zahlreiche fortgeschrittene Editorfunktionalitäten wie Syntaxprüfung, Code Highlighting, Code Completion, Navigationslinks oder Quickfixes zur Verfügung. NatSpec generiert automatisch Testcode, der auf bewährte Testframeworks aufsetzt (z.B. JUnit, Selenium) und auf einfache Weise weitere einbinden lässt.

FazitAcceptance Test-Driven Development beschreibt einen pragmatischen Ansatz, um die Spezifikation von Anfor-derungen verständlicher und wartbarer zu gestalten und gleichzeitig ausführbare Tests zu erhalten. Durch die Nut-zung von natürlicher Sprache können Fachexperten und Kunden direkt in die Spezifikation einbezogen werden. Neben den methodischen Aspekten ist die Auswahl eines passenden ATDD Werkzeuges maßgeblich. Sie entscheidet über Aufwand, Nutzen, die Akzeptanz und letztendlich den Erfolg von ATDD in der Praxis. Wie zahlreiche Fallstudien in [3] zeigen, gelingt es durch eine richtige Kombination von Methodik und Werkzeugen mit ATDD Kundenanforde-rungen zielgerichtet und punktgenau umzusetzen.


Die Autoren entwickeln neben NatSpec die Open-

Source-Tools EMFText, JaMoPP, JUnitLoop und

HEDL. Ihr Unternehmen, die DevBoost GmbH,

bietet Werkzeuge zur Effizienz- und Qualitätsstei-

gerung in der Softwareentwicklung und unterstützt

nationale und internationale Partner beim Einsatz

innovativer Qualitätssicherungsmaßnahmen.

L INKS & L ITER ATUR [1] http://www.junit.org [2] http://www.testng.org [3] Gojko Adzic: Bridging the Communication Gap: Specification by Example and Agile Acceptance Testing. Neuri (2009) [4] http://cukes.info [5] http://jnario.org [6] http://www.nat-spec.com


Dr. Christian Wende

Florian Heidenreich

Dr. Mirko Seifert

Tester haben das V-Modell mit seinen Teststufen verinnerli-cht. Sie reagieren verunsichert, wenn neu agil Software ent-wickelt wird. Das V-Modell sammelt am Projektbeginn alle Anforderungen – vollständig und abschliessend. Die Soft-ware wird entwickelt, durchgetestet und danach dem Kun-den übergeben. Das ist bei der agilen Softwareentwicklung anders. Das Agile Manifest [1] akzeptiert auch spätere oder sich ändernde Anforderungen nach Projektbeginn. Weiter fordert es regelmässig lauffähige Zwischenversionen. Agi-le Entwicklung stellt also bekannte Regeln in Frage und hat damit Erfolg. Jenseits anekdotischer Jubelberichte agiler Projekte und ihrer Projektleiter belegen Studien die Vorteile. So loben Vijayasarathy und Turk: „The ability to meet client needs and the delivery of quality software products on time are significant benefits of agile development …” [2].

In der heutigen agilen Entwicklungspraxis dominiert Scrum. In einer Studie aus dem Jahr 2011 bekennen sich 57% zu Scrum, 27% verwenden hauseigene Methoden – andere Methoden erreichen kaum 5% Verbreitung [3]. Daher disku-tiert dieser Artikel zwei Fragekomplexe für Scrum:- Was wird getestet? Wann?- Wie ist das Testen in der Organisation verankert?

Beim V-Modell folgt erst nach Analyse, Design und Umset-zung das Testen mit den Phasen Unit Test, Unit Integration Test, System Test, System Integration Test und User Ac-ceptance Test. Mit den Phasen strukturiert das V-Modell das Testen inhaltlich (Was wird getestet?) und temporal (wann werden die verschiedenen Tests gemacht?).

Scrum strukturiert Projekte in Sprints. Ein Sprint hat eine feste Dauer, zum Beispiel zwei oder vier Wochen. Das Ent-wicklungsteam wählt am Anfang eines Sprints die User Sto-ries (Aufgabenpakete) aus, die es in dem Sprint umsetzt. Am Ende des Sprints sind diese User Stories nicht nur im-plementiert, sondern vollständig getestet und auslieferbe-reit. Scrum kennt keine nachgelagerten Testphasen mehr. Das erfordert eine Neuinterpretation der Testphasen. Aus

Testphasen werden Testaspekte. Scrum braucht alle Testa-spekte des V-Modells wie Unit Tests oder System Tests. Neu ist einzig, dass die feste Reihenfolge – erst Unit Test, dann Unit-Integration-Test etc. – entfällt. Das illustriert Ab-bildung 1. Die Farbintensität veranschaulicht den Bedarf an Testaspekten in der jeweiligen Phase (V-Modell) oder in Sprints (Scrum). Beim V-Modell gibt es die bekannte Ord-nung, bei Scrum ist die Verteilung dynamischer. Ein Sprint beinhaltet meist überlappend verschiedene Testaspekte, wobei es auch einzelne reine Integrations- oder Testsprints geben kann.

Welche Testaspekte wichtig sind hängt vom Unternehmen ab. Große IT-Firmen wie Microsoft und Google entwickeln intern Software mit eigenen Entwicklern und Testern. Ihre Bücher [4][5] prägen das Testing. Für sie sind alle Testa-spekte wichtig. Doch viele Tester in Deutschland, Österreich und der Schweiz arbeiten in einem anderen Umfeld. Kun-denunternehmen und ihre IT-Abteilungen (Kunden-IT) lagern Entwicklungsprojekte oft aus oder kaufen Standardsoftware ein. Standardsoftware wird „nur“ installiert und konfiguriert. Softwarelieferanten und Kunden-IT haben folglich andere Bedürfnisse für Tests (Abbildung 2). Der Softwarelieferant übernimmt Unit Tests, Unit-Integration Tests und System Tests und steigert so die Produktqualität. Er managet je nach Projektgrösse zusätzlich Haftungs- und Reputations-risiken, beispielsweise durch Reviews.

Die Kunden-IT hat beim Testen einen anderen Fokus. Sie muss verhindern, dass eine neue Software die Bank oder Produktion lahmlegt. Ihr Fokus sind System Integration Tests und User Acceptance Tests. System Tests werden nur bei stark konfigurierbaren Systemen wie ERP-Syste-men notwendig. Ziel ist nicht, die Softwarequalität zu ver-bessern. Das ist die Aufgabe des Softwarelieferanten. Ziel ist eine Abnahme oder Rückweisung einer konkreten Soft-wareinstallation.Wie wirkt sich die neue Welt des Testens auf die Testorga-nisation in Firmen aus? Softwarelieferant und Kunden-IT

SCRUM: Untergang der Test Center?

Im Fokus

Klaus Haller


Inhaltliche Strukturierung Temporale Ordnung

Typ Validiert… / Testaspekt V-Modell Scrum

Unit Test Module, Klassen etc. 1

Unit Integration Tests Zusammenspiel von Modulen etc. 2

System Tests Ganzes System 3

System Integration Tests System mit Umsystemen 4

User Acceptance Tests Anforderungen 5

Abbildung 1: Testziele und Strukturierung (verschieden tiefe Blauschattierungen symbolisieren, wie intensiv getestet wird.)

haben, wie oben beschrieben, andere Bedürfnisse beim Te-sten. Es bieten sich unterschiedliche Organisationsformen an. Bei einer Kunden-IT gibt es keinen Änderungsbedarf. Sie muss entscheiden, ob die Software produktiv eingesetzt werden kann. Ein unabhängiges Test Center hilft. Ein Softwarelieferant hat dagegen kaum Freude, wenn ein Test Center erst am Projektende kurz vor Auslieferung sagt „Zu viele Fehler - „zurück zum Start!“. Bei Softwareliefe-ranten geht es um „move quality upstream“ [4]. Dafür werden die Tester in Scrum-Teams integriert und eingebettet. Orga-nisatorisch können die Tester aus einem zentralen Tester-Pool stammen oder fixen Produkt- oder Entwicklungsteams zugeordnet werden. Solche Tester sind natürlich weniger unabhängig als bisher. Ein kleines Quality Assurance-Team sollte daher ergänzend Prozesse und Testqualität überwa-chen. So verhindern Softwarelieferanten, dass Projektteams unter grossem Druck Software ausliefern, die die Reputation ruiniert oder Schadenersatzansprüche verursacht. In grossen Non-IT-Unternehmen wie Banken ist es kompli-zierter. Sie entwickeln intern Software. Dafür benötigen sie die eingebetteten Tester für Scrum-Projekte plus die Quality Assurance-Funktion zur Begleitung. Gleichzeitig ist eine Ja/Nein-Entscheidung nicht nur bei intern entwickelter, son-dern auch bei extern gekaufter Software notwendig. Von der Organisation her bietet sich ein klassisches Test Center an, das neu die Quality Assurance-Funktion für die Begleitung der agilen Entwicklung beinhaltet. Die Tester für Scrum-Pro-jekte können als Pool dem Test Center angegliedert werden oder aber den verschiedenen Entwicklungsprojekten und Produkten.

Ist Scrum der Untergang der Test Center? Wenn Test Cen-ter die Produktion schützen wie bei einer Kunden, dann verändert Scrum bei ihnen nichts. Ist der Fokus von Test Centern auf Software-Entwicklung, gibt eine Reorganisati-on nach dem Motto „form follows function“ Sinn. Doch egal ob Test Center reorganisiert oder aufgelöst werden oder unverändert bleiben - auch mit Scrum benötigt Software-entwicklung kompetente Tester. Scrum mag bessere Qua-lität für weniger Geld liefern. Der Ausspruch von Selfridge gilt trotzdem: „Qualität bleibt bestehen, wenn der Preis längst vergessen ist.“

Ziel Organisationsform

Improve Quality Eingebettete Tester in Scrum-Teams

Manage Risks QA-Organisation (Prozess und/oder Testing)

Protect Operations Unabhängiges Test Center

Abbildung 3: Ziele und passende Organisationsformen


Klaus Haller arbeit als Expert im Test-Consulting

bei Swisscom IT Services in Zürich. Seine Schwer-

punkte sind (Test-)Organisation und Prozesse,

Testdatenmanagement, Compliance Testing und

IT Risk/DLP.

L ITER ATURVER ZEICHNIS [1] Agile Manifesto, http://agilemanifesto.org/, letzter Abruf 31.3.2013[2] L. R. Vijayasarathy, D. Turk: Agile Software Development: A Survey of early Adopters, Journal of Information Technology Management Volume XIX, Number 2, 2008 [3] Haberl, P., et al.: Umfrage 2011 - Softwaretest in der Praxis, dpunkt.Verlag, Heidelberg, 2012 [4] A. Page, K. Johnston, Bj Rollison: How We Test Software at Microsoft, Microsoft Press, Redmond, WA, 2009 [5] J. Whittaker, J. Arbon, J. Carollo: How Google Tests Software, Addison-Wesley, Westford, MA, 2012


Im Fokus

Testen mobiler Apps: ein Paradebeispiel für agiles VorgehenSven Euteneuer

Mobile Apps verändern

In der letzten Zeit ist ein Paradigmenwechsel am IT-Markt zu beobachten. Aktuelle Studien zeigen, dass eine Ab-kehr vom PC als „geschäftlichem Alleskönner“ hin zu einer stärkeren Nutzung mobiler Geräte (vgl. (IDC, Inc., 2013)) erfolgt. Mobile Geräte und Anwendungen durch-dringen den privaten und beruflichen Alltag und werden zum Innovationstreiber der Informations- und Kommuni-kationstechnologie (IKT). Eine Folge der stärkeren Ver-breitung und Nutzung der Informationstechnologie ist unter anderem eine sich ändernde Nomenklatur. So wird aus Software eine App, und deren Verteilung erfolgt nicht mehr über DVDs oder FTP-Server, sondern über App-Stores. Dabei stellt Mobile Computing in Bezug auf eine Vielzahl von Aspekten eine veritable Revolution dar: Nicht nur verändern mobile, smarte Geräte die Art und Weise geschäftlichen wie privaten Lebens, sie erfordern glei-chermaßen eine Anpassung der Art und Weise, wie Soft-ware für sie entwickelt wird. Indiz hierfür ist, dass mobile Anwendungen nicht als Anwendungen, Programme oder Software bezeichnet werden, sondern als Apps – ein Be-griff, der bereits darauf hindeutet, dass sich mobile Soft-ware von bekannten Pfaden entfernt.Die geänderten Rahmenbedingungen stellen auch die Softwareentwicklung und damit die Qualitätssicherung vor neue Herausforderungen. Konkret ergibt sich eine Reihe von Herausforderungen, die mobiles Entwickeln im Allgemeinen und mobiles Testen im Besonderen zu Anpassungen zwingen. Dies sind zunächst technische Spezifika mobiler Geräte, wie zum Beispiel begrenzte Re-chen- oder Speicherkapazität, Unterschiede in der Be-

nutzerschnittstelle oder Einflussfaktoren wie wechseln-de Netzanbindung oder Unterbrechungen durch Anrufe, Erinnerungen oder andere Apps. Zusätzlich erfordert die Heterogenität des mobilen Marktes die Anpassung und Erweiterung des Prinzips des risikobasierten Tests. Um die endlichen Testressourcen möglichst optimal zu ver-teilen, genügt es nun nicht mehr, nur Testobjekte anhand ihres Risikos zu klassifizieren und mehr oder weniger gründlich zu testen. So ergibt sich für mobile Apps häu-fig das Problem, dass mit der Anzahl der Vertriebskanäle (z.B. PC vs. Web vs. Mobile vs. TV), Plattformen (z.B. An-droid, iOS, BlackBerry, Windows Phone) und konkreter Geräte die Anzahl möglicher Produktvarianten und damit auch die Anzahl denkbarer Testfälle sowie die Anzahl der Testumgebungen stark steigt (vgl. (Euteneuer, 2012)).Darüber hinaus unterscheidet sich Softwareentwicklung für mobile Geräte aber noch in einem viel wesentlicheren Aspekt von traditioneller IT: Die Innovationszyklen sind noch einmal erheblich kürzer, die Anforderungen wech-seln mit noch größerer Volatilität und die Hürden für Mit-bewerber mit einer guten Idee sind noch niedriger. Um in diesem Umfeld erfolgreich zu sein, ist also unter anderem eine sehr kurze „Time to Market“ mit guter Qualität erfor-derlich.

Agilität als Problemlöser

In diesem Kontext erscheinen traditionelle, phasengetrie-bene Vorgehensmodelle (vgl. Abbildung 1) als Anachronis-mus, der mit seinen Formalismen, früh festgeschriebenen Anforderungen und erst am Projektende verfügbaren Produkten ungeeignet ist, erfolgreich Produkte zu entwi-


Abbildung 1: Phasengetriebenes Vorgehensmodell

INITIALISIERUNG

ANFORDERUNG

DESIGN

UMSETZUNG

TEST

LAUNCH


ckeln. Gleichzeitig klingen die oben beschriebenen He-rausforderungen, als ob sie fast wörtlich aus dem Agilen Manifest entnommen wurden. Dem Dokument also, das die Werte und Prinzipien der agilen Softwareentwicklung zusammenfasst. Insbesondere fallen die Werte zu funkti-onierender Software, Zusammenarbeit mit dem Kunden und dem Reagieren auf Veränderungen ins Auge (vgl. (Agile.org, 2001)).Agilität erscheint also in der Softwareentwicklung für mo-bile Plattformen noch mehr als die magische Lösung aller Probleme, als es in klassischen IT-Projekten ohnehin der Fall ist. Neben aller Euphorie löst die Verwendung spezi-fischer agiler Methoden aber in der Tat typische Probleme in der App-Entwicklung (vgl. auch (Spataru, 2010)).

Auf wechselnde Anforderungen reagieren

Im Umfeld mobiler Apps existieren gleich mehrere Trei-ber für sich verändernde Anforderungen. Zum einen zielt die Natur einer App häufig auf Bedarfe ab, die entweder zeitlich begrenzt sind (z.B. Apps mit Bezug auf Großer-eignisse oder Werbeaktionen) oder die sich im Laufe der Zeit stark verändern können. Andererseits werden die Anforderungen an mobile Apps durch das dynamische Technologieumfeld stärker als in anderen Bereichen auch durch die Evolution der mo-bilen Plattformen mitbestimmt. Anders als auf dem PC erscheinen neue Geräte – und damit Hardware-Innovati-onen – im Rhythmus eines Quartals. Dazu werden mobile Plattformen wie Android, iOS und Windows Phone mehr-mals im Jahr aktualisiert und erweitert (vgl. Abbildung 2 für Android).

Abbildung 2: Android Releasezyklen, Quelle: (Wikipedia, 2013)

Einer der Vorteile der Anwendung agiler Methoden liegt in der schnellen Reaktion auf sich ändernde Anforderun-gen. Der Einsatz iterativ-inkrementeller Vorgehensmodel-le erlaubt es, Anforderungen in regelmäßigen Zyklen zu erheben, zu priorisieren und die zu implementierenden Anforderungen auszuwählen (vgl. Abbildung 3).


Sven Euteneuer hat Informatik studiert und ist bei

der SQS AG als Senior Research Manager tätig.

Dort ist er verantwortlich für das Innovieren des

Serviceportfolios in den Bereichen Mobile Compu-

ting und IT Security.

Im Fokus

allein der Product Owner und das Entwicklungsteam für die Sicherung der gesamten Produktqualität verantwortlich. In der Regel beherrschen aber weder Product Owner noch Entwickler den systematischen Testansatz, noch kennen sie die Anwendung verschiedener Teststufen.

Gleichzeitig nimmt die Zahl der relevanten Qualitätsei-genschaften zu (z.B. für Sicherheit, Zuverlässigkeit oder Gebrauchstauglichkeit) und die Komplexität der benöti-gten Infrastruktur erhöht sich. Es muss also eine Vielzahl – möglicherweise neuer – Testtechniken systematisch ge-plant und durchgeführt werden.Daher ist die Etablierung von Sprint-Testern unabding-bar. Sie müssen die marktüblichen Teststandards, wie sie z.B. im ISTQB festgeschrieben sind, sicher beherr-schen. Darüber hinaus müssen Tester wie Entwickler im Vorfeld den agilen Methodenkoffer vermittelt bekommen. Wünschenswert ist ebenfalls eine technische Affinität und Kenntnisse zu Entwicklungstechniken bis hin zur Automa-tisierung von Testfällen, um sehr eng mit den Entwicklern kooperieren zu können.

Mehr Integration in der Mobile App Entwicklung

Apps stellen zwar häufig eine eng begrenzte Funktiona-lität zur Verfügung, sind aber immer häufiger Teil einer komplexen Architektur, welche diverse Backendsysteme, Server, Web Services oder Cloud-Dienste nutzt und or-chestriert.Diese Integration erzwingt planerische Weitsicht, die ins-besondere die Testplanung und das Release-Manage-ment betrifft. Abhängigkeiten müssen bei der Planung genauso berücksichtigt werden wie andere Vorgehens-modelle. So werden Legacy-Dienste häufig eben nicht agil weiterentwickelt.Gerade weil eine vielgestaltige Integration in SCRUM zu-nächst nicht vorgesehen ist, muss die Sprint-Planung um die o.g. Aspekte erweitert werden. Ein kompletter Ent-wicklungs-Lifecycle kann sich dann über ein bis zwei Jah-re mit einer Reihe von Release-Zyklen hinziehen. Jedes


Dies erlaubt es, auch auf dynamische Änderungen schnell und gleichzeitig ohne den in phasengetriebenen Model-len einhergehenden Wertverlust großer Arbeitspakete zu reagieren. Entsprechend sind SCRUM und verwandte Vorgehensmodelle beliebte Prozesse bei der Organisati-on der Entwicklung mobiler Apps.

Überschaubarkeit von Aktion und Reaktion

Außerdem haben iterative Vorgehensmodelle den Vorteil, dass komplexe Aufgabenstellungen notwendigerweise in überschaubare Implementierungs-Teilpakete herunterge-brochen werden müssen. Dies schafft mehr Transparenz. Der Status des Projektes lässt sich jederzeit kleingranular berichten. Trends und Fehlentwicklungen sind schneller ersichtlich und steuerbar. Der kurze Zyklus zwischen Pla-nen, Entwickeln, Testen und Reviewen erzeugt kontinuier-lich Verbesserungen am Produkt und am Prozess, da sich das Entwicklungsteam iterativ immer weiter optimierten Lösungen annähert.Der wirtschaftliche Nutzen generiert sich aus dem ge-ringeren Aufwand für Fehler- & CR-Handling sowie aus verkürzten Release-Zyklen. Das agile Vorgehen vermei-det langwierige Abstimmungs- und Freigabeprozesse in frühen Projektphasen. Dazu kommt, dass Kosten gene-rierende Fehler in Anforderungen oder im Design deutlich früher erkannt werden.

Notwendige Anpassungen

Auch wenn viele agile Methoden scheinbar perfekt in das Umfeld mobiler App-Entwicklung passen, empfehlen sich doch Anpassungen in drei Bereichen, um Spezifika der App-Entwicklung berücksichtigen zu können. Diese sol-len im Folgenden erläutert werden:

Mehr Test im agilen Mobile App Entwicklungsteam

Die Rolle des Testers gibt es beispielsweise nach der „rei-nen“ SCRUM-Methodik gar nicht. Im SCRUM-Modus sind

INITIALISIERUNG

Abbildung 3: Agiles Vorgehen

ANFORDERUNG ANFORDERUNG

ANFORDERUNG ANFORDERUNG

DESIG

N

DESIG

N

TEST

TEST

LAUNCH LAUNCH


LITER ATUR Agile.org. (2001). Manifest für Agile Softwareentwicklung. Von http://agilemanifesto.org/iso/de/ abgerufen Euteneuer, S. (19. 11 2012). SPL Testing for Efficient Mobile Testing. Von The 23rd CREST Open Workshop - Change Impact Analysis and Testing of Software Product Lines: http://crest.cs.ucl.ac.uk/cow/23/ abgerufen IDC, Inc. (03. April 2013). PC Shipments Post the Steepest Decline Ever in a Single Quarter, According to IDC . Abgerufen am 03. April 2013 von http://www.idc.com/getdoc.jsp?containerId=prUS24065413#.UWZrp1dtzpj Wikipedia. (2013). Android Release Cycles. Von http://en.wikipedia.org/wiki/Android_version_history abgerufen


sepp.med gmbh Fon +49 (0) 91 95-931-0Fax +49 (0) 91 95-931-300

Gewerbering 9D-91341 Röttenbach

[email protected]

Potsdamer Platz 11D-10785 Berlin

Fon +49 (0) 30 2589-5042Fax +49 (0) 91 95-931-300

Über Modellbasiertes Testen (MBT) wird viel geredet. Der CMBT stellt weltweit erstmals das standardisierte und fi rmenunabhängige Zertifi zierungsschema der iSQI Special Interest Group MBT für Sie zur Verfügung.

Termine:

Weitere Termine auf Anfrage.

CMBT - iSQI® Certifi ed Model Based Tester

Buchen Sie bis zum 8.7.2013

und sparen Sie 20%!

DoMoDoDi

20.06.2013 - 22.07.2013 -08.08.2013 - 10.09.2013 -

FrDiFrMi

21.06.2013 23.07.201309.08.201311.09.2013

NürnbergNürnbergPotsdamRöttenbach

Mehr Informationen:www.seppmed.de/dienstleistungen/sepptrain-schulungen/isqir-cmbt.html

Release setzt sich dann wiederum aus einer Anzahl von Sprints und einer komplexen Integration (oder Release-Test) zusammen, d.h. dass nicht nach jedem Sprint das Ergebnis zwingend live geht.

Mehr Tooleinsatz der agilen Entwicklung für Mobile Apps

Aufgrund der beschriebenen Vielzahl an möglichen Ziel-kanälen, -plattformen, und -geräten ergibt sich für den Tester eine gefährliche kombinatorische Explosion be-züglich Testfällen und Testumgebungen. Neben metho-dischen Erweiterungen des risikobasierten Testens bietet der Tooleinsatz die Möglichkeit, möglichst viele relevante Plattformen ausreichend mit Tests abzudecken. Dies wi-derspricht aber zunächst dem agilen Paradigma. In der Praxis zeigt sich, dass sich ohne Werkzeugunterstützung im Bereich der Automatisierung der Testausführung sowie im Testumgebungsmanagement deutliche Effizienzver-luste ergeben. Gerade in einem so jungen Markt wie den mobilen Apps sollten diese Tools jedoch sorgfältig ausge-wählt werden, da es große Unterschiede in Bezug auf As-pekte wie Funktionalität oder Plattformunterstützung gibt.

Fazit

Agilität ist das präferierte Vorgehensmodell für die App-Entwicklung – doch erfordert die Umsetzung eine mehr-schichtige Erweiterung des agilen Methodenkoffers hinsichtlich der speziellen mobilen Herausforderungen. Dies betrifft die stärkere Berücksichtigung von Testen und Testern als Rolle, der bewussten Integration mit den Entwicklungsvorgehen von Umsystemen und dem ver-stärkten Tooleinsatz als Mittel zur Verbesserung von Test-effektivität und -effizienz auf vielfältigen Plattformen und Geräten.

Anzeige

sepp.med gmbh Fon +49 (0) 91 95-931-0Fax +49 (0) 91 95-931-300

Gewerbering 9D-91341 Röttenbach

[email protected]

Potsdamer Platz 11D-10785 Berlin

Fon +49 (0) 30 2589-5042Fax +49 (0) 91 95-931-300

Über Modellbasiertes Testen (MBT) wird viel geredet. Der CMBT stellt weltweit erstmals das standardisierte und fi rmenunabhängige Zertifi zierungsschema der iSQI Special Interest Group MBT für Sie zur Verfügung.

Termine:

Weitere Termine auf Anfrage.

CMBT - iSQI® Certifi ed Model Based Tester

Buchen Sie bis zum 8.7.2013

und sparen Sie 20%!

DoMoDoDi

20.06.2013 - 22.07.2013 -08.08.2013 - 10.09.2013 -

FrDiFrMi

21.06.2013 23.07.201309.08.201311.09.2013

NürnbergNürnbergPotsdamRöttenbach

Mehr Informationen:www.seppmed.de/dienstleistungen/sepptrain-schulungen/isqir-cmbt.html

Mitglieder Ausgabe 27 | Juni 2013 50

Auf seiner ordentlichen Mitgliederversammlung am 07. Mai 2013 in Erlangen hat der ASQF ein neues Präsidium ge-wählt. Mit Rudolf van Megen, Gründer und ehemaliger CEO der SQS Software Quality Systems AG, wurde einer der prägendsten Personen des Marktes für Software Testen und Qualitätsmanagement der vergangenen 30 Jahre als neuer Präsident an die Spitze des ASQF berufen. Norbert Bochynek, Geschäftsführer und Gesellschafter der tolina Software GmbH und deren Tochtergesellschaften, wurde zum neuen Vizepräsidenten gewählt. Ebenfalls neu im Prä-sidium des größten Expertennetzwerks für Software-Quali-tät im deutschsprachigen Raum ist Prof. Dr. Joachim Horn-egger, Friedrich-Alexander-Universität Erlangen-Nürnberg. In Ihren Ämtern bestätigt wurden als Vizepräsidentin Frau Prof. Dr. Ina Schieferdecker, Fraunhofer Institut FOKUS, und als Mitglieder des Präsidiums Herr José Díaz, Díaz & Hilterscheid Unternehmensberatung, Norbert Kastner, sepp.med gmbh, und Ludger Meyer, Siemens AG.

Mit dem neu gestalteten Präsidium geht der ASQF auch den nächsten Schritt in seiner Entwicklung. „Aufbauend auf dem geschaffenen Fundament möchte ich sicherstel-len, dass die gesetzten Ziele und die Position des Vereins als Sprachrohr der Wirtschaft in allen Belangen von Soft-ware-Qualität nachhaltig weiterentwickelt werden. Dies betrifft Aspekte der Fortbildung genauso, wie die Verbes-serung der Unart, dass immer der Billigste gewinnen muss, egal ob es dann nachher ein Endergebnis gibt oder das Projekt eingestampft wird. Denn Qualität hat ihren Preis!“ so Rudolf van Megen zu seinen Zielen als neuer Präsident des ASQF e.V.

Auf zur nächsten Etappe: Neues ASQF-Präsidium gewählt.

Das neue Präsidium mit der ASQF-Geschäftsführung (vlnr.): Stephan Goe-

ricke, Joachim Hornegger, Rudolf van Megen, Norbert Kastner, Norbert

Bochynek und Felix Winter.

Rudolf van Megen (r.) übernimmt den ASQF aus den Händen

von Thomas Thurner (l.).

Für ASQF-Hauptgeschäftsführer Stephan Goericke steht die Übergabe des Staffelstabs an der Spitze des Fachver-bands im Zeichen des Fortschritts: „Der Wechsel in den Spitzenpositionen eines Verbandes ist auch immer mit dem Einläuten einer neuen Etappe verbunden. Zusammen mit Thomas Thurner und Karl-Heinz John haben wir ein hervorragendes Fundament für den ASQF und das iSQI geschaffen, auf dem wir nun sicher bauen können. Rudolf van Megen hat schon 2005 bei der Gründung des iSQI an der Vision des iSQI und ASQF mitgearbeitet. Dieser sind wir nun schon sehr nahe. Ich freue mich daher, zusammen mit Rudolf van Megen und dem neuen Präsidium unsere Vision weiterzuentwickeln und mit Leben zu füllen.“

Der ASQF bedankt sich bei Thomas Thurner, ASQF-Präsi-dent von 2007 bis 2013, und Karl-Heinz John, ASQF-Vize-präsident von 2007 bis 2013. Beide scheiden auf eigenen Wunsch nach insgesamt achtjähriger Amtszeit in verschie-denen Funktionen und großem Einsatz für den ASQF aus dem Präsidium aus.

Auf der Mitgliederversammlung wurde auch über eine neu-erliche Satzungsänderung entschieden. Einstimmig nah-men die anwesenden Mitglieder den Vorschlag zur Sat-zungsänderung an. Neben Studenten und Auszubildenden gelten die ermäßigten Beitragssätze nun auch für Personen im Ruhestand. Arbeitslose ASQF-Mitglieder können über die neue Regelung eine Beitragsbefreiung beantragen.

www.asqf.de

Quiz

„Get certified“ war die Lösung des letzten Sudokus und alle fünf Gewinner dürfen sich ab heute „Sudoku certified“ fühlen und können weitere knifflige Probleme mit Gelassenheit angehen. Mit dem Buch „Tes-ten in Scrum-Projekten“, erschienen im dpunkt.verlag, können Sie Ihre Fähigkeiten in der agilen Welt sogar noch weiter ausbauen.

DIE GEWINNER SIND: DAMIAN NOWROTH, Bad Homburg // DEBORAH HÖVERMANN, ITGAIN GMBH, Hannover // ARMIN RUHLAND-KÖNIG, ING-DIBA AG, Frankfurt am Main // KLAUS BRÜGGEMANN, DER QUALITÄTSBERATER, Niddatal // BORIS WRUBEL, Wien

Gewinner SQ-Magazin Nr. 26Ausgabe 26 | März 2013

Arbeitskreis Software-Qualität

und -Fortbildung e.V.

Arbeitskreis Software-Qualität

und -Fortbildung e.V.

ADVANCED

TESTING Testen für Profis

Im Gespräch

Yaron Tsubery

Präsident des ISTQBSeite 8

Statement Rudolf van Megen -

„Qualität hat ihren Preis“

Seite 40

Blickwinkel

ISTQB® New 2012

Advanced Level Syllabus

im DetailSeite 14

In vielen Projekten findet Dokumentation in einer ihrer beiden Extremformen statt: Entweder wird fast überhaupt nichts dokumentiert, und wich-tiges Wissen geht verloren, oder es existiert ein Übermaß an teils schlecht strukturierten Doku-menten, die für die Weitergabe von Wissen denk-bar ungeeignet sind.

Gerade von den agilen Verfahren zur Softwareentwicklung kön-nen wir lernen, wie eine bedarfsgerechte „Dokumentation in agi-len Projekten“ aussehen kann. So ist es sinnvoll, nur Dokumente zu erstellen, die einen klar erkennbaren Nutzen haben. Darüber hinaus ist es wichtig, Dokumentation auch als eine Form des Wissensaustauschs im Team zu begreifen. Schließlich hängt die Verwendbarkeit der Dokumentation auch von ihrer Gestaltung ab. Es werden Lösungsmuster vorgestellt und Hinweise gegeben, wie eine gute Dokumentation von Softwareprojekten aussehen kann. Der Aufbau des Buches orientiert sich weitgehend am iterativen Vorgehen in agilen Projekten und spiegelt den Lebenszyklus von Dokumenten in einem agilen Kontext wider.

Wenn Sie eines von fünf Büchern gewinnen wollen, dann schicken Sie das richtige Lösungswort bis 05.08.2013 an [email protected].

Sudoku

8 4 7 1 9 5

9 2 5 7

5 2 9

7 5

1 8 2

8 1 4 9

7 9 8 2 3 1

Buchstaben: 1=L, 2=S, 3=I, 4=A, 5=E, 6=N, 7=G, 8=O, 9=T

LÖSUNGSWORT

Der Automation Day am 10. Juli 2013 widmet sich in diesem Jahr dem Thema „Web-Technologien in der Automatisierung“. Die rapide Verbreitung einer völlig neuen Generation von Computern („Tablets“, „iPads“) erzeugt den Wunsch, diese auch in der Automatisierung zu verwenden. Mobile Geräte mit bisher nicht ge-nutzten Betriebssystemen, kleine Bildschirme, Touch-Bedienung – wie kann das für die Automatisierung effizient genutzt werden? Wie das geht, zeigt infoteam in einem Vortrag: „Von 0 auf 100 für alle Endgeräte: Web-Technologie aus dem Baukasten“. Sie kommen doch auch? http://automationday.de

Agil macht auch mobil: von 0 auf 100 für alle Endgeräte!

empfiehlt „dilbert“zur leichteren Alltagsbewältigung

*Der Rechtsweg ist wie immer ausgeschlossen. Die Mitarbeiter der iSQI GmbH und des ASQF e.V. sowie sämtliche am Gewinnspiel beteiligten Personen sind von der Teilnahme aus-geschlossen. Teilnehmer erklären sich mit der Veröffentlichung Ihres Namens in der Folgeausgabe einverstanden.


Fachgruppentermine: Juni - Juli 2013JUNI 2013

KW Mo Di Mi Do Fr Sa So

22 1 2

23 3 4 5 6 7 8 9

24 10 11 12 13 14 15 16

25 17 18 19 20 21 22 23

26 24 25 26 27 28 29 30

JULI 2013

KW Mo Di Mi Do Fr Sa So

27 1 2 3 4 5 6 7

28 8 9 10 11 12 13 14

29 15 16 17 18 19 20 21

30 22 23 24 25 26 27 28

31 29 30 31

JUN

I

04.06.2013 FG Software-Test, Sachsen, DresdenOrganisation von Penetrationstest inkl. Live-Hacking: Gefahren, Bedrohungen und wie man sich schützen kann.

Thomas Haase

04.06.2013 FG Automotive NRW, KölnWhat is the impact? Adding Traceability to your development tool chain

Mark Brörkens

04.06.2013 FG Software-Test, MünchenISTQB® Certified Tester: Der neue Advanced Level Lehrplan 2012 - Update oder Upgrade?

Dr. Uwe Hehn

06.06.2013 FG Requirements Engineering Franken„RE & Scrum - Product Backlog - System-Spezifikation“

Marta Bednarczyk

11.06.2013: FG Software-Test, FrankenKommunikation im Projekt - Teamentwicklung und wirksame Kommunikation

Ewa Sadowicz und Heribert Jenus

11.06.2013 FG Software-Test, Österreich, WienSoftware-Test für Embedded Systems: Ein Einblick in nicht-alltägliche Testtechniken

Dr. Stephan Grünfelder

13.06.2013 FG Automatisierung, FrankenVon der Idee zum Interaktionsdesign

Dr. Markus Schleicher

13.06.2013 FG Software-Test, BerlinRisikobasierter IT-Sicherheitstests in Forschung und Standardisierung

Jürgen Großmann

19.06.2013 7. RHEIN-MAIN TESTING DAYThema: Open Space - „Aus der Praxis für die Praxis“

Ganztagesveranstaltung

20.06.2013 4. MEDICAL DEVICE DAY FrankenThema: Klinische Bewertungen und Validierung von Software


20.06.2013 FG Software-Test, BWVorankündigung

24.06.2013 FG Projektmanagement, FrankenBalanced Scorecard als Instrument zur Analyse der Softskills im PM

Sebastian Krieger

JUL

I

10.07.2013 22. Automation Day, FrankenThema: Web-Technologien in der Automatisierung


16.07.2013 FG Requirements Engineering FrankenVorankündigung

17.07.2013 FG Requirements Engineering Bayern-Süd, MünchenVorankündigung 23.07.2013 FG Software-Test, FrankenLead+Relax - Wie wir uns durch einfache, aber gezielte Übungen in unserer Kommunikation

Ewa Sadowicz und Heribert Jenus

ISTQB® Certif ied TesterÜber 265.000 Certi�ed Tester weltweit. Über 28.000 davon in Deutschland. Wann gehören Sie dazu? Qualität entscheidet zunehmend über den Erfolg von IT. Professionelles, modernes Testen ist hierbei eine Conditio sine qua non!Vor 20 Jahren wurde Testen noch als die destruktive Technik am Ende der Software-Entwicklung verstanden, ein Programm zum Fehlverhalten zu zwingen. Doch die IT-Industrie lernte, und Testen rückte von der Rolle der nachgelagerten Feststellung des Todes einer Applikation in die Rolle der begleitenden, konstruktiven Heilung. Die Schulung zum ISTQB® Certi�ed Tester trainiert diesen ganzheitlichen, modernen Testansatz seit über 10 Jahren: Mit seinen drei Reifegraden Foundation, Advanced und Expert wird es den unterschiedlichen Ansprüchen an erfolgreiche Tester gerecht. Doch auch hier wird weiter gelernt: So gibt es in 2013 einen überarbeiteten Advanced-Level. Viele Inhalte wurden modernisiert und aktualisiert und alle Begri�ichkeiten wurden konsistent zum neuen ISTQB®-Glossar gewählt. Lernen aus einem Guß! Des weiteren gibt es im Advanced-Level kaum mehr Überschneidungen zum Foundation-Level: Die Schulungen sind dadurch sehr viel fokussierter und bieten noch mehr Raum für praktische Übungen. Einige Kurse konnten daher nun auch zeitlich verkürzt werden, was den knappen Weiterbildungsetats entgegen kommt. Und was für den Hochbildungsstandort Deutschland besonders wichtig ist: Die ISTQB®-Schulungen unterstützen nun explizite Karrierepfade, die dem lernenden Tester vom Foundation-Level, über den Advanced-Level zum Expert-Level als Orientierungsbojen begleiten können. Wann rudern SIE wieder?

Der ISTQB® Certi�ed Tester ermöglicht Tester-Karrieren - die Schulungen bieten damit erstmals ein internationales und branchenübergreifendes Berufspro�l für Software-Tester, jeweils mit individuellen Schwerpunkten.

Der ISTQB® Certi�ed Tester macht die Arbeit leichter - Tester sprechen nun die gleiche Fachsprache, benutzen die gleichen Begri�e, sind up-to-date.

Der ISTQB® Certi�ed Tester hilft, Kosten zu senken - durch geschulte Tester werden Fehler bereits in frühen Phasen der SW-Entwicklung systematisch entdeckt. Und hierbei helfen gerade im Advanced-Level gute Test-Manager, Test-Analysten und gute technische Tester.

Anmelden ist einfach.Ein akkreditierter Trainingsanbieter ist sicher auch in Ihrer Nähe:

Alle Trainingsprovider siehe www.german-testing-board.info

GTB Premium PartnerALTRAN GmbH & Co. KG

berner & mattner Systemtechnik GmbH

C1 SetCon GmbH

EXCO GmbH

imbus AG

ISARTALakademie GmbH

Knowledge Department GmbH

Logica Deutschland GmbH & Co. KG

Loyal Team GmbH

Method Park Software AG

Philotech GmbH

sepp.med gmbh

Software Quality Lab GmbH

Sogeti Deutschland GmbH

SQS AG

T-Systems

Autorisierte Zerti�zierungsstellenCert-IT GmbH

gasq Service GmbH

iSQI GmbH

„Lernen ist wie Rudern gegen den Strom. Sobald man aufhört, treibt man zurück.“

Anzeige_OBJEKTspektrum_210x148mm_RZ_2013_02_14.pdf 1 14.02.13 10:39

ISTQB® Certif ied TesterÜber 265.000 Certi�ed Tester weltweit. Über 28.000 davon in Deutschland. Wann gehören Sie dazu? Qualität entscheidet zunehmend über den Erfolg von IT. Professionelles, modernes Testen ist hierbei eine Conditio sine qua non!Vor 20 Jahren wurde Testen noch als die destruktive Technik am Ende der Software-Entwicklung verstanden, ein Programm zum Fehlverhalten zu zwingen. Doch die IT-Industrie lernte, und Testen rückte von der Rolle der nachgelagerten Feststellung des Todes einer Applikation in die Rolle der begleitenden, konstruktiven Heilung. Die Schulung zum ISTQB® Certi�ed Tester trainiert diesen ganzheitlichen, modernen Testansatz seit über 10 Jahren: Mit seinen drei Reifegraden Foundation, Advanced und Expert wird es den unterschiedlichen Ansprüchen an erfolgreiche Tester gerecht. Doch auch hier wird weiter gelernt: So gibt es in 2013 einen überarbeiteten Advanced-Level. Viele Inhalte wurden modernisiert und aktualisiert und alle Begri�ichkeiten wurden konsistent zum neuen ISTQB®-Glossar gewählt. Lernen aus einem Guß! Des weiteren gibt es im Advanced-Level kaum mehr Überschneidungen zum Foundation-Level: Die Schulungen sind dadurch sehr viel fokussierter und bieten noch mehr Raum für praktische Übungen. Einige Kurse konnten daher nun auch zeitlich verkürzt werden, was den knappen Weiterbildungsetats entgegen kommt. Und was für den Hochbildungsstandort Deutschland besonders wichtig ist: Die ISTQB®-Schulungen unterstützen nun explizite Karrierepfade, die dem lernenden Tester vom Foundation-Level, über den Advanced-Level zum Expert-Level als Orientierungsbojen begleiten können. Wann rudern SIE wieder?

Der ISTQB® Certi�ed Tester ermöglicht Tester-Karrieren - die Schulungen bieten damit erstmals ein internationales und branchenübergreifendes Berufspro�l für Software-Tester, jeweils mit individuellen Schwerpunkten.

Der ISTQB® Certi�ed Tester macht die Arbeit leichter - Tester sprechen nun die gleiche Fachsprache, benutzen die gleichen Begri�e, sind up-to-date.

Der ISTQB® Certi�ed Tester hilft, Kosten zu senken - durch geschulte Tester werden Fehler bereits in frühen Phasen der SW-Entwicklung systematisch entdeckt. Und hierbei helfen gerade im Advanced-Level gute Test-Manager, Test-Analysten und gute technische Tester.

Anmelden ist einfach.Ein akkreditierter Trainingsanbieter ist sicher auch in Ihrer Nähe:

Alle Trainingsprovider siehe www.german-testing-board.info

GTB Premium PartnerALTRAN GmbH & Co. KG

berner & mattner Systemtechnik GmbH

C1 SetCon GmbH

EXCO GmbH

imbus AG

ISARTALakademie GmbH

Knowledge Department GmbH

Logica Deutschland GmbH & Co. KG

Loyal Team GmbH

Method Park Software AG

Philotech GmbH

sepp.med gmbh

Software Quality Lab GmbH

Sogeti Deutschland GmbH

SQS AG

T-Systems

Autorisierte Zerti�zierungsstellenCert-IT GmbH

gasq Service GmbH

iSQI GmbH

„Lernen ist wie Rudern gegen den Strom. Sobald man aufhört, treibt man zurück.“

Anzeige_OBJEKTspektrum_210x148mm_RZ_2013_02_14.pdf 1 14.02.13 10:39

Date post:	23-Sep-2020
Category:	Documents
Upload:	others
View:	0 times
Download:	0 times

Arbeitskreis Software-Qualität und -Fortbildung e.V ... · Software Testanalyst (w/m) Océ...

Documents