usability - [email protected] am 15. november fand im unicum er-langen die...

Ausgabe 41 | Dezember 2016

Fol

gen

Sie

un

s au

f T

wit

ter

un

d F

aceb

ook

.tw

itte

r.co

m/S

QM

agaz

in

face

boo

k.c

om/S

Qfo

ryou

ISS

N 2

367-

3516 USABILITY &

USER EXPERIENCEEIN NEUES VERSTÄNDNIS VON QUALITÄT

IM INTERVIEW:

GMX-Gründer starten mit neuer App

BEST PRACTICE:

Wenn die Digitalisierung die Usability herausfordert

PLUS: Die neuesten Schulungs-termine für 2017

Große Ereignisse werfen ihre Schatten voraus. Gemeint sind mit dem poetischen Ausspruch die ersten spürbaren Anzeichen einer besonde-ren, bevorstehenden Veranstaltung oder ähn-lichem. Und so begehen wir, kaum, dass wir das 10-jährige Bestehen des SQ-Magazins gewürdigt haben, das nächste große Event: das 20-jährige Jubiläum des ASQF.Seit nunmehr zwei spannenden und aufre-genden Jahrzehnten steht die Arbeit des ASQF ganz im Dienst von Qualität. Qualitätsexperten und -idealisten machten sich Mitte der 1990er Jahre auf den Weg, um gemeinschaftlich die ersten Standards in Sachen Software-Qualität im deutschsprachigen Raum zu etablieren. Ur-sprünglich entwickelt aus einem lokal begrenz-ten EU-Förderprojekt, hat sich der ASQF zum größten Expertennetzwerk für Software-Quali-tät im deutschsprachigen Raum entwickelt. Der Weg dahin war nicht immer einfach. Dennoch haben wir durchgehalten. Das Ziel, weltweit an-erkannte Standards für Software-Qualität zu eta-blieren, ist erfüllt. Parallel zu dieser regulären SQ-Ausgabe, wid-men wir deshalb dem ASQF eine ganz besonde-re SQ-Sonderedition. Für die 100 Seiten starke Publikation konnten wir herausragende Persön-lichkeiten aus Praxis und Forschung gewinnen. Neben der limitierten Printausgabe wird dem-nächst auch ein Exemplar als Online-Version auf der Webseite des ASQF verfügbar sein. Doch nicht nur deshalb lohnt es sich, auf der neuen Homepage des Vereins vorbeizuschauen! In den vergangenen Monaten haben wir die Zeit ge-nutzt, sowohl die Online-Präsenz als auch den

Editorial

3 Ausgabe 41 | Dezember 2016

visuellen Auftritt des Vereins komplett zu über-arbeiten. Ein selbstgemachtes Weihnachtsge-schenk, sozusagen.In diesem Sinne wünsche ich Ihnen ein geseg-netes Weihnachtsfest und einen erfolgreichen Start in das kommende Jahr.

Herzlichst

Ihr Stephan GoerickeASQF-Hauptgeschäftsführer

Etwas ganz Besonderes

Was ist Ihre Meinung oder Erfahrung? Teilen Sie mir Ihre Gedanken mit! Ich freue mich auf Ihre Zuschrift und einen anregenden Austausch zu den verschiedensten Themen. [email protected]

Am 15. November fand im Unicum Er-langen die diesjährige Mitgliederver-sammlung des ASQF e.V. statt. ASQF-Präsidentin Prof. Dr. Ina Schie-ferdecker machte mit Blick auf das Jahr 2017 auf den Beginn des Jubilä-umsjahres aufmerksam: Vor 20 Jahren wurde der ASQF e.V. im Rahmen eines europäischen Förderprojektes aus der Taufe gehoben. Ina Schieferdecker, die bereits im vergangenen Jahr zur Vor-sitzenden gewählt wurde, informierte die anwesenden Mitglieder über die bevorstehenden Aktionen anlässlich des Jubiläumsjahres. Gleichzeitig lud sie alle dazu ein, sich mit eigenen Bei-trägen zu beteiligen. Dr. Armin Metzger stellte sich als neuer Referent des ASQF den anwesenden Mitgliedern vor und erläuterte die an-stehenden Ziele für die Vereinsarbeit. Ein Schwerpunkt im kommenden Jahr wird die intensive Kooperation und

Mitgliederversammlung des ASQF in Erlangen

ASQF NEWS

Abstimmung mit den Fachgruppen sein, um den Know-how-Austausch der ASQF-Mitglieder wieder deutlich zu steigern und inhaltlich auf aktuell brennende Fragestellungen besser eingehen zu können. Zudem sollen Ko-operationen mit anderen Verbänden geschlossen werden, um das Exper-tennetzwerk weiter auszubauen und den Mitgliedern eine noch größere Plattform zu bieten. Über eine erfolgreiche Entwicklung der ASQF-Tochter konnte Stephan Goericke berichten. Der ASQF-Haupt-geschäftsführer, der auch gleichzeitig die Geschäfte und Geschicke der iSQI GmbH leitet, konnte sich in den ver-gangenen Geschäftsjahren über ste-tigen Zuwachs freuen. Beim anschließenden Get-together nutzen die Mitglieder die Gelegenheit, sich in Gesprächen zu aktuellen The-men und Fachfragen auszutauschen.

4 ASQF-NEWS

8 TITELTHEMA

8 Usability und User Experience im Zeitalter maximaler Beschleunigung

11 Qualität aus der Perspektive eines Product Owners

30 Usability und User Experience Ein neues Verständnis für Qualität

16 IM GESPRÄCH 16 „Bezahlte Sicherheit“ GMX-Gründer starten mit neuer App

38 mit ASQF-Förderpreisträger Stefan Meiler

24 iSQI-NEWS

26 BEST PRACTICE

26 Wenn die Digitalisierung die Usability herausfordert

34 IM FOKUS

34 Weiterentwicklung der Fault Seeding Methode zur Steigerung der Testeffizienz

Inhalt

Wir sind stolz, Ihnen eine völlig über-arbeitete und neu gestaltete Website präsentieren zu können! Auf der neuen Website www.asqf.de finden Sie neben der Vorstellung des Vereins und seiner Mitarbeiter auch die Termine rund um den ASQF, das Karriereportal und vieles mehr.

Außerdem gibt es ein Blog, das nur darauf wartet, mit Inhalt gefüllt zu werden. Wenn Sie also ein span-nendes Thema haben, das Sie gern in der Öffentlichkeit vorstellen möchten oder mit anderen ASQF-Mitgliedern teilen wollen, freuen wir uns auf Ihre Zusendungen an [email protected].

ASQF reloaded

ASQF NEWS5 Ausgabe 41 | Dezember 2016

Am 20. September hatte die Fachgrup-pe Safety and Security Rhein-Main unter der Leitung von Vera Gebhardt zum dritten Mal zu einem ASQF-Day nach Flörsheim am Main eingeladen. Das Thema der Konferenz lautete „Herausforderungen der integrierten Entwicklung von Safety and Security Anforderungen“. Die insgesamt sie-ben Expertenvorträge präsentierten Lösungsbeispiele, offene Fragestel-lungen sowie erfahrungsbasierte Vor-gehensweisen für die Teilnehmer. Im Anschluss an die Fachreferate sowie in den Pausen wurde rege und praxis-bezogen gemeinsam diskutiert.Dr. Daniel Schneider (Fraunhofer IESE Kaiserslautern), referierte über of-fene Systeme und deren spezifische Herausforderungen bezüglich Safety

Safety and Security Day 3. Expertenfachtagung ASQF/tecmata

and Security. Jens Palluch (Method Park Consulting GmbH) brachte seine Erfahrungen im security engineering hervorragend ein und Thomas Schütz (PROTOS Software GmbH) führte die besonderen Herausforderungen des Einsatzes von Open Source Tools für Safety und Security deutlich vor Au-gen. Praxisnah sprach Markus Schmidt (Vertical GmbH) zur QAuth2.0 Imple-mentierung und den dabei angewen-deten Problemlösungen. Martin Zeh (TÜV NORD Systems GmbH & Co. KG) zeigte an einem lebendigen Projekt-beispiel, wie man die Manipulation abgasrelevanter Software-Funktionen durch entsprechende Konzepte für die Bewertung von Prozessen, Techniken und Maßnahmen erschweren kann. Gastgeberin Vera Gebhardt (tecmata

Die Präsentationen der ASQF-Days können Sie als ASQF-Mitglied im Mitgliederberich der neuen ASQF-Website www.asqf.de herunterladen.

GmbH) lieferte einen guten Überblick zu den Änderungen in Automotive SPICE 3.0. Außerdem führte Dr. Frank Schuhmacher am Beispiel eines auto-nomen Rasenmähers die Brisanz zum Nachweis der Authentizität von Sys-temkomponenten auf. Er vermittelte deutlich die Auswirkung von Geräte-Plagiaten auf Security-Anforderungen mit Safety-Wirkung.

„Anforderungen und Test oder Testen der Anforderungen“ lautete das über-greifende Thema beim ASQF Testing Day Niedersachsen Ende September. Die Leiter der Fachgruppe Software-Test, Niedersachsen, Guido Werner und Alexandra Schladebeck, hatten sieben Vorträge von Experten aus Theorie und Praxis ausgewählt, um die Verbindungen zwischen Test und Anforderungen zu beleuchten. Das Thema fand Resonanz: Über 50 Teil-nehmer hatten sich für den Day ange-meldet. Alexander Poth und Jörn Schrader (Volkswagen AG) begannen den Tag mit einem Bericht über das VW Agile Center of Excellence und erläuterten die Arbeitsweisen. Referent Marc Henke (IAV GmbH) wartet hingegen mit einem ganz anderen Fokus auf. Er beschäftigte sich mit Anforderungen und funktionaler Sicherheit sowie der Frage, welche Rolle das Dokumentie-

Testing Day Niedersachsenren bzw. die Rückverfolgbarkeit im ge-samten Entwicklungsprozess spielen. Remo Lachmann (TU Braunschweig) stellte seine Doktorarbeit zum Thema Machine Learning vor, die sich mit der automatischen Priorisierung von Test-fällen befasst. Nachmittags berichtete zunächst Han-nelore Papke (Otto GmbH & Co. KG) über ihre anforderungsgetriebene Teststrategie. Ihr Team hat Verbin-dungen zwischen Tests und Anforde-rungen in HP ALM abgebildet, damit Stakeholder entweder detaillierte oder high-level-Berichte zu den Tests und den abgedeckten Anforderungen für ausgewählte Testobjekte ansehen können. Der darauffolgende Talk von Roland Riedel (Brose Fahrzeugtechnik GmbH & Co. KG) war eine exzellente Gele-genheit, das Thema „Anforderungen“ über den normalen Entwicklungspro-zess hinaus zu betrachten.

Alexandra Schladebeck (BREDEX GmbH) berichtete von der „Qualität aus der Product Owner Perspektive“. Sie sensibilisierte das Publikum für zusätzliche Qualitätskriterien, die vom Entwicklungsteam und Testern in der Regel eher nicht betrachtet werden. Der Tag endete mit einem Vortrag von Jörg Marhenke (IAV GmbH): „Samba in Gummistiefeln tanzen“. Er betonte, dass man auch in nicht-agilen und dokumentationslastigen Umfeldern frühzeitig Feedback von Nutzern ein-holen kann. Seine „ausführbaren An-forderungen“ auf mobilen Geräten sind ein Werkzeug, um Anforderun-gen einfach zu visualisieren. Zusammenfassend lässt sich festhal-ten, dass die Talks des Testing Days die Vielfalt von Verbindungen zwi-schen Anforderungen und Testen auf-zeigten.

Ausgabe 41 | Dezember 2016 6

Am 6. Oktober 2016 fand zum drit-ten Mal die Mobile Quality Night im Stockwerk in Wien statt. Die Veranstal-tung war wieder ein voller Erfolg mit interessanten Vorträgen und einem breiten Publikum aus Österreich und Deutschland, von Studierenden bis zu Koryphäen im Bereich Software Testing. Die Themen waren aktueller denn je und widmeten sich den auf-kommenden Smart Devices und den Herausforderungen, die eine Qualitäts-sicherung von Hard- und Software mit sich bringt.Die Organisatoren Rudolf Grötz und Christoph Börner, beide Leiter der Mobile Quality Crew Vienna, hatten zu diesem Event Referenten aus ver-schiedenen Bereichen und Themen eingeladen. So teilte Christoph Schaal

ASQF NEWS

Mobile Quality Night Vienna 2016 von Smart Devices und Qualitätssicherung

Zuwachs: Neue Mitglieder im ASQF e.V.

Bakis Automation GmbHHamburgwww.bakis-automation.com

Werden Sie Mitglied im ASQF!Jetzt Mitgliedsantrag stellen und Teil einer Community aus über 1.400 Qualitätsexperten werden. www.asqf.de/asqf/mitglied-werden

www.asqf.de

azh GmbHAschheim bei Münchenwww.azh.de

Das Expertennetzwerk

seine Erfahrungen als Test Engineer bei Bosch Smart Home Solutions und Marcus Wiegand (Testplus) berich-tete von Erfahrungen mit einer smar-ten Waage. Bastian Baumgartner und Michael Mlynarski der QualityMinds präsentierten die Ergebnisse der Stu-die „Smartwatches und Usability-All-tag”.An diesem Abend wurde aber nicht nur Theorie vermittelt, sondern auch mit praktischem Wissen und Vorfüh-rungen veranschaulicht: Andreas Lü-decke (TestObject), Marcel Gehlen (MaibornWollf), Gerhard Wiesinger (Zoomsquare), Severin Winkler (SBA Research) sowie Sergej Mudruk (XING AG) und Christian Breitwieser (Rano-rex) ließen die Teilnehmer an Ihren Er-fahrungen teilhaben.

Alle Vortragenden zu den neuen Smart Devices stimmten größtenteils in einem Punkt überein: Die Herausfor-derung und das Fehlerpotenzial liegen in der Verbindung von Hardware und Software und in dem Umstand, dass diese oft von unterschiedlichen Her-stellern produziert werden. Damit wer-den Spezifikationen oft unzureichend aufeinander abgestimmt, was zu Bugs und schwächelnder Usability führt und das Testing von nicht-funktionalen An-forderungen zu einer großen Heraus-forderung machen.

Haben Sie Interesse die Organisation der Mobile Quality Night zu unterstüt-zen? Dann kontaktieren Sie uns unter: [email protected]

777

Zu Beginn jeden Projekts steht eine, auf Annahmen basierte Planung. Im Projektverlauf stellt sich heraus, dass manche Planungspunkte und Annah-men der Realität nicht mehr stand-halten. Eine Überarbeitung ist nötig. Wie wird sichergestellt, dass die neue Planung den neuen Anforderungen entspricht? Wie kann in Zukunft davon ausgegangen werden, dass das „neue Projektende-Datum“ halbwegs realis-tisch ist? Und wie begegnet man als Testmanager der Frage: „Können wir den geplanten Einsatztermin aus Sicht des Testteams halten?“Robert Licen, erfahrener Testmanager bei ANECON, suchte nach einer Lö-sung, die faktenbasiert und mit Hilfe von Hochrechnungen, Fragen über die Zukunft fundiert beantwortet – ohne sich dabei auf Annahmen bzw. das Bauchgefühl stützen zu müssen. Da-raus entwickelte er das ANECON End-of-Testing-Tool (EOT-Tool).

Der Ansatz

Der Software-Test ist naturgemäß ab-geschlossen, sobald alle gefundenen Fehler behoben wurden. Es ist davon auszugehen, dass die geschlossene Fehleranzahl immer größer und da-durch die Arbeitslast des Entwick-lungsteams verringert wird. Auf Basis der gesamten Projekthistorie ist fest-zustellen, wie lange der aktuelle Trend

noch anhalten wird und wann die An-zahl der offenen Fehler gegen null geht.

Der Schlüssel: Team-Performance

Je effizienter das gesamte Team zu-sammenarbeitet, desto schneller wird das Ziel erreicht. Passende Daten über die Team-Performance sind Indika-toren, um das Testende berechnen zu können. Gute Anhaltspunkte sind:

Aufdeckungsrate: Wie viele Fehler werden im Schnitt pro Zeiteinheit gefunden?

Behebungsrate: Wie viele Fehler konnten im Schnitt pro Zeiteinheit vom Testteam endgültig geschlossen werden?

Für eine aussagekräftige Prognose ist zusätzlich zu klären, wie lange das Ent-wicklungsteam neue Funktionalität im-plementiert.

Die Hochrechnung

Auf Basis dieser drei Werte wird er-mittelt, wie viele Tage noch benötigt werden, um alle Fehler abzuschließen – daraus ergibt sich ein Datum in der Zukunft. Robert Licen rät: „Da wir mit Durchschnittsdaten arbeiten, sollten mehrere Zeiträume betrachtet werden. Drei haben sich bewährt: gesamter Projektzeitraum, letzten zehn Wochen, letzten fünf Wochen.“ Zur Absiche-rung und Bestätigung werden die drei

Datumswerte über die Monte-Carlo-Simulation überprüft. Sie ist seit Jahr-zehnten wissenschaftlich anerkannt.

Nach der Prognose ist vor der Prognose

Die erste Hochrechnung ist frühestens vier Wochen nach Projektstart sinn-voll. Danach sollten die Berechnung regelmäßig durchgeführt werden. Denn je mehr Daten herangezogen werden, desto bessere Rückschlüsse können getroffen werden. Die Metho-de liefert Anhaltspunkte und keine ta-gesgenauen Prognosen. Jedoch ist die Wahrscheinlichkeit, mit der die Pro-gnose eintritt, hoch. Generiert aus der Projekthistorie lassen sich Fakten und Performance-Werte des Gesamtteams ablesen, die sich erfahrungsgemäß nicht signifikant ändern. „Das Tool hat den Praxistest bestanden: Seine Aus-sagen stimmen mit der Projektpraxis in meinen Projekten überein“, unter-streicht Robert Licen.

Maßnahmen setzen

Ergeben sich beim Abgleich von Plan – zu hochgerechnetem Ist-EOT-Wert – Abweichungen, sind entlang folgender Fragen Maßnahmen zu setzen:

Kann das Produkt zu einem bestimmten Zeitpunkt in Produktion gehen?

Hat sich die Team-Performance im Laufe der Zeit verbessert?

Welcher Produktivsetzungszeitpunkt wäre aus Testsicht mit hoher Wahrscheinlichkeit zu empfehlen?

ANECON bietet ein wichtiges Tool für Ihre Planung und unterstützt Sie mit optimal auf das Projektziel abge-stimmten Maßnahmen. Robert Licen bringt es auf den Punkt: „Mit dem von mir entwickelten ANECON EOT-Tool, haben Projektteams ein Tool in der Hand, das sie im Laufe des Projekts mit guten Prognosen versorgt. Das schafft Sicherheit und Qualität.“

Die End-of-Testing-Prognose Vom Bauchgefühl zu einer fundierten Vorhersage

Abb. 1 Screenshot einer Fehlertrend-Kurve

Titelthema Ausgabe 41 | Dezember 2016 8

Usability und User Experience im Zeitalter maximaler Beschleunigung

Wenn man Ray Kurzweil, dem genialen Erfinder und Futuristen, glauben darf, sind es nur noch 13 Jahre bis zu dem Zeitpunkt, an dem Computer den Menschen endgül-tig und unumkehrbar überflügeln. Ob die sogenannte „Singularität“ tatsächlich wie von ihm berechnet im Jahr 2029 eintritt und welche Folgen dieses mögliche Ereig-nis haben wird, ist aber völlig unklar und Gegenstand kontroverser Diskussionen von Experten in allen Bereichen. Als ein mögliches Szenario gilt die Vorstellung, dass es eine Art allumfassende künstliche Intelligenz geben wird, mit der sich unser Leben und Arbeiten steuern lässt, indivi-duell auf jeden Menschen zugeschnitten und ganz ohne haptische Objekte oder Schnittstellen. Das Ergebnis wäre quasi eine intuitive, unsichtbare Usability und eine perfekte, durchweg positive User Ex-perience. Ob das Szenario so eintritt und ob man es sich wünschen sollte, ist eine andere Frage.Dass die zunehmend beschleunigte Ent-wicklung von Informationstechnologien jetzt schon sichtbare und weitreichende Veränderungen in unserer Lebens- und Arbeitswelt nach sich zieht, lässt sich je-den Tag beobachten. Allerdings: Bis die Mensch-Maschine-Schnittstellen unsicht-bar in der Cloud verschwinden und nur noch über Gesten, Gedanken oder Spra-che gesteuert werden, ist im Bereich Usa-bility und User Experience noch viel zu tun.

von Manuel Fischer

999

Utopie und Wirklichkeit

Wenn man den Blick von der Utopie auf die Realität in Deutschland lenkt, fällt auf, dass der Status quo von „Usability“ und „User Experience“ sehr unterschiedlich ist und daher differenziert betrachtet werden sollte. Auf der einen Seite beklagen viele Wissenschaftler, Politiker und Unter-nehmer eine fehlende Innovations-kraft und -fähigkeit von Unternehmen im digitalen Bereich. Auf der anderen Seite gibt es aber viele Unternehmen, die massiv in die Digitale Transfor-mation investieren und sehr erfolg-reich mit ihren Innovationen sind. Das Spektrum reicht dabei von Steu-erungs-Software für international tä-tige Maschinenbauunternehmen über nahezu perfekte, serviceorientierte Apps bis hin zu spezialisierten VR-Anwendungen im B2B-Bereich. Wenn man Beispiele für das Verschlafen von digitalen Entwicklungen sucht, reicht ein Blick auf die Dax-30-Unternehmen. Fast ein Drittel von ihnen haben heute − im Jahr 2016 − noch keine mobil op-timierte Corporate-Webseite. Und das obwohl 56 Prozent der Internetnut-zung bereits heute über Smartphones und Tablets erfolgt, Tendenz steigend.

Sehr anschaulich werden die Bestre-bungen beim Thema Digitale Trans-formation in Deutschland mit einem Blick auf die Infrastruktur auf Straßen, Plätzen oder Bahnhöfen deutlich. So basiert das Bedienkonzept von Fahr-kartenautomaten in den Bahnhöfen offensichtlich auf internen IT-Anfor-derungen und internen Abläufen der Verkehrsunternehmen. Dies hat aber kaum etwas mit dem wahrschein-lichen Nutzungsszenario „Ich brauche jetzt gleich eine Fahrkarte von hier nach dort“ zu tun, mit dem diese Au-tomaten genutzt werden.

Im Trend: Nutzerzentrierung

Bei aller Unterschiedlichkeit der An-wendungen und Notwendigkeit der differenzierten Betrachtung lässt sich

Usability und User Experience im Zeitalter maximaler Beschleunigung

aktuell aber auch beobachten, dass der Aspekt der „Nutzerzentrierung“ bei der Entwicklung und Optimierung von Technologien und Schnittstellen immer wichtiger wird. Der unter ande-rem von Peter F. Drucker, dem legen-dären Vordenker der Management-lehre, geprägte Ansatz geht davon aus, dass der Kunde im Mittelpunkt aller Aktivitäten der Organisation ste-hen muss, wenn sie erfolgreich sein will. Es liegt in der Natur der Sache, dass jeder Experte – je nach seinem Fachbereich – unter dem Begriff „Nutzerzentrierung“ etwas anderes versteht. Daher ist es hilfreich und nützlich, gemeinsame Standards wie zum Beispiel in der Norm EN ISO 9241 („Ergonomie der Mensch-System-Interaktion“) zu definieren und so zu versuchen, eine gemeinsame Sprache und ein gemeinsames Vokabular zu finden. Erfahrungsgemäß ist schon oft viel gewonnen, wenn Einigkeit über die Bedeutung der zugrunde lie-genden Begrifflichkeiten wie Usability und User Experience besteht. In vielen Projekten lässt sich beobachten, dass beide Begriffe als Synonyme verwen-det werden oder, je nach Verständnis, unterschiedlich interpretiert werden. Im Sinne der ISO 9241 bedeutet Usa-bility kurz gesagt die konkrete Nut-zung der Anwendung durch einen be-stimmten Nutzer in einem konkreten Kontext zu einem bestimmten Zweck.

User Experience ist subjektiv

Die User Experience umfasst die sub-jektiven Eindrücke, Meinungen und Erwartungen des Nutzers vor, wäh-rend und nach der Nutzung. Dass sich die Anstrengung für eine optimale User Experience lohnt, zeigt eine ak-tuelle Studie aus den USA. Danach haben Unternehmen, die eine opti-male User Experience (beziehungs-weise Customer Experience) bieten, eine viel höhere Wertschöpfung, als Unternehmen, die keinen oder weni-ger Wert darauf legen. Im Zentrum der digitalen Wertschöpfung steht die möglichst einfache, intuitive Be-

Titelthema

nutzung der Anwendungen durch den End-Nutzer. Dabei gilt, dass sich gute Usability dadurch auszeichnet, dass sie nicht sichtbar ist und quasi unbemerkt wirkt. Schlechte Usabili-ty dagegen fällt den Nutzern sofort negativ auf und führt im ungünstigs-ten Fall zu einer unbefriedigenden User Experience, die sich wiederum direkt auf die „Digitale Marke” aus-wirkt. Und da im Zeitalter der Digi-talen Transformation fast alle Unter-nehmen, Organisationen und Marken digitale Touchpoints haben, die aus Kundensicht eine ganzheitlichen Er-fahrung („Customer Experience”) bil-den, steckt in der Optimierung von Usability und User Experience so viel Potential. Optimale Gebrauchstaug-lichkeit und Nutzungserlebnisse sind also kein Selbstzweck, sondern tra-gen entscheidend zur Wertschöpfung des Unternehmens und damit indirekt auch zum Erhalt der Gesellschaft bei.

Neue Technologien erfordern neue Nutzungskonzepte

Während viele Unternehmen in Deutschland noch überlegen, ob und wie sie auf die Veränderungen durch die Digitale Transformation reagieren oder gerade dabei sind, ihre digitalen Aktivitäten auf den neuesten Stand zu

bringen, entstehen parallel dazu ganz neue Technologien, die die bisherigen Standards in Frage stellen. Beispiele hierfür sind die Stichpunkte „Virtu-al Reality“, „Chat-Bots“ oder „Smart Home“, bei denen völlig neue Nut-zungs- und Bedienkonzepte entstehen, für die sich erst noch allgemeingültige Standards herausbilden müssen. Eini-ge Experten arbeiten heute unter dem Begriff “Zero-UI” an User Interfaces jenseits von Bildschirmen und son-stigen Oberflächen. Ob und wie die bisher bestehenden Grundlagen von Usability wie Aufgabenangemessen-heit, Selbstbeschreibungsfähigkeit, Lernförderlichkeit, Steuerbarkeit, Er-wartungskonformität, Individualisier-barkeit und Fehlertoleranz auch für die neuen Nutzungskonzepte gelten können, muss sich erst noch zeigen. Wahrscheinlich werden diese Grund-lagen aber an die neue Entwicklung angepasst werden müssen − mit allen Konsequenzen, die sich daraus für die Anpassung der Normen, Schulung oder Weiterbildung ergeben. Aktu-ell bestimmt aber − wie so oft schon bei solchen Entwicklungen – eher das technisch Machbare die Entwicklung von User Experience und Usability.

Gesucht: Eine neue Haltung

In der Ära der exponentiellen techno-logischen Beschleunigung müssen in immer kürzerer Zeit immer kom-plexere und noch bessere Lösungen entwickelt werden. Hierfür sind auch neue Methoden der Zusammenarbeit zwischen allen Beteiligten erforder-lich. Neben den schon seit einiger Zeit in der Software-Entwicklung eingesetzten agilen Methoden geht es aber auch um die Veränderung in der Haltung und der grundsätzlichen Einstellung. Es geht um nicht weniger als einen Weg von einem technisch getriebenen Ansatz hin zu einem Technologieverständnis, bei dem der spätere Nutzer − egal in welcher Rolle oder Funktion − wirklich und konse-quent im Mittelpunkt aller Aktivitäten steht. Es gibt zahlreiche Ansätze für die Organisation einer verbesserten

Manuel Fischer ist Mit-Gründer und Geschäfts-führer der Innovation & Excellence GmbH und hat über Jahre den Bereich Software der IT-Bundesverbands BITKOM geleitet.


Zusammenarbeit von Experten unter-schiedlicher Fachbereiche im Sinne einer optimalen Usability und User Experience. Die grundsätzlichen An-sätze sind:

Agilität: Kooperatives, gemeinschaft-liches Arbeiten in gemischten Teams mit agilen Methoden wie Scrum oder Design Thinking.

Kundenverständnis: Umfassende und tiefgreifende Kenntnisse über die Erwar-tungen und Meinungen der Kunden.

Interdisziplinarität: Besseres Verständnis für das Wissen und den Input aus anderen Fachbereichen.

Offenheit: Eigenes Wissen mitteilen statt schützen.

Iteratives Vorgehen: Komplexe Entwick-lungsprozesse in kleine Schritte aufteilen.

Stakeholder integrieren: In möglichst je-der Phase das Feedback von potentiellen Nutzern einholen.

Ganz entscheidend: Zielorientierung: Ziel und Ergebnis nicht aus den Augen verlie-ren.

Bis jetzt hat sich noch kein wirkliches Patentrezept als passend für alle Un-ternehmen, Märkte oder Situationen etabliert. Jede Organisation wird da-her für sich selbst herausfinden müs-sen, welchen Weg und welche Me-thoden für sie, ihre Mitarbeiter und Kunden die richtigen sind, um die di-gitale Zukunft aktiv mitzugestalten.

Und womit beschäftigen sich Usabili-ty- und Software-Experten nachdem die Singularität wirklich eingetreten ist und die Computer selbstständig über die Entwicklung und Nutzung von digitalen Anwendungen entscheiden? Sie könnten sich zum Beispiel wieder der Herstellung und Optimierung von Faustkeilen widmen. Damit würde sich ein langer Entwicklungskreislauf schließen und wer weiß – vielleicht wieder von vorne beginnen.

111111

Qualität aus der Perspektive eines Product Owners

Spricht man über Qualität im agilen Kontext, hört man früher oder später den Begriff

Whole Team Quality. Dahinter steckt die Er-kenntnis, dass ein Entwicklungsteam im agilen Prozess gemeinsam die Qualität der Entwick-lung verantwortet. Auch wenn ein oder mehrere integrierte Tester im Team sind, liegen nicht alle Testaufgaben allein bei diesen, sondern es arbeitet jeder im Team an der Qualität mit. Aber wie sieht es mit dem Product Owner aus? Welche Rolle nimmt er bei Whole Team Quality ein und welche beson-dere Sichten hat er in Hinblick auf die Qualität?

Sollen Product Owner auch testen?

Eine erste berechtigte Frage für einen Product Owner in Bezug auf Qualität lautet: Soll der Product Owner auch testen? In einem Scrum-Prozess ist der Product Owner nicht offiziell Teil des Entwicklungsteams und somit „ausgespart“ von den Aufgaben, die im Dev-Team angesiedelt sind. Die mögliche daraus resultierende Ant-wort „Testen ist nicht mein Job“ kommt sicher in manchen verantwortungsbewussten, cross-functional Teams schlecht an. Viele Product Ow-ner (die Autorin inbegriffen) haben einen Hinter-

von Alexandra Schladebeck


grund im Testen und wechseln je nach Team oder Aufgabe zwischen den bei-den Rollen. Man muss also nicht testen, könnte aber durchaus mitwirken. Die Gründe, warum ein Product Ow-ner eher nicht testet, sind andere. Wie in den kommenden Absätzen dargestellt, hat der Product Owner einen anderen Fokus oder sogar ganz andere Qualitätskriterien vor Augen. Auch die schlichte Zeitfrage kann ein Grund dafür sein. Der Product Owner steht dem Kunden und dem Team für Fragen, Demos, neue Anforderungen und klärende Gespräche zur Verfü-gung. Gründliches Testen oder neue Tests zu automatisieren, kann mei-stens nicht zeitnah genug erfolgen, um eine Funktion in kurzen Zyklen fer-tigzustellen.

Der Product Owner – Rollenbild und Bezug zur Qualität

Der Product Owner ist, wenn über-haupt, kaum am dynamischen Test be-teiligt. Das bedeutet aber keinesfalls, dass der Product Owner sich mit dem Thema Qualität nicht auseinander-setzen muss – ganz im Gegenteil. Der Qualitätsfokus für den Product Owner ist eng mit seiner Rolle und damit ein-hergehenden Aufgaben verbunden.

Das Priorisieren von Anforderungen im Sinne des Kunden.

Arbeiten an User Stories und Akzeptanzkriterien.

Als Ansprechpartner für Fragen zur Verfügung stehen.

Diese Aufgaben sind wichtig, jedoch sind sie rein operativ. Ohne das be-wusste Einhalten der agilen Prin-zipien, führen sie nicht automatisch zu zufriedenen Stakeholdern. Schaut man sich die agilen Prinzipien an, liest man folgendes:„Our highest priority is to satisfy the customer through early and continuo-us delivery of valuable software .”

In anderen Worten: Ohne einen gelie-ferten Value (Wert), haben die vielen Gespräche, Implementierungen und Tests wenig Bedeutung. Aus diesem Grund hat der Product Owner ein spe-zifisches Hauptziel vor Augen: Dem Kunden etwas Wertvolles ausliefern. Das kann dazu führen, dass der Pro-duct Owner ganz andere Qualitätskri-terien in Blick hat, als ein Tester oder Entwickler im Projekt.

Drei Bereiche sind für den Product Owner aus der Qualitätsperspektive besonders wichtig:

Qualität der Anforderungen,

Qualität der Entwicklung (bzw. der Arte-fakte, die aus der Entwicklung stammen),

Qualität des Releases.

Nachfolgend werden für jeden Bereich Hintergründe, Qualitätsmerkmale und praktische Hinweise beschrieben. Qualität der Anforderungen

Man kennt es aus der Software-Te-sting-Theorie: Schon bei der Anfor-derungsdefinition soll auf die Qualität geachtet und Anforderungen gete-stet werden. Doch agil und qualitativ hochwertige Anforderungen sind ein Widerspruch in sich, oder?

Korrektheit ist wichtig!

Nicht unbedingt. Wenn wir über gute Anforderungen sprechen, meinen wir häufig, dass sie den Qualitätskrite-rien Vollständigkeit, Eindeutigkeit und Klarheit genügen. In agilen Prozessen werden User Sto-ries vorgestellt, die diese Kriterien nicht erfüllen. Sie werden teilweise durch Refinement Meetings konkre-tisiert oder sie werden erst bei der Umsetzung im Detail diskutiert. Trotz-dem kann man von qualitativ hoch-wertigen Anforderungen sprechen – und zwar nach den Qualitätskriterien Nachvollziehbarkeit, Leanness (Ver-schwendungsminimierung) und Vor-stellbarkeit.

Nachvollziehbarkeit: Sind wir in der Lage, das Problem des Kunden zu ver-stehen? Wissen wir, warum der Kunde eine Lösung braucht bzw. wofür?

Leanness: Priorisierungen können sich bis zum Sprint-Anfang ändern. Es kann dadurch sein, dass eine Sto-ry, die sehr detailliert und aufwändig diskutiert wurde, nie (oder erst viel später) implementiert wird. Die Be-sprechungen zu einer Story, die nicht zeitnah implementiert wird, sind eine Zeitverschwendung (waste). Genauso verschwenderisch ist es, eine Story im Detail zu besprechen, bevor man sie angefangen hat, denn Pläne wer-den bei der Implementierung häufig geändert. Agile Prozesse versuchen solche Verschwendung zu vermeiden.

Vorstellbarkeit: Ohne, dass man alle Spezifikationen, Teilanforderungen oder technische Informationen vorlie-gen hat, sind wir in der Lage, Beispiele für eine mögliche Lösung zu erarbei-ten und vorzustellen?

„Gute“ Anforderungen

Bezüglich der Anforderungen legt der Product Owner einen besonderen Fokus auf das „Warum“ anstelle des „Wie´s“. Er sorgt in User Story Mee-tings dafür, dass die Stories, die oben genannten Qualitätskriterien erfül-

Alexandra Schladebeck

131313

len. Bei einem Team, bestehend aus Technikern, kann es schwer sein, sich verstärkt auf das „Warum“ zu konzen-trieren – aber der Versuch lohnt sich. Viele in User-Story-Meetings ausdis-kutierten Implementierungen oder Details ändern sich, sobald die ersten Code-Zeilen geschrieben sind. Um Verschwendung zu minimieren und um das Team eigenständig, selbstor-ganisiert und initiativergreifend ar-beiten zu lassen, fokussiert man sich besser auf das „Warum“ anhand von Beispielen, die einen konkreten An-satzpunkt erlauben. Im Alltag kann das so aussehen: User-Story-Meetings werden ohne Rechner durchgeführt. Die Stories werden tat-sächlich als Stories vorgestellt. Das Problem des Kunden wird erläutert. Es wird Empathie und Verständnis dafür erzeugt. Beispiele können mündlich oder am Whiteboard besprochen wer-den. Der Product Owner notiert sich wichtige Anmerkungen oder Randbe-dingungen für die Story oder Akzep-tanzkriterien zum Dokumentieren im Nachgang – aber es müssen nicht alle Details schriftlich festgehalten wer-den. Das Team hat das „Warum“ ver-standen, und dieser Zustand spart viel Dokumentation. Natürlich muss der Fokus auf das „Wie“ irgendwann kommen. Das kann in technischen Gesprächen im Entwicklungsteam passieren. Da-her sollten entsprechende Puffer im Sprint oder in den Schätzungen dafür eingeplant werden. Größere, wichtige Architektur- oder Technik-entscheidungen können immer noch gesondert gehandelt werden.

Qualität der Entwicklungsartefakte

Der neue Sprint hat angefangen. Als Product Owner freut man sich darauf, die aktuell zu entwickelnden Funkti-onen dem Kunden bald zur Verfügung zu stellen und möchte natürlich, dass sie gut getestet sind. Anhand der ein-leitenden Absätze dieses Beitrags ist jedoch ersichtlich, dass der Pro-

duct Owner selbst sehr wenig testen kann. Korrektheit ist daher wichtig: Diese wird aber vom Entwicklungs-team geleistet und verantwortet. Bei laufenden Entwicklungen interessiert sich der Product Owner daher stär-ker für Qualitätskriterien, die über die Korrektheit hinausgehen – denn dem Kunden reicht korrekt implementiert nicht aus. An dieser Stelle achten Pro-duct Owner auf Angemessenheit und Auslieferbarkeit.

Angemessenheit: Hier wird die Fra-ge gestellt, ob das Team das Richtige umgesetzt hat, um das Problem des Kunden zu lösen.

Auslieferbarkeit: Nur durch ausge-lieferte Funktionen bekommt der Kun-de einen Wert. Aus diesem Grund ist es für den Product Owner wichtig, dass das Team in absehbarer Zeit zu einem Auslieferungsstand kommen kann.

„Fertigwerdbarkeit“: Diesen Begriff findet man nicht in der Literatur, aber er beschreibt ein wichtiges Qualitäts-ziel: die Fähigkeit, eine Funktion tat-sächlich fertig zu bekommen. In einem agilen Team wird hierfür die Definition

of Done verwendet. Es darf nicht der Fall sein, dass Funktionen zeitnah im-plementiert werden, aber danach viel Zeit vergeht, bis sie getestet, doku-mentiert und abgenommen sind.

Auswertbarkeit: Bei vielen Ände-rungen und kurzen Release-Zyklen ist es entscheidend, zeitnahes Feed-back über die aktuelle Qualität zu er-halten. So kann der Product Owner besser Rest-Risiken einschätzen und Entscheidungen über Auslieferungen oder Weiterentwicklung treffen.

Angemessenheit ständig prüfen

Die Überprüfung der Angemessenheit kann und soll während des ganzen Sprints passieren. Der Product Owner ist maßgeblich daran beteiligt. Er kann mit Entwicklern oder Testern gemein-sam arbeiten (Pairing), um Zwischen-versionen anzuschauen und Feedback zu geben. Es finden Gespräche über neue Erkenntnisse oder Details statt und Verwendungsbeispiele werden regelmäßig verfeinert. Wichtig ist, dass der Product Owner nicht erst im Sprint Review die aktuellen Entwick-lungen sieht. Durch zeitnahes Feed-


Alexandra Schlade-beck ist Leiterin der Test Consulting bei der BREDEX GmbH und der Product Owner für das Eclipse Jubula Test-Tool. Sie verbringt ihre Zeit in Kommunikation mit Kunden, Testern, Be-nutzern und Entwick-lern. Besonders inter-essiert sie sich neben Benutzerfreundlichkeit und Ergonomie auch für Agilität in Test- und Entwicklungs-prozessen. Sie spricht häufig auf Konferenzen über Agilität und Qualitätssicherung aus Sicht ihrer Projekter-fahrung.

back während des Sprints werden Funktionen häufig und frühzeitig auf ihre Angemessenheit überprüft.

Wann können wir ausliefern?

Der richtige Test der Angemessenheit findet natürlich beim Kunden statt. Als Product Owner achtet man aus diesem Grund darauf, dass das Team tatsächlich Potentially Shippable In-crements erzeugt. Ein typisches zu vermeidendes Szenario ist, dass im-mer wieder neue Stories umgesetzt werden, bevor schon implementierte Stories als fertig gelten.

In der Praxis kann man die „Fertig-werdbarkeit“ durch bewusste Fragen und einen strengen Fokus auf Work-in-Progress-Limitierung erhöhen. Ein Beispiel: Nach dem Stand-up-Meeting stellt sich das Team die Frage „Was bekommen wir heute fertig?“. Es wird

gemeinsam auf die Stories „in Arbeit“ geschaut, um Schritte und Prioritäten festzulegen, damit diese als done ge-kennzeichnet werden können. Um Fla-schenhälse zu vermeiden, muss jeder im Team grundsätzlich für den Test (oder auch die Dokumentation/andere Aufgaben im Definition of Done) zur Verfügung stehen. Es kann gemein-sam gearbeitet werden, ein integrier-ter Tester und/oder der Product Ow-ner können Test-Chartas definieren aber die gesamte Test-Last wird nicht alleine auf die Schultern von wenigen Personen verteilt.

Ein weiterer Aspekt, um fertig zu wer-den und ein Potentially Shippable Increment zu erzeugen, ist die Mini-mierung von Blockaden. Wenn Funk-tion X fertig ist, aber Funktion Y noch in Arbeit ist, kann dieser Konflikt ein Release behindern. Um solche Situa-tionen zu vermeiden, kann man Fea-ture Branches einsetzen, damit die Entwicklung unterschiedlicher Funk-tionen unabhängig voneinander er-folgt. Ist Funktion Y nicht fertig, wird sie einfach nicht mit ausgeliefert.

Der Wunsch nach Auswertbarkeit bei dem Product Owner stammt von dem Bedarf, ohne lange Release-Phasen Software-Stände ausliefern zu kön-nen, bzw. dem Kunden Zwischenver-sionen ohne Angst auf böse Überra-schungen zeigen zu können. Feedback über die Qualität gehört zum Prozess, zum Beispiel durch automatisierte Tests und zeitnahes exploratives Te-sten. Am Ende des Stand-Up-Mee-tings empfiehlt es sich, dass das gan-ze Team auf die Testergebnisse der Nacht schaut. Damit dieser Prozess effizient bleibt, kann man einfache Schritte definieren:

1 Teilautomatisierte Auswertung: Es soll ein automatischer Bericht erzeugt wer-den, der aussagt, welche Tests mit wel-chem Ergebnis gelaufen sind. So ist der Suchaufwand nach eingefrorenen Test-maschinen oder grundsätzlichen Build-/ Environment-Problemen reduziert.

2 Vorbereitung: Die tatsächlichen Fehl-schläge werden im Voraus von einem Teammitglied analysiert, sodass eine Übersicht zur Verfügung steht.

3 Regeln im Team einführen, die Entschei-dungen erleichtern: Zum Beispiel, dass fehlschlagene Tests mit höchster Prio-rität analysiert, angepasst oder gegen einen neuen gefixten Software-Stand erneut durchgeführt werden.

Mit diesem Fokus auf Auslieferbarkeit ist es leichter für den Product Owner, einen Release-Candidate zu benen-nen.

Qualität des Releases

Trotz zahlreicher Tests während eines Sprints führen viele Teams zusätzlich einen Release-Test durch, bevor die Software ausgeliefert wird. In solchen Phasen muss der Product Owner risi-kobasiert und kontextabhängig zwei Qualitätskriterien abwägen: Abde-ckung und Geschwindigkeit.

Abdeckung: Dieses Qualitätskriteri-um gibt Auskunft darüber, wie viel ge-testet wurde und welche Risiken noch offen sein könnten. Man kann die Ab-deckung durch weitere Tests erhöhen, aber 100% Abdeckung bzw. 0% Rest-Risiken sind nie erreichbar.

Geschwindigkeit: Sie definiert, wie lange ein Team von dem Bereitstellen eines Release-Candidates bis zur tat-sächliche Freigabe braucht.

Agile Projekte sollen dem Kunden einen Marktvorteil durch regelmäßige Aus-lieferungen bringen. Wie oben schon erwähnt, kann sich eine nicht auslie-ferbare Software oder ein verzögertes Release negativ auswirken. Deshalb ist Geschwindigkeit ein relevantes Quali-tätsmerkmal für einen Product Owner.

Übung und Vertrauen

Um eventuelle Rest-Risiken zu iden-tifizieren oder die Software bzw. die

151515

neuen Funktionen ganzheitlich be-trachten zu können, kann ein schlan-ker Release-Test angebracht sein. Ein diesbezüglicher Ansatz ist der „ex-plorative Test-Tag“ mit dem ganzen Team. Sowohl Product Owner als auch das Team bereiten hierfür die Chartas vor, die mit Session-Based Test-Management organisiert und durchgeführt werden. Die Chartas fal-len meist in drei Kategorien:

1 Neue Funktionalitäten, als Epics statt als individuelle Stories betrachtet

2 Offene, bekannte Risiken

3 Wiederkehrende Problembereiche aus der Erfahrung mit vergangenen Releases

Nach diesem Test-Tag verfügt der Pro-duct Owner über eine zusätzliche Ent-scheidungsgrundlage für die Freigabe der Software. Damit der Nachgang zum explora-tiven Test Tag nicht durch panisches Bug Fixing geprägt wird (welches das Release zwar stabiler macht, aber auch verzögert), muss die Grundqua-lität ein gewisses Level erreicht und gehalten haben. Dies passiert dann, wenn das Team gemeinsam im Sprint testet und eine vernünftige Testauto-matisierungsstrategie einhält. Die bö-sen Überraschungen im letzten Test werden dadurch minimiert. Man muss aber nicht gleich für das nächste große Release auf 1-Tag-Testphasen umstellen. Teams können sich in Geschwindigkeit üben, indem sie nach jedem Sprint eine Beta-Ver-sion bereitstellen (die zum Beispiel für gewisse Kundengruppen verfügbar ist). Dies übt die Schritte vom poten-tially shippable zum actually shipped in einem kleineren, weniger risikobe-hafteten Umfang. Außerdem werden eventuelle Hürden oder Blockaden für den Release-Prozess an sich erkannt, die man ausräumen kann. Letztendlich muss der Product Owner dann eine der schwierigsten Entschei-dungen treffen und die Frage beant-worten: Wird dieser Stand mit seinen

bekannten und unbekannten Proble-men ausgeliefert? Die Versuchung ist groß, einen letzten Fix reinzunehmen oder noch einen Test durchzuführen. Aber die Geschwindigkeit – und da-durch eventuell der Kunde – leiden darunter. Deshalb muss man auf das Team, seine Arbeit und die durchgän-gigen Überprüfungen und Tests ver-trauen und loslassen. Falls Probleme im produktiven Stand identifiziert werden, weiß man, dass eine Behe-bung wiederum zeitnah ausgeliefert werden kann.

Zusammenfassung

Die in diesem Artikel beschriebenen Schritte müssen natürlich für jeden Projektkontext abgewogen werden. Für sicherheitskritische Systeme zum Beispiel könnte das Merkmal Ge-schwindigkeit eine deutlich reduzier-tere Rolle spielen. Nichtsdestotrotz sollten sich Product Owner immer wieder daran erinnern, dass der Kun-de frühzeitig und regelmäßig Value benötigt. Hier sind einige Beispiele für Qualitätskriterien aus Sicht der Pro-duct Owner genannt worden. Wichtig ist, dass jeder Product Owner in sei-nem Kontext die für sich besonderen Merkmale identifiziert und auf deren Erfüllung achtet.

M. Winter · T. Roßner · C. Brandes · H. Götz

Basiswissen modellbasierter TestAus- und Weiterbildung zum ISTQB® Foundation Level – Certified Model-Based Tester

2. Auflage2016, 474 Seiten€ 44,90 (D) ISBN 978-3-86490-297-0

Wieblinger Weg 17 · D-69123 Heidelberg fon: 0 62 21 / 14 83 40 · fax: 0 62 21 / 14 83 99e-mail: [email protected]

www.dpunkt.de

P. Metz

Automotive SPICE® – Capability Level 2 und 3 in der PraxisProzessspezifische Interpretationsvorschläge

2016, 286 Seiten€ 42,90 (D) ISBN 978-3-86490-360-1

M. Müller · K. Hörmann · L. Dittmann · J. Zimmer

Automotive SPICE® in der PraxisInterpretationshilfe für Anwender und Assessoren


Neu bei dpunkt

Buch + E-Book:

www.dpunkt.de/plus

T. Linz

Testen in Scrum-Projekten Leitfaden für Software-qualität in der agilen WeltAus- und Weiterbildung zum ISTQB® Certified Agile Tester – Foundation Extension


D. Knott

Mobile App TestingPraxisleitfaden für Soft-waretester und Entwickler mobiler Anwendungen

2016, 256 Seiten€ 29,90 (D) ISBN 978-3-86490-379-3

Im Gespräch Ausgabe 41 | Dezember 2016 16

„Wir holen die Privatsphäre in die digitale Welt zurück!“, versprachen die GMX-Gründer im Som-mer und kündig ten den Launch einer vollständig verschlüsselten, integrierten App namens Brabb-ler an. Sie soll noch in diesem Jahr erscheinen und eine Alternative zu den herkömmlichen An-geboten bieten. Der Knackpunkt: Die App soll sich nicht über Werbung, sondern über die Bezahlung der Nutzer finanzieren. Christin Senftleben, Chef-redakteurin des SQ-Magazins, befragte dazu die Brabbler-Hersteller Karsten Schramm, Eric Dola-tre, und Jörg Sellmann.

SQ: Fast 20 Jahre nach der Gründung von GMX kündigen Sie eine Kommunikations-App an, die werbefrei ist und auch deshalb keine Daten-spuren hinterlässt. Hand aufs Herz: Wäre das nicht schon viel eher notwendig gewesen?

Dolatre: Stimmt, das haben wir uns eben auch gefragt: Wieso gibt es das noch nicht? Das hat uns angespornt.

Sellmann: Vor zehn Jahren gab es noch kein Bewusstsein für Themen wie Datenschutz oder digitale Privatsphäre. Schuld daran war die „Kostenlos-Mentalität“ und die hatte ihren Ur-sprung in den Anfängen des Internets. Die ersten Business-Modelle, die sich im Web vor knapp 20 Jahren etablierten, beruhten alle auf dem „Gra-tis-für-Werbung-Prinzip“. Der Konsument hat sich schnell daran gewöhnt und das fast zwei Jahr-zehnte lang nicht hinterfragt. Währenddessen entwickelte sich der Daten- und Werbemarkt im Hintergrund immer weiter. Erst die Enthüllungen der letzten Jahre haben die Menschen ernsthaft zum Nachdenken bewegt. Unserer Meinung nach befinden wir uns nun in einer Phase der Aufklä-rung, die einem Ansatz wie unserem einen Nähr-boden bietet.

Schramm: In Unternehmen erkannte man digi-tale Gefahren etwas früher. Hier steht ja nicht die Privatsphäre, sondern die Vertraulichkeit von Da-ten, geistigem Eigentum und Korrespondenz im Vordergrund. Digitale Spionage, Sabotage oder Hacker-Angriffe sind selbst bei kleinen Unterneh-men schon lange ein Thema. Durch die rasante Digitalisierung in allen Branchen und Unterneh-mensgrößen wird das noch weiter an Bedeutung gewinnen. Das ist ein Grund, warum unsere Stra-tegie je zur Hälfte auf Geschäftskunden und End-verbraucher setzt. SQ: Was ist der Unterschied zu Konkurrenzange-boten wie beispielsweise Threema?

Dolatre: Allen voran sind wir kein Messenger. Wir setzen digitale Kommunikation nicht mit Messaging gleich, sondern sehen darin alles, was digital mit anderen ausgetauscht wird. Das sind nicht nur Nachrichten, sondern auch Ter-mine, Dateien oder Kontakte. All diese Abläufe decken wir in einer einzigen App ab, so dass ein Nutzer nicht zwischen zahlreichen Anwen-dungen hin- und herspringen muss. Da unsere Mission die Wiederherstellung von Vertraulich-keit und Privatsphäre ist, haben wir auch gleich einen Passwort-Manager mit Passwort-Genera-tor hinzugefügt. Denn schwache Passwörter ste-hen bei den Sicherheitslücken, die beispielswei-se von Geheimdiensten ausgenutzt werden, an allererster Stelle.

Schramm: Im Gegensatz zu anderen Produkten verschlüsseln wir nicht nur den Datentransport Ende-zu-Ende, sondern auch die Datenspeiche-rung, und realisieren damit einen Datentresor, der sich über mehrere vom Nutzer verwendete Endgeräte erstrecken kann. Das alles basiert auf den derzeit anerkanntesten Kryptotechnologien, die sogar Angriffen von Quantenrechnern stand-halten würden. Unser Ansatz bietet einen Funk-tionsumfang, der dem bekannten Produktivitäts-Suiten am Arbeitsplatz ähnelt.

SQ: Wir verbringen täglich mehrere Stunden im Web, mobil per Smartphone und am PC. Die di-gitale Privatsphäre gerät zunehmend in Gefahr. Dennoch tauschen Millionen Nutzer ihre per-sönlichen Daten bereitwillig gegen kostenfreie Angebote. Warum meinen Sie, wird ein Bezahl-dienst wie Brabbler Erfolg haben?

Bezahlte SicherheitMit einem Bezahlmodell wollen die GMX-Gründer den Schutz von Kommunikations-daten gewährleisten

17

Die Brabbler-Grün-

der (v.l.n.r.) Peter

Köhnkow, Jörg

Sellmann, Eric

Dolatre, Karsten

Schramm wollen

mit ihrer App

unsere Kommu-

nikation sicherer

machen.

Dolatre: Wie Herr Sellmann bereits erwähnte, se-hen wir einen Trend zu mehr Bewusstsein, nicht nur bei Unternehmen, sondern auch bei den End-verbrauchern. Diese Entwicklung begann um die Zeit der Snowden-Enthüllungen und hat seitdem kontinuierlich Fahrt aufgenommen. Die Zielgrup-pe derer, die sich bewusst mit dem Schutz der eigenen Daten und digitalen Privatsphäre ausein-andersetzen, stellt bereits heute einen lukrativen Markt dar und der wächst rasant. Ein Beispiel: Kurz nach der US-Wahl konnten Anbieter von Verschlüsselungslösungen enormen Zuwachs

verzeichnen. Grund war die Sorge, die neue Re-gierung könne noch stärker Gebrauch von den enormen Überwachungskapazitäten der NSA machen. Aktuell findet ein kollektives Umden-ken statt und zahlreiche Menschen suchen nach Lösungen für den Schutz ihrer Daten, sowohl im privaten als auch im gewerblichen Kontext. Doch bisher gab es keine wirkliche Alternative zu den werbefinanzierten und/oder in den USA ansäs-sigen Diensten. Diese bieten wir. Wir sind werbe-frei, sammeln keinerlei Daten, verschlüsseln nicht nur beim Versand, sondern auch bei der Speiche-

Im Gespräch Ausgabe 41 | Dezember 2016 18

rung, haben ein transparentes Geschäftsmodell und sind made and hosted in Germany.

Sellmann: Das etablierte Businessmodell, in der Leistung gegen Werbung erbracht wird, gerät zunehmend ins Wanken. Die letzten zwei Jahre haben einen regelrechten Boom im Bereich der Ad-Blocker gesehen. Alleine im Jahr 2015 hat sich die Zahl der Nutzer von Lösungen, die On-line-Werbung herausfiltern, verdoppelt. In Folge versuchen sich Verlage weltweit an Paid-Content-Modellen und verlangen bares Geld für digitale Inhalte – manche mit mehr, manche mit weniger Erfolg. Das alles zeigt in dieselbe Richtung: Die End-Verbraucher sind von der Flut an Werbung übersättigt und offen für Bezahlmodelle. Im Üb-rigen zahlen Nutzer auch heute schon bares Geld für digitale Leistungen wie beispielsweise Pre-mium-Mitgliedschaften bei XING oder Fitness-Apps. Im gewerblichen Kontext stellt sich die Frage der Zahlungsbereitschaft übrigens über-haupt nicht. Hier war man schon immer bereit, in Sicherheit zu investieren. Und genau diese Denke etabliert sich jetzt auch bei Privatnutzern.

SQ: Sie sprechen von einer „Erosion der Privat-sphäre“. Als Gründer von GMX haben auch Sie zur Datensammelwut im Internet beigetragen. Wie sehen Sie das aus heutiger Sicht?

Dolatre: Es ist richtig, dass wir die Entwicklung der profilbasierten Werbung in Deutschland zu unseren Zeiten bei GMX federführend vorange-trieben haben. Wir sahen seinerzeit viel Potential

in diesem Ansatz. Doch das Ausmaß dessen, was heute mit den Daten von Nutzern geschieht, über-steigt alles, was wir uns damals für die Zukunft ausgemalt hatten, um ein Vielfaches. Wir garan-tierten unseren Mitgliedern, deren anonymisierte Daten ausschließlich innerhalb des Werbeträgers GMX zu nutzen. Eine Weitergabe war komplett ausgeschlossen. Was jedoch Anbieter von ko-stenlosen Diensten aktuell mit solchen Daten ma-chen, ist bekannt. Aus gesellschaftlicher Sicht müssen wir insbesondere auch unsere Kinder vor der drohenden totalen Transparenz schützen. So-mit sind wir heute angetreten, um die Büchse der Pandora, die wir damals öffnen halfen, wieder zu schließen.

Schramm: Aus technischer Sicht sahen wir schon damals Ansätze dessen, was heute gang und gäbe ist. Doch wir hatten strenge, moralische Standards. So waren unter unserer Führung die Inhalte der Nutzer absolut tabu, obwohl es tech-nisch möglich gewesen wäre, mitzulesen und auszuwerten. Heute verschwenden die weltbe-sten Datenanalysten ihr Potential für enorme Gehälter damit, personenbezogene Inhalte und Daten auszuwerten und zu Verbraucherprofilen zu verknüpfen, die möglichst zielgerichtete Wer-bung erlauben. Das ist absurd. Ich denke nicht, dass wir das damals so hätten vorhersehen kön-nen. Doch es ist nie zu spät, etwas zu ändern. Und genau das haben wir mit Brabbler vor.

Schulungen 2017Januar -März 2017Certified-Schulungen werden ausschließlich von akkreditierten Unternehmen durchgeführt. Das iSQI fungiert hier als Vermitt-ler. Anmeldeformular und Preise unter www.isqi.org.

Ort Datum (Start) Tage Anbieter

ASQF® Certified Professional for Project Management

Köln 06.03.17 4 SQS

Frankfurt 20.03.17 4 SQS

CMAP Mobile App Testing

Berlin 16.01.17 2 Díaz & Hilterscheid Unternehmensberatung GmbH

Braunschweig 23.01.17 2 BREDEX GmbH

Berlin 09.02.17 2 Loyal Team GmbH

Berlin 06.02.17 2 CGI Deutschland Ltd. & Co. KG

Offenbach a.M. 20.02.17 2 Sogeti Deutschland GmbH


Hannover 27.02.17 2 Díaz & Hilterscheid Unternehmensberatung GmbH


Frankfurt 09.03.17 2 Loyal Team GmbH

Köln 09.03.17 2 Loyal Team GmbH

München 13.03.17 2 Loyal Team GmbH

Stuttgart 13.03.17 2 Loyal Team GmbH

Düsseldorf 13.03.17 2 Sogeti Deutschland GmbH


Köln 30.03.17 2 SQS

CMAP Mobile App Test Automation


Düsseldorf 22.02.17 3 CGI Deutschland Ltd. & Co. KG




iSQI® Certified Agile Business Analysis


München 29.03.17 2 Sogeti Deutschland GmbH


iSQI® Certified Agile Essentials




Hamburg 09.02.17 2 Loyal Team GmbH

Stuttgart 13.02.17 2 Sogeti Deutschland GmbH


iSQI's CAT Certified Agile Tester®



Wien 20.02.17 5 ANECON

Frankfurt 20.02.17 5 Integrata / CGI Deutschland Ltd. & Co. KG

Stuttgart 20.02.17 5 Method Park Consulting GmbH


Frankfurt 20.03.17 5 Integrata / CGI Deutschland Ltd. & Co. KG


iSQI Certified Agile Test Driven Development (TDD)


ISTQB® Certified Tester – Foundation Level



München 09.01.17 4 ISARTAL akademie GmbH


Erlangen 10.01.17 4 Method Park Consulting GmbH

Hamburg 16.01.17 4 SQS

Termine to goeinfach aus der Heftmitte heraustrennen

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

STA

ND

: Nov

emb

er 2

016

Hamburg 16.01.17 4 Díaz & Hilterscheid Unternehmensberatung GmbH

München 17.01.17 4 CGI Deutschland Ltd. & Co. KG



Köln 23.01.17 4 SQS

Bielefeld 23.01.17 3 Díaz & Hilterscheid Unternehmensberatung GmbH

München 30.01.17 4 Method Park Consulting GmbH

Stuttgart 30.01.17 3 Díaz & Hilterscheid Unternehmensberatung GmbH

Hamburg 31.01.17 4 CGI Deutschland Ltd. & Co. KG


München 06.02.17 4 SQS




Berlin 13.02.17 4 SQS

Köln/Düsseldorf 13.02.17 3 Díaz & Hilterscheid Unternehmensberatung GmbH

Stuttgart 15.02.17 3 Loyal Team GmbH

Röttenbach 15.02.17 3 sepp.med



Osnabrück 20.02.17 3 Díaz & Hilterscheid Unternehmensberatung GmbH

Frankfurt 21.02.17 4 CGI Deutschland Ltd. & Co. KG



München 27.02.17 3 Díaz & Hilterscheid Unternehmensberatung GmbH






Berlin / englische Sprache 06.03.17 4 Díaz & Hilterscheid Unternehmensberatung GmbH


Wien 07.03.17 4 OBJENTIS Software Integration GmbH

Hannover 13.03.17 4 SQS



Köln 20.03.17 4 SQS

Dortmund 20.03.17 3 Díaz & Hilterscheid Unternehmensberatung GmbH

Stuttgart 21.03.17 4 CGI Deutschland Ltd. & Co. KG


Nürnberg 27.03.17 3 Díaz & Hilterscheid Unternehmensberatung GmbH

ISTQB® Certified Tester – Foundation Level Extension, Agile Tester


Frankfurt 19.01.17 2 Díaz & Hilterscheid Unternehmensberatung GmbH

Wolfsburg 23.01.17 2 sepp.med



Bielefeld 26.01.17 2 Díaz & Hilterscheid Unternehmensberatung GmbH

Stuttgart 02.02.17 2 Díaz & Hilterscheid Unternehmensberatung GmbH


Köln/Düsseldorf 16.02.17 2 Díaz & Hilterscheid Unternehmensberatung GmbH


Osnabrück 23.02.17 2 Díaz & Hilterscheid Unternehmensberatung GmbH



München 02.03.17 2 Díaz & Hilterscheid Unternehmensberatung GmbH



Bremen 09.03.17 2 Loyal Team GmbH








Dortmund 23.03.17 2 Díaz & Hilterscheid Unternehmensberatung GmbH

Nürnberg 30.03.17 2 Díaz & Hilterscheid Unternehmensberatung GmbH

ISTQB® Certified Tester – Advanced Level, Test Manager

Hamburg 09.01.17 5 CGI Deutschland Ltd. & Co. KG


Wolfsburg 16.01.17 5 sepp.med






Köln 13.02.17 5 SQS



Bremen 01.03.17 5 Loyal Team GmbH







Wien 22.03.17 5 (exkl. Sa/So) ANECON






ISTQB® Certified Tester – Advanced Level, Test Analyst




Köln 23.01.17 4 SQS


München 06.03.17 5 Method Park Consulting GmbH




ISTQB® Certified Tester – Advanced Level, Technical Test Analyst









München bei Isartal Akademie 20.03.17 4 Method Park Consulting GmbH



Köln 27.03.17 3 SQS

ISTQB® Certified Tester – Foundation Level Extension, Model-Based Tester



IREB® Certified Professional for Requirements Engineering – Foundation Level



Nürnberg 23.01.17 3 SOPHIST GmbH


Frankfurt 06.02.17 3 SOPHIST GmbH

München 13.02.17 3 SOPHIST GmbH




Frankfurt 01.03.17 3 SOPHIST GmbH


Berlin 06.03.17 3 microTOOL GmbH



Stuttgart 20.03.17 3 SOPHIST GmbH



IREB® Certified Professional for Requirements Engineering – Advanced Level, Requirements Elicitation and Consolidation




IREB® Certified Professional for Requirements Engineering – Advanced Level, Requirements Modeling


Düsseldorf 28.02.17 3 SOPHIST GmbH

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

Ansprechpartner:Beatrice MichelisTrainings and SeminarsTel.: +49 331 [email protected]

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

SIE WOLLEN IHR SEMINAR AUCH IMNÄCHSTEN SQ-MAGAZIN BEWERBEN? Wir freuen uns über eine Nachricht. Bitte sendenSie uns Ihre Termine per E-Mail zu: [email protected]

Friedrich-Engels-Straße 24 14473 PotsdamTel.: +49 331 231810-0Fax: +49 331 231810-10

Alle Themen auch als Inhouse-Angebot buchbar!

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

Seminartitel Ort Datum(Start) Tage Anbieter

Automotive SPICE® - iNTACS™ certified Competent Assessor (englischsprachig) Kornwestheim 23.01.17 5 KUGLER MAAG CIE GmbHAutomotive SPICE® - iNTACS™ certified Provisional Assessor (englischsprachig) Region Stuttgart 06.02.17 5 KUGLER MAAG CIE GmbHTrain-the-Trainer München 13.02.17 3 ISARTAL akademie GmbHUpdate zu Automotive SPICE v3.0 (deutschsprachig) Kornwestheim 23.02.17 1 KUGLER MAAG CIE GmbHGTB® Certified Automotive Softwaretester München 27.02.17 2 ISARTAL akademie GmbHAgile in Automotive (deutschsprachig) Kornwestheim 07.03.17 2 KUGLER MAAG CIE GmbH360° Testautomatisierung Wien 07.03.17 2 ANECONTTCN-3 Training "Theory and Practice of TTCN-3" Berlin 13.03.17 1 Spirent Technologies GmbHAutomotive System Design nach ISO 26262 - TÜV Functional Safety Engineer ohne Prüfung (deutschsprachig) Kornwestheim 14.03.17 3 KUGLER MAAG CIE GmbH

Automotive System Design nach ISO 26262 - TÜV Functional Safety Engineer mit Prüfung (deutschsprachig) Kornwestheim 14.03.17 4 KUGLER MAAG CIE GmbH

Automotive SPICE® - iNTACS™ zertifizierter Provisional Assessor (deutschsprachig) Kornwestheim 27.03.17 5 KUGLER MAAG CIE GmbH

Seminare 2017Januar - März 2017

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

STA

ND

: Nov

emb

er 2

016

S O F T WA R E T E S T I N G

P R O D U C T M A N A G E R M E D I C A L W E I T E R E A N G E B O T E

U S A B I L I T Y S P E C I A L I S E D

R E Q U I R E M E N T S E N G I N E E R I N G S E C U R I T Y M O B I L E

P R O J E C T M A N A G E M E N T

A G I L E



IREB® Certified Professional for Requirements Engineering – Advanced Level, Requirements Management

München 29.03.17 3 Methdo Park Consulting GmbH

ICPMSB Certified Professional for Medical Software



UXQB® Certified Professional for Usability and User Experience, Foundation Level

Köln 13.03.17 3 ProContext Consulting GmbH

UXQB® Certified Professional for Usability and User Experience - Advanced Level, User Requirements Engineering

Köln 13.03.17 4 ProContext Consulting GmbH

Sonstiges


ANZEIGE

Das ASQF-KarriereportalWir haben den passenden Job für Sie!

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

Testmanager (m/w)netcare Business Solutions GmbH

Frankfurt oder Neustetten

Testspezialist (m/w)G. Muth Partners GmbH

Wiesbaden

Softwareentwickler (m/w) Medizintechnik

CORSCIENCE GmbH & Co. KGErlangen

Senior IT Enterprise Architect (m/w)VON ESSEN GmbH & Co. KG

Erlangen

IT & Process Support Specialist (m/w)netcare Business Solutions GmbH

Neustetten

Softwaretester / Mitarbeiter IT Quali-tätssicherung (m/w)

affilinet GmbHHannover

Consultant: Software Tester / Testautomatisierung (m/w)

Qytera Software Testing Solutions GmbH Eschborn

Senior Software Quality Engineer (m/w)

TecAlliance GmbH Ismaning

Software Tester (m/w)Panasonic AVC Langen

Langen

Testingenieur / System Test Engineer (m/w)

CORSCIENCE GmbH & Co. KGErlangen

Software Tester - Quality Assurance

beQualified GmbH Köln

Technical Software Tester (m/w) im Bereich Testautomatisierung & Last-

und Performance Testsnetcare Business Solutions GmbH

Neustetten

Senior IT Enterprise Architect (m/w)VON ESSEN GmbH & Co. KG

BankgesellschaftEssen

Junior / Senior Softwaretester (m/w)OMNINET GmbH

Eckental

(Senior) Testmanager/-in (m/w)ckc group

Braunschweig

Consultant: Software Tester – Testma-nagement/ Software Testmanager (m/w)

Qytera Software Testing Solutions GmbHEschborn

Webentwickler C# / ASP.NET (m/w)iucon GmbHHattingen

Hier könnte Ihre Anzeige stehen!

Schreiben Sie uns unter [email protected]

iSQI NEWS

Aus dem iSQI-Konferenzplaner 2017


Die Start-up-Metropole Berlin be-kommt tatkräftige Unterstützung. An-getrieben vom erfolgreichen Start im vergangenen Jahr, legt die Start-up-Förderinitiative „HIGHFIVE powered by iSQI“ nun mit einer eigenen Fir-mengründung namens High 5 – The Startup Booster nach. Ziel ist es, jun-ge Unternehmen noch intensiver als bisher zu unterstützen. „Wir planen unter anderem, bei viel-versprechenden Gründungen finan-ziell zu investieren“, erklärt Stephan Goericke, Geschäftsführer der neuen High5 GmbH, die ihren Sitz im Sony Center in Berlin hat. Mit High5 setzt das Potsdamer Inter-national Software Quality Institute, Träger der Förderinitiative HighFive, seinen erfolgreichen Kurs fort. Die neue Niederlassung in Berlin ist ein konsequenter Schritt nach vorn. „Da-mit können wir gezielt vor Ort Start-

iSQI gründet Start-up-Booster High5

Das International Software Quality In-stitute (iSQI) hat im Oktober eine Ko-operationsvereinbarung mit dem Uni-ted Kingdom Testing Board (UKTB) für die Zertifizierung des Certified Mobile Application Professional (CMAP) un-terzeichnet. Das UKTB ist das offizielle britische ISTQB® National Board und akkreditiert die ISTQB® Ausbildung und das Zertifizierungsschema.CMAP wurde von einer iSQI Special Interest Group entwickelt, die sich aus internationalen Test-Experten zusam-mensetzt. Der Standard wurde von mehreren der ISTQB® National Boards und Exam Provider weltweit angenom-men und verabschiedet.Debbie Archer, Managing Director der iSQI Ltd, sagt zu dem Kooperati-onsvertrag: „CMAP hat sich zu einem weltweiten Standard im Bereich mobi-

ups im Bereich Mitarbeiteraus- und -weiterbildung beraten und fördern“, erklärt Stephan Goericke, „Erfah-rungsgemäß ist neben finanzieller Sicherheit, eine vorausschauende, nachhaltige Personalentwicklung der Erfolgsfaktor für Start-ups. Wer hier nicht frühzeitig ansetzt, vergibt viele Chancen und gerät schnell ins Ab-seits. Deshalb unterstützen wir mit High5 insbesondere die Weiterbil-dung und unabhängige Zertifizierung von (IT)-Fachkräften.“ Mehrere deutsche Start-ups hat die Initiative bereits erfolgreich unter-stützt, u.a. bei der weltgrößten Digi-talmesse South by South West oder durch die eigene Beteiligung an der Bits&Pretzels sowie der re:publica.

CMAP in Großbritannien

UKTB und iSQI kooperieren

ler Applikationstests entwickelt und ist bereits im Vereinig ten Königreich mit ausgezeichnetem Feedback von Einzel-personen und Organisationen etabliert – wir freuen uns, dass das UKTB CMAP anerkannt hat und wir diese Vereinba-rung auf der ISTQB®-Vollversammlung in Seoul unterzeichnet haben.“Geoff Thompson, Vorsitzender des UKTB, begrüßt die Vereinbarung eben-falls und sagt: „Dies ist ein spannender Schritt vorwärts für die britische Soft-ware-Test-Community. iSQI ist ein vom UKTB zugelassener Prüfungsan-bieter für ISTQB® Prüfungen in Groß-britannien und die Zusammenarbeit zur Förderung von CMAP hier wird ein enormer Vorteil sein.“

05. - 09.12.2016Agile Testing Days // Potsdam

07.12.2016ASQF Quality Day // Berlin

07.12.2016SIGIST Winter Conference // London

17.01. - 20.01.2017 Software Quality Days // Wien

30.01. - 03.02.2017 OOP GTB Gemeinschaftsstand // München

27.02. - 28.02.2017UKStar // London

10.03. -19.03.2017SXSW // Austin

20.03. - 22.03.20177th World Congress for Software Quality // Lima

252525

Die TMMi® (Test Maturity Model Inte-gration) Foundation hat das Internati-onal Software Quality Institute (iSQI) zum exklusiven Prüfungsanbieter für die Zertifizierung zum TMMi® Profes-sional ernannt.„iSQI bietet TMMi® Foundation-Prü-fungen seit Mai 2013 an. Es unterstützt damit das Wachstum des Programms und bietet für die (TMMi®-)Stiftung, Schulungsanbieter und Einzelper-sonen ein Höchstmaß an Servicequa-lität und unabhängiger Validierung von Zertifizierungen. Die exklusive Partnerschaft mit iSQI ist ein weiterer positiver Schritt zur Unterstützung der nächsten Wachstumsphase des Pro-gramms“, erklärt Les Murray, Chair-man des TMMi® Foundation Board of Directors.TMMi® Professional Certification eig-net sich für alle, die ein Verständnis des TMMi®-Modells und die damit verbundene Verbesserung von Test-prozessen entwickeln wollen. Inhaber des TMMi® Professional Certificate

Das Kuratorium des Fraunhofer In-stitut für offene Kommunikationssy-steme (FOKUS) hat Stephan Goericke, Geschäftsführer des Potsdamer In-ternational Software Quality Institute (iSQI GmbH), zu seinem neuen Mit-glied berufen. Der 43-jährige wird in den kommenden Jahren gemeinsam mit hochrangigen Vertretern aus Po-litik, Wirtschaft und Wissenschaft das Fraunhofer FOKUS bei der strate-gischen Ausrichtung beraten. FOKUS erforscht fortgeschrittene Technologien für eine barrierefreie Kommunikations-Infrastruktur. Es ent-wickelt städtische IT-Infrastrukturen und berät die Industrie, öffentliche

TMMi®-Zertifizierungen iSQI ist exklusiver Prüfungsanbieter

erwerben das erforderliche Wissen, welches Voraussetzung für den Er-werb eines akkreditierten TMMi®-Lead-Assessors oder Assessors ist.iSQI-CEO Stephan Goericke freut sich über die Ernennung seines In-stituts zum exklusiven Prüfungsan-bieter: „Wir schätzen es sehr, mit der TMMi® Foundation als exklusiver Prü-fungsanbieter zusammenzuarbeiten.

Stephan Goericke zum Kurator des Fraunhofer Institut FOKUS berufen

Verwaltungen und Organisationen bei der Konzeption und Umsetzung ihrer IT-Strategien. Mit rund 500 Mit-arbeitern ist es eines der größten Fraunhofer-Institute.„Ich bedanke mich für das entgegen-gebrachte Vertrauen und freue mich auf viele spannende Projekte!“, erklär-te das neue Kuratoriumsmitglied Ste-phan Goericke. Goericke gilt als ausgewiesener Ex-perte in der international standar-disierten Ausbildung und Zertifizie-rung von IT-Fachkräften. Bereits seit 2005 leitet er als Geschäftsführer das weltweit tätige International Soft-ware Quality Institute mit Hauptsitz

Die Verbesserung der Testprozesse ist ein wesentlicher Bestandteil der Software-Entwicklung und kann letzt-endlich dazu beitragen, den Erfolg ei-ner Organisation zu unterstützen. Die TMMi®-Zertifizierung hilft Menschen und Unternehmen, sicherzustellen, dass sie die Möglichkeit haben, effi-zientere und effektivere Testprozesse anzubieten.“

in Potsdam (DE) und Niederlassungen in Amstelveen (NL), London (UK) und Boston (USA).

Best Practice

Traurig, aber wahr: Usability war für Unterneh-mens-Anwendungen, die in den 2000er Jahren entwickelt wurden, das Letzte, worum sich die Entwickler Gedanken machten. Meist ging es nur darum, einen bestehenden manuellen Pro-zess per Applikation zu unterstützen. 30 Jahre später werden viele Business- Anwendungen noch immer auf diese Art und Weise konzipiert und entwickelt. Von Mobile First weit und breit keine Spur, die Unterstützung des Anwenders bei Digitalisierungs- Aspekten (Digital Transfor-mation) bleibt auf der Strecke.

Es ist nicht immer möglich Anwendungen „Mo-bile First“ zu realisieren. Trotzdemw ist es sinn-voll, Anwendungen aus der Desktop- Welt in die Mobile Welt („Mobile Ready“) zu portieren. Oft reicht es, nur die wichtigsten Geschäftsfälle zu berücksichtigen. Im Zuge der Digitalisierung genügt es aber nicht, nur die IT- Abteilung umzu-bauen und fit für die neuen Herausforderungen zu machen. Auch die IT- Anwendungen müssen diesen neuen Herausforderungen gerecht wer-den. Schließlich muss die IT- Abteilung gemein-


sam mit den anderen Fachbereichen fachlich und technisch integrierte Gesamtlösungen defi-nieren und in die IT- Systeme einsteuern. Dieser Artikel beschreibt, wie Cisco ServiceGrid IT (CSG- IT) die Usability einer 20 Jahre alten Web- Anwendung verbessern und „Mobile Rea-dy“ machen konnte.

Situation

Cisco ServiceGrid ist der weltweite Markt-führer für die Synchronisation von „IT Service Management“-Systemen. Vor allem große Fir-men haben die Betreuung ihrer IT ausgelagert, verwenden aber trotzdem Software zur Ver-waltung ihrer ITIL-Prozesse wie Incident- oder Change- Management. Service-Lieferanten, die diese IT -Systeme betreuen, benötigen ebenfalls Software, um die Service Requests zu verwal-ten. Cisco ServiceGrid vereinfacht die Synchro-nisierung dieser Systeme, erhöht die Transparenz und ist ein neutraler Messpunkt zur Beurteilung der SLA-Erreichung.

Wenn die Digitalisierung die Usability herausfordert

Service Definition im neuen Design - Mobile Ready

von Rudolf Grötz & Joachim Niederreiter

272727

Die grafische Benutzeroberfläche von Cisco Ser-viceGrid (CSG) war nicht mehr auf der Höhe der Zeit. Das Layout und die abgebildeten Abläufe waren umfangreich konfigurierbar und flexibel, aber im Sinne einer „gewachsenen“ Anwen-dung wurde Funktionalität über Jahre nur hin-zugefügt. Die Usability wurde nicht ausreichend berücksichtigt, speziell in Bezug auf mobile End-geräte. Diese Versäumnisse kamen zutage, als es nach Jahren der klassischen Optimierung für Desktop-Webbrowser notwendig wurde, die Ap-plikation für Tablets verfügbar zu machen. Um eine gute Usability auf mobilen Endgeräten zu ermöglichen, musste nicht nur die Benutzer-schnittstelle angepasst werden. Es war auch notwendig, die wichtigsten Geschäftsprozesse der Anwendung an die Arbeitsweise der Ziel-gruppe (IT- Administratoren) anzupassen. Folgende Anforderungen galt es bei der Umset-zung zu berücksichtigen:

Rückwärtskompatibilität der bestehenden Backend- Funktionalität,

keine Beeinträchtigung der Release-Zyklen der bestehenden Legacy- Applikation,

keine Beeinträchtigung der laufenden Ent-wicklungsprojekte der Legacy- Applikation,

Berücksichtigung von iOS und Android-Tablets,

Fast Feedback durch einen zweiwöchigen Release-Zyklus,

Power- User (Admin) müssen ihre Geschäfts-prozesse schneller bedienen können,

die Benutzeroberfläche muss den Workflow unterstützen und nicht umgekehrt.

weiter auf der nächsten Seite

Für die Umsetzung all dieser Anfor-derungen waren neue Herangehens-weisen notwendig. Die Einführung neuer Architekturansätze, Design- Paradigmen und Rollout- Strategien war unabdingbar. Vor allem im Bereich Usability Engineering musste CSG- IT neue Wege gehen und versuchte ei-nen Ansatz via User- Centered Design.CSG- IT verbrachte eine beträchtliche Menge Zeit vor dem Zeichenbrett, um die bestehenden Anwendungsab-hängigkeiten zu verstehen, bevor die neuen und innovativen Ansätze einge-führt werden konnten.

Folgende Grundsätze für die Entwick-lung wurden definiert:

die Gestaltung beruht auf einem umfas-senden Verständnis der Benutzer, Ar-beitsaufgaben und Arbeitsumgebungen,

die Benutzer sind während der Gestaltung und Entwicklung einbezogen,

das Verfeinern und Anpassen der Lösung geschieht fortlaufend auf

Basis von Evaluierungen,

der Prozess ist iterativ,

im Team sind fachübergreifende Kennt-nisse und Perspektiven vertreten.

Die Projektanforderung bestand in der Implementierung eines neuen Produkts mit dem Namen Cisco Ser-viceGrid Connector, kurz Connector (CONN). Die Lösung bestand aus der Implementierung neuer APIs, die die Backend- Funktionen abstrahieren und einem neuen GUI, welches auf diesen APIs aufsetzt. Außerdem wurde ent-schieden, den Anwendern CONN als Minimum Viable Product1 zur Verfü-gung zu stellen und alle zwei Wochen mit Neuerungen zu erweitern.

Usability-Anforderungen

Die Anforderungen an die Benutzero-berfläche haben sich in den letzten Jahren stark verändert. Sie sind mitt-

lerweile eine der wichtigsten Heraus-forderungen bei der Gestaltung einer modernen Applikation. So können beim Redesign, bis hin zu einer mo-bilen Anwendung, die Prinzipien und das bestehende Layout der Desktop-Version nicht einfach in die mobile Welt übertragen werden.CSG- IT musste neue Wege beschrei-ten, um diesen Herausforderungen begegnen zu können. User- Centered Design, Contextual Inquiry, Fokus-Gruppen und UX- Prototyping sind nur einige der Schlagworte, auf die im Fol-genden eingegangen wird.Wichtigstes Ziel war es, den Benutzer in den Mittelpunkt der Anforderungen zu stellen und durch den Einsatz neuer Methoden und Techniken sicherzustel-len, dass die User Experience den Er-wartungen der Benutzer gerecht wird. Im Ergebnis enstand eine Benutzero-berfläche, die komfortabler, bequemer und intuitiver zu bedienen ist.

Contextual Inquiry (CI)

Contextual Inquiry ist ein benutzer- zentrierter Ansatz, um die Anforde-rungen an die Benutzerschnittstelle zu erforschen. Interviews sind nicht geeignet, um implizites Wissen ab-zurufen, deshalb wird bei Contextual Inquiry der Benutzer bei seiner Arbeit beobachtet. Parallel dazu werden mit ihm die Tätigkeiten und Abläufe im Kontext diskutiert.Im Rahmen von CI wurden u.a. fol-gende Sichten der Anwender betrach-tet: Rollenteilung und Kommunikation, Handlungsstrategien und Vorgehen, kulturelle und soziale Einflüsse und das physische Umfeld. Danach wur-den auf Basis dieser Informationen die Nutzerführung und die notwendi-gen Funktionen des neuen Systems erarbeitet.

Fokus-Gruppen

Mit Unterstützung sogenannter Fo-kus-Gruppen wurden die Benutzer in den einzelnen Projektphasen zu ihren Anforderungen an die grafische Ober-

Ausgabe 41 | Dezember 2016 28Best Practice

fläche befragt. Es wurden Meinungen eingeholt, Wünsche und Bedürfnisse dokumentiert. In offenen Diskussi-onen innerhalb kleiner Gruppen wur-den folgende Fragen erörtert:

Wie kommen die Benutzer mit dem derzei-tigen Produkt zurecht, was ist ihre subjek-tive Meinung?

Wie wird es aktuell genutzt und einge-setzt, welche Schwierigkeiten treten da-bei auf?

Falls es mehrere Lösungsvarianten inner-halb der grafischen Oberfläche gibt, wel-che Variante bevorzugen die Nutzer?

Was gefällt besonders und sollte daher beibehalten werden?

Interaction Design (ID)

Mit dem Interaction Design werden alle Arten der Interaktion definiert, dazu gehören, das Verhalten des Sys-tems, die Möglichkeiten es zu steu-ern. Hierzu gehört auch die Rückmel-dungen an den Benutzer.Die Erkenntnisse aus den Fokus-Grup-pen wurden anschließend mit Metho-den aus dem Interaction Design auf-gearbeitet. Nachdem das für CSA Neuland war, wurden externe Spezia-listen in das Scrum- Team aufgenom-men. Das ID hat seinen eigentlichen Ursprung im Web- und Grafik- Design, und hat sich daraus ständig weiterent-wickelt. Interaction Designer sind weit davon entfernt, nur mit Texten und Grafiken zu arbeiten. Sie sind verant-wortlich dafür, jedes Element auf dem Bildschirm zu kreieren, mit dem der Benutzer agiert.

Personas

Personas sind prototypische Benutzer in Bezug auf das zukünftige Produkt. Ihre Definition erfolgt aufgrund ange-nommener Ziele und Verhaltenswei-sen im Kontext des Produkts.Im vorliegenden Fall entwarf der Pro-duct Owner Vorschläge und validierte diese gemeinsam mit dem Team, um

292929

Rudolf Grötz ist Engi-neering Manager bei CISCO ServiceGrid Austria und verant-wortlich für den Be-reich Software Test.

Joachim Niederreiter ist Senior Engineering Manager bei CISCO ServiceGrid Austria.

festzustellen, ob diese die für das Pro-duktdesign relevanten Eigenschaf-ten der Benutzer widerspiegelten. Personas wurden erstellt, um zum Zeitpunkt der Entwicklung der Benut-zerschnittstelle die richtige Design- Entscheidungen treffen zu können.

Szenarien

Szenarien beschreiben anhand realis-tischer Beispiele in einfachen Sätzen oder mittels Kärtchen an einer Pinn-wand, wie ein Benutzer mit dem ge-planten System interagieren wird. Es geht dabei stärker um inhaltlich rich-tige Aussagen als um formale Korrekt-heit, ähnlich wie bei Personas. Szena-rien können interaktiv entwickelt oder in Workshops gemeinsam mit den Be-nutzern erarbeitet werden. Durch ihre hohe Verständlichkeit erleichtern sie die Zusammenarbeit zwischen Benut-zern und Entwicklern in den Bereichen Erhebung und Validierung von Anfor-derungen, Spezifikation, Testszenari-en und Schulung.

Benutzerperspektive

Im Anschluss verwendete das Pro-jektteam die Personas und Szenarien, um aus deren Blickwinkel das System zu betrachten. Die Diskussionen wur-den dadurch aus der Sicht der Perso-nas und nicht aus eigener Erfahrung geführt. Damit änderte sich auch der Inhalt der Diskussionen in den Work-shops, er wurde objektiver. Im näch-sten Schritt war es dann leichter, für jede Benutzergruppe die passende Benutzerschnittstelle zu entwerfen. Das Produktmanagement begann zu-sätzlich etwaige Konkurrenzprodukte zu evaluieren und auch dort gewon-nene Erkenntnisse einzubringen.

UX- Prototyping

Für den eigentlichen Entwurf der Benutzerschnittstelle, wurde UX- Prototyping eingesetzt.Im ersten Schritt wurden die grund-legenden Ideen auf Papier skizziert.

Dieser Entwurf beinhaltete neben den Ausgangselementen auch grobe Design- Elemente.Anschließend wurden diese Skizzen mit Wireframes konkretisiert und spezifiziert. Der Fokus lag auf den fol-genden Fragen:

Was sind die wichtigsten Gruppen von In-halten?

Wo liegt die Struktur der Daten?

Wie sieht die grundlegende Visualisierung der Benutzer- Schnittstelle und der Inter-aktion aus?

Aus den Wireframes entstanden dann High- Fidelity- Mockups. Diese wur-den „pixelgenau“ erstellt, um den Frontend- Entwicklern das Umsetzen im Code zu erleichtern.

Usability-Tests

In Usability- Tests wurde die neu er-stellte Benutzeroberfläche von ausge-wählten, realen Anwendern getestet, um verifizieren zu können, wie einfach die Anwendung schlussendlich zu be-dienen ist.Die Anwender mussten Aufgaben (Szenarien) erledigen, während sie von Usability Engineers und dem Product Owner beobachtet wurden. Dabei wurden auch Fragen beantwor-tet, wie „brauchbar“ oder „intuitiv“ die Anwendung empfunden wird, bzw. wie einfach es ist, vorgegebene Use- Cases erfolgreich abzuschließen. Der wichtigste Unterschied zwischen Usability- Tests und traditionellen Tests besteht darin, dass Usability- Tests mit den tatsächlichen Benutzern oder Kunden des Produkts erfolgen, während traditionelle Tests durch ei-nen Entwickler oder Designer vorge-nommen werden. Fazit

Das Ziel von User- Centered Design ist eine möglichst hohe Gebrauchs-tauglichkeit (Usability) des neuen

Produkts. Im Mittelpunkt steht der künftige Nutzer, seine Ziele, seine Auf-gaben und seine Eigenschaften. Ein Prototyping Workshop gemeinsam mit Anwendern und Entwicklern mag unkonventionell erscheinen, die auf-gewendete Zeit wird aber durch den Gewinn an wertvollen Einsichten und Erkenntnissen mehr als aufgewogen. Im weiteren Verlauf des Projekts kön-nen dann Zeit und Kosten gespart und die Akzeptanz der Benutzer erhöht werden.Im Rahmen von User- Centered De-sign finden neue, nutzerorientierte Vorgehensmodelle, wie Contextual Inquiry für die Business-Analysen und Fokus-Gruppen-Verwendung. Für die Modellierung und Spezifikation kom-men neue Ansätze wie Interaction Design, Personas, Szenarien und UX- Prototyping zum Einsatz.

Titelthema

Usability und User Experience ein neues Verständnis für Qualität


von Thomas Geis

313131

W as genau verstehen wir unter „User Experience“? Und wie

unterscheidet sich User Experience von Usability? Eines steht fest: Un-ternehmen, die IT-Systeme mit hoher Usability und User Experience her-stellen, haben Erfolg.

Qualität = Nutzungsqualität x tech-nische Qualität

Der Begriff Qualität ist unstrittig. Je-des nachhaltig agierende Unterneh-men, stellt die Qualität seiner Pro-dukte und Dienstleistungen in den Mittelpunkt der Entwicklung. Doch bereits hier ist die Betrachtung von Usability und User Experience wich-tig. Neue ISO-Standards unterschei-den zwischen Nutzungsqualität (Hu-man-centred quality) und technischer Qualität (technology-centred quality).

Hersteller, die die technische Qualität ihrer Produkte im Griff haben, haben deswegen noch lange nicht die Nut-zungsqualität im Griff.

Nutzungsqualität beschreibt alle Di-mensionen, die Käufer und Benutzer von Produkten aktiv wahrnehmen. Hierzu gehören:

Usability (dt. Gebrauchstauglichkeit)

Accessibility (dt. Barrierefreiheit)

User Experience (dt. Benutzererlebnis)

Avoidance of use-related risks (dt. Freiheit von Risiken, die aus der Nutzung resultie-ren können)

Technische Qualität wiederum be-schreibt alle Dimensionen von Pro-

Usability als Voraussetzungfür User Experience

Der Begriff „Usability“ (dt. Gebrauchs-tauglichkeit) hat in der Produktent-wicklung bereits eine längere Historie als der Begriff „User Experience“. Usability ist keine Frage des persön-lichen Geschmacks. Die DIN EN ISO 9241-11 definiert Usability als „das Ausmaß, in dem ein Produkt durch bestimmte Nutzer in einem bestimm-ten Nutzungskontext genutzt werden kann, um bestimmte Ziele effektiv, effizient und zufriedenstellend zu er-reichen“.

Effektiv heißt hierbei „die Genauigkeit und Vollständigkeit, mit der Benutzer ein be-stimmtes Ziel erreichen“

Effizient heißt hierbei „der im Verhältnis zu Genauigkeit und Vollständigkeit ein-gesetzte Aufwand, mit dem Benutzer ein bestimmtes Ziel erreichen“

Zufriedenstellend bedeutet „Freiheit von Beeinträchtigungen und positive Einstel-lung gegenüber der Nutzung des Produkts“

duktqualität, die die Voraussetzung für Nutzungsqualität sind. Hierzu gehören:

Funktionale Angemessenheit

Performanz

Kompatibilität (mit anderen Produkten)

Zuverlässigkeit

Security

Wartbarkeit

Portierbarkeit

Nutzungsqualität ist also mehr als Usability und User Experience, sie wird aber durch diese beiden Dimen-sionen maßgeblich geprägt.

Soweit, so gut. Im Grunde genom-men können Benutzer mit den mei-sten Produkten das gewünschte Ziel genau und vollständig erreichen. Das eigentliche − nach wie vor bestehende − Problem bei der Benutzung von Pro-dukten ist der eingesetzte Aufwand, den der Benutzer betreiben muss, um zum eigentlichen Ziel zu kommen. Das heißt, die mangelnde Effizienz macht dem Benutzer in der Regel zu schaf-fen. Die Konsequenz: Unzufriedenheit mit der Benutzung des Produkts und – im gewerblichen Kontext – hohe Ko-sten für ineffizientes Arbeiten…Aber welche Faktoren sind es, die die Benutzung eines Produkts gezielt effi-zient machen und aus Nutzersicht „in-tuitiv“? Auch hier gibt es eine Norm, die DIN EN ISO 9241-110, die die so-genannten „Grundsätze der Dialog-gestaltung“ beinhaltet sowie über 50 Empfehlungen für deren Umsetzung. Sieben Faktoren bestimmen maßgeb-lich die effiziente Nutzung eines Pro-dukts.

Effizienz aus Benutzersicht wird pri-mär erreicht durch:

Aufgabenangemessenheit Keine überflüssigen Schritte, keine

irreführende Information.

Selbstbeschreibungsfähigkeit Genau die Information, die für einen

bestimmten Schritt erforderlich ist, ist auch vorhanden.

Erwartungskonformität Das System reagiert immer mit ge-

nau der Information, die aus Sicht der Aufgabe auch tatsächlich „zu erwarten“ ist.

Lernförderlichkeit Das Produkt ist auf der Basis des

Wissens über die Aufgabe unmittel-bar benutzbar, es ist keine Schulung erforderlich.

Steuerbarkeit Der Benutzer kann bei der Erledi-

gung seiner Aufgabe konsequent in die Richtungen gehen, die aus Sicht der Aufgabe erforderlich sind (ohne Umwege und „Neueinstieg an ande-rer Stelle“).

Titelthema

Fehlertoleranz Der Benutzer wird vom System vor

Fehlern geschützt, beziehungswei-se, wenn der Benutzer Fehler ge-macht hat, kann er diese mit mini-malem Aufwand beheben.

Individualisierbarkeit Der Benutzer kann das User Inter-

face selbst anpassen und individu-elle Voreinstellungen treffen, die seinen physischen Gegebenheiten gerecht werden (z.B. Schriftgröße) oder Spezifika seines Kontextes be-rücksichtigen (z.B. bestimmte Def-ault-Einstellungen).

User Experience im Unterschied zu Usability

Zunehmend wird in Entwicklungs-projekten nicht nur über „Usability“ diskutiert, sondern auch über „User Experience“. Aber seien wir ehrlich, so richtig weiß keiner, was der Un-terschied ist, oder? Fragt man Betei-ligte in Projekten, die beide Begriffe verwenden, was der Unterschied sei, so gibt es ein ganzes Spektrum an − mehr oder minder befriedigenden − Antworten. Auch wagt man sich kaum, den Begriff „User Experience“ ins Deutsche zu übersetzen.User Experience ist seit kurzem als genormter Begriff in der DIN EN ISO 9241-210 „Prozess zur Entwicklung ge-brauchstauglicher interaktiver Syste-me“ enthalten und wie folgt definiert:User Experience (Benutzererlebnis): Wahrnehmungen und Reaktionen ei-

ner Person, die aus der tatsächlichen und/oder der erwarteten Benutzung eines Produkts, eines Systems oder ei-ner Dienstleistung resultieren.

Abbildung 1 illustriert den Zusam-menhang zwischen Usability und User Experience. Platt gesagt be-trachtet „Usability“ die tatsächliche Nutzungssituation selbst, während „User Experience“ darüber hinaus die antizipierte Nutzung und die Verarbei-tung der Nutzungssituation nach der Nutzung miteinschließt.

Grundsätzlich lässt sich sagen, dass Käufer von Produkten sich vor dem Kauf eines Produkts die Nutzung des Produkts vorstellen. Es findet also ein Usability-Test im Kopf des po-tentiellen Käufers statt. Wenn das Produkt hierbei „durchfällt“, weil be-stimmte Aspekte der Gestaltung aus Nutzersicht hinderlich eingeschätzt werden, dann wird das Produkt eben eher nicht gekauft, auch wenn es sich

in der Nutzung als gebrauchstauglich erweist. So lässt sich auch z.B. der Misserfolg vieler Universalfernbedie-nungen erklären, die beim bloßen Be-trachten in der Plastikhülle im Laden den Eindruck erwecken, als hätte man mit der Universalfernbedienung noch größere Probleme als mit den drei bis vier Fernbedienungen, die bereits auf dem Wohnzimmertisch liegen.

Fallbeispiel Online Check-In

Ist Usability und User Experience be-reits eine Selbstverständlichkeit bei IT-Systemen? Die Antwort lautet nein. Man denke nur an die ERP-Systeme großer Software-Hersteller bei denen der Benutzer täglich das Gegenteil von „Selbstbeschreibungsfähigkeit“ und „Aufgabenangemessenheit“ er-lebt. Aber auch simple Aufgaben wie der Check-In bei Fluggesellschaften erfordern Methodiken der Anforde-rungsanalyse aus Benutzersicht und der User-Interface-Konzeption, um


Thomas Geis ist Geschäftsführer der ProContext Consulting GmbH.

333333

einerseits „usable“ zu sein und an-dererseits hohe User Experience zu erreichen, sprich positive Wahrneh-mungen und Reaktionen beim Benut-zer.Schauen wir uns als Beispiel eine App zum „Online Check-In“ für Flugreisen-de an. Zahlreiche Flugreisende che-cken sich bereits online zu ihren Flü-gen ein, um einerseits den Gang zum Check-In-Schalter am Flughafen zu vermeiden und andererseits in letzter Minute am Flughafen auch noch Flüge zu erwischen, die bereits „geschlos-sen“ sind. Der typische Ablauf ist so, dass der Fluggast von seiner Flugge-sellschaft rechtzeitig eine E-Mail erhält mit einem Link auf die Check-In-Mög-lichkeit. Klickt der Benutzer auf den Link gelangt er zur App für den Online Check-In. Abbildung 2 veranschaulicht den Ablauf eines Online Check-In. Der Fluggast loggt sich ein (1), erhält dann eine Übersicht über seine Flugdaten (2) − und dann... ?(3)Führt man einen Usability-Test mit der abgebildeten App durch, so ist die Wahrnehmung der meisten Benutzer beim Erreichen des Bildschirms (3), dass der Flug noch nicht zum Check- In bereitsteht. Die typische Reaktion der Benutzer ist, dass sie sich von der Flug-gesellschaft „verschaukelt“ fühlen, da zunächst die Information kommt, man könne sich einchecken, es dann aber (augenscheinlich) gar nicht geht. Die-ses negative Benutzererlebnis (User Experience) beruht auf einem Usabili-ty-Problem. Die Anzeige im Bildschirm (3) „Diesen Flug können Sie erst 72h vor Flugantritt einchecken.“ bezieht sich auf den Rückflug. Dies ist jedoch für den Benutzer nicht ohne weiteres erkennbar (Selbstbeschreibungsfähig-keit).Die Illustrationen in Abbildung 2 zeigen nur einen kleinen Ausschnitt aus einem insgesamt nicht aufgabenangemes-senen, nicht selbstbeschreibenden und nicht erwartungskonformen Ab-lauf aus Benutzersicht, der in Summe zu negativer User Experience führt und den Online Check-In in seiner Lei-stungsfähigkeit entwertet.

Abbildung 1: User Experience und Usability unterscheiden

Abbildung 2: Startbildschirm zum Online Check-In

Positive User Experience erfordert qualifiziertes Personal

Unternehmen, die es ernst meinen mit der Nutzungsqualität ihrer Produkte, investieren zunehmend in die Qualifi-kation derjenigen Mitarbeiter, die beim Herleiten der Nutzungsanforderungen, der Konzeption der User Interfaces und dem Testen der Usability Hand anle-gen. So ist es nur folgerichtig, dass es inzwischen die Personenzertifizierung „Certified Professional für Usability und User Experience“ (CPUX) gibt, die vom International Usability and User Experience Board (UXQB) betrieben wird. Folgende Zertifizierungen wer-den aktuell angeboten:

Certified Professional für Usability und User Experience – Foundation Level (CPUX-F)

Advanced Level “User Requirements Engineering“ (CPUX-UR)

Advanced Level “Usability Testing and Evaluation” (CPUX-UT)

Das aktuelle Angebot für vorberei-tende Trainings der anerkannten Trai-ningsanbieter des UXQB ist zu finden unter http://uxqb.org/de/vorbereitende-trainings/trainingskalender.

Im Fokus

Kann eine erweiterte Fault Seeding Methode die Fehlerfindungsrate stei-gern und zu einem geringerem Rest-risiko beitragen? Diese Frage wid-mete sich Michael Altmann in seiner Masterarbeit „Weiterentwicklung der Fault Seeding Methode zur Steige-rung der Testeffizienz“, die er unter der Leitung von Dr. Mohsen Ekssir an der Fachhochschule Wiener Neu-stadt in Österreich verfasste. Altmann setzte sich hierzu ausführlich mit der Fault Seeding Methode auseinander. Im Rahmen eines Entwicklung- und Testprojekts bei dem Unternehmen TechTalk wurden die theoretischen Annahmen in der Praxis überprüft. Die Steigerung der Testeffizienz ist ein Thema, dem schwer Grenzen gesetzt werden können, denn viele

Hebel und Ansätze sind vorhanden, mit denen ein Testmanager die Effi-zienz verbessern kann. Wie aber die Testeffizienz gemessen wird und wel-che Faktoren dabei eine Rolle spielen, kann projekt abhängig unterschied-lich ausfallen. Generell treten bei den Testaufgaben und im Zuge des Testprozesses zwei große wichtige Fragen auf:

Wie hoch ist der aktuelle Fehlerentde-ckungsgrad und wie kann dieser erhöht werden?

Wie hoch ist die Restfehleranzahl, wie hoch sind die Restrisiken nach dem Testende und wie können diese reduziert werden?


Weiterentwicklung der Fault Seeding Methode zur Steigerung der Testeffizienzvon Dr. Mohsen Ekssir-Monfared & Michael Altmann MSc

353535

Fault Seeding Methode

Um den Fehlerentdeckungsgrad und die Restfehleranzahl zu ermitteln, kann die seit Jahrzehnten bekannte Methode Fault Seeding eingesetzt werden. Harlan Mills hat diese Metho-de entwickelt und im Jahr 1972 veröf-fentlicht [1, S. 442]. Das Problem dabei ist, dass das Fault Seeding Ergebnis lediglich für eine allgemeine Einschät-zung des aktuellen Standes des Feh-lerentdeckungsgrades und der Rest-fehleranzahl ausreicht. Grund dafür ist der sehr begrenzte Datenbestand, der zur Auswertung gewonnen wer-den kann. Der Datenbestand besteht bei Fault Seeding ausschließlich aus Daten, die Auskunft darüber geben, welche künstlichen Fehlerzustände von den Testsuites aufgedeckt wur-den und welche nicht. Diese Ergeb-nisse sind Ist-Zustandserhebungen und reichen bei weitem nicht aus, um die Testeffizienz zu erhöhen.

Fault Seeding ist eine Methode mit deren Hilfe zwei Software-Metriken ermittelt werden können: der Fehler-entdeckungsgrad (Information über die Test-Qualität) und die Restfehle-ranzahl (Information über die Soft-ware-Qualität). Nach dem Standardglossar der Test-begriffe des ISTQB®/GTB wird unter Fault Seeding das absichtliche Ein-fügen von künstlichen Fehlerzustän-den in eine Komponente oder ein System verstanden. Das Ziel ist, aus dem Anteil der aufgedeckten künst-lichen Fehlerzustände eine Schätzung über die verbliebenen Fehlerzustände abgeben zu können. Diese Methode kann in allen Teststufen eingesetzt werden.

Nach der Definition des ISTQB®/GTB ist ein künstlicher Fehlerzustand eine Manipulation des Originalquellcodes an einer bestimmten Position mit der Absicht, eine Fehlerwirkung zu verur-sachen. Die künstlichen Fehlerzustän-de können unterschiedlich eingebaut werden, wie z.B.:

Ersetzen eines arithmetischen Operators (+, -, *, /, usw.)

Ersetzen eines relationalen Operators (Vergleichsoperators) (>, <, >=, usw.)

Ersetzen eines logischen Operators (Lo-gisch Und, Logisch Oder, usw.)

Ersetzen eines Zuweisungsoperators (+=, -=, *=, /=, usw.)

Ersetzen einer Variable Einfügen einer Bomb-Anweisung (Produ-ziert einen Fehlerfall)

Ersetzen eines Parameters beim Metho-denaufruf

Entfernen eines Methodenaufrufs Ändern eines Zugriffsmodifikators (public, private, protected)

Ändern des Datentyps eines Parameters

Es ist von essentieller Wichtigkeit zu klären und zu bestimmen, in welchem Verhältnis die Fehler und welche Art von Fehlern in die Software injiziert werden sollen. Die Fehlerzustände für die Injizierung dürfen nicht frei erfunden werden. Diese zu bestim-men, ist aber ohne eine Vorstudie (Vorbereitungsphase) über die bisher gefundenen realen Fehler und deren Häufigkeitsverteilung nicht möglich. Deswegen ist die Phase der Fehlermo-dellierung besonders wichtig.

Die Erweiterung der Methode

Um die reale Fehlerverteilung auf Ba-sis gemeldeter Software-Fehler bei diesem Forschungsprojekt zu bestim-men, mussten zuerst die Software-Fehler, die im Zuge der Komponen-ten- und Integrationstests, gefunden wurden, nach mehreren Fehlertaxo-nomien klassifiziert werden. Da aber die bereits gefundenen Fehler nicht mit erforderlichen Informationen ver-sehen waren, wurden sie im ersten Schritt neu analysiert und mit wei-teren Informationen, wie Fehlerart, Schweregrad oder der Position im Code ergänzt. Dadurch konnten alle gemeldeten Software-Fehler nach den folgenden Fehlertaxonomien klassifiziert werden:

Fehlerart Fehlerhafte Interpretation der Anforde-rungen

Fehler im Kontrollfluss Fehler in der Berechnung Fehler in Klassen und Datentypen Fehler im Datenfluss/Objektzugriff Schnittstellenfehler Konfigurationsfehler

Schweregrad eines Fehlers Position im Code

Auf Basis der gesammelten Informati-onen wurden Häufigkeitsverteilungen nach den Fehlertaxonomien Fehlerart, Schweregrad und Position im Code erstellt. Dadurch bekam man ein sehr detailliertes Gesamtbild der realen Fehlerverteilung im System. Dieses gewonnene Gesamtbild der bishe-rigen realen Fehlerverteilung des Systems liefert das Fundament für das Design und die Modellierung der einzupflanzenden künstlichen Fehler-zustände. Diese erweiterte Fault Seeding Me-thode liefert mehr als zwei einzel-ne Zahlenwerte zur Beurteilung der Restfehleranzahl und des Fehler-entdeckungsgrades, und zwar den Fehlerentdeckungsgrad bzw. die Restfehleranzahl pro Klasse nach ausgewählten Fehlertaxonomien. Da die eingesetzte Fehlerklassifikation aus der Methode Orthogonal Defect Classification stammt, wurde die Wei-terentwicklung von Fault Seeding als „Orthogonal Fault Seeding“ bezeich-net. [2, S.442]

Orthogonal Fault Seeding-Methode

Die Vorgehensweise für die Durchfüh-rung der Orthogonal Fault Seeding Methode wurde, wie in Abbildung 1 dargestellt, in fünf Phasen unterteilt: PHASE 1

FEHLERMODELLIERUNG Diese Phase beinhaltete die Model-lierung der künstlichen Fehlerzu-stände, die später in die zu testende Software eingepflanzt wurden. Die-se Aufgabe wurde manuell durch-

geführt. Basis dafür war die reale Fehlerverteilung, die in der Vorbe-reitungsphase gewonnen wurde. Die Verteilung der künstlichen Fehler-zustände sollte demnach der realen Fehlerverteilung gleichen und die künstlichen Fehlerzustände durften sich nicht gegenseitig beeinflussen.

PHASE 2

FEHLERINJIZIERUNG In dieser Phase wurden die zuvor modellierten Fehlerzustände in die zu testende Software eingepflanzt. Die Anzahl der künstlich einge-pflanzten Fehlerzustände wurde als |Fseededtotal| bezeichnet.

PHASE 3

DURCHFÜHRUNG DER TESTS In dieser Phase wurden die bereits implementierten automatisierten Testfälle für Komponenten- und Integrationstest voll automatisiert durchgeführt. Das Ziel der Tests war die Aufdeckung von möglichst vielen künstlichen und realen Fehl-erzuständen.

PHASE 4

AUSWERTUNG Die durchgeführten Tests fanden eine bestimmte Anzahl von künstlichen Fehlerzuständen (|Fseededfound|). Wei-terhin wurde mithilfe der durchge-

führten Tests auch eine bestimmte Anzahl von realen Fehlerzuständen entdeckt (|Frealfound|). Die Relation der Anzahl der gefun-denen künstlichen Fehlerzustände zu der Gesamtanzahl der künst-lichen Fehlerzustände ist ein Indiz für den Fehlerentdeckungsgrad der Software-Tests.

PHASE 5

ANALYSE UND INTERPRETATION In dieser Phase wurden die ermit-telten Zahlen analysiert und inter-pretiert. Die relevanten Variablen, wie in Abbildung 2 dargestellt, sind:

|Fseededtotal| Gesamtzahl der künstlichen Fehlerzustände |Fseededfound| Anzahl der gefundenen künstlichen Fehlerzustände |Frealtotal| Gesamtzahl der realen Fehlerzustände |Frealfound| Anzahl der gefundenen realen Fehlerzustände |Ftotal| Anzahl der realen und künst-

lichen Fehlerzustände im System|Ffound| Anzahl der gefundenen realen

und künstlichen Fehlerzustände

Bei Fault Seeding gilt die Annahme, dass die Relation der Anzahl der ge-fundenen künstlichen Fehlerzustände zu der Gesamtanzahl der künstlichen Fehlerzustände und die Relation der Anzahl der gefundenen realen Fehler-zustände zu der Gesamtanzahl der re-alen Fehlerzustände gleich ist:

|Fseededfound|/|Fseededtotal|= |Frealfound|/|Frealtotal|

Diese Metrik gibt Auskunft über die geschätzte (und berechnete) Anzahl der in der Software verbleibenden Fehler und kann wie folgt berechnet werden:

|Frealtotal| = |Fseededtotal| * |Frealfound|/|Fseededfound|

Die Restfehleranzahl ergibt sich dann aus der Differenz der gesamten realen Fehlerzustände und den davon gefun-den Fehlerzuständen. Diese Restfeh-leranzahl bestimmt die Software-Qua-lität. Die Test-Qualität wird über den Fehlerentdeckungsgrad (FEG) ermit-telt. Dieser gibt an, zu welchem Grad der Software-Test die Fehler findet. Dieser numerische Wert gibt Auskunft über die Effektivität der Testaktivitäten und errechnet sich wie folgt:

FEG = |Fseededfound| / |Fseededtotal|

Einsatz in der Praxis

Im empirischen Teil der Arbeit von Michael Altmann wurde Orthogonal Fault Seeding in einem Software-Projekt des Unternehmens TechTalk eingesetzt. In diesem kamen automa-tisierte Komponenten- und Integra-tionstests zur Anwendung. Das Ziel der empirischen Untersuchung war, die Qualität der im Projekt verwen-deten Testsuites zu bestimmen und Optimierungspotenziale in diesen zu identifizieren. Danach sollten Opti-mierungsmaßnahmen abgeleitet und umgesetzt werden, um die Testsu-ites weiter zu verbessern und die Te-steffektivität zu erhöhen. Zu diesem Zweck wurde die empirische Untersu-chung wie im Folgenden beschrieben abgearbeitet.

Ausgabe 41 | Dezember 2016 36Im Fokus

Abbildung 1

Abbildung 2

Planung und Vorbereitung durchführen

Fehler modellieren

Fehler injizieren

Durchgang Ja

Nein

Weitere Durchgänge?Tests durchführen

Primärergebnisseermitteln

Ergebnisinterpretieren

Auswertungdurchführen

FseededtotalFrealtotal

Fseededfound Frealfound

Ftotal

Ffound

1. ORTHOGONAL FAULTSEEDING ZYKLUS Die Aktivitäten Fehlermodellierung, Fehlerinjizierung, Testdurchführung und Berechnung der Software-Me-triken wurden durchlaufen. Am Ende standen folgende Software-Metriken zur Verfügung:

Gesamtfehlerentdeckungsgrad Restfehleranzahl Fehlerentdeckungsgrad des Komponen-ten- und Integrationstests

Fehlerentdeckungsgrad pro Klasse nach den Fehlertaxonomien Fehlerart, Schwe-regrad und Position im Code

Auf Basis der im ersten Zyklus ge-wonnenen Informationen wurden Optimierungspotenziale in den ein-gesetzten Testsuites identifiziert und Optimierungsmaßnahmen abgeleitet, um die Testeffektivität der Testsuites weiter zu verbessern. Laut Richtlinien von IBM müssen mindestens 80 Prozent aller Soft-ware-Fehler vom eigenen Testteam aufgedeckt werden [3, S. 36]. Nach dieser Richtlinie stellt ein Fehleren-tdeckungsgrad unter 80 Prozent ein Mangel in der Testsuite dar. In der Abbildung 3 ist der Fehlerent-deckungsgrad pro Klasse nach der Fehlertaxonomie Fehlerart zu sehen. Die Fehlerentdeckungsgrade von An-forderungs-, Datenfluss- und Schnitt-stellenfehler wurden als mangelhaft deklariert, da diese nur einen Wert von 60 Prozent erreichten. Folgende Mängel konnten im Kompo-nenten- und Integrationstest des Pro-jektes identifiziert werden:

Unzureichender Gesamtfehlerentde-ckungsgrad

Unzureichender Fehlerentdeckungsgrad von Anforderungs- und Schnittstellenfeh-lern beim Integrationstest

Unzureichender Fehlerentdeckungsgrad von Blocker-Fehlern bei Komponenten- und Integrationstest

Unzureichender Fehlerentdeckungsgrad mancher Klassen bei Komponenten- und Integrationstest

Diese Mängel bildeten die Grundlage für die Ableitung der Optimierungs-maßnahmen, wie die Änderung vor-handener Testfälle bzw. Hinzufügen zusätzlicher Testfälle im Integrati-onstest, die besonders auf die Entde-ckung von Anforderungsfehlern, Da-tenflussfehlern, Schnittstellenfehlern und Blocker-Fehlern abzielten. Aufgrund von Beschränkungen der personellen und zeitlichen Ressour-cen zielten die Maßnahmen nur zur Verbesserung des Integrationstests ab. Der Komponententest wurde nicht verändert bzw. erweitert. Das Ent-wicklungs- bzw. Testteam hat von ins-gesamt 39 Integrationstestfällen sie-ben Testfälle entfernt, sechs Testfälle geändert und 19 Testfälle zusätzlich hinzugefügt.

2. ORTHOGONAL FAULT SEEDING ZYKLUS Nachdem der zweite Orthogonal Fault Seeding Zyklus durchgeführt wurde, wurden die Ergebnisse des ersten und zweiten Zyklus gegen-übergestellt, um zu ermitteln, in-wiefern die umgesetzten Optimie-rungsmaßnahmen die Effektivität der Testsuites erhöhen konnten. Im zweiten Zyklus wurden die exakt gleichen künstlichen Fehlerzustände noch einmal in die Software injiziert. Des Weiteren wurden alle Testfälle

des Komponenten- und Integrations-tests ausgeführt und die gleichen Software-Metriken wie beim ersten Zyklus berechnet. Wie in Abbildung 4 zu sehen ist, konnte der Gesamtfeh-lerentdeckungsgrad von 66 Prozent auf 84 Prozent erhöht werden. Be-gründet ist dies ausschließlich durch die Umsetzung der abgeleiteten Op-timierungsmaßnahmen, die auf eine Verbesserung des Integrationstests abzielen.

Ergebnis

Abschließend lässt sich durch den empirischen Teil der Arbeit festhalten, dass die Weiterentwicklung Orthogo-nal Fault Seeding eine geeignete Me-thode im Software-Entwicklungs- und Testprozess darstellt, um die Effektivi-tät der Testaktivitäten zu verbessern und eine höhere Software- und Test-Qualität zu erreichen.

Orthogonal Fault Seeding ermöglicht, wie erwiesen, einen intelligenten und zielorientierten Einsatz der Testres-sourcen und der Testintensität. Die im Projekt verfügbaren begrenzten Testressourcen werden dadurch op-timal zur Erreichung der geforderten Software-Qualität genutzt und es ist möglich, eine höhere Testeffizienz zu erreichen.

Abbildung 4

LITERATUR:

[1] S. L. Pfleeger and J. M. Atlee, Software Engi-

neering Theory and Practice, Fourth Edition. Pearson

Higher Education, 2010. [2] R. Chillarege, I. S.

Bhandari, and J. K. Chaar, Orthogonal Defect Classifi-

cation – A Concept For In-Process Measurements. IEEE

Transactions on Software Engineering, Vol 18, No 11,

1992. [3] H. M. Sneed and S. Jungmayr, “Produkt-

und Prozessmetriken für den Softwaretest,”Informatik-

Spektrum, vol. 29, no. 1, pp. 23–38, 2006.

373737

Abbildung 3

Komponententest

100

KF A DF S B

80

60

40

20

0

Fehl

eren

tdec

kung

sgra

d [%

]

Integrationstest

Gesamt

Gefunden vom KomponententestGefunden vom IntegrationstestNicht gefunden

2. Fault Seeding Zyklus1. Fault Seeding Zyklus

Im Gespräch

Fachgruppentermine: Dezember 2016 - März 2017

Alle Termine und Anmeldung unter: www.asqf.de/events

DEZEMBER 2016

KW Mo Di Mi Do Fr Sa So

48 1 2 3 4

49 5 6 7 8 9 10 11

50 12 13 14 15 16 17 18

51 19 20 21 22 23 24 25

52 26 27 28 29 30 31

MÄRZ 2016

KW Mo Di Mi Do Fr Sa So

40 1 2 3 4 5

41 6 7 8 9 10 11 12

42 13 14 15 16 17 18 19

43 20 21 22 23 24 25 26

44 27 28 29 30 31

45

DE

ZE

MB

ER

01.12.2016: FG Software-Test, NRW 18:00 – 20:00 UhrThema: Zustandsbezogener Test: Methoden & Werkzeugdemonstration

07.12.2016: FG Software-Test, Berlin/Brandenburg 09:00 – 17:30 UhrThema: Qualitätssicherung für das Internet der Dinge

15.12.2016: FG Automotive, Bayern-Süd, Ingolstadt 18:00 – 20:00 UhrThema: Der Einsatz von Open Source Tools für Safety and Security

MÄ

RZ 28.03.2017: FG Safety and Security, Rhein-Main 18:00 – 20:00 Uhr

Vorankündigung

Als erster Preisträger erhielt Stefan Meiler vor zehn Jahren den ASQF-Förderpreis. Die mit 500 Euro do-tierte Auszeichnung wird einmal im Semester an Studenten und/oder Absolventen verliehen und würdigt besonders gute Leistungen während des Studiums, eine kurze Studien-dauer und eine Abschlussarbeit, die in besonderem Maße Praxisnähe und Software-Qualitätsaspekte be-rücksichtigt. In Kooperation mit ver-schiedenen Hochschulen wird der ASQF-Förderpreis derzeit an der FU Berlin, FH Brandenburg, BTU Cottbus, FH Nürnberg, Friedrich-Alexander-Universität Erlangen-Nürnberg und der TU München vergeben. Und was macht der einstige Förderpreisträger von damals heute, zehn Jahre später? Wir haben bei Stefan Meiler nachge-fragt.

Herr Meiler, Sie erhielten als Erster den ASQF-Förderpreis, der an beson-ders vielversprechende Nachwuchs-talente vergeben wird. Was bedeute-te die Auszeichnung für Sie?

Ich habe mich über die Auszeichnung damals sehr gefreut. Der Förderpreis war eine schöne Abrundung eines

Auszeichnung für den Branchennachwuchs

spannenden und abwechslungsreichen Studiums an der FAU in Erlangen.

Welchen Weg haben Sie nach Ihrem Studienabschluss eingeschlagen und warum?

Bereits in meinem Studium war es mir wichtig, verschiedene Firmen sowie deren Geschäft und Kultur kennen-zulernen. So konnte ich direkt nach meinem Studium bei Siemens in einer Abteilung einsteigen, in der ich zuvor als Werkstudent gearbeitet und für die ich auch meine Diplomarbeit angefer-tigt habe. Dort beschäftigte ich mich vor allem mit dem Design und der Implementierung von Reporting-Sys-

temen und Kundenportalen und hatte auch die Möglichkeit, in den USA zu arbeiten, um so erste interkulturelle Erfahrung zu sammeln. Nach fünf Jahren in der IT habe ich dann in den Customer-Services-Bereich von Sie-mens Healthineers gewechselt. Noch spannender als die Realisierung von IT-Systemen fand ich die Möglichkeit, Prozesse und Dienstleistungen zu ent-wickeln. Aktuell leite ich ein globales Team, das aus Daten Geschäftswerte generiert. Dabei harmonisieren wir Datenflüsse, generieren Transparenz durch KPI-Systeme, optimieren Pro-zesse und entwickeln innovative digi-tale Dienstleistungen. Da gibt es noch viel zu gestalten.

Was würden Sie heutigen Absol-venten mit auf den Weg geben?

IT ist ein spannendes, aber auch sehr weites Feld. Es ist wichtig heraus zu finden, was einem Spaß macht und vor allem, was man mit IT alles bewe-gen kann. Für mich geht dabei weni-ger um das Programmieren, sondern viel mehr um das, was man damit er-reichen kann.

Das Interview führte Christin Senftleben.


Stefan Meiler

Ein effizientes Requirements Engineering ist Grundlage für erfolgreiche Software-Projekte. Dieses Buch zeigt, wie Work-shops zur schrittweisen Ermitt-lung von Anforderungen effektiv gestaltet werden können. Der Autor geht dabei über eine the-

oretische Betrachtung allgemeiner Methoden hinaus und tief hinein in die Mühen der täglichen Arbeit als Product Owner, Projektleiter, Business

Sudoku

5 2 6 4

8 7 1

6 1 9

9 6 7 2

4 2 3 6 5

3 9 2

5

1 9

6 8 2

Buchstaben: 1=P, 2=X, 3=C, 4=E, 5=N, 6=U, 7=R, 8=S, 9=I

LÖSUNGSWORT

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

Quiz

SQ № 42

Thema: Mehr Qualität durch DevOps

Anzeigenschluss: 22.02.2017

Redaktionsschluss: 01.03.2017

erscheint im März 2017№ 42

HERAUSGEBER

ASQF e.V.

Friedrich-Engels-Str. 24, 14473 Potsdam

Tel +49 331 231810-29

Fax +49 331 231810-10

[email protected], www.asqf.de

REDAKTION

V.i.S.d.P.:

Stephan Goericke (Hauptgeschäftsführer)

Chefredaktion: Christin Senftleben

Redaktionsteam: Julia Schirmer,

Anja Schreinert, Isabel von Gustedt

Friedrich-Engels-Str. 24, 14473 Potsdam

Tel +49 331 231810-56

Fax +49 331 231810-10

[email protected],

www.sq-magazin.de

SATZ / LAYOUT

Frenkelson Werbeagentur, Potsdam

www.frenkelson.de

FOTOS: ASQF e.V. und iSQI GmbH

Titel:

©Rawpixel_ shutterstock

Seite 3:

©Karoline Wolf

Seite 8-9:


Seite 11,13:

©Ingo Jenko

Seite 25:

©dotshock_shutterstock

©Marc Frommer Fraunhofer

Seite 26-29:

©Zhenikeyev Arman_shutterstock

Seite 30, 32:

©Ollyy_ shutterstock

Seite 32:


Seite 34:

©Bubbers BB_ shutterstock

Alle Portraits und Grafiken mit freundlicher

Genehmigung der Autoren.

DRUCK: PRINTEC OFFSET, Kassel

DRUCKAUFLAGE: 4.000 Stück

INTERNETAUSGABE: www.sq-magazin.de

MEDIADATEN

Gern senden wir Ihnen unsere Mediadaten zu.

Richten Sie Ihre Anfrage an

[email protected]

Namentlich gekennzeichnete Beiträge müssen

nicht mit der Meinung der Redaktion überein-

stimmen. Die Redaktion behält sich das Recht

auf sinngerechte Kürzung und Bearbeitung

eingereichter Manuskripte vor. Wir machen da-

rauf aufmerksam, dass Daten nicht an Dritte

weitergegeben und ausschließlich zur internen

Auswertung herangezogen werden können.

Impressum

Analyst oder Requirements Engineer. Die ein-zelnen Schritte in der Anforderungsermittlung sind entlang einer durchgängigen Vorgehens-weise angeordnet. Der Leser findet in diesem Buch viele Best Practices und Checklisten, die sofort in den Workshops umgesetzt werden können, sowie Beispiele für Workshop-Mode-rationspläne.

Lösungswort des Gewinnspiels an [email protected]. Gewinnen Sie eines von fünf Büchern.

Mitmachen und gewinnen!

Die Lösung des letzten

Sudokus lautete:

GEBURTSTAGSSPASS

Die Gewinner aus Heft 40 sind:

Claas Henning Wrede, Bremen

Christian Odenthal, Köln

Peter Engelhardt, Mannheim

Sonja Kloppig, Ludwigsburg

Thierry Dalon, Neutraubling

2017

SQ-Themenschwerpunkte Im kommenden Jahr widmen wir uns den folgenden Themen:

SQ 42 (Märzausgabe): Mehr Qualität durch DevOpsSQ 43 (Juniausgabe): Qualitätssicherung in der DigitalisierungSQ 44 (Septemberausgabe): Agilität – Was wir gelernt haben.SQ 45 (Dezemberausgabe): Zukunft der Weiterbildung

Die SQ-Schwerpunktthemen sind auch für Ihr Unternehmen bzw. Ihre Kunden interessant? Dann helfen wir Ihnen gern dabei, die ideale Präsenz im Magazin zu finden. Bei einer langfristigen Zusammenarbeit gewähren wir attraktive Sonderkonditionen. Mediadaten und Preise zum Download auf www.sq-magazin.de

usability - [email protected] am 15. november fand im unicum er-langen die...

Documents