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
ISTQB® Certified Tester | Advanced Level –
Test Analyst
ISTQB® Certified Tester | Advanced Level –
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
Anja van Ackern
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%
50 Kurstage Schulungs-Voucher 50 10%
100 Kurstage Schulungs-Voucher 100 20%
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
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
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
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
Sprache DE / EN / Unterlagen EN
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
Sprache DE / EN / Unterlagen EN
Typ öffentlich/firmenintern
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
Requirements Engineers
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
Requirements Engineers
Business Projektleiter
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
Typ öffentlich/firmenintern
Dauer 2 Tage Code ATMS
Agile
Requirements
Testing
Zertifizierungen
Blog
Der Test Manager muss sich weiter- entwickeln, 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
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
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
Requirements Engineers
Business Analysten
Business Projektleiter
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
11 / 2014 www.netzwoche.ch © netzmedien ag20
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
Requirements Engineers
Business Analysten
Business Projektleiter
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
In Zusammenarbeit mit
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
In Zusammenarbeit mit
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
Zertifizierte Requirements Engineers – Foundation Level o. adäquate Zertifizierung
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
In Zusammenarbeit mit
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
Zertifizierte Requirements Engineers – Foundation Level o. adäquate Zertifizierung
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
In Zusammenarbeit mit
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
Typ öffentlich/firmenintern
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
06 / 2014 www.netzwoche.ch © netzmedien ag28
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
Typ öffentlich/firmenintern
Dauer 2 Tage Code CABA
In Zusammenarbeit mit
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.
Zertifizierungen | Agile 62
Sprache DE/EN
Typ öffentlich/firmenintern
Dauer 3 Tage Code CSM
In Zusammenarbeit mit
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
Zertifizierungen | Agile 63
Sprache DE/EN
Typ öffentlich/firmenintern
Dauer 3 Tage Code CSPO
In Zusammenarbeit mit
Agile
Requirements
Testing
Zertifizierungen
Artikel
www.netzwoche.ch © netzmedien ag 2510 / 2014
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
www.netzwoche.ch © netzmedien ag 2510 / 2014
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
10 / 2014 www.netzwoche.ch © netzmedien ag26
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
Zertifizierungen | Agile 66
Sprache DE/EN
Typ öffentlich/firmenintern
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
In Zusammenarbeit mit
Sprache DE/EN
Typ öffentlich/firmenintern
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
Zertifizierungen | Requirements 70
In Zusammenarbeit mit
Sprache DE/EN
Typ öffentlich/firmenintern
Dauer 3 Tage Code ALEC
Agile
Requirements
Testing
Zertifizierungen
Zertifizierungen | Requirements 71
In Zusammenarbeit mit
Sprache DE/EN
Typ öffentlich/firmenintern
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
Typ öffentlich/firmenintern
Dauer 4 Tage Code CTFL
In Zusammenarbeit mit
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
Qualitätsbeauftragte
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.
Das Seminar schliesst mit einer 180-minütigen Prüfung zum Erlangen des Zertifikates
«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
18 Monate Erfahrung im Testing oder höhere IT Ausbildung
Zertifizierungen | Testing 73
Sprache DE/EN
Typ öffentlich/firmenintern
Dauer 5 Tage Code ALTM
In Zusammenarbeit mit
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
Qualitätsbeauftragte
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.
Das Seminar schliesst mit einer 180-minütigen Prüfung zum Erlangen des Zertifikates
«ISTQB® Certified Tester | Advanced Level – Test Analyst» ab.
Inhalt
Testprozess
Test Management
Testverfahren
Softwarequalitätsmerkmale
Reviews
Fehlermanagement
Testwerkzeuge
Voraussetzungen
ISTQB® Certified Tester | Foundation Level Zertifikat
18 Monate Erfahrung im Testing oder höhere IT Ausbildung
Zertifizierungen | Testing 74
Sprache DE/EN
Typ öffentlich/firmenintern
Dauer 4 Tage Code ALTA
In Zusammenarbeit mit
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
Qualitätsbeauftragte
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.
Das Seminar schliesst mit einer 120-minütigen Prüfung zum Erlangen des Zertifikates
«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
ISTQB® Certified Tester | Foundation Level Zertifikat
18 Monate Erfahrung im Testing oder höhere IT Ausbildung
Zertifizierungen | Testing 75
Sprache DE/EN
Typ öffentlich/firmenintern
Dauer 3 Tage Code ALTTA
In Zusammenarbeit mit
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
Qualitätsbeauftragte
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
ISTQB® Certified Tester | Advanced Level –
Test Manager Zertifikat
Zertifizierungen | Testing 76
Sprache DE/Unterlagen EN
Typ öffentlich/firmenintern
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
ISTQB® Certified Tester | Advanced Level –
Test Manager Zertifikat
Zertifizierungen | Testing 78
Sprache DE/Unterlagen EN
Typ öffentlich/firmenintern
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!