Zertifizierungen

ACADEMY 

HANDBUCH 2016 

Kursangebote mit Mehrwert 

Agile 

Requirements 

Testing 

Zertifizierungen

Inhalt 02 

Inhaltsverzeichnis 

Über SwissQ 

SwissQ Academy /Service Profil 

Unsere Konferenzen 

Vorteile der SwissQ Kurse 

Academy Dozenten 

Voucher System/Coaching und Workshops 

Culture Code 

Schulungspartner 

03 

04 

05 

06 

08 

09 

10 

Kursangebot Testing 

Software-Testing für Manager 

Testmanager Expert Skills 

Testdesign Expert Skills 

Session Based Testing 

Best Practices in Test Automation 

Best Performance Test Implementation 

Manage Outsourced SW-Testing 

45 

46 

47 

48 

50 

51 

53 

Kursangebot Agile 

Leading SAFe 

Agile Essentials 

Agile Leadership & Transformation 

Agile Requirements Engineering 

Product Owner Expert Skills 

User Stories definieren & schneiden 

Agiles Testen mit SCRUM 

Test Master (Agiles Testmanagement) 

Scrum Master Expert Skills 

Kursangebot Requirements 

Requirements Engineering für Manager 

Stakeholderanalyse 

Business Value Alignment 

Geschäftsprozesse analysieren 

und verbessern 

Visual Facilitation Workshop 

Collaboration & Communication 

Design Thinking - Einführung 

mit Gestaltung eines Workshops 

UX und Usability im Requirements 

Engineering 

15 

16 

18 

19 

22 

23 

25 

28 

29 

31 

34 

35 

36 

38 

39 

42 

43 

Zertifizierungen 

SAFe Program Consultant 

iSQI ® Certified Agile Business Analysis 

IQBBA ® Certified Foundation Level – 

Business Analyst 

ISTQB ® Agile Tester 

Certified Scrum Master 

Certified Scrum Product Owner 

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 – 

Testmanager 


Test Analyst 


Technical Test Analyst 

ISTQB ® Certified Tester | Expert Level – 

Improving the Test Process | Part 1 



CMAP Mobile App Testing – 

Foundation Level 

55 

56 

58 

59 

60 

61 

62 

64 

65 

66 

67 

68 

69 

72 

73 

74

Über SwissQ 03 

SwissQ Academy 

Nichts ist steter als der Wandel. Deshalb überarbeiten wir auch unser Kursportfolio laufend, 

um Ihnen stets aktuelles Wissen zu liefern. Auch SwissQ verändert sich kontinuierlich. Wir haben 

viel daran gesetzt, unsere einmalige Kultur zu Papier zu bringen und für unsere Mitarbeiter 

und Kunden transparent zu machen. Der SwissQ Culture Code zeigt unsere Freude und Leidenschaft 

für die Themen Agilität, Requirements und Testing und warum wir so viel ins handwerkliche 

Können und die stetige Weiterentwicklung unserer Mitarbeiter investieren. 

Dies manifestiert sich auch in unserer Academy: Unsere Dozenten sind erfahrene Consultants, 

welche sich tagtäglich mit der Realität in Projekten und Unternehmen befassen. Davon profitieren 

nicht nur unsere Mitarbeiter, welche sich durch die Referententätigkeit in ihrem Fachgebiet 

weiterentwickeln und ihren Expertenstatus festigen. Insbesondere Sie als Kursteilnehmer 

kommen in den Genuss langjähriger Erfahrung mit einem hohen Praxisbezug. 

Wir lieben es, unser Wissen zu teilen: Nicht nur in Form von Kursen. Darum haben wir in diesem 

Jahr dem erfolgreichen Agile Testing Framework das Agile Requirements Engineering Plakat zur 

Seite gestellt. Sie können es kostenlos unter www.swissq.it beziehen. Diese Quellen konzentrierten 

Wissens finden natürlich auch in unseren Kursen Einzug. 

Silvio Moser 

Silvio.Moser@SwissQ.it 

Wir hoffen, Ihnen auch dieses Jahr wieder ein spannendes Angebot zu bieten und freuen uns, 

Sie in unseren Kursen persönlich zu treffen und Erfahrungen und Wissen auszutauschen. 

Silvio Moser, CTO/Head Academy | Anja van Ackern, Training Manager 

Service Prof il 

Consulting 

Agile Methoden und Management Kompetenz, Übernahme 

von Test und RE Aufgaben, Assessment und Coaching 

Anja van Ackern 

Anja.vanAckern@SwissQ.it 

Conferences 

Organisation von 

Konferenzen 

Academy 

Aus- und Weiterbildung, 

öffentlich und inhouse 

Community 

Events, Trends & Benchmarks, Stärkung der Berufsbilder


Unsere Konferenzen 

www.SwissTestingDay.ch 

www.SwissRequirementsDay.ch 

www.ProductManagementFestival.com 

www.AgileLeadershipDay.ch 

Ihre Ansprechpartnerin: 

Nadine Anderson, Head Conferences


Aus der Praxis 

Vorteile der SwissQ Kurse 

für die Praxis! 

Kurse der SwissQ Academy stehen für 

Verständliche Vermittlung von praxisrelevantem Wissen 

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

Effektive Umsetzung des Gelernten in die Praxis 

Kundenspezifische Anpassungen bei Firmenkursen möglich 

Durchführung in Englisch bei Firmenkursen auf Anfrage 

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

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

und dessen Umsetzung im Alltag erfolgreich geschlagen werden.


Academy Dozenten – Die Quelle unseres Wissens 

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. 

Armin Born | Principal Consultant | Armin ist seit über 25 Jahren als Ingenieur FH im Bereich Hard- und Softwareentwicklung 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». 

Charly Vogelsinger | Senior Consultant | Charly ist als Business Analyse Consultant und Coach mit dem Fokus auf Geschäftsprozesse und Serviceorientierung 

für ihre Kunden tätig. Der Faktor Mensch ist für sie sehr wichtig, um ein optimales Zusammenspiel zwischen Menschen, Prozessen und 

Technologie zu erzielen. Neben ihren beruflichen Erfahrungen als Software Engineer, Produktmanager und Requirements Engineer ist Charly auch mit 

verschiedenen Branchen wie zum Beispiel Maschinenbau, Öffentlicher Verkehr und Finance vertraut. Charlys wichtigstes Prinzip ist: Fail early, learn fast & 

improve continuously! Verbessern kannst du dich am schnellsten durch offene Kommunikation, stetiges Hinterfragen des eigenen «Tuns» und durch das 

Akzeptieren und Verzeihen der eigenen Fehler. 

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

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. 

David Berger | Senior Consultant | Seit mehr als sechs Jahren bewegt sich David Berger im Spannungsfeld zwischen Business und IT. Mit vernetztem 

Denken, Kreativität und der Gabe, seine Kunden für Visionen zu begeistern, beweist er, dass Requirements die Schlüssel zum Geschäftserfolg sind. Die IT 

ist für David Berger ein Produktionsmittel, das die Industrialisierung des Business unterstützt. Die IT hat sich also immer um den geschäftlichen Mehrwert 

zu bemühen. David Berger hat einen kaufmännischen Hintergrund und hat sich zum Wirtschaftsinformatiker weitergebildet, weil er überzeugt ist, dass 

Wirtschaft und Informatik zusammengehören. 

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

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. 

Marcel Stoop | Senior Consultant | Marcel ist seit fast 20 Jahren im Testumfeld tätig. Während dieser Zeit war er in verschiedensten Rollen und Branchen 

im Testumfeld unterwegs: Tester, Testdesigner, Testmanager, Testprozess Engineer und Trainer. Solange Software geschrieben wird, ist das Bedürfnis nach gut 

funktionierenden Testprozessen 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 immer notwendige Arbeit ist, psychologisch vielschichtig ist und eine Herausforderung darstellt, fällt ihm nicht schwer. 

Nermin Elsayed | Senior Consultant | Nermin ist eine engagierte Testmanagerin, die seit Jahren verschiedene Testprojekte in sequenziellen und 

agilen Modellen geleitet hat. Ihre Leidenschaft für Qualität und Prozessoptimierung im IT Bereich hat ihr geholfen, ein Coaching Programm in einer Schweizer 

Grossbank zu initiieren. Ihre Erfahrungen mit verschiedenen Kulturen, sowie in Test On-/ und Offshore-Projekten in Grossunternehmen, unterstreichen 

ihren zielorientierten, flexiblen und motivierten Charakter. Agile Whole Team Approach ist für sie das Schlüsselwort für höchste Qualität an Testabdeckung 

und Optimierung. In der SwissQ hat Nermin Testmanagement Projekte und Mobile Testing Projekte betreut. Als zertifizierter Scaled Agile Practitioner und 

Agile Coach unterstützt sie Organisationen und Projekte in der agilen Transformation des Testing. 

Silvia Linschi | Senior Consultant | Silvia ist seit mehr als zehn Jahren im Qualitäts-, Anforderungs- und im Testmanagement in führenden Rollen und 

verschiedener Branchen tätig und kann dadurch unterschiedliche Perspektiven miteinander verbinden. Als Referentin vermittelt sie methodisches Wissen 

für die Gewinnung der eigenen Sicherheit und verbindet dies pragmatisch mit den gesuchten Antworten der Praxis. Ihr Anliegen ist es, die persönlichen 

Einflussfaktoren aufzuzeigen. Jeder kann was bewegen. 

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, Mitgestalter und Trainer. 

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 zehn 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, Telekommunikation, 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. 

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. 

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, Entwickler 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.


Voucher-System 

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

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

Staffelungen 

Anzahl Kurstage Bezeichnung Ermässigung 

25 Kurstage Schulungs-Voucher 25 5% 



1 Voucher-Tag entspricht einem Kurstag 

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

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

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

Preise exkl. MwSt. 

Alle Kurse werden auch als Inhouse Kurse angeboten. Bitte kontaktieren Sie uns für eine Offerte: info@SwissQ.it 

Coaching und Workshops 

Die Umsetzung im Alltag 

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 Know-how, 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

Über SwissQ 09


Schulungspartner 

Gemeinsam 

sind wir stark! 

SwissQ Academy führt diverse Kurse in Zusammenarbeit mit den Spezialisten der jeweiligen Fachgebiete durch. Alle 

Kurse können über uns gebucht werden. 

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

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

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

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

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

Scaled Agile’s mission is to help software-dependent companies achieve better outcomes, increase 

employee engagement, and improve business economics through adoption of Lean-Agile 

principles and practices based on the Scaled Agile Framework ® (SAFe ® ). 

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

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 Personenzertifizierungsstelle 

zertifiziert mit ihren Partnern Personen in verschiedenen Bereichen. 

Das International Software Quality Institute iSQI GmbH zertifiziert weltweit das Know-how 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.


Raus ausm Trott – Rein zu SwissQ! 

Wir arbeiten mehr als wir leben – das ist für eine Vollzeitanstellung 

nicht ungewöhnlich. Also sollten wir hinterfragen, wie wir arbeiten. 

In diesem Beitrag möchte ich erklären, wieso ich bei der SwissQ 

arbeite. 

Ich habe zwar kein erotisches Verhältnis zur Arbeit – dennoch ist mir 

Arbeit wichtig, weil ich schliesslich mehr arbeite als zum Beispiel 

schlafe oder mich in meinem Privatleben verwirkliche. Daher ist mir 

nicht gleichgültig, wo und wie ich arbeite. Ich folge nicht dem Lebenskonzept 

eines Brotberufs, einer zweckmässigen Arbeit, die nur monatlich 

Einkommen generiert, aber weder beseelt noch erfüllt. Ich meine 

und auch andere meinen, Arbeit darf und soll Spass machen und nicht 

bloss Zwang und Verpflichtung sein. 

Machen wir mal einen Test. Täglich quälst du dich ausm Bett, schlurfst 

zur Dusche, säuberst dein Gesicht, steigst in den Zug. Du trödelst zu 

deinem Arbeitsplatz, aktualisierst dein Postfach, löst deinen Kaffee, 

quatschst übers Wetter. Du zählst die Stunden, planst die übernächsten 

Ferien, sehnst dich nach Abwechslung, hoffst auf neue Projekte. 

Das grosse Ding 

Ich kenne ausreichend Menschen, die sich langweilen, deren Alltag sich 

wiederholt so wie ich ihn ein wenig überspitzt habe. Das muss doch 

nicht sein? In der Schweiz werden täglich IT-Grossprojekte initiiert, 

täglich wichtige Entscheidungen getroffen. Täglich ist jemand gefordert, 

täglich ist jemand mittendrin. Niemand müsste sich langweilen. 

Stattdessen verzettelst du dich in internen politischen Kämpfen, mühst 

dich durch langwierige Projektanträge, quälst dich mit überkommenen 

internen Projektführungssystemen. Und wenn du leistest, erhältst du 

trotzdem per Definition keine Lohnerhöhung. 

Wer wo auch immer neue IT-Projekte stemmt – er denkt an SwissQ, 

weil wir an erfolgreiche Projekte glauben. Wir können glauben, weil 

wir wissen, dass wir die fähigsten Mitarbeitenden haben. Menschen 

wollen der SwissQ angehören, weil sie Herausforderungen suchen – 

echte Herausforderungen. Ich habe den Beruf des Consultants 

deswegen gewählt, weil ich die grossen und wichtigen IT-Projekte in 

der Schweiz unterstützen möchte. Als Consultant kommt man herum. 

Man gewinnt Eindrücke, häuft Erfahrungen und steigert dadurch – 

bewusst oder nicht – die persönlichen Marktchancen. 

Consultants bei SwissQ 

Das Berufsbild des Consultants ist aber verbrämt durch das sogenannte 

«Berater-Proletariat» mancher Mitbewerber. Weltweit operierende 

Beratungshäuser, die selbstgefällig alle Jahrgangsbesten rekrutieren 

und sie dann in 60h-Wochen an sinnlosen Projekten verleihen. SwissQ 

ist stattdessen eine Boutique, die schlanke und einfache Prozesse lebt. 

Bei uns musst du keine zehn Formulare ausfüllen und drei gleichberechtigte 

Vorgesetzte konsultieren, um zu entscheiden respektive erwirken 

zu lassen, ob du an einer Weiterbildung teilnehmen darfst oder 

nicht. Wir glauben nämlich, dass wir alle erwachsen sind und einen 

gesunden Menschenverstand bei unseren Entscheidungen praktizieren 

können. 

SwissQ ist und bleibt weiterhin anders. Zwar bist du auch mehrheitlich 

beim Kunden und unsere Kunden sind naturgemäss grössere Unternehmen. 

Dafür hast du endlich einen Heimathafen, der dir gefällt und 

den du regelmässig ansteuern darfst. Wir sind unkompliziert, wir sind 

menschlich. Wir verwalten dich nicht, wir werden dich lieben. Wir werden 

dein Leben nicht künstlich verkomplizieren, sondern vereinfachen. 

Dies, weil wir den Menschen und nicht die Ressource wollen. SwissQ ist 

dein persönlicher Dienstleister für deine Zufriedenheit und kein reiner 

Personalverleiher. Bei uns bist du also nicht bloss im Kundenprojekt 

versenkt, sondern wirkst weiterhin für die und mit 

der SwissQ. Du hast einen Heimathafen. 

David Berger, RE/BA Consultant 

Den vollständigen Blog können Sie nachlesen auf www.swissq.it/de/insides/raus-ausm-trott-rein-zu-swissq/ 

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!

Artikel 

34 MANAGEMENT & KARRIERE Unternehmenskultur 

Entscheidungsfähig bleiben 

Zu viele Richtlinien und Vorgaben lähmen Unternehmen – sie werden 

unfähig, dringende Entscheide zu treffen. Dabei ginge es auch anders: 

Wer auf die Vernunft der Angestellten vertraut, kommt mit einem Minimum 

an Regeln aus. Zu Beginn sind allerdings einige Punkte zu beachten. 

VON ADRIAN ZWINGLI 

Veränderungen sind heute gefragter 

denn je. Wer sich neuen Umständen 

anpassen will, muss auch in der Lage 

sein, Entscheidungen rasch zu fällen. 

Das aber schaffen die meisten Organisationen 

nicht: Entschlüsse werden hinausgezögert oder 

nach oben geschoben, bis zur Unkenntlichkeit 

verwässert und nach einer gefühlten Ewigkeit 

an die Mitarbeiter zurückgegeben. 

ZU VIELE DETAILREGELUNGEN 

Das Problem: Die Organisationen sind ungünstig 

aufgestellt. Basierend auf herkömmlicher Organisations- 

und Prozesslehre wird bis ins letzte 

Detail festgelegt, wer was wie entscheiden darf. 

Stellt sich eine Entscheidung als falsch heraus, 

werden die Prozesse entsprechend ergänzt. Lieber 

werden gar keine Entscheidungen getroffen 

als ungenaue. Dadurch wächst das Regelwerk 

stetig an und nimmt zusehends absurdere Formen 

an. Gibt es am Anfang vielleicht die einfache 

Regel, dass man zu Hause bleiben soll, wenn 

man krank ist, wird später definiert, wann man 

genau als krank gilt und wann nicht. Es folgen 

Richtlinien, wer Büromaterial bestellen darf, wie 

viele Sterne ein Hotel haben darf, und schliesslich 

landet man bei der Richtlinie, wie viele 

Drinks an einem Event ausgegeben werden sol- 

BILD: ISTOCKPHOTO.COM/RYANKING999

Computerworld 5/27. März 2015 

www.computerworld.ch 

COMPUTERWORLD 5/27. März 2015 www.computerworld.ch 

35 

len und der Vorschrift, dass man bei einem 

Schneesturm von zu Hause aus arbeiten soll. Im 

Prinzip liessen sich diese Hunderten von Regelungen 

durch eine einzige ersetzen, nämlich: 

Benutze deinen gesunden Menschenverstand! 

Die Überregulierung hat gravierende Nachteile. 

Sie führt nicht nur zu einer überbordenden 

Komplexität, welche die Dynamik im Unternehmen 

abwürgt, sondern man verzichtet auch auf 

die Urteilskraft der Mitarbeitenden. Das bedeutet, 

vorhandenes Potenzial nicht zu nutzen und 

den Prozessen mehr zu vertrauen als den Mitarbeitenden 

selbst. 

UNTERNEHMENSKULTUR ÄNDERN 

Aus eigener Erfahrung in unserem Unternehmen 

wissen wir: Eine moderne Unternehmenskultur 

hilft, die richtigen Entscheidungen rasch 

zu treffen. Anstatt eine ständig wachsende Zahl 

von Richtlinien und Vorgaben umzusetzen, sind 

unsere Mitarbeitenden aufgefordert, ganz einfach 

ihre Vernunft zu benutzen. 

Das Prinzip ist zwar einfach. Doch mit der 

Freiheit, mehr Macht über Entscheidungen zu 

haben, kommt auch mehr Verantwortung. Diese 

nehmen die Mitarbeiter interessanterweise 

gerne wahr, müssen den Umgang damit jedoch 

oft erst wieder erlernen. In der Lernphase helfen 

die folgenden Orientierungspunkte. 

INTERESSEN PRIORISIEREN 

Unternehmen haben oft Angst, dass die Angestellten 

Entscheidungen zu ihrem Vorteil, aber 

zum Nachteil des Teams oder des Unternehmens 

fällen. Ist die Priorisierung jedoch klar 

und die Mitarbeitenden und Führungskräfte 

wissen, dass sie daran gemessen werden, so 

ergeben sich selten wirklich mangelhafte 

Entscheidungen. Wenn doch, ist das oft ein 

Zeichen eines tiefer gehenden Problems der 

Person oder des Teams und sollte sofort ange- 

gangen werden. 

Welche Interessen gehen vor? Dazu gibt es 

drei einfache Regeln. Erstens: Die Teaminteressen 

gehen über die eigenen. Zweitens: Die Interessen 

der Firma gehen über diejenigen des 

Teams, und drittens: Kundeninteressen sind 

wichtiger als die Interessen der Firma. 

TRAGWEITE DES ENTSCHEIDS 

Erfahrungsgemäss gibt es zwei Charaktertypen: 

Typ A, der gern mehr entscheiden will, sich 

aber der Tragweite gewisser Entscheide nicht 

bewusst ist und dadurch andere oft vor den 

Kopf stösst. Und Typ B, der sich vor Entscheidungen 

scheut und diese auf die Vorgesetzten 

abschiebt. 

In beiden Fällen muss sich der Mitarbeiter 

zuerst einmal die Frage stellen, ob er die Entscheidung 

selbst treffen soll. Dies ist beispielsweise 

nicht der Fall, wenn eine andere Hierar- 

«Jede dritte meiner 

Entscheidungen ist falsch. 

Daher muss ich mich 

fragen, welchen Spielraum 

wir unseren 

Mitarbeitenden geben» 

Adrian Zwingli 

chiestufe, mehr Fachwissen oder eine höhere 

Akzeptanz nötig ist. Basierend auf der Tragweite 

des Entscheids wird bewusst eines der 

unten genannten Vorgehen gewählt: 

Selbst entscheiden, ohne sich mit anderen 

zu besprechen. 

Das Team um Input fragen, dann selbst entscheiden. 

Rückfrage und Bestätigung: Input des 

Teams einholen, eine Option vorschlagen und 

vor der finalen Entscheidung prüfen, ob diese 

für das Team okay ist. 

Organisations-Entscheidung: Entscheid 

muss durch das Team oder die bestehende 

Organisationsstruktur getroffen werden. 

AUSWIRKUNGEN ABSCHÄTZEN 

Oft ist es wichtig, Entscheidungen schnell zu 

fällen. Aber auch dann sollten sich Mitarbeitende 

fragen, wie die möglichen Auswirkungen 

aussehen. Folgende Überlegungen können dabei 

helfen: 

Schwierigkeit: Wie schwierig ist es, einen 

Konsens mit allen zu finden? 

Dringlichkeit: Wie dringend ist ein Entscheid 

und wie hoch sind die Kosten bei einer Verzögerung? 

Konsequenzen: Welche Auswirkungen hat 

eine falsche Entscheidung? Wer ist davon betroffen? 

Standpunkt: Der Entscheidungsprozess kann 

je nach Perspektive anders aussehen. Dabei 

spielt es auch eine Rolle, wie lange jemand 

bereits im Unternehmen ist. Neue Mitarbeiter 

trauen sich tendenziell weniger, Entscheidungen 

zu fällen. 

KONTEXT STATT KONTROLLE 

Damit Mitarbeitende fundierte Entscheidungen 

treffen können, muss ihnen der Kontext 

bewusst sein, in dem sie operieren. Ohne Informationen 

über die Strategie und die (Bereichs-)Ziele 

ist es kaum möglich, die richtigen 

Wege zu beschreiten. Die richtige Beurteilung 

basiert auf Einblick und Verständnis. Dafür 

sind auch transparente Entscheidungswege 

unabdingbar. 

Auf der anderen Seite kann in gewissen 

Situationen Kontrolle notwendig sein. Zum Beispiel, 

wenn jemand sein Gebiet erst kennenlernt, 

wenn eine Rolle falsch besetzt oder wenn 

keine Zeit vorhanden ist, langfristig das entsprechende 

Wissen aufzubauen. 

JEDE DRITTE ENTSCHEIDUNG IST FALSCH 

Unsere Erfahrung zeigt, dass sich einer von drei 

Entschlüssen trotz besten Wissens und Gewissens 

als falsch herausstellt. Im Nachhinein stehen 

mehr Informationen zur Verfügung, ergeben 

sich neue Erkenntnisse oder es ändert sich 

der Kontext. Dennoch ist es besser, einen Fehler 

zu machen (vorausgesetzt, man hat sich an 

obige Grundsätze gehalten), statt Entscheidungen 

herauszuzögern oder mit schwerfälligen 

Prozessen zu versuchen, diese zu kontrollieren. 

Denn aus Fehlern lernt man. 

Wenn sich nun Führungskräfte bei jeder 

dritten Entscheidung irren, wieso wird dem einzelnen 

Mitarbeiter nicht auch die gleiche Lernmöglichkeit 

eingeräumt? 

KONSEQUENZ: EIN NEUER LEADERTYP 

Entscheidungen durch die betroffene Person 

fällen zu lassen, klingt einfacher, als es in der 

Praxis tatsächlich ist. Führungskräfte müssen 

sich an ein neues Verhalten gewöhnen: Angestellte 

debattieren mit, wollen ihr Wissen und 

ihre Erfahrung einbringen und fordern Beschlüsse 

aufgrund einer Datenbasis. Entsprechend 

wandelt sich das Bild der Führungskraft. 

Nicht ein Kommandant einer Truppe ist gefragt, 

sondern ein Leader, der Visionen gestaltet und 

vermittelt, Ziele herunterbricht und aufzeigt, 

was jeder Einzelne für den Unternehmenserfolg 

beitragen kann. Die Betreuung der Mitarbeitenden 

und anderer Führungskräfte wird intensiver 

und fordert mehr Zeit. Doch das lohnt sich: Die 

Leistung der Einheit steigt. 

Adrian Zwingli ist CEO von SwissQ 

www.swissq.it 

Der Artikel basiert auf dem SwissQ Culture Code. 

Die vollständige Beschreibung finden Sie unter: 

www.swissq.it/verantwortung

Agile 14 

Kursangebot 

Agile 

Leading SAFe 15 

Agile Essentials 16 

Agile Leadership & Transformation 18 

Agile Requirements Engineering 19 

NEU 

Product Owner Expert Skills 22 

User Stories definieren & schneiden 23 

Agiles Testen mit SCRUM 25 

Test Master (Agiles Testmanagement) 28 

NEU 

Scrum Master Expert Skills 29 

Siehe auch Agile Kurse unter «Zertifizierungen», Seite 54

Agile 15 

Leading SAFe 

Introduction 

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

transformation by leveraging the Scaled Agile Framework, and its underlying principles 

of lean thinking, and product development flow. You will leave with an understanding 

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. 

Target Group 

Sprache DE / EN / Unterlagen EN 

Typ firmenintern 

Dauer 2 Tage 

Code SAFE 

Executives, managers and agile change agents leading a Lean/ 

Agile transformation 

Anybody interested in SAFe 

Objectives 

Apply lean, agile and product development flow principles 

Apply the Scaled Agile Framework 

Understand the skills necessary for an enterprise transformation 

Content 

Intro to SAFe 

Lean Thinking 

Agile Development 

SAFe ScrumXP 

Agile Release Train 

Agile Portfolio Management 

Agile 

Requirements 

Testing 


In Zusammenarbeit mit

Agile 16 

Agile Essentials 

Einführung 

Auf Teamebene haben sich die agilen Vorgehensmodelle Scrum und Kanban etabliert. 

Doch warum sind diese so erfolgreich? Welche Prinzipien stecken dahinter? Wo eignet 

sich welches Modell und warum? Nach dem Kurs wissen Sie, wie Sie in der Entwicklung 

systematisch den Business Value steigern, die Time-to-Market verkürzen, die Effizienz 

und Qualität steigern und das Mitarbeiterengagement erhöhen. Sie kennen die ideale 

agile Organisationsform und wie man basierend auf ökonomischen Prinzipien Prioritäten 

setzt. Sie verstehen gängige Lean und Agile Begriffe, wie WIP-Limiten, Batch 

Sizes, Flow, Waste, User Stories, Story Points, Retrospektiven und vieles mehr. 



Dauer 1 Tag 

Code AE 

Dieser Kurs richtet sich an Personen, welche Agilität zusammenhängend verstehen 

möchten. Er vermittelt die Lean und Agile Prinzipien und das nötige Basiswissen, um 

agile Initiativen im Unternehmen zu unterstützen oder weiterzubringen. 

Zielgruppe 

Entscheidungsträger 

Produktmanager 

Projektleiter 

Interessierte an agilen Methoden 

Ziele 

Die Kursteilnehmer verstehen die Prinzipien hinter Lean und Agile und wie diese 

helfen bessere Resultate zu erzielen. Es ist klar, wie die populärsten agilen Methoden 

Scrum und Kanban Lean und Agile umsetzen und das Mitarbeiterengagement 

erhöhen. Zudem können die Teilnehmer beurteilen wann und wo ein agiler Ansatz 

zielführend ist und warum kontinuierliche Verbesserung ein Schlüssel zum Erfolg ist. 

Inhalt 

House of Lean und agile Prinzipien 

wieso Business Value wichtiger als Vorhersagbarkeit ist 

Prozess (bzw. Flow) auf Reaktionsfähigkeit trimmen 

Motivation der Mitarbeiter 

Unermüdliche Verbesserung & Change Management 

Agile 

Requirements 

Testing 


Auch im Package buchbar mit Agile Leadership & Transformation (siehe Seite 18)

Blog 

Agile Modelle im Vergleich: 

Wo passt welches? 

Die meisten Unternehmen haben positive Erfahrungen mit 

einzelnen agilen Teams gemacht. Viele scheitern jedoch beim 

Versuch Agilität auf mehrere Teams und weitere Bereiche auszuweiten. 

Skalierbare Ansätze, wie SAFe oder LeSS, bieten hier 

praktische Hilfe. Um erfolgreich zu sein, muss man jedoch die 

verschiedenen Modelle verstanden haben und Kontext bezogen 

die richtigen Praktiken in einem stimmigen Ganzen anwenden. 

Ein weiterer kritischer Erfolgsfaktor ist die Art und Weise, wie 

man diese umfassende Veränderung einführt. 

Auf Teamebene haben sich die agilen Vorgehensmodelle Scrum 

und Kanban etabliert und erzielen in vielen Fällen die gewünschten 

Resultate. Will man die Agilität auf mehrere Teams und Bereiche 

ausweiten wird es ungemein schwieriger. Viele Firmen sehen 

in der Skalierung von Agilität eine der grössten Herausforderungen 

(Quelle: Trends & Benchmarks Report Schweiz 2015). Potentielle 

Hilfe findet man bei den skalierbaren agilen Vorgehensmodellen 

wie SAFe oder LeSS, um nur zwei momentan häufig genannte 

aufzuzählen. Diese Modelle adressieren die übergeordneten und 

weiterführenden Fragestellungen, welche von Scrum und Kanban 

unbeantwortet gelassen werden. 

Skalierbare Modelle 

werden und deren Abhängigkeiten untereinander, kann man die 

Modelle wie folgt einordnen: 

Wie grösser die Abhängigkeiten, desto stärker ist die Notwendigkeit 

für systematische Koordination und Synchronisation zwischen den 

verschiedenen Organisationseinheiten. Zudem muss die Ausrichtung 

auf die gemeinsamen Ziele und Strategien der möglichst autonomen 

Organisationseinheiten gewährleistet werden. Dies kann Bereiche wie 

die Gesamtarchitektur, User Experience, Plattformstrategie und die 

Systemintegration betreffen. Für grosse und komplexe Unternehmen 

mit vielen bestehenden Systemen sind viele Abhängigkeiten oft die 

Realität. Dieser Realität muss Rechnung getragen werden. 

Erkenntnis 

Die skalierbaren Modelle basieren auf dem gleichen Lean-Agile 

Gedankengut und dessen Prinzipien und Werte. Sie unterscheiden 

sich in der praktischen Umsetzung der Ideen und dem Grad an 

gebotener konkreter Hilfestellung. Ausserdem wird der Kontext 

einer Firma verschieden stark berücksichtigt und es gibt Differenzen 

darüber, ob oder in wie fern traditionelle meist zentralisierte 

Rollen im Produktelieferzyklus ins neue Modell eingebunden 

werden sollen. Auch bei der Kommerzialisierung gibt es erhebliche 

Unterschiede. Dies zeigt sich im Umfang bereitgestellter Schulungen 

und Zertifizierungen oder in der Grösse und Dichte der 

Partnernetzwerke. 

Modelleignung: Organisationsebene vs. «Maturität» 

Bildet man die beiden Dimension Organisationsebene und 

Maturität einer Unternehmung ab und platziert die Modelle 

darauf, ergibt sich nachfolgende Darstellung: 

Nachdem nun das passende Modell eruiert wurde, soll dieses als 

Ausgangspunkt und Leitfaden für die agile Transformation verstanden 

werden. Das Modell sollte stimmig auf das jeweilige Umfeld adaptiert 

und in einem stetigen Lern- und Verbesserungsprozess weiterentwickelt 

werden. Wichtig dabei ist, dass die agilen Prinzipien von 

allen Mitarbeitern und vor allem vom Leadership Team verstanden und 

gelebt werden. Die Ziele, welche man mit der Agilität verfolgt, sollte 

man dabei nie aus den Augen verlieren. Zudem kann es zielführend 

sein aus anderen Modellen die Praktiken zu übernehmen, welche den 

jeweiligen Kontext optimal unterstützen. 

Einführung eines Modells 

Zu Beginn entscheidend ist, dass der relevante Kontext der Firma 

erfasst und berücksichtigt wird. Zudem muss die Frage geklärt werden, 

welchen geschäftlichen Herausforderungen man mit der Agilität 

begegnen will. Eine Einführung ist in jedem Fall komplex und bringt 

erhebliche Veränderungen in den verschiedenen Ebenen und Rollen 

eines Unternehmens mit sich. Dabei wird der Einfluss der Agilität 

auf die Organisation als Ganzes unterschätzt und der notwendige 

Paradigmen- und Kulturwandel findet oft nicht statt. Bei einer agilen 

Transformation müssen die 4 P’s einer Unternehmung (People, Process, 

Place, Product) berücksichtigt werden. Mehr zum Thema agile Transformation 

und das 4 P-Modell im Kontext der Skalierung von Agilität 

finden sie hier. Oder fragen Sie die Experten von SwissQ. 

Weitere Informationen zu den Modellen 

Die Dimension Organisationsebene erläutert, welches Modell 

welche Stufe eines Unternehmens adressiert. Die Maturität bezieht 

sich darauf, in wie fern eine Organisation basierend auf Prinzipien 

operieren kann oder wie stark diese durch definierte Praktiken 

oder Prozesse geleitet werden muss. 

Das Dokument «Vergleich agiler Modelle» bietet Ihnen eine Übersicht 

über die verschiedenen Modelle und dient Ihnen als Orientierungshilfe. 

Es erklärt die Hintergründe zu Scrum, Kanban, SAFe und Co. Erläutert 

wie diese Agilität umsetzen und beschreibt 

welche Modelle sich für welche Art von 

Unternehmen, Produkte und Projekte 

eignen. 

Modelleignung: Portfoliogrösse vs. Abhängigkeiten 

Betrachtet man die Grösse des Portfolios, also die Anzahl der Produkte 

oder Services, welche durch das Unternehmen entwickelt 

Sacha Czudek, 

Head Agile

Agile 18 

Agile Leadership & Transformation 

Einführung 

Die meisten Unternehmen haben positive Erfahrungen mit einzelnen agilen Teams 

gemacht. Viele scheitern jedoch beim Versuch Agilität auf mehrere Teams und weitere 

Bereiche auszuweiten. Eine erfolgreiche und nachhaltige Transformation verlangt 

starkes Leadership. Man muss die kritischen Erfolgsfaktoren einer nachhaltigen agilen 

Transformation kennen. Skalierbare Ansätze, wie SAFe oder LeSS, bieten hier praktische 

Hilfe. Es ist jedoch wichtig Kontext bezogen die richtigen Praktiken in einem 

stimmigen Ganzen anzuwenden. Der agile Paradigmawechsel hat weitreichende Konsequenzen 

auf die Aufbau- und Ablauforganisation und verlangt ein ganzheitliches 

und systematisches Vorgehen. Dieser Kurs richtet sich an Personen, welche in ihrem 

Unternehmen agile Transformationen organisieren und vorantreiben sowie an Personen, 

welche von agilen Transformationen betroffen sind und mehr dazu verstehen 

wollen. Vorgehen für die agile Transformation werden diskutiert und entsprechende 

Praktiken und Tools vorgestellt. 



Dauer 1 Tag 

Code ALT 

Zielgruppe 

Entscheidungsträger 

Projektleiter 

Agile Coaches/Scrum Master 

Interessierte an agilen Methoden 

Ziele 

Die Kursteilnehmer kennen die kritischen Erfolgsfaktoren und Dimensionen einer erfolgreichen 

und nachhaltigen agilen Transformation. Die wichtige aktivierende Rolle 

des Leaderships ist geklärt und mögliche Metriken einer agilen Organisation sind 

bekannt. Die heute gängigsten skalierten agilen Ansätze sind in ihren Grundzügen 

besprochen und es ist klar wann diese wo bevorzugt zum Einsatz kommen. Zudem 

werden folgende Fragen geklärt: Wie integriere ich traditionelle Rollen und was ist 

ein adäquates Training? Welche Strategien gibt es, um mit angrenzenden Bereichen 

erfolgreich zusammenzuarbeiten? Die Teilnahme am Kurs «Agile Essentials» oder entsprechende 

Vorkenntnisse werden empfohlen. 

Inhalt 

Leadership: Überzeugung und Befähigung der Mitarbeiter, agile Planung 

und Metriken 

Vorstellung und Auswahl skalierbarer Ansätze (SAFe, LeSS, …) 

IT – Business Alignment 

Agile Transformation: empfohlenes Vorgehen, Tipps und Tricks 

Agile 

Requirements 

Testing 


Auch im Package buchbar mit Agile Essentials (siehe Seite 16)

Agile 19 


Einführung 

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

in die Unterschiede des Requirements Engineering in traditionellen (wasserfall-orientierten) 

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. 

Sprache DE / EN 


Dauer 1 Tag 

Zielgruppe 

Code 

AREQ 

Projektleiter 

Requirements Engineers 

Product Manager 

Product Owner (künftige) 

Teamleiter 

Ziele 

Sie sind nach diesem Workshop 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 Vorgehensweise zu 

definieren. 

Inhalt 

Ein beispielhafter High-Level Durchlauf durch die RE Aktivitäten auf Produkt-, 

Portfolio-, Release- und Iterationsebene. 

Artefakte im agilen RE-Epic, Feature, User Story und Task. Beispielsstruktur 

und Akzeptanzkriterien. Definition of Ready und Just-in-time-Specification der 

Artefakte. 

Backlog Management. Detaillieren, Schneiden und Priorisieren der Artefakte. 

Minimum Viable Product. 

Events im agilen RE-Backlog Grooming, Planning 1 und Planning 2. Übersicht über 

die RE Aktivitäten auf der Release- und Iterationsebene. 

Mapping Techniques – Story Mapping, Roadmapping und Dependance Mapping. 

Organisationssicht. Rollen und die notwendigen Kompetenzen im agilen RE und 

Faktoren, die eine Organisation bei der Transformation zu agil berücksichtigen 

muss. 

Agile 

Requirements 

Testing 



© SwissQ, Version 0.9 

BIG PICTURE 

internal / external Customers 

PORTFOLIO 

PORTFOLIO 

BUGS 

S.M.A.R.T. GOALS 

Management 

S pecific 

M easurable 

A chievable 

R elevant 

T imely 

€ 

3 

1 

5 

PRODUCT 

PRODUCT BACKLOG 

VISION 

PRODUCT ROADMAP 

MVP 

RELEASE BACKLOG 

RELEASES 

RELEASE ROADMAP 

1 2 3 

3 

1 

5 

Product Manager 

3 

1 

5 

D.E.E.P. 

DoR 

D etailed 

E stimated 

E mergent 

P rioitized 

FEATURE GROOMING 

BAs 

POs 

REs 

STORY GROOMING 

ITERATION 

DoR 

TEAM BACKLOGS 

I.N.V.E.S.T. 

To 

PO PO PO PO 

TEAM 1 TEAM 2 TEAM 3 TEAM n 

Teams & Product Owner 

I ndependent 

N egotiable 

V aluable 

E estimable 

S mall 

T estable 

3 

1 

5 

EPIC TO TASK 

Epic Feature User Story Task 

E1 F1 F2 F3 US1 

US2 

US1 T1 T2 T3 

E2 

F4 F5 

US3 US4 US5 US6 US3 T1 T2 

E3 

F6 F7 F8 F9 

US7 US8 US9 

US7 T1 T2 T3 T4 

JUST IN TIME SPECIFICATION – 

DEFINITION OF READY (DOR) 

US 

US 

US 

US 

US 

US 

US 

DoR 

VISION 

Business Value 

Key Stakeholders 

System Boundaries / Dependencies 

VISION 

DoR 

DoR 

DoR 

F 

F 

F 

F 

F 

DoR 

EPIC TO TASK 

1 

3 

5 

Vision 

Context Diagram 

Vision Glossary 

Business Object 

Model 

Business Process 

Process Model UI Model Wireframes 

Tech Spec 

Personas Data Model 

User Journey 

Choose what 

you need. 

Less is more. 

LEVEL OF DETAIL 

E 

E 

E 

DoR 

TIME 

RELEASE 

DoR 

SPRINT 

DoR 

Epics 

Features 

User Stories 

Tasks 

Why? 

What? 

How? 

Uncertainty / Scribble 

Clarity / Focus

BACKLOG MANAGEMENT 

1 

PRIORITY POKER 

3 

5 

3400 

2100 

500 

1300 

800 

Possible criteria 

(consider at least 2): 

· Business value 

· Strategic fit 

· Risk 

· Cost of delay / urgency 

· Cost/Benefit, ROI, NPV 

· Effort 

· Technical debt 

· Political weather situation 

DISCOVER 

BACKLOG MAGIC 

DELIVER 

Source: Ellen Gottesdiener, «Discover to Deliver» 

WHEN TO ADD DETAIL? 

LOW EFFORT HIGH 

Feature A 

STOP 

Feature B 

Feature C 

Feature D 

TIME 

Influencing factors: 

· (technical) Complexity 

· Existing domain 

knowledge 

· Number of 

dependencies 

· Level of risk in the 

domain 

· Past issues and bugs 

· Number of unknowns 

MINIMAL VIABLE 

PRODUCT (MVP) 

NOT 

THIS 

THIS 

MVP 

SPLITTING 

Business Process 

Data Variants 

Interface 

Simple / Complex 

Non–Functional 

Requirements 

Business Rules 


Workflow Steps 

CONTINOUS 

BACKLOG GROOMING 

PLANNING I 

PLANNING II 

n 

DoD 

· Identify relevant backlog items 

· Clarify items with business stakeholders 

· Socialize and validate with the team 

· Estimate 

· Assess relative priority of the items 

· Split items 

· Repeat the above 

· Select the items according 

to the given priority 

· Clarify and reestimate the items 

· Commit to the items 

· Define the iteration goal 

· Break down epics into features, 

features into user stories and / or 

user stories into tasks 

· Split further if needed (on the same level) 

· Create product, release or sprint backlog 

· Confidence vote 

STORY MAPPING 

ROADMAPPING 

DEPENDENCY MAPPING 

RE ACTIVITIES 

ROLLOUT 

Product 

Increment 

Backbone 

1 2 

High Middle 

Clarity Clarity 

F03 F09 

F10 F43 

3 

Scribble 

F47 

F37 

1 

2 

3 

4 

5 

Sprint 1 Sprint 2 Sprint 3 

F 

F F 

F F 

F F F 

F 

F 

F F 

Product Focus 

Analyse epic / features 

Manage dependency 

Split feature / story 

Refine stories 

Prioritize stories 

Backlog magic 

Release 

RELEASE 

Release 3 

Release 2 

Release 1 

Prio 

F13 F31 F38 

Features 

Product Increments 

UX? F 

ARCH? F 

Needs UX Help 

Needs Sys Arch Help 

F 

F 

F 

= Dependency 

Team Focus Sprint Sprint Sprint 

Communicate user stories 

(planning I and II) 

Clarify user stories 

DoD 

TEAM BOARDS 

Do In Work Verify Done 

3 

1 Prioritize & Estimate 

5 

Prioritize & Estimate 

VIEW OF THE ORGANISATION 

Business Goals 

€ … 

Profitability User Involvement / Feedback 

… 

FOR (target customer) 

WHO (statement of the need or opportunity) 

THE (product name) IS A (product category) 

THAT (key benefit, compelling reason to buy) 

UNLIKE (primary competitive alternative) 

OUR PRODUCT (statement of primary differentiation) 

Crossing the Chasm, Geoffrey Moore 

ACCEPTANCE 

E 

EPIC 

· Description 

· Feature Benefits 

F 

Feature 

· Description 

· Benefit 

· Scenarios 

User Story 

· As a (role) 

· I want (requirement) 

· So that (benefit) 

US 


What must / must not happen 

to deliver the business value 

(in/ out of scope) 

Business Scenario 

Which personas with which 

business scenarios deliver the 

business value 

User Scenario 

Acceptance criteria and/or test 

cases required to move the 

story to a state of complete. 

AGILE REQUIREMENTS ENGINEERING 

PRINCIPLES AND VALUES 

1 Focus on business value 

2 Just in time specification 

3 High customer involvement 

4 Slice and prioritize continuously 

5 Master the art of simplicity 

6 Practice continous improvement 

7 Respond to change 

8 Self-organize 

9 Focus on people 

10Enjoy 

RE ROLES AND COMPETENCES 

LOW METHODICAL EXPERTISE HIGH 

HIGH 

dedicated BA / RE 

in the team 

Proxy PO 

· Requirements Engineer 

· System Engineer 

· Business Analyst 

· Solution Designer 

· Project Manager 

· Product Manager 

3 Amigos 

Agile RE tasks are distributed 

among team members 

ROLES NEW 

· Agile Requirements Engineer 

· Agile Business Analyst 

· UX Expert 

· Release Train Engineer 

· Product Owner 

· Product Manager 

BA Team 

PO Team 

dedicated PO 

PO as part-time job 

[Expert PO] 

ROLES OLD 

= Business expertise 

Product 

Manager 

Culture 

Skills 

Org Structure 

INVIDUAL UNLEARNING ORGANISATIONAL UNLEARNING 

Knowledge 

Process 

INVIDUAL LEARNING ORGANISATIONAL LEARNING 

Mindset 

Infrastructure & Tools 

Behavior 

NEED FOR CHANGE 

INNOVATION ADAPTION CURVE 

2,5 % 

Innovators 

13,5 % 

Early Adopters 

THE ADAPTIVE WALK 

HOW MUCH STRUCTURE DO WE NEED? 

AGILE REQUIREMENTS ENGINEERING 

POSTER 

34 % 

Early Majority 

34 % 

zu bestellen über: 

Late Majority 

16 % 

swissq-1.hs-sites.com/ 

agile-re-poster-order 

Laggards 

GRATIS 

TEAM FOCUS 

PRODUCT FOCUS 

CHAOS 

EDGE OF CHAOS 

STRUCTURE 

Source: based on Jurgen Appelo, «Management 3.0» 

SwissQ Consulting AG | Stadthaus-Quai 15 | CH-8001 Zürich | Fon: + 41 43 288 88 40 | Fax: + 41 43 288 88 39 | Twitter: @SwissQ | eMail: info@SwissQ.it | www.SwissQ.it

Agile 22 

Product Owner Expert Skills 

Einführung 

Die Teilnehmer dieses Praxismoduls lernen die Expert Skills eines Product Owners anhand praktischer 

Beispiele und vieler Übungen kennen. Der Hauptfokus des Trainings liegt auf dem Backlog Management 

und den damit verbundenen Techniken wie z.B. Minimal Viable Release, Priorisierung, Story Mapping und 

Grooming. Erweitert wird das Modul mit einem Einblick in die Organisationsformen und der Positionierung 

des PO in verteilten Teams. 

Zielgruppe 

Product Owner Requirements Engineers Business Analysten Business Projektleiter 

Sprache DE 


Dauer 1 Tag 

Code POEX 

Ziele 

Nach diesem Kurs haben Sie das nötige Rüstzeug, um als Expert Product Owner – auch in verteilten Teams 

– die Qualität der Backlogs vom Portfolio bis hin zum Team-Backlog sicherzustellen. 

Inhalt 

Kurze Einführung in SCRUM 

Die Rolle des Product Owners 

- Definition, Aufgaben, Verantwortung und Kompetenzen 

- Einbettung in Organisation, Stakeholder und SCRUM Team 

- Governance, Quality Control & Reporting 

- Einbindung in die Organisation 

Backlog Management 

- Einsatzgebiet 

- Die drei wichtigsten Aktivitäten des Backlog Managements 

- Grundlagen der Just-in-time-Specification 

- Impact auf nachhaltige Dokumentation 

Expert Skills des Product Owners 

- Story Mapping und Road Mapping 

- Dependency Mapping 

- Schneiden von Artefakten 

- Umgang mit nicht-funktionalen Anforderungen 

Ergänzende Konzepte 

- Kommunikation in verteilten Teams 

- User Experience und User Interaction Design 

Voraussetzungen 

Erfahrung als Product Owner, Grundlagen Requirements Engineering, CPRE Foundation Level Zertifikat 

oder adäquate Ausbildung ergänzt mit Basiswissen SCRUM und/oder SAFe ist ideal. 

Agile 

Requirements 

Testing 


Agile 23 

User Stories def inieren & schneiden 

Einführung 

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

betraut 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 Architekturen 

und die Berücksichtigung von Akzeptanzkriterien. 

Sprache DE 


Dauer 2 Tage 

Code USDS 

Zielgruppe 

Product Owner 


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 


Idealerweise Grundlagen im Requirements Engineering, CPRE Foundation Level Zertifikat 

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

Agile 

Requirements 

Testing 


Agile 25 

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. 

Sprache DE /EN 

Typ öffentlich/firmenintern 

Dauer 2 Tage 

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

bedeutet. 

Code 

ATMS 

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 


Erfahrung in den Bereichen Informatik, Organisation oder Betriebswirtschaft 

Agile 

Requirements 

Testing 


0 

30 

25 

20 

15 

10 

5

AGILE TESTING FRAMEWORK 

POSTER 

zu bestellen über: 

GRATIS 

swissq-1.hs-sites.com/ 

agile-testing-poster-order

Agile 28 

Test Master (Agiles Testmanagement) 

Einführung 

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

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 Testmanagement im 

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

Testmanager vorgestellt. 

Zielgruppe 

Sprache DE 


Dauer 1 Tag 

Code ATMA 

Tester im agilen Umfeld 

Testmanager 

Projektleiter 

Ziele 

Sie lernen die Grundlagen und Vorgehensweisen des agilen Testmanagements kennen 

und verstehen die Rolle des Test Masters. 

Inhalt 

Herausforderungen 

Agiles Testen 

Integration mehrerer Teams 

Agiles Testmanagement 

Test Master 


Grundkenntnisse des Testmanagements und der agilen Entwicklung 

Agile 

Requirements 

Testing 


Agile 29 

Scrum Master Expert Skills 

Einführung 

Wie Scrum funktioniert kann man nachlesen! Wie aber die agilen Projekte in der Praxis 

ablaufen, erfährt man selten. «Getting Things Done!» Lernen Sie Retrospektiven 

richtig aufzusetzen, damit die stetige Verbesserung auch greift. Bereiten Sie Ihr Team 

und Ihre Stakeholder richtig auf User Story Groomings vor, damit diese effizient ablaufen. 

Moderieren Sie Meetings mit Leichtigkeit und unterstützen Sie deren Verlauf 

mit passenden Flipcharts. 

Die Scrum Master Rolle hört nicht beim Teamcoaching auf, sondern fängt dort erst an. 

Verlassen Sie Ihre Komfortzone und begegnen Ihren Projektstakeholdern auf Augenhöhe 

und lernen Sie, wie Sie Ihr Team und dessen Arbeit ins beste Licht rücken. Sie 

führen nicht in Ihrer Scrum Master Rolle, müssen den Projektverlauf aber beeinflussen 

können! Ihr Team wechselt ständig, wie können Sie die Änderungen bestmöglichst 

aufnehmen und wieder in geordnete Bahnen lenken? 

Sprache DE 


Dauer 1 Tag 

Code SMES 

Scrum Master aus der Praxis lassen sich in die Karten schauen und zeigen mit welchen 

Tricks und Fähigkeiten sie ihre Teams performant halten. 

Zielgruppe 

Scrum Master (aktiv oder zukünftig) 

Ziele 

Die Teilnehmer erhalten Einblicke in die Praxis des Scrum Masters und lernen, wie sie 

ihre Fähigkeiten erweitern können, im Team und über die Teamgrenzen hinweg. 

Inhalt 

Gestalten von Retrospektiven 

User Story Grooming 

Moderieren von Meetings 

Führen als Scrum Master 

Stakeholdermangement 

Changemanagement 


Certified Scrum Master oder äquivalent 

Agile 

Requirements 

Testing 


Requirements 30 

Kursangebot 

Requirements 

Requirements Engineering für Manager 31 

Stakeholderanalyse 34 

NEU 

NEU 

Business Value Alignment 35 

Geschäftsprozesse analysieren und verbessern 36 

Visual Facilitation Workshop 38 

NEU 

NEU 

NEU 

Collaboration & Communication 39 

Design Thinking - Einführung mit Gestaltung eines Workshops 42 

UX und Usability im Requirements Engineering 43 

Siehe auch Requirements Kurse unter «Agile», Seite 14 

Siehe auch Requirements Kurse unter «Zertifizierungen», Seite 54


Requirements Engineering für Manager 

Einführung 

Projektleiter benötigen Anforderungen aus vielen unterschiedlichen Quellen. Zum Teil 

erhalten sie diese von Fachspezialisten, zum Teil von weiteren spezialisierten Rollen. 

Was kann ein Projektleiter oder ein Manager 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 

Sprache DE 


Dauer 0,5 Tag 

Code SQ_REMG 

Projektleiter Personen in Führungsfunktionen Manager 

Ziele 

Sie lernen die Grundlagen und Vorgehensweise des Requirements Engineerings kennen, 

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 


Basiswissen des IT-Managements 

Grundlegende Kenntnisse des Software-Entwicklungsprozesses 

Agile 

Requirements 

Testing 


Artikel 

NETZWOCHE 07/2015 www.netzwoche.ch 

Technology Focus 

33 

Wann Anforderungen zum Erfolg führen 

Softwareentwicklung kann unabhängig vom Vorgehen grob in die drei Hauptschritte Design, Build und Test unterteilt werden. 

Ein Hauptergebnis im ersten Schritt sind Anforderungen, die beschreiben, was die Software «können» muss. Je besser die 

Anforderungen desto grösser die Erfolgschancen. 

DER AUTOR 

Anton 

Podokschik 

Consultant 

Requirements, 

Engineering 

and Testing, 

SwissQ 

Die Redewendung «Garbage in, Garbage out» besagt, dass 

schlechter Input mit hoher Wahrscheinlichkeit zu schlechtem 

Output führt. Dies kann sinngemäss auf Anforderungen 

angewandt werden, da sich die Realisierung und das 

Testen daran orientieren. Es ist also im Interesse aller Projektbeteiligten, 

möglichst gute Anforderungen zu schreiben, 

damit das Ergebnis den Erwartungen entspricht. Das 

bedeutet, eine Anforderung muss testbar sein, denn je 

weniger testbar sie ist, desto höher ist das Risiko, am gewünschten 

Ergebnis vorbeizuentwickeln. 

Anforderungen sind aber oftmals mangelhaft und entsprechen 

nicht den gängigen Qualitätskriterien wie vollständig, 

eindeutig, konsistent und aktuell. Für diese Mängel 

gibt es mehrere Gründe. Einer davon ist, dass Anforderungen 

teilweise über Jahre, auf verschiedene Arten – von 

Geschäftsprozessen, über Fachkonzepte zu User Stories – 

und von unterschiedlichen Personen erarbeitet werden. 

Damit ist die Chance gross, dass das ursprüngliche Ziel 

aus den Augen verloren wird. Ein weiterer Grund ist die 

Vernachlässigung des methodischen Vorgehens. Vielleicht 

fehlen die theoretischen Kenntnisse beziehungsweise die 

praktische Erfahrung. Oder die Anforderungen müssen 

unter Zeit- und Budgetdruck erstellt werden. Die Anforderungserhebung 

erfolgt unstrukturiert und verkommt zu 

einem notwendigen Übel, die Qualität bleibt jedoch auf 

der Strecke. 

Halde geschrieben, die rasch veralten und eventuell nie 

realisiert werden. 

Ist man bereits mit mangelhaften Anforderungen konfrontiert, 

helfen die erwähnten Massnahmen nicht. Steht 

man am Anfang der Umsetzung der Anforderung, hilft das 

sogenannte Tres-Amigos-Prinzip. Die Tres Amigos – Anforderungsersteller, 

Entwickler und Tester – klären gemeinsam 

die offenen Punkte, treffen Design-Entscheide 

und erstellen Testideen. Im Test setzt man auf exploratives 

Testen. Anstatt unnötig Zeit mit der Erstellung von Testfällen 

auf der Basis von schlechten Anforderungen zu vergeuden, 

erfolgt der Test in Form von «Sessions». Dabei 

lernt man das System kennen, findet Fehler und entwickelt 

gleichzeitig Ideen für weitere Sessions. 

Frühzeitig testen 

Eine weitere Redewendung lautet «If you can’t test, you can’t 

build it». Indem man sich frühzeitig überlegt, wie die Software 

getestet werden soll, werden Ungereimtheiten ausgeräumt. 

Gleichzeitig betrachtet man damit nicht nur den 

Schönwetterfall, denn der Teufel liegt ja bekanntlich im 

Detail, sprich in den Spezial- und Ausnahmefällen. Testbare 

Anforderungen liefern somit eine wichtige Grund lage für 

eine erfolgreiche Softwareentwicklung. 

Das Problem an der Wurzel packen 

Es braucht zuerst einmal die Erkenntnis, dass schlechte 

Anforderungen die Wurzel des Problems sind. Dann 

kann man Massnahmen ergreifen, um diesen vorzubeugen. 

Ein probates Mittel ist der frühzeitige Review. Bindet 

man in diesen zusätzlich die Tester ein, werden fast 

zwangsläufig Unstimmigkeiten aufgedeckt. Fehler werden 

früh und somit kostengünstig entdeckt. Eine weitere 

effektive Technik ist die Erweiterung der Anforderungen 

durch Akzeptanzkriterien. Diese beschreiben die Erwartungen 

des Kunden an die Lösung und stecken den Rahmen 

einer Anforderung ab. Dadurch wird definiert, worauf 

in der Entwicklung und im Test geachtet werden 

muss, was der Qualität zugute kommt. Erwähnenswert 

ist zudem die Methode der Just-in-Time-Spezifikation. 

Hierbei werden die Anforderungen zuerst nur grob erhoben. 

Detailliert werden diese nur, wenn der Umsetzungszeitpunkt 

naht. Somit werden keine Anforderungen auf 

Im Vorfeld der Softwareentwicklung sollten Projektverantwortliche 

sorgfältig planen, um nachfolgende Probleme zu vermeiden. 

www.netzwoche.ch © netzmedien ag 07 / 2015


Stakeholderanalyse 

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 Stakeholderanalyse 

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

Begriffe Stakeholder, Stakeholderanalyse 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 Stakeholderanalyse erzeugen. 

Sprache DE 


Dauer 1 Tag 

Code RESA 

Zielgruppe 


Business Analysten 


Ziele 

Die Teilnehmer dieses Workshops erhalten einen Einblick in die Themen Stakeholder– 

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

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

können. 

Inhalt 

Grundlagen & Begriffe Stakeholderanalyse 

Stakeholder als Quellen von Anforderungen 

4 Schritte zur Durchführung der Stakeholderanalyse 

Prinzipien des Stakeholder Managements 


Grundlagen des Requirements Engineerings 

Grundlagen Vorgehensmodelle der Software-Entwicklung 

Agile 

Requirements 

Testing 




Einführung 

Die Teilnehmer dieses Praxismoduls lernen das Konzept des agilen Requirements 

Engineerings mit Fokus auf Business Value Alignment vertieft kennen. Kern bildet 

dabei das Thema, wie Business Value von der Vision bis in die einzelnen User Stories 

nachvollziehbar übertragen werden kann und wie dieses Konzept im Alltag des Product 

Owners eingesetzt wird. 

Sprache DE 


Dauer 1 Tag 

Zielgruppe 

Code 

BUVA 

Product Owner 




Ziele 

Nach diesem Kurs haben Sie das nötige Rüstzeug, um den Business Value von der 

Vision bis hin zur User Story sicherzustellen. 

Inhalt 

Kurze Einführung in agile Methoden 

Artefakte der agilen Business Analyse: Vision, Epic, Feature, User Story 

Grundlagen Backlog Management 

- Einsatzgebiet 

- Die drei wichtigsten Aktivitäten des Backlog Managements 


- Grundprinzip 

- Idee / Vision entwerfen 

- Schärfen – Priorisierung und Fokus setzen 

- Umsetzen – Vision entwickeln 

- Validieren – Vision prüfen und testen 

- Adaptieren – Feedback valideren und einbinden 

Ergänzende Konzepte 

- Kommunikation in verteilten Teams 

- Rapid Prototyping 

- User Experience und User Interaction Design 


Erfahrung als Product Owner, Grundlagen Requirements Engineering, CPRE Foundation 

Level Zertifikat oder adäquate Ausbildung, ergänzt mit Basiswissen SCRUM 

Agile 

Requirements 

Testing 



Geschäftsprozesse analysieren und verbessern 

Einführung 

scout [engl.] /skaut/ Nomen 1. Englische Bezeichnung für Pfadfinder 2. Jemand der 

Etwas aufspüren soll 3. Kundschafter 4. Verb: Etwas oder jemanden an verschiedenen 

Plätzen suchen 

Sprache DE 

Typ 

firmenintern 

Sind Sie ein Business Value Scout? Also stetig auf der Suche nach Möglichkeiten, um 

die Abläufe Ihres Unternehmens, Arbeitgebers oder Kunden zu verbessern und somit 

den Business Value zu erhöhen? Wenn ja, dann ist dieses Praxismodul für Sie! Wir liefern 

Ihnen Antworten auf folgende Fragestellungen: Wie identifiziere und vermeide ich 

«Waste» in Geschäftsprozessen? Welchen Einfluss hat der Mensch und die Unternehmenskultur 

auf den Erfolg der Prozessverbesserungsinitiative? Welches sind die Do’s and 

Don’ts der Prozessanalyse und Modellierung aus der Praxis? 

Dauer 

Code 

1 Tag 

GPAV 

Zielgruppe 

Business Value Scouts, und die, die es werden wollen: Business Analysten, Requirements 

Engineers, Process Owners, Business Projektleiter 

Ziele 

Sie vertiefen Ihre Business Value Scouting Skills und lernen dabei gezielt «Waste» in 

Geschäftsprozessen zu identifizieren und zu vermeiden. Sie schärfen dabei Ihr Verständnis 

für kulturelle Erfolgsfaktoren und wenden die Essentials der Prozessanalyse 

und Modellierung an. 

Inhalt 

Die 7 Arten der Verschwendung: Identifikation und Vermeidung von «Waste» 

in Geschäftsprozessen 

Erfolgsfaktoren der Prozessverbesserung 

- Kultur: Mut zur Lücke, Offene Kommunikation, Fail Early 

- Agilität: Plan – Do – Act – Check 

- Modellierung: Anti-Patterns und Best Practices 

Essentials: 5S Methode, Business Motivation Model, BPMN 2.0, Service 

Blueprints u.a. 


Grundlagen der Business Analyse und erste Erfahrung in der Analyse & Modellierung 

von Geschäftsprozessen 

Agile 

Requirements 

Testing 


Blog 

Requirements Engineering ist nicht sexy 

«Requirements Engineering ist nicht sexy». 

Das war ein der Aussage, die ich bei einer 

Umfrage unter RE-Verantwortlichen von 

verschiedenen Firmen bekommen habe. 

Als passionierter Requirements Engineer 

war ich natürlich zuerst einmal empört 

über diese Aussage. Nach einigem Nachdenken 

musste ich dann aber zugeben, 

dass dies doch nicht so falsch ist. Warum 

ist das so und was kann man dagegen tun? 

RE ist nicht sexy – wieso? 

In SW-Entwicklungsprojekten geben Produktmanager oder 

Produkt Owner vor, was implementiert werden soll. Projektleiter 

steuern das Projekt. Entwickler sind sowieso cool, vor 

allem wenn sie objektorientiert programmieren und/oder in 

einem agilen Team sind. Alle diese Rollen werden als sexyer 

angesehen als REs. Und Tester … OK, Testing wird wohl als 

noch weniger sexy angesehen als RE (das dürfen meine 

Test-Kollegen gerne kommentieren). 

In der Tat hat das Ansehen von RE in der letzten Zeit abgenommen. 

Im Vergleich zu 2014 ist in unserem neuesten Trends 

& Benchmark-Report die Zustimmung zur Aussage «RE ist für 

den Erfolg der Organisation strategisch» stark von über 50% 

auf 14% gefallen. Dagegen ist die Zustimmung zu «RE ist ein 

wichtiger Faktor um verlässliche Software zu produzieren» von 

20% auf 50% gestiegen. Das hört sich immer noch OK an – 

aber sexy? 

Irgendwie hat ja schon jeder im Projekt das Gefühl, dass der RE 

einen wichtigen Beitrag zum Projekterfolg leistet. Aber können 

wir das auch beweisen? Man kann für RE relevante KPIs definieren. 

Aber auf die für das Management entscheidende Frage fällt es 

zumindest mir schwer, eine Antwort zu geben: «Um wieviel sind 

die Einsparungen durch professionelles Requirements Engineering 

höher als die Kosten, die es verursacht?» Also, was kann mal also 

sonst machen? 

Und was kann man tun? 

Eine Antwort ist, dass Profil zu schärfen: Dazu gehört, die Rolle 

des Requirements Engineers klar zu definieren. Dabei ist insbesondere 

die Abgrenzungen zu anderen Rollen im Projekt deutlich 

darzustellen. Das heisst nicht, dass der RE nicht auch andere 

Aufgaben übernehmen darf, z.B. mit zu testen. Aber es muss klar 

sein, was zu seinem Kernaufgabengebiet gehört und was nicht. 

Ausserdem gilt: «Tue Gutes und sprich darüber». Viele RE-Organisationen 

sind noch zu defensiv, wenn es um Selbstmarketing 

geht. Die eigene Leistung und Erfolge herauszustellen hat nichts 

mit Überheblichkeit zu tun, sondern ist ein wichtiges Mittel, 

um Akzeptanz im Unternehmen zu erreichen. Ein monatliches 

Newsletter ist OK, wird aber oft nicht gelesen. Etwas besser ist es, 

ab und zu in Management-Meetings die vergangenen Highlights 

zu präsentieren. In einer Roadshow wichtigen Stakeholder (z.B. 

Produktmanager, Architekten, Testmanager) darzustellen, welche 

Dienstleistungen man anbietet, wie die Prozesse aussehen und 

was man von ihnen erwartet, hilft, die Akzeptanz der eigenen 

Arbeit zu steigern. 

Weiterhin ist es wichtig, laufend zu reflektieren, ob die Dienstleistungen, 

die wir als RE anbieten, noch angemessen sind. Wenn 

sich das Unternehmen z.B. in Richtung Agilität entwickelt, kann 

eine Facilitator-Rolle in den Teams nötig werden. Diese kann 

durch kommunikative REs gut gefüllt werden. Gibt es im Unternehmen 

schon jemand, der sich mit Usability beschäftigt? Wenn 

nicht, kann ein RE sich weiterbilden und diese Rolle abdecken. 

Ein scharfes Profil, ein gesundes Selbstmarketing und die 

Reflektion der eigenen Tätigkeit können also einen wertvollen 

Beitrag dazu leisten, dass Requirements Engineering in Zukunft 

als ein bisschen sexyer angesehen wird. 

Weitere Informationen, Ideen und 

Anregungen zu Requirements Engineering 

The Business Analysis Center of Excellence, Requirements 

Engineering Magazine 2015-3, IREB 

In agilen Projekten muss der RE oft um seine Daseinsberechtigung 

kämpfen. Man ist ja ein Team und da braucht 

es keine speziellen Rollen (Tester sind davon auch betroffen, 

aber etwas weniger). Wenn der RE Glück hat, darf er noch 

Proxy-PO für den vielbeschäftigten Produktmanager spielen. 

Dabei muss er bei Entscheidungen aber immer rückfragen, was 

nicht gerade sein Ansehen stärkt. 

Christoph Wolf, 

Principal Consultant


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 Symbolen 

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 Testworkshops 

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. 



Dauer 1 Tag 

Code VF 

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 

Basiselemente 

Aufbau Visual Facilitation 

Plakate erzählen Geschichten 

Hilfsmittel 

Spezifischer Einsatz von Visual Facilitation im beruflichen Alltag 

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

des Workshops erstellt. 

Agile 

Requirements 

Testing 



Collaboration & Communication 

Einführung 

In diesem Praxisseminar zeigen wir auf, welche Formen von Meetings es gibt und wie 

Meetings in produktive Workshops verändert werden können. Die Teilnehmer lernen, 

wie sie Workshops vorbereiten und moderieren, welche Formen der Kommunikation 

es gibt und wie diese zielgerichtet eingesetzt werden. 

Zielgruppe 

Product Owner 




Sprache DE 


Dauer 1 Tag 

Code COCO 

Ziele 

Die Teilnehmer dieses Praxisseminars erhalten einen Einblick in die Einsatzgebiete von 

Workshops, die Grundlagen der Kommunikation und werden befähigt, dieses Wissen 

in ihrer täglichen Arbeit mit den Stakeholdern einzusetzen. 

Inhalt 

Grundlagen der Kommunikation 

- Kommunikation auf verschiedenen Kanälen 

- Missverständnisse in der Kommunikation und ihre Hintergründe 

Grundlagen Konfliktmanagement 

- Wieso es Konflikte geben kann? 

- Konflikte erkennen und darauf reagieren 

Grundlagen Meetings 

- Bausatz eines guten Meetings 

Wie ein Meeting zum Workshop wird 

- Planung und Vorbereitung von Workshops 

- Durchführung von Workshops 

- Tipps und Tricks in der Moderation von Workshops 

- Abschluss und Protokollierung von Workshops 

Agile 

Requirements 

Testing 


Blog 

Das Wissen im Raum nutzen? Nichts einfacher als das! 

Als eingefleischter Requirements Engineer bietet mir in meiner 

Rolle als Trainer die Durchführung von Vorbereitungskursen zur 

IREB CPRE FL Zertifizierung eine willkommene, aber auch 

anstrengende Abwechslung zum Beratungsalltag. 

Je nach Teilnehmerkreis sitzen im Vorbereitungskurs Berufskolleginnen 

und -kollegen mit teils langjähriger Berufserfahrung, 

welche einfach das Zertifikat erlangen wollen. 

Zu Beginn meiner Tätigkeit als Kursleiter war es für mich nicht 

immer einfach, einen Kurs zu leiten, in dem die Teilnehmer 

mehr Fachwissen als ich als Trainer hatten: auf Grund meiner 

Konditionierung war ich der Ansicht, dass ich als Trainer 

eigentlich einen Wissensvorsprung gegenüber den Kursteilnehmenden 

haben muss, oder? 

Heute sehe ich dies ganz anders: je mehr Wissen im Raume ist, 

desto mehr können wir alle, also die Teilnehmenden und ich 

als Trainer, profitieren. In meiner Rolle als Trainer muss ich nur 

sicherstellen, dass Wissen zielgerichtet eingesetzt und aktiv 

eingebracht wird. In diesem Blog will ich 5 Tipps aus meiner 

Praxis weitergeben, wie ich das Wissen im Raum einbinde. 

Einmaligkeit des Kurses 

Jeder Kurs ist einmalig, und verfolgt trotzdem dasselbe Ziel: 

die Teilnehmenden erfolgreich auf die Zertifizierungs-Prüfung 

vorzubereiten. 

Meine drei letzten Kursdurchführung konnten vom Teilnehmerkreis 

her betrachtet nicht unterschiedlicher sein: 

ein Inhouse-Kurs bei einem namhaften Consulting 

Unternehmen in Zürich, bestehend aus einem Dutzend 

erfahrener Requirements Engineers, ein öffentlicher Kurs 

mit Teilnehmenden mit unterschiedlichstem Kenntnisstand, 

und ein Crash-Kurs an einer Fachhochschule mit Studierenden, 

welche oft keine oder nur wenig Praxiserfahrung mitbringen. 

Wie gehe ich damit um? Wie kann ich sicherstellen, dass am 

Ende des Vorbereitungskurses trotz den unterschiedlichen 

Voraussetzungen alles Kursteilnehmenden erfolgreich den Kurs 

abschliessen können? 

Tipp 1: Teilnehmerkreis kennen 

Mir ist es als Trainer wichtig, am Anfang genügend Zeit 

darin zu investieren, die Teilnehmer kennen zu lernen. 

Dazu verwende ich meist folgende drei Fragestellungen: 

C 

Was sonst für Fragen sind aktuell 

ganz zuvorderst? 

Die Frage nach der persönlichen 

Erfahrung im Thema hilft mir, die 

Teilnehmenden bessern durch ihren 

Lernprozess zu begleiten. 

Mehr dazu in Tipp 3. 

Tipp 2: Abgleich der Ziele mit den Kurszielen 

Die Ziele der Teilnehmenden werden für alles sichtbar aufgehängt und 

nun mit den Kurszielen abgeglichen. Zusammen mit den TN priorisieren 

wir die Ziele – beim Vorbereitungskurs auf die Zertifizierungsprüfung 

ist logischerweise das wichtigste Ziel «Bestehen der Prüfung». 

Das hilft mir im Verlauf des Kurses, die Lernprozesse so zu steuern, 

dass sie dem Erreichen der zusammen am Kursanfang vereinbarten 

Ziele dienen. 

Nun können wir in den eigentlichen Kurs einsteigen. 

NB: auch im eintägigen Crash-Kurs gehe ich so vor – an diesem Teil 

kann keine Zeit gespart werden. 

Tipp 3: Expertenwissen gezielt abrufen 

Während dem Kurs gibt es vielerlei Möglichkeiten, das 

Expertenwissen im Raum einzubinden. Ich will dies an drei 

konkreten und direkt umsetzbaren Beispielen illustrieren. 

Beispiel1: Übungen: 

Im Rahmen von Übungen kommen oft 

sehr kreative und detaillierte Lösungen, 

in denen das Wissen einfliesst. Oft kann 

in diesen Fällen auf das Präsentieren 

einer vorbereiteten Musterlösung verzichtet 

werden und mindestens eine der 

Lösungen aus dem Workshop als mögliche 

Musterlösung besprochen werden. Damit 

wir dem Wissen der Teilnehmenden Platz 

gegeben. Ideal dafür ist natürlich, wenn 

die Lösung in einer Kleingruppe direkt an 

einem Flipchart erarbeitet werden kann. 

A 

B 

Was bringen die Teilnehmenden als Erfahrung in 

Zusammenhang mit dem Kursinhalt mit? 

Welche Erwartungen an den Kurs haben die TN? Wie wissen 

die TN, dass sie am Ende des Kurses zufrieden sind? 

Achtung Falle: ein bis zweimal pro Kurs 

muss ich selbst mit einer guten Musterlösung auftrumpfen, um mich 

bei den Kursteilnehmenden als Experte zu positionieren. Ich habe 

auch schon erlebt, dass mit der Zeit die Teilnehmenden das Gefühl erhalten 

haben, dass ich als Trainer ja gar nichts weiss, das Praxis-Wissen 

komme ja immer von Ihnen. Wichtig ist, diese Momente zu erkennen 

und dann mit ein oder zwei konkreten und guten Beispielen aus 

meiner Praxis aufzutrumpfen.

Beispiel 2: Bezug zur Praxis der Teilnehmenden 

«Wie macht ihr das bei euch?»: Beispiele zur Illustration eines 

Sachverhaltes sollen von den TN selbst eingebracht werden. 

Wo setzen die TN die soeben gehörte Theorie bewusst ein? 

Welchen Unterschied sehen die TN in Ihrer Praxis zur erklärten 

Theorie? Wo sehen die TN Schwierigkeiten im Umsetzen der 

Theorie in ihrer Praxis? Damit werden die TN zu Beteiligten, 

fühlen sich als Mensch wahrgenommen und nehmen aktiver 

am Kurs teil. 

Beispiel 3: Diskussionen 

Es kann gut sein, dass Diskussionen im Raum entstehen. 

Bilaterale Gespräche können moderativ in den Vordergrund 

geholt werden, und als kleine Auflockerung zu einem kurzen 

Austausch überleiten. 

Gerne reisse ich auch ein- bis zweimal pro Kurs eine kurze 

Diskussion zu einem neu einzuführenden Thema ein: «Was 

habt ihr für Erfahrungen mit dem folgenden Thema?», oder 

«Welche Assoziazionen weckt das folgende Thema bei euch?». 

Achtung Falle: bei jeder Diskussion muss ich als Moderator 

sicherstellen, dass die Diskussion nicht ausufert und zu viel 

Zeit beansprucht. Ebenso muss ich spontan auftretende 

Verwirrungen oder inhaltlich nicht korrekte Aussagen von 

Teilnehmenden auffangen und auflösen. Hier kann auch der 

Parkplatz gute Dienste leisten, indem ich mit Rücksicht auf die 

Zeit ein nicht zu Ende diskutiertes Thema dort hinterlege. 

Tipp 4: Abschweifungen erkennen 

und positiv beenden 

Gerade wenn TN ihr Wissen einbringen dürfen und sollen, wird 

die Situation immer wieder auftauchen, dass Diskussionen 

abschweifen, oder zwei Meinungen im Raum aufeinander 

prallen. In diesem Fall verwende ich, falls mir nichts anderes 

spontan in den Sinn kommt, einer der beiden folgenden Tricks: 

«Parkplatz»: Am Anfang 

jedes Kurses hänge ich ein 

leeres Flip-Chart auf mit 

einem grossen blauen P. Auf 

diesem Parkplatz findet alles 

einen Platz, das nicht der 

eigentlichen Zielerreichung 

dient. Also auch spannende 

Diskussionsthemen. In einer 

Pause oder gegen Ende des 

Tages können diese Themen 

bilateral oder im Plenum 

aufgegriffen werden. 

«Moderativ einschreiten»: ich gehe physisch in die Mitte des 

Raumes, unterbreche die Diskussion, danke für das aktive Mitarbeiten 

und verbalisiere dabei meine Gefühle: ich denke nicht, 

dass die Diskussion uns helfe, die gesetzten Ziele zusammen zu 

erreichen. Aus diesem Grunde erlaube ich mir als Moderator und 

Verantwortlicher für die Zielerreichung, die Diskussion nun zu 

beenden mit dem Angebot, das Thema zB. über die Mittagspause 

ausserhalb des Kursraumes wieder aufzunehmen. 

Tipp 5: Ich bin «nur» der Trainer, 

die TN sind das Lernteam 

Als Trainer sehe ich mich nicht als einziger verantwortlich für die 

Lernerfolge der Teilnehmenden, sondern teile mir diese Verantwortung 

zusammen mit den Teilnehmenden. 

Fazit: 

Wir halten dies am Anfang der Lernsequenz 

fest und formulieren zusammen 

unsere Spielregeln. Um eine lernfördernde 

Umgebung zusammen herzustellen, 

gehört es in der heutigen Zeit zum 

Beispiel auch dazu, den Umgang mit 

elektronischen Medien zu reglen. In den 

Pausen kein Problem, sonst grundsätzlich 

abgestellt. 

Zusammen mit den Lernzielen hilft mir 

das, den Lernprozess zu lenken und 

sicherzustellen, dass das Lernteam in der 

vorgesehen Zeit die Lernziele erreichen 

kann. 

Wichtig ist aus meiner Sicht primär, dass ich mich als Trainer 

und nicht als allwissender Dozent sehe. Diese Haltung führt 

automatisch dazu, dass ich das Wissen im Raum nicht als Gefahr 

(ich als Referent sollte doch alles wissen) wahrnehme, sondern 

als Chance sehe den Lerneffekt zu verstärken und das Wissen zur 

Zielerreichung uns zu Nutze mache. 

Wie machst du das? Was für Tipps und Tricks wendest du an? 

Ich freue mich auf tolle Feedbacks und auf Deine Erfahrungen 

aus der Praxis. 

Alain Hofer, 



Design Thinking - 

Einführung mit Gestaltung eines Workshops 

Einführung 

Können Sie sich ein Leben ohne Dienstleistungen vorstellen? Keine Kreditkarte, kein 

Online Check-In, kein Pizzakurier?! Wann waren Sie zuletzt im Stress, in einer fremden 

Stadt, und wollten ein Ticket für den Bus, Zug oder die Metro am Automat kaufen? 

Wieviel Nerven kostet Sie das Zügeln und die nachfolgenden Adressänderungen? Waren 

Sie schon mal verärgert über Ihre Versicherung? Wechseln Sie nun die Perspektive 

und versetzen sich in die Lage des Dienstleistungsanbieters. Heutzutage kauft der 

Kunde nicht nur eine Dienstleistung, sondern er kauft ein «Erlebnis». Service Design 

Thinking ist ein Prozess zur ganzheitlichen Gestaltung und Entwicklung von Dienstleistungen. 

Dabei steht das Kundenerlebnis, also die Interaktionen zwischen dem Anbieter 

der Dienstleistung und dem Kunden, im Mittelpunkt. Dieses Praxismodul richtet 

sich in erster Linie an Interessierte, die erlernen möchten wie man einen Design Thinking 

Workshop vorbereitet und durchführt. 

Sprache DE 


Dauer 1 Tag 

Code DETHI 

Zielgruppe 

Design Thinkers und die, die es werden wollen: Business Analysten, Requirements 

Engineers, UX Experten, Product Owners, Produkt Manager 

Ziele 

Sie lernen die Prinzipien des Service Designs kennen 

Sie erleben wie der Design Thinking Prozess funktioniert 

Sie wenden verschiedene Service Design Techniken an 

Sie verbessern Ihre Moderationstechniken 

Sie lernen Visual Facilitation kennen 

Inhalt 

Kano-Model The 5 Whys Personas 

Customer Journey Canvas Emotional Journey Service Blueprints 

Co-Creation Storytelling Customer Lifecycle Maps 

Business Model Canvas 


Erfahrung mit der Business Analyse/Requirements Engineering 

Interesse am Design Thinking und/oder Visual Facilitation 

Grundlagen der Moderation von Workshops 

Agile 

Requirements 

Testing 



UX und Usability im Requirements Engineering 

Einführung 

Eine gute UX eines Produkts basiert auf der benutzerzentrierten Anforderungserhebung, 

wie sie das Vorgehen nach User Centered Design vorsieht. Ein wichtiges Teilgebiet 

von UX ist Usability, welche sich mit der benutzerfreundlichen Bedienung beschäftigt. 

Dazu gehört die Zielsetzung, dass das Produkt den Benutzer in seiner Arbeit 

zufriedenstellend unterstützt. Für den Requirements Engineer heisst das, dass er bei 

der Anforderungserhebung die Bedürfnisse, die Aufgabe und das Arbeitsumfeld des 

Benutzers verstehen muss, um für das Produkt eine gute UX und Usability zu erreichen. 

Dieser Kurs bietet eine Einführung in die Methoden zur Anforderungserhebung 

und –validierung aus dem User Centered Design und zeigt auf, dass der Einbezug von 

Benutzern im Requirements Engineering ein Schlüsselfaktor bei der Investition in eine 

gute UX und Usability ist. Theorie Inputs und Praktische Übungen führen in diese Methoden 

ein und zeigen auf, wie sich diese in klassischen und agilen Vorgehensweisen 

einbetten lassen. 

Sprache DE 


Dauer 1 Tag 

Code UURE 

Zielgruppe 


Product Owner 



Ziele 

Die Teilnehmer erhalten einen Einblick 

in Vorgehensweisen zur Erreichung einer guten Usability 

in die Kernelemente des User Centered Design 

in Methoden zur benutzerzentrierten Anforderungserhebung und –validierung 

in Aspekte zur Methodenauswahl in klassischen und agilen Projekten 

Inhalt 

Begriffe UX und Usability 

Benutzerzentrierte Erhebungstechniken 

Walkthrough vs. Usability Test 

Einbindung der Methoden im RE Vorgehen 


Grundsätze User Centered Design 

Prototyping 

Agile 

Requirements 

Testing 

Grundlagen im Requirements Engineering, Idealerweise CPRE Foundation Level Zertifikat 

oder adäquate Ausbildung 


Testing 44 

Kursangebot 

Testing 

Software-Testing für Manager 45 

NEU 

NEU 

Testmanager Expert Skills 46 

Testdesign Expert Skills 47 

Session Based Testing 48 

Best Practices in Test Automation 50 

Best Performance Test Implementation 51 

Manage Outsourced SW-Testing 53 

Siehe auch Testing Kurse unter «Agile», Seite 14 

Siehe auch Testing Kurse unter «Zertifizierungen», Seite 54

Testing 45 

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 Testmanager erwarten? 

Nach welchen Prinzipien arbeiten diese? 


Typ 

firmenintern 

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

des Software Testens auf Managementebene vermittelt. 

Zielgruppe 

Dauer 

Code 

0,5 Tag 

STMA 

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 


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

Agile 

Requirements 

Testing 


Testing 46 

Testmanager Expert Skills 

Einführung 

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

So sind z.B. die Ressourcenplanung und der Umgang mit Stakeholdern auf allen Stufen 

ebenso elementare Aufgaben, welche der Testmanager beherrschen muss. Nebst den 

Methodik-Tasks zählen also auch Themen aus dem Bereich Projektmanagement und 

Soft-Skills wie Präsentationstechnik und Moderation zu den Fähigkeiten, welche nötig 

sind um ein erfolgreiches Abschliessen mittlerer und grösserer Testprojekte gewährleisten 

zu können. Dieser Kurs beleuchtet diese Expert Skills anhand anschaulicher 

Beispiele, wie der Planung und Durchführung eines Test Kick-Off Meeting, von der 

Einladung der richtigen Personen, über die Präsentation, bis zur Zusammenfassung 

und dem Tracking der offenen Punkte. Thematisiert wird auch das Testmanagement 

in agilen Projekten. 

Sprache DE 


Dauer 2 Tage 

Code TMEX 

Zielgruppe 

Testmanager 

Test Master 

Test Koordinatoren 

Ziele 

Dieser Kurs ermöglicht dem Testmanager ein vollumfängliches Projektmanagement 

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

Projektleitung mit Fokus auf Testing beleuchtet. Ausserdem kann der Teilnehmer nach 

diesem Kurs effektiv und zielgerichtet kommunizieren. Er versteht die Wichtigkeit von 

Informationen, weiss diese zu priorisieren und die daraus resultierenden Inhalte entsprechend 

zu vermitteln. 

Inhalt 

Aufgaben und Terminplanung 

Stakeholder-Management 

Kommunikationsplanung 

Moderationstechnik 

Präsentationstechnik 

Kickoff-Meeting 

Konfliktmanagement 

Agile 

Requirements 

Testing 


Testing 47 

Testdesign Expert Skills 

Einführung 

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

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

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

Es erlaubt unter anderem, Aussagen über die Testabdeckung dieser Anforderungen 

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. 

Sprache DE 


Dauer 2 Tage 

Code TDiP 

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 auf Basis 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 

Agile 

Requirements 

Testing 


Testing 48 

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 Anforderungen), 

entsteht eine transparente und nachvollziehbare Testdokumentation. Eine 

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

Zielgruppe 

Sprache DE 


Dauer 1 Tag 

Code SBTE 

Testmanager 

Projektleiter 

Ziele 

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

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

bewusst, welche Vorteile/Nachteile Session Based Testmanagement 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 

Agile 

Requirements 

Testing 


Blog 

CELEBRATE BUGS! 

Warum wir Fehler feiern müssen. 

Ich komme einfach nicht an dem Thema vorbei. Es gab bis heute noch keinen Kunden, der in 

der agilen Software Entwicklung keine Abneigung gegenüber dem Berichten von Fehlern hatte. 

Meist liegt es an der Firmenkultur, die Fehler als etwas Schlechtes ansehen und darauf mit 

Fingern zeigen. Ich höre aber auch immer mehr die dogmatische Äusserung der agilen Jünger, 

dass das Vertrauen über der Kontrolle steht (was ja gut und recht ist) und darum keine Bugs 

erfasst werden sollen (was weder gut noch recht ist). Wir kontrollieren mit den gefunden Bugs 

keine Teams sondern erhalten über die Qualität des Produktes Auskunft. Erst dann wenn wir 

uns bewusst werden, was wir aus Fehlern alles lernen können, wird der Kontrollgedanke 

verdrängt. Und jetzt ist es endgültig an der Zeit, die kleinen Käfer unter die Lupe zu nehmen. 

Fakt 1: Ein Bug ist ein Bug ist kein Bug 

Was ist eigentlich ein Bug? Ist es ein Fehlerzustand, sprich: ein 

inkorrektes Teil eines Programmes oder Dokumentes? Oder ist es 

eine Abweichung vom erwarteten Soll- zum gelieferten Ist-Zustand? 

Handelt es sich bei einem Bug um die Fehlermeldung, die 

uns auf dem Bildschirm erscheint oder in Form eines Systemabsturzes 

auffällt? Der Bug ist ein sehr gängiger Überbegriff 

von all den erwähnten Situationen oder besser gesagt: Es ist ein 

Verhalten des Systems, welches der Anwender nicht erwartet 

und erst recht nicht goutiert. Bei einer mobilen App, welche 

von Millionen von Kunden zur Unterhaltung benutzt wird, ist der 

Kunde ein bisschen nachsichtiger betreffend einem möglichen 

Fehlverhalten. Ein Absturz einer Poker-App läuft nicht Gefahr, 

dass Sammelklagen über falsche Funktionalität eingehen könnten. 

Es kommt niemand zu finanziellem oder noch schlimmer, zu 

gesundheitlichem Schaden. Sobald aber diese Aspekte ins Spiel 

kommen, dann kann schnell einmal ein Bug einem Produkthersteller 

teuer zu stehen kommen wenn es um die Korrektur des 

Fehlerzustandes, oder um Zahlung von Schadenersatz geht. 

Fakt 2: Bugs haben Charaktere 

Wie und wann Fehler gefunden werden sagt einiges über den 

Charakter des betroffenen Bugs aus. Persönlich unterscheide ich 

zwischen den guten und den bösen Bugs. Das hat nichts damit 

zu tun, was sie dem System oder dessen Benutzer für Schaden 

zufügen, nein es geht eher darum, wer sie findet. Die «Bad 

Bugs» haben sich lange versteckt und werden von den Kunden 

und den Endanwendern eines Systems gefunden. Sie sind die 

miesen, kleinen Fehler, welche uns verärgern. Es sind genau die, 

welche ein schlechtes Bild auf die Qualität des Produktes liefern. 

Solche Bugs wollen wir nicht und können dem Problem auch mit 

Testen Abhilfe schaffen. Und genau das sind dann die «Good 

Bugs». Fehler, die sich vor der Auslieferung eines Produktes von 

einem Tester finden lassen. Und der Tester ist nicht eine Job- 

Description oder eine Rolle. Sobald ein Produkt von jemandem 

geprüft wird, trägt der Prüfer den Testerhut und ist persönlich 

verpflichtet, sich um den Bug zu kümmern. Am einfachsten ist 

das, wenn ein Entwickler ihn sofort beheben kann. Aber das 

bringt mich bereits zum nächsten Fakt. 

Fakt 3: Bugs brauchen Aufmerksamkeit 

Das hört sich jetzt vielleicht ein bisschen komisch an, aber 

Defects sind die grössten Diven in der Entwicklung. Sie wollen 

gefunden werden und dass sich jemand um sie kümmert. Am 

liebsten haben sie es, wie schon erwähnt, wenn sie vom Entwickler 

gefunden und umgehend behoben werden. Falls dies 

aber nicht möglich ist, dann lieben sie es, in einer Liste mit ihren 

Kollegen gepflegt zu werden. Ich habe schon oft erlebt, dass 

vergessene Fehler zu «Bad Bugs» mutiert sind und erst in der Produktion 

wieder gefunden wurden. Kommt noch dazu, dass Fehlerzustände 

richtig gesellige Kerlchen sind. Sie fühlen sich wohl, wenn sie 

unter sich sind. Solange sie man in einer zentralen Liste hält, sind sie 

glücklich und pflegeleichte «Good Bugs». Einzelgänger, die einsam 

in irgendwelchen Mails oder auf losen Zetteln dahinsiechen müssen, 

haben die Neigung zu «Bad Bugs» zu werden. Wenn auch nicht alle 

Fehlerzustände vor der Produktion behoben werden können, die 

gelisteten Bugs haben wir im Griff und Wissen das sie potentiell 

als böse gelten. Solange wir das aber den relevanten Stakeholdern 

kommunizieren können, hält sich das Böse aber in Grenzen. 

Fakt 4: Bugs zeigen Qualitätslücken 

Oh ja, Fehler haben einiges zu erzählen und wenn man ihnen richtig 

zuhört, kann man herausfinden, wo und warum sie überhaupt entstanden 

sind. Einige entstehen in der Anforderungsbeschreibung, 

andere während der Entwicklung und gar nicht so wenige entstehen 

während des Testens. Ich möchte nichts relativieren, aber Fehler, die 

aufgrund von schlechten Testfällen oder Testdaten entstehen, weisen 

auf einen schwachen Testprozess hin. Diese Fehler sind so quasi die 

«Ghost Bugs», also Fehler, die nach Definition gar keine Fehler sind. 

Genau so können sie auch über die Maturität der anderen Prozesse 

Auskunft geben oder auf gewisse Stellen in Systemen hinweisen, die 

noch Qualitätslücken aufweisen. Und falls wir etwas testen möchten, 

dann sollten wir immer wieder auf den Rat der Fehler in den genannten 

Listen hören, denn sie sagen uns, wo wir potentiell noch Kollegen 

von ihnen in unserem Produkt finden können. 

Quintessenz: Good Bugs sind Freunde 

Fehler werden geliebt und gehasst. Fehler brauchen Zuneigung und 

Pflege. Der Aufwand hält sich meist in Grenzen, wenn man ein gutes 

System einsetzt. Etwas weiss ich aus meiner langjährigen Erfahrung: 

Ich kümmere mich lieber um «Good Bugs» als um «Bad Bugs», weil 

sie geplant behoben werden können. Es gibt wahrscheinlich nichts 

lästigeres, als wenn man an der Weiterentwicklung eines Systems 

arbeitet und immer wieder Kraft, Zeit und Mühe mit der Behebung 

von Fehlern aus der Produktion aufwenden muss. Auf diese Fehler 

muss man mit den Fingern zeigen und sie sollen auch für eine negative 

Bewertung der gelieferten Qualität dienen. Aber jeder einzelne 

Fehler, der noch vor Auslieferung gefunden wird, ist unser Freund 

und darum sollten wir sie auch feiern können. 

Marcel Rütschi, 


Testing 50 

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 Vorgehen 

als auch die Herausforderungen der Testautomatisierung aufgezeigt und detailliert 

besprochen. 

Zielgruppe 

Sprache DE 


Dauer 1 Tag 

Code BPTA 

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» (Pitfalls) bei der Testautomatisierung bewusst. 

Inhalt 

Grundlagen Testautomatisierung 

Best-Practice Ansatz in der Testautomatisierung 

Voraussetzungen und Vorgehen/Methode der Testautomatisierung 

Pitfalls der Testautomatisierung 

Agile 

Requirements 

Testing 


Testing 51 

Best Performance Test Implementation 

Einführung 

Die aktuelle Trends- und Benchmarks-Befragung von Mitgliedern der Schweizer Testing-Community 

zeigt, dass bereits bei der Hälfte der Befragten «Last- und Performance-Test» 

im Testingbereich ein Thema ist. Jeder Tester wird wohl früher oder später 

mit Tests auf Effizienz konfrontiert. Was in der Theorie unproblematisch erscheint, 

wird in praktisch jedem Projekt zu einem langwierigen und komplizierten Thema. 

Jeder Stakeholder versteht unter Performanz eines Systems etwas anderes. Darum 

ist eine angemessene Strategie und das passende Vorgehen der Schlüssel zum Erfolg. 

Sprache DE 


Dauer 1 Tag 

Code BPTI 

Zielgruppe 

Testmanager 

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 Effizienz 

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 Practices Performance Testing 

Agile 

Requirements 

Testing 


Blog 

Wenn Tester 

Mobile Apps 

entwickeln 

Entwickler entwickeln, Tester testen und Endbenutzer … 

benutzen Apps. Die Welt kann einfach und klar sein. Manchmal 

ist sie aber auch verdreht. Z.B. wenn Tester selbst das Eclipse 

starten und Apps entwickeln. In diesem Blogbeitrag wird ein 

Erfahrungsbericht dargestellt: Wenn Tester entwickeln. 

Herausforderung Gerätevielfalt 

Mobile Apps, insbesondere, wenn sie für Android und iOS 

entwickelt werden, müssen auf einer Vielzahl an Geräten und 

Betriebsystemversionen laufen. Dies führt zu viel Arbeit im Testen, 

bedarf aber auch sorgfältiger Programmierung. Im Projektalltag 

höre ich als Testmanager häufig von der Entwicklung, dass etwas 

«nicht geht» oder «ein bekannter Bug auf Gerät XXX» sei. In praktisch 

allen Fällen ist dies aber nur eine Ausrede der Entwickler. 

Darunter liegt eine komplett andere Denkweise zwischen Testern 

und Entwicklern. Da wir in der Informatik 

letztlich mit 0en und 1en arbeiten lassen sich 

die wiedersprüchlichen Meinungen jedoch mit 

Fakten beweisen. Immer. Nicht immer ist der 

Aufwand gerechtfertigt, aber möglich ist es 

immer. 

Moderne Apps laufen heute häufig 

auf einer Vielzahl an Geräten 

Entwickler denken positiv 

Als Entwickler denkt man positiv. Jetzt möchte ich nicht behaupten, 

dass Entwickler «bessere Menschen» wären, oder freundlicher, 

optimistischer, aber, ein ganz wenig ist schon dran. Tester 

mit langer Berufserfahrung neigen ein wenig dazu, ständig das 

berühmte Haar in jeder Suppe zu suchen. Hat der Entwickler also 

die positive Grundeinstellung, dass eine Funktion funktionieren 

wird und er sie «richtig» umgesetzt hat, so denkt der Tester 

immer zuerst: «das funktioniert doch eh noch nicht richtig!». 

Und entsprechend prüft man eine Funktion anders. 

Wenn der Entwickler dann noch sieht, dass eine Funktion auf 

seinem Gerät korrekt funktioniert, dann ist für ihn bewiesen, dass 

er es richtig gemacht hat. Funktioniert es auf Gerät X dann nicht, 

so ist es die Schuld von dem Gerät. Ein Tester hingegen denkt «nur 

weil es auf Gerät A funktioniert, beweist das nicht, dass es auch 

auf Gerät B funktioniert». 

Tester denken konstruktiv destruktiv 

Als Tester sind wir sehr vertraut mit dem Phänomen, dass eine 

Funktion auf verschiedenen Systemen/Geräten unterschiedlich 

gut funktionieren kann. Und dass da in der Regel ein Fehler 

in der Programmierung, der Konfiguration oder den Daten 

zugrunde liegt. Entsprechend sind wir sehr gut darin, den Unterschied 

aufzuspüren, und aufzuzeigen, dass der Fehler reproduzierbar 

ist und eine behebbare Ursache hat. Im mobilen 

Umfeld führen wir routiniert Tests auf verschiedenen Geräten 

oder OS-Versionen durch und können schnell aufzeigen, bzw. 

haben idealerweise auch einen entsprechenden Erfahrungsschatz, 

dass der angebliche Bug im Gerät XXX in Wirklichkeit 

ein Nullpointer ist, der auf verschiedenen Geräten auftaucht. 

Langjährige Erfahrung ist hier natürlich von Vorteil. Wenn man die 

besonderen Eigenheiten bestimmter OS-Versionen kennt, dann 

kann man hier sehr gezielt und kostengünstig vorgehen. 

Wenn Tester Apps entwickeln 

Wenn nun ein technisch versierter Tester eine Android App entwickelt, 

dann denkt er von Beginn an anders. 

Mobile App Tester mit mehreren 

Geräten parallel am Arbeiten 

Er wird seine App routiniert auf 

verschiedenen Geräten testen 

und wenn es zu einem Problem 

kommt, wird er sich nicht dagegen 

wehren, dass es ein Fehler auf 

seiner Seite ist. Auch ist es für ihn 

selbstverständlich, dass es viele Fehler bestimmter Gattungen gibt. 

Nullpointer z.B. sind unser täglich Brot. Als Entwickler kann man hier 

sehr defensiv programmieren und aktiv auf Nullpointer prüfen und 

diese behandeln – oder halt nicht. Das benötigt ein wenig mehr Aufwand, 

ist aber deutlich billiger, als das Debuggen auf der Suche nach 

von Testern gemeldeten Fehlern. Umgekehrt kann ein zu sorgfältiges, 

vorsichtiges Vorgehen natürlich auch dazu führen, dass der Fortschritt 

leidet. Hier braucht es ein gewisses Mass an Fingerspitzengefühl. 

Einbindung der Endanwender 

muss früh und häuf ig erfolgen 

Als Tester sind wir häufig die Ersten (und manchmal Einzigen), die 

entstehende Softwaresysteme intensiv nutzen. Wir nehmen regelmässig 

die Rolle des künftigen Users ein. Entsprechend fordern wir 

aktiv, dass echte Endanwender regelmässig und möglichst früh in Reviewssitzungen 

eingebunden werden. Entwickler hingegen sind häufig 

sehr protective. Sie weigern sich, ihre noch nicht fertige Software 

jemandem zu zeigen – um dann 

zu erleben, dass sie am Ende das 

falsche korrekt entwickelt haben. 

Moderierte Workshops helfen 

wirklichen Mehrwert zu schaffen 

Sind Tester die besseren 

Entwickler? 

Offensichtlich nicht. Wenn ein Tester zum Entwickler wird, dann wird 

er früher oder später die gleichen Denkweisen annehmen, die ein 

Entwickler hat. Arbeitet er nur teilzeit als Entwickler, so wird er 

nicht die gleichen Fähigkeiten und Erfahrungen mitbringen, wie ein 

erfahrener Entwickler. Spezialisierung hat in Jobs mit einem hohen 

Skillset auf jeden Fall seine Berechtigung! 

Andererseits ist es auch wichtig, nicht zu engstirnig in Muster zu 

verfallen und eine gewisse Flexibilität aufrecht zu erhalten. Gemischte 

Teams vereinen idealerweise das Beste aus beiden Welten. 

Wenn Entwickler und Embedded Tester 

es schaffen, konstruktiv zusammen zu 

arbeiten, dann entstehen häufig sehr 

robuste Systeme, die dem Endanwender 

einen hohen Mehrwert bieten … 

Stephan Wiesner, 

Testing Consultant 

Teamwork statt 

Einzelkämpfer 

führen zum Ziel

Testing 53 

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? 

Sprache DE 

Typ 

firmenintern 

In diesem Seminar erhalten die Teilnehmer das Grundlagenwissen, wie die Auslagerung 

von Testaktivitäten konzipiert, geplant, vertraglich abgesichert und implementiert 

werden muss. 

Dauer 

Code 

3 Tage 

MOST 

Zielgruppe 

IT-Leiter 

Testmanager 

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 Methoden, 

die ihnen dabei helfen, eine erfolgreiche Outsourcing-Beziehung aufzubauen 

und zu pflegen. 


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

Agile 

Requirements 

Testing 


Zertifizierungen 54 


NEU 

SAFe Program Consultant 55 

iSQI ® Certified Agile Business Analysis 56 

NEU 

IQBBA ® Certified Foundation Level – Business Analyst 58 

ISTQB ® Agile Tester 59 

Certified Scrum Master 60 

Certified Scrum Product Owner 61 

IREB ® CPRE | Foundation Level 62 

IREB ® CPRE | Advanced Level – Elicitation & Consolidation 64 

IREB ® CPRE | Advanced Level – Requirements Modeling 65 

ISTQB ® Certified Tester | Foundation Level 66 

ISTQB ® Certified Tester | Advanced Level – Testmanager 67 

ISTQB ® Certified Tester | Advanced Level – Test Analyst 68 

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

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

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

NEU 

CMAP Mobile App Testing – Foundation Level 74

Zertifizierungen | Agile 55 

SAFe Program Consultant 

Introduction 

The SAFe Program Consultant Training and Certification course is for internal agile 

change agents and external consultants. It provides the tools to implement agile 

programs and validates their knowledge in agile programs, program portfolio management, 

agile architecture, and leadership so that they can launch Agile Release 

Trains as part of an enterprise Lean|Agile change initiative. Those who receive their 

SPC certification are qualified to launch Agile Release Trains and train aspiring SAFe 

Agilists (SAs) and SAFe Practitioners (SPs). Learn more about becoming a trainer. 

Sprache EN 

Typ öffentlich 

Dauer 4 Tage 

Code SPC 

Target Group 

Change agents implementing SAFe 

People leading SAFe initiatives and/or running Agile Release Trains 

Objectives 

Lead an enterprise agile transformation 

Implement the Scaled Agile Framework ® (SAFe) 

Run an Agile Release Train 

Be a SAFe trainer 

Content 

Apply lean, agile and product development flow principles to improve 

productivity, employee engagement, time to market, and quality 

Apply the Scaled Agile Framework based on lecture, real-world examples, 

and insights by Scaled Agile experts 

Understand the skills necessary for an enterprise transformation based on the 

information and examples presented, and additional recommended readings 

and resources 

Find the value streams around which to organize the enterprise’s Agile Release 

Trains and prepare the organization and the teams to launch the trains 

Requirements 

5+ years of experience in software development, testing, 

business analysis, product or project management 

3+ years of experience in Agile 

One or more relevant Agile certifications (e.g., CSM, CSPO, CSP, CSC, CST, 

Scrum.org, DSDM, ICAgile, PMI-ACP) 

Agile 

Requirements 

Testing 




iSQI ® Certified Agile Business Analysis 

Einführung 

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

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

diesem Umfeld gültig ist. 

Sprache DE/EN/Unterlagen EN 

Typ 

öffentlich/firmenintern 

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 existiert 

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. 

Dauer 

Code 

2 Tage 

CABA 

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 

Agile Ansätze 

Business Analyse Methoden in agilen Projekten 

Agile Business Analysis Discovery Framework 

Review 


Vorteilhafterweise Erfahrung als Business Analyst, Requirements Engineer, Tester oder Developer 

in traditionellen Projekten 

Agile 

Requirements 

Testing 



Blog 

DIE ROLLEN DES PO, RE UND BA IM VERGLEICH 

Während einer Bahnfahrt ist eine Diskussion zwischen einem 

der jüngsten und einem der ältesten Business Analysten der 

SwissQ über das Thema BA /RE Skills in Agil entstanden. Dies 

war die Grundlage zu diesem Blog. Lesen Sie selbst … 

Die Business Analyse (BA)/Requirements Engineering (RE) Szene befindet 

sich in einem Umbruch. Die Community, die jahrelang um die 

Anerkennung der Rolle BA /RE in der Schweizer IT-Welt gekämpft hat, 

wird vom immer stärkeren Trend hin zu agiler Softwareentwicklung 

(siehe auch SwissQ Trends & Benchmarks Report) stark beeinflusst. 

Dabei wird das Thema BA /RE in Scrum oder Kanban nicht explizit erwähnt. 

Bedeutet dies, dass die Aufgaben der klassischen BA /RE nicht 

mehr vorhanden sind und heisst es auch, dass die Ausbildung und 

Erfahrung der klassischen BA /RE nichts mehr wert ist? Wie würden Sie 

in der Rolle eines Budgetverantwortlichen gerade jetzt entscheiden, 

wenn ein Teammitglied bei Ihnen den Antrag für einen Zertifikatskurs 

zum Thema Requirements Management stellen würde? 

kriterien auf ihre Testbarkeit, Prüfen der Akzeptanzkriterien inkl. 

Testdaten, Sicherstellen der Traceability zwischen User Story und Test. 

Um diese Tätigkeiten qualitativ auszuführen bedarf es u.a. guter 

Kommunikation, analytischer Kenntnisse und methodisches Vorgehen. 

Analoge Fähigkeiten und Aufgaben 

wie im klassischen BA /RE 

Wenn man die oben beschriebenen Tätigkeiten der agilen Rollen 

genauer betrachtet, fällt einem die Verbindung zum klassischen BA/RE 

auf. Tätigkeiten, welche früher durch den BA /RE durchgeführt wurden, 

sind nun auf verschiedene Rollen verteilt. Die dafür geforderten 

Fähigkeiten sind ebenfalls bei klassischen BAs/REs zu finden. 

Fazit 

In diesem Blog fragen wir uns, welche klassischen BA /RE Disziplinen in 

Agil von Nutzen sind und in welchen Rollen sie zum Tragen kommen. 

Agile Rollen und ihre Tätigkeiten 

Auch im agilen Umfeld muss Requirements Engineering betrieben 

werden. Dies wird jedoch nicht dediziert getan, sondern durch 

verschiedene Rollen ausgeführt. Schauen wir uns typische Rollen 

aus den agilen Projekten und deren Tätigkeiten zum Thema 

Requirements Engineering doch mal genauer an: 

Nach Scrum hat der Product Owner (PO) die Aufgabe die richtige 

Funktionalität in der richtigen Priorität ins Projekt zu bringen. Dazu 

ist es wichtig seine Kunden und Benutzer zu kennen und auch von 

deren Bedürfnissen und Abläufen eine Ahnung zu haben. Weiterhin 

muss der PO gute kommunikative Fähigkeiten und Moderations-Skills 

haben, um Anforderungen zu erheben und entsprechend der Kundenwünsche 

zu priorisieren. Daraus abgeleitet erscheinen die folgenden 

wichtigsten Skills für POs sehr wünschenswert: Stakeholderanalyse, 

Erhebungstechniken, Konfliktmanagement und Prioriserung (z.B. 

Priority Poker). 

Die Rolle Business Analyst (BA) wird in Scrum nicht explizit 

erwähnt, ist jedoch in vielen agilen Projekten vorhanden. Diese 

Rolle unterstützt den Product Owner bei der Erhebung fachlicher 

Anforderungen und der Prüfung, ob und wie die Anforderungen zu 

den Geschäftsprozessen passen. Weiterhin unterstützt der Business 

Analyst den PO beim Erarbeiten fachlicher Akzeptanzkriterien für 

die Anforderungen. Hier wird fachliche Erfahrung und Branchen- 

Know-how benötigt, zudem sollte der BA über die folgenden 

wichtigsten Skills verfügen: Stakeholderanalyse, Kreativitätstechniken 

und Erhebungstechniken. 

Auch der Requirements Engineer (RE) ist nicht in Scrum 

definiert. Trotzdem findet sich diese Rolle ebenfalls in vielen agilen 

Projekten. Der Requirements Engineer hat die Aufgabe die Anforderungen 

nachhaltig zu spezifizieren und dabei auf die Übersetzung 

der Anforderungen in die technische Umgebung zu achten. Die 

folgenden wichtigsten Skills für den RE werden ebenfalls im agilen 

Umfeld sehr geschätzt: Stakeholderanalyse, Kreativitätstechniken, 

Erhebungstechniken, Dokumentationstechniken und Modellierung 

von Anforderungen (typischerweise mittels UML). 

Last but not least gibt es weiterhin den Tester. In agilen Projekten 

oftmals Embedded Tester genannt. Auch diese Rolle sucht man in 

Scrum vergeblich. Diese Rolle hat folgende wichtigste Tätigkeiten: 

Analysieren der User Stories auf ihre (Qualitäts-)Risiken, 

(Mit -)Definieren der Akzeptanzkriterien, Prüfen der Akzeptanz- 

Die Techniken die im klassischen RE wichtig waren und sind, helfen 

auch in agilen Projekten. 

Dokumentation – sicherlich wird agil anders dokumentiert wie in 

klassischen Projekten: 

-- So wird die Dokumentation nicht mehr Monate im Voraus erstellt, 

sondern bei Bedarf. Und Normierungen wie z.B. die Satzschablone 

sind nicht mehr gefordert. Erlaubt ist, was hilft. 

-- Aber gerade wenn ein Produkt weiterentwickelt wird zeigt die 

Erfahrung, dass es eine Dokumentation braucht, welche eine 

Verbindung von einer Anforderung zum Business Value 

dokumentiert. So ist man bei Änderungen und Erweiterungen 

ungleich sicherer und somit auch schneller anstatt erst bei der 

Implementierung zu bemerken, dass es einen Grund hatte wieso 

das Produkt so funktioniert und nicht anders. 

Die Anforderungen müssen erkannt, erhoben, konsolidiert und 

gemanagt werden. Dabei spielt es eine untergeordnete Rolle wie 

sie umgesetzt werden. 

Menschen bleiben auch bei agilen Vorgehen Menschen. Es ist 

also für die Beteiligten BA /RE nach wie vor essentiell, dass sie 

kommunikativ sind und mit Konflikten umgehen können. 

Daher sind die die Techniken die in den IREB ® -Kursen (Foundation 

Level, Requirements Modeling und Elicitation & Consolidation) 

gelernt werden sicher eine solide Basis, auch für agile Projekte und 

auch eine gute Ausgangslage für den CABA Kurs, da in diesem vor 

allem auf die agilen Ansätze eingegangen wird. Für die Tester gibt 

es etwas Analoges von ISTQB ® den Agile Tester. 

Würden Sie nun den oben beschriebenen Antrag bewilligen? 

Und ganz nebenbei gesagt, wir von SwissQ suchen zur Erweiterung 

unseres stetig wachsenden BA /RE Teams, Mitarbeiter die bereits mit 

BA /RE Themen Erfahrung haben. Dabei spielt es eine untergeordnete 

Rolle, ob diese in klassischen oder agilen Projekten erworben wurde. 

Mehr… 

Beat Bourquin, 

Anton Podokschik, 

Consultants in 

Business Analyse/ 

Requirements 

Engineering


IQBBA ® Certified Foundation Level – Business Analyst 

Einführung 

Am Anfang eines jeden IT Projekts stehen immer die geschäftliche Anforderung und 

der Bedarf nach einem Produkt. Verbesserung oder Automatisierung von Geschäftsprozessen, 

Ausweitung der Software-System Funktionalität, Eröffnung neuer Einstiegskanäle 

für Kunden – das sind Beispiele für unterschiedliche geschäftliche Anforderungen. 

Jede geschäftliche Anforderung muss dabei genau erforscht, analysiert 

und an eine bestimmte Situation angepasst werden. Genau das ist das Feld des Business 

Analysten. Der Erfolg eines Projekts hängt dabei von den Fähigkeit und der 

Erfahrung des Business Analysten ab. Er muss konkrete Anforderungen sammeln und 

sie in eine Lösung umsetzen. Dazu sind spezifische Kompetenzen und standardisiertes 

Wissen notwendig. 

Sprache DE 


Dauer 3 Tage 

Code IQBBA FL 

Zielgruppe 

Das Foundation Level Zertifikat richtet sich an Business und System Analysten, 

Produktverantwortliche und Produktmanager. Ein Grundlagenwissen im Bereich 

Lösungskonzepte, Design oder Entwicklung wird empfohlen. Mit dem Bestehen 

des Foundation Levels qualifiziert sich der Teilnehmer für das Advanced Level. 

Ziele 

Das Zertifikat zum IQBBA ® Certified Foundation Level – Business Analyst ist die Schlüsselqualifikation 

im Feld der Geschäftsanalyse. Das abverlangte Wissen stellt dabei die 

Kenntnisse von Definitionen und Hintergründen für die Geschäftsprozessmodellierung, 

Anforderungssammlung und Anforderungsanalyse sicher. Ausserdem bescheinigt 

das Foundation Level dem Teilnehmer grundlegendes Wissen für die Bereiche 

Design von Geschäftslösungen und der Arbeit im Bereich von Innovation. 

Hauptfokus der Foundation Level Zertifizierung ist die Schaffung eines einheitlichen 

Standards im Bereich der Geschäftsanalyse. Zusätzliche Punkte sind ausserdem Innovation 

und Design als Mittel für fortschrittliche Lösungen. Am letzten Tag findet die 

abschliessende Zertifizierungsprüfung statt. 

Inhalt 

Grundlagen 

Geschäftsanalyse und Prozessplanung 

Anforderungsanalyse 

Werkzeuge und Techniken 

Prozessverbesserung 

Geschäftsanalyse 

Anforderungserhebung 

Lösungsvalidierung 

Kompetenzen 

Innovation, Design und Kunde 

Agile 

Requirements 

Testing 




ISTQB ® Agile Tester 

Einführung 

In diesem Kurs werden Testern und Testmanagern die Grundsätze des Testens in Agilen 

Projekten vermittelt. Die Teilnehmer erfahren, wie agile Softwareentwicklungsprogramme 

organisiert sind und lernen die üblichen agilen Umsetzungen kennen. 

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

welche Position der Tester in der agilen Organisation einnimmt sowie die 

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

Zielgruppe 



Dauer 2 Tage 

Code CTAT 

Testmanager, 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 


ISTQB ® Certified Tester Foundation Level Zertifikat 

18 Monate Erfahrung im Testing oder höhere IT Ausbildung 

Agile 

Requirements 

Testing 



Certified Scrum Master 

Einführung 

Sie haben 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. 

Sprache DE 


Dauer 3 Tage 

Code CSM 

Zielgruppe 

Führungskräfte 

Projektleiter 

Entwickler 

Tester 

Produktmanager 


Berater 

Ziele 

Verstehen, wie Scrum funktioniert. Fühlen, warum Scrum funktioniert. Begreifen, wie 

Sie Scrum einsetzen 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 Scrum Master (Online Prüfung erforderlich). 

Inhalt 

Warum agile Prozesse? 

Agile Werte und Prinzipen 

Rollen in Scrum: Scrum Master, 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 Scrum Masters 

Agile 

Requirements 

Testing 



Certified Scrum Product Owner 

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? 

Sprache DE 


Dauer 3 Tage 

Zielgruppe 

Code 

CSPO 

Dieser Kurs ist ideal für Product Owner, Scrum Master, Kunden bzw. Auftraggeber, Projektleiter, IT-Manager 

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 


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 

Agile 

Requirements 

Testing 


Zertifizierungen | Requirements 62 

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 Weichen 

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

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 kostenverursachender 

Änderungen deutlich reduziert. 



Dauer 3 Tage 

Code CPRE 

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 Prozesse 

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 


Erfahrung in den Bereichen Informatik, Organisation oder Betriebswirtschaft 

Agile 

Requirements 

Testing 



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 welche 

Technik passt zu welcher Situation? Wie gehe ich vor, wenn mehrere Stakeholderwü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 



Dauer 3 Tage 

Code ALEC 

Projektleiter 

Systemdesigner 

Entwickler 



Ziele 

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

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

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

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


IREB ® CPRE | Foundation Level Zertifikat 

36 Monate Erfahrung in den Bereichen Informatik, Organisation oder 

Betriebswirtschaft 

Agile 

Requirements 

Testing 



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

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. 



Dauer 3 Tage 

Code ALMO 

Zielgruppe 

Projektleiter 

Systemdesigner 

Entwickler 



Ziele 

Durch praktische Übungen und Beispiele erhalten die Teilnehmer einen Wissens- und 

Kenntnisstand gemäss dem Lehrplan zum «IREB ® CPRE | Advanced Level – Requirements 

Modeling». Nach dem Training sind sie vertraut mit den Modellierungstechniken 

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 innert 12 Monaten. Das Zertifikat 

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 


IREB ® CPRE | Foundation Level Zertifikat 

36 Monate Erfahrung in den Bereichen Informatik, Organisation oder Betriebswirtschaft 

Agile 

Requirements 

Testing 


Zertifizierungen | Testing 66 

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 anerkannte 

Certified-Tester Qualifikationsschema. 

Zielgruppe 

Sprache DE/EN/FR 


Dauer 4 Tage 

Code CTFL 

Tester 

Testmanager 

Entwickler 

Qualitätsverantwortliche 

Ziele 

Dieses Grundlagentraining behandelt Aufgaben, Methoden und Techniken des Softwaretestens. 

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 


Vorteilhafterweise Vorkenntnisse in Software Testing 

Agile 

Requirements 

Testing 




ISTQB ® Certif ied Tester | Advanced Level – Testmanager 

Einführung 

Im Fokus des Modul Testmanager stehen die speziellen Aufgaben und Aktivitäten, die 

ein Testmanager im Rahmen seiner täglichen Aufgaben planen und durchführen muss. 

Das Modul bietet eine spezielle Weiterführung in den Themen des Testmanagements. 


Typ 

öffentlich/firmenintern 

Zielgruppe 

Dauer 

5 Tage 

Tester 

Testmanager 


Projektmanager 

Code 

ALTM 

Ziele 

Ziel ist es, den Teilnehmern eine qualifizierte Ausbildung im Bereich des Testmanagements 

zu vermitteln, die sich für die tägliche Arbeit nutzen und integrieren lässt. Die 

praktische Umsetzung mit Hilfe von Übungen steht im Vordergrund. 


«ISTQB ® Certified Tester | Advanced Level – Testmanager» ab. 

Inhalt 

Grundlegende Aspekte des Softwaretestens 

Testprozesse 


Review 

Fehler und Abweichungsmanagement 

Standards im Testverbesserungs-Prozess 

Soziale Aspekte und Teamzusammensetzung 


ISTQB ® Certified Tester | Foundation Level Zertifikat 


Agile 

Requirements 

Testing 




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 Testfallerstellung 

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 qualifizierte 

Ausbildung zu vermitteln, deren Inhalte die tägliche Testarbeit unterstützen. 

Zielgruppe 



Dauer 4 Tage 

Code ALTA 

Tester 

Testmanager 



Testdesigner 

Ziele 

Aufbauend auf die Foundation Level Ausbildung vermittelt der Kurs vertiefte Kenntnisse 

zu Methoden und Techniken zur Ableitung und Spezifikation von Softwaretests 

auf Black-Box Ebene und zum Review. 


«ISTQB ® Certified Tester | Advanced Level – Test Analyst» ab. 

Inhalt 

Testprozess 


Testverfahren 

Softwarequalitätsmerkmale 

Reviews 

Fehlermanagement 

Testwerkzeuge 




Agile 

Requirements 

Testing 




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

Der Fokus dieses Moduls liegt somit auf der technischen Arbeit eines 

Testers und den von ihm zu testenden Testobjekten. 



Dauer 3 Tage 

Zielgruppe 

Code 

ALTTA 

Tester 

Testmanager 



Testdesigner 

Ziele 

Aufbauend auf die Foundation Level Ausbildung vermittelt der Kurs vertiefte Kenntnisse 

zu Methoden und Techniken zur Ableitung und Spezifikation von Softwaretests 

auf White-Box Ebene. 


«ISTQB ® Certified Tester Advanced Level – Technical Test Analyst» ab. 

Inhalt 

Risikobasiertes Testen 

Strukturbasiertes Testen 

Analytische Techniken 

Qualitätsmerkmale Technical Testing 

Reviews 

Test Tools und Automation 




Agile 

Requirements 

Testing 



Artikel 

16 STRATEGIE & PRAXIS Entwicklung 

FOKUS: SOFTWARE-TESTING 

Testen ohne Ballast 

Leichtgewichtige und preiswerte Testmanagement-Tools sind bei 

kleineren und agilen Projekten oft die bessere Wahl. Unter anderem, 

weil sie qualifizierte Software-Tester nicht einengen. 

VON ALAIN WEIBEL 

Manuelles Testen ist noch immer die 

am weitesten verbreitete Art, Fehler 

aufzudecken und die korrekte Funktionalität 

einer Applikation zu bestätigen. 

Diese Methode scheint wenig kompliziert 

und durch jeden ausführbar, da sie 

praktisch kein technisches Wissen oder Programmierkenntnisse 

voraussetzt. Wichtige 

Unterstützung bietet dabei ein geeignetes Tool 

zur Verwaltung, Planung, Ausführung und Auswertung 

benötigter Testfälle. Auf dem Markt 

gibt es dazu sehr leistungsfähige Werkzeuge. 

Der Einsatz eines solchen führt jedoch nicht 

automatisch zu hoher Software-Qualität. 

Alain Weibel ist Senior Consultant für Testmanagement 

bei SwissQ www.swissq.it 

WAS EIN TOOL KÖNNEN MUSS 

«Ein Test-Tool zu kaufen, ist wie jemandem einen 

Pulli zu kaufen. Das Problem dabei ist: Man 

fühlt sich gezwungen, den Pulli zu tragen, auch 

wenn er nicht passt.» Das Zitat des bekannten 

Software-Testers James Bach beschreibt treffend 

die Lage in vielen Organisationen. Es 

wurde ein Testmanagement-Tool angeschafft, 

diverse Projekte damit abgewickelt und folglich 

wird damit auch eine grosse Zahl an Regressionstests 

verwaltet. Das Tool hat möglicherweise 

bereits einige Jahre auf dem Buckel und 

entspricht in seiner Aufmachung und Struktur 

nicht mehr dem neusten Stand. 

Dasselbe gilt wohl für die unzähligen Regressionstests, 

die oft nicht mehr an die aktuellen 

Gegebenheiten angepasst wurden oder 

so umfangreich und kompliziert sind, dass sie 

gar nicht mehr ausgeführt werden. Sicherlich 

gibt es für die meisten Tools ein Update, das 

die User Experience verbessert und die Funktionalität 

erweitert. Oftmals vernachlässigen die 

Entscheidungs träger diese Aktualisierungen 

aber aus verschiedenen Gründen (z.B. zeitlicher 

Aufwand, Kosten, Unwissenheit etc.). 

«Die Anwendung läuft und seine Funktionen 

reichen doch völlig aus», hört man sie argumentieren. 

Oft passt das Tool jedoch genauso wenig wie 

ein geschenktes Kleidungsstück. Gerade bei 

weniger grossen und komplexen Vorhaben mit 

einer überschaubaren Menge an Testfällen sind 

die verbreiteten, umfangreichen Tools manchmal 

zu viel des Guten. Vielfältige Konfigura- 

BILD: ISTOCKPHOTO.COM/NISERIN

Computerworld 11/3. Juli 2015 

www.computerworld.ch 

COMPUTERWORLD 11 /3. Juli 2015 www.computerworld.ch 

17 

tionsmöglichkeiten verkomplizieren die Abläufe. 

Der Aufwand für die Erfassung und Pflege 

der Daten sowie die Einhaltung der Workflows 

verlangsamen den Testfortschritt und verunmöglichen 

schlanke Prozesse. 

Egal, welche Anforderungen Ihr Projekt zu 

erfüllen hat, ein effektives Testmanagement- 

Tool sollte mindestens die folgenden Eigenschaften 

aufweisen: 

Leicht zu verwaltendes Testfall-Repository 

Möglichkeit für integriertes Fehlermanagement 

Sicherstellung der Traceability durch Verknüpfen 

mit Anforderungen und Fehlern 

Mehrmalige Durchführung von Tests durch 

Abbildung in verschiedenen Testläufen 

Ortsunabhängiger Zugriff auf das System 

Übersicht und Reporting-Möglichkeiten notwendiger 

Testmetriken 

Benutzerfreundliche und intuitive Oberfläche 

Funktionen eines Testmanagement-Tools 

TESTMANAGEMENT LIGHT 

Neben den gestandenen Testmanagement- 

Werkzeugen haben es in den letzten Jahren 

einige neue Tools mit beachtlichem Erfolg auf 

den Markt geschafft. Viele davon sind eher 

schlanke Anwendungen, die sich mit geringem 

Aufwand auf die eigenen Bedürfnisse einstellen 

lassen. Teilweise können sie als Service 

bezogen werden und sind somit schnell einsatzbereit. 

Besonders beliebt sind Tools, die sich durch 

eine ansprechende und leicht verständliche 

Oberfläche auszeichnen. Wenn zudem der Ablauf 

eines Tests und dessen Abhängigkeiten 

leicht nachvollziehbar sind, steigert das besonders 

bei Testpersonen aus dem Business-Umfeld 

die Akzeptanz. Aber auch bei Entwicklern 

«Die Testpersonen 

erledigen die wichtigen 

Aufgaben, nicht das Tool» 

Alain Weibel 

und hauptberuflichen Testern kommen solche 

Tools gut an, da sie im Kontrast zur stetig wachsenden 

Komplexität der zu produzierenden 

Software stehen und die Arbeit erleichtern. 

Zudem bieten mittlerweile viele Tools 

Schnittstellen zu bewährten ergänzenden Anwendungen, 

die beispielsweise die Testautomatisierung 

oder kontinuierliche Integration in die 

Prozesskette einbinden. Es ist somit möglich, 

anstelle einer komplexen und allumfassenden 

Lösung den Best-of-Breed-Ansatz zu verfolgen 

und damit die für das Projekt geeigneten Tools 

ineinander zu verschmelzen, sodass alle am 

Entwicklungs-, Test- und Delivery-Prozess teilnehmenden 

Personen adäquat unterstützt werden. 

Dabei gilt es allerdings zu beachten, dass 

Die Testpersonen stehen im Zentrum. Das Testmanagement-Tool unterstützt sie bei 

Planung, Ausführung, Fehlermanagement, Nachvollziehbarkeit und Auswertung 

eine solche Tool-Integration oft Kompromisse 

bei der Nutzung einzelner Werkzeuge nach sich 

zieht, damit eine saubere Synchronisation der 

Daten sichergestellt werden kann. 

Der jüngste Erfolg von leichtgewichtigen 

Tools bedeutet allerdings nicht, dass umfangreiche 

Testmanagement-Werkzeuge generell 

veraltet oder gar überflüssig sind. Ganz im Gegenteil: 

Sie sind in grösseren 

und langfristigen Projekten 

oder Portfolios nicht wegzudenken, 

denn sie erfüllen 

Aufgaben, die kleinere Tools 

nicht abdecken. Insbesondere 

begleiten sie mehr Aufgaben 

im Software-Lebenszyklus 

und bieten wesentlich tiefergehende 

Funktionalität im Bereich der Planung, Verwaltung, 

Auswertung und Kontrolle der (Test-) 

Projekte. 

MENSCH VOR PROZESSEN UND TOOLS 

So wichtig die Wahl des passenden Tools auch 

ist: Auf keinen Fall darf vergessen gehen, dass 

die wesentlichen Testaufgaben nicht durch das 

Tool ausgeführt werden, sondern durch die 

Tester. Diese sollten nicht nur über das notwendige 

Fach- und Methodenwissen verfügen, 

sondern auch eine hohe Sozialkompetenz 

sowie Hingabe und Engagement beim Fehlerfinden 

im Dienste der Software-Qualität mitbringen. 

Durch das Vertrauen in die Fähigkeiten 

der Spezialisten resultieren oft bessere Ergebnisse 

als durch detailreiche Workflows und 

umfangreiche Tools. 

Gerade deshalb bietet es sich an, leichtgewichtige 

Tools einzusetzen. Die vorher beschriebenen 

Eigenschaften der Tester kommen 

vollständig zur Geltung, da sie nicht der Resignation 

aufgrund hoher Komplexität zum Opfer 

fallen. Nicht zu vernachlässigen ist aber auch 

die schnellere Time To Market. Immer mehr 

Projekte werden in agiler Weise abgewickelt, 

um gewisse Elemente bereits früher in Betrieb 

zu nehmen. Den so entstehenden kurzen Entwicklungszyklen 

muss auch das Testing Rechnung 

tragen. Neben angepassten Testverfahren 

wie exploratives Testen oder Embedded Testing 

bieten schlanke Test-Tools das nötige Rüstzeug. 

FAZIT: PASSENDES TOOL, FÄHIGE LEUTE 

Um Software-Entwicklungsprojekte erfolgreich 

zu bewältigen, sind verschiedene Massnahmen 

nötig. Ein schlankes und auf genau die gewünschten 

Bedürfnisse abgestimmtes Testmanagement-Tool 

kann seinen Beitrag in praktisch 

allen Messgrössen leisten: Zeit, Umfang, 

Budget und Qualität. Auf jeden Fall ist es empfehlenswert, 

nicht einfach nur das vorhandene, 

sondern für jedes Projekt das richtige Tool zu 

verwenden. Sehr wichtig ist aber auch, die richtigen 

Testpersonen mit den notwendigen Skills 

im Projekt zu haben, denn sie beeinflussen damit 

die Qualität des Produkts entscheidend. 

GRAFIK: SWISSQ




Introduction 

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 «improvements» 

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. 

Sprache DE /Unterlagen EN 


Dauer 9 Abendsessions + Prüfung 

Code EXITP1 

Target Group 

Testmanager 



Objectives 

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 

Content 

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) 

Requirements 

Agile 

Requirements 


Testmanager Zertifikat 

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. 

Testing 





Introduction 

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 process 

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 benefits 

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

Sprache DE /Unterlagen EN 


Dauer 7 Abendsessions + Prüfung 

Code EXITP2 

Target Group 

Testmanager Qualitätsbeauftragte Projektmanager 

Objectives 

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 

Content 

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 

Agile 

Requirements 

Requirements 


Testmanager Zertifikat 

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. 

Testing 



CMAP Mobile App Testing - Foundation Level 

Einführung 

Apps und Mobile Geräte sind nicht mehr wegzudenken aus unserer Gesellschaft und 

somit auch aus dem IT Alltag. Mobile Technologien ändern sich schnell und haben 

einen grossen Einfluss auf unsere Entwicklung, wie und was wir testen. IT Experten 

sollten stets up to date mit den neusten Entwicklungen in der mobilen Welt sein und 

die Auswirkungen auf das Testen, die Performance und Sicherheit kennen. Der Kurs 

gibt eine Einführung in die Welt des Mobile App Testings. Zahlreiche Übungen werden 

durchgespielt, ein generelles Verständnis für den Einfluss und die Bandbreite der mobilen 

Entwicklung auf dem Markt werden vermittelt. 



Dauer 2 Tage 

Code CMAP 

Zielgruppe 

(Mobile) Tester 

Testmanager 



Ziele 

Der Kurs gibt einen Einblick in die wichtigsten Techniken und Begriffe. Das Seminar 

schliesst mit einer 60-minütigen Prüfung zum Erlangen des Zertifikates «CMAP Mobile 

App Testing - Foundation Level» ab. 

Inhalt 

Testen mobiler Apps 

Testautomatisierung im mobilen Umfeld 

Performance Testing im mobilen Umfeld 

Security im mobilen Umfeld 

Einblick in die App-Entwicklung 


ISTQB ® Foundation Level oder adäquate Vorkenntnisse 

Basiswissen Testing 

Agile 

Requirements 

Testing 



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

Fragen? 

Bitte kontaktieren Sie uns! 

© by SwissQ Consulting AG 

Stadthaus-Quai 15 

CH-8001 Zürich 

www.SwissQ.it 

info@SwissQ.it 

Tel +41 43 288 88 40 

Fax +41 43 288 88 39 

Twitter: @SwissQ 

Facebook: swissqconsulting

Zertifizierungen

Sie wollen auch ein ePaper? Erhöhen Sie die Reichweite Ihrer Titel.

Template löschen?

Als Template speichern?