Requirements Zertiﬁzierungen Testing ACADEM Y HANDBUCH … · Testing Agile ACADEM Y HANDBUCH...

Kursangebote mit Mehrwert

Testing

Agile

ACADEMY HANDBUCH 2015

Requirements

Zert

ifizi

eru

nge

n

Über SwissQSwissQ – SwissQ Academy/Service Profil

Unsere Konferenzen

Vorteile der SwissQ Kurse

Academy Dozenten

Voucher System/Coaching und Workshops

Priority Poker

Schulungspartner

Kursangebot Agile Leading SAFe

Einführung in Agile Vorgehen

Agile Transformation

Agile Requirements Engineering

Agile Backlog Management

User Stories definieren & schneiden

Agiles Testen mit SCRUM

Test Master (Agiles Test Management)

Kursangebot Requirements Requirements Engineering für Manager

Textuelle Anforderungen gut und effizient

formulieren

Use Cases in der Praxis

Stakeholder Analyse

Roadmap to success | Foundation Level

Analyze and Specify Requirements

Get the right Stuff Fast Facilitated JAD Workshops

Scope Modeling

Visual Facilitation Workshop

Kursangebot Testing Software-Testing für Manager

Projekt Management für Test Manager

Soft Skills in Testing

Testdesign in der Praxis

Session Based Testing

Best Performance Test Implementation

Best Practices in Test Automation

Manage Outsourced SW-Testing

Inhalt 02

Inhaltsverzeichnis

Zertifizierungen iSQI® Certified Agile Business Analysis

Certified ScrumMaster ScrumAlliance®

Certified Scrum Product Owner ScrumAlliance®

ISTQB® Agile Tester

IREB® CPRE | Foundation Level

IREB® CPRE | Advanced Level –

Elicitation & Consolidation

IREB® CPRE | Advanced Level –

Requirements Modeling

ISTQB® Certified Tester | Foundation Level

ISTQB® Certified Tester | Advanced Level –

Test Manager


Test Analyst


Technical Test Analyst

ISTQB® Certified Tester | Expert Level –

Improving the Test Process | Part 1

ISTQB® Certified Tester | Expert Level –

Improving the Test Process | Part 2

03

04

05

06

10

11

12

17

18

19

22

23

24

25

27

29

32

33

35

37

38

39

40

42

45

46

48

49

50

53

54

57

60

62

63

66

68

70

71

72

73

74

75

76

78

2006 begann SwissQ als 2-Mann Startup im Bereich Testing und machte sich schnell

einen Namen – nicht nur als Beratungsunternehmen, sondern auch im Ausbildungs-

bereich. Während ich das Swiss Testing Board mit ins Leben rief, sicherte sich SwissQ

Co-Gründer Adrian Zwingli die Pole Position als erster ISTQB® Referent in der Schweiz.

Zusammen legten wir so den Grundstein für die Etablierung des internationalen Stan-

dards im Software Testing auf nationaler Ebene. Von Anfang an war eines unserer Er-

folgsrezepte, als Consultants bei verschiedenen Kunden im Einsatz zu sein, und so die

eher theoretischen Schulungen mit anschaulichen Beispielen und Episoden aus dem

Berufs-Alltag bereichern zu können.

Heute zählt SwissQ über 40 Mitarbeiter, das Angebotsspektrum wurde längst erweitert

um die Bereiche Requirements Engineering und Agile. Damals wie heute liegt uns die

ständige Weiterentwicklung dieser Themen am Herzen. Sei es mit unseren Konferen-

zen (Days and Nights), der jährlichen Erhebung der Trends & Benchmarks im Software

Development, wie auch der ständigen Erweiterung des Kursportfolios, die Stärkung

der Community ist uns wichtig.

Die SwissQ Academy profitiert vom Wissen der erfahrenen Referenten, welche tag-

täglich die Entwicklungen in ihren Projekten erleben und Ihnen im Kurs weitergeben

können. In kleinen Schulungsgruppen bis 12 Personen unterstützen wir Sie auf dem

Weg zur Zertifizierung oder Umsetzung des Themas in Ihren Berufsalltag.

Silvio Moser, CTO/Head Academy

Service Prof il

Praxisnah und menschlich – Willkommen bei der SwissQ Academy!

Über SwissQ 03

Silvio Moser

[email protected]

Anja van Ackern

[email protected]

Silvio Moser

Anja van Ackern

Community Events, Trends & Benchmarks, Stärkung der Berufsbilder

Consulting Agile Methoden und Management Kompetenz, Übernahme

von Test und RE Aufgaben, Assessment und Coaching

Academy Aus- und Weiterbildung, öffentlich und inhouse

Conferences Organisation von

Konferenzen

Unsere Konferenzen

Über SwissQ 04

SWISS REQUIREMENTS DAYWhere Business Analysts, System- and Requirements Engineers meet

www.AgileLeadershipDay.ch

www.ProductManagementFestival.com

www.SwissRequirementsDay.ch

www.SwissTestingDay.ch

Sévérine Reusser, Head Conferences | Tel +41 43 288 88 40 | [email protected]

Ihre Ansprechpartnerin:

Vorteile der SwissQ Kurse

Kurse der SwissQ Academy stehen für

Verständliche Vermittlung von praxisrelevantem Wissen

Optimale Vorbereitung von Zertifizierungen (ISTQB®/ IREB®/SCRUM)

Effektive Umsetzung des Gelernten in die Praxis

Kundenspezifische Anpassungen bei Firmenkursen möglich

Englisch-Durchführung bei Firmenkursen auf Anfrage

Diese Ziele erreichen wir mit unseren erfahrenen Dozenten. SwissQ setzt ausschliesslich Trainer mit jahrelanger Projekt-

erfahrung ein, welche täglich bei Mandanten im Einsatz sind. Somit kann die Brücke zwischen theoretischem Grund-

wissen und dessen Umsetzung in den Alltag erfolgreich geschlagen werden.

Über SwissQ 05

Aus der Praxis für die Praxis!

Academy Dozenten – Die Quelle unseres Wissens

Silvio Moser Lead Consultant, CTO

Silvio engagiert sich seit langem in der und für die Schweizer Testing Community.

Als Leiter des Test Competence Centers einer Schweizerischen Grossbank hatte er das

Bedürfnis nach einer grösseren Wertschätzung des Berufsbildes SW-Tester nicht nur

erkannt, sondern als Gründungsmitglied des Swiss Testing Boards auch unterstützt.

Er hat daran mitgearbeitet, die Certified Tester Ausbildung in der Schweiz aufzubauen

und hat über Jahre hinweg die verschiedensten Initiativen zur Qualitätsverbesserung

begleitet (SPiCE, Prozess Management, Six Sigma, Scaled Agile Framework). Silvio

gibt seine Erfahrungen auch laufend als Referent weiter. Heute unterstützt er (Test-)

Organisationen in ihrem Streben nach kontinuierlicher Verbesserung als Coach, Mit-

gestalter und Trainer.

Stephan Wiesner Principal Consultant

Mit über zehn Jahren Berufserfahrung und einem Wirtschaftsinformatik Studium

(FH) besitzt Stephan ein sehr breites Fachwissen in diversen Sparten und kann sich

ausgesprochen schnell in neuen Projekten zurecht finden.

Er ist Autor diverser Fachbücher und -artikel, tritt auf internationalen Konferenzen als

Sprecher zu Test–Themen auf und hält Vorlesungen zum Thema Software Test an der

Fachhochschule Bern. Technisch liegt sein Schwerpunkt im Bereich technischer Tests,

Testautomation und Mobile Apps.

Marcel Rütschi Principal Consultant

Marcel hat seine Berufung für Testing und Qualitätssicherung vor über zehn Jahren

entdeckt. Mit seinem betriebswirtschaftlichen Hintergrund hat er schnell erkannt,

dass mit frühen Qualitätskontrollen sehr viel Geld eingespart werden kann. Sein

persönliches Ziel liegt darin, das Ansehen des Testens zu steigern und als Motivator

seine Stakeholder mit Begeisterung für das Thema zu gewinnen. Als Mitverfasser

der Teststrategie für eine Schweizerische Grossbank und Umsetzer der ISTQB-

Methodik hat er sein Verständnis der Materie unabhängig von Entwicklungsmethoden

bewiesen.

Der zertifizierte Scrum-Master versteht es ausgezeichnet, mit seiner kommunikativen

Art und seinen didaktischen Fähigkeiten sein Wissen auf eine professionelle und

pragmatische Weise zu vermitteln.

Über SwissQ 06

Armin Born Principal Consultant

Armin ist seit über 25 Jahren als Ingenieur FH im Bereich Hard- und Software-

entwicklung tätig. Seit mehr als zehn Jahren befasst er sich nun hauptsächlich

mit dem Thema Software Testing, dies meistens im Banken-, Versicherungs- und

Industrie-Umfeld internationaler Projekte mit Entwicklungen in Portugal, Indien oder

Ungarn.

Er war der erste Schweizer Dozent für die Certified Tester Advanced Level Ausbildung

in der Schweiz und hat diverse Lehrskripts zu diesem Thema verfasst. Er ist Mitglied

im Swiss Testing Board und arbeitet aktuell in der Arbeitsgruppe «ISTQB® Expert Level

Test Automation».

Marcel Stoop Senior Consultant

Marcel ist seit fast 20 Jahren im Testumfeld tätig. Während dieser Zeit war er in ver-

schiedensten Rollen und Branchen im Testumfeld unterwegs: Tester, Testdesigner,

Testmanager, Testprozess Engineer und Trainer.

Solange Software geschrieben wird, ist das Bedürfnis nach gut funktionierenden Test-

prozessen und qualitativ hochstehender Testarbeit ungebrochen. Diese Erkenntnis

hat bei Marcel dazu geführt, immer noch mit sehr viel Freude und Begeisterung im

Testumfeld tätig zu sein. Seine Leidenschaft liegt darin, anstehende Tester mit dem

Tester-Gen zu infizieren. Aufzuzeigen, dass Testing eine sehr dankbare und noch im-

mer notwendige Arbeit ist, psychologisch vielschichtig ist und eine Herausforderung

darstellt, fällt ihm dann auch nicht schwer.

Adrian Stoll Principal Consultant

Adrian ist begeistert von agilen Entwicklungsmethoden und Projekten im Bereich

Web, Social Media und Mobile Applications. Als Wirtschaftsinformatiker mit einem

Background als Softwareentwickler deckt er ein breites Technologie-Spektrum vom

IBM-Host über Web bis zu Mobile Application Development ab.

Für SwissQ ist er als Senior Consultant und Embedded Tester in Scrum Projekten im

Einsatz und hat ein Faible für Testautomatisierung. Dank seiner kommunikativen Art

und einem praxisorientierten Ansatz kann er an seinen Vorträgen und Schulungen

zum Thema Agile Software Testing und Testautomatisierung aus dem Vollen schöpfen.

Über SwissQ 07

Frederic Hesse Senior Consultant

Frederic hat in einem grossen internationalen SAP Implementierungsprojekt die

Wichtigkeit und Notwendigkeit des Testings erkannt und sich ab diesem Zeitpunkt

dem Thema gewidmet. Seither hat er schon viele Jahre in unterschiedlichen Branchen

und Ländern in diesem Bereich gearbeitet. Mit seinem breit aufgestellten Studium des

Wirtschaftsingenieurwesens und seiner grossen Projekterfahrung kann er alle Rollen

im Testing übernehmen – angefangen vom Testmanagement, über manuelles Testing,

Embedded Testing bis hin zur Testautomatisierung. Die Testautomatisierung ist aktuell

sein Lieblingsgebiet, und er unterstützt verschiedene Unternehmen bei der richtigen

Testautomatisierungsstrategie und der Einführung in die Organisation.

Als erster Referent in der Schweiz für die HP Kurse ergänzt er optimal unser Referenten-

portfolio.

Tobias Ellenberger Managing Consultant

Tobias arbeitet seit mehr als zehn Jahren erfolgreich in verschiedenen Software-

Entwicklungsprojekten als Requirements Engineer, Business Analyst und Projektleiter.

Während seines beruflichen Werdegangs war er fast ausschliesslich in zeitkritischen

Projekten involviert und konnte sein Wissen als Requirements Engineer, Entwick-

ler und Projektleiter mehrfach erfolgreich einbringen und so die Brücke zwischen

dem Fachbereich und der Entwicklung bauen. Durch seine offene und motivierende

Art versteht er es ausgezeichnet, sein Wissen auf eine professionelle und didaktisch

geschickte Weise zu vermitteln.

Alain Hofer Principal Consultant

Alain bringt ein fundiertes Wissen aus seiner früheren Tätigkeit als Software Ingenieur

und Coach in der objektorientierten Software-Entwicklung mit. Seit über 10 Jahren

ist er an der Schnittstelle zwischen Fach/Auftraggeber und IT/Auftragnehmer in

verschiedenen Rollen unterwegs: Coach Projekt-Spezifikation, Prozess-Manager

Requirements Engineering & Testing, Projektleiter, Business Analyst und Leiter

Kompetenzcenter Requirements Management.

Didaktisch wertvolle Wissensvermittlung ist Alain ein wichtiges Anliegen. Nach

langjähriger Erfahrung als Dozent – sei dies an Fachhochschulen, in Firmenkursen

oder direkt in Projekten – festigte er seine methodische Basis für prozessgesteuerte

Wissensvermittlung durch Diplomierung als eidg. dipl. Erwachsenenbildner HF.

Über SwissQ 08

Christoph Wolf Principal Consultant

Chris arbeitet seit über 15 Jahren als Requirements Engineer, Business Analyst,

Projektleiter und IT Consultant bei verschiedenen Firmen. Unter anderem hat er ein

Business-Analyse-Team aufgebaut und geleitet. Ausserdem war er einige Jahre im

Conference Board des Swiss Requirements Day tätig und hat an Konferenzen Vorträge

gehalten – beides mit dem Ziel, die Requirements-Engineering-Community weiter-

zuentwickeln.

In letzter Zeit ist ihm die Vermittlung zwischen Requirements Engineering und Testing

ein grosses Anliegen. Er entwickelt Konzepte, wie sich Requirements Engineers und

Tester erfolgreich unterstützen können, und wie eine Quality-Assurance-Strategie auf

frühe Projektphasen angewendet werden kann.

Stephan Adler Senior Consultant

Stephan legt seinen Fokus auf zielgerichtete und praxisorientierte Lösungen,

sehr gerne auch mit agilen Ansätzen. Er hat seit über 10 Jahren Erfahrung in allen

Bereichen der Softwareentwicklung, sowohl in der Schweiz als auch in Übersee.

Durch seine Tätigkeiten im Management, in der Business-Analyse und in technischen

Bereichen versteht er die unterschiedlichsten Sichtweisen zu verbinden. Dabei kommen

ihm seine Erfahrungen in verschiedenen Branchen wie Energieversorgung, Tele-

kommunikation, Luftfahrt und Medizinaltechnik sehr entgegen.

Als Referent für Requirements Engineering und Business Analyse, agil oder klassisch,

vermittelt er diese Disziplinen im Gesamtkontext der Softwareentwicklung.

Über SwissQ 09

Über SwissQ 10

Voucher-System

SwissQ bietet mit dem Voucher-System attraktive Konditionen für die Teilnahme an öffentlichen Kursen. Das Prinzip bie-

tet Ihnen die Möglichkeit, mehrere Kurstage in einem Paket zu kaufen und dadurch von Ermässigungen zu profitieren.

Staffelungen

Anzahl Kurstage Bezeichnung Ermässigung

25 Kurstage Schulungs-Voucher 25 5%



1 Voucher-Tag entspricht einem Kurstag

Alle Kosten sind im Voucher-Preis enthalten (Verpflegung, Schulungsunterlagen, Prüfungsgebühren)

Anmeldungen können kostenfrei bis 14 Werktage vor Kursbeginn storniert werden

Das Voucher-Paket ist 24 Monate ab Kaufdatum gültig

Preise exkl. MwSt.

Alle Kurse werden auch als Inhouse Kurse angeboten. Bitte kontaktieren Sie uns für eine Offerte: [email protected]

Coaching und Workshops

Aus unseren Schulungen ist uns bekannt, dass es vielen Firmen schwerfällt, das gewonnene theoretische Wissen in die

Praxis umzusetzen. Die Komplexität ist doch meist höher als zuerst angenommen. Oftmals sehen die Firmen die beste

Lösung in der Anstellung eines externen Mitarbeiters. Dabei wird Wissen eingekauft, welches das Unternehmen aber

nach Ende eines Projektes wieder verlässt. Zusätzlich werden so die Fähigkeiten der eigenen Mitarbeiter nicht gefördert

respektive weiterentwickelt, was zu Demotivation führen kann. SwissQ befähigt die Mitarbeiter Ihrer Organisation durch

gezielte Coachings und vermittelt ihnen so das nötige Knowhow, Projekte selbstständig umsetzen zu können.

Nutzen von Projektcoaching

Erweiterter Lerneffekt durch direkten Einsatz des Gelernten im täglichen Arbeitsumfeld

Zielgeführte Massnahmen für Learning by doing

Optimierung des expliziten Wissens im Unternehmen durch gemeinsames Erarbeiten des Wissens

Befähigung der Mitarbeiter, Projektaufgaben selbstständig umzusetzen

Die Umsetzung im Alltag

Die Regeln sind einfach (Details siehe Einführung

und Beispiel) und sind mit dem bereits weit ver-

breiteten Planning Poker verwandt. Innert we-

nigen Schätzrunden ergibt sich eine Reihenfolge

nach dem Prinzip der relativen Gewichtung. Un-

terstützt wird dies durch eine klare Abstufung der

verwendeten Messzahlen:

Die einfachen Regeln ermöglichen eine lösungsorientierte Diskussion über das wirklich Wichtige. Die in Relationen er-

mittelten Wichtigkeiten entwickeln sich unter der Berücksichtigung der Meinung jedes Stakeholders. Die soziale Kom-

ponente verspricht ein gemeinsames Umsetzen der erarbeiteten Strategie und führt zu erfolgreichen Priorisierungen.

Priority Poker

Entwickeln Sie schon oder priorisieren Sie noch?

In vielen Projekten, sowohl im agilen wie auch im traditionellen Entwicklungsumfeld, wird oft um die

«richtige» Priorisierung gerungen. Unterschiedliche Interessen und Einflüsse führen dazu, dass eine

Konsensfindung unter den verschiedenen Beteiligten häufig schwierig bis unmöglich ist.

Priority-Poker-SetDie bekannten Methoden zur Prioritätensetzung werden zudem nicht allen Stake-

holdern gerecht und führen dazu, dass sich die Entwicklung verzögert oder sich in die falsche Richtung

bewegt. Endlose Diskussionen über die Prioritäten gehören ebenfalls zur Tagesordnung und einmal festgelegte Priorisie-

rungen werden nicht selten dauernd wieder korrigiert.

Kommen Ihnen diese Probleme bekannt vor? Mit Priority Poker möchten wir Ihnen eine Methode in die Hand geben,

welche viele diese Probleme lösen kann resp. gar nicht aufkommen lässt. Durch einen spielerischen Approach motiviert,

treffen sich Experten aus verschiedenen Disziplinen zu einer Priority Poker Session. An einer solchen Session nehmen im

Idealfall sämtliche Stakeholder, Beteiligte und Betroffene teil. Durch die «Erspielung» von Prioritäten ist das Interesse

und die Motivation der Teilnehmer praktisch sofort geweckt.

Über SwissQ 11

Priority Poker Set jetzt kostenlos bestellen: www.Swissq.it/priority-poker-bestellformular/

SynSpace ist ein international tätiges Beratungs- und Schulungsunternehmen und beschäftigt

Projektleiter, Experten und Trainer mit Führungsqualitäten, Integrität und scharfem analy-

tischem Verstand. SynSpace arbeitet in den Kernbereichen Qualitäts-, Projekt- und Prozess-

management unter anderem für Firmen wie ABB, Johnson Controls, Kudelski, Meggitt, Roche

Diagnostics, SICPA, SwissRe, UBS, Volkswagen und viele andere.

Seit mehr als 20 Jahren hilft HOOD nationalen und internationalen Organisationen, ihren Require-

ments Engineering Prozess zu verbessern, um komplexe Produkte zu entwickeln und anspruchsvolle

Projekte erfolgreich durchzuführen – im agilen, wie auch im klassischen Umfeld. HOOD vermittelt

sein Wissen an andere Menschen und Organisationen auch durch Schulungen, Workshops, Beratung

und Coaching. HOOD befähigt Unternehmen, Anforderungsmanagement erfolgreich umzusetzen.

Das ScrumTeam ist Ihr Partner für Agile Transitions, Certified ScrumMaster und Certified Scrum

Product Owner Trainings sowie Team Coaching während Ihrer Scrum-Einführung. Andreas Schliep

(CST, CSC) und Peter Beck (CST) haben umfangreiche Erfahrung in der Unterstützung von Teams und

Organisationen bei der Anwendung von Scrum und verwandten Prinzipien und Praktiken (z.B.

Lean Thinking, XP/Extreme Programming, Kanban). Wir helfen Ihnen, die gesamte Performance

zu steigern, bessere Software zu liefern - und die Zufriedenheit der Mitarbeiter zu verbessern.

Trainingsanbieter Werkzeuge

Microsoft steht seit Jahren für Software von höchster Qualität. Im Entwicklungsbereich ist der

Team Foundation Server ein sehr verbreitetes Arbeitsinstrument, und mit dem Produkt MS Test

Professional 2010 wird der Bereich Testing vollintegriert abgedeckt. Seit 2011 besteht eine

Partnerschaft zwischen SwissQ und Microsoft.

Training und Zertifizierungen sind die Grundlage für Business Technology Investment Opti-

mierung. Es ist allgemein bekannt, dass durch gut ausgebildete Mitarbeiter Investitionen in

Technologien schneller gewinnbringend sind. HP stellt ein umfangreiches Lehrangebot zu allen

HP Produkten zur Verfügung.

Zertif izierungsstellen

Personenzertifizierungen machen theoretisches Wissen wie praktische Fertigkeiten sichtbar,

transparent und international vergleichbar. SAQ als neutrale und unabhängige Personen-

zertifizierungsstelle zertifiziert mit ihren Partnern Personen in verschiedenen Bereichen.

Das International Software Quality Institute iSQI GmbH zertifiziert weltweit das Knowhow von

(IT-)Fachkräften. Das Institut ist vielgefragter Ausbildungspartner sowohl für Global Player als

auch für mittelständische Firmen in über 80 Ländern auf sechs Kontinenten in sieben Sprachen.

SwissQ Academy führt diverse Kurse in Zusammenarbeit mit den Spezialisten der jeweiligen Fachgebiete durch. Alle Kurse können über uns gebucht werden.

Gemeinsam sind wir stark!

Über SwissQ 12

Schulungspartner

WE WANT YOU!Egal ob Emporkömmling, Quereinsteiger oder Überflieger: SwissQ ist immer auf der Suche nach neuen Mitarbeitern! Informier dich und bewirb dich: www.SwissQ.it Das SwissQ Team freut sich auf dich!

«Den täglichen Umgang mit vielen unterschiedlichen Menschen.

Die Verantwortung, für meine Kunden echten Geschäftswert in Anforderungen zu erkennen. Die Basis für erfolgreiche

Projekte zu gestalten. Diese Herausforderung liebe ich.»

[ Tobias Ellenberger, Rolle im Projekt: Lead Business Analyst ]

«Man begegnet sich auf gleicher Augenhöhe. Deshalb SwissQ.»

[ Anton Podokschik, RE Consultant ]

Egal ob Emporkömmling, Quereinsteiger oder Überflieger: SwissQ ist immer auf der Suche nach neuen Mitarbeitern! Informier dich und bewirb

«SwissQ is Magic!»

dungskonzept definiert. Der Stand der Weiter-entwicklung – vom Consultant über den Senior Consultant bis zum Principal Consultant – ist auch Thema der regelmässigen Mitarbeiter-gespräche.

DAS RICHTIGE ANREIZSYSTEMUm dieses Fördern und Fordern kontinuierlich sicherstellen zu können, haben wir das «PDU-System» (Personal Development Unit) ent-wickelt. In Anlehnung an die PDU-Methode des Project Management Institute (www.pmi.org), werden von den Mitarbeitern PDU-Punkte in zwei Bereichen gesammelt:

Ausbildung & Networking (AN): Eine inves-tierte Stunde entspricht grundsätzlich 1 PDU. Wissen weitergeben (WW): Hier werden der Vorbereitungsaufwand sowie die externe Relevanz berücksichtigt.

Je nach Senioritätsstufe ist im Laufe des Jahres eine unterschiedliche Anzahl an PDU-Punkten zu sammeln:

Consultant: 50 Punkte, wovon 9 Punkte aus dem Bereich «Wissen weitergeben» stammen müssen. Senior Consultant: 60 Punkte, wovon 10 Punkte aus dem Bereich «Wissen weiter-geben» stammen müssen. Principal Consultant: 70 Punkte, wovon 40 Prozent aus dem Bereich «Wissen weiter-geben» stammen müssen.

WISSEN ALS JAHRESZIELAb dem Level «Senior Consultant» wird ein variabler Lohnbestandteil ausbezahlt. Dieser ist direkt an erreichte Ziele gebunden, ein Teil da-von sind vorgegebene PDU-Punkte. Dank dieses Systems ist die Weiterbildung sichergestellt. Jeder Mitarbeiter muss sich weiterbilden, an-sonsten ist die Zielerreichung gefährdet. Die Art der Ausbildung kann allerdings variieren. Wäh-rend Consultants eher eine klassische Wissens-vermittlung brauchen, bevorzugt ein Principal Consultant vielleicht eher eine Weiterbildung im Rahmen eines Networkings. Das Wissen kann in Kursen, an Konferenzen und Events oder im Selbststudium angeeignet werden (vgl. Beispiel rechts). Wichtig ist, dass ein gewisser Mix vorhanden ist.

VORTEILE DES PDU-SYSTEMSDas PDU-System fördert die Eigeninitiative bei der Weiterentwicklung, berücksichtigt aber trotzdem die Unternehmensvision. Der interne Wissensaustausch wird eingefordert, ohne dass Top Down eine explizite Anordnung («Du musst nun dies, dann, dort erzählen») erfolgen muss. Der Mitarbeitende entscheidet selbst, welche Möglichkeiten er nutzt, um sein Wissen zu tei-len. Das Wissen versteckt sich so nicht nur in den Köpfen Einzelner, sondern wird untereinan-der geteilt und ist damit allen zugänglich.

In unseren Kernkompetenzen, Require-ments Engineering und Testing, wollen wir auch

extern als kompetent wahrgenommen werden. Externe Wissensvermittlung gibt entsprechend mehr PDU-Punkte. Die Mitarbeiter werden auf diese Weise in die Unternehmenskommunika-tion mit eingebunden.

Zudem werden aufgrund des PDU-Systems die Anforderungen an Senioritätsstufen mess-barer. Vom Senior Consultant erwarte ich, dass sich ein Spezialgebiet herauskristallisiert. Vom Principal Consultant erwarte ich, dass er zum Leuchtturm wird – sowohl intern als auch ex-

tern. Das PDU-System zeigt, ob dem so ist. In der Rekrutierung dient es als wichtiges Instru-ment, um den Kandidaten zu zeigen, dass Wei-terbildung nicht nur ein schönes Wort ist, son-dern auch effektiv gelebt wird.

MOTIVATION VON INNEN UND AUSSENIst der spielerische Ansatz, Punkte zu sammeln, dafür der richtige? Offensichtlich sind wir nicht die Einzigen, die im Bereich Wissensmanage-ment und Mitarbeiterweiterentwicklung auf spielerische Elemente setzen. Bis 2015, so schätzt Gartner, werden 40 Prozent der «Global 1000»-Organisationen in der Mitarbeiterweiter-entwicklung «Gamification» einsetzen. Dieser Ansatz ist auch unter dem Begriff «Engagifica-tion» bekannt (zusammengesetzt aus «Em-ployee Engagement» und «Gamification»).

Für Wissensarbeiter sind gemäss der gängi-gen Theorie vier Faktoren wichtig: herausfor-dernde Arbeit, Anerkennung, Verantwortung und Selbstbestimmung. Das PDU-System deckt alle vier ab. Die Weiterentwicklung wird zum Job-inhalt und ist der Unternehmensvision angelehnt.

Ist es sinnvoll, das PDU-System mit der Zielbeurteilung zu verknüpfen? Theoretiker

VON RETO MADUZ

Heute reicht es als Beratungsunterneh-men nicht mehr aus, gute Mitarbei-tende einfach nur zu rekrutieren. Die-ses «Firmenkapital» muss auch aktiv

gefördert, gefordert und gepflegt werden. Das Beratungshaus muss sich quasi zum Think Tank weiterentwickeln, damit der Kunde vom geball-ten Wissen des gesamten Unternehmens und aller Mitarbeitenden profitieren kann. Dazu müssen sich die Berater im Einklang mit der

wie Dank Pink, Autor des Bestsellers «Drive: The Surprising Truth About What Motivates Us», sagen, eine von aussen, etwa durch den Vorgesetzten gesteuerte, extrinsische Motiva-tion könne sich sogar negativ auf die Perfor-mance auswirken. Als Beratungsunternehmen gehen wir davon aus, dass vor allem der Be-reich «Wissen weitergeben» Jobinhalt sein muss. Mit der Zieldefinition via PDU ist dies explizit messbar. Zudem dient das System als Hilfsmittel bei der Rekrutierung, um die rich-

tigen Mitarbeiter zu finden und diese auch richtig einstufen zu können.

Die PDUs als Ziele erzeugen Druck auf die Mitarbeitenden, das ist richtig. Wir wollen aber gerade, dass sich die Mitarbeiter dem Unter-nehmen verbunden fühlen und sich im Sinne des Unternehmens engagieren.

FAZIT: POSITIVE RÜCKMELDUNGBei SwissQ haben wir unser PDU-System Ende 2012 eingeführt – mit erfreulichen Ergebnis-sen: Fast alle Mitarbeiter haben 2013 ihre Ziele erreicht. Auch das Feedback ist positiv. Ge-schätzt wird vor allem die Freiheit, selbst ent-scheiden zu können, welche Schwerpunkte gesetzt werden.

Als Beratungsunternehmen konnten wir uns noch stärker als Think Tank mit einem funktionierenden internen Netzwerk positio-nieren und dies dank PDU-System auch ent-sprechend untermauern. Unsere Kunden schät-zen die transparente Art und Weise, wie wir damit umgehen. Und sie schätzen einen ver-lässlichen Partner, der im Fall einer Projekt-schieflage intern genügend Wissen hat, um schnell Unterstützung zu leisten.

«Wir wollen, dass sich die Mitarbeiter mit uns verbunden fühlen und sich im Sinne des Unternehmens engagieren»

Reto Maduz

Im Bereich «Ausbildung & Networking» (AN):

Besuch einer zweitägigen Ausbildung: 14 PDU

Besuch von Vorträgen im Rahmen von Konferen-zen oder Vortragsreihen während der Arbeitszeit (9 bis 17 Uhr): 2,5 PDU

Besuch von Vorträgen im Rahmen von Konferenzen oder Vortragsreihen aus-serhalb der Arbeitszeit: 7 PDU

Aktive Teilnahme an einer Interessensgruppe in di-rektem Zusammenhang mit der eigenen Tätigkeit bei SwissQ: 2 PDU

Selbststudium ausserhalb der Arbeitszeit: 5 PDU

Im Bereich «Wissen wei-tergeben» (WW):

Halten eines Vortrags im Rahmen von Konferenzen oder Vortragsreihen (extern): 10 PDU

Halten eines Vortrags bei SwissQ (intern), z.B. am Roundtable: 10 PDU

Schreiben eines Artikels zu einem der Kernthemen von SwissQ (z.B. Agil, Test und RE): 10,5 PDU

Schreiben eines Blog-Beitrags auf der SwissQ-Webseite: 18,5 PDU

Das ergibt total 79,5 PDU, davon 49 PDU im Bereich «Wissen weitergeben».

Beispiel: PDU-Sammlung eines Mitarbeiters

Think Tank statt EinzelkämpferKunden erwarten von einem externen Berater, dass er mit Know-how aus der Patsche hilft, egal, wo gerade das Problem liegt. IT-Dienstleister müssen also Expertenwissen zu vielen Bereichen auf Abruf bereitstellen können. Wie lässt sich das bewerkstelligen?

FOKUS: IT-CONSULTANTS

BILD

: IST

OCKP

HOTO

.COM

/GKU

CHER

A

Reto Maduz ist als COO für die operative Führung des SwissQ-Geschäftsbereichs Consulting (Business Units Testing und Requirements Engineering) ver-antwortlich www.swissq.it

Unternehmensstrategie nicht nur kontinuier-lich weiterbilden und weiterentwickeln, min-destens genauso wichtig ist es, dass sie ihr Wissen auch untereinander austauschen. Wie lässt sich dieses «Know-how-Sharing» fördern?

ECKPFEILER DES WISSENSMANAGEMENTSBei SwissQ haben wir einen Weg gefunden, die Mitarbeiterweiterbildung und -weiterentwick-lung sowie das Thema «Wissen weitergeben» für das Unternehmen und die Mitarbeitenden glei-chermassen interessant zu machen. Wissen wird innerhalb der Firma vernetzt und die Unter-nehmensvision zusammen mit den Mitarbeitern nach aussen getragen. Die Kunden profitieren

vom Netzwerk jedes einzelnen Mitarbeiters. Keiner ist als «Einzelmaske» unterwegs. Das firmeninterne Wissensmanagement baut dabei auf folgenden Eckpfeilern auf:

Interessierte Mitarbeitende, ein Ausbildungs-/Weiterentwicklungskonzept sowie ein Anreizsystem für die Weiterbildung und Wissensweitergabe.

DIE RICHTIGEN MITARBEITENDENDie richtigen Mitarbeiter zu finden, ist für alle Unternehmen essenziell. Wir suchen ganz kon-kret Personen, die unsere Unternehmensvision weitertragen können. Welche Ausbildungen möglich und nötig sind, wird in einem Ausbil-

18 19STRATEGIE & PRAXIS Mitarbeiterweiterbildung Computerworld 4/14. März 2014 www.computerworld.ch

Artikel















VON RETO MADUZ









Reto Maduz
















BILD

: IST

OCKP

HOTO

.COM

/GKU

CHER

A






















VON RETO MADUZ









Reto Maduz
















BILD

: IST

OCKP

HOTO

.COM

/GKU

CHER

A








COMPUTERWORLD 4/14. März 2014 www.computerworld.ch

Agile 16

Leading SAFe 17

Einführung in Agile Vorgehen 18

Agile Transformation 19

Agile Requirements Engineering 22

Agile Backlog Management 23

User Stories definieren & schneiden 24

Agiles Testen mit SCRUM 25

Test Master (Agiles Test Management) 27

Siehe auch Agile Kurse unter «Requirements», Seite 28

Siehe auch Agile Kurse unter «Zertifizierungen», Seite 58

NEU

NEU

Kursangebot

Agile

Leading SAFe

Einführung

In this course, you will gain the knowledge necessary to lead an enterprise agile

transformation by leveraging the Scaled Agile Framework, and its underlying princi-

ples of lean thinking, and product development flow. You will leave with an under-

standing of how the principles and practices of the framework support Lean Thinking,

Agile Development, SAFe ScrumXP, Agile Release Train, Agile Portfolio Management,

Agile Architecture, and Scaling Leadership.

Zielgruppe

Executives, managers and Agile change agents leading a Lean/

Agile transformation

Anybody interested in SAFe

Ziele

Apply lean, agile and product development flow principles

Apply the Scaled Agile Framework

Understand the skills necessary for an enterprise transformation

Inhalt

Intro to SAFe

Lean Thinking

Agile Development

SAFe ScrumXP

Agile Release Train

Agile Portfolio Management

Agile 17

Sprache DE / EN / Unterlagen EN

Typ firmenintern

Dauer 2 Tage Code SAFE

Agile

Requirements

Testing

Zertifizierungen

Einführung in Agile Vorgehen

Einführung

Nebst dem bekannten Wasserfall-Modell und seinen mehr oder weniger iterativen

Ableitungen (Hermes, RUP, …), finden agile Modelle eine immer grössere Verbreitung.

In diesem Kurs werden die grundlegenden agilen Praktiken erläutert und die zwei am

meisten gebrauchten Modelle - Scrum und Kanban - detaillierter betrachtet. Weitere

agile Vorgehen werden kurz vorgestellt. Es wird aufgezeigt, wo die Unterschiede zum

Wasserfall liegen und welche Vor- und Nachteile damit verbunden sind.

Die Unterlagen sind auf englisch.

Zielgruppe

Entscheidungsträger

Produkt-Manager

Projektleiter

Weitere an Agil interessierte Personen

Ziele

Die Kursteilnehmer sind nach dem Kurs mit den wichtigsten agilen Praktiken vertraut

und können beurteilen, ob der Einsatz agiler Vorgehen in ihrem Umfeld sinnvoll und

praktikabel ist.

Inhalt

Wieso Agil?

Agile Prinzipien

Agile Methoden

Skalierung von Agil

Agile 18


Typ öffentlich/firmenintern

Dauer 1 Tag Code EAV

Auch im Package buchbar mit Agile Transformation (siehe nächste Seite)

Agile

Requirements

Testing

Zertifizierungen

Agile Transformation

Einführung

Agile Vorgehen überzeugen durch ihre Einfachheit und unkomplizierte Anwendung. In

der Praxis gestaltet sich die Einführung oft schwieriger als erwartet. Es handelt sich

um einen Paradigmawechsel der weitreichende Konsequenzen auf die Aufbau- und

Ablauforganisation des Unternehmens hat. Ohne gezieltes Vorgehen ist die Chance ei-

nes Scheiterns gross. Dieser Kurs richtet sich an Personen, die in ihrem Unternehmen

agile Transformationen organisieren und vorantreiben sowie an Personen, welche von

agilen Transformationen betroffen sind und mehr dazu wissen wollen. Es werden die

Grundprinzipien der Agilität thematisiert und deren Auswirkungen auf die Organisati-

on veranschaulicht. Die Vorgehen für die agile Transformation werden diskutiert und

entsprechende Praktiken und Tools vorgestellt.

Zielgruppe

Entscheidungsträger

Agile Coaches/Scrum Master

Projektleiter

Weitere an Agil interessierte Personen

Ziele

Die Kursteilnehmer sind mit den Herausforderungen einer agilen Transformation ver-

traut und in der Lage, entsprechende Schritte in Angriff zu nehmen.

Inhalt

Gründe für das Scheitern agiler Projekte

Dimensionen der Agilität im Unternehmen

Vorgehen für die agile Transformation

Prinzipien, Praktiken und Tools

Voraussetzungen

Teilnahme am Kurs «Einführung in agile Vorgehen» oder entsprechende Vorkenntnisse

Agile 19



Dauer 1 Tag Code ATRA

Auch im Package buchbar mit Einführung in Agile Vorgehen (siehe vorherige Seite)

Agile

Requirements

Testing

Zertifizierungen

0

5

10

15

20

25

30

0

5

10

15

20

25

30

www.swissq.it/embedded-testing-plakat-bestellformular/

AGILE TESTING FRAMEWORK

POSTER zu bestellen über:

GRATIS

Agile Requirements Engineering

Einführung

Dieses Praxismodul führt Sie in die Welt der Agilen Entwicklung ein, insbesondere

in die Unterschiede des Requirements Engineering in traditionellen (wasserfallorien-

tierten) Vorgehen und in agilen Vorgehen (wie z.B. in SCRUM). Sie werden anhand von

Praxisbeispielen die Unterschiede im Vorgehen, der Dokumentation, der Prüfung und

der Verwaltung kennenlernen.

Zielgruppe

Projektleiter

Requirements Engineers

Produktmanager

Product Owner (künftige)

Teamleiter

Ziele

Nach diesem Workshop sind die Teilnehmer in der Lage, die Unterschiede im Vorgehen

bezüglich Requirements Engineering zu erkennen und in Ihrem Kontext zu bewerten.

Damit haben sie die notwendigen Grundlagen, um die für sie passende Vorgehens-

weise zu definieren.

Inhalt

Übersicht über bekannte Entwicklungsprozesse

(HERMES, V-Model, RUP, SCRUM, XP, etc.)

Unterschiede und Gemeinsamkeiten

Unterschiede bei der Einführung von agilen Methoden

Erkennen der Nutzenpotentiale von agilen Vorgehensweisen

Voraussetzungen

Interesse an agilen Vorgehensweisen im Requirements Engineering

Agile 22

Sprache DE

Typ firmenintern

Dauer 1 Tag Code AREQ

Agile

Requirements

Testing

Zertifizierungen

Agile Backlog Management

Einführung

Dieses Praxismodul richtet sich an Product Owner, die ihr Backlog effizienter ver-

walten möchten. Der Fokus liegt dabei sowohl auf der Verwaltung eines einzelnen

Backlogs, als auch auf den Techniken, wie Backlogs in verteilten Teams bewirtschaftet

werden können. Den Teilnehmer werden die unterschiedlichen Techniken anhand von

Praxisbeispielen erklärt. Des Weiteren erhält man einen Einblick in vorhandene Tools

und deren Einsatzmöglichkeiten.

Zielgruppe

Product Owner


Business Projektleiter

Ziele

Die Teilnehmer dieses Workshops wissen, wie sie ihr Backlog auf den verschiedenen

Stufen verwalten können und welche Techniken sie bei der effizienten Erstellung und

Bewirtschaftung unterstützen.

Inhalt

Kurze Einführung in SCRUM

Die Rolle des Product Owners

Das Product Backlog als Basis von Entwicklungs-Iterationen (in SCRUM = Sprints)

Techniken des Product Backlog Managements an Praxisbeispielen erklärt

Tools & Techniken zur Unterstützung des Backlog Managements

Voraussetzungen

Idealerweise Grundlagen im Requirements Engineering, CPRE Foundation Level Zerti-

fikat oder adäquate Ausbildung, ergänzt mit Basiswissen SCRUM

Agile 23

Sprache DE

Typ firmenintern

Dauer 1 Tag Code ABMA

Agile

Requirements

Testing

Zertifizierungen

User Stories def inieren & schneiden

Einführung

Dieses Praxismodul richtet sich in erster Linie an Product Owner, die mit der Aufga-

be betreut sind, Anforderungen in Form von User Stories zu definieren. Dabei liegt

der Fokus nicht ausschliesslich auf den User Stories. So erfahren die Teilnehmer auch

den Zusammenhang zwischen der Portfolio-Sicht bis hin zu einzelnen Vorhaben. Das

Schneiden von User Stories, die in einer Iteration (Sprint) umgesetzt werden können,

steht dabei ebenso im Vordergrund, wie die Betrachtung von unterschiedlichen Archi-

tekturen und die Berücksichtigung von Akzeptanzkriterien.

Zielgruppe

Product Owner



Ziele

Die Teilnehmer dieses Workshops erhalten einen Einblick in die Techniken und Best

Practice Ansätze zur Erstellung von User Stories, die iterativ entwickelt werden.

Inhalt

Kurze Einführung in SCRUM

Die Rolle des Product Owners

Die Basis einer User Story

Die Beziehung zwischen Epics und User Stories

User Stories in iterativen Vorhaben

Tools & Techniken zur Erstellung von User Stories

Voraussetzungen

Idealerweise Grundlagen im Requirements Engineering, CPRE Foundation Level Zerti-

fikat oder adäquate Ausbildung, ergänzt mit Basiswissen SCRUM

Agile 24

Sprache DE

Typ firmenintern

Dauer 2 Tage Code USDS

Agile

Requirements

Testing

Zertifizierungen

Agiles Testen mit SCRUM

Einführung

Seit einigen Jahren werden erfolgreich agile Methoden und insbesondere Scrum in

Software Projekten eingesetzt, mit dem Ziel, Kundenwünsche besser und schneller

umzusetzen, als es bei einem traditionellen Wasserfall- Vorgehen möglich ist. Der

stark im Vordergrund stehende Teamgedanke und die zahlreichen kurzen Iterationen

bei agilen Vorgehen, stellen Tester vor neue Herausforderungen.

In diesem zweitägigen Kurs lernen die Teilnehmer, was Testen in einem agilen Kontext

bedeutet.

Zielgruppe

Tester

Testleiter

Testmanager

Projektleiter

Qualitätsverantwortliche

Ziele

Die Teilnehmer eignen sich agile Techniken und Methoden an, um als Testspezialisten

erfolgreich in einem SCRUM Team agieren zu können. Neben Grundkenntnissen über

die Scrum Methodik werden vor allem spezifisches Wissen und Techniken im Bereich

Testing vermittelt.

Inhalt

Einführung in SCRUM

Traditionelles Testen vs. agiles Testen

Testen in SCRUM

Aufwandsschätzung

Continuous Integration und Regression Testing

Testautomatisierung Voraussetzungen

Erfahrung in den Bereichen Informatik, Organisation oder Betriebswirtschaft

Agile 25

Sprache DE/EN


Dauer 2 Tage Code ATMS

Agile

Requirements

Testing

Zertifizierungen

Blog

Der Test Manager muss sich weiterentwickeln, will er nicht vom Tiger gebissen werden.Am 19.03.2014 war es wieder so weit. Swiss Testing Day. Einer der grössten Test-Conferences in Europa feierte an diesem Tag sein 9. «Jubiläum». Als Senior Consultant von SwissQ konnte ich einige Präsentationen beiwohnen. Wie zu erwarten, gab es dieses Jahr wieder viele Beiträge die als Thema Agilität hatten. Auch Silvio Moser, CTO SwissQ, hat dieses Jahr einen Beitrag im agilen Umfeld beigesteuert. Mit seinem Referat, mit dem doch ziemlich provo-kativen Titel «Der Test Manager ist tot, lang lebe der Test Master», hat er sich einen spezifischen Bereich der Agilität ausgesucht: der Test Manager. Sein Referat thematisiert den Wandel, dem sich die heutigen Testmanager stellen müssen. Meiner Meinung nach hat Silvio Moser genau das richtige Thema gewählt. In den vergange-nen Jahren hat man viel referiert über agile Prozesse, wie man das Testing innerhalb des agilen Vorgehensmodells gestallten soll und wo die Herausforderungen in der agilen Entwicklung liegen. Aber der Test Manager wurde niemals thematisiert, obwohl dieser doch eine zentrale Rolle in der Qualitätssicherung einnimmt.

Der Testmanager 2.0

Das Silvio Moser mit diesem Thema «gold»-richtig lag, zeigte sich an der Zuhörerpräsenz. Der Saal war sehr gut gefüllt, was auf ein reges Interesse für dieses Thema schliessen lässt.

Silvio Moser hatte das Ziel, ein neues Bild des Test Managers zu kreieren, der sich dem Trend zur Agilität anschliesst. Der Test Ma-nager der mit Excel-Sheets, Testmanagement Tools, statistischen Testauswertungen und Top-Down kommunizierten Testkonzepten und Teststrategien jongliert, will nicht mehr so recht in das heutige Umfeld passen. Besonders in einer Organisation, die den Wandel zum agilen Software Development – Stichwort Scrum – eingeschlagen hat. Der moderne Test Manager sollte sich nicht mehr als Verwalter und Administrator von definierten Testprozes-sen und Teststrategien sehen, sondern eher als agiler Virtuose in der Qualitätssicherung.

Schon nach den ersten Slides meinte ich, bei einigen Zuhörern ein leichtes Unbehagen wahrzunehmen:

«Werde ich als Test Manager jetzt tatsächlich wegrationalisiert und durch einen Art Merlin ersetzt?»

In der heutigen Zeit, wo immer mehr auf Agilität gesetzt wird, sollte man vermehrt die Komplexität aus Prozessen rausnehmen und diese in die gesteigerten Fähigkeiten des Embedded Testers umwandeln. In dem Sinne sollte der Test Master nur noch das machen, wozu das Scrum-Team oder der Embedded Tester nicht mehr in der Lage ist. Hierbei geht es vor allem um teamüber- greifende Testaktivitäten wie z.B. End-To-End Tests.

Der Embedded Tester nimmt innerhalb des Scrum-Teams schon jetzt eine zentrale Position bezüglich Testing ein. Er kommuni-ziert mit den Entwicklern auf direktem Wege über Testqualität, gefundene Bugs und die spezifische Teststrategie die angewendet werden soll. Er plant seine Tests und stellt sicher, dass diese termingerecht ausgeführt werden. In diesem Sinne hat der Embedded Tester schon einen Teil der Test Manager Rolle inne.

Ich sehe jetzt zwei Zuhörer, die mit dem Smartphone in der Hand sehr schnell den Saal verlassen. Ich vermute mal, dass sie mit ihren Vorgesetzten Kontakt aufnehmen und zur Sicherheit kurz nachfragen, ob ihre Rolle als Test Manager noch immer existiert.

Der Test Manager ist tot, lang lebe der Test MasterScrum, muss das jetzt wirklich sein?

Ich muss ehrlich sein, vor einigen Jahren hatte auch ich meine liebe Mühe mit dem Thema Agilität und Scrum: «Wenn die Entwickler unbe-dingt wollen, sollten sie doch ihre Arbeit nach Scrum organisieren. Aber lass uns Tester und Test Manager doch bitte unsere Arbeit und unsere Rollen so organisieren, wie wir das schon seit eh und je machen und darin erfolgreich sind». Lee Copeland nennt es: «The Curse of Past Successes». «Processes that made us successful in the past may prevent us from being successful in the future.» Wir, die in der Qualitätssiche-rung tätig sind, müssen uns ändern und Wege finden wie wir als Sicher-heitsnetz der Entwicklung innerhalb der agilen Welt erfolgreich bleiben.

Dabei spielt noch etwas anderes mit. Wir Tester und Test Manager müssen akzeptieren, dass wir am Ende der Nahrungskette stehen. Wenn der Tiger schneller wird, muss der Hirsch schlauer werden. Die Entwicklungsabteilung gibt den Takt an, so war es früher und so wird es auch immer bleiben. Entweder ändern wir uns als Tester und als Test Manager, oder wir enden, gefangen in unsere traditionellen Rollen- auffassung bezüglich Testing und Testmanagement in Madame Tussauds.

Die Evolution geht weiter

Voll Spannung erwarteten die Zuhörer die wichtigsten Slides aus dem Referat von Silvio Moser: Was sind jetzt die Unterschiede zwischen dem traditionellen Test Manager und dem Test Master, und was sind seine Kernaufgaben?

Einige Zuhörer zückten sofort ihre Schreibblöcke und schrieben bei den beiden präsentierten Slides fleissig mit. Zugleich meinte ich meinem Sitznachbar denken hören:

«Passe ich in das neue Berufsbild rein?»

Und genau das ist der Punkt. Die Entwicklungswelt ist im Begriff, sich Richtung Agilität zu ändern. Wir müssen uns die Frage stellen, wie wir uns anpassen können und was es noch zusätzlich braucht, damit wir fit sind für die nächste Entwicklung im Testbereich. Diese «Evolution» wird nicht von heute auf morgen stattfinden, aber dass es stattfinden wird, ist sicher. Jetzt geht es nur noch darum, dass wir die verbleibende Zeit nutzen und Klarheit verschaffen, wie wir unsere Rolle als Tester und Test Manager innerhalb der agilen Welt sehen und wie wir diese, so optimal wie möglich ausfüllen können.

In Gesprächen, die ich mit einigen Zuhörern geführt habe, gab es nicht nur positives Feedback, sondern auch kritische Kommentare:

Wieso sollte jetzt wieder eine neue Rolle eingeführt werden? Der Test Manager kann doch als «Titel» einfach weiterleben.

Man braucht nur den Inhalt seiner Rolle zu ändern.

Dieser Einwand tönt sehr logisch und ist teilweise nachvollziehbar. Was aber dabei vergessen geht ist, dass es wichtig ist, bei der Einführung von neuen Vorgehensweisen keine Begriffsverwirrungen bezüglich Rollen entsteht zu lassen. So wird der Test Manager als Rolle eher mit der tra-ditionellen Vorgehensweise wie Wasserfall und V-Modell assoziiert. Der Test Master könnte das Pendant für die agile Vorgehensweise werden. So wie auch der Scrum Master und der Embedded Tester eindeutig mit agilen Vorgehensweisen identifiziert werden. Meiner Meinung nach, werden in Zukunft Test Manager und Test Master beide als Rolle nebeneinander existieren. Der Eine im traditionellen Umfeld, der Andere eher im agilen Umfeld.

Marcel Stoop, Senior Consultant, 25.03.2014

werden in Zukunft Test Manager und Test Master

Der Eine im traditionellen Umfeld, der Andere

Test Master könnte das Pendant für die agile Vorgehensweise werden. So wie auch der Scrum Master und der Embedded Tester eindeutig mit

Den vollständigen Blog können Sie nachlesen auf www.Swissq.it/lang-lebe-der-test-master/

Test Master (Agiles Test Management)

Einführung

Dieser Kurs zeigt anhand von Good Practices und Beispielen auf, wie das Testmanage-

ment im agilen Umfeld angepasst werden kann, um auf die veränderten Bedürfnisse

reagieren zu können. Ausgehend von den Herausforderungen bei agilen Vorgehen

wird aufgezeigt, was agiles Testen im Allgemeinen und agiles Test Management im

Speziellen ausmacht. Es wird die Rolle des Test Masters in Abgrenzung zum klassischen

Test Manager vorgestellt.

Zielgruppe

Tester im agilen Umfeld

Test Manager

Projektleiter

Ziele

Sie lernen die Grundlagen und Vorgehensweisen des agilen Test Managements kennen

und verstehen die Rolle des Test Masters.

Inhalt

Herausforderungen

Agiles Testen

Integration mehrerer Teams

Agiles Test Management

Test Master

Voraussetzungen

Grundkenntnisse des Testmanagements und der agilen Entwicklung

Agile 27

Sprache DE

Typ firmenintern

Dauer 1 Tag Code ATMA

Agile

Requirements

Testing

Zertifizierungen

Requirements 28

Requirements Engineering für Manager 29

Textuelle Anforderungen gut und effizient formulieren 32

Use Cases in der Praxis 33

Stakeholder Analyse 35

Roadmap to success | Foundation Level 37

Analyze and Specify Requirements 38

Get the right Stuff Fast Facilitated JAD Workshop 39

Scope Modeling 40

Visual Facilitation Workshop 42

Siehe auch Requirements Kurse unter «Agile», Seite 16

Siehe auch Requirements Kurse unter «Zertifizierung», Seite 58

Kursangebot

RequirementsNEU

NEU

NEU

Requirements Engineering für Manager

Einführung

Anforderungen kommen aus vielen unterschiedlichen Quellen unter anderem

von Fachspezialisten und werden von Projektleitern benötigt, aber es gibt auch

spezialisierte Rollen. Was kann ein Projektleiter von einem Requirements Engineer/

Business Analysten erwarten, nach welchen Methoden und Prinzipien arbeiten diese.

In diesem Kurs bekommen Personen in Führungsfunktion Kompakt die Grundlagen

des Requirements Engineering auf Management Ebene vermittelt.

Zielgruppe

Projektleiter Personen in Führungsfunktionen Manager

Ziele

Sie lernen die Grundlagen und Vorgehensweise des Requirements Engineerings ken-

nen, inkl. den wichtigsten Normen und Standards in diesem Bereich. Sie verstehen

die Sprache der Requirements Engineers und wissen, was sie von diesen erwarten

können.

Inhalt

Grundlagen Requirements Engineering

- Stakeholdermanagement

- Scope-Management

- Wünsche und Anforderungen

- Hürden des Requirements Engineerings

Der Requirements Engineering Prozess

- Was kann ich von einem Requirements Engineer erwarten

- Artefakte in klassischen Projekten

- Artefakte in agilen Projekten

Wie kann ich von einem Requirements Engineer profitieren

- Social Skills

- Moderation

- Methoden-Rucksack

- Interdisziplinäres Denken

Voraussetzungen

Basiswissen des IT-Managements

Grundlegende Kenntnisse des Software-Entwicklungsprozesses

Requirements 29

Sprache DE

Typ firmenintern

Dauer 0,5 Tag Code SQ_REMG

Requirements

Testing

Zertifizierungen

Agile

Artikel

www.netzwoche.ch © netzmedien ag 2316 / 2014

Qualität beginnt im Kopf – Sechs Praxistipps zur Verbesserung von AnforderungenMit welchen Mitteln können wir im Projektalltag dafür sorgen, dass trotz Zeit- und Budgetdruck genügend Ressourcen ins Erheben und Präzisieren von Anforderungen investiert werden? Wie können wir unser Umfeld davon überzeugen, dass es sich lohnt, die Qualität von Anforderungen zu verbessern? Alain Hofer

In der Neu- und Weiterentwicklung von Soft-ware oder Produkten stehen wir oft im Kon�ikt zwischen dem Bedürfnis, eine gute, ausgereif-te und vollständige Lösung zu entwickeln, und der Tatsache der beschränkt vorhandenen Ressourcen. Dies wirkt sich oft schon früh im Projekt dadurch aus, dass keine Zeit für das saubere und seriöse Erheben von Kundenan-forderungen besteht. Seriös in dem Sinne, dass die Anforderungen vollständig, konsistent, widerspruchsfrei und testbar formuliert wer-den, und von den Stakeholdern priorisiert und für gültig erklärt sind.

Die mit dem Formulieren und Erheben von Anforderungen betrauten Personen, wie Busi-nessanalysten, Product Owner oder Require-ments Engineers (hier im Weiteren als Business-analysten bezeichnet), sind dafür mitverant-wortlich, dass die nachgelagerten Aktivitäten wie die Entwicklung und das Testing auf einer soliden Basis aufsetzen können. Dies gilt so-wohl für Produktentwicklungen im agilen als auch im traditionellen Wasserfall-Umfeld. Im Folgenden werden sechs konkrete Ideen be-schrieben, die in hektischen Zeiten erfolgreich angewendet werden können.

Eins sei vorweggenommen: Das wichtigs-te Instrument für die Umsetzung der Ideen durch den Businessanalysten sind neben dem analytischen Denken seine sozialen Fähigkei-ten, wie Empathie, Argumentationsgabe und Standhaftigkeit! 1. Scoping: Zeit durch Reduktion des Umfangs gewinnbringend nutzen In bestehenden Produkten werden im Schnitt bis zu zwei Dritteln der Funktionalität nicht oder kaum verwendet. Viele Produkte werden

über Jahre weiterentwickelt, indem neue Funktionalitäten durch Projekte hinzugefügt werden, ohne bestehende Funktionen zu hin-terfragen und entfernen. Welcher Business-analyst kennt sie nicht, die Mutter aller Anfor-derungen, sinngemäss: Die neue Lösung soll mindestens alles, was bisher möglich war, unterstützen.

Bestehende Funktionalitäten und neue Anforderungen sollten also hinterfragt wer-den. Dazu können bei Erweiterung von beste-henden Produkten allenfalls auch Statistiken Aufschluss geben, welche Funktionalitäten selten oder nie verwendet werden.

Sind die Anforderungen für den geschäft-lichen Erfolg und die Kundenzufriedenheit wirklich relevant? Und wie sehen es andere Stakeholder, wie beispielsweise Endbenutzer, die Security oder der Betrieb? Und sind diese Stakeholder auch bereit, für die Realisierung und den Betrieb einer Anforderung die Kosten zu übernehmen? Spätestens bei dieser Frage werden sich die Stakeholder wirklich überle-gen, welchen Business Value sie einer Anfor-derung beimessen.

Je früher also im Prozess der Scope ge-setzt werden kann, desto mehr können die Ressourcen auf das Wesentliche fokussiert werden. Eine Kundenanforderung kann zu vielen System- und Designanforderungen

führen, und Auswirkungen auf viele Code-Ele-mente haben. Wenn eine solche Kundenanfor-derung früh verworfen oder präzisiert werden kann, hat dies unmittelbare Auswirkung auf die Ressourcenverteilung in den Folgeaktivi-täten. Deshalb ist sicher eine der wichtigsten Aufgaben eines Businessanalysten, die Anfor-derungen zu hinterfragen und nach dem Wa-rum einer Anforderung zu suchen. Eine be-liebte, e�ektive und einfach anzuwendende Methode des Requirements Engineers ist, fünfmal die Warum-Frage zu stellen, um auf den Kern der Anforderung zu vorzustossen.

2. Priorisierung: das Wesentliche zuerstIn diesem Zusammenhang ist auch die Priori-sierung zu sehen. Die Anforderungen werden gegeneinander nach wohlde�nierten Kriteri-en priorisiert, wie zum Beispiel Business Value, Risiko oder Umsetzungskosten. Was in der agilen Softwareentwicklung erprobt ist und zum Backlog Management gehört wie das Gelbe zum Ei, kann in herkömmlichen Pro-jektvorgehen genauso angewendet werden.

In einem ersten Schritt werden nur die Anforderungen umgesetzt, die für den ge-schäftlichen Erfolg unabdingbar sind. Nach diesem Schritt liegt bereits eine funktionie-rende Lösung vor, wenn auch mit einge-schränkten Funktionsumfang.

Falls noch Ressourcen übrig sind, können weitere Anforderungen zu einem späteren Zeit-punkt realisiert werden. Ganz nach dem Motto: lieber ein funktionierendes Produkt mit redu-ziertem Funktionsumfang als ein nicht funkti-onierendes Produkt mit vielen Funktionen. In

Bild 1: Knapp zwei Drittel aller Funktionalitäten eines Softwareprodukts werden nie oder sehr selten ver-wendet. Grafik: SwissQ, Daten: Standish Group, Chaos Report 2006

Alain Hofer leitet das Büro von SwissQ in Bern, ist Businessanalyst und IREB- Kurs-trainer.

IT-MANAGEMENT SCHWERPUNKT

Bild 2: Hinter einer einzigen Kundenanforderung können viele System- und Designanforderungen stecken. Grafik: SwissQ

Immer Häufig Manchmal Selten Nie

45 %

19 %

13 %

13 %

7 %

Business- anforderungen

System- anforderungen

Design/Code


Qualität beginnt im Kopf – Sechs Praxistipps zur Verbesserung von AnforderungenMit welchen Mitteln können wir im Projektalltag dafür sorgen, dass trotz Zeit- und Budgetdruck genügend Ressourcen ins Erheben und Präzisieren von Anforderungen investiert werden? Wie können wir unser Umfeld davon überzeugen, dass es sich lohnt, die Qualität von Anforderungen zu verbessern? Alain Hofer

In der Neu- und Weiterentwicklung von Soft-ware oder Produkten stehen wir oft im Kon�ikt zwischen dem Bedürfnis, eine gute, ausgereif-te und vollständige Lösung zu entwickeln, und der Tatsache der beschränkt vorhandenen Ressourcen. Dies wirkt sich oft schon früh im Projekt dadurch aus, dass keine Zeit für das saubere und seriöse Erheben von Kundenan-forderungen besteht. Seriös in dem Sinne, dass die Anforderungen vollständig, konsistent, widerspruchsfrei und testbar formuliert wer-den, und von den Stakeholdern priorisiert und für gültig erklärt sind.

Die mit dem Formulieren und Erheben von Anforderungen betrauten Personen, wie Busi-nessanalysten, Product Owner oder Require-ments Engineers (hier im Weiteren als Business-analysten bezeichnet), sind dafür mitverant-wortlich, dass die nachgelagerten Aktivitäten wie die Entwicklung und das Testing auf einer soliden Basis aufsetzen können. Dies gilt so-wohl für Produktentwicklungen im agilen als auch im traditionellen Wasserfall-Umfeld. Im Folgenden werden sechs konkrete Ideen be-schrieben, die in hektischen Zeiten erfolgreich angewendet werden können.

Eins sei vorweggenommen: Das wichtigs-te Instrument für die Umsetzung der Ideen durch den Businessanalysten sind neben dem analytischen Denken seine sozialen Fähigkei-ten, wie Empathie, Argumentationsgabe und Standhaftigkeit! 1. Scoping: Zeit durch Reduktion des Umfangs gewinnbringend nutzen In bestehenden Produkten werden im Schnitt bis zu zwei Dritteln der Funktionalität nicht oder kaum verwendet. Viele Produkte werden

über Jahre weiterentwickelt, indem neue Funktionalitäten durch Projekte hinzugefügt werden, ohne bestehende Funktionen zu hin-terfragen und entfernen. Welcher Business-analyst kennt sie nicht, die Mutter aller Anfor-derungen, sinngemäss: Die neue Lösung soll mindestens alles, was bisher möglich war, unterstützen.

Bestehende Funktionalitäten und neue Anforderungen sollten also hinterfragt wer-den. Dazu können bei Erweiterung von beste-henden Produkten allenfalls auch Statistiken Aufschluss geben, welche Funktionalitäten selten oder nie verwendet werden.

Sind die Anforderungen für den geschäft-lichen Erfolg und die Kundenzufriedenheit wirklich relevant? Und wie sehen es andere Stakeholder, wie beispielsweise Endbenutzer, die Security oder der Betrieb? Und sind diese Stakeholder auch bereit, für die Realisierung und den Betrieb einer Anforderung die Kosten zu übernehmen? Spätestens bei dieser Frage werden sich die Stakeholder wirklich überle-gen, welchen Business Value sie einer Anfor-derung beimessen.

Je früher also im Prozess der Scope ge-setzt werden kann, desto mehr können die Ressourcen auf das Wesentliche fokussiert werden. Eine Kundenanforderung kann zu vielen System- und Designanforderungen

führen, und Auswirkungen auf viele Code-Ele-mente haben. Wenn eine solche Kundenanfor-derung früh verworfen oder präzisiert werden kann, hat dies unmittelbare Auswirkung auf die Ressourcenverteilung in den Folgeaktivi-täten. Deshalb ist sicher eine der wichtigsten Aufgaben eines Businessanalysten, die Anfor-derungen zu hinterfragen und nach dem Wa-rum einer Anforderung zu suchen. Eine be-liebte, e�ektive und einfach anzuwendende Methode des Requirements Engineers ist, fünfmal die Warum-Frage zu stellen, um auf den Kern der Anforderung zu vorzustossen.

2. Priorisierung: das Wesentliche zuerstIn diesem Zusammenhang ist auch die Priori-sierung zu sehen. Die Anforderungen werden gegeneinander nach wohlde�nierten Kriteri-en priorisiert, wie zum Beispiel Business Value, Risiko oder Umsetzungskosten. Was in der agilen Softwareentwicklung erprobt ist und zum Backlog Management gehört wie das Gelbe zum Ei, kann in herkömmlichen Pro-jektvorgehen genauso angewendet werden.

In einem ersten Schritt werden nur die Anforderungen umgesetzt, die für den ge-schäftlichen Erfolg unabdingbar sind. Nach diesem Schritt liegt bereits eine funktionie-rende Lösung vor, wenn auch mit einge-schränkten Funktionsumfang.

Falls noch Ressourcen übrig sind, können weitere Anforderungen zu einem späteren Zeit-punkt realisiert werden. Ganz nach dem Motto: lieber ein funktionierendes Produkt mit redu-ziertem Funktionsumfang als ein nicht funkti-onierendes Produkt mit vielen Funktionen. In

Bild 1: Knapp zwei Drittel aller Funktionalitäten eines Softwareprodukts werden nie oder sehr selten ver-wendet. Grafik: SwissQ, Daten: Standish Group, Chaos Report 2006

Alain Hofer leitet das Büro von SwissQ in Bern, ist Businessanalyst und IREB- Kurs-trainer.

IT-MANAGEMENT SCHWERPUNKT

Bild 2: Hinter einer einzigen Kundenanforderung können viele System- und Designanforderungen stecken. Grafik: SwissQ

Immer Häufig Manchmal Selten Nie

45 %

19 %

13 %

13 %

7 %

Business- anforderungen

System- anforderungen

Design/Code

16 / 2014 www.netzwoche.ch © netzmedien ag24

der Praxis sehr bewährt hat sich zur objektiven und e�zienten Priorisierung der Priority Poker (www.swissq.it/agile-de/priority-poker/).

3. Anforderungen auf Testbarkeit prüfen: Je früher ein Fehler entdeckt wird, desto besserEs ist ein Trugschluss zu glauben, dass wir Zeit gewinnen könnten, wenn wir uns in frühen Projektphasen beeilen. Im Gegenteil: Jeder nicht entdeckte Fehler in einer Kunden- oder Systemanforderung kostet in späteren Projekt-phasen ein Vielfaches für dessen Behebung.

Was in der agilen Softwareentwicklung heute selbstverständlich ist, funktioniert sehr gut auch in einem wasserfallartig aufgesetz-ten Projekt. Früh werden Testpersonen zuge-zogen, die zu jeder Kunden- oder Systeman-forderung einen Testfall de�nieren – oder mindestens eine Testidee skizzieren: Wie wür-de die Testperson die Anforderung testen oder abnehmen? Ist dies nicht möglich, ist die An-forderung allenfalls noch nicht präzise genug und lässt zu viel Interpretationsspielraum zu. Der IREB-Standard verlangt übrigens, dass jede Anforderung mit einem Abnahmekriteri-um hinterlegt wird.

Das frühe Anfügen eines Abnahmekrite-riums ist umso wichtiger, weil als Spezi�kati-onssprache für Anforderungen heute immer noch mit über 50 Prozent Prosa am verbrei-tetsten ist. Und textbasierte Anforderungen lassen bekanntlich deutlich mehr Interpreta-tionsspielraum zu als modellbasierte (Quelle: Trends & Benchmarks Report Schweiz, 2014).

4. Dokumentieren ja – aber was und wie?Wer ist nicht schon mal zu einem laufenden Projekt dazugestossen, in dem zwar vieles do-kumentiert war, aber einem trotzdem nie-mand sagen konnte, welche Anforderungen nun gültig sind, und weshalb andere zurück-gestellt oder gelöscht wurden? Der Zusam-menhang und die Historie zur entsprechen-den Anforderung war nicht nachvollziehbar.

Die Dokumentation ist so eine Sache für sich. Man sollte grundsätzlich in Informatio-nen denken und nicht in Dokumenten. Ein Dokument ist nichts anderes als eine Zusam-menführung von Informationen zu einem be-stimmten Zweck und zu einem wohlde�nier-ten Zeitpunkt. So soll ein Anforderungsdoku-ment mit Businessanforderungen beispiels-weise dazu dienen, die Anforderungen des Kunden an die Lösung zu einem ganzen und für die Entwicklung verständlichen Bild zu führen. Beim Festhalten der Information kann man sich als Businessanalyst von den folgen-den fünf Fragen leiten lassen:

y Wer interessiert sich für die zusammenge-stellten Informationen? (zB. Entwicklung, Testing, Betrieb oder Fach).

y Wie sollen die Informationen festgehalten sein? (Modell, Text, Kombination, elektro-nisch, auf Papier).

y Welche Informationen werden das Projekt nachhaltig überleben?

y Welche Vorgaben sind allenfalls einzuhalten? y Welche Metainformationen sind mit festzu-

halten? (Dazu gehören nach IREB.de sicher die Quelle, der Status, Verknüpfungen zu anderen Objekten und die Historie).

Requirement-Management-Werkzeuge sind eine wesentliche Unterstützung im Verwalten dieser Informationen und den dazugehören-den Metainformationen und erlauben es, ent-sprechende Dokumente daraus zu generieren. Herkömmliche Textverarbeitungs- und Tabel-lenkalkulationsprogramme unterstützen das Verwalten der einzelnen Informationsbaustei-nen zu wenig.

Genauso wichtig ist es, festzuhalten, was nicht realisiert werden soll, und die Entschei-de dazu zu dokumentieren. Bei personeller Änderung muss nachvollziehbar sein, wann und weshalb gewisse Anforderungen gelten oder zurückgestellt wurden.

5. Agile Denk- und Handlungsweise lebenNicht alle unserer Kunden haben die Gele-genheit, ein Projekt nach rein agilen Metho-den durchzuführen. Doch auch in wasserfal-lartigen Vorgehensmethoden können agile Handlungsweisen übernommen werden. Es ist auch eine Frage der persönlichen Haltung und Denkweise.

So ist es oft möglich, Anforderungen so zu paketieren, dass in einem Projekt das Soft-wareprodukt in kleinere Realisierungseinhei-ten zerlegt wird. Jede dieser Einheiten kann dann in einem in sich funktionierenden In-krement des Softwareprodukts realisiert wer-den. Beispielsweise wird in einem ersten Durchgang der Haupt�uss oder Durchstich aus Businesssicht realisiert, ohne Alternativen und Sonderfälle, dafür inklusive minimales GUI und Datenbankzugri�. Alternativ�üsse werden anschliessend einer darauf folgenden Realisierungseinheit hinzugefügt. Nach jeder realisierten Einheit oder jedem Inkrement kann das Projekt auch ohne vorgesehenen

Meilenstein die Stakeholder oder das Business bereits um Feedback fragen und dies gleich mit aufnehmen. Auch ganz im Sinne eines evolutionären Prototyps (siehe IREB.de).

6. Erfahrungen weitergeben: QualitätstippsAll die in der Projektarbeit gesammelten Er-fahrungen in Bezug auf Qualitätsverbesse-rung können ihre Wirkung im Unternehmen erst entfalten, wenn sie für andere Mitarbeiter und Projekte nutzbar gemacht wird. Man er-lebt oft, dass nach Abschluss des Projekts zwar eine Erfolgskontrolle und Feedbackrunde statt�ndet (Stichwort Lessons Learned), die Erkenntnisse daraus jedoch nicht weiter ge-nutzt werden.

Bewährt hat sich in der Praxis, die in den Projekten gemachten Erfahrungen an einer Stelle zu sammeln und gemeinsam mit einem Expertenzirkel aus Businessanalysten zu Best Practices oder Qualitätstipps zu verarbeiten. Diese Tipps müssen für Laien fassbar und ein-fach umsetzbar sein. Dabei gilt: Nur die maxi-mal zehn wesentlichsten Tipps, auf einer A4- Seite kurz erklärt, zusammentragen. Die Tipps ändern sich im Laufe der Zeit ganz nach dem Prinzip der lernenden Organisation. Mit höhe-rer Maturität werden auch die Tipps spezi�-scher. Wichtig ist, dass die pragmatischen Tipps in dieselbe Richtung weisen wie die al-lenfalls vorhandenen methodische Vorgaben.

Ziel der Tipps ist, dass Mitarbeiter mit we-niger Erfahrung von den Fehlern der Kollegin-nen und Kollegen pro�tieren und ihre Erfah-rung selbst darauf aufbauen können. Die Vor-aussetzung dafür ist simpel, aber dennoch nicht trivial zu erreichen: Es braucht eine wert-schätzende Fehler- und o�ene Kommunkati-onskultur, damit die Mitarbeiter auch o�en und ehrlich über ihre gesammelten Erfahrun-gen berichten.

«Bist du in Eile, gehe langsam» Um die Qualität von Anforderungen in einem IT-Projekt zu verbessern, und damit letztlich Zeit und Kosten zu sparen, liegt es oft nicht am fehlenden Werkzeug oder an unvollständigen Methoden, sondern an der O�enheit, beste-hende Prozesse, Anforderungen und Funkti-onalitäten zu hinterfragen. Dazu braucht es neben den organisatorischen Voraussetzun-gen die präzise und emphatische Denkarbeit des Businessanalysten. Gerade in hektischen Projektphasen verfallen wir oft einem Aktivis-mus und nehmen Anforderungen auf, ohne sie wirklich zu hinterfragen, und kommen vor lauter Tun nicht mehr vom Fleck. Zu diesem Zeitpunkt ist es gut, sich auf eine alte Weisheit aus dem Zen-Buddhismus zu besinnen: «Bist du in Eile, gehe langsam». Also: kühlen Kopf bewahren, denn Qualität beginnt im Kopf.

SCHWERPUNKT IT-MANAGEMENT

Bild 3: Kosten von Softwarefehlern, abhängig von der Projektphase. Grafik: Nach Stuart R. Faulk 1995

Anforderungen 1-2

5

10

20

50

200

Design

Implementierung

Unit-Tests

Systemtests

Betrieb

NETZWOCHE 16/2014 www.netzwoche.ch

Textuelle Anforderungen gut und eff izient formulieren

Einführung

Bei der Formulierung von Anforderungen hat sich bis heute noch keine formale

Notation in den Entwicklungsprojekten umfassend durchgesetzt. Der Aufwand für

die Einführung dieser ist sehr hoch und damit kostenintensiv. Darüber hinaus wer-

den solche formalen Notationen nur von wenigen Anforderungsautoren akzeptiert.

Um die Solleigenschaften eines zu entwickelnden Systems zu spezifizieren, werden

deshalb in den Entwicklungsprojekten neben Modellierungssprachen (z.B. UML) meist

natürlichsprachlich formulierte Anforderungen verwendet.

Zielgruppe

Marketingmitarbeiter

Quality Assurance Manager

Entwicklungsingenieure

Systemingenieure

Vertriebsmitarbeiter

Jeder, der Anforderungen schreibt oder liest Ziele

In diesem eintägigen Training werden die Prinzipien einer geschickten Spezifikation

von Anforderungen vermittelt. Die Kursteilnehmer erhalten damit eine fundierte

Basis, um Anforderungen zu formulieren und im Projektverlauf zu nutzen.

Inhalt

Der Produktlebenszyklus und die Rolle von Anforderungen

Der Anforderungsdefinitionsprozess

Qualitätsmerkmale von Anforderungen und Spezifikationen

Anforderungen schreiben und analysieren

Requirements 32

Sprache DE

Typ firmenintern

Dauer 1 Tag Code TAEF

In Zusammenarbeit mit

Requirements

Testing

Zertifizierungen

Agile

Use Cases in der Praxis

Einführung

Use Cases sind ein Konzept, welches seit mehr als 20 Jahren bekannt und hinlänglich

dokumentiert ist. Dieses Praxismodul richtet sich in erster Linie an Requirements

Engineers, die mit der Aufgabe betreut sind, Anforderungen in Form von Use Cases

zu definieren. Dabei liegt der Fokus nicht nur auf den Use Cases. Die Teilnehmer

lernen auch die Zusammenhänge von der Use Case Map bis hin zu einzelnen Use Cases

kennen. Die Einbettung von Use Cases in ein iteratives Vorhaben und das Konzept der

«Just-in-time Specification» werden ebenso vermittelt.

Zielgruppe


Business Analysten


Ziele

Die Teilnehmer dieses Workshops erhalten einen Einblick in das Thema Use Cases

und lernen, welche Bestandteile einen guten Use Case ausmachen, wie Use Cases als

Management Werkzeug genutzt werden können und welche Hürden es in diesem

Themengebiet gibt.

Inhalt

Kurze Einführung in einen beispielhaften Entwicklungsprozess

Der Use Case Ansatz

Die Bestandteile eines Use Cases

Umsetzung in der Praxis

Weitere Einsatzmöglichkeiten

Voraussetzungen

Grundlagen des Requirements Engineerings

Grundlagen der Software Entwicklung

Requirements 33

Sprache DE

Typ firmenintern

Dauer 1 Tag Code UCP

Requirements

Testing

Zertifizierungen

Agile


Liebe Tester, bitte arbeitet nicht gegen uns!

Anforderungen sind das A und O eines Softwareprojekts. Probleme, die sich im Zusammengang mit Anforderungen

ergeben, betreffen nicht nur das Requirements Engineering, sondern auch die Testing-Mitarbeiter. Die Mitarbeiter beider

Disziplinen müssen folglich näher zusammenarbeiten, wenn sie in Zukunft effizienter sein wollen. Janine Aegerter

Seit sechs Jahren verö�entlicht SwissQ jähr-

lich die Trends- und Benchmarks-Studie mit

Zahlen und Fakten zum Stand der Soft-

wareentwicklung in der Schweiz. Was mit den

Testing-Trends angefangen hat, wurde später

um die emenbereiche Requirements und

Agile ergänzt. Was bisher als separate Reports

verö�entlicht worden ist, hat SwissQ in die-

sem Jahr im Rahmen des «Trends & Bench-

marks in Software Development Report 2014»

in einem einzigen Bericht vereint. Grundlage

dafür bildete wie in der Vergangenheit eine

Onlineumfrage, an der gut 500 Personen aus

unterschiedlichen Firmen, Branchen und Re-

gionen der Schweiz teilgenommen haben. Zu-

sätzlich wurden etwa 25 Executive-Interviews

durchgeführt. Im vorliegenden Text widmen

wir uns dem Abschnitt zum Requirements En-

gineering.

Zusammenarbeit ist wichtig

Die beiden Disziplinen Requirements En-

gineering (RE) und Testing sind eng miteinan-

der verknüpft, was nicht ganz unproblema-

tisch ist, wie SwissQ in der Einführung des

Reports schreibt. Im Testing habe es in den

letzten Jahren grosse Fortschritte gegeben,

dadurch habe sich der Druck auf das Require-

ments Engineering erhöht, weil der Ursprung

des vielfach sehr hohen Testaufwands oft bei

den ungenügenden Anforderungen zu �nden

sei, so SwissQ.

Es sei daher wichtig, dass die beiden

Disziplinen nicht mehr nacheinander oder

schlimmstenfalls gegeneinander, sondern

mit einander arbeiteten, schreibt SwissQ wei-

ter. Requirements-Engineering- und Testing-

Experten müssten daher zusammenarbeiten

und interdisziplinär denken. Die anhaltende

Bewegung zur Agilität und auch die vermehrt

auftretenden agilen Wasserfall- Hybriden ver-

stärke das Zusammenwirken der beiden Dis-

ziplinen nur noch.

Zufriedenheit lässt zu wünschen übrig

Dass es Nachholbedarf gibt, zeigen die Zahlen

zur Zufriedenheit bei der Erhebung von Anfor-

derungen. 61,4 Prozent der Befragten sind mit

der Erhebung von Anforderungen nur mittel-

mässig bis gar nicht zufrieden. Ganze 70,6 Pro-

zent geben zudem an, mit dem Dokumentie-

ren von Anforderungen nicht zufrieden zu

sein. SwissQ zieht daraus den Schluss, dass

die Notationen und Werkzeuge ihren Zweck

nicht erfüllen.

Als wichtigsten Grund für die ungenügen-

den Anforderungen geben die Befragten mit

52,8 Prozent Missverständnisse in der Kom-

munikation an. Auch stetig steigende oder

sich verändernde Anforderungen werden von

46,8 Prozent der Befragten genannt. Ebenso

falsche oder fehlende Priorisierung von Anfor-

derungen (37,5 Prozent) oder unvollständige

oder falsche Quellen als Basis für Anforderun-

gen sind mit 36,8 Prozent der Antworten ver-

treten. Zudem führt der Zeit- und Termin-

druck laut Report dazu, dass dem Require-

ments Engineering zu wenig Zeit eingeräumt

wird (35,7 Prozent).

Visuelle Kommunikation verbessern

Als Massnahmen gegen diese Probleme set-

zen 53,6 Prozent der Befragten interne Aus-

und Weiterbildungen ein. 22,4 Prozent planen

diese. Auch die Etablierung interner Vorlagen

und Normen wird von 50,2 Prozent der Befrag-

ten bereits umgesetzt, 31,5 Prozent haben die-

se geplant. Nicht zuletzt haben sich 44,8 Pro-

zent der Befragten dafür entschieden, gezielt

mehr Personal einzustellen, 23,9 Prozent wol-

len dies noch tun. Um grundsätzlich die Erhe-

bung von Anforderungen zu verbessern, se-

hen 64,9 Prozent aller Befragten ein sehr ho-

hes oder hohes Verbesserungspotenzial, wenn

man die visuelle Kommunikation verbessern

würde. Dazu gehört beispielsweise, Anforde-

rungen zu visualisieren, statt UML-Modelle zu

zeichnen. 64,9 Prozent aller Befragten sehen

darin ein sehr hohes oder hohes Verbesse-

rungspotenzial. Dasselbe gilt für 63,8 Prozent

der Befragten auch für den Einbezug von

Fachvertretern. Als weiteres Problem wird die

Fähigkeit der RE-Mitarbeiter genannt. Ein

Drittel der Unternehmen ist mit deren Skills

nicht zufrieden. Fachwissen sei zwar oft vor-

handen, der methodische Teil leide jedoch

sehr, geben die Befragten an.

Herausforderungen für RE-Mitarbeiter

Die RE-Mitarbeiter wiederum äussern als

grösste Herausforderungen die Sicherstellung

der Rückverfolgbarkeit mit 34 Prozent sowie

die Behandlung von Qualitätsanforderungen

(29,5 Prozent). Auch die Skills und Fähigkeiten

gehören zu den grössten Anforderungen im

RE, wie 28,7 Prozent der Befragten bestätigen.

Weiter wird die Verwaltung von mehr als 500

Anforderungen pro Projekt oder Produkt mit

28,4 Prozent genannt.

TRENDS TRENDS & BENCHMARKS IN SOFTWARE DEVELOPMENT REPORT 2014

ERHEBEN VON ANFORDERUNGEN

Wo sehen die Befragten Verbesserungspotenzial?

Basis: alle Befragten (n=500)

Quelle: Trends & Benchmarks in Software

Development Report 2014, SwissQ

Vereinfachung der visuellen Kommunikation (z.B. Visualisierung anstelle von UML-Modellen)

Einbezug von Fachvertretern

Einbezug von IT

Bereitschaft, Anforderungen während eines Kaffeegesprächs zu formulieren

Wechsel der Dokumentationsform während der Erhebungsphase

Gruppenarbeiten mit Rollenspielen

sehr hoch hoch mittel ungeplant

0 % 20 % 40 % 60 % 80 % 100 %

Artikel NETZWOCHE 11/2014 www.netzwoche.ch

Stakeholder Analyse

Einführung

Unsere Stakeholder sind zu einem grossen Teil Quelle und Treiber von Anforderungen.

Richtig mit ihnen umzugehen will gelernt sein.

In diesem Praxisseminar teilen unsere Experten ihr Praxiswissen zum Thema Stake-

holder Analyse gepaart mit wichtigen Punkten aus der Theorie. Wir zeigen auf, wie die

Begriffe Stakeholder, Stakeholder Analyse und -Management zusammenhängen und

welchen Mehrwert sie erzeugen können, wenn sie in Zukunft mehr als nur eine Liste

von Personen als Resultat der Stakeholder Analyse erzeugen.

Zielgruppe


Business Analysten


Ziele

Die Teilnehmer dieses Workshops erhalten einen Einblick in die Themen Stakeholder

Analyse und -Management und wissen, welche Herausforderungen und Hürden es in

diesem Gebiet gibt. Sie lernen praxisnahe Techniken, die sie in ihrem Alltag einsetzen

können.

Inhalt

Grundlagen & Begriffe Stakeholder Analyse

Stakeholder als Quellen von Anforderungen

4 Schritte zur Durchführung der Stakeholder Analyse

Prinzipien des Stakeholder Managements

Voraussetzungen

Grundlagen des Requirements Engineerings

Grundlagen Vorgehensmodelle der Software Entwicklung

Requirements 35

Sprache DE

Typ firmenintern

Dauer 1 Tag Code RESA

Requirements

Testing

Zertifizierungen

Agile

Roadmap to success | Foundation Level

Einführung

In diesem Kurs lernen die Teilnehmer, wie Anforderungen entwickelt und ver-

waltet werden. Sie erhalten Tipps, wie Anforderungen erhoben und dokumentiert

werden. Sie erfahren, wie die «Requirements Roadmap» zur Analyse von Requirements

verwendet wird und lernen, wie diese Inhalte in ihren Projekten einsetzen können. Zielgruppe

Projektleiter

Systemdesigner

Entwickler

Business Analysten

Projektmitarbeiter, die Anforderungen an IT Systeme stellen

oder interpretieren müssen Ziele

In diesem eLearning Modul werden in acht Lektionen die Grundlagen der Business

Analyse erklärt. Dieser Lehrgang wird durch das International Institute of Business

Analysis (IIBA™) empfohlen und auf die Task und Techniken des IIBA™ Business Analysis

Body of Knowledge (BABOK®) abgestützt. Teilnehmer dieses Lehrgangs erhalten 24 PDs

(Professional Development hours) für die initiale Zertifizierung oder 24 CDUs (Continu-

ing Development Units) für die Re-Zertifizierung.

Inhalt

Einführung in Anforderungen

Grundlagen für die Entwicklung von Anforderungen

Erheben von Anforderungen

Analyse von Anforderungen

Dokumentieren von Anforderungen

Prüfen von Anforderungen

Verwalten von Anforderungen

Anforderungs-Techniken an Ihre Situation anpassen Voraussetzungen

Mindestens 3 Jahre Berufserfahrung in den Bereichen Informatik, Organisation oder

Betriebswirtschaft

Requirements 37

Sprache EN

Typ eLearning

Dauer 1 Tag Code EBG-RSFL


Requirements

Testing

Zertifizierungen

Agile

Analyze and Specify Requirements

Einführung

In diesem 3-tägigen Intensivkurs werden die Grundlagen der Spezifikation von detail-

lierten Anforderungen – die entscheidende Aktivität, um erfolgreich Anforderungen

zu entwickeln – weiter ausgebaut. In kleinen Teams werden detaillierte Modelle als

Bestandteil von Anforderungsspezifikationen in praktischen Beispielen erarbeitet.

Zielgruppe

Zertifizierte Requirements Engineers – Foundation Level o. adäquate Zertifizierung

Projektleiter

Systemdesigner

Entwickler

Business Analysten

Ziele

Die Kursteilnehmer lernen, wie das Scope Modell mittels verschiedenen Modellie-

rungs-Techniken erweitert werden kann. Sie erfahren, wie Anforderungs-Model-

le definiert sowie detaillierte, funktionale und nicht-funktionale Anforderungen

geschrieben werden. Im Fokus stehen auch die Verbindungen zwischen den ver-

schiedenen Anforderungs-Typen. Dieser Lehrgang wird durch das International In-

stitute of Business Analysis (IIBA™) empfohlen und auf die Task und Techniken des

IIBA™ Business Analysis Body of Knowledge (BABOK®) abgestützt. Teilnehmer dieses

Lehrgangs erhalten 21 PDs (Professional Development hours) für die initiale Zer-

tifizierung oder 21 CDUs (Continuing Development Units) für die Re-Zertifizierung. Inhalt

Definieren von High-Level Produktanforderungen

Definition von detaillierten Produktanforderungen

Techniken zur Priorisierung von Anforderungen

Zusammenspiel der verschiedenen Anforderungstypen und Ebenen

Verwalten von verschiedenen Anforderungen

Dokumentationstechniken für Anforderungen

Prüfmethoden für Anforderungen Voraussetzungen

«EBGs Roadmap to Success: Scope Modeling» oder adäquate Kenntnisse

Requirements 38

Sprache EN

Typ firmenintern

Dauer 3 Tage Code EBG-ASRE


Requirements

Testing

Zertifizierungen

Agile

Get the right Stuff Fast Facilitated JAD Workshops

Einführung

In gestützten JAD (Joint Application Design) Workshops kreieren, prüfen und vervoll-

ständigen Teams wichtige Lieferobjekte von Projekten. Teams, welche die erlernten

Workshop-Techniken anwenden, verkürzen ihre Lieferzeit und verbessern die Quali-

tät ihrer Software. Dies wird möglich, da sie präzise Anforderungen definieren und

weitere qualitativ hochwertige Dokumente erstellen, welche die Projektplanung und

das Management unterstützen. In diesem praxisbezogenen Workshop lernen Sie die

Tools, Techniken und Vorlagen für die Planung und Durchführung von JAD Workshops

kennen. Die Teilnehmer lernen den Prozess und das Framework, von der Planung bis

hin zur Nachbearbeitung.

Zielgruppe


Projektleiter

Systemdesigner

Entwickler

Business Analysten

Ziele

In diesem sorgfältig entwickelten Kurs lernen die Teilnehmer in der idealen Umge-

bung durch Praxis-Beispiele, Diskussionen und diverse Übungen den Prozess und das

Framework hinter den JAD Workshops kennen.

Inhalt

Kernkonzepte der JAD Workshops

Anwendung der 6 Ps

Prüfung Ihrer JAD-Workshop Kompetenzen

Praktische Erfahrung aus simulierten Workshops

Referenztechniken für die Planung und Durchführung verschiedener Workshops

Erfolgsfaktoren komplexer Workshops Voraussetzungen

Mindestens 3 Jahre Berufserfahrung in den Bereichen Informatik, Organisation oder

Betriebswirtschaft

Requirements 39

Sprache EN

Typ firmenintern

Dauer 3 Tage Code EBG-JAD


Requirements

Testing

Zertifizierungen

Agile

Scope Modeling

Einführung

Dieser interaktive 2-Tageskurs erweitert Ihre Fähigkeiten im Scope Modeling, dem

entscheidenden ersten Schritt bei der Erstellung von Projektanforderungen. Die Teil-

nehmer lernen, wie sie auf der Basis von acht Anforderungsmodellen schnell Anforde-

rungen erheben, analysieren und dokumentieren, damit sie schnell und effizient die

Grenzen Ihres Projektes abstecken können. Diese Scope-Modelle ersetzen den «Ra-

te-Prozess» innerhalb der Projektplanungs-Aktivitäten und sind unersetzlich für spä-

tere detaillierte Analyse Modelle. Die gezeigten Modelle funktionieren für eine breite

Palette von Aufgaben wie das Starten von neuen Entwicklungsprojekten, Auswahl

von kommerziellen Software Lösungen und Erweiterung von bestehenden Systemen. Zielgruppe


Projektleiter

Systemdesigner

Entwickler

Business Analysten Ziele

Dieser Lehrgang wird durch das International Institute of Business Analysis (IIBA™)

empfohlen und auf die Task und Techniken des IIBA™ Business Analysis Body of

Knowledge (BABOK®) abgestützt. Teilnehmer dieses Lehrgangs erhalten 14 PDs (Pro-

fessional Development hours) für die initiale Zertifizierung oder 14 CDUs (Continuing

Development Units) für die Re-Zertifizierung.

Inhalt

Wirtschaftlicher Nutzen von Anforderungsentwicklung

Verständnis von Benutzeranforderungen

Idendifizierung und Auflistung der 4 Modell-Sichten

Benutzeranforderungen auf der Ebene Ziele

Erhebungstechniken

Verknüpfung und Vervollständigung von Zielen

Beschaffung und Erweiterung von Standardsoftware Voraussetzungen E-Learning Kurs «EBGs Roadmap to success | Foundation Level»

Requirements 40

Sprache EN

Typ firmenintern

Dauer 2 Tage Code EBG-SCM


Requirements

Testing

Zertifizierungen

Agile

Visual Facilitation Workshop

Einführung

Ein Bild sagt mehr als tausend Worte. Visual Facilitation kommt ursprünglich aus der

Welt der Bauvorhaben und der Architektur und wurde dort als «Problem Seeking»

Methode etabliert. Prinzipiell geht es darum, komplexe Systeme mit einfachen Sym-

bolen schnell und verständlich zu erklären. Die Kernaussage steht im Mittelpunkt und

wird entsprechend in Szene gesetzt. Genau diese Methode haben wir übernommen,

verfeinert und wenden sie erfolgreich in unseren Trainings, Anforderungs- und Test-

workshops an. Wir machen dies also nicht zum Selbstzweck, sondern um unsere eigene

Kommunikation um eine wichtige Dimension zu erweitern und Nachrichtenempfänger

visuell zu unterstützen.

Ziele

Die Kursteilnehmer lernen zunächst die Grundlagen und Symbole von Visual Facilitation

kennen und anwenden. Hauptziel ist es, neben dem Kennenlernen der Standards,

den Teilnehmern die Scheu vor dem Zeichnen zu nehmen. Neben der eigentlichen

Visualisierungstechnik lernen sie, wie Workshops einfach und effizient moderiert

werden können. Später werden in kleinen Gruppen die Struktur und der grafische

Aufbau von aussagekräftigen Flip-Charts erarbeitet. Der Teilnehmer kann nach dem

Workshop arbeitsspezifische Prozesse oder Arbeitsabläufe verständlich visualisieren.

Inhalt

Erste Schritte

Basis Elemente

Aufbau Visual Facilitation

Plakate erzählen Geschichten

Hilfsmittel

Spezifischer Einsatz von Visual Facilitation in den Tätigkeiten

Inklusive: 1 Starter Paket mit Stiften pro Teilnehmer. Als Resultat wird ein Fotoproto-

koll des Workshops erstellt.

Sprache DE/EN


Dauer 1 Tag Code VF

Requirements 42

Requirements

Testing

Zertifizierungen

Agile

Blog

Bedenken Sie immer folgendes: Kommen Sie auf den Punkt.

Grund 3: Einfach ist verständlich

In der Einfachheit liegt die Macht des Verständnisses. Bei

Symbolen ist unbedingt darauf zu achten, dass mit wenigen

Strichen ein aussagekräftiges «Bild» entsteht. Verzichten sie auf

unnötigen Schnörkel und Firlefanz. Punkt, Punkt, Komma, Strich –

Fertig ist das Lachgesicht.

Wer mit Organisationslehre zu tun hat, weiss, dass ich bei KISS

nicht von der Rockband spreche, sondern von Keep It Smart and

Simple. Eine Regel, welche bei Visual Facilitation auf jeden Fall

angewendet werden muss.

Grund 4: Ein Bild sagt mehr als tausend Worte

Für die Vision einen Leuchtturm oder ein Fernrohr, für die

Strategie einen Wegweiser und für die Produktion ein

Fabrikgebäude: entsprechende Symbole helfen dem Verständnis

Ihrer Stakeholder. Mit kleinen, aber feinen Unterschieden lassen

sich sämtliche Rollen in allen Arten von Projekten eindeutig

identifizieren. Der Kunde trägt eine Krone, der Projektleiter

einen Zylinder und der Testmanager eine Krawatte.

Wer auf keinen Fall an einen rosaroten Elefanten denken soll,

hat dieses Bild automatisch vor seinem inneren Auge, und wenn

in den Repetitions-Sessions eines Kurses ein Teilnehmer sagt,

«das war doch der mit der Fahne in der Hand», ist dies die beste

Bestätigung für Grund 4.

Grund 5: Jeder kann es anwenden

Selbst der talentloseste Leser dieses Blogs kann innerhalb von

wenigen Stunden Visual Facilitation lernen und anwenden. Was

es benötigt sind Flip-Charts, gute Marker, ein bisschen Übung

und den Mut, Ideen zu klauen, oder schöner: sich von anderen

Präsentationen und Symbolen inspirieren zu lassen.

Ausprobieren lohnt sich auf jeden Fall. Ihr Erfolg ist garantiert,

Sie heben sich unweigerlich vom Einheitsbrei ab und überzeugen

mit Kreativität, Individualität und Ihrem Bekenntnis zu Ihrer

Aussage.

Viel Spass! Marcel Rütschi, Principal Consultant und Trainer,

25.06.2013

Die Top 5 Gründe für Visual Facilitation

Sind Sie auch der exzessiven PowerPoint-Schlachten müde? Bei Prezi-Präsentationen wird Ihnen schlecht, weil Sie sich wie auf einer Achterbahnfahrt fühlen? Die technischen Er-rungenschaften bieten schier unendlich viele Möglichkeiten, schreckliche und inhaltslose Präsentationen zu erstellen. Es steht nicht mehr die Kernaussage, sondern die sexy Aufbereitung der mit Animationen überhäuften Ergüsse von sogenannten Präsentatoren im Vordergrund. Auf der Strecke bleibt immer der einst geneigte Zuhörer, welchem flatternde Buchstaben und sich drehende Elemente um die Ohren geschlagen beziehungsweise aufs Auge gedrückt werden. Der bewusste Schritt zurück ergab schon immer eine bessere Sicht auf das sogenannte Ganze. Wagen Sie diesen Schritt zurück, und zwar auch in der angewendeten Technologie. Verwenden Sie wieder Papier und Schreiber und verleihen Sie Ihren Aussagen in Ihrer Präsentation Ihre persönliche Note – Ihre Handschrift.

Grund 1: Individualität durch die persönliche Note

Zeichnen Sie doch Ihre Protagonisten selber auf. Verzichten Sie auf herzlose 3D-Avatare, welche mit roten Nasen und orangenen Perücken Clowns darstellen. Ein Kreis dient als Kopf und der Korpus kann simpel als Viereck, Halbkreis oder rea-litätsnaher mit Extremitäten wie Arme und Beine gezeichnet werden.

Eine Spielf igur wie aus «Mensch ärgere Dich nicht» ist einfach gezeichnet und ärgert einen Zuhörer sicher weniger als die perfekten, aalglatten Figuren aus den Grafikküchen von Software-Grosskonzernen. Natürlich, es gehört Überwindung und Übung dazu, aber Sie verleihen durch gezeichnete Stakeholder automatisch eine gewisse Menschlichkeit.

Grund 2: Endlich wieder zur Sache kommen

Bei Visual Facilitation besteht keinerlei Anspruch auf künstlerische Höhenflüge. Es geht darum, sich auf die Kernaussage zu reduzieren. Das Wesentliche muss erfasst und vermittelt werden. Dabei helfen eine Struktur und kurze, prägnante Aussagen in sogenannten Containern auf dem grossen weissen Flip-Chartpapier.

Alles was Sie jetzt noch zu tun haben, ist Ihre Geschichte spannend und verbal zu vervollständigen. Sie brauchen sich nicht hinter technisch überfüllten Slides zu verstecken!

Erfolg mit Punkt, Punkt, Komma, Strich

Testing 44

Software-Testing für Manager 45

Projekt Management für Test Manager 46

Soft Skills in Testing 48

Testdesign in der Praxis 49

Session Based Testing 50

Best Performance Test Implementation 53

Best Practices in Test Automation 54

Manage Outsourced SW-Testing 57

Siehe auch Testing Kurse unter «Agile», Seite 16

Siehe auch Testing Kurse unter «Zertifizierung», Seite 58

Kursangebot

Testing

Software-Testing für Manager

Einführung

Seit einiger Zeit werden die meisten Projekte durch dedizierte Testteams unterstützt.

Was kann ein Projektleiter von einem Testteam und/oder einem Test Manager erwar-

ten? Nach welchen Prinzipien arbeiten diese?

In diesem Kurs bekommen Personen in Führungsfunktion kompakt die Grundlagen

des Software Testens auf Management- Ebene vermittelt.

Zielgruppe

Projektleiter

Personen in Führungsfunktionen

Manager

Ziele

Sie lernen die Grundlagen und Vorgehensweisen von Software Tests kennen, inklusive

den wichtigsten Normen und Standards in diesem Bereich. Sie verstehen die Sprache

der Software Tester und wissen, was Sie von einer Testorganisation erwarten können.

Inhalt

Der Testprozess

Managementrelevante Dokumentation

Erwartungen an und Umgang mit den Testressourcen

Äussere Einflussfaktoren auf Software Testing

Voraussetzungen

Basiswissen des IT-Managements, sowie grundlegende Kenntnisse des Software-Ent-

wicklungsprozesses

Testing 45

Sprache DE/EN

Typ firmenintern

Dauer 0,5 Tag Code STMA

Requirements

Testing

Zertifizierungen

Agile

Projekt Management für Test Manager

Einführung

Dieser Kurs beleuchtet die wichtigsten Themen aus dem Bereich Projektmanagement,

die jeder Testmanager kennen muss, um ein erfolgreiches Abschliessen des Testpro-

jektes gewährleisten zu können.

Heute reicht es nicht mehr aus, den Testprozess zu kennen und anwenden zu können.

Der Umgang mit allen Stakeholdern und die richtige Einschätzung des Testaufwandes

sind elementare Aufgaben, die der Test Manager beherrschen muss.

Zielgruppe

Test Manager

Ziele

Dieser Kurs ermöglicht dem Test Manager ein vollumfängliches Projektmanagement

für sein Teilprojekt. Anhand von Praxisbeispielen werden die wichtigsten Aspekte der

Projektleitung mit Fokus auf Testing beleuchtet.

Inhalt

Stakeholder-Analyse

Risiko-Management

Aufwandschätzung

Planung und Tracking

Testing 46

Sprache DE

Typ firmenintern

Dauer 2 Tage Code PMTM

Requirements

Testing

Zertifizierungen

Agile

Blog

Um das Testmanagement für ein Projekt so umfassend wie nötig, gleichzeitig aber so einfach wie möglich zu gestalten benötigen wir Hilfsmittel, welche weit über die gängigen Funktionen einer Text-verarbeitungs- oder Tabellenkalkulationssoftware hinausgehen.

Wir Consultants von SwissQ verwenden üblicherweise das bei unseren Kunden bereits im Einsatz stehende Testmanagement-Tool. Hat der Kunde jedoch kein solches Instrument zur Hand, schlagen wir ein geeignetes oder ein uns bekanntes Produkt zur Unter- stützung vor. Genau so verhält es sich bei einem aktuellen Projekt eines grossen Transportunternehmens, bei welchem SwissQ für die Durchführung der User Acceptance Tests einer Systemerweiterung beauftragt wurde. Ich bin als Tester ein Teil des von SwissQ gestellten dreiköpfigen Testteams. Wir arbeiten eng mit den Ansprechpartnern unseres Kunden zusammen. Aus diesem Grund legen wir grossen Wert darauf, dass uns das Testmanagement-Tool in allen Bereichen des Testmanagements, der Zusammenarbeit sowie der Testdurchführung optimal unterstützt. Ein nützliches Testmanagement-Tool sollte über folgende Eigenschaften verfügen:

Gemeinsames Requirements- und Testfall-Repository Bereitstellung und Organisation von umfangreichen

(Test-)Daten Vereinfachte Zusammenarbeit im Team/Projekt (Collaboration) Ortsunabhängiger Zugriff auf das System Integration von Test- und Reporting-Tools Abbildung von Prozessen und Standards Benutzerfreundliche und intuitive Oberfläche

Um unseren Nutzen aus dem Tool zu maximieren haben wir darauf geachtet, dass Funktionen wie das Verknüpfen verschiedener Work Items, das Bilden von Testsuiten, die eindeutige Zuweisung an ver-antwortliche Tester sowie die Verwaltung und Auswertung bereits durchgeführter Testläufe möglich ist. Unterstützt uns das Tool zu-sätzlich bei der Erstellung aussagekräftiger Reports und können die festgestellten Defects gesammelt und priorisiert werden, so erfüllt das Tool bereits unsere wesentlichsten Anforderungen.

Der gezielte Einsatz einer solchen Anwendung zahlt sich oftmals bereits nach kurzer Projektzeit aus. Bedingung dafür ist natürlich, dass die eingesetzte Lösung auf die individuellen Bedürfnisse des Projekts eingestellt wird. Aus der Fülle von Produkten und Anbietern aber das richtige Werkzeug zu finden ist gar nicht so einfach. Wähle ich ein Open Source-Tool, eine SaaS-Lösung oder doch eine etablierte und weit verbreitete kommerzielle Software eines renommierten Anbieters? In den nachfolgenden Abschnitten heben wir die Vor- und Nachteile der vorhandenen Produktgruppen hervor und beschreiben, wie wir für ein Projekt die optimale Lösung evaluiert haben.

Wie finde ich die optimale Testmanagement-Software?

Open Source

Open Source-Tools bestechen durch ihre hohe Flexibilität und An-passbarkeit. Nicht zu vergessen ist die unschlagbare preisliche Komponente. Nachteile sind wohl, dass einerseits keine ordent-lichen Updates erfolgen und durch die selbst vorgenommenen Anpassungen möglicherweise ein erheblicher Aufwand bei der Wartung entstehen kann. Nachfolgend finden Sie eine kleine Auswahl von Open Source Tools:*

-- TestLink -- Bugzilla Testopia -- Mantis Bug Tracker -- Testia Tarantula

Software as a Service (SaaS)

Lösungen, welche als Service angeboten werden, beherbergen einige positive Eigenschaften. Einerseits muss weder für die geeignete technische Infrastruktur, noch für Datensicherungen und Datensicherheit gesorgt werden. Andererseits kann der Service bei vielen Anbietern zeitnah wieder gekündigt bzw. auch nur für eine bestimmte Zeit abonniert werden. Vor allem für projektbezogene, klar terminierte Aufgaben könnte sich die Wahl eines solchen Services anbieten. Nachfolgend einige Tools welche als Service angeboten werden:* -- Practitest -- Testwave -- Gurock TestRail -- Testuff -- Qmetry -- QA Symphony qTest

Kommerzielles Testmanagement-Tool

Kommerzielle Testmanagement-Anwendungen zeichnen sich bei mehreren Faktoren aus. Unter anderem sicherlich mit den umfangreichen und tiefgreifenden Funktionen. So bildet eine ausgewachsene Applikation den gesamten Lebenszyklus eines Produktes von der Entstehung bis zur Stilllegung ab. Ein kritischer Faktor könnten hierbei die tendenziell hohen Kosten für die Lizenzen sein. Nachfolgend einige Tools dieser Kategorie:* -- HP Quality Center/ALM -- Tricentis Tosca Testsuite -- Microsoft Testmanager -- IBM Rational Quality Manager -- Polarion ALM

Unter diesem Link auf den aktuellen Trendreport 2014 bezüglich Agilität, Testing und Requirements Engineering finden Sie auch die Markterhebung über die Verbreitung der Testmanagement- Tools in der Schweiz.

Alain Weibel, Senior Consultant, 03.04.2014

* Auswahl nicht abschliessend

Den vollständigen Blog können Sie nachlesen auf www.Swissq.it/wie-finde-ich-die-optimale-testmanagement-software/

Soft Skills in Testing

Einführung

Zu den Aufgaben eines Test Managers zählen nebst den klassischen Methodik-Tasks

grosse Teile von Soft-Skill-Management-Funktionen. Zum Beispiel: Das Test Kick-Off

Meeting, die Einladung und Präsentation dazu, eine Zusammenfassung und even-

tuelle Punkte, die nachgeliefert werden. Eine Auswahl an Kommunikations-Punk-

ten, welche mündlich und schriftlich vermittelt werden. Die wichtigen Informationen

müssen zum richtigen Zeitpunkt an die relevanten Projektmitarbeiter verständlich

kommuniziert werden.

Zielgruppe

Test Manager

Tester

Ziele

Nach diesem Kurs kann der Teilnehmer effektiv und zielgerichtet kommunizieren. Er

versteht die Wichtigkeit von Informationen, weiss diese zu priorisieren und die daraus

resultierenden Inhalte entsprechend zu vermitteln. Die verständliche Informations-

vermittlung in schriftlicher wie auch mündlicher Form ist Ziel dieses Trainings.

Inhalt

Kommunikation

Stakeholder-Management

Time Management

Arbeitseinteilung

Testing 48

Sprache DE/EN

Typ firmenintern

Dauer 1 Tag Code SST

Requirements

Testing

Zertifizierungen

Agile

Testdesign in der Praxis

Einführung

Beim Testdesign hat der Tester im Grunde eine ähnliche Aufgabe wie die Systemar-

chitekten und Entwickler: aus Anforderungen vollständige und eindeutige Testfälle

zu ermitteln. Das direkte Ableiten der Testfälle aus den Anforderungen hat viele Vor-

teile. Es erlaubt unter anderem, Aussagen über die Testabdeckung dieser Anforde-

rungen zu machen. Ausserdem wird offensichtlich, welche Testfälle bei der Änderung

einer Anforderung angepasst werden müssen. Zudem kann durch eine frühzeitige und

systematische Testvorbereitung die Qualität der Anforderungen gesteigert werden.

Zielgruppe

Test Designer/ Tester

Personen, die mit Testfällen für höhere Teststufen (Systemtest, Abnahmetest)

in Berührung kommen

Ziele

In diesem Seminar wird aufgezeigt, wie aufgrund von Anforderungen Testfälle erstellt

werden, die systematisch die wichtigen Aspekte des Softwaresystems abdecken.

Inhalt

Anforderungen an Anforderungen

Abnahmekriterien

Methoden zur Testfallermittlung

Dokumentation von Testfällen

Nicht-Funktionale Tests

Testing 49

Sprache DE

Typ firmenintern

Dauer 2 Tage Code TDiP

Requirements

Testing

Zertifizierungen

Agile

Session Based Testing

Einführung

Session Based Testing ist eine Vorgehensweise beim Testen, bei der die Testaktivitäten

– insbesondere Testdesign und Testdurchführung – als unterbrechungsfreie Sitzungen

geplant werden. Oft findet man es in Verbindung mit Explorativem Testen. Obwohl

ohne dokumentierte Testfälle getestet wird (z.B. aufgrund unzureichender Anforde-

rungen), entsteht eine transparente und nachvollziehbare Testdokumentation. Eine

Einbettung in einen formalen Testprozess ist so ohne weiteres möglich.

Zielgruppe

Test Manager

Projektleiter

Ziele

Die Teilnehmer lernen, was der Ansatz des Session Based Test Managements ist, woher

er kommt und wie dieser in der Praxis angewandt wird. Nach dem Kurs ist den Teil-

nehmern bewusst, welche Vorteile/Nachteile Session Based Test Management hat und

wie es zusammen mit Explorativem Testen optimal eingesetzt werden kann.

Inhalt

Grundlagen Session Based Testing

Zusammenspiel mit Explorativem Testen und Risikobasiertem Testen

Nutzen von Session Based Testing

Dokumentation und Reporting

Einbettung von Session Based Testing im formalen Testprozess

Praktische Übungen

Testing 50

Sprache DE

Typ firmenintern

Dauer 1 Tag Code SBTE

Requirements

Testing

Zertifizierungen

Agile

Blog

Last- und Performancetest

Wie gehe ich das an? Der Übergang vom Proof of Concept in die nächste Phase des Projektes erfolgt nicht automatisch. Der PoC muss ein Quality Gate (Q-Gate) überwinden. Das Q-Gate beinhaltet die Analyse und Bewertung der bisherigen Ergebnisse, die Diskussion der sich daraus ergebenden Detailplanung und deren Auswirkungen auf das Projektbudget. Zusammen mit dem Kunden arbeiten wir auf eine Go/NoGo-Entscheidung für die Umsetzung des Pro- jektes hin. Es kommt häufiger vor, dass Projektziele oder -budgets angepasst werden, als dass die Leistungstests bereits nach dem PoC beendet werden.

«Ich persönlich halte den Proof of Concept für eine der wichtigsten Komponenten erfolgreicher Last- und Performance- Testprojekte. Mit ihm gewinne ich mehr Sicherheit und gehe die Projekte effizienter an, als wenn ich mich direkt in das«kalte Wasser»stürze.» (Niko Messerschmidt)

Häufig entdecken wir «Stolpersteine», die zu Beginn nicht sichtbar waren und Einfluss auf die Testdurchführung haben.

Gute Vorbereitung ist das A und O

Nach der Entscheidung, das Testprojekt umzusetzen, kann die Vorbereitungsphase starten. In dieser Phase konzentriert man sich auf:

• Kick-Off mit dem Team und weiteren Stakeholdern • das Setup der Testinfrastruktur (z.B. Systemzugänge, Monitoring) • Testdaten und Test-Skripte erstellen • Abgleich der Testszenarien mit dem Kunden/Business • Planung der Tests mit dem Team

Während der Entwicklung der Last-Skripte prüfen wir mit einigen wenigen virtuellen Nutzern, ob die implementierten Szenarien erfolgreich durchlaufen werden. Ausserdem prüfen wir die einwandfreie Funktionsweise im Fall der parallelen Abarbeitung.

Die Auslastung von Subsystemen bekommen wir hauptsächlich von Überwachungssystemen, die bereits beim Kunden eingesetzt werden oder die vom Lasttesttool mitgeliefert werden. Für uns ist das Monitoring ein zentraler Aspekt für gute Last- und Performance-Tests.

Ein weiterer wichtiger Bestandteil während der Testvorbereitung ist die Kommunikation. Es beginnt mit dem Kennenlernen der Stakeholder. Diejenigen von ihnen, die aktiv am Test mitwirken, bilden das Testteam. Die Entwickler gehören idealerweise auch dazu. Mit dem Team sind wir fast täglich in Kontakt. Damit wir die Ziele des Kunden genau verstehen und keine Missverständ-nisse aufkommen, kommunizieren wir anfangs intensiv mit ihnen. Uns ist es ein Bedürfnis, dass wir nicht nur LuP-Tests durchführen – sie sollen zielgerichtet sein und den Bedarf des Kunden decken.

Niko Messerschmidt, Senior Consultant, 16.12.2013

kommunizieren wir mit ihnen. Uns ist es ein

Bedürfnis, dass wir nicht nur LuP-Tests sein

Den vollständigen Blog können Sie nachlesen auf www.Swissq.it/last-und-performancetest-teil-2-wie-gehe-ich-das-an/

In unserer beruflichen Vergangenheit wurden wir des Öfteren im

ersten Kundengespräch mit der Frage konfrontiert: «Wie gut ken-

nen Sie sich mit dem Tool Loadrunner aus?»

Bei solch einer Frage erläutern wir dem Kunden, dass wir eine

Vielzahl an Werkzeugen kennen. Entscheidend für den Erfolg ist

aber nicht das Tool, sondern das Wissen, wie solche Tests vorbe-

reitet und durchgeführt werden. Da ist das Werkzeug nur ein Be-

standteil des Prozesses, in das wir uns als Engineers oft in kurzer

Zeit einarbeiten. Das Tool sagt einem aber nicht, wie man Last-

und Performance- Testprojekte zum Erfolg bringt, sondern es ist

nur Mittel zum Zweck.

Unsere Erfahrungen zeigen, dass ein methodisches Vorgehen und

das frühzeitige Erkennen von Hindernissen entscheidend für den

Erfolg sind. Mit welcher Methodik wir von der SwissQ LuP- (Last-

und Performance-) Tests erfolgreich meistern, zeigen wir in diesem

Beitrag.

Dass unsere Vorgehensweise erfolgreich ist, zeigt folgendes Beispiel

aus der Praxis: Eines Tages bekamen wir den Auftrag, bei einem

unserer Kunden Last- und Performance-Tests einer Webanwendung

durchzuführen. In der Vergangenheit gab es mehrere Versuche, die

Anwendung unter Last zu testen, die jedoch alle gescheitert waren.

Hier konnten wir nun unter Beweis stellen, dass wir auch unter

schwierigen Bedingungen Resultate liefern können.

Der Grund für diesen Erfolg war neben unseren eigenen Erfahrun-

gen sicher die methodische Vorgehensweise bei Leistungstest-Pro-

jekten. Dieses Bild stellt die Phasen dieses Vorgehensmodells dar:

Wir als Performancetest-En-gineers bei SwissQ greifen damit auf ein erprobtes Vorgehen zu-rück, welches bei verschiedenen Kunden in unterschiedlichen Branchen erfolgreich war und ist. Mit unserer Methodik kön-nen wir schnell auf die indivi-duellen Situationen bei Kunden reagieren und die optimalen Schritte festlegen.

Der PoC – «Drum prüfe, wer sich ewig bindet»

Eingangs erwähnten wir, dass die Werkzeuge zur Lastgenerierung,

Antwortzeitmessung, Monitoring etc. Bestandteile unserer Methodik sind. Mit geeigneten Tools können Kosten gespart

werden. Ihr Einfluss ist jedoch nicht so gross, dass sich unsere

Methodik ändern würde. Insbesondere das Monitoring wirkt sich

stark auf den Projektaufwand aus.

Damit wir uns ein Bild: • vom Kundenumfeld • von der Infrastruktur (insbesondere den Monitoring-Möglichkeiten)

• vom Umfang an Entwicklungs-Aktivitäten • und von eventuellen Hindernissen machen können, starten wir mit einem Proof of Concept (PoC).

Diesen führen wir an 1 – 2 ausgewählten Geschäftsprozessen durch.

Solch eine Überprüfung hat für beide Parteien einen positiven

Effekt:

Der Kunde «opfert» einen kleinen Teil des verfügbaren Budgets

und erhält mehr Sicherheit für ein erfolgreiches Projekt.

Wir sehen in kurzer Zeit, welche Hindernisse auf uns zukommen

werden und können das Vorgehen mit dem Kunden besprechen und planen.

Wir als Performancetest-En-gineers bei SwissQ greifen damit auf ein erprobtes Vorgehen zu-

reagieren und die optimalen Schritte festlegen.

an, als wenn ich mich direkt in das«kalte Wasser»stürze.»Wasser»stürze.»Wasser»stürze.»

Best Performance Test Implementation

Einführung

Die aktuelle Trends- und Benchmarks-Befragung von Mitgliedern der Schweizer Tes-

ting-Community zeigt, dass bereits bei der Hälfte der Befragten «Last- und Perfor-

mance-Test» im Testingbereich ein Thema ist. Jeder Tester wird wohl früher oder

später mit Tests auf Effizienz konfrontiert. Was sich in der Theorie als scheinbar un-

problematisch beschreibt, wird in praktisch jedem Projekt zu einem langwierigen und

komplizierten Thema. Jeder Stakeholder versteht unter Performanz eines Systems et-

was anderes. Darum ist eine angemessene Strategie und das passende Vorgehen der

Schlüssel zum Erfolg.

Zielgruppe

Test Manager

Test Designer/ Tester

Personen und Rollen, welche mit Performance Testing in Berührung kommen

Ziele

Nach diesem Kurs kann der Teilnehmer Anforderungen zum Qualitätsmerkmal Effizi-

enz bewerten und notwendige Verbesserungen der Qualität solcher Anforderungen

identifizieren. Anhand unseres Vorgehensmodells, dessen einzelne Phasen detailliert

behandelt werden, lernt der Kursteilnehmer das prinzipielle Vorgehen bei Last- und

Performance-Tests kennen. Er wird künftig die passende Vorgehensweise für seine

Projekte auswählen können. Die Planung und die angemessene Umsetzung ist ein

grosser Teil dieses Trainings.

Inhalt

Grundlagen Performance Testing

Stakeholder-Management im Performance Testing

Vorgehensmodell für Tests auf Effizienz

Auswertung und Bewertung von Testresultaten

Best Practice Performance Testing

Testing 53

Sprache DE

Typ firmenintern

Dauer 1 Tag Code BPTI

Requirements

Testing

Zertifizierungen

Agile

Best Practices in Test Automation

Einführung

Möchten Sie erfolgreich Testautomatisierung in Ihrer Organisation einführen, wollen

Sie die bestehende Testautomatisierung auf ein höheres Niveau bringen oder haben

Sie Schwierigkeiten mit einer stabilen und zuverlässigen Testautomatisierung? Dann

ist dieser Kurs genau das richtige für Sie. Es werden die Voraussetzungen, das Vorge-

hen als auch die Herausforderungen der Testautomatisierung aufgezeigt und detail-

liert besprochen.

Zielgruppe

Test Engineers/ Test-Automatisierer

Test Designer

Entwickler

Personen und Rollen, welche mit Testautomatisierung in Berührung kommen

Ziele

Nach dem Kurs kann der Teilnehmer die verschiedenen Arten der Testautomatisierung

unterscheiden. Er kennt das Best Practice Vorgehen der Testautomatisierung und ist

sich den «Stolpersteinen» (Pit-Falls) bei der Testautomatisierung bewusst.

Inhalt

Grundlagen Testautomatisierung

Best-Practice Ansatz in der Testautomatisierung

Voraussetzungen und Vorgehen/Methode der Testautomatisierung

Pit-falls der Testautomatisierung

Testing 54

Sprache DE

Typ firmenintern

Dauer 1 Tag Code BPTA

Requirements

Testing

Zertifizierungen

Agile

Blog

Finanzieller Nutzen von Testautomation

Dieses Projekt ist ein Musterbeispiel für den Mehr-wert, welchen Testautomation liefern kann. Bei rund 300.000 Produkten ist unmittelbar klar, dass ein wie-derholter, vollständiger manueller Test nicht möglich ist. Folglich hätte man mittels risikobsiertem Ansatz eine Analyse machen und eine Stichprobe auswählen müssen – mit Restrisiko.

Die Automation war an dieser Stelle einfach (=kostengünstig), da man sich komplett auf Schnittstellenebene bewegt hat. Die Tests haben rein lesend stattgefunden. Da die Testdaten, in Form des CSV-Exports, nächtlich frisch generiert wurden, waren sie auch immer aktuell. Dies ist keineswegs selbst- verständlich. Testautomatisierer sind häufig auf alte oder unregelmässig wechselnde Testdaten angewiesen, ein Umstand der die Automatisierung deutlich verteuern kann.

FAZIT

Es lohnt sich immer, zu Beginn von IT Projekten über die benötigten Testdaten nachzudenken. Mit ein wenig Kreativität und Erfahrung kann man in den meisten Fällen intelligente Lösungen finden, welche die Qua-lität der Tests massiv erhöhen – bzw. manche Tests überhaupt erst möglich machen.

Stephan Wiesner, Principal Consultant, 10.04.2014

Stephan Wiesner ist Principal Consultant der SwissQ Consulting AG und vielfach in agilen Projekten als Testmanager unterwegs. Er veröffentlicht regelmässig Fachbücher und -artikel und tritt als Sprecher auf Software- konferenzen auf, wie beispielsweise dem Swiss Testing Day. Seine Spezialitäten liegen im Bereich Mobile Development (Android und iOS), Testautomation und Performanztests.

Die Erzeugung und Verwendung von Testdaten spielen im Software-Test eine sehr wichtige Rolle. Sie werden sowohl für manuelle, als auch für automatisierte Tests benötigt. Jedoch erlangen sie nur selten zum Projektstart die Bedeutung, welche sie verdienen. In diesem Artikel stellen wir anhand von einem Praxisbeispiel Möglichkeiten vor, wie man Testdaten erzeugen und beherrschen kann.

In zwei weiteren Artikeln zeigen wir weitere Beispiele auf und gehen auf die Theorie der Testdaten ein.

Praxisbeispiel Testorakel bei einem Detailhändler

Viele Softwareprojekte können auf ein Altsystem oder ein bestehendes Produktionssystem, das als Testorakel für die (manuellen oder automatischen) Tests dienen kann, zurückgreifen. Dies kann man sich auch für die Testauto-mation zu Nutze machen, wie das folgende Praxisbeispiel zeigt.

In dem Projekt für einen grossen Detailhändler wurde eine einheitliche, moderne API auf ein bestehendes SAP System entwickelt, mit dem Ziel ausgewählte Produkte für verschiedene Frontends (Web, Android, iOS) zur Verfügung zu stellen. Die Grafik zeigt dies schematisch.

Ziel des Tests war es, diese API auf Vollständigkeit und Korrektheit zu testen. Da es bereits einen existierenden Export des SAP-Warenkatalogs gab, wurde beschlossen, diese CSV-Datei als Basis, und somit als Testorakel, für den Ver-gleichstest zu verwenden. Vereinfacht gesagt wurde

Die CSV Datei zeilenweise durchlaufen (jede Zeile = ein Produkt)

Für jeden Eintrag (wahlweise für zufällige Einträge) wurde geprüft, ob das Produkt über die API kam und ob die vorhandenen Werte/ Eigenschaften (z.B. Preis) korrekt waren

Gefundene Abweichungen wurden wiederum in einer CSV-Datei mit den entsprechenden IDs, erwartetem Wert und vorgefundenem Wert gespeichert. Somit war die Fehleranalyse relativ einfach

Einmalig pro Durchlauf wurde die Anzahl abgefragt und mit der erwarteten Anzahl verglichen (Vollständigkeit)

Wie beherrscht man Testdaten für Testautomation erfolgreich?

Die Grafik zeigt die

schematische Darstellung

der Systemarchitektur

und die Position des

Testautomatisierungs

Frameworks

Manage Outsourced SW-Testing

Einführung

Es klingt sehr verlockend, Testaktivitäten auszulagern, aber bei welchen lohnt es sich?

Gibt es welche, die nicht an eine andere Firma übertragen werden dürfen? Macht es

Sinn, weiterhin Tests selbst durchzuführen?

In diesem Seminar erhalten die Teilnehmer das Grundlagenwissen, wie die Auslage-

rung von Testaktivitäten konzipiert, geplant, vertraglich abgesichert und implemen-

tiert werden muss.

Zielgruppe

IT-Leiter

Test Manager

Projektleiter

Qualitätsbeauftragte

Ziele

Die Kursteilnehmer lernen, welche Ziele und Erwartungen im Zusammenhang mit Test

Outsourcing realistisch sind, welche Risiken lauern und was sie unternehmen müssen,

um dafür gewappnet zu sein. Ausserdem kennen sie Werkzeuge, Metriken und Me-

thoden, die ihnen dabei helfen, eine erfolgreiche Outsourcing-Beziehung aufzubauen

und zu pflegen.

Voraussetzungen

Basiswissen des IT-Managements, sowie grundlegende Kenntnisse des Software-Ent-

wicklungsprozesses

Testing 57

Sprache DE

Typ firmenintern

Dauer 3 Tage Code MOST

Requirements

Testing

Zertifizierungen

Agile

Zertifizierungen 58

ZertifizierungeniSQI® Certified Agile Business Analysis 60

Certified ScrumMaster ScrumAlliance® 62

Certified Scrum Product Owner ScrumAlliance® 63

ISTQB® Agile Tester 66

IREB® CPRE | Foundation Level 68

IREB® CPRE | Advanced Level – Elicitation & Consolidation 70

IREB® CPRE | Advanced Level – Requirements Modeling 71

ISTQB® Certified Tester | Foundation Level 72

ISTQB® Certified Tester | Advanced Level – Test Manager 73

ISTQB® Certified Tester | Advanced Level – Test Analyst 74

ISTQB® Certified Tester | Advanced Level – Technical Test Analyst 75

ISTQB® Certified Tester | Expert Level – Improving the Test Process | Part 1 76

ISTQB® Certified Tester | Expert Level – Improving the Test Process | Part 2 78

NEU

NEU

NEU

NEU

Artikel NETZWOCHE 03/2014 www.netzwoche.ch

Requirements Engineering (RE) ist die Basis eines jeden Softwareprojekts, sei es nun die Weiterentwicklung einer be-stehenden Software oder eine Neuent-wicklung. Gleichzeitig ist RE oft auch Sorgenkind der Softwarebranche. SwissQ hat im aktuellen Trends & Benchmarks Report Schweiz 2013 die Schwierigkei-ten, Möglichkeiten und Entwicklungen im RE untersucht und bietet damit eine Möglichkeit, die eigenen Beobachtungen mit deren anderer Unternehmen zu ver-gleichen.

Die Datenbasis für die Studie bilden einerseits eine Onlineumfrage aus 580 ausgefüllten Fragebogen und anderer-seits rund 25 persönliche Interviews mit IT-Entscheidungsträgern aus unterschied-lichen Firmen, Branchen und Regionen. Neu führte SwissQ die diesjährige Studie zu den Trends & Benchmarks in Kooperation mit dem Institut für Technologiemanagement der Uni-versität St. Gallen durch.

Die Art der ProjekteWas die IT-Projekte betrifft, hat sich einer-seits die Anzahl der Neuentwicklungen im Vergleich zum Vorjahr reduziert. Andererseits gibt es immer mehr Grossprojekte. Dies hat laut den Autoren der Studie wohl damit zu tun, dass immer weniger Vorhaben auf der grünen Wiese starten. Entweder würden bestehende Lösungen erweitert oder komplett neu gebaut.

Was die Qualität betrifft, hat sich das Pro-blem der Missverständnisse in der Kommu-nikation verschärft. Zusammen mit den sich ändernden Anforderungen oder mit dem Zeitmangel bezüglich des RE sind dies die wichtigsten Probleme im Bereich der Anforde-rungsanalyse. Letzteres wird durch die Ergeb-nisse der Studie bestätigt: Rund drei Fünftel aller Befragten wenden weniger als 15 Pro-zent des Gesamtprojektaufwandes für RE auf. Hinzu kommt, dass gut zwei Fünftel der Be-fragten den Reifegrad ihres RE als mittelmäs-sig oder schwach einstufen. Auch zeigt sich die Mehrheit der Befragten mit dem Erheben, Analysieren, Dokumentieren, Prüfen und Ver-

walten von Anforderungen unzufrieden oder nur mässig zufrieden. Wie aber kann man die Qualität verbessern?

Als Massnahmen sehen mehr als die Hälfte der Befragten am ehesten die Etablie-rung interner Vorlagen und Normen. Rund die Hälfte will intern aus- und weiterbilden sowie gezielt geeignetes Personal einstellen. Dies zeigt sich auch in den Trends für die kommen-den Jahre: Rund ein Viertel der Befragten gibt die Aus- und Weiterbildung im RE als oberste Priorität an. Agile Requirements Engineering, die Etablierung von Standardprozessen sowie Business Process Driven Requirements stehen ebenfalls hoch im Kurs. Ein ähnliches Bild zeichnet sich auch in den Investitionen ab. In der Zusammenarbeit zwischen IT und Busi-ness nehmen die Investitionen zu, genauso wie in der Aus- und Weiterbildung für Mitar-beiter sowie der Entwicklung von Vorlagen und Richtlinien.

Wie werden Anforderungen analysiert?Für die Analyse der Anforderungen werden meistens bestehende Systeme analysiert, wie rund 70 Prozent der Befragten angeben. Rund zwei Drittel führen Interviews, etwas mehr als die Hälfte strukturierte Workshops durch. Was die Spezifikation der Anforderungen be-trifft, sind Use Cases die am meisten verbrei-tete Technik. Mehr als die Hälfte der Befragten

setzt sie ein. Knapp dahinter folgt die na-türliche Sprache, gefolgt von gut einem Drittel, das mit User Stories arbeitet.

Ein weiterer Aspekt, der in der Stu-die behandelt wird, sind die Herausfor-derungen, die sich den Unternehmen in Bezug auf RE stellen. Gut zwei Fünftel der Befragten nennen hier das Anforde-rungsmanagement beziehungsweise die Rückverfolgbarkeit der Anforderungen. Knapp ein Drittel nennt je die Erhebung, Verwaltung der Anforderungen sowie deren Verteilung auf die verschiedenen Teams. Hinzu kommen die Behandlung von nicht-funktionalen Anforderungen sowie die Umsetzung von RE in agilen Projekten.

Haben es Unternehmen aber einmal ge-schafft, RE im agilen Umfeld einzusetzen, scheint dies einige Vorteile mit sich zu brin-gen: Beispielsweise ist eine grosse Mehrheit der Befragten der Meinung, dass man jederzeit oder zumindest meistens im Überblick habe, was gerade implementiert werde. Ausserdem seien die Stakeholder stärker involviert und die Änderungen im Backlog brauchten keinen formalen Change-Prozess mehr. Auch sei der Umfang der Spezifikation deutlich geringer geworden, was auf eine Vereinfachung hin-deutet.

Auch interessant sind die verwendeten RE-Tools. Microsoft Word und Excel werden am häufigsten verwendet, sei es nun im agi-len oder nicht agilen Umfeld. Sie haben aber im Vergleich zum letzten Jahr an Marktanteil verloren, dies von 84,5 Prozent im Vorjahr auf 67,2 Prozent im nicht agilen Umfeld und von 67,6 Prozent im Vorjahr auf 52,9 Prozent im agi-len Umfeld. Daneben sind Atlassian Jira und HP Quality Center beliebte Werkzeuge. Im nicht agilen Umfeld kommt zusätzlich Microsoft Visio häufig zum Einsatz. Atlassian Jira hat stark an Marktanteilen gewonnen. Im agilen Umfeld konnte die Software von 31 Prozent im letz-ten Jahr auf 47,1 Prozent dieses Jahr zulegen. Im nicht agilen Umfeld machte sie gar einen Sprung von 1,8 Prozent auf 27,2 Prozent. <www.swissq.it

11/2013 © netzmedien ag 23

Trends und Hürden im Requirements EngineeringSwissQ hat im aktuellen «Requirements Trends & Benchmarks Report Schweiz 2013» unter anderem die Techniken, Tools und Trends im Requirements Engineering analysiert. Fazit des Reports: Es geht zwar vorwärts, aber noch bleibt Luft nach oben. Janine Aegerter

Wie gross ist der Aufwand des Requirements Engineerings im Verhältnis zum Gesamtprojektaufwand? Quelle: Requirements Trends & Benchmarks Report Schweiz 2013, SwissQ

REQUIREMENTS ENGINEERING TRENDS


TRENDS TESTING IN DER SOFTWARE-ENTWICKLUNG

Kein Netz

07:40

92%

Anzeige

Ungleiche Sicht von Testern und Management SwissQ beleuchtet in seinem Trends- und Benchmark-Report Schweiz das Thema Testing. Unter anderem geht daraus hervor, dass das Management die Fähigkeiten von Testmitarbeitern zu gut einschätzt und die Testabteilung dadurch unter Druck geraten kann. Janine Aegerter

Wer Software entwickelt, muss die-se auch testen. Das ist grundsätz-lich jedem klar, der in der Soft-ware-Entwicklungs-Branche tätig ist. Dennoch scheint es, als ob die Testing-Abteilungen die alte Sicht-weise «Testen als notwendiges Übel» noch nicht ganz abgeschüt-telt haben, wie aus dem Trends- und Benchmark-Report Schweiz von SwissQ zum �ema Testing hervorgeht.

500 Personen befragtDie Grundlage für den Report bildet eine Onlineumfrage, an der etwa 500 Personen aus unterschiedli-chen Firmen, Branchen und Regio-

nen der Schweiz teilnahmen. Zu-sätzlich wurden zirka 25 Executi-ve-Interviews durchgeführt.

Einer der Gründe, warum Tes-ter teilweise noch immer um ihre Berechtigung kämpfen müssen, ist vermutlich ein Dilemma zwischen der Testabteilung und dem Ma-nagement, das die Autoren der Stu-die beschreiben: Vergleicht man die Antworten des Managements mit denen der Testmitarbeiter, werden klare Unterschiede in der Wahr-nehmung sichtbar.

So schätzt das Management laut Report die Maturität und das fachliche Wissen im Testbereich viel positiver ein als die Testmitar-

beiter selbst. Dadurch werden den Testmitarbeitern wiederum Test-aufgaben zugewiesen, die das dafür nötige Wissen gar nicht mitbringen.

Dadurch gerät das Testen in die Kritik und sein Nutzen wird infrage gestellt. Zudem ist durch die Feh-leinschätzung der Testmitarbeiter laut SwissQ in der Führungsebene auch weniger Bereitschaft vorhan-den, die (tatsächlich vorhandenen) Missstände anzugehen und die not-wendigen Investitionen zu tätigen. Diese Fehleinschätzung einerseits und die Kritik andererseits kann laut Report zu einer starken Reduk-tion des Testbudgets oder der Auf-lösung der Testorganisation führen. Die Testmitarbeiter sind somit laut SwissQ gefordert, ihrem Manage-ment die Problembereiche und gleichzeitig aber auch den Nutzen des Testings klar aufzuzeigen.

Testprozess nicht zufrieden-stellendWeiter hat SwissQ im Report den Testprozess unter die Lupe genom-men und die Studienteilnehmer zu

ihrer Zufriedenheit mit Testaktivi-täten befragt. Dazu gehören Test-management, Testplanung, Test-fallermittlung, Test auswertung und Testdurchführung.

Am besten bewerten die Studi-enteilnehmer die Testdurchfüh-rung mit einer Zufriedenheit von 58,1 Prozent. Auch mit dem Test-management ist mit 51 Prozent zu-mindest etwas über der Hälfte der Befragten zufrieden. Alle anderen drei Disziplinen erzielen mit 41,7 Prozent (Testplanung), 40,1 Pro-zent (Testauswertung) oder gar nur 38,1 Prozent Zufriedenheit (Testfal-lermittlung) keine guten Resultate.

Kritik der TesterDie Tester ihrerseits kritisieren mangelhafte oder unvollständige Anforderungen, zu späte Lieferung der Software, Verfügbarkei der Soft-wareumgebung und eine zu späte Involvierung der Testabteilung.

Mehr dazu auf www.netzwoche.ch, Webcode 265

DIE GRÖSSTEN HERAUSFORDERUNGEN

Thema: Das kritisieren die Tester () = Werte Umfrage 2013

Quelle: Trends & Benchmarks Report Schweiz, Testing, 2014, SwissQ

Management Attention 32 % (17%)

Tester zu spät involviert 46 % (30%)

Automatisierung 34 % (22%)

Anforderungen mangelhaft 58 % (58%)

Zu wenig Budget / Ressourcen 36 % (29%)

Testdaten 37 % (19%)

Zu späte Lieferungen der SW 48 % (26%)

Testumgebung 35 % (21%)

Anzeige

Fakten aus und für die Community: Fakten aus und für die Community:

Der Software Development Trends und Benchmark Report

zu bestellen ü[email protected]

Der Software Development

Requirements - Trends & Benchmarks in Soware Development 2014 | 25

Requirements - Trends & Benchmarks in Soware Development 2014 | 24Aufwand

0%

10%

20%

30%

bis 5% 6-10% 11-15% 16-20% 21-30% 31-50% darüberRE-Aufwand im Verhältnis zum Gesamtprojektaufwand

12.4

%

18.2

%

27.5

%

15.1

%18.6

%

5.8% 2.

3%

Aufwand RE im Verhältnis zum Gesamtaufwand

n 2013 n 2014

bis 5% 6-10% 11-15% 16-20% 21-30% 31-50% darüberRE-Aufwand im Verhältnis zum Entwicklungsaufwand

0%

10%

20%

30%

RE-Prozess

4. Prüfen

5. Verwalten

RE ZufriedenheitUnzufrieden Mittelmässig Zufrieden

1. Erheben

38.6%

11.8%

49.6%

3. Dokumentieren

29.4%21.0%

49.6%

20.6%24.3%

55.1%

21.7%29.4%

48.9%

2. Analysieren

40.4%

13.6%

46.0%

5 4

3

2

1

Entwicklungs- aufwand

Der durchschnittliche RE-Aufwand im Verhältnis zum Gesamtprojektaufwand wird über die Jahre konstant auf 16 – 20% geschätzt.

Der RE-Aufwand im Verhältnis zum Entwick-lungsaufwand wird im Durchschnitt auf 16-20% geschätzt.RE-Aufwand

16-20%

Gesamt- aufwand

RE-Aufwand 11-15%

17.1%

8.2%

18.2%

21.6%

16.7%

13.4%

4.8%

Aufwand RE im Verhältnis zum Entwicklungsaufwand

61.4%der Projekte sind mit der Erhebung von Anforderun-gen mittelmässig oder gar nicht zufrieden.

70.6%sind mit dem Dokumen-tieren von Anforderun-gen unglücklich. Die o gelobten Notationen und Werkzeuge scheinen nichtzu befriedigen.

20.6%sind mit dem Prüfen vonAnforderungen nur zu-frieden. Je später eine Aktivität im RE-Prozess stattfindet, desto unzu-friedener sind die Un-ternehmen mit diesen. Unterwegs scheint die Energie und eventuell der Fokus verloren zu gehen.

Agile - Trends & Benchmarks in Soware Development 2014 | 17

Agile - Trends & Benchmarks in Soware Development 2014 | 16

Zufriedenheit

Agile Praktiken

Hauptgründe für das Scheitern agiler Projekte

52% Unternehmens-

philosophie nicht mit

agilen Werten verknüp�ar

(Theorie mit Praxis nur

schwer vereinbar)

49%

Fehlende Erfahrung

mit agilen

Vorgehensmethoden

43% Fehlende Unterstützung

durch das Management

31%

Fehlende/

ungenügende

Schulung/

Coaching

26%

Externer Druck

weiter einem

klassischen

Modell zu folgen

24% Fehlende

Verbindung

zwischen den

Organisationsein-

heiten

25%

Unpassendes Projekt

für Einführung

Zufriedenheitn Läu alles super

- keine Probleme

n Erwarteter Nutzen erfüllt

n Dauer länger als erwartet

n Ist kompliziert

n Erfüllt die Erwartungen nicht

n Übung abgebrochen

( ) = Veränderung zu Umfrage 2013

30.1% (+0.8%)

38.4% (-5.2%)

19.9% (+7.9%)

7.9% (-0.7%)

1.4% (-5.0%)

2.3% (k.A.)

Im Vergleich zum Vorjahr

Läu alles

super -

keine

Probleme

Erwarteter

Nutzen

erfüllt

0%

20%

30%

40%

10%

38.4

%

1.4%6.

4%

43.6

%

n 2013

n 2014

12.0

% 19.9

%

ist

kompliziert

Management Practices

Daily Standup

Backlog Management

Sprint Review / Product Demo

Burndown Chart

De�nition of Done

Retrospektiven

Release Planning

Iterative Planung

Taskboard

Planning Poker

Dedicated Product Owner

Product Roadmap

Velocity Chart

De�nition of Ready

Priority Poker

Work in Progress (WiP) Limits

Co-Location

On-Site Customer

n Werte aus 2014

n Werte aus 2013

78.6%

75.0%

73.2%

65.9%

65.0%

62.7%

56.8%

54.5%

54.1%

40.5%

34.1%

30.9%

28.6%

27.7%

15.5%

15.0%

11.4%

8.6%

0% 20% 40% 60% 80%

Engineering Practices

Unit Testing

Continuous Integration

Automated Build

Issue/Bug Tracker

Refactoring

Test Driven Development (TDD)

Pair Programming

Acceptance Test Driven

Development (ATDD)

Automated Acceptance Testing

Collective Ownership

Behavior Driven Development (BDD)

Andere

72.3%

60.5%

54.5%

53.6%

40.5%

34.1%

29.5%

17.3%

16.8%

16.8%

6.4%

4.5%n Werte aus 2014

n Werte aus 2013

0% 20% 40% 60% 80%

« Wir sehen Agilität als Werkzeugkasten,

nicht als die ultimative Lösung. »

Bereichsleiter, Industrie

Trends & Benchmarks in So�ware Development 2014 | 10

Erhebungsgrundlagen

Wirtscha ssektor

Wie bereits in den Vorjahren stellen IT Unternehmen sowie Finanzen und

Versicherungen den grössten Teil der Teilnehmenden.

Aufgabenbereich

Viele Teilnehmende umschreiben ihre Tätigkeit mit mehr als einer Rolle.

Das Spektrum der Befragten ist insgesamt sehr breit.

IT-Mitarbeitende

0%10%

20%30%

40%

IT

Finanzen, Versicherungen

Industrie

Staatliche und staatsnahe

Betriebe

Transport und Verkehr

MedTech

Telekom

Andere

32.3%

30.7%

9.1%

8.1%

6.9%

30%

2.2%

6.6%

3.9%

2001 - …

501 - 2000

251 - 500

50 - 250

11 - 50

1 -10

0%10%

20%30%

40%

33.9%

15.7%

12.4%

17.5%

15.4%

5.1%

30%

20%

10%

0%

Test Manager

Test Engineer / Test Analyst / Tester

Requirements Engineer

Projektleiter

Business Analyst

Berater / Consultant

Teamleiter

Abteilungsleiter / Bereichsleiter

Quality Manager / QS-Verantwortlicher

SW Engineer in Test / Testautomatisierer

C-Level (CEO / CIO / ...)

Scrum Master

Product Owner

So�wareentwickler / Developer

Solution/So�ware Architekt

Product Manager

Betrieb / Support

Solution Designer

Andere

24.4%

23.0%

19.9%

18.5%

18.5%

16.7%

16.3%

13.2%

9.1%

7.1%

6.7%

6.7%

6.7%

6.5%

4.9%

2.8%

2.2%

1.0%

2.8%

Agile

Trends & Benchmarks Report Schweiz

Wo stehen wir –

wohin geht es?

Software Development

In Kooperation mit

Agile

Requirements

Testing

iSQI® Certified Agile Business Analysis

Einführung

Die Aufgabe des Business Analysten ist sicherzustellen, das Projekte, bzw. Investionen für das Unterneh-

men einen Mehrwert erzeugen. Mit wachsender Maturität agiler Methoden zeigt sich, das dies auch in

diesem Umfeld gültig ist.

Die Rolle des BA ist im Gegensatz zu Entwicklern und Testern in den meisten agile Frameworks nicht klar

definiert. Dies mag zum Teil daran liegen, dass die Rolle des BA häufig missverstanden wird, jedoch exis-

tiert auch keine weitesgehend aktzepierte Rollendefinition, kein Framework für den Agile BA – bis jetzt.

Die Agile Erweiterung des BABOK Guide v1.0 wurde in Zusammenarbeit mit der «Agile Alliance» entwickelt,

eine der Mitgründer des Agile Manifesto. Die Erweiterung liefert einen akzeptierten Industrie Standard für

die Business Analyse im Agile Umfeld.

Zielgruppe

Projektleiter, Requirements Engineers, Business Analysten, Projektmitarbeiter, welche mit Anforderungen

arbeiten und im agilen Umfeld tätig sein wollen.

Ziele

Nach Ende des Kurses sind erfolgreiche Teilnehmer in der Lage, die Rolle des Business Analysten in agilen

Software-Entwicklungsprojekten zu identifizieren. Sie können in agilen Software-Entwicklungsteams

partizipieren und die Verantwortung des Business Analysten sowohl zum Unternehmen als auch zum

Team artikulieren. Das Agile Business Analysis Framework und seine Prinzipien wird verstanden und

angewendet. Der Teilnehmer kennt Business Analysis Techniken und Methoden, welche die Erstellung

von Artefakten unterstützen, die dem Unternehmen Mehrwert bei der Initiierung agiler Projekte liefert.

Er kennt die Bedeutung des KVP und weiss, wie man ihn unterstützt.

Der Kurs schliesst mit der 60-minütigen Prüfung zum Erlangen des Zertifikates «iSQI® Certified Agile

Business Analysis» ab.

Inhalt

What is Business Analysis?

What is Agile?

Common Agile Approaches

Business Analysis Techniques in Agile Projekts

Agile Business Analysis Discovery Framework

Review

Voraussetzungen

Vorteilhafterweise Erfahrung als Business Analyst, Requirements Engineer, Tester oder Developer in tra-

ditionellen Projekten

Zertifizierungen | Agile 60

Sprache DE/EN/Unterlagen EN


Dauer 2 Tage Code CABA


Agile

Requirements

Testing

Zertifizierungen

Ich musste beim Inhalt der Anforderungen nun also einen Konsens zwischen allen Stakeholdern finden. Ganz plötzlich erschienen mir die Wünsche der Tester als beträchtlich weniger bedeutend, als noch in meiner letzten Rolle. Auch ich hatte nun viel zu wenig Zeit, um mich um die Bedürfnisse und Wünsche der Tester zu kümmern – musste diese sogar verneinen. Es tat mir dementsprechend leid die Tester vertrösten zu müssen, oder ihre Änderungswünsche (Detailverliebtheit!?) zurückzuweisen.

Ich habe mir vorgestellt wie wenig begeistert die Tester von meinem Vorgehen sein mussten. Nachdem ich erfuhr, dass ein Engpass im Testing enstanden ist, ahnte ich bereits, dass mir ein Wechsel zurück zum Test Team bevorstand.

Back to the Roots - Wieder Testing

Nun lag mein Fokus wieder auf den Testfälle mit welchen ich wieder Anforderungen testen sollte. Es dauerte nicht lange und meine Anliegen gegenüber den BAs nahmen zu. Doch diesmal wusste ich wieso die Anforderungen so geschrieben wurden. Eines guten Tages machte ich mir Gedanken wie es zu diesem «Missverständnis» zwischen BAs und Testern gekommen ist und was man dagegen tun könnte. Ich will hierbei gerne auf zwei Themen präziser eingehen.

Die richtige Kommunikation und Empathie sind schon die halbe Miete

Kommunikation

Man hört es immer wieder. Die Kommunikation sei sehr wichtig. Man nimmt es sich vor, so viel wie möglich miteinander «zu reden». Leider bleibt es nur bei dem guten Vorsatz, vor allem unter Zeitdruck.

Als Tester habe ich mich immerzu darüber beschwert, dass von den BAs nicht genug Zeit in die Kommunikation investiert wird. Entscheidungen waren mir nicht immer verständlich oder sind erst spät im Team angekommen. Änderungen an Anforderungen wurden von uns bemerkt, anstatt von den BAs kommuniziert zu werden.

Als BA hatte ich leider nicht genügend Zeit um Entscheidungen über und Änderungen an den Anforderungen ausführlich zu kommunizieren. Wie man es dreht und wendet, diese Aufgabe darf man nicht vernachlässigen. Es wird oft als selbstverständlich angesehen und fliesst deshalb nicht in die Planung ein. In meiner Rolle als BA werde ich in Zukunft eine ausführliche Kommunikation gegenüber den Testern einplanen.

Anton Podokschik, Consultant, 23.05.2014

Blog

darf man nicht vernachlässigen. Es wird oft als selbstverständlich angesehen und fliesst deshalb nicht in die Planung ein. In meiner Rolle als BA werde ich in Zukunft eine ausführliche Kommunikation

Business Analysten (beziehungsweise Requirements Engineers) und Tester sind bekanntlich nicht immer gleicher Meinung. Hinter dem diplomatischen Lächeln auf dem Gang herrscht oft Unverständnis für die Taten des Gegenübers. Der Tester würde es in der Business Ana-lysten Rolle sowieso anders machen und umgekehrt. Solche Gedan-kenexperimente werden jedoch nur selten wahr. In diesem Beitrag berichte ich, wie mir das Privileg zuteil wurde beide Rollen innerhalb kurzer Zeit einnehmen zu dürfen und was ich daraus lernen konnte.

Der Sprung ins kalte Wasser – Testing im neuen Projekt

Neu im Projekt zu sein ist meiner Meinung nach immer aufregend. Man lernt die Projektteams, -strukturen, -tools und -vorgehens-weisen kennen. Als Tester durfte ich Testfälle aus bestehenden Anforderungen (Requirements) generieren. An sich eine klare Auf-gabenstellung. Allerdings ist mir nach einigen Wochen aufgefallen, dass man als Tester unter sich ständig ändernden Anforderungen doch ein wenig zu leiden hat:

Testfälle müssen immerzu aktualisiert werden

Der Umfang ist nicht immer von Anfang an (bei der Erstellung des Testfälle) klar

Testfälle müssen archiviert werden, da diese auf gelöschte Anforderungen verweisen.

Sowas schreit nach enger Zusammenarbeit zwischen Business Ana-lyse (BA) und Test. Die BAs waren jedoch immerzu eng angebunden und gingen selten auf meine Verbesserungsvorschläge bezüglich der Anforderungen ein. Zumindest war das mein Eindruck. Dieser sollte sich jedoch in einigen Monaten von Grund auf ändern, denn mir wurde mitgeteilt, dass ich in kurzer Zeit für die Anforderungen im Projekt verantwortlich sein würde.

Aus dem Regen in die Traufe – Auf in die Business Analyse

Voller Elan machte ich mich in meiner neuen Rolle ans Werk die Anforderungen endlich den Wünschen der Tester anzupassen. Nebst den Testern kamen aber bald auch andere Stakeholder auf mich zu, mit Änderungswünschen an den spezifizierten Anforderungen. Plötzlich sollten meine Anforderungen es allen recht machen:

- Quality Engineers - Tester - Entwickler - System-Integratoren - Produkt Manager - Projektleiter

Business Analysten und Tester – 2 unterschiedliche Sichtweisen

Der Sprung ins kalte Wasser – Testing im neuen Projekt

Back to the Roots - Wieder Testing

Auf in die Business Analyse

Den vollständigen Blog können Sie nachlesen auf www.Swissq.it/bas-und-tester-2/

Certified ScrumMaster ScrumAlliance®

Einführung

Als Führungskraft, Projektleiter, Entwickler, Tester, Produktmanager, Business Analyst oder Berater haben

Sie sicher schon von den Vorteilen von Scrum gehört. Vielleicht stehen Sie den ganzen Behauptungen und

dem Hype um Scrum und der agilen Softwareentwicklung auch skeptisch gegenüber. Vielleicht haben Sie

auch den Entschluss gefasst, mit Ihrem ersten agilen Projekt zu starten. Oder Sie haben bereits begonnen,

Scrum einzusetzen – aber es funktioniert nicht so wie erwartet. Sie wollen besser darin werden, Projekte

umzusetzen. Sie wollen dazu lernen. Wie funktioniert Scrum? Was unterscheidet die agile Entwicklung

vom klassischen Ansatz? Wie sollte man anfangen? Wie können Sie die anfallenden Arbeiten schätzen?

Mit welchen Veränderungen müssen Sie rechnen, wenn Sie Scrum einsetzen? Dieser Kurs bietet Ihnen die

Antworten auf Ihre Fragen – und einen intensiven praktischen Blick auf Scrum. Damit Sie wissen, was

für Sie der nächste Schritt sein sollte. Wie funktioniert Scrum? Was unterscheidet die agile Entwicklung

vom klassischen Ansatz? Wie sollte man anfangen? Wie können Sie die anfallenden Arbeiten schätzen?

Mit welchen Veränderungen müssen Sie rechnen, wenn Sie Scrum einsetzen? Dieser Kurs bietet Ihnen die

Antworten auf Ihre Fragen – und einen intensiven praktischen Blick auf Scrum. Damit Sie wissen, was für

Sie der nächste Schritt sein sollte.

Zielgruppe

Führungskräfte Projektleiter Entwickler Tester

Produktmanager Business Analysten Berater

Ziele

Verstehen, wie Scrum funktioniert. Fühlen, warum Scrum funktioniert. Begreifen, wie Sie Scrum ein-

setzen können. Kurz gesagt, Sie sollten in der Lage sein, mit Ihrem ersten Scrum Projekt zu beginnen, die

Ergebnisse eines bestehenden Scrum Projekts zu verbessern, und die bedeutsame Frage zu beantworten,

ob Scrum für Ihre Organisation geeignet ist. Mit der erfolgreichen Teilnahme an diesem Kurs qualifizieren

Sie sich für die Kandidatur zum Certified ScrumMaster™ (Online Prüfung erforderlich) und erhalten eine

zweijährige Mitgliedschaft in der Scrum Alliance. Detaillierte Informationen zum Zertifizierungsprogramm

der Scrum Alliance sind auf der Scrum Alliance Website beschrieben.

Inhalt

Warum agile Prozesse?

Agile Werte und Prinzipen

Rollen in Scrum: ScrumMaster, Product Owner, Team

Rituale (Meetings): Sprint Planning, Sprint Review, Daily Scrum, Retrospektive

Dokumente und Artefakte: Product Backlog, Sprint Backlog, Taskboard, Burndown Charts

Planen: User Stories, Schätzen, Abnahmetests, Release-Planung

Kenntnisse und Handwerkszeug eines guten ScrumMasters

Reguläre Certified ScrumMaster Kurse dauern zwei Tage. Im Gegensatz zu den üblichen Trainings ent-

hält dieser Kurs mehr Zeit für: Intensive Übungen, Fragen und Themen der Teilnehmer, Hintergründe

und Geschichten, Fallstudien und Erfahrungsaustausch.


Sprache DE/EN


Dauer 3 Tage Code CSM


Agile

Requirements

Testing

Zertifizierungen

Certified Scrum Product Owner ScrumAlliance®

Einführung

Haben Sie sich über Scrum oder XP informiert oder bereits ein agiles Projekt durchgeführt und gedacht,

«Klingt wunderbar, aber …!» Wie kann ich das Projekt planen? Wann wird es fertig sein? Wie lenke ich das

Projekt, und wie verhandle ich mit dem Team? Wie viel wird es kosten? Wie offeriere ich das Projekt? Wie

gehe ich vor, wenn Preis, Termin & Umfang zu Projektbeginn fixiert werden müssen? Wie geht ein agiles

Projekt mit Linienmanagement, Reporting und den anderen Stakeholdern um? Wie werde ich meinen

Aufgaben als Product Owner gerecht?

Zielgruppe

Dieser Kurs ist ideal für Product Owner, ScrumMaster, Kunden bzw. Auftraggeber, Projektleiter, IT-Mana-

ger und Verkaufsberater, die agile bzw. Scrum-Projekte ein oder verkaufen, planen, steuern, leiten oder

betreuen wollen.

Ziele

Nachdem Sie diesen Kurs absolviert haben, sind Sie (mit Hilfe Ihres agilen Teams) in der Lage, ein agiles

Projekt zu führen – von der Vision bis zum erfolgreichen Abschluss.

Inhalt

Aufgaben, Rechte und Pflichten des Product Owners

Scrum-Überblick (Auffrischung)

Produkte schaffen, die Ihre Kunden und Nutzer begeistern

Anforderungen: User Stories, Story Points und Business Value

Führung eines sich selbst organisierenden Teams

Qualität einbauen – Von Spezifikation zum Testen zur Abnahme

Linien-Management, Stakeholder und das Scrum Team

Das Product Backlog erstellen und priorisieren

Projekt-Laufzeit schätzen, Meilensteine definieren

Fortschrittskontrolle

Skalierung: grosse Projekte handhaben

Vertragswesen und das berüchtigte Fixpreis-Angebot

Das agile Angebot

Das agile Lastenheft – Agile Projekte ausschreiben

Kommunikation und Reporting

Scrum im Unternehmen: Prozessverbesserungen und Portfolios

Fallstricke: Was kann ich als Product Owner falsch machen

Voraussetzungen

Folgender Lesestoff sollte als Vorbereitung für das Training genutzt werden:

Scrum – Agiles Projektmanagement erfolgreich einsetzen; Roman Pichler; dpunkt 2007

User Stories Applied; Mike Cohn Agile Estimating and Planning; Mike Cohn


Sprache DE/EN


Dauer 3 Tage Code CSPO


Agile

Requirements

Testing

Zertifizierungen

Artikel


Beim Testen in agilen Softwareprojekten führt enge Zusammenarbeit zum ErfolgWie kann in agilen Projekten sichergestellt werden, dass das Budget und der zeitliche Rahmen eingehalten werden? Wie schafft man es in Projekten, den schmalen Grat zwischen Chaos und agiler Methodik zu bewältigen? Stephan Wiesner

71 Prozent der Schweizer Firmen setzen agile Vorgehensweisen in der Softwareentwicklung ein. Gleichzeitig werden nur 39 Prozent der IT-Projekte innerhalb der geplanten Zeit und des Budgets beendet. Dabei fallen im Schnitt 18 Prozent der Gesamtprojektkosten für das Testen der Software an, wie der «Trends und Benchmark Report 2014» aufzeigt. Die E�zi-enzsteigerung in der Softwareentwicklung und die Senkung der Testkosten sind zwei Punkte, die in diesem Zusammenhang eine sehr hohe Relevanz für die Softwarebranche in der Schweiz haben.

Testen im agilen UmfeldAgile Softwareentwicklung, das heisst vor allem: Mit Veränderungen leben und umge-hen können. Schnelle Anpassungen an den Markt, �exible Gestaltung der Wünsche des Auftraggebers und wenige Fehlentwicklungen sind die verlockenden Versprechen. Wech-selnde Anforderungen führen in der Folge zu häu�gen Anpassungen der Software. Entspre-chend wichtig ist es, immer wieder zu testen, sowohl die neuen und geänderten Anforde-rungen als auch die bereits fertig gestellten Softwareartefakte.

Im Scrum-Team wird Testing als gemein-same Verantwortung wahrgenommen. Oft werden Entwickler für das Testing zugeteilt, was einige Risiken mit sich bringt:

y Ist (High-Level-)Test-Know-how vorhanden? y Ist das Testing wirklich unabhängig und

objektiv? y Wie/wer verantwortet Bug-Fixing und Re-

tests? y Wenn der Zeit-/Kostendruck am Projekt-

ende steigt, dann wird das Testen häu�g zugunsten der Entwicklung eingestellt.

y Entwickler fühlen sich häu�g nicht wohl in der Rolle des Testers und vermeiden sie, wo sie können.

Diese Risiken werden durch den Einsatz von dedizierten Testern eliminiert. Für diesen Ein-satz gibt es dann prinzipiell zwei Möglichkei-ten: Es gibt Tester, die am Ende jedes Sprints einen Test durchführen (Wasserfall innerhalb eines Sprints). Oder man wählt den Embed-ded-Testing-Ansatz, bei dem während des ge-samten Sprints getestet wird, sobald etwas «vorzeigbar» ist.

Embedded Testing für bessere ProgrammierungDie Verteilung der Testaufwände auf Verant-wortliche lässt sich anhand einer Pyramide darstellen. Am Ende des Projekts steht der Ab-nahmetest, der typischerweise durch den Fachbereich durchgeführt wird. Entwickler testen immer auch einen Teil ihres Codes. Bei-de Gruppen sind aber nicht speziell für das Testen ausgebildet oder quali�ziert, und die wesentliche Frage ist, wie die Brücke zwischen Entwicklertests und Abnahmetest geschlagen werden kann.

Der Embedded-Testing-Ansatz bedeutet, dass die Entwickler sehr eng mit den Testern zusammenarbeiten. Sobald ein Feature test-bar ist, kann der Tester sich dieses ansehen. In einem ersten Schritt geschieht dies häu�g informell und gemeinsam an einem Bild-schirm. Dadurch kommen nicht nur Fehler ans Licht, der eigentliche Vorteil ist, dass der Entwickler ein unmittelbares Feedback er-

hält. So kann er Fehler direkt beheben – zu den kleinstmöglichen Kosten. Er bekommt aber auch einen Einblick in die Denkweise der Tester. Dadurch kommt es im Laufe des Pro-jekts häu�g zu einer deutlichen Steigerung der Qualität. Statt nur den «Positiv-Fall» zu programmieren, beginnt der Entwickler, auch an mögliche Probleme zu denken. Seine Pro-grammierung wird defensiver, stabiler und somit besser.

In der Folge sinken die Kosten für die Feh-lerdokumentation, das Verwalten und die Be-hebung von «einfachen» Fehlern. Fast noch wichtiger ist aber, dass mehr Zeit in das Fin-den von komplexen Fehlern gesteckt und so-mit die Qualität der Software noch weiter ge-steigert werden kann. Auf der anderen Seite sprechen die Tester mit dem Fachbereich und decken so häu�g Lücken oder Missverständ-nisse in der Spezi�kation auf. Dies führt wie-derum zu deutlichen E�zienzsteigerungen, was einen wesentlichen Vorteil agiler Vorge-hensweisen gegenüber dem klassischen Was-serfall-Modell ausmacht.

In der Praxis werden besonders in agilen Projekten die Mitarbeiter des Fachbereichs besonders gefordert. Häu�g müssen sie die Rolle der Tester übernehmen – zusätzlich zu ihrer normalen Arbeit. Das sind versteckte Aufwände, die nicht immer ausgewiesen oder budgetiert sind. Wichtig ist daher: Die Gesamtprojektkosten dürfen durch den Ein-satz von Testexperten nicht steigen. Im Ge-genteil, häu�g kann eine Senkung der Ge-samtkosten beobachtet werden – jedenfalls,

In agilen Projekten kann das Testen am Ende des Sprints oder «embedded» erfolgen. Bild: SwissQ

Stephan Wiesner ist Head of Testing bei SwissQ und Dozent an der FH Bern.

ENTWICKLUNG SCHWERPUNKT

SCRUM TESTING IM DETAILEm

bedd

edSc

rum

ST/AT

S3 S4 S5

ST/AT ST/AT

S3 S4 S5

ST/AT ST/AT ST/AT


Beim Testen in agilen Softwareprojekten führt enge Zusammenarbeit zum ErfolgWie kann in agilen Projekten sichergestellt werden, dass das Budget und der zeitliche Rahmen eingehalten werden? Wie schafft man es in Projekten, den schmalen Grat zwischen Chaos und agiler Methodik zu bewältigen? Stephan Wiesner

71 Prozent der Schweizer Firmen setzen agile Vorgehensweisen in der Softwareentwicklung ein. Gleichzeitig werden nur 39 Prozent der IT-Projekte innerhalb der geplanten Zeit und des Budgets beendet. Dabei fallen im Schnitt 18 Prozent der Gesamtprojektkosten für das Testen der Software an, wie der «Trends und Benchmark Report 2014» aufzeigt. Die E�zi-enzsteigerung in der Softwareentwicklung und die Senkung der Testkosten sind zwei Punkte, die in diesem Zusammenhang eine sehr hohe Relevanz für die Softwarebranche in der Schweiz haben.

Testen im agilen UmfeldAgile Softwareentwicklung, das heisst vor allem: Mit Veränderungen leben und umge-hen können. Schnelle Anpassungen an den Markt, �exible Gestaltung der Wünsche des Auftraggebers und wenige Fehlentwicklungen sind die verlockenden Versprechen. Wech-selnde Anforderungen führen in der Folge zu häu�gen Anpassungen der Software. Entspre-chend wichtig ist es, immer wieder zu testen, sowohl die neuen und geänderten Anforde-rungen als auch die bereits fertig gestellten Softwareartefakte.

Im Scrum-Team wird Testing als gemein-same Verantwortung wahrgenommen. Oft werden Entwickler für das Testing zugeteilt, was einige Risiken mit sich bringt:

y Ist (High-Level-)Test-Know-how vorhanden? y Ist das Testing wirklich unabhängig und

objektiv? y Wie/wer verantwortet Bug-Fixing und Re-

tests? y Wenn der Zeit-/Kostendruck am Projekt-

ende steigt, dann wird das Testen häu�g zugunsten der Entwicklung eingestellt.

y Entwickler fühlen sich häu�g nicht wohl in der Rolle des Testers und vermeiden sie, wo sie können.

Diese Risiken werden durch den Einsatz von dedizierten Testern eliminiert. Für diesen Ein-satz gibt es dann prinzipiell zwei Möglichkei-ten: Es gibt Tester, die am Ende jedes Sprints einen Test durchführen (Wasserfall innerhalb eines Sprints). Oder man wählt den Embed-ded-Testing-Ansatz, bei dem während des ge-samten Sprints getestet wird, sobald etwas «vorzeigbar» ist.

Embedded Testing für bessere ProgrammierungDie Verteilung der Testaufwände auf Verant-wortliche lässt sich anhand einer Pyramide darstellen. Am Ende des Projekts steht der Ab-nahmetest, der typischerweise durch den Fachbereich durchgeführt wird. Entwickler testen immer auch einen Teil ihres Codes. Bei-de Gruppen sind aber nicht speziell für das Testen ausgebildet oder quali�ziert, und die wesentliche Frage ist, wie die Brücke zwischen Entwicklertests und Abnahmetest geschlagen werden kann.

Der Embedded-Testing-Ansatz bedeutet, dass die Entwickler sehr eng mit den Testern zusammenarbeiten. Sobald ein Feature test-bar ist, kann der Tester sich dieses ansehen. In einem ersten Schritt geschieht dies häu�g informell und gemeinsam an einem Bild-schirm. Dadurch kommen nicht nur Fehler ans Licht, der eigentliche Vorteil ist, dass der Entwickler ein unmittelbares Feedback er-

hält. So kann er Fehler direkt beheben – zu den kleinstmöglichen Kosten. Er bekommt aber auch einen Einblick in die Denkweise der Tester. Dadurch kommt es im Laufe des Pro-jekts häu�g zu einer deutlichen Steigerung der Qualität. Statt nur den «Positiv-Fall» zu programmieren, beginnt der Entwickler, auch an mögliche Probleme zu denken. Seine Pro-grammierung wird defensiver, stabiler und somit besser.

In der Folge sinken die Kosten für die Feh-lerdokumentation, das Verwalten und die Be-hebung von «einfachen» Fehlern. Fast noch wichtiger ist aber, dass mehr Zeit in das Fin-den von komplexen Fehlern gesteckt und so-mit die Qualität der Software noch weiter ge-steigert werden kann. Auf der anderen Seite sprechen die Tester mit dem Fachbereich und decken so häu�g Lücken oder Missverständ-nisse in der Spezi�kation auf. Dies führt wie-derum zu deutlichen E�zienzsteigerungen, was einen wesentlichen Vorteil agiler Vorge-hensweisen gegenüber dem klassischen Was-serfall-Modell ausmacht.

In der Praxis werden besonders in agilen Projekten die Mitarbeiter des Fachbereichs besonders gefordert. Häu�g müssen sie die Rolle der Tester übernehmen – zusätzlich zu ihrer normalen Arbeit. Das sind versteckte Aufwände, die nicht immer ausgewiesen oder budgetiert sind. Wichtig ist daher: Die Gesamtprojektkosten dürfen durch den Ein-satz von Testexperten nicht steigen. Im Ge-genteil, häu�g kann eine Senkung der Ge-samtkosten beobachtet werden – jedenfalls,

In agilen Projekten kann das Testen am Ende des Sprints oder «embedded» erfolgen. Bild: SwissQ

Stephan Wiesner ist Head of Testing bei SwissQ und Dozent an der FH Bern.

ENTWICKLUNG SCHWERPUNKT

SCRUM TESTING IM DETAIL

Embe

dded

Scru

m

ST/AT

S3 S4 S5

ST/AT ST/AT

S3 S4 S5

ST/AT ST/AT ST/AT

NETZWOCHE 10/2014 www.netzwoche.ch


wenn man die Kosten des Testaufwands durch die Mitarbeiter im Fachbereich hinzu-zählt.

Agile Projekte haben häu�g Schwierigkei-ten, ihren Fortschritt und ihre Qualität zu kon-trollieren. In der �eorie klingt es einfach, anhand von Sprints zu agieren. Wenn man in Sprint 5 von 10 ist, dann hat man die Hälfte des Projekts gescha�t. Aber sind die entwickelten Features wirklich «Done Done», also komplett getestet und abgenommen? Oder wurde nur der Standard-Positiv-Fall entwickelt?

Ein Embedded-Tester zwingt alle Betei-ligten, sich zum Projekt zu bekennen – und kontrolliert es. Dadurch ist eine Fortschritts-kontrolle viel aussagefähiger. Die Folge ist, dass schleichende Probleme und Risiken frühzeitig aufgedeckt und angegangen wer-den – bevor sie gross und teuer werden. Dies gilt sowohl innerhalb eines Sprints, wo eine User Story erst geschlossen werden darf, wenn der Tester getestet hat. Es gilt aber auch übergreifend.

Da agile Softwareprojekte häu�g von Ver-änderungen betro�en sind, müssen in jedem Sprint auch Tests von alten Funktionen durch-geführt werden. Andernfalls besteht eine hohe Wahrscheinlichkeit, dass Fehler in bereits ab-genommenen Modulen unentdeckt bleiben. Dieses hohe Mass an sogenannten Regressi-onstests ist manuell irgendwann nicht mehr zu stemmen. Daher sind Testautomationen auf

Code-Ebene (Unit-Tests) heute ein etablierter Standard in agilen Projekten. Sie sind fast schon eine Art Hygienefaktor. Mit ihnen kön-nen aber keine Fehler in der Spezi�kation auf-gedeckt werden, und Unit-Tests stellen keinen ausreichenden Ersatz für manuelle Tests da. Aspekte wie Design, Usability oder Konsistenz in Bedienung und Layout können nicht auf die-sem Weg abgedeckt werden.

Der Einsatz von Testautomation für über-geordnete Tests (Integrations- und System-tests) kann hohe Kosteneinsparungen brin-gen – kann aber auch ein hoher Kostenfaktor werden. Dies muss im Einzelfall beurteilt wer-den und ist in hohem Masse von der Kompe-tenz der entsprechenden Test-Engineers ab-hängig.

Der Embedded-Tester führt den FachbereichGibt es einen Fachbereich als künftigen Benut-zer der Software, so wird dieser typischerweise in Form von Sprint-Demos über den Fortschritt der Software informiert. Eine einstündige De-mo kann aber nicht die Erfahrung ersetzen, selbst mit der Maus in der Hand zu arbeiten. Ein Embedded-Tester kann hier unterstützen, indem er entweder kleine Arbeitssitzungen mit Mitarbeitern des Fachbereichs macht, oder zumindest intensiv mit ihnen spricht. In der Folge kann er dann ihren Standpunkt ver-stehen und Ein�uss auf die Softwareentwick-lung nehmen. Aus dieser Zusammenarbeit

entstehen häu�g sehr wertvolle Details, die die Arbeit mit der Software deutlich verbes-sern können. Ein Punkt, der langfristig deut-liche �nanzielle Einsparungen bedeuten kann – aber in keiner Statistik auftaucht.

Erst mit dem Ansatz des Embedded-Tes-ters können die Vorteile agiler Softwareent-wicklung wirklich realisiert werden. Fort-schrittskontrolle erfolgt auf wirklich fertigen User-Stories und ermöglicht eine detaillierte Budgetkontrolle. Zudem wird die Qualität der Entwicklung, wie auch der Spezi�kation, zum frühestmöglichen – und damit wirtschaft-lichsten – Zeitpunkt gesteigert.

SCHWERPUNKT ENTWICKLUNG

SCRUM TESTING: BEST PRACTICES

Diese Ansätze haben sich als Best Practices für den Einsatz von Embedded-Testern in agi-len Projekten bewährt:• Auch agile Projekte benötigen gute Werk-

zeuge. Der Einsatz eines Tools für Anforde-rungsmanagement, Fehlerverwaltung und Problembehandlung mit Workflow ist unab-dingbar. Eine einfache Excel-Liste wird nur für die kleinsten Projekte genügen.

• Anforderungsbasiertes Testing anhand von User Stories hat sich als ideale Lösung für Quick-Win-Situationen etabliert. Es darf einfach nicht die einzige Methode sein.

• Ungewöhnlich, aber sehr erfolgreich kann es sein, wenn der Entwickler ein «How to test» pro Issue schreibt.

• Man sollte Tests möglichst zeitnah durch-führen. Eine Anhäufung von pendenten Testfällen gilt es, zu vermeiden. So erhält man zum einen eine engere Kontrolle über den Projektfortschritt (was ist wirklich fer-tig), zum anderen aber auch die gewünschte massive Senkung der Fehlerfolgekosten, da der Fehlerverursacher noch tief in die be-treffenden Materie involviert ist.

• Integrationsfördernde Massnahmen zahlen sich aus: Anpassung an Kleidung, Sprache, Arbeitszeiten, Gewohnheiten des Teams etc.

• Nahe beim Team sein: Physisch präsent oder zumindest mithilfe elektronischer Kommunikationsmittel.

Fixe

s Bu

dget

Vers

chie

bung

von

Auf

wan

dEntwicklertest

Neue Funk tionen

Regres-sionstest

Systemintegrations- und Abnahmetest

Die Testverantwortung lässt sich als Pyramide darstellen. Bild: SwissQ

ISTQB® Agile Tester

Einführung

In diesem Kurs werden Testern und Test Managern die Grundsätze des Testens in Agi-

len Projekten vermittelt. Die Teilnehmer erfahren, wie agile Softwareentwicklungs-

programme organisiert sind und lernen die üblichen agilen Umsetzungen kennen.

Sie verstehen, wie sich agile Entwicklung sich von herkömmlichen Vorgehen unter-

scheidet, welche Position der Tester in der agilen Organisation einnimmt sowie die

grundsätzlichen Agilen Testing Prinzipien, Praktiken, Prozesse und Tools.

Zielgruppe

Test Manager, Tester und Entwickler, Business Analysten und Requirements Engineers,

die in agilen Projekten testen oder vorhaben, in agilen Projekten zu arbeiten.

Ziele

Nach Abschluss dieses Kurses sind die Teilnehmer in der Lage, sich in agilen Projekten

zurecht zu finden, sowie die Prinzipien und Praktiken agiler Projekte zu verstehen. Sie

können ihre bisherige Erfahrung in Testing Projekten an agile Projekte anpassen und

agile Testmethoden und -techniken anwenden. Sie unterstützen agile Teams in der

Planung testbezogener Aktivitäten sowie Testautomation. Die Teilnehmer des Kurses

sind in der Lage, effizent in einem agilen Team und Projekt zu arbeiten und dieses

kommunikativ zu unterstützen. Das Seminar schliesst mit einer 60-minütigen Prüfung

zum Erlangen des Zertifikates «ISTQB® Agile Tester» ab.

Inhalt

Anpassung der Konzepte des ISTQB Foundation Level in agilen Projekten

Vorteile einer agilen Projektführung

Methoden und Prozesse

User stories und Test Cases

Retrospektive, Continuous Integration

Iteration und Release Planning

Testaktivitäten in agilen und nicht agilen Projekten

Die Rolle unabhängigen Testens

Die Skills /die Rolle des agilen Testers in einem Scrum Team Voraussetzungen

ISTQB® Certified Tester Foundation Level Zertifikat

18 Monate Erfahrung im Testing oder höhere IT Ausbildung


Sprache DE/EN


Dauer 2 Tage Code CTAT

Agile

Requirements

Testing

Zertifizierungen

IREB® CPRE | Foundation Level

Einführung

IT-Lösungen erfolgreich einzuführen bedeutet, die Anforderungen der relevanten

Stakeholder umzusetzen sowie geplante Termine und Budgets einzuhalten. Die Wei-

chen für den Erfolg werden gestellt, indem die Anforderungen sorgfältig und mög-

lichst vollständig erhoben werden. Um zu verhindern, dass verschiedene Stakeholder

die Anforderungen unterschiedlich interpretieren, müssen diese möglichst eindeutig

dokumentiert werden. Nur so lassen sich Ziel- und Anforderungskonflikte rechtzeitig

erkennen und lösen. Damit wird zudem die Notwendigkeit nachträglicher kostenver-

ursachender Änderungen deutlich reduziert.

Zielgruppe

Projektleiter Systemdesigner Entwickler Business Analysten

Projektmitarbeiter, die Anforderungen an IT Systeme stellen o. interpretieren müssen Ziele

Im Zertifikatslehrgang Requirements Engineering werden die Methoden und Prozes-

se aus dem Requirements Engineering vermittelt und vertieft. Dabei werden sowohl

die Auswirkung verschiedener Implementierungsansätze (Standard-Software und/

oder Individualentwicklung) als auch die eventuelle Einbindung von Sourcing- oder

Offshore-Partnern berücksichtigt. Der Lehrgang ist abgestützt auf den Lehrplan des

Zertifikats «IREB® CPRE | Foundation Level» und schliesst mit der entsprechenden

75-minütigen Zertifikatsprüfung ab.

Inhalt

Motivation und Grundlagen des Requirements Engineering

Abgrenzung des Systems und Systemkontextes

Erheben von Anforderungen

Dokumentation der Anforderungen (funktionale u. nicht funktionale Anforderungen)

Use Case Formulierung und Darstellung

Use Case Diagramme, Aktivitätsdiagramme und Zustandsdiagramme in UML

Prüfung und Abstimmung der Anforderungen

Management der Anforderungen

Unterstützung der Werkzeuge Voraussetzungen

Erfahrung in den Bereichen Informatik, Organisation oder Betriebswirtschaft

Zertifizierungen | Requirements 68


Sprache DE/EN


Dauer 3 Tage Code CPRE

Agile

Requirements

Testing

Zertifizierungen

Es herrschte immerzu eine kollegiale Atmosphäre und man bekam zu keinem Zeitpunkt das Gefühl bei einem Frontalunterricht mitzuma-chen. Dank des Praxisbezugs (in Form von Geschichten aus der Praxis aller Teilnehmer) hatte man nicht das Ge-fühl realitätsferne Theorie vermittelt zu bekommen.

Sehr gute Vorbereitung auf die Prüfung

Am Ende jedes Kapitels des Skripts wurde ein Review über das Themengebiet gezogen und ich konnte Fragen beantworten, anhand derer ich mein Wissen prüfen (bzw. meine Lücken aufdecken) konnte. Das erlaubte mir schnell festzustellen, wo und wie intensiv ich mich noch auf die Prüfung vorbereiten muss. Zusätzlich gab es am Ende des Kurses, kurz vor der Prüfung, einen Fragebogen mit potenziellen Testfragen. Diese nahmen mir den letzten Rest an Prüfungsangst. Durch die ständige Visualisierung komplizierter Themen wurde das Lernen sehr stark erleichtert. Am Ende des dritten Tages ging ich selbstbewusst in die Prüfung, welche ich auch bestand.

Wissen im Arbeitsalltag

Ein paar Monate später folgte mein erster Kundeneinsatz als Require-ments Engineer. Nun kannte ich also die Theorie und konnte dies mit einem Zertifikat belegen. Ein wenig Angst hatte ich aber trotzdem, da die Praxis oft anders aussieht als die Theorie. Umso erstaunlicher fand ich es, dass ich viele im Kurs besprochene Situationen im Arbeitsalltag wiederfand und die vermittelten Inhalte anwenden konnte. Endlich habe ich also einen Kurs absolviert, dessen Wissen man als Require-ments Engineer auch wirklich anwenden kann.

Persönliches Fazit

Man wird sehr gut auf die Zertifizierung vorbereitet und lernt Menschen aus verschiedenen Branchen kennen. Es findet ein Erfah-rungsaustausch zwischen den Kursteilnehmern und dem Kursleiter statt. Durch die Visualisierung kann man komplexere Themen besser verstehen und schafft am Ende die Prüfung «mit Links».

Ganz besonders hat mir der freundliche und offene Umgang aller Teil-nehmer untereinander gefallen. Es wird keinem das Gefühl gegeben, vor einer unmöglichen Aufgabe zu stehen. Ich hatte immerzu den Eindruck in einem Workshop zu sein, das einem Erfahrungsaustausch dienen soll. Das Bestehen der Prüfung wurde somit zu einem kleinen «Goodie», anstatt das primäre Ziel des Kurses zu sein.

Anton Podokschik, Consultant, 09.10.2013

Blog

vor einer unmöglichen Aufgabe zu stehen. Ich hatte immerzu den vor einer unmöglichen Aufgabe zu stehen. Ich hatte immerzu den Eindruck in einem Workshop zu sein, das einem Erfahrungsaustausch dienen soll. Das Bestehen der Prüfung wurde somit zu einem kleinen

Ganz besonders hat mir der freundliche und offene Umgang aller Teil-nehmer untereinander gefallen. Es wird keinem das Gefühl gegeben,

Wie besiegt man seine Prüfungsangst und lernt dabei auch noch etwas Nützliches für den Arbeitsalltag?

Mit dem folgenden Erfahrungsbericht erzähle ich, wie ich ein Zertifikat in einem vorher nicht gekannten Bereich erworben habe, dabei Networking betreiben und Wissen aufbauen konnte, welches ich auch im späteren Kundeneinsatz angewandt habe.

Zertifizierung in einem vorher nicht gekannten Bereich

Meinen Einsteig bei der SwissQ machte ich am 1. Januar als Requirements Engineer. Mein Vorgesetzter erklärte dabei, dass es sehr wichtig sei, mein Know-How im Bereich «Requirements Engineering» zügig auszubauen. Dabei wurde ein Akronym in den Raum geworfen: «CPRE FL». Ausgeschrieben bedeutet es: «Certified Professional for Requirements Engineering Foundation Level». Dies ist ein Kurs, welcher mit einer Zertifizierungsprüfung abschliesst. Laut einer Trends & Benchmarks Umfrage besitzen knapp 50% aller in der Schweiz tätigen Requirements Engineers und Business Analysten dieses Zertifikat. Ich wollte mich natürlich dieser grossen Anzahl an Spezialisten so bald wie möglich anschliessen.

Ich fand heraus, dass die SwissQ eigene Kurse (SwissQ Academy) in den Themenbereichen Testing und Requirements Engineering anbietet. Es hat sich also angeboten, an einem «CPRE FL» Kurs schnellstmöglich teilzunehmen und das Zertifikat zu erwerben.

Ein Zertifikat in einem Bereich zu machen, das ich vorher nur implizit kennenlernen durfte, empfand ich jedoch als eine ernst-zunehmende Herausforderung.

Meiner Erfahrung nach glich ein Zertifizierungskurs so gut wie immer einem Frontalunterricht in der Schule und im Nachhinein kann man die Inhalte schnell vergessen, weil diese oft veraltet oder sehr theorielastig sind. Mir war also ein bisschen unwohl bei dem Gedanken an diesem Kurs teilzunehmen.

Trotzdem meldete ich mich für einen Kurs an, der schon im Februar stattfinden würde.

Teilnahme am Kurs

Es nahmen 12 Personen am Kurs teil, womit der Kurs voll aus- gebucht war. Die Teilnehmer kamen aus verschiedenen Branchen, mit verschiedenen beruflichen Erfahrungen. Es waren sogar Teilnehmer aus Deutschland anwesend. Einige waren, genauso wie ich, recht neu im Requirements Engineering Bereich. Dadurch verlor ich meine Unsicherheit. Die Kursdauer betrug 3 Tage.

Wider meiner schlimmen Befürchtung war die Gestaltung des Kurses sehr interaktiv. Es wurden Geschichten durch alle Teilneh-mer (inklusive Kursleiter) aus der Praxis erzählt und diskutiert. Der Kursleiter regte uns an, ausführliche Diskussionen über die Themen zu führen und unser bisheriges Wissen mit den Anderen zu teilen. Somit wurden Themenbereiche ausführlich behandelt. Dank der grosszügigen Visualisierung wurde das Lernen für die Prüfung um einiges erleichtert. Wir sollten zusätzlich Gruppenarbeiten durchführen und unsere Ergebnisse auf Flipcharts präsentieren.

Dadurch konnte ich mich mit anderen Teilnehmern besser austauschen und die Inhalte besser verinnerlichen.

Der IREB CPRE FL Kurs für einen

IREB® CPRE | Advanced Level – Elicitation & Consolidation

Einführung

Anforderungserhebung ohne Tränen! Wie kitzle ich die wichtigsten Anforderungen aus

den Stakeholdern? Welche Ermittlungstechniken stehen mir zur Verfügung, und wel-

che Technik passt zu welcher Situation? Wie gehe ich vor, wenn mehrere Stakeholder-

wünsche scheinbar miteinander in Konflikt stehen? Sie wollen Ihre Ermittlungs- und

Konfliktlösungsfähigkeiten aufbessern bzw. Sie überlegen sich, die Advanced-Level

Prüfungen des International Requirements Engineering Boards zu machen.

Zielgruppe

Projektleiter

Systemdesigner

Entwickler

Business Analysten

Requirements Engineers Ziele

Durch praktische Übungen und Rollenspiele erhalten die Teilnehmer einen Wis-

sens- und Kenntnisstand gemäss dem Lehrplan zum «IREB® CPRE | Advanced Level –

Elicitation and Consolidation». Nach dem Training sind sie vertraut mit Ermittlungs-

und Konfliktlösungstechniken und in der Lage, diese anzuwenden.

Die Prüfung besteht aus zwei Teilen: die schriftliche Prüfung im Anschluss an den

Kurs sowie die Hausarbeit inner 12 Monaten. Das Zertifikat wird erreicht, wenn beide

Prüfungsteile innert 12 Monaten bestanden werden.

Inhalt

Ermittlungs- und Konsolidierungsfähigkeiten des Requirements Engineers

Anforderungsquellen

Ermittlungstechniken

Konsolidierungstechniken Voraussetzungen

IREB® CPRE | Foundation Level Zertifikat

36 Monate Erfahrung in den Bereichen Informatik, Organisation oder Betriebs-

wirtschaft



Sprache DE/EN


Dauer 3 Tage Code ALEC

Agile

Requirements

Testing

Zertifizierungen



Sprache DE/EN


Dauer 3 Tage Code ALMO

IREB® CPRE | Advanced Level – Requirements Modeling

Einführung

Aufbauend auf die Zertifizierung zum CPRE | Foundation Level lernen die Teilnehmer

in diesem Training, Modelle effizient bei Ihrer Arbeit als Requirements Engineer ein-

zusetzen. Hierbei wird das Können in den Vordergrund gestellt. Sie lernen anhand

von zahlreichen Übungen, wie UML-Modelle bei der Beschreibung der Funktionen, des

Verhaltens und natürlich der statischen Informationen eingesetzt und diese Modelle

mit natürlichsprachlichen Anforderungen verknüpft werden. Als Abrundung werden

in diesem Training die Verbindung zu den Geschäftsprozessen und die Verwendung

der erstellten Modelle in der Realisierung vorgestellt.

Zielgruppe

Projektleiter

Systemdesigner

Entwickler

Business Analysten

Requirements Engineers Ziele

Durch praktische Übungen und Beispiele erhalten die Teilnehmer einen Wissens- und

Kenntnisstand gemäss dem Lehrplan zum «IREB® CPRE | Advanced Level – Require-

ments Modeling». Nach dem Training sind sie vertraut mit den Modellierungstechniken

und in der Lage, diese anzuwenden. Die Prüfung besteht aus zwei Teilen: die schriftli-

che Prüfung im Anschluss an den Kurs sowie die Hausarbeit inner 12 Monaten. Das Zer-

tifikat wird erreicht, wenn beide Prüfungsteile innert 12 Monaten bestanden werden.

Inhalt

Einsatz der Modellierung im Requirements Engineering

Kennen und Können der Modellierung von Informationen, Funktionen,

Verhalten und Szenarien

Zusammenspiel von Modellen miteinander

Zusammenhang von Modellen mit natürlichsprachlichen Anforderungen Voraussetzungen

IREB® CPRE | Foundation Level Zertifikat

36 Monate Erfahrung in den Bereichen Informatik, Organisation oder Betriebs-

wirtschaft

Agile

Requirements

Testing

Zertifizierungen

ISTQB® Certif ied Tester | Foundation Level

Einführung

Als wichtiger Bestandteil des Software-Entwicklungsprozesses ist Testen heute eine

Daueraufgabe, die qualifizierte Fachleute erfordert. Die Kenntnis anerkannter und

etablierter Software-Testmethoden sowie die Verwendung einheitlich definierter

Begriffe sind hierbei wichtige Voraussetzungen. Das Certified-Tester-Programm

implementiert das in den meisten europäischen Ländern standardisierte und an-

erkannte Certified-Tester Qualifikationsschema.

Zielgruppe

Tester

Test Manager

Entwickler

Qualitätsverantwortliche

Ziele

Dieses Grundlagentraining behandelt Aufgaben, Methoden und Techniken des Soft-

waretestens. Die Teilnehmer lernen alle Schritte des Software-Testprozesses kennen,

von der Planung über die Spezifikation bis zur Durchführung und Protokollierung von

Tests.

Das Seminar schliesst mit einer 60-minütigen Prüfung zum Erlangen des Zertifikates

«ISTQB® Certified Tester | Foundation Level» ab.

Inhalt

Grundlagen des Softwaretestens

Testen im Softwarelebenszyklus

Statischer Test

Dynamischer Test

Testmanagement

Testwerkzeuge

Voraussetzungen

Vorteilhafterweise Vorkenntnisse in Software Testing

Zertifizierungen | Testing 72

Sprache DE/EN/FR


Dauer 4 Tage Code CTFL


Agile

Requirements

Testing

Zertifizierungen

ISTQB® Certif ied Tester | Advanced Level – Test Manager

Einführung

Im Fokus des Modul Test Manager stehen die speziellen Aufgaben und Aktivitäten,

die ein Test Manager im Rahmen seiner täglichen Aufgaben planen und durchführen

muss. Das Modul bietet eine spezielle Weiterführung in den Themen des Test Manage-

ments.

Zielgruppe

Tester

Test Manager


Projektmanager

Ziele

Ziel ist es, den Teilnehmern eine qualifizierte Ausbildung im Bereich des Test Manage-

ments zu vermitteln, die sich für die tägliche Arbeit nutzen und integrieren lässt. Die

praktische Umsetzung mit Hilfe von Übungen steht im Vordergrund.


«ISTQB® Certified Tester | Advanced Level – Test Manager» ab.

Inhalt

Grundlegende Aspekte des Softwaretestens

Testprozesse

Test Management

Review

Fehler und Abweichungsmanagement

Standards im Testverbesserungs-Prozess

Soziale Aspekte und Teamzusammensetzung

Voraussetzungen

ISTQB® Certified Tester | Foundation Level Zertifikat



Sprache DE/EN


Dauer 5 Tage Code ALTM


Agile

Requirements

Testing

Zertifizierungen

ISTQB® Certif ied Tester | Advanced Level – Test Analyst

Einführung

Neben einer starken praktischen Auslegung auf die Inhalte, liegt der Schwerpunkt des

Modul Test Analyst auf der fachlichen Analyse von Spezifikationen und Testfallerstel-

lung im Black-Box-Testen. Im Fokus stehen die speziellen Aufgaben und Aktivtäten,

die ein fachlicher Tester täglich durchführen und planen muss. Das Modul bietet eine

spezielle Weiterführung der genannten Themen. Ziel ist es, den Teilnehmern eine qua-

lifizierte Ausbildung zu vermitteln, deren Inhalte die tägliche Testarbeit unterstützen.

Zielgruppe

Tester

Test Manager


Projektmanager

Testdesigner

Ziele

Aufbauend auf die Foundation Level Ausbildung vermittelt der Kurs vertiefte Kennt-

nisse zu Methoden und Techniken zur Ableitung und Spezifikation von Softwaretests

auf Black-Box Ebene und zum Review.


«ISTQB® Certified Tester | Advanced Level – Test Analyst» ab.

Inhalt

Testprozess

Test Management

Testverfahren

Softwarequalitätsmerkmale

Reviews

Fehlermanagement

Testwerkzeuge

Voraussetzungen




Sprache DE/EN


Dauer 4 Tage Code ALTA


Agile

Requirements

Testing

Zertifizierungen

ISTQB® Certif ied Tester | Advanced Level – Technical Test Analyst

Einführung

Schwerpunkte des Modul Technical Test Analyst sind die praktische Anwendung der

Inhalte und die Vermittlung von weiterführendem Wissen im White-Box-Testen.

Themen sind u.a. die Kontroll- und Datenflussanalyse sowie Metriken und Kodie-

rungsrichtlinien. Der Fokus dieses Moduls liegt somit auf der technischen Arbeit eines

Testers und den von ihm zu testenden Testobjekten.

Zielgruppe

Tester

Test Manager


Projektmanager

Testdesigner

Ziele

Aufbauend auf die Foundation Level Ausbildung vermittelt der Kurs vertiefte Kennt-

nisse zu Methoden und Techniken zur Ableitung und Spezifikation von Softwaretests

auf White-Box Ebene.


«ISTQB® Certified Tester Advanced Level – Technical Test Analyst» ab.

Inhalt

Risikobasiertes Testen

Strukturbasiertes Testen

Analytische Techniken

Qualitätsmerkmale Technical Testen

Reviews

Test Tools und Automation

Voraussetzungen




Sprache DE/EN


Dauer 3 Tage Code ALTTA


Agile

Requirements

Testing

Zertifizierungen

ISTQB® Certified Tester | Expert Level – Improving the Test Process | Part 1

Einführung

Improving your test process is an essential element of effective and efficient testing. How often do we

hear remarks like these: «Testing costs too much!» «Those failures have to stop!» «We can’t test like

that any more!» These are typical remarks which indicate that the test process needs improving. It may

need a major overhaul within your organization, it may need some fine tuning within your project or

it may simply be a matter of understanding and implementing «lessons learned». There are so many

different aspects to a test process that finding the right improvement approach and ensuring that the

most effective improvement actions are taken can be a daunting task. Unfortunately, the wrong «im-

provements» often just make things worse! This course will enable you to select the right improvement

approach for a given situation, properly assess a test process using a variety of approaches and propose

improvements which align to specific goals. Part 2 of the course considers how to set up an improvement

plan and successfully implement the plan within a project or organization.

Zielgruppe

Test Manager


Projektmanager

Ziele

Lead programs for improving the test process within an organization or project and can identify

critical success factors

Take appropriate business-driven decisions on how to approach improvement to the test process

Assess the current status of a test process, propose step-wise improvements and show how these

are linked to achieving business goals

Analyze specific problems with the test process and propose effective solutions

Inhalt

Context of improvement: Why improvement is necessary

Setting the scope and objectives of an improvement initiative

Diagnosing the current situation and proposing improvements

Selecting the right improvement approach

Using software process models for test process improvement (CMMi, ISO 15504)

Using test improvement models (TPI NEXT, TMMi, CTP, STEP)

Using analytical-based approaches (causal analysis, GQM approach, analysis of metrics)

Voraussetzungen


Test Manager Zertifikat


Sprache DE/Unterlagen EN


Dauer 5 Tage Code EXITP1

To get the certificate: You must pass both

part 1 and part 2 exams and have at least

7 years of experience in testing, 2 of

which are in test process improvement.

Agile

Requirements

Testing

Zertifizierungen

In der Umfrage zum Trends und Benchmarks Report 2014 wurden die Teilnehmer unter anderem gefragt, wie sie mit den Test- aktivitäten des Testprozesses in ihrer Organisation zufrieden sind. Über alle Testaktivitäten hinweg betrachtet, ist das Ergebnis eher bescheiden. Eine Zufriedenheit von 50% oder weniger zeigt deutlich auf, dass Verbesserungsbedarf besteht.

Best …

58% aller Umfrageteil- nehmer sind mit der Test- durchführung zufrieden. Obwohl dieser Wert nicht gerade ein Spitzenergebnis ist, ist es doch die Aktivität innerhalb des Test- prozesses mit der höchsten Zufriedenheitsrate. Vielleicht ist es damit zu erklären, dass in diesem Schritt die fassbarsten Resultate erzielt werden.

… and worst

Im Gegensatz dazu sind rund zwei Drittel der Befragten mit der Test-fallermittlung mittelmässig oder gar nicht zufrieden. Setze ich diese schlechte Bewertung der Testfallermittlung in Kontext zur Frage, welches denn die grössten Herausforderungen im Testing sind, so kann ich durchaus die ein oder andere Abhängigkeit daraus ableiten.

Die grössten Herausforderungen

Als grösste Herausforderung werden mangelhafte Anforderungen beschrieben. Da eine Vielzahl der Testfälle direkt von den An- forderungen abgeleitet werden liegt es nahe, dies als eine der Ur-sachen der schwachen Bewertung der Testfallermittlung zu betiteln.

Die späte Involvierung der Tester in den Prozess wird ebenfalls als eminente Herausforderung bezeichnet. Ausgehend davon, dass Zeit und personelle Ressourcen für Tests in den Projekten eher knapp bemessen und hauptsächlich in klassischen Vorgehensmodellen jeweils am Schluss des Projekts angesiedelt sind, vermute ich, dass die Testfallermittlung möglicherweise vielerorts vernachlässigt und direkt in die Durchführung der Tests übergegangen wird, denn dort wird Zählbares geliefert. Ist dies der Fall, so ist es für mich durchaus nachvollziehbar, dass die Testfallermittlung in der Bewertung der Testmitarbeitenden schlecht abschneidet.

Exploratives Testen ist im agilen Umfeld weit verbreitet. Bei dieser Art des Testens werden im Vorfeld keine Testszenarien entworfen. Die Testfälle entstehen dabei während der Testausführung.

Die Zufriedenheit mit dem Testprozess

Eine verlässliche Testdatenbasis mitsamt funktionierender Test- umgebung sind somit eine Grundvoraussetzung. Gerade die Test- daten und -umgebungen werden aber häufig als ungenügend wahrgenommen. Könnte also folglich die verbesserte Bereitstellung und Bewirtschaftung der Testdaten möglicherweise auch auf die Testfallermittlung einen positiven Effekt haben?

Und was ist mit dem Methodenwissen?

Rund ein Drittel der befragten Testmitarbeitenden attestieren sich selber eine eher bescheidene methodische Kompetenz. Kontrovers ist, dass fehlende Methodik bei der Umfrage nicht in den obersten Ränge der grössten Herausforderungen landete. Diese Fähigkeiten sind jedoch in allen Bereichen des Testprozesses unverzichtbar um die geforderte Qualität eines Produkts zu gewährleisten. Die Frage sei hier also erlaubt, ob allenfalls ein vermehrtes Augenmerk auf die Methodenkompetenz auch die Zufriedenheit im ganzen Prozess verbessern könnte?

Und was ist mit der Kommunikation?

Management und Testmitarbeitende sind sich bezüglich der Güte der Kommunikation im Testbereich nicht ganz einig. Das Mana- gement beurteilt die Kommunikation etwas besser als die Tester selber. Trotzdem, zufriedenstellend sind beide Werte nicht.

Liesse sich allenfalls durch optimierte Kommunikation innerhalb und über die Grenzen des Teams hinweg, auch eine bessere Beurteilung der Testaktivitäten erzielen? Ich meine ja. Mein Kollege Marcel Rütschi formulierte bereits in einem früheren Blogbeitrag zur Stakeholder-gerechten Kommunikation einige hilfreiche Ansätze zur Verbesserung der Kommunikation.

Das Fachbuch Soft Skills für Softwaretester und Testmanager von Heinz Hellerer (dpunkt.verlag) befasst sich hauptsächlich mit der Kommunikation im Testteam und bildet mit viel Praxisbezug aber auch theoretischen Grundlagen einen klugen Ratgeber für Optimierungen in diesem heiklen Bereich. SwissQ bietet ebenso einen Kurs Soft Skills in Testing an.

Fazit

Die Zufriedenheit über die einzelnen Aktivitäten des Testprozesses hält sich in Grenzen. Die Ursachen sind vielschichtig und auf viele Rollen und Phasen des Prozesses verteilt. Eine Steigerung der Zufriedenheit zu erreichen scheint folglich nicht ganz einfach. Ich denke, den Herausforderungen muss mit unterschiedlichen Mitteln auf breiter Front und unmittelbar entgegengetreten werden. Hier einige Ideen, wie diese Hindernisse abgebaut werden können:

Mit spezifischen Ausbildungen methodische Lücken schliessen Sensibilisierung auf die Wichtigkeit der Kommunikation

im Team durch Workshops Distanzen und örtliche Grenzen zwischen den am Prozess

beteiligten Akteuren (Business Analysten, Tester, Entwickler, Projektleiter, etc.) eliminieren

Einbindung von Testern in den Review-Prozess von Anforder- ungen (Stichwort: Testbare Anforderungen)

Durchführung eines Test Prozess Assessments und Einleitung ent- sprechender Massnahmen Erfahren Sie hier mehr und bestellen Sie kostenlos den diesjährigen Trendreport.

Alain Weibel, Senior Consultant, 14.05.2014

Als grösste Herausforderung werden mangelhafte Anforderungen

Heinz Hellerer (dpunkt.verlag) befasst sich hauptsächlich mit der Kommunikation im Testteam und bildet mit viel Praxisbezug aber auch theoretischen Grundlagen einen klugen Ratgeber für Optimierungen in diesem heiklen Bereich. SwissQ bietet ebenso einen Kurs

Fazit

Die Zufriedenheit über die einzelnen Aktivitäten des Testprozesses hält sich in Grenzen. Die Ursachen sind vielschichtig und auf viele Rollen und Phasen des Prozesses verteilt. Eine Steigerung der Zufriedenheit zu erreichen scheint folglich nicht ganz einfach. Ich denke, den Herausforderungen muss mit unterschiedlichen Mitteln auf breiter Front und unmittelbar entgegengetreten werden. Hier einige Ideen, wie diese Hindernisse abgebaut werden können:

Die grössten Herausforderungen Heinz Hellerer (dpunkt.verlag) befasst sich hauptsächlich mit der Kommunikation im Testteam und bildet mit viel Praxisbezug aber auch theoretischen Grundlagen einen klugen Ratgeber für Optimierungen in diesem heiklen Bereich. SwissQ bietet ebenso einen Kurs

Fazit

Die Zufriedenheit über die einzelnen Aktivitäten des Testprozesses hält sich in Grenzen. Die Ursachen sind vielschichtig und auf viele Rollen und Phasen des Prozesses verteilt. Eine Steigerung der Zufriedenheit zu erreichen scheint folglich nicht ganz einfach. Ich denke, den Herausforderungen muss mit unterschiedlichen Mitteln auf breiter Front und unmittelbar entgegengetreten werden. Hier einige Ideen, wie diese Hindernisse abgebaut

Stichwort: Testbare Anforderungen)

mehr und bestellen Sie kostenlos den diesjährigen Trendreport.

Einbindung von Testern in den Review-Prozess von Anforder-

Die grössten HerausforderungenDie grössten HerausforderungenDie grössten HerausforderungenDie grössten HerausforderungenDie grössten Herausforderungen

Blog

ISTQB® Certified Tester | Expert Level – Improving the Test Process | Part 2

Einführung

We know where we want to go: now how do we get there? Part 1 of the course gave us the skills which

enable us to select the right test improvement approach for a given situation, properly assess a test pro-

cess using a variety of approaches and propose improvements which align to specific business goals. So

far so good, but this does not guarantee success! Many test process improvement programs fail because

the implementation runs into trouble. The improvement program is not organised as a project. We don’t

have a realistic plan. We don’t have the right people with the right skills to guide and implement the

improvements. People show resistance to change. Expectations are not managed properly. Costs and be-

nefits are not measured. The list is long. Any one of these critical success factors can spell failure for the

improvement program as a whole. Hence, in part 2 of the course we learn how to deal with the critical

success factors when implementing test process improvement (in fact, anyone intending to make process

changes will benefit from this part).

Zielgruppe

Test Manager Qualitätsbeauftragte Projektmanager

Ziele

Lead test process improvement programs within an organization or project, and identify and

manage critical success factors

Set up and implement a strategic policy for test process improvement

Create a test improvement plan which meets business objectives

Develop organizational concepts for improvement of the test process which include required roles,

skills and organizational structure

Manage the introduction of changes to the test process

Apply soft skills to understand and manage the human issues associated with assessing the test

process and implementing necessary changes

Inhalt

Establishing a test improvement plan

Managing and controlling the implementation (incl. pilots)

Organizing test improvement programs

Roles in test process improvement

Skills required by the test process improver/assessor

Managing change as a process, and with particular regard for human factors

Critical success factors

Establishing a culture of improvement

Voraussetzungen


Test Manager Zertifikat


Sprache DE/Unterlagen EN


Dauer 4 Tage Code EXITP2

To get the certificate: You must pass both

part 1 and part 2 exams and have at least

7 years of experience in testing, 2 of

which are in test process improvement.

Agile

Requirements

Testing

Zertifizierungen

Quellenverweis der Bilder in dieser Broschüre

Stephan Wiesner (Principal Consultant)

Nicht nur im Testing versteht Stephan sein Handwerk, auch im Umgang mit der Fotoausrüstung

ist ihm nicht so schnell etwas vorzumachen. Individuell und trotzdem vielseitig ist sein Portfolio,

aus welchem er uns dieses Jahr Fotos aus dem Bereich Sport zur Verfügung stellt.

Unser Team bereichert er zudem nicht mehr nur mit Wissenswerten aus seinem Berufsalltag,

auch seine Fotografier-Kurse stehen gern vor dem Feierabendbier auf dem Programm.

Auf seiner persönlichen Website können Sie bei Interesse seine Gallerie besuchen:

www.fotograf-bern.net

© by SwissQ Consulting AG Stadthaus-Quai 15 CH-8001 Zürich www.SwissQ.it [email protected] Tel +41 43 288 88 40 Fax +41 43 288 88 39 Twitter: @SwissQ Facebook: swissqconsulting

Fragen? Bitte kontaktieren Sie uns!

Requirements Zertiﬁzierungen Testing ACADEM Y HANDBUCH … · Testing Agile ACADEM Y HANDBUCH...

Documents

Transcript of Requirements Zertiﬁzierungen Testing ACADEM Y HANDBUCH … · Testing Agile ACADEM Y HANDBUCH...