Sq magazin27 issuu

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

Arbeitskreis Ausgabe 27 Software-Qualität | Juni 2013 und -Fortbildung e.V.

TRADITIONELL VS.

AGIL

Im Gespräch Interview mit Chris Carter Seite 8

Standard NEWS Nachwuchs bei den „Certified’s“ Seite 30

ASQF-Umfrage 2013 IT-Branche bleibt zuversichtlich Seite 39

Kostenlos* zum ISTQB Certified Tester!

Wie ist das möglich?

Am 1. Juli feiert die Díaz & Hilterscheid GmbH ihr 15-jähriges Firmenjubilä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 kostenfreien Platz im oben genannten Kurs! Sie buchen hierzu lediglich zwei weitere Teilnehmer für unsere Kurse im laufenden Kalenderjahr. Für weitere Informationen und die Onlineanmeldung zu unseren Kursen besuchen Sie training.diazhilterscheid.de.

* Bitte beachten Sie folgende Hinweise: • 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 innerhalb von 24 Stunden zwei weitere kostenpflichtige Anmeldungen von Mitarbeitern desselben Unternehmens zu unseren ISTQB, CPRE oder CAT Kursen im Kalenderjahr 2013 eingehen. Bitte verweisen Sie im Kommentarfeld der Onlineanmeldung auf die weiteren Teilnehmer aus Ihrem Unternehmen.

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

• Dieser Sonderrabatt ist nicht mit anderen Sonderaktionen kombinierbar.

training.diazhilterscheid.de

3

Ausgabe 27 | Juni 2013

Editorial

Liebe Freunde, Deutschland steht vor wichtigen Wahlen im September und damit kündigt sich für unser Land eine Richtungsentscheidung an.

Entscheidende Wahlen haben in den letzten Wochen auch in unserer Branche stattgefunden: Das ISTQB wählte mit Chris Carter einen neuen Präsidenten (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. Sicherlich 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 treibende Kraft für Innovationen. Vor allem aber muss das Ohr wieder mehr am Markt sein. Ein Vorwurf, den der ASQF sich sicher nicht machen lassen muss, ist er doch mit seinen Fachgruppen und regionalen Fachgruppen 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 Branchenvertretung, 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 bestimmen, 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 kontinuierlich 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.

Inhalt

Ausgabe 27 | Juni 2013

4

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

8

Interview mit Chris Carter

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 //

3 EDITORIAL 6 ASQF-NEWS Die ASQF-Days: Leuchttürme im Knowhow-Transfer // Einreichung: Deutscher Preis für Software-Qualität // Zuwachs: Neue Mitglieder // Günstiges Fachwissen: Partnerkonferenzen 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)

develoPPP.de Entwicklungspartnerschaft: Fachkräftequalifizierung 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.

Das ASQF Karriereportal Wir haben den passenden JOB für Sie. Load & Performance Test Analysts (m/w) Atos IT Solutions and Services GmbH, München

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

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

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

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

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

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

Softwareentwickler Webanwendungen CONTACT Software GmbH, Bremen

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

Softwareentwickler/in GFB EDV Consulting und Services GmbH, Oberursel

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

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

Testspezialisten (m/w) ckc group, Braunschweig

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

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

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

Softwarearchitekten m/w Sepp.med GmbH, Röttenbach Softwareentwickler für embedded Systeme m/w Sepp.med GmbH, Röttenbach

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

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

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

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

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

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

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

Software Quality Engineer (w/m) CAS Software AG, Karlsruhe Testmanager (m/w) BITMARCK Holding GmbH, Hamburg Teamleiter (m/w) - Testarchitektur BITMARCK Holding GmbH, Hamburg Testmanager (w/m) mit bankfachlichem Hintergrund ISMC 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 Firmwaretests 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 Vollzeit tecmata GmbH, Wiesbaden Consultants m/w für modellbasierte Softwareentwicklung MID GmbH, Stuttgart Consultants m/w für modellbasierte Softwareentwicklung MID GmbH, Nürnberg

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# - Entwicklung CLEAR 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

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

ASQF NEWS

Ausgabe 27 | Juni 2013

6

Die ASQF-Days: Leuchttürme im Knowhow-Transfer Im Rahmen der gemeinnützigen Arbeit des ASQF nehmen die ASQF Days einen besonderen Stellenwert ein. Sie sind die Leuchttürme, die die Fachkompetenz der ASQFThemenbereiche 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.

19.06.2013: Rhein-Main Testing Day in Frankfurt am Main

TESTING DAY

„Open Space“ lautet auch in diesem Jahr wieder der Ansatz der FRANKFURT a.M. bekannten Reihe aus dem ASQF. Mit seinem WWW.ASQF.DE offenen DiskussionsKonzept 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.

RHEIN-MAIN 19/06/2013

PROGRAMM UND ANMELDUNG UNTER: https://www.asqf.de/fachgruppentermine-anzeige/events/id-19062013-7rhein-main-testing-day.html.

10.07.2013: Automation DAY in Nürnberg Klassisch ist die Automatisierung zweigeteilt in Embedded Steuerungen (proprietär) und Tools (Windows).

Neu ist der Trend, einen Teil 10/07/2013 der Tools auf „irgendeinem“ WWW.AUTOMATIONDAY.DE Gerät – sei es ein SmartPhone, 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öglichkeiten werfen eine Menge Fragen auf und bieten Vorteile.

Doch was gibt es zu beachten und was sind die wirklich relevanten Vorteile? „Web-Technologien in der Automatisierung“ lautet daher das Thema des 22. Automation Day. PROGRAMM UND ANMELDUNG UNTER: www.automationday.de

20.06.2013: MEDICAL DEVICE DAY in Erlangen

MEDICAL DEVICE

Mit dem Leitthema “Klinische Bewertungen und Validierung von Software“ findet am 20.06.2013 der 4.

ERLANGEN Medical Device Day in Er20/06/2013 WWW.ASQF.DE 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 praxisnah und verständlich erläutern.

PROGRAMM UND ANMELDUNG UNTER: https://www.asqf.de/fachgruppentermine-anzeige/events/id20062013-4-medical-device-day-franken-ganztagesveranstaltung.html

24.09.2013: Testing-Day Franken in Erlangen

TESTING DAY

Zum 10-jährigen Jubiläum veranstaltet die ASQFFachgruppe SoftwareTest Franken den „3. TesERLANGEN ting Day Franken“ in Erlangen. Unter dem Leit- WWW.TESTING-DAY-FRANKEN.DE thema „Testen im innovativen Umfeld“ wird ein zweigliedriges Vortragsprogramm angeboten, 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 Testautomatisierungsmethoden.

FRANKEN

24/09/2013

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

7

ASQF NEWS

Ausgabe 27 | Juni 2013

Einreichung: Deutscher Preis für SoftwareQualität 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 Forschung auf dem Gebiet der SoftwareQualität verdient gemacht haben. 2011 wurde der Deutsche Preis für Software-Qualität an Harry M. Sneed vergeben. 2012 wurde Rudolf van Megen mit dem Preis für sein Lebenswerk geehrt. Der Vorschlag ist in schriftlicher Form (auch elektronisch) als maximal zweiseitiges Dokument an die Geschäftsstelle des ASQF in Erlangen (an info@asqf.de ) 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

Zuwachs: Neue Mitglieder + 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

Werden auch Sie Mitglied im ASQF!

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.

Sommeraktion: Mitglied werben und Prämie sichern Sie werben ein persönliches Mitglied und erhalten als Dankeschön das exklusive ASQF-Kochbuch.

Sie werben drei persönliche Mitglieder oder ein Firmenmitglied. 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 besonderes Dankeschön ein iSQI Examen Ihrer Wahl. Wir übernehmen die Prüfungsgebühr für Sie!

Günstiges Fachwissen: Partnerkonferenzen mit ASQF-Rabatt ASQF-Mitglied sein lohnt sich. Neben den zahlreichen kostenlosen Wissensangeboten des ASQF erhalten Mitglieder auf vielen anerkannten Fachkonferenzen V o r z u g s p r e i s e auf die Teilnahmegebühren. Aktuell gibt es für folgende Veranstaltungen Vorzugspreise: - 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

Neu: Fachgruppenleiter Ralf Bongard, ISARTALakademie GmbH, zuvor stellvertretender Fachgruppenleiter, übernimmt sowohl die regionale Fachgruppenleitung Requirements Engineering SüdBayern, als auch die Stellvertreterfunktion der gesamten Fachgruppe RE. Gesamtfachgruppenleiter ist Jens Palluch von der Method Park Software AG. In der regionalen FG Requirements Engineering in NRW übernimmt Peter Joost, Honeywell, die bisher vakante Position des Stellvertreters.

Jürgen Andert

Dr. Wolfram Esser

Sobald Sie auf dem Mitgliedsantrag eines Neumitgliedes als Werber genannt werden, nehmen wir Sie auf die Prämienliste auf. Am Ende der Sommeraktion 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

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

Im Gespräch

Chris Carter is ISTQB president and founder of Planit, one of the biggest testing consultancy 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.

Ausgabe 27 | Juni 2013

8

9

Ausgabe 27 | Juni 2013

Im Gespräch

Interview mit Chris Carter, der neue Präsident des ISTQB 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’ accreditation for anyone who is serious about getting certified 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 competing 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 relevance 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 diminishing in terms of its appeal but quite frankly the reality is completely the opposite. In fact, I see the momentum increasing 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 different levels of maturity that have been operating for different 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 significant 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 looking to be software testers..

Stephan Goericke: If you, as president, set up three milestones 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 individual 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 biggest 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 reasons would you mention?

Chris Carter: First thing is the relevance of the ISTQB - it is a global scheme that encourages international standardisation 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.

Im Fokus

Ausgabe 27 | Juni 2013

10

Warum Glaubenskriege?

Dr. Mohsen Ekssir In der letzten Zeit ist man oft mit den verhärteten Standpunkten in Bezug auf die Auswahl der Software-Entwicklungsmodelle konfrontiert. Es wird sehr gerne das eine oder andere Software-Entwicklungsmodell als Allheilmittel dargestellt. Oft hört man von den Anhängern der klassischen Entwicklungsmodelle, dass die agilen Methoden nur zur Chaos führen. Umgekehrt vernimmt man von Anhä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 rigide Entweder-oder-Sichtweise in Bezug auf die Wahl des Entwicklungsmodells.

Woher kommen diese extremen Einstellungen?

Es gibt leider keine Anwender-Altersstatistik der verschiedenen Entwicklungsmodelle im deutschsprachigen Raum.

Auch existiert keine Statistik bezüglich des Bestehensalters der Unternehmen und der bei ihnen eingesetzten Entwicklungsmodelle. Diese beiden Aspekte wurden bei der Testumfrage vom Jahr 2011 [1], die im letzten Jahr durchgeführt wurde, nicht berücksichtigt.

Da es keine fundierten Informationen bezüglich der Altersgruppe 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 Traditionalisten 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 auseinandergesetzt haben.

Auf der anderen Seite ist im Manifest für „Agile Softwareentwicklung“ festgehalten: „Wir erschließen bessere Wege, Software zu entwickeln, indem wir es selbst tun und anderen dabei helfen“ [3]. Die Einstellung, mit agilen Modellen die „besseren Wege“ zu bestreiten, behält sich den Anspruch, das bessere Entwicklungsmodell zu sein vor. Dies könnte auch ein Grund dafür sein, dass die Agilisten glauben, eine bessere Schule als Traditionalisten zu haben.

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

Situationsbezogenes Vorgehen Das Teilen des gesamten Entwicklungsvorhabens in Phasen oder Iterationen (und Inkrementen) muss wohlüberlegt und ausgeführt werden. Es soll je nach aufgestellten Bedürfnissen und Anforderungen sowie dem Vorhandensein bestimmter Rahmenbedingungen das geeignete Modell für eine spezifische Situation ausgewählt werden. Die Vorgehendmodelle 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 situationsbezogene 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 wahrscheinlich 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 herauszuholen. Es sind gewisse Praktiken bei beiden Entwicklungsmodellrichtungen, 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 unflexibel Entscheidungen zu treffen. Die folgenden Praktiken könnten situationsbezogen von agilen oder klassischen Modellen jeweils in das andere Modell übernommen werden. 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 interdisziplinär besetzten Teams mit Scrum-Master durchzuführen.

11

Ausgabe 27 | Juni 2013

Traditionell vs. Agil

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 geographischen Raum arbeiten, kann diese Praktik separat für das Entwickler- und/oder Testteam durchgeführt werden.

Schnelles Feedback: Bei diesem Grundpfeiler des agilen Entwicklungsmodells geht es darum, schnelles Feedback zu erreichen. Mit schnellem Feedback ist es möglich, 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 aufgenommen werden kann. Schnelles Feedback kann mit der Durchführung des explorativen Tests (z. B. durch einen Fachbereichsmitarbeiter) vor dem tatsächlichen strukturierten Test (vor jeder Teststufe oder sogar vor jedem Testzyklus) geliefert werden. Der explorative Test kann nach einem erfolgreichen Smoke-Test (als Eingangskriterium) durchgeführt werden.

Dr. Mohsen Ekssir ist Bereichsleiter Software Test und Qualitätssicherung bei BDC EDV-Consulting.

Er ist sowohl ISTQB® Certified Tester (Full Advanced Level) als auch Certified Agile Tester (CAT®).

Klassische Praktiken, die in ein agiles Modell integriert werden können: Rollen: Agile Teams sind interdisziplinär besetzt und haben keine formalen Rollen. Hinsichtlich des Qualitätsmanagements arbeiten die Teams nach agiler Vorgehensweise 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ätssicherung (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 Erstellung 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ückverfolgbarkeit 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 dokumentieren. Bei der Dokumentation muss überlegt werden, wie granular diese zu erstellen ist, damit es kein unnötiger bürokratischer Buchführungsaufwand generiert wird [5].

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 Sinneseindrücke benutzt wurden, ohne das Wesen und Dasein 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, darüber sollte situationsbezogen entschieden werden. Das Tailoring des ausgewählten Modelles kann noch zur Effizienzsteigerung des Abwicklungsprozesses führen. Dabei können einige Praktiken der agilen Vorgehensweise in das klassische Phasenmodell übernommen werden und vice versa.

L I T E R AT U R : [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 Softwareentwicklung: 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

Ausgabe 27 | Juni 2013

12

Ain’t no mountain high enough! – Das iSQI zertifiziert nun auch in der Schweiz 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 Trainingsanbietern. In der Zusammenarbeit mit dem iSQI können die Trainingsanbieter Foundation Level Prüfungen papierbasiert 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

Produktvorstellung auf der iqnite Düsseldorf Zwei neue Produkte stellte das iSQI auf der diesjährigen iqnite in Düsseldorf vor. Zum einen das Agile Essentials Weiterbildungs- und Zertifizierungsprogramm, welches allen 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 Special Interest Group „Model Based Testing“ (SIG MBT) den Certified Model Based Tester auf den Markt. Interessierte 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 Weiterbildung ist groß. iSQI kommt dieser Entwicklung mit dem Agile Essentials und dem MBT Kurs nach.

Dutch Testing Days: Lange Schlangen vor „Agile“-Vorträgen Über 200 Teilnehmer besuchten am 17. April die Dutch Testing Confrence in Bussum, Niederlanden. Das Programm enthielt exzellente Keynotes zum Branchenthema Nr. 1 „Agile“ sowie aus Schlüsselbereichen zwischen Testen und Business. Die Vortragsthemen fokussierten sich auf Agile, Test Automatisierung, Cloud und Test Center of Excellence, wobei sich gerade vor den „Agile“ Vorträgen lange Schlangen bildeten. Die Dutch Testing Days belegten die große Relevanz 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.

13

iSQI NEWS

Ausgabe 27 | Juni 2013

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

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 Teilnehmern neuer Partner-Unternehmen. Der Kurs fand vom 28.04.2013 bis 02.05.2013 an der Birzeit University, Palästina statt. Durch die Kurse werden lokale IT-Fachkräfte zu Trainern ausgebildet. Langfristig wollen wir in unser Zusam-

Foto: © T. Braune

Ende April reiste Geschäftsführer Stephan Goericke gemeinsam 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 unterstü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.

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 presse@isqi.org

Alles auf „Agile“ 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 Engineering 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-

iSQI on tour JUNI

JULI

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

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

12.06.2013 | iSQI @ iqnite | Wien, Österreich

AUGUST

25.06.2013 | iSQI @ iqnite | Genf, Schweiz

23.08.2013 | iSQI @ ISTQB® Hauptversammlung | Helsinki, Finnland

sem Kurs, in dem sie ein fundamentales Verständnis der agilen Techniken erhalten. Der Erfolg eines Projekts, das einem 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 Projektteams und der Nutzergruppe, dem Management und den Stakeholdern. Die Entscheidung, mit agilen Methoden zu arbeiten, wirkt sich auf das Projekt und dessen Management wie auch auf deren Umfeld aus. „Agile“ ist weltweit auf dem Vormarsch und da noch relativ neu, gibt es aktuell im Verhältnis wenige Fachkräfte mit praktischer Erfahrung. Um die Nachfrage nach agilen Spezialisten 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 entwickeln, 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

Im Fokus

Ausgabe 27 | Juni 2013

14

Agiles Projekt-Management vs. IT-ServiceManagement (Zielstellungen des DevOps-Ansatzes) Andreas Schmietendorf Motivation Agile Methoden zur Softwareentwicklung haben sich insbesondere 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ällige Strukturen und Abläufe, wo Unternehmen auf flexible, verantwortliche Zusammenarbeit angewiesen sind.“ Lange wurde eine hohe Prozessreife innerhalb des IT-Lebenszyklus mit qualitativ hochwertigen IT-Services gleichgesetzt, die auch aus wirtschaftlicher Sicht determinierbar erschienen. Sowohl für die Softwareentwicklung als auch für die betrieblichen Aufgabenstellungen des IT-ServiceManagements entstanden daher komplexe Prozessbeschreibungen, die für sich einen „best practice“-Ansatz beanspruchen. Trotz der zunehmenden Prozessreife existieren 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ünstigen und qualitativ hochwertigen Implementierung von Software in Verbindung gebracht. In diesem Zusammenhang wird auch von einer Entbürokratisierung der Softwareentwicklung und dem Verzicht einer dokumentengetriebenen Vorgehensweise gesprochen. Durch die Annnahme einer flachen Aufwandskurve ist der Aufwand für umzusetzende Anforderungen unabhängig vom Zeitpunkt ihres Eintreffens. Diese Annahme kann allerdings nur mit Hilfe einer aus Sicht der Wartung guten Softwarearchitektur 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 Systemeinsatz.

Fragen des späteren Wirkbetriebs (speziell IT-Service-Management) berücksichtigen Publikationen im Kontext der agilen Softwareentwicklung zumeist nur am Rande. [Röpsdorf 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 stabile und qualitativ nachhaltige Bereitstellung kundenwirksamer 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 Verantwortlichkeiten. 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 gelungen 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. Stattdessen sollte auf die Themen geschaut werden, wegen derer man ITIL einführen möchte.“ Es sei darauf hingewiesen, dass die Verfasser des ITILFrameworks keinesfalls eine Berücksichtigung aller „good practices“ einfordern. Erfolgreiche Unternehmen benutzen

15

Traditionell vs. Agil

Ausgabe 27 | Juni 2013

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 Ursache 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 entwicklungs- und betriebseitiger Belange kann auf eine lange Historie zurückblicken. Firmenspezifische Vorgehensmodelle betrachteten schon zum Anfang der 90-er Jahre den gesamten Lebenszyklus eines Softwaresystems. Die organisatorische Separierung entwicklungs- und betriebsseitiger Aufgabenstellungen war insbesondere den steigenden Anforderungen einer wirtschaftlichen Transparenz und zunehmenden Industrialisierung der IT geschuldet. Die anbieterseitige 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 Wochen) bei mobilen Anwendungen (Apps) beobachtet werden, auch hier ist die parallele Berücksichtigung entwicklungsseitiger und betrieblicher Anforderungen unerlässlich.

Eine treffende Problembeschreibung zur Lücke zwischen Entwicklung und Betrieb findet sich unter [Appleton 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 making 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“) versucht diese Lücke zu schließen. Im Sinne agiler Projektmanagementansätze sollen in die IT-Leistungserbringung involvierte Organisationen motiviert werden, miteinander zu kommunizieren. Darüber hinaus sollten Entwicklungs- und Einführungsprojekte mit demselben Kundenbezug kooperativ bearbeitet und betriebliche Belange frühzeitig berücksichtigt 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-Prozessen - 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 Integrationsarchitekturen und zum Cloud-Paradigma.

Im Jahr 2006 rief er die durch die ASQF, ceCMG, DASMA und GI unterstützte BSOA-Initiative (Bewertungsaspekte serviceorientierter Architekturen) ins Leben.



Im Fokus

Ausgabe 27 | Juni 2013

Die erreichbare Agilität innerhalb des IT Service-Managements hängt insbesondere von der Komplexität bestehender Hard- und Softwarearchitekturen ab. Nicht selten führen eng gekoppelte Systeme bzw. die Nutzung proprietä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 Softwareentwicklung bedarf einer Versachlichung. Noch immer existiert bei Banken und Versicherungen eine Vielzahl von Altsystemen, die sich dem Einsatz agiler Methoden weitgehend entziehen. Gründe, die dort gegen den Einsatz 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-Prozesses. Darüber hinaus spielen auch die Sensibilität einer Anwendung, Fragen der Compliance oder sicherheitstechnische Erwägungen eine Rolle für die Auswahl einer Vorgehensweise.

16

Bedarf eines agilen Service Designs Aus Sicht des Autors wird ein agiles und risikogetriebenes Service Design benötigt, welches aus fachlicher Sicht entlang 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 technologischen Schnittstellengestaltung zwischen Entwicklung und Betrieb. Im Mittelpunkt stehen dabei Aufgaben wie ein agiles Testen (vgl. Certified Agile Tester der ASQF), die kontinuierliche Integration entsprechender Softwareversionen oder aber eine automatisierte Anpassung der einhergehenden Service-Managementprozesse. fachlicher Nutzen - Business Architekturmanagement Prozesse, Daten, Integration, Service

SW-Entwicklung

Agilität

Häufige Releases Qualitätssicherung Agiles Testen Konfiguration-Management Fehler-Toleranz Kontinuierliche Integration

Änderungen als Herausforderung

IT-Betrieb

Stabilität Änderungen als Bedrohung

Klassische Methoden

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

Back-End Orientiert Stabilität

Flexibilität Front-End Orientiert

Agile Methoden

Mainframe

Laptop

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

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

Zusammenfassung Der fachliche Kunde bzw. Nutzer eines IT-Service interessiert 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 ITManagements (speziell Architekturmanagement) ab, da dort sämtliche Aufgabenstellungen der informationstechnischen Versorgung eines Unternehmens verantwortet werden. Die Verantwortung dafür kann nicht an einen externen Anbieter 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 Entwicklerund 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.

V ER W EN D E T E Q U E L L EN [Appleton 2010] Appleton, B.; Berczuk, S.; Cowham, R.: Agility Throughout 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 Helping 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?, Javamagazin 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

17

Ausgabe 27 | Juni 2013

Testen im SAP Umfeld Nichts Besonderes und doch irgendwie anders

Durch die gebotenen Anpassungs- und Änderungsmöglichkeiten entsteht aus der Standardsoftware SAP sehr schnell eine individuelle Softwarelösung. Die Folgen?

Durch falsch vorgenommene Anpassungen und unerwünschte, von Änderungen ausgelöste, Seiteneffekte, kann eine Beeinflussung der vorhandenen Funktionalitä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 „Aufgrund der vielen Customizing Möglichkeiten die SAP bietet, gibt es immer wieder neue, spannende Herausforderungen beim Test im SAP Umfeld.“ Claudia Blankschein / Testconsultant, ANECON claudia.blankschein@ anecon.com

Zudem kann es beispielsweise beim Aufruf von Reports zu frustrierenden und unnötigen Wartezeiten für den Tester kommen.

Auswahl / Anlegen von Test-Usern SAP hat ein umfangreiches Berechtigungskonzept. Im Vorfeld ist es daher wichtig zu klären, welcher User welche Geschäftsprozesse ausführt bzw. welche Transaktionen prüft. Meist ist es nicht sinnvoll mit umfassenden 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 Testwerkzeugs

Auswahl der Testdaten Für funktionale Tests ist die Auswahl der richtigen Testdaten schwierig 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 Bestandsdaten notwendig sind. Zudem stellt sich bei der Nutzung von Produktionsabzü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 Transaktionen Funktionalität und Komplexität von SAP Transaktionen ist unterschiedlich.

Das geht z.B. von der Anzeige von Daten im Displaymodus bis zum Ausfü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.

Nicht 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-Standardtestfällen möglich. Dennoch dürfen auch Pflegeaufwand und Benutzbarkeit nicht außer Acht gelassen werden.

Auswahl des Testansatzes Von Customizing, über komplette Geschäftsprozesse, bis zum End-toEnd Test mit verschiedenen Systemen und internen & externen Schnittstellen 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 Tabelleneinträ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 Advertorial

Im Fokus

Ausgabe 27 | Juni 2013

18

Testende Entwickler und entwickelnde Tester: Eine Win-Win-Konstellation Frank Simon Auch wenn der Großteil der heutigen IT-Projekte immer noch nach klassisch phasenorientierten und iterativen Vorgehen entwickelt wird (vgl. z.B. www.softwaretest-umfrage.de), hat sich die agile Software-Entwicklung als angesehenes 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 Tester nun vorbei, da jetzt jeder im agilen Team testet und entwickelt? Müssen also alle ISTQB Syllabi umgeschrieben 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 korrespondiert dabei aus Testsicht mit spezifischen Testobjekten und Testkriterien: Die naturgemäße White-Box-Sicht der Softwareerstellung orientiert sich an Kontrollflüssen, Datenabhängigkeiten, Klassen, Funktionen und so weiter. Die Nutzungssicht orientiert sich eher an Business-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 Aufgaben. 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, Speichermanagement oder Threadverwaltung).

Die so aufgespannte Matrix kann damit wie folgt dargestellt werden und erlaubt die Positionierung des klassischen Nutzers oben rechts und des klassischen Entwicklers 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 Integrations- und den Funktionstest, unten rechts den Penetrations- und Performance-Test und oben rechts gibt es beispielsweise den Systemabnahme- und Usability-Test.

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

Bzgl. der ISTQB® -Syllabi kann interessanterweise folgendes 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 Methodenkasten 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 entsprechenden 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 Kontext 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 dominieren damit heute die testenden Entwickler und damit die linken 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 professionell aus Sicht der Anwender testet.

19

Ausgabe 27 | Juni 2013

Traditionell vs. Agil

In klassisch entwickelten Systemen findet sich dagegen häufig genau die umgekehrte Situation: Viele dedizierte Tester decken den oberen, rechten Bereich gut ab, meiden aber die technischeren Tests. Die jeweiligen Stärken beider Testschwerpunkte sind in der folgenden Abbildung 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 Kombination aus agilen Entwicklern und klassischen Testern ermöglicht eine wirklich effiziente und effektive Software-Erstellung, bei der alle möglichen Fehlerquellen (technische und fachliche) so früh wie möglich gefunden werden. An der Schnittmenge treffen dann testende Entwickler und entwickelnde Tester zusammen (vgl. Abbildung 2).

An ein solches Win-Win-Team können heute folgende Anforderungen gestellt werden: - Jedes Team-Mitglied sollte ein Grundverständnis vom Testen haben. Dies ist für ein konsistentes Testvokabular im Team unabdingbar. Der ISQB® -Foundation Level bietet hierfür eine solide Ausgangsbasis.

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

Der ISTQB® -Syllabus ist also bereits heute geeignet, solche Win-Win-Teams aufzubauen. Es wird Zeit, diese Vorteile 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 Qualitä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.

Im Fokus

Ausgabe 27 | Juni 2013

20

Klassisches Konzert mit agilen Partituren Johannes Helders Mit wachsenden organisatorischen und technischen Abhängigkeiten führt am Traditionell Testing kein Weg vorbei.

Aber auch in einem traditionellen Umfeld können agile Methoden ihre Effizienzvorteile ausspielen.

Bei IT Projekten, in denen fachliche, technische oder organisatorische Abhängigkeiten in einem hohen Maß zu berücksichtigen sind, greifen agile Methoden alleine zu kurz. Um diese Abhängigkeiten zu bewerten und im Testmanagement zu berücksichtigen braucht es Vorlauf. Allerdings 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 werden, wirken die traditionellen Testansätze häufig sehr starr.

Hier sind agile Test-Methoden klar im Vorteil.

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 Einfluss auf die Entwicklung genommen werden (test driven developement), so dass auch frühzeitig mit Testautomatisierung begonnen werden kann.

In größeren Arbeitspakten hingegen wirkt ein Testmanager eher als Moderator und Übersetzer zwischen den Fachbereichen 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.

Von Anfang an dabei

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

Mit dem Aufsetzen des IT-Projekts beginnt auch das Testmanagement. Sobald Architektur Entscheidungen getroffen 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 Konzeptreviews sorgt dafür, dass erste Fehler erkannt werden, bevor sie programmiert werden. Billiger kann Fehlerbehebung nicht sein.

Prozessentwicklung (a) und Releasetests (b)

Neben den fachlichen und technischen Test-Requirements müssen auch die Anforderungen an den Testprozess rechtzeitig klar sein, damit noch hinreichend Zeit bleibt, um den Testprozess für die kommenden Anforderungen weiter zu entwickeln bevor die eigentlichen Tests starten (vgl. Abbildung (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 Testmanager häufig alle Aufgaben in Personalunion. Er schreibt die Testfälle, kümmert sich um Testdaten, konfiguriert sei-

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 Anwendungen zu harmonisieren. (vgl. Abbildung (b)) Für den End to End Test müssen Installationstermine aufeinander abgestimmt werden. Desweiteren sind für Produktionseinsätze entsprechende Vorlaufzeiten zu berücksichtigen. 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ühzeitig sind die Releasetests und damit auch die Projekttests auf diesen Anwendungen abzuschließen.

21

Ausgabe 27 | Juni 2013

Traditionell vs. Agil

Projektmanagementkompetenzen 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. Insbesondere 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 Mitarbeiterentwicklung sollte daher nicht alleine auf dem Erwerb von Testzertifikaten und der Kenntnis von Tools Wert gelegt werden. Mindestens genauso wichtig sind Kompetenzen in Moderation, Planung, Steuerung und Führung. Genau diese befähigen einen erfahrenen Testmanager auch als Projektleiter.

Johannes Helders verantwortet seit 2001 den Testprozess 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 Kongressen auf.

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

Im Fokus

Ausgabe 27 | Juni 2013

22

Modellierung – agil versus traditionell Andreas Ditze, Susanne Mühlbauer, Philip Stolz 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 Abstraktionsebene können wir Modelle mit unterschiedlichen Zielsetzungen einsetzen. Unterschiedliche Abstraktionsebenen ermöglichen es uns, sowohl den Überblick zu behalten, als auch dabei, den Problemraum vom Lösungsraum – das Was und Warum vom Wie – zu trennen.

Gibt es überhaupt eine Agile Modellierung?

Um diese Frage zu beantworten, ist es unerlässlich, einen 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 agiler 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 Prinzipien des agilen Manifests herausgreifen, die durch Modellierung 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 übermitteln, ist im Gespräch von Angesicht zu Angesicht (Agiles Manifest).“ Agile Entwicklung versucht auf umfassende schriftliche Vorabspezifikationen zugunsten von Konversation und schnellem Feedback zu verzichten.

Dieses Prinzip basiert also auf dem persönlichen Gesprä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önnen, je nach Zielsetzung, mit unterschiedlichen Formalisierungsgraden 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 Aspekte 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 unterschiedlich verfahren werden: - Sie werden entsorgt, nachdem das gemeinsame Verständnis erzielt wurde - Sie werden in eine elektronische Form übertragen (z.B. in ein Modellierungswerkzeug), die eine weitere Bearbeitung der Modelle zulässt: - Auswirkungsanalyse der betrachteten Teilaspekte auf das Gesamtsystem (falls dieses bereits als Modell repräsentiert vorliegt) - Ableitung des Software-Designs durch das Entwicklungsteam - Implementierungsvorgabe für modellbasierten Code - Verfeinerung und Aktualisierung als Systemdokumentation 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. Modellgetriebene Vorgehensweise hilft dabei Routinearbeiten zu sparen durch: - Code-Generierung aus Design-Modellen - Dokumentations-Generierung aus allen Modellen - Erstellung von Benutzerdokumentation aus ausgewählten Modellen - modellbasiertes Testen In Verbindung dazu sind auch die folgenden beiden Prinzipien zu sehen: „Unsere höchste Priorität ist es, den Kunden durch frühe und kontinuierliche Auslieferung wertvoller Software zufrieden zu stellen (Agiles Manifest).“ „Liefere funktionierende Software regelmäßig innerhalb weniger Wochen oder Monate und bevorzuge dabei die kürzere Zeitspanne. (Agiles Manifest).“

23

Traditionell vs. Agil

Ausgabe 27 | Juni 2013

Diese beiden Forderungen lassen sich nur erfüllen, wenn sich die Entwicklung auf die wirkliche Entwicklungsleistung und Innovation konzentrieren kann und Änderungen 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 Manifest).“ In der Praxis sehen wir leider, dass agile Teams kaum mit Modellierung arbeiten. Sie erkennen häufig den Nutzen nicht, der Ihnen durch Modellierung entstehen kann – Modellierung wird als Aufwand, nicht als Entlastung angesehen. Die Erklärungsversuche hierfür sind unterschiedlich: - 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 Entwicklungsumgebung - Es ist zu wenig Modellierungs-Know-how im Team vorhanden - Modellierung wird als kompliziert empfunden, da immer der höchste Formalisierungsgrad angestrebt wird

Andreas Ditze ist Geschäftsführer bei der MID GmbH. Er ist Leiter der Fachgruppe Modellierung im ASQF.

Susanne Mühlbauer ist Senior Consultant, Trainer und Coach bei der HOOD Group.

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 Verwendung von Modellierung unter Berücksichtigung agiler Prinzipien und agiler Werte.

Philip Stolz ist Senior Consultant, Trainer und Coach bei der HOOD Group.

Was macht traditionelle Modellierung traditionell?

Prinzipiell unterscheiden wir im Folgenden die Phasen Analyse, Design und Implementierung. In der Analysephase 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 Implementierung erfolgt die eigentliche Umsetzung.

Bei eher traditionellen, phasenorientierten Vorgehensweisen werden die einzelnen Phasen sequentiell bearbeitet (siehe Abbildung 1), wobei auch hier ein iterativer Ansatz natürlich nicht ausgeschlossen ist. Auch die Modellierungsaktivitäten richten sich dann nach diesen Phasen, wir unterscheiden zum Beispiel nach objektorien-



Im Fokus

Ausgabe 27 | Juni 2013

24

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

tierter Analyse (OOA) und objektorientiertem Design (OOD).

Modellierungsnotationen wie die UML sind universell für alle Phasen und Abstraktionsebenen einsetzbar oder beziehen sich auf die Beschreibung konkreter Artefakte, wie die BPMN für Geschäftsprozesse und Workflows.

Agiles Vorgehen ist iterativ und inkrementell. Analyse, Design und Implementierung sind keine Phasen, sondern Aktivitäten, die laufend stattfinden. Das Ergebnis jeder Iteration (hier Sprint) ist jeweils ein potentiell lieferbares Produktinkrement. Im Rahmen der Sprintplanungsmeetings am Anfang jeden Sprints erfolgt Analyse und Design für die im aktuellen Sprint umzusetzenden Anforderungen. Während 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 traditioneller 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 Gedankengänge nachvollziehbar darstellen – sind Modellierungskenntnisse für die professionelle Software-Entwicklung unabdingbar. Unabhängig davon, ob Sie agil oder traditionell vorgehen bietet Modellierung ausgezeichnete Möglichkeiten, 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-Generierung) - Analyse-/Design-Entscheidungen und die erstellte Implementierung zu dokumentieren.

Für den Einsatz von Modellierung ist es dabei vollkommen unerheblich, welches Vorgehensmodell für die Systementwicklung gewählt wird.

In allen Phasen eines Produktlebenszyklusses kann Modellierung 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ändnisses im Team, hat jedoch den Nachteil, dass viele Potentiale der Modellierung ungenutzt bleiben. In traditionell 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 Entwicklungsumgebung derart integriert sind, dass Modell und Code zu jedem Zeitpunkt weiterentwickelt werden können und dabei automatisch konsistent zueinander bleiben.

Schulungen 2013

Termine to go

einfach aus de

r Heftmitte he

raustrennen

Juni 2013 bis August 2013 Certified Schulungen werden ausschließlich von akkreditierten Unternehmen durchgeführt. Das iSQI fungiert hier als Vermittler.

Anmeldeformular und Preise unter www.isqi.org.

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

Schulungstitel/Seminartitel

Ort

Agile Essentials

International Software Quality Institute

Datum (Start)

Dauer

Anbieter

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

AGILE ESSENTIALS

International Software Quality Institute

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

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ürich

06.-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

®

®

®

®

®

®

STAND: Juni 2013

ISTQB® CERTIFIED TESTER FOUNDATION LEVEL

ISTQB® Certified Tester - Foundation Level

Zürich

01.-02.07.13 + 4 Tage 08.-09.07.13

SynSpace AG

ISTQB® Certified Tester - Foundation Level - Kompaktkurs

Leipzig

08.07.13

3 Tage

Diaz & Hilterscheid Unternehmensberatung GmbH

ISTQB® Certified Tester - Foundation Level

Berlin

08.07.13

3 Tage

Loyal Team 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

Frankfurt

09.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

Frankfurt

06.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

Berlin

14.08.13

3 Tage

Loyal Team GmbH

ISTQB® Certified Tester - Foundation Level - Kompaktkurs

Karlsruhe

19.08.13

3 Tage

Diaz & Hilterscheid Unternehmensberatung GmbH

ISTQB® Certified Tester - Foundation Level

Basel

19.-20.08.13 + 4 Tage 26.-27.08.13

SynSpace AG

ISTQB® Certified Tester - Foundation Level

Frankfurt/Main

26.08.13

Diaz & Hilterscheid Unternehmensberatung GmbH

®

®

®

4 Tage

ISTQB® CERTIFIED TESTER ADVANCED LEVEL - TEST MANAGER ISTQB® Certified Tester - Advanced Level Test Manager

Basel

27.-28.05.13 + 5 Tage 03.-05.06.13

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

Bern

10.-11.06.13 + 4 Tage 17.-18.06.13

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

®

®

S O F T WA R E T E S T

PROJECTMANAGEMENT

SPI

SECURITY

MEDICAL

ANDERE

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

5 Tage

KUGLER MAAG CIE GmbH

INTACSTM – CERTIFIED ASSESSOR ISO/IEC 15504 Automotive SPICE® Training - iNTACS™ zertifizierter Provisional Assessor

Kornwestheim

03.06.13

Seminare 2013 Juni 2013 bis August 2013 Das iSQI fungiert hier als Vermittler.

Ausführliche Seminarbeschreibungen, Preise und Anmeldeformular: www.isqi.org

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

Seminartitel

Ort

International Software Quality Institute

Datum (Start)

Dauer

Anbieter

Wien

12.06.13

3 Tage

ANECON Software Design und Beratung GmbH

Hamburg

17.06.13

5 Tage

oose Innovative Informatik GmbH

Wien

17.06.13

1 Tag

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

Berlin

10.06.13

2 Tage

Avenqo GmbH

Kornwestheim

11.06.13

3 Tage

KUGLER MAAG CIE GmbH

Zürich

18.06.13

3 Tage

Anywhere. 24 GmbH

München

01.07.13

3 Tage

Anywhere. 24 GmbH

AGILE / SCRUM Agile Developer - Practitioner Agiles Software-Projektmanagement Agile Testing In A Nutshell

SCRUM

Quality Institute ANECON Software Design undInternational BeratungSoftware GmbH

CMMI Einführung in CMMI for Development V1.3 ®

Einführung in CMMI für Produktentwicklung (CMMI-DEV v1.3) Einführung in CMMI für Produktentwicklung (CMMI-DEV v1.3)

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

®

® ® ®

®

STAND: Juni 2013

TEST

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

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

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

TPI NEXT für Testmanager und Projektleiter ® ®

Unit Testing

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

Hamburg

24.06.13

5 Tage

oose Innovative Informatik GmbH

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

Berlin

13.06.13

2 Tage

QMETHODS - Business & IT Consulting GmbH

Java für Anwendungsentwickler Prozesse visualisieren und zum Leben erwecken - E-Learning

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

AGILE / SCRUM

TEST

S O F T WA R E A R C H I T E C T U R

A U TO M OT I V E

V-MODELL XT

UML

CMMI

ISO 26262

WEITERE SEMINARE

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

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

Alle Themen auch als Inhouse-Angebot buchbar!

iSQI GmbH | www.isqi.org Henkestr. 91, Haus 8, 3. OG 91052 Erlangen Tel +49 9131 91910-0 Fax +49 9131 91910-10

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

Ansprechpartner: Anett McAulay Trainings and Seminars Tel.: +49 331 231810-33 trainings@isqi.org

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

29

Impressum Im Fokus

Ausgabe 27 | Juni 2013

Überschrift

HERAUSGEBER ASQF e.V. Henkestraße 91, 91052 Erlangen Frank Simon Tel +49 9131 91910-0 Fax +49 9131 91910-10 info@asqf.de, www.asqf.de

SATZ / LAYOUT Frenkelson Werbeagentur, Potsdam www.frenkelson.de

-

FOTOS ASQF e.V. und iSQI GmbH Titelbild: © ollyy - Shutterstock.com

David-Gilly-Str. 1, 14469 Potsdam Tel +49 331 231810-0 Fax +49 331 231810-10 redaktion-sq@isqi.org, www.isqi.org

Alle Portraits und Grafiken mit freundlicher Genehmigung der Autoren.

REDAKTION V.i.S.d.P.: Stephan Goericke (Hauptgeschäftsführer) Redaktion: Felix Winter (Geschäftsführer) Isabel von Gustedt presse@asqf.de redaktion-sq@isqi.org

DRUCK PRINTEC OFFSET, Kassel DRUCKAUFLAGE 3.000 Stück

SQ-Magazin Nr. 28 erscheint im September 2013

INTERNETAUSGABE www.asqf.de/mitgliedermagazin-sq-magazin.html MEDIADATEN Gern senden wir Ihnen unsere Mediadaten zu. Richten Sie Ihre Anfrage an redaktion-sq@isqi.org. Weitergabe und Vervielfältigung, auch auszugsweise, ist unter vollständiger Angabe der Quelle erlaubt.

Haben Sie Anregungen zu den Inhalten des SQ-Magazins, dann schreiben Sie an: presse@asqf.de oder redaktion-sq@isqi.org 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 eingereichter Manuskripte vor. Wir machen darauf aufmerksam, dass Daten nicht an Dritte weitergegeben und ausschließlich zur internen Auswertung herangezogen werden können.

Thema: Softskills Anzeigenschluss: 17.07.2013 Druckunterlagenschluss: 24.07.2013 Anzeige

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

Beratung zu agiler Entwicklung nach ISO 26262 Unterstützung von agilen Methoden in der Medizintechnik SPICE konforme Migration von Projekten Schulung zum Certified Agile Tester ® www.methodpark.de

Standard NEWS

Ausgabe 27 | Juni 2013

30

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.

Doch zurück zu den Anfängen. 2010 hat sich eine Gruppe überzeugter Verfechter des modellbasierten Testens zusammen gefunden und im Rahmen des ASQF die „Special Interest Group MBT“ (SIG MBT) gegründet. Erklärtes Ziel dieser Interessensgemeinschaft ist es, den industriellen Einsatz der Methode zu fördern. Dazu muss jedoch erst einmal ein einheitliches Verständnis geschaffen werden, was modellbasiertes Testen überhaupt ist.

Wir haben es hier mit einer neuen, aufstrebenden Technologie zu tun. Doch wie so oft, wenn sich etwas ändern soll, beobachten wir Ressentiments. Dem modellbasierten 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 vertretbarem 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ärken des modellbasierten Testens.

Schließlich starten wir ja nicht von der grünen Wiese.

In den letzten Jahren haben sich durchaus Quasi-Standards 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 Gemeinsamkeiten und Unterschiede liegen, ist schon ein erster Schritt zum Ziel. Nur wer ein klares und strukturiertes Verständnis der Grundlagen und Konzepte des modellbasierten Testens besitzt, kann von den enormen Vorteilen der Methodik bezüglich Verbesserung der Wirtschaftlichkeit 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 kommunizieren zu können. Hinsichtlich einer Taxonomie haben [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 endet 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 International Software Quality Institute iSQI ® bietet interessierten Trainingsanbietern die Möglichkeit, eine CMBT Train-theTrainer-Schulung zu absolvieren und lizensiert die Verwendungsrechte an den Unterlagen. Dadurch wird der Akkreditierungsprozess vereinfacht. Die Kosten einer Akkreditierung werden nicht im Voraus fällig, sondern richten sich nach dem individuellen Trainingsvolumen des Anbieters.

Inhaltlich gliedert sich der CMBT in vier Module auf: 1. Grundlagen des modellbasierten Testens 2. Modelle in der Entwicklung 3. Testmodelle 4. 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 Schulungsteilnehmer 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 Testfallexplosion in den Griff bekommen können. Dadurch

31

Standard NEWS

Ausgabe 27 | Juni 2013

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

Dr. Anne Kramer ist seit 2001 Projektleiterin, Prozessberaterin und Trainerin für die sepp.med GmbH.

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

INTERESSIERT? WEITERE INFORMATIONEN UNTER model-based.isqi.org

Dr. Armin Metzger ist als Abteilungsleiter bei sepp.med GmbH verantwortlich für IT-Multiprojekte in komplexen und sicherheitskritischen Branchen.

R E F E R E N Z E N [ETSI2011] ETSI ES 202 951 V1.1.1 (2011-07), “Requirements for Modeling Notations”, 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: OBJEKTSpektrum 3/07, 2007, 39-45 [Utt2011] M. Utting, A. Pretschner, B. Legeard, “A taxonomy of model-based testing approaches”, in: Software Testing, Verification and Reliability, John Wiley & Sons, Ltd., 2011.

Anzeige

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

Zertifizierung

Zürich

Keynotes

Ausstellung

agil

Compliance

Outsourcing

Offshoring

interaktiv

Tools

Ideen

Programmkomitee

Testmanagement

Prozessmodelle

Recruiting

Qualitätssicherung

Lasttest

Workshops

Podiumsdiskussion

www.iqnite-conferences.com/ch

Performance

Services

Metriken

ISTQB

Networking innovativ

Q es S SQ15 ser d ode: CH .) e L r fü 15.8 onsc Akti ültig bis (G

Quality Spotlights

Standards

Testautomation interdisziplinär inspirierend Managed Services Security praxisrelevant

Erfahrungsaustausch

interaktiv

Mobile Computing

Qualitätsmanagement

Homeshoring

informativ

Nearshoring

Best Practice

Cloud

Erfahrungsberichte

Ausbildung

Impulse

Methoden

Requirements unabhängig fokussiert

Prozesse

15

t abaagtazins R % -M

Trends

etabliert

„ More for Less – Maximale Ergebnisse mit geringstem Einsatz “

Business-Solutions

Vielfalt unter dem Konferenzmotto

Risk Management

24. September 2013 | Zürich, Schweiz

Im Fokus

Ausgabe 27 | Juni 2013

32

Traditionell cum Agil Am Beispiel Test-Driven Development Karin Vosseberg & Andreas Spillner Bewährtes erhalten und mit Neuem verbinden In den zurückliegenden Jahrzehnten wurden viele Methoden, Vorgehensmodelle und auch Praktiken propagiert, mit deren Hilfe sich die Entwicklung von Softwaresystemen als einfach und im Vergleich zu vorher qualitätsverbessernd 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 Beispiel Test-Driven Development zeigen, wie ein Umstieg unter 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 gesehen, sondern von Beginn an in die Iterationen agiler Projekte 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].

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 ausgeklammert 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 Akzeptanztests 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 Integration das direkte Einsatzumfeld einer Komponente und die Schnittstellen zwischen Komponenten untersuchen. Darüber hinaus gibt es Fehler, die nur beim Integrationstest aufgedeckt werden können [Win12]. Jede Teststufe benötigt somit ihre eigenen Testfälle.

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 Kommunikation 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 Softwareentwicklung« 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 folgenden näher erläutert werden.

Abb. 1: Testgetriebenes Vorgehen ([Amb])

Von beispielgetrieben zu testgetriebenen Im Kontext der Diskussion testgetriebener Softwareentwicklung spielen Testentwurfsverfahen eine untergeordnete Rolle. Vordergründig wird eher die Testautomatisie-

33

Traditionell vs. Agil

Ausgabe 27 | Juni 2013

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 systematischer Ansatz zur Testfallermittlung.

Prof. Dr. Karin Vosseberg ist Hochschullehrerin an der Hochschule Bremerhaven mit den Schwerpunkten Systemintegration und Qualitätssicherung.

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].

Prof. Dr. Andreas Spillner ist Hochschullehrer für Software Engineering und Qualitätssicherung an der Hochschule Bremen. Er ist Mitglied im ASQFBeirat, war Gründungsmitglied und ist nun Ehrenmitglied des German Testing Boards.

Bereits beim Komponententest sind geeignete Teststrategien zu entwickeln, die mit den Iterationen der Softwareentwicklung fortgeschrieben werden. In Anlehnung an die Ablaufbeschreibung 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älle werden zu den bisherigen Testfällen hinzugefügt und



Im Fokus

Ausgabe 27 | Juni 2013

34

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 Implementierung 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« Funktionalität ist bereits implementiert.

Die Funktionalität wird programmiert und die Testsuite erneut ausgeführt. Das Programmstück wird solange korrigiert, 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/Funktion 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 entwickelt, 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 Anforderungen einer Iteration im Projekt anzupassen, um nicht wieder in starre Verhaltensmuster traditioneller Vorgehensmodelle zu verfallen.

Der beschriebene Ansatz ist über die Entwicklung der Komponenten hinaus auf die gesamte Systementwicklung anzuwenden. 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 Testprozesses [Spi12]. Um die Akzeptanz des generischen ISTQBⓇ Testprozesses in der agilen Welt der Entwickler zu etablieren, 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 Aktivitäten.

Abb. 3: Integration der Testprozessaktivitäten

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 bekommen. Dies verdeutlicht den Mehrwert testgetriebener Softwareentwicklung 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ätssicherung erweitert werden können. Dies wird dazu beitragen die Kluft zwischen Entwicklern und Testern weiter abzubauen 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 Komponenten- und Systemintegration, Hanser Verlag, 2012

SAG WAS

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

Studentische AusbildunG und berufliche Weiterbildung in Agiler Softwareentwicklung

WORKSHOP WÄHREND DER GI-JAHRESTAGUNG AM 19. SEPTEMBER 2013 ANSPRECHPARTNER: Prof. Dr. Andreas Spillner, Hochschule Bremen, andreas.spillner@hs-bremen.de

Dr. Michael Mlynarski, QualityMinds GmbH, michael.mlynarski@qualityminds.de

Prof. Dr. Karin Vosseberg, Hochschule Bremerhaven, karin.vosseberg@hs-bremerhaven.de

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

35

Ausgabe 27 | Juni 2013

Interview mit Horst Pohlmann Sie wurden kürzlich zum Vorsitzenden des German Testing Boards (GTB e.V.) gewählt. Zunächst unseren herzlichen Glückwunsch dazu. Können Sie kurz unseren Lesern erklären, was das GTB ist und was es für Aufgaben wahrnimmt?

Danke.

Das German Testing Board ist bekanntermaßen ein Zusammenschluss von Fachexperten auf dem Gebiet „Test von Software und softwarebasierten Systemen“. In Deutschland verantwortet das GTB als Gründungsmitglied des International Software Testing Qualifications Boards (ISTQB) das Certified-Tester- Schema zur Qualifizierung und Prüfung von Software-Testern. Das GTB kümmert sich um die Weiterentwicklung 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 Erfolgsgeheimnis?

Einer der Erfolgsfaktoren ist sicherlich, dass durch die persönlichen Mitglieder des GTB die Bereiche Industrie, Trainingsanbieter und Hochschulen gleichermaßen repräsentiert 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 Internationalisierung weltweit gestellt haben.

Stellen Sie sich vor, Sie arbeiten heute in einem Automotive Projekt zur Entwicklung eines Steuergerätes. In einem solchen 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 notwendig, dass alle Beteiligten die gleiche Sprache sprechen und die gleiche Methoden und Verfahren mindestens bis zu einer gewissen Ebene beherrschen.

Des Weiteren haben wir durch die Umsetzung einer qualitätsorientierten Wachstumsstrategie eine hohe Marktakzeptanz 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.

Im Gespräch Horst Pohlmann ist Leiter Prozesse, Methoden und Tools bei Lemförder Electronic. Seit 2010 ist er Lehrbeauftragter für Software Qualitätsmanagement an der Hochschule Ostwestfalen-Lippe.

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

Ich war stellvertretender Vorsitzender des GTB seit diese Rolle in 2004 geschaffen wurde. Ich werde nun als Vorsitzender nicht alles anders machen, sondern den Spagat versuchen, 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 unseren Partnern den Zertifizierungsstellen und der Technical Advisory Group (TAG) in Vorbereitung bzw. auf den Weg gebracht haben. Dabei setzen wir auf unsere Grundprinzipien wie Neutralität, Fairness, Offenheit und Transparenz. Ebenso pflegen wir weiterhin klare und regelmäßige Kommunikation mit unseren Partnern: der Industrie, den Trainingsanbietern 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 NichtMitglieder 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 gemeinsame Geschichte zurück und haben die gleichen Wurzeln. Welche Bedeutung messen Sie als GTB-Vorsitzender 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 softwarebasierten Systemen kümmert, deckt der ASQF ein viel breiteres Spektrum mit all seinen Facetten ab. Ich sehe den ASQF deshalb als eine komplementäre Ergänzung und einen Partner des GTB. Das Interview mit dem neuen Präsidenten des GTB führte Stephan Goericke

Im Fokus

Ausgabe 27 | Juni 2013

36

Die Rolle des agilen Testers im Kampf gegen technische Schulden Harry M. Sneed & Richard Seidl Als Teil eines agilen Entwicklungsteams haben Tester eine besondere Verantwortung. Sie müssen unter anderem verhindern, dass die technischen Schulden (Technical Debt) ausufern.

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

Technical Debt

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

„Technical Debt“ ist ein Begriff für mangelhafte Software.

Er soll die Problematik unzulänglicher Softwarequalität in betriebswirtschaftlichen Kategorien zum Ausdruck bringen [1]. Managern soll damit gezeigt werden, dass Versä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 ausgedrü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 Mitarbeiter der CAST Software Limited in Texas vorgeschlagen.

Diese Formel verbindet Problemarten mit Aufwand und Aufwand mit Geld. Die Basisformel ist eine Erfahrungsdatenbank zahlreicher Projekte, aus der der mittlere Aufwand zur Beseitigung von Softwaremängeln hervorgeht [3]. Das Refactoring 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 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 auftreten. 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 Ausgaben, z.B. falsch berechnete Beträge und verschobene Texte, sowie Fehler in der Eingabeprüfung. Hinzu kommen 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 behoben 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-

37

Ausgabe 27 | Juni 2013

Traditionell vs. Agil

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 sichern die Qualität des Produktes während seiner Entstehung 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 Integrationstest [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 unzureichend erklären. Die Tester sollen ihn darauf aufmerksam 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 Konformität mit den Codierregeln, die Einhaltung der Architekturrichtlinien 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überdeckung 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 immer rasch Feedback geben zu können [6]. „Continuous Integration“ macht dies möglich [7]. Der Tester hat einen Integrationstestrahmen, in den er die neuen Komponenten hineinsteckt. Die bisherigen Komponenten sind bereits vorhanden. Sie werden täglich mit den neuen ergänzt. Natürlich spielt hier die Testautomation eine entscheidende Rolle. Mit den Testwerkzeugen ist es möglich, den Regressionstest täglich zu wiederholen und dabei auch noch den Funktionstest der neuesten Komponenten zu fahren. Probleme, die auftreten, können dann sofort an die Entwickler 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 Entwicklerstunden verloren. 

Harry M. Sneed ist Tester und Berater der ANECON GmbH. Zudem unterrichtet er Softwareentwicklung an der Universität von Regensburg 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-, Firmund Hardware verantwortlich.

Im Fokus 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önnen die Tester nicht den von ihnen erwarteten Nutzen erbringen, 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 schnelle 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 Entwicklern 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 eingegangen. 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 vorantreiben. 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 erforderlich, 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 verschiebt 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 Fortschrittsbretter, eins für den Funktionenstand und eins für den Qualitätsstand.

Der funktionale Stand eines Software-Produktes ist leichter 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

Ausgabe 27 | Juni 2013

38

Funktionen der Software getestet hat. Wie gut der Code ist, kann man erst beurteilen, wenn man den Code ausführlich 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 funktionalen 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 abstimmen. 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 funktionale Fortschritt darf nicht auf Kosten der Softwarequalitä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 nachgebessert werden. Wenn sie allzu schlecht ist, muss das nächste Release ein Überarbeitungs-Release sein, bei dem die Fehler entfernt werden und die Software refaktoriert wird. Crispin räumt sogar ein separates Qualitätssicherungs-Team ein, welches neben dem Entwicklungsteam 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 mitbestimmen, was „done“ bedeutet, und das vom Anfang des Projektes 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 beitragen. „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 commitment 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 eingegrenzt und abgebaut werden.

L I T E R AT U R H I N W E I S E [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] Duvall, 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

39

Umfrage

Ausgabe 27 | Juni 2013

ASQF-Umfrage 2013: IT-Branche bleibt zuversichtlich

Bücher für Tester und Testmanager Stephan Grünfelder

Software-Test für Embedded Systems 2013, 390 Seiten E 42,90 (D) ISBN 978-3-86490-048-8

Welche Art von Weiterbildung bevorzugen Sie?

NEU

Basiswissen Softwaretest Sonstiges

E-Learning

ASQF-Fachgruppentreffen / ASQF Days

0

Andreas Spillner, Tilo Linz Fachkonferenz (über 1 Tag)

20

Seminar (2-3 Tage)

40

Workshop / Tutorial (1 Tag)

60

Seminar (über 3 Tage)

80

ASQF-Mitglieder, Partner und Kunden des iSQI waren von März bis Mai aufgerufen, 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 deutschsprachigen IT-Landschaft und zur wirtschaftlichen Leistungsfähigkeit abgegeben.

Wie auch im Vorjahr zeigt sich die IT-Branche und die Software-Qualitätsbranche im speziellen wieder sehr optimistisch. Über 70% empfinden die aktuelle gesamtwirtschaftliche Lage als gut bis sehr gut und halten diese auch für stabil, sodass über ¾ auch in 2014 mit einem gesamtwirtschaftlichen Wachstum rechnen. Nahezu identisch positiv sieht die Einschätzung bei der eigenen, aktuellen Lage und zukünftigen Entwicklung aus. Das wirkt sich auch auf die Investitionen 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 konsequente Aus- und Weiterbildung der vorhandenen Mitarbeiter. Fast 40% verstä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 externe 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 zunehmenden technischen Möglichkeiten von nicht einmal 1/3 der Befragten angenommen. Gegenüber 2012 eine Verschlechterung um ca. 4%.

Der ASQF bedankt sich bei den Teilnehmern der Umfrage. Alle Ergebnisse können grafisch aufbereitet unter www.asqf.de/mitglieder-umfragen.html abgerufen werden.

5. Auflage 2012, 312 Seiten E 39,90 (D) ISBN 978-3-86490-024-2

Tilo Linz

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

Markus Gärtner

ATDD in der Praxis 2013, 224 Seiten E 32,90 (D) ISBN 978-3-86490-046-4

Heinz Hellerer

Soft Skills für Softwaretester und Testmanager 2013, 184 Seiten E 29,90 (D) ISBN 978-3-89864-831-8

Ringstraße 19 B · D-69115 Heidelberg fon: 0 62 21 / 14 83 40 · fax: 14 83 99 e-mail: bestellung@dpunkt.de

www.dpunkt.de

Gastkommentar

Ausgabe 27 | Juni 2013

40

ISTQB® Partner Program – Appreciating Scheme Adaptors Alon Linetzki,

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

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 budget 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 certification exams on the different certification scheme levels, and would like to get acknowledged for doing so. It is in the ISTQB® 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 system, 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 accumulation 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 level 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-

41

Ausgabe 27 | Juni 2013

Gastkommentar

on of the investments made in the certification of testing resources; - Specific RECOGNITION letter, indicating identity/location, validity and level; - Listing of the partner company in ISTQB® worldwide WEBSITE; - Access to ISTQB® ‘Conference Network’ events at special conditions (depending on local considerations); - Ability to receive new Syllabi in Alpha Versions of ISTQB® published certifications with the opportunity to contribute 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 Member 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 enhance our commitment to the market with new certification schemes. A new certification add-on to Foundation, is being planned today: ‘Agile Testing’, which involves many professionals worldwide contributing to the content. Partners 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 – success 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 PROVIDERS.

Die Mitgliedschaft im ISTQB® Partner Programm können interessierte Unternehmen einfach und unkompliziert über das iSQI beantragen. Bei Interesse wenden Sie sich bitte an: jan.schubert@isqi.org

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 Certification 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 president.

Im Fokus

Ausgabe 27 | Juni 2013

42

Kundenanforderungen erfassen und mit den richtigen Werkzeugen in ausführbare Tests umwandeln Christian Wende, Mirko Seifert und Florian Heidenreich Acceptance Test-Driven Development verbindet die Lesbarkeit natürlichsprachlicher Spezifikationen mit der Automatisierbarkeit formaler Tests. Automatisiertes Testen ist inzwischen ein fester Bestandteil jedes qualitätsorientierten Entwicklungsprozesses. Entwickler erstellen automatisierte 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, Anforderungen aber normalerweise natürlichsprachlich erfasst werden ergibt sich zwangsläufig eine Lücke zwischen den eigentlichen Anforderungen und dem Testcode, der die Anforderungen prüft. Acceptance Test-Driven Development (ATDD) schließt diese Lücke, indem natürlichsprachliche Anforderungen automatisiert in ausführbare Testspezifikationen übersetzt werden. Im vorliegenden Artikel werden die grundlegenden Prinzipien von ATDD eingeführt, sowie einige 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 bestimmte 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 ausgestellt 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 hinterfragen warum wir Anwendungen testen und woher die eigentlichen Inhalte für Tests stammen: Man nutzt Tests, um sicher zu stellen, dass alle Kundenanforderungen vollständig und erwartungskonform von der implementierenden Anwendung umgesetzt werden. Eine ideale Grundlage für Testfälle und Testdaten stellen daher die fachlichen Anforderungen 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, Fachexperten, Programmierer und Tester) näher zusammen zu bringen. Der Austausch über die Anforderungen soll intensiviert 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 illustrieren. 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 einfach zu einer umfassenden Menge von Szenarien, die alle relevanten Anwendungsfunktionen inklusive der verschiedenen Verhaltenspfade abdecken.

Zugunsten einer verständlichen und klaren Kommunikation ist natürliche Sprache das Mittel der Wahl zur Dokumentation 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 lauten: „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 Szenarienkatalog das zentrale Medium zur interdisziplinären Kommunikation und Dokumentation von Anforderungen, DesignEntscheidungen und Anpassungswünschen.

Im Vergleich zu klassischen Werkzeugen zur Anforderungsanalyse dient der erfasste Szenarienkatalog nicht ausschließlich der Kommunikation zwischen den verschiedenen Parteien. Bei ATDD geht es darum Anforderungen so zu erfassen, dass diese später direkt für die Qualitätssicherung, d.h. den Test der Anwendung, genutzt werden können. Genau hier setzen ATDD Werkzeuge an. Sie erlauben es, die natürlichsprachlichen Szenariobeschreibungen automatisiert auszuführen und so direkt zur Qualitätssicherung einzusetzen. Mit Hilfe von Übersetzungsmustern werden einzelne Sätze der Szenarioberschreibung durch den Tester auf den ausführbaren Testcode abgebildet. Ein Übersetzungsmuster verbindet dabei die Testspezifikation mit dem zugehörigen Testcode. Beispielsweise kann folgendes Muster definiert werden, um die oben aufgeführte Testspezifikation 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-

43

Ausgabe 27 | Juni 2013

Traditionell vs. Agil

onen durch beliebige Werte ersetzt werden. Dadurch wird es möglich mit einem Muster mehrere Szenariobeschreibungen 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 Systemteilen 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üsselworte 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 Übersetzungsmuster 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ürlichsprachlich 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 Szenarien in NatSpec keiner vorgegebenen Grundstruktur folgen - vom Werkzeug selbst werden weder feste Schlüsselworte 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.

Fazit Acceptance Test-Driven Development beschreibt einen pragmatischen Ansatz, um die Spezifikation von Anforderungen verständlicher und wartbarer zu gestalten und gleichzeitig ausführbare Tests zu erhalten. Durch die Nutzung 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 Kundenanforderungen zielgerichtet und punktgenau umzusetzen.

Dr. Christian Wende

Florian Heidenreich

Dr. Mirko Seifert Die Autoren entwickeln neben NatSpec die OpenSource-Tools EMFText, JaMoPP, JUnitLoop und HEDL. Ihr Unternehmen, die DevBoost GmbH, bietet Werkzeuge zur Effizienz- und Qualitätssteigerung in der Softwareentwicklung und unterstützt nationale und internationale Partner beim Einsatz innovativer Qualitätssicherungsmaßnahmen.

L I N K S & L I T E R AT U R [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

Im Fokus

Ausgabe 27 | Juni 2013

44

SCRUM: Untergang der Test Center?

Klaus Haller Inhaltliche Strukturierung Typ

Temporale Ordnung

Validiert… / Testaspekt

Unit Test

Module, Klassen etc.

Unit Integration Tests

Zusammenspiel von Modulen etc.

System Tests

Ganzes System

System Integration Tests

System mit Umsystemen

User Acceptance Tests

Anforderungen

V-Modell

Scrum

1 2 3 4 5

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

Tester haben das V-Modell mit seinen Teststufen verinnerlicht. Sie reagieren verunsichert, wenn neu agil Software entwickelt wird. Das V-Modell sammelt am Projektbeginn alle Anforderungen – vollständig und abschliessend. Die Software wird entwickelt, durchgetestet und danach dem Kunden ü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. Agile 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 diskutiert 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 Umsetzung das Testen mit den Phasen Unit Test, Unit Integration Test, System Test, System Integration Test und User Acceptance 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 Entwicklungsteam wählt am Anfang eines Sprints die User Stories (Aufgabenpakete) aus, die es in dem Sprint umsetzt.

Am Ende des Sprints sind diese User Stories nicht nur implementiert, sondern vollständig getestet und auslieferbereit. Scrum kennt keine nachgelagerten Testphasen mehr.

Das erfordert eine Neuinterpretation der Testphasen. Aus

Testphasen werden Testaspekte. Scrum braucht alle Testaspekte 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 Abbildung 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 Ordnung, 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 Testaspekte wichtig. Doch viele Tester in Deutschland, Österreich und der Schweiz arbeiten in einem anderen Umfeld. Kundenunternehmen 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 Reputationsrisiken, 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-Systemen notwendig. Ziel ist nicht, die Softwarequalität zu verbessern. Das ist die Aufgabe des Softwarelieferanten. Ziel ist eine Abnahme oder Rückweisung einer konkreten Softwareinstallation.

Wie wirkt sich die neue Welt des Testens auf die Testorganisation in Firmen aus? Softwarelieferant und Kunden-IT

45

Ausgabe 27 | Juni 2013

haben, wie oben beschrieben, andere Bedürfnisse beim Testen. 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 Softwarelieferanten geht es um „move quality upstream“ [4]. Dafür werden die Tester in Scrum-Teams integriert und eingebettet. Organisatorisch können die Tester aus einem zentralen TesterPool 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 überwachen. 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 komplizierter. 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, sondern 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-Projekte 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 Center 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 Reorganisation 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 Softwareentwicklung kompetente Tester. Scrum mag bessere Qualitä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 L I T E R AT U R V E R Z E I C H N I S [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

Traditionell vs. Agil

Klaus Haller arbeit als Expert im Test-Consulting bei Swisscom IT Services in Zürich. Seine Schwerpunkte sind (Test-)Organisation und Prozesse, Testdatenmanagement, Compliance Testing und IT Risk/DLP.

Im Fokus

Ausgabe 27 | Juni 2013

46

Testen mobiler Apps: ein Paradebeispiel für agiles Vorgehen Sven Euteneuer Mobile Apps verändern In der letzten Zeit ist ein Paradigmenwechsel am IT-Markt zu beobachten. Aktuelle Studien zeigen, dass eine Abkehr 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 durchdringen den privaten und beruflichen Alltag und werden zum Innovationstreiber der Informations- und Kommunikationstechnologie (IKT). Eine Folge der stärkeren Verbreitung 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 AppStores. 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 gleichermaßen eine Anpassung der Art und Weise, wie Software für sie entwickelt wird. Indiz hierfür ist, dass mobile Anwendungen nicht als Anwendungen, Programme oder Software bezeichnet werden, sondern als Apps – ein Begriff, der bereits darauf hindeutet, dass sich mobile Software 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 Rechen- oder Speicherkapazität, Unterschiede in der Be-

nutzerschnittstelle oder Einflussfaktoren wie wechselnde 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 verteilen, 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äufig das Problem, dass mit der Anzahl der Vertriebskanäle (z.B. PC vs. Web vs. Mobile vs. TV), Plattformen (z.B. Android, 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 wechseln mit noch größerer Volatilität und die Hürden für Mitbewerber 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 erforderlich.

Agilität als Problemlöser In diesem Kontext erscheinen traditionelle, phasengetriebene Vorgehensmodelle (vgl. Abbildung 1) als Anachronismus, der mit seinen Formalismen, früh festgeschriebenen Anforderungen und erst am Projektende verfügbaren Produkten ungeeignet ist, erfolgreich Produkte zu entwi-

INITIALISIERUNG ANFORDERUNG DESIGN UMSETZUNG TEST LAUNCH

Abbildung 1: Phasengetriebenes Vorgehensmodell

47

Ausgabe 27 | Juni 2013

Traditionell vs. Agil

ckeln. Gleichzeitig klingen die oben beschriebenen Herausforderungen, 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 funktionierender 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 mobile 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 spezifischer 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 Treiber 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ßereignisse 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 mobilen Plattformen mitbestimmt. Anders als auf dem PC erscheinen neue Geräte – und damit Hardware-Innovationen – im Rhythmus eines Quartals. Dazu werden mobile Plattformen wie Android, iOS und Windows Phone mehrmals 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 Anforderungen. Der Einsatz iterativ-inkrementeller Vorgehensmodelle 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 Computing und IT Security.

Im Fokus

Ausgabe 27 | Juni 2013

INITIALISIERUNG

ANFORDERUNG

48

ANFORDERUNG

TEST

TEST

DESIGN

DESIGN ANFORDERUNG

LAUNCH

ANFORDERUNG

LAUNCH

Abbildung 3: Agiles Vorgehen

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

Überschaubarkeit von Aktion und Reaktion Außerdem haben iterative Vorgehensmodelle den Vorteil, dass komplexe Aufgabenstellungen notwendigerweise in überschaubare Implementierungs-Teilpakete heruntergebrochen 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 Planen, Entwickeln, Testen und Reviewen erzeugt kontinuierlich 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 geringeren Aufwand für Fehler- & CR-Handling sowie aus verkürzten Release-Zyklen. Das agile Vorgehen vermeidet langwierige Abstimmungs- und Freigabeprozesse in frühen Projektphasen. Dazu kommt, dass Kosten generierende 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 sollen im Folgenden erläutert werden:

Mehr Test im agilen Mobile App Entwicklungsteam Die Rolle des Testers gibt es beispielsweise nach der „reinen“ SCRUM-Methodik gar nicht. Im SCRUM-Modus sind

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ätseigenschaften zu (z.B. für Sicherheit, Zuverlässigkeit oder Gebrauchstauglichkeit) und die Komplexität der benötigten Infrastruktur erhöht sich. Es muss also eine Vielzahl – möglicherweise neuer – Testtechniken systematisch geplant und durchgeführt werden.

Daher ist die Etablierung von Sprint-Testern unabdingbar. Sie müssen die marktüblichen Teststandards, wie sie z.B. im ISTQB festgeschrieben sind, sicher beherrschen. 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 Automatisierung 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 Funktionalität zur Verfügung, sind aber immer häufiger Teil einer komplexen Architektur, welche diverse Backendsysteme, Server, Web Services oder Cloud-Dienste nutzt und orchestriert.

Diese Integration erzwingt planerische Weitsicht, die insbesondere die Testplanung und das Release-Management betrifft. Abhängigkeiten müssen bei der Planung genauso berücksichtigt werden wie andere Vorgehensmodelle. So werden Legacy-Dienste häufig eben nicht agil weiterentwickelt.

Gerade weil eine vielgestaltige Integration in SCRUM zunächst nicht vorgesehen ist, muss die Sprint-Planung um die o.g. Aspekte erweitert werden. Ein kompletter Entwicklungs-Lifecycle kann sich dann über ein bis zwei Jahre mit einer Reihe von Release-Zyklen hinziehen. Jedes

49

Traditionell vs. Agil

Ausgabe 27 | Juni 2013

Release setzt sich dann wiederum aus einer Anzahl von Sprints und einer komplexen Integration (oder ReleaseTest) 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 Zielkanälen, -plattformen, und -geräten ergibt sich für den Tester eine gefährliche kombinatorische Explosion bezüglich Testfällen und Testumgebungen. Neben methodischen Erweiterungen des risikobasierten Testens bietet der Tooleinsatz die Möglichkeit, möglichst viele relevante Plattformen ausreichend mit Tests abzudecken. Dies widerspricht 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 Effizienzverluste ergeben. Gerade in einem so jungen Markt wie den mobilen Apps sollten diese Tools jedoch sorgfältig ausgewählt werden, da es große Unterschiede in Bezug auf Aspekte wie Funktionalität oder Plattformunterstützung gibt.

Fazit Agilität ist das präferierte Vorgehensmodell für die AppEntwicklung – doch erfordert die Umsetzung eine mehrschichtige 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 verstärkten Tooleinsatz als Mittel zur Verbesserung von Testeffektivität und -effizienz auf vielfältigen Plattformen und Geräten.

L I T E R AT U R 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

Anzeige

CMBT - iSQI® Certified Model Based Tester

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

Termine: Do 20.06.2013 Mo 22.07.2013 Do 08.08.2013 Di 10.09.2013

-

Fr Di Fr Mi

21.06.2013 23.07.2013 09.08.2013 11.09.2013

Nürnberg Nürnberg Potsdam Röttenbach

Weitere Termine auf Anfrage.

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

sepp.med gmbh

Gewerbering 9 D-91341 Röttenbach

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

Potsdamer Platz 11 D-10785 Berlin

13 .20 7 .

8 zum 20%! s i b ie Sie ren S n che spa Bu und Fon +49 (0) 30 2589-5042 Fax +49 (0) 91 95-931-300

www.seppmed.de info@seppmed.de

Mitglieder

Ausgabe 27 | Juni 2013

50

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

Auf seiner ordentlichen Mitgliederversammlung am 07. Mai 2013 in Erlangen hat der ASQF ein neues Präsidium gewä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-Qualität im deutschsprachigen Raum ist Prof. Dr. Joachim Hornegger, 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.

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 Fachverbands 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.“

Das neue Präsidium mit der ASQF-Geschäftsführung (vlnr.): Stephan Goericke, Joachim Hornegger, Rudolf van Megen, Norbert Kastner, Norbert Bochynek und Felix Winter.

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 sicherstellen, dass die gesetzten Ziele und die Position des Vereins als Sprachrohr der Wirtschaft in allen Belangen von Software-Qualität nachhaltig weiterentwickelt werden. Dies betrifft Aspekte der Fortbildung genauso, wie die Verbesserung 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.

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

Auf der Mitgliederversammlung wurde auch über eine neuerliche Satzungsänderung entschieden. Einstimmig nahmen die anwesenden Mitglieder den Vorschlag zur Satzungsä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

51

Quiz

Ausgabe 27 | Juni 2013

Sudoku

8

4

9

2 5

7

1

9

5

5

7

2

9 7

5

1

8

8

1

7

9

8

2

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

2 4

9

3

1

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

Gerade von den agilen Verfahren zur Softwareentwicklung können wir lernen, wie eine bedarfsgerechte „Dokumentation in agilen 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 presse@asqf.de.

*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 ausgeschlossen. Teilnehmer erklären sich mit der Veröffentlichung Ihres Namens in der Folgeausgabe einverstanden.

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

März 2013 26 | Software-Qualität Arbeitskreis Ausgabe e.V. und -Fortbildung

Im Gespräch Yaron Tsubery Präsident des ISTQB Seite 8

Blickwinkel ISTQB® New 2012 Advanced Level Syllabus im Detail Seite 14

Statement Rudolf van Megen „Qualität hat ihren Preis“ Seite 40

ADVANCED

TESTING Testen für Profis

Gewinner SQ-Magazin Nr. 26 „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 „Testen 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

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

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 genutzten 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

empfiehlt „dilbert“zur leichteren Alltagsbewältigung

Fachgruppentermine: Juni - Juli 2013 04.06.2013 FG Software-Test, Sachsen, Dresden

Thomas Haase

JUNI 2013

Organisation von Penetrationstest inkl. Live-Hacking: Gefahren, Bedrohungen und wie man sich schützen kann.

KW

Mo

Di

Mi

Do

Fr

22

04.06.2013 FG Automotive NRW, Köln

Mark Brörkens

What is the impact? Adding Traceability to your development tool chain

04.06.2013 FG Software-Test, München

Dr. Uwe Hehn

ISTQB® Certified Tester: Der neue Advanced Level Lehrplan 2012 - Update oder Upgrade?

06.06.2013 FG Requirements Engineering Franken

Sa

So

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

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

Marta Bednarczyk

„RE & Scrum - Product Backlog - System-Spezifikation“

11.06.2013: FG Software-Test, Franken

Ewa Sadowicz und Heribert Jenus

JULI 2013

JUNI

Kommunikation im Projekt - Teamentwicklung und wirksame Kommunikation

11.06.2013 FG Software-Test, Österreich, Wien

Dr. Stephan Grünfelder

Software-Test für Embedded Systems: Ein Einblick in nicht-alltägliche Testtechniken

13.06.2013 FG Automatisierung, Franken

Dr. Markus Schleicher

Von der Idee zum Interaktionsdesign

13.06.2013 FG Software-Test, Berlin

Jürgen Großmann

Risikobasierter IT-Sicherheitstests in Forschung und Standardisierung

19.06.2013 7. RHEIN-MAIN TESTING DAY

Ganztagesveranstaltung

Thema: Open Space - „Aus der Praxis für die Praxis“

20.06.2013 4. MEDICAL DEVICE DAY Franken

Ganztagesveranstaltung

Thema: Klinische Bewertungen und Validierung von Software

20.06.2013 FG Software-Test, BW Vorankündigung

24.06.2013 FG Projektmanagement, Franken

Sebastian Krieger

Balanced Scorecard als Instrument zur Analyse der Softskills im PM

10.07.2013 22. Automation Day, Franken

Ganztagesveranstaltung

JULI

Thema: Web-Technologien in der Automatisierung

16.07.2013 FG Requirements Engineering Franken Vorankündigung

17.07.2013 FG Requirements Engineering Bayern-Süd, München Vorankündigung

23.07.2013 FG Software-Test, Franken

Ewa Sadowicz und Heribert Jenus

Lead+Relax - Wie wir uns durch einfache, aber gezielte Übungen in unserer Kommunikation Anzeige_OBJEKTspektrum_210x148mm_RZ_2013_02_14.pdf

1

14.02.13

10:39

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

ISTQB® Certified Tester

Über 265.000 Certified 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® Certified 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 Begrifflichkeiten 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® Certified Tester ermöglicht Tester-Karrieren die Schulungen bieten damit erstmals ein internationales und branchenübergreifendes Berufsprofil für Software-Tester, jeweils mit individuellen Schwerpunkten.

Der ISTQB® Certified Tester macht die Arbeit leichter - Tester sprechen nun die gleiche Fachsprache, benutzen die gleichen Begriffe, sind up-to-date.

Anmelden ist einfach.

Der ISTQB® Certified 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.

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

Autorisierte Zertifizierungsstellen

GTB Premium Partner ALTRAN GmbH & Co. KG

Knowledge Department GmbH

Software Quality Lab GmbH

Cert-IT GmbH

berner & mattner Systemtechnik GmbH

Logica Deutschland GmbH & Co. KG

Sogeti Deutschland GmbH

gasq Service GmbH

C1 SetCon GmbH

Loyal Team GmbH

SQS AG

iSQI GmbH

EXCO GmbH

Method Park Software AG

T-Systems

imbus AG

Philotech GmbH

ISARTALakademie GmbH

sepp.med gmbh

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