SQ Magazin 41

Folgen Sie uns auf Twitter und Facebook.

twitter.com/SQMagazin facebook.com/SQforyou

ISSN 2367-3516

Ausgabe 41 | Dezember 2016

USABILITY & USER EXPERIENCE EIN NEUES VERSTÄNDNIS VON QUALITÄT

PLU Die n S : eu Schul esten ung termi sn f ür 2 0 e 17

IM INTERVIEW:

BEST PRACTICE:

GMX-Gründer starten mit neuer App

Wenn die Digitalisierung die Usability herausfordert

3

Ausgabe 41 | Dezember 2016

Editorial

Etwas ganz Besonderes

Große Ereignisse werfen ihre Schatten voraus.

Gemeint sind mit dem poetischen Ausspruch die ersten spürbaren Anzeichen einer besonderen, bevorstehenden Veranstaltung oder ähnlichem. 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 aufregenden 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. Ursprünglich entwickelt aus einem lokal begrenzten EU-Förderprojekt, hat sich der ASQF zum größten Expertennetzwerk für Software-Qualität im deutschsprachigen Raum entwickelt. Der Weg dahin war nicht immer einfach. Dennoch haben wir durchgehalten. Das Ziel, weltweit anerkannte Standards für Software-Qualität zu etablieren, ist erfüllt.

Parallel zu dieser regulären SQ-Ausgabe, widmen wir deshalb dem ASQF eine ganz besondere SQ-Sonderedition. Für die 100 Seiten starke Publikation konnten wir herausragende Persönlichkeiten aus Praxis und Forschung gewinnen.

Neben der limitierten Printausgabe wird demnä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 genutzt, sowohl die Online-Präsenz als auch den

visuellen Auftritt des Vereins komplett zu überarbeiten. Ein selbstgemachtes Weihnachtsgeschenk, sozusagen.

In diesem Sinne wünsche ich Ihnen ein gesegnetes Weihnachtsfest und einen erfolgreichen Start in das kommende Jahr.

Herzlichst

Ihr Stephan Goericke ASQF-Hauptgeschäftsführer

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. s.goericke@sq-magazin.de

ASQF NEWS

Inhalt 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

Mitgliederversammlung des ASQF in Erlangen Am 15. November fand im Unicum Erlangen die diesjährige Mitgliederversammlung des ASQF e.V. statt.

ASQF-Präsidentin Prof. Dr. Ina Schieferdecker 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 Vorsitzenden 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 Beiträgen zu beteiligen.

Dr. Armin Metzger stellte sich als neuer Referent des ASQF den anwesenden Mitgliedern vor und erläuterte die anstehenden Ziele für die Vereinsarbeit.

Ein Schwerpunkt im kommenden Jahr wird die intensive Kooperation und

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 Kooperationen mit anderen Verbänden geschlossen werden, um das Expertennetzwerk 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-Hauptgeschäftsführer, der auch gleichzeitig die Geschäfte und Geschicke der iSQI GmbH leitet, konnte sich in den vergangenen Geschäftsjahren über stetigen Zuwachs freuen.

Beim anschließenden Get-together nutzen die Mitglieder die Gelegenheit, sich in Gesprächen zu aktuellen Themen und Fachfragen auszutauschen.

ASQF reloaded Wir sind stolz, Ihnen eine völlig überarbeitete 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 spannendes 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 info@asqf.de.

5

ASQF NEWS

Ausgabe 41 | Dezember 2016

Safety and Security Day 3. Expertenfachtagung ASQF/tecmata Am 20. September hatte die Fachgruppe 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 sieben Expertenvorträge präsentierten Lösungsbeispiele, offene Fragestellungen sowie erfahrungsbasierte Vorgehensweisen für die Teilnehmer. Im Anschluss an die Fachreferate sowie in den Pausen wurde rege und praxisbezogen gemeinsam diskutiert.

Dr. Daniel Schneider (Fraunhofer IESE Kaiserslautern), referierte über offene Systeme und deren spezifische Herausforderungen bezüglich Safety

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 Augen. Praxisnah sprach Markus Schmidt (Vertical GmbH) zur QAuth2.0 Implementierung und den dabei angewendeten Problemlösungen. Martin Zeh (TÜV NORD Systems GmbH & Co. KG) zeigte an einem lebendigen Projektbeispiel, 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 ASQFDays können Sie als ASQFMitglied 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 autonomen Rasenmähers die Brisanz zum Nachweis der Authentizität von Systemkomponenten auf. Er vermittelte deutlich die Auswirkung von GerätePlagiaten auf Security-Anforderungen mit Safety-Wirkung.

Testing Day Niedersachsen „Anforderungen und Test oder Testen der Anforderungen“ lautete das übergreifende Thema beim ASQF Testing Day Niedersachsen Ende September.

Die Leiter der Fachgruppe SoftwareTest, 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 Teilnehmer hatten sich für den Day angemeldet.

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-

ren bzw. die Rückverfolgbarkeit im gesamten Entwicklungsprozess spielen.

Remo Lachmann (TU Braunschweig) stellte seine Doktorarbeit zum Thema Machine Learning vor, die sich mit der automatischen Priorisierung von Testfällen befasst.

Nachmittags berichtete zunächst Hannelore Papke (Otto GmbH & Co. KG) über ihre anforderungsgetriebene Teststrategie. Ihr Team hat Verbindungen zwischen Tests und Anforderungen 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 Gelegenheit, das Thema „Anforderungen“ über den normalen Entwicklungsprozess 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 einholen kann. Seine „ausführbaren Anforderungen“ auf mobilen Geräten sind ein Werkzeug, um Anforderungen einfach zu visualisieren.

Zusammenfassend lässt sich festhalten, dass die Talks des Testing Days die Vielfalt von Verbindungen zwischen Anforderungen und Testen aufzeigten.

ASQF NEWS

Ausgabe 41 | Dezember 2016

6

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

Am 6. Oktober 2016 fand zum dritten Mal die Mobile Quality Night im Stockwerk in Wien statt. Die Veranstaltung 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 aufkommenden Smart Devices und den Herausforderungen, die eine Qualitätssicherung 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 verschiedenen Bereichen und Themen eingeladen. So teilte Christoph Schaal

seine Erfahrungen als Test Engineer bei Bosch Smart Home Solutions und Marcus Wiegand (Testplus) berichtete von Erfahrungen mit einer smarten Waage. Bastian Baumgartner und Michael Mlynarski der QualityMinds präsentierten die Ergebnisse der Studie „Smartwatches und Usability-Alltag”.

An diesem Abend wurde aber nicht nur Theorie vermittelt, sondern auch mit praktischem Wissen und Vorführungen veranschaulicht: Andreas Lüdecke (TestObject), Marcel Gehlen (MaibornWollf), Gerhard Wiesinger (Zoomsquare), Severin Winkler (SBA Research) sowie Sergej Mudruk (XING AG) und Christian Breitwieser (Ranorex) ließen die Teilnehmer an Ihren Erfahrungen teilhaben.

Zuwachs: Neue Mitglieder im ASQF e.V. Bakis Automation GmbH Hamburg www.bakis-automation.com

azh GmbH Aschheim bei München www.azh.de

Das Expertennetzwerk

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

Haben Sie Interesse die Organisation der Mobile Quality Night zu unterstützen? Dann kontaktieren Sie uns unter: info@asqf.de

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

7

Die End-of-Testing-Prognose Vom Bauchgefühl zu einer fundierten Vorhersage Datumswerte über die Monte-CarloSimulation überprüft. Sie ist seit Jahrzehnten wissenschaftlich anerkannt.

Nach der Prognose ist vor der Prognose

Abb. 1 Screenshot einer Fehlertrend-Kurve

Zu Beginn jeden Projekts steht eine, auf Annahmen basierte Planung. Im Projektverlauf stellt sich heraus, dass manche Planungspunkte und Annahmen der Realität nicht mehr standhalten. 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 realistisch 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. Daraus entwickelte er das ANECON Endof-Testing-Tool (EOT-Tool).

noch anhalten wird und wann die Anzahl der offenen Fehler gegen null geht.

Der Ansatz

Auf Basis dieser drei Werte wird ermittelt, 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 Absicherung und Bestätigung werden die drei

Der Software-Test ist naturgemäß abgeschlossen, sobald alle gefundenen Fehler behoben wurden. Es ist davon auszugehen, dass die geschlossene Fehleranzahl immer größer und dadurch die Arbeitslast des Entwicklungsteams verringert wird. Auf Basis der gesamten Projekthistorie ist festzustellen, wie lange der aktuelle Trend

Der Schlüssel: Team-Performance Je effizienter das gesamte Team zusammenarbeitet, desto schneller wird das Ziel erreicht. Passende Daten über die Team-Performance sind Indikatoren, um das Testende berechnen zu können. Gute Anhaltspunkte sind:

Die erste Hochrechnung ist frühestens vier Wochen nach Projektstart sinnvoll. 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 Methode liefert Anhaltspunkte und keine tagesgenauen Prognosen. Jedoch ist die Wahrscheinlichkeit, mit der die Prognose 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 Aussagen stimmen mit der Projektpraxis in meinen Projekten überein“, unterstreicht Robert Licen.

Maßnahmen setzen

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 Entwicklungsteam neue Funktionalität implementiert.

Die Hochrechnung

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

Titelthema

Ausgabe 41 | Dezember 2016

Usability und User Experience im Zeitalter maximaler Beschleunigung von Manuel Fischer

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ültig 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 Ereignis 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, individuell 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 Experience. Ob das Szenario so eintritt und ob man es sich wünschen sollte, ist eine andere Frage.

Dass die zunehmend beschleunigte Entwicklung von Informationstechnologien jetzt schon sichtbare und weitreichende Veränderungen in unserer Lebens- und Arbeitswelt nach sich zieht, lässt sich jeden Tag beobachten. Allerdings: Bis die Mensch-Maschine-Schnittstellen unsichtbar in der Cloud verschwinden und nur noch über Gesten, Gedanken oder Sprache gesteuert werden, ist im Bereich Usability und User Experience noch viel zu tun.

8

9

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 Unternehmer eine fehlende Innovationskraft und -fähigkeit von Unternehmen im digitalen Bereich. Auf der anderen Seite gibt es aber viele Unternehmen, die massiv in die Digitale Transformation investieren und sehr erfolgreich mit ihren Innovationen sind.

Das Spektrum reicht dabei von Steuerungs-Software für international tätige Maschinenbauunternehmen über nahezu perfekte, serviceorientierte Apps bis hin zu spezialisierten VRAnwendungen 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 optimierte Corporate-Webseite. Und das obwohl 56 Prozent der Internetnutzung bereits heute über Smartphones und Tablets erfolgt, Tendenz steigend.

Sehr anschaulich werden die Bestrebungen beim Thema Digitale Transformation in Deutschland mit einem Blick auf die Infrastruktur auf Straßen, Plätzen oder Bahnhöfen deutlich. So basiert das Bedienkonzept von Fahrkartenautomaten in den Bahnhöfen offensichtlich auf internen IT-Anforderungen und internen Abläufen der Verkehrsunternehmen. Dies hat aber kaum etwas mit dem wahrscheinlichen Nutzungsszenario „Ich brauche jetzt gleich eine Fahrkarte von hier nach dort“ zu tun, mit dem diese Automaten genutzt werden.

Im Trend: Nutzerzentrierung Bei aller Unterschiedlichkeit der Anwendungen und Notwendigkeit der differenzierten Betrachtung lässt sich

aktuell aber auch beobachten, dass der Aspekt der „Nutzerzentrierung“ bei der Entwicklung und Optimierung von Technologien und Schnittstellen immer wichtiger wird. Der unter anderem von Peter F. Drucker, dem legendären Vordenker der Managementlehre, geprägte Ansatz geht davon aus, dass der Kunde im Mittelpunkt aller Aktivitäten der Organisation stehen 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-SystemInteraktion“) 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 liegenden Begrifflichkeiten wie Usability und User Experience besteht. In vielen Projekten lässt sich beobachten, dass beide Begriffe als Synonyme verwendet werden oder, je nach Verständnis, unterschiedlich interpretiert werden.

Im Sinne der ISO 9241 bedeutet Usability kurz gesagt die konkrete Nutzung der Anwendung durch einen bestimmten Nutzer in einem konkreten Kontext zu einem bestimmten Zweck.

User Experience ist subjektiv Die User Experience umfasst die subjektiven Eindrücke, Meinungen und Erwartungen des Nutzers vor, während und nach der Nutzung. Dass sich die Anstrengung für eine optimale User Experience lohnt, zeigt eine aktuelle Studie aus den USA. Danach haben Unternehmen, die eine optimale User Experience (beziehungsweise Customer Experience) bieten, eine viel höhere Wertschöpfung, als Unternehmen, die keinen oder weniger Wert darauf legen. Im Zentrum der digitalen Wertschöpfung steht die möglichst einfache, intuitive Be-

Titelthema

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

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 Usability dagegen fällt den Nutzern sofort negativ auf und führt im ungünstigsten Fall zu einer unbefriedigenden User Experience, die sich wiederum direkt auf die „Digitale Marke” auswirkt. Und da im Zeitalter der Digitalen Transformation fast alle Unternehmen, Organisationen und Marken digitale Touchpoints haben, die aus Kundensicht eine ganzheitlichen Erfahrung („Customer Experience”) bilden, steckt in der Optimierung von Usability und User Experience so viel Potential. Optimale Gebrauchstauglichkeit und Nutzungserlebnisse sind also kein Selbstzweck, sondern tragen 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

Ausgabe 41 | Dezember 2016

bringen, entstehen parallel dazu ganz neue Technologien, die die bisherigen Standards in Frage stellen. Beispiele hierfür sind die Stichpunkte „Virtual Reality“, „Chat-Bots“ oder „Smart Home“, bei denen völlig neue Nutzungs- und Bedienkonzepte entstehen, für die sich erst noch allgemeingültige Standards herausbilden müssen. Einige Experten arbeiten heute unter dem Begriff “Zero-UI” an User Interfaces jenseits von Bildschirmen und sonstigen Oberflächen. Ob und wie die bisher bestehenden Grundlagen von Usability wie Aufgabenangemessenheit, Selbstbeschreibungsfähigkeit, Lernförderlichkeit, Steuerbarkeit, Erwartungskonformität, Individualisierbarkeit und Fehlertoleranz auch für die neuen Nutzungskonzepte gelten können, muss sich erst noch zeigen.

Wahrscheinlich werden diese Grundlagen 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. Aktuell bestimmt aber − wie so oft schon bei solchen Entwicklungen – eher das technisch Machbare die Entwicklung von User Experience und Usability.

10

Zusammenarbeit von Experten unterschiedlicher Fachbereiche im Sinne einer optimalen Usability und User Experience. Die grundsätzlichen Ansätze sind: Agilität: Kooperatives, gemeinschaftliches Arbeiten in gemischten Teams mit agilen Methoden wie Scrum oder Design Thinking.

Kundenverständnis: Umfassende und tiefgreifende Kenntnisse über die Erwartungen 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 Entwicklungsprozesse in kleine Schritte aufteilen.

Stakeholder integrieren: In möglichst jeder Phase das Feedback von potentiellen Nutzern einholen.

Ganz entscheidend: Zielorientierung: Ziel und Ergebnis nicht aus den Augen verlieren.

Gesucht: Eine neue Haltung In der Ära der exponentiellen technologischen Beschleunigung müssen in immer kürzerer Zeit immer komplexere und noch bessere Lösungen entwickelt werden. Hierfür sind auch neue Methoden der Zusammenarbeit zwischen allen Beteiligten erforderlich. 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 konsequent im Mittelpunkt aller Aktivitäten steht. Es gibt zahlreiche Ansätze für die Organisation einer verbesserten

Bis jetzt hat sich noch kein wirkliches Patentrezept als passend für alle Unternehmen, Märkte oder Situationen etabliert. Jede Organisation wird daher für sich selbst herausfinden müssen, welchen Weg und welche Methoden für sie, ihre Mitarbeiter und Kunden die richtigen sind, um die digitale Zukunft aktiv mitzugestalten.

Und womit beschäftigen sich Usability- 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.

11

Qualität aus der Perspektive eines Product Owners von Alexandra Schladebeck

S

pricht man über Qualität im agilen Kontext, hört man früher oder später den Begriff Whole Team Quality. Dahinter steckt die Erkenntnis, dass ein Entwicklungsteam im agilen Prozess gemeinsam die Qualität der Entwicklung 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 besondere 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 ScrumProzess 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 Antwort „Testen ist nicht mein Job“ kommt sicher in manchen verantwortungsbewussten, crossfunctional Teams schlecht an. Viele Product Owner (die Autorin inbegriffen) haben einen Hinter-

Titelthema grund im Testen und wechseln je nach Team oder Aufgabe zwischen den beiden Rollen.

Man muss also nicht testen, könnte aber durchaus mitwirken.

Die Gründe, warum ein Product Owner 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 meistens nicht zeitnah genug erfolgen, um eine Funktion in kurzen Zyklen fertigzustellen.

Ausgabe 41 | Dezember 2016

In anderen Worten: Ohne einen gelieferten Value (Wert), haben die vielen Gespräche, Implementierungen und Tests wenig Bedeutung. Aus diesem Grund hat der Product Owner ein spezifisches Hauptziel vor Augen: Dem Kunden etwas Wertvolles ausliefern.

Das kann dazu führen, dass der Product Owner ganz andere Qualitätskriterien 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 Artefakte, die aus der Entwicklung stammen), Qualität des Releases.

Der Product Owner – Rollenbild und Bezug zur Qualität Der Product Owner ist, wenn überhaupt, kaum am dynamischen Test beteiligt. Das bedeutet aber keinesfalls, dass der Product Owner sich mit dem Thema Qualität nicht auseinandersetzen muss – ganz im Gegenteil. Der Qualitätsfokus für den Product Owner ist eng mit seiner Rolle und damit einhergehenden Aufgaben verbunden.

Das Priorisieren von Anforderungen im Sinne des Kunden.

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

Qualität der Anforderungen Man kennt es aus der Software-Testing-Theorie: Schon bei der Anforderungsdefinition soll auf die Qualität geachtet und Anforderungen getestet werden. Doch agil und qualitativ hochwertige Anforderungen sind ein Widerspruch in sich, oder?

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 bewusste Einhalten der agilen Prinzipien, 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 continuous delivery of valuable software .”

Korrektheit ist wichtig!

Alexandra Schladebeck

12

Nicht unbedingt. Wenn wir über gute Anforderungen sprechen, meinen wir häufig, dass sie den Qualitätskriterien Vollständigkeit, Eindeutigkeit und Klarheit genügen.

In agilen Prozessen werden User Stories vorgestellt, die diese Kriterien nicht erfüllen. Sie werden teilweise durch Refinement Meetings konkretisiert oder sie werden erst bei der Umsetzung im Detail diskutiert. Trotzdem kann man von qualitativ hochwertigen Anforderungen sprechen – und zwar nach den Qualitätskriterien Nachvollziehbarkeit, Leanness (Verschwendungsminimierung) und Vorstellbarkeit.

Nachvollziehbarkeit: Sind wir in der Lage, das Problem des Kunden zu verstehen? 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 Story, die sehr detailliert und aufwändig diskutiert wurde, nie (oder erst viel später) implementiert wird. Die Besprechungen 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 werden bei der Implementierung häufig geändert. Agile Prozesse versuchen solche Verschwendung zu vermeiden.

Vorstellbarkeit: Ohne, dass man alle Spezifikationen, Teilanforderungen oder technische Informationen vorliegen hat, sind wir in der Lage, Beispiele für eine mögliche Lösung zu erarbeiten 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 Meetings dafür, dass die Stories, die oben genannten Qualitätskriterien erfül-

13

len. Bei einem Team, bestehend aus Technikern, kann es schwer sein, sich verstärkt auf das „Warum“ zu konzentrieren – aber der Versuch lohnt sich.

Viele in User-Story-Meetings ausdiskutierten Implementierungen oder Details ändern sich, sobald die ersten Code-Zeilen geschrieben sind. Um Verschwendung zu minimieren und um das Team eigenständig, selbstorganisiert und initiativergreifend arbeiten zu lassen, fokussiert man sich besser auf das „Warum“ anhand von Beispielen, die einen konkreten Ansatzpunkt erlauben.

Im Alltag kann das so aussehen: UserStory-Meetings werden ohne Rechner durchgeführt. Die Stories werden tatsä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 werden. Der Product Owner notiert sich wichtige Anmerkungen oder Randbedingungen für die Story oder Akzeptanzkriterien zum Dokumentieren im Nachgang – aber es müssen nicht alle Details schriftlich festgehalten werden. Das Team hat das „Warum“ verstanden, 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. Daher sollten entsprechende Puffer im Sprint oder in den Schätzungen dafür eingeplant werden. Größere, wichtige Architektur- oder Technikentscheidungen 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 Funktionen dem Kunden bald zur Verfügung zu stellen und möchte natürlich, dass sie gut getestet sind. Anhand der einleitenden 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 Entwicklungsteam geleistet und verantwortet. Bei laufenden Entwicklungen interessiert sich der Product Owner daher stärker für Qualitätskriterien, die über die Korrektheit hinausgehen – denn dem Kunden reicht korrekt implementiert nicht aus. An dieser Stelle achten Product Owner auf Angemessenheit und Auslieferbarkeit.

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

Auslieferbarkeit: Nur durch ausgelieferte Funktionen bekommt der Kunde 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ätsziel: die Fähigkeit, eine Funktion tatsä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 implementiert werden, aber danach viel Zeit vergeht, bis sie getestet, dokumentiert und abgenommen sind.

Auswertbarkeit: Bei vielen Änderungen und kurzen Release-Zyklen ist es entscheidend, zeitnahes Feedback über die aktuelle Qualität zu erhalten. 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 gemeinsam arbeiten (Pairing), um Zwischenversionen 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 Entwicklungen sieht. Durch zeitnahes Feed-

Titelthema

Alexandra Schladebeck 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, Benutzern und Entwicklern. Besonders interessiert sie sich neben Benutzerfreundlichkeit und Ergonomie auch für Agilität in Testund Entwicklungsprozessen. Sie spricht häufig auf Konferenzen über Agilität und Qualitätssicherung aus Sicht ihrer Projekterfahrung.

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 Increments erzeugt. Ein typisches zu vermeidendes Szenario ist, dass immer 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 Workin-Progress-Limitierung erhöhen. Ein Beispiel: Nach dem Stand-up-Meeting stellt sich das Team die Frage „Was bekommen wir heute fertig?“. Es wird

Ausgabe 41 | Dezember 2016

gemeinsam auf die Stories „in Arbeit“ geschaut, um Schritte und Prioritäten festzulegen, damit diese als done gekennzeichnet werden können. Um Flaschenhä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 gemeinsam gearbeitet werden, ein integrierter Tester und/oder der Product Owner 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 werden und ein Potentially Shippable Increment zu erzeugen, ist die Minimierung von Blockaden. Wenn Funktion X fertig ist, aber Funktion Y noch in Arbeit ist, kann dieser Konflikt ein Release behindern. Um solche Situationen zu vermeiden, kann man Feature Branches einsetzen, damit die Entwicklung unterschiedlicher Funktionen unabhängig voneinander erfolgt. 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önnen, bzw. dem Kunden Zwischenversionen ohne Angst auf böse Überraschungen zeigen zu können. Feedback über die Qualität gehört zum Prozess, zum Beispiel durch automatisierte Tests und zeitnahes exploratives Testen. Am Ende des Stand-Up-Meetings empfiehlt es sich, dass das ganze 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 werden, der aussagt, welche Tests mit welchem Ergebnis gelaufen sind. So ist der Suchaufwand nach eingefrorenen Testmaschinen oder grundsätzlichen Build-/ Environment-Problemen reduziert.

14

2 Vorbereitung:

Die tatsächlichen Fehlschläge werden im Voraus von einem Teammitglied analysiert, sodass eine Übersicht zur Verfügung steht.

3 Regeln im Team einführen, die Entscheidungen erleichtern: Zum Beispiel, dass fehlschlagene Tests mit höchster Prioritä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 benennen.

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 risikobasiert und kontextabhängig zwei Qualitätskriterien abwägen: Abdeckung und Geschwindigkeit.

Abdeckung: Dieses Qualitätskriterium gibt Auskunft darüber, wie viel getestet wurde und welche Risiken noch offen sein könnten. Man kann die Abdeckung durch weitere Tests erhöhen, aber 100% Abdeckung bzw. 0% RestRisiken sind nie erreichbar.

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

Agile Projekte sollen dem Kunden einen Marktvorteil durch regelmäßige Auslieferungen bringen. Wie oben schon erwähnt, kann sich eine nicht auslieferbare Software oder ein verzögertes Release negativ auswirken. Deshalb ist Geschwindigkeit ein relevantes Qualitätsmerkmal für einen Product Owner. Übung und Vertrauen Um eventuelle Rest-Risiken zu identifizieren oder die Software bzw. die

Neu bei dpunkt

15

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

neuen Funktionen ganzheitlich betrachten zu können, kann ein schlanker Release-Test angebracht sein. Ein diesbezüglicher Ansatz ist der „explorative 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 fallen meist in drei Kategorien:

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

bekannten und unbekannten Problemen ausgeliefert? Die Versuchung ist groß, einen letzten Fix reinzunehmen oder noch einen Test durchzuführen.

Aber die Geschwindigkeit – und dadurch eventuell der Kunde – leiden darunter. Deshalb muss man auf das Team, seine Arbeit und die durchgängigen Überprüfungen und Tests vertrauen und loslassen. Falls Probleme im produktiven Stand identifiziert werden, weiß man, dass eine Behebung wiederum zeitnah ausgeliefert werden kann.

2 Offene, bekannte Risiken

Zusammenfassung

3 Wiederkehrende

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 Geschwindigkeit eine deutlich reduziertere Rolle spielen. Nichtsdestotrotz sollten sich Product Owner immer wieder daran erinnern, dass der Kunde frühzeitig und regelmäßig Value benötigt. Hier sind einige Beispiele für Qualitätskriterien aus Sicht der Product Owner genannt worden. Wichtig ist, dass jeder Product Owner in seinem Kontext die für sich besonderen Merkmale identifiziert und auf deren Erfüllung achtet.

Problembereiche aus der Erfahrung mit vergangenen Releases

Nach diesem Test-Tag verfügt der Product Owner über eine zusätzliche Entscheidungsgrundlage für die Freigabe der Software.

Damit der Nachgang zum explorativen Test Tag nicht durch panisches Bug Fixing geprägt wird (welches das Release zwar stabiler macht, aber auch verzögert), muss die Grundqualität ein gewisses Level erreicht und gehalten haben. Dies passiert dann, wenn das Team gemeinsam im Sprint testet und eine vernünftige Testautomatisierungsstrategie 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-TagTestphasen umstellen. Teams können sich in Geschwindigkeit üben, indem sie nach jedem Sprint eine Beta-Version bereitstellen (die zum Beispiel für gewisse Kundengruppen verfügbar ist). Dies übt die Schritte vom potentially shippable zum actually shipped in einem kleineren, weniger risikobehafteten 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 Entscheidungen treffen und die Frage beantworten: Wird dieser Stand mit seinen

Automotive SPICE® in der Praxis Interpretationshilfe für Anwender und Assessoren 2. Auflage 2016, 418 Seiten € 46,90 (D) ISBN 978-3-86490-326-7

P. Metz

Automotive SPICE® – Capability Level 2 und 3 in der Praxis Prozessspezifische Interpretationsvorschläge 2016, 286 Seiten € 42,90 (D) ISBN 978-3-86490-360-1

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

Basiswissen modellbasierter Test Aus- und Weiterbildung zum ISTQB® Foundation Level – Certified ModelBased Tester 2. Auflage 2016, 474 Seiten € 44,90 (D) ISBN 978-3-86490-297-0

T. Linz

Testen in Scrum-Projekten Leitfaden für Softwarequalität in der agilen Welt Aus- und Weiterbildung zum ISTQB® Certified Agile Tester – Foundation Extension 2. Auflage 2016, 270 Seiten € 34,90 (D) ISBN 978-3-86490-414-1 D. Knott

Mobile App Testing Praxisleitfaden für Softwaretester und Entwickler mobiler Anwendungen 2016, 256 Seiten € 29,90 (D) ISBN 978-3-86490-379-3

ok: Buch + E-Bokt.de/plus www.dpun

Wieblinger Weg 17 · D-69123 Heidelberg fon: 0 62 21 / 14 83 40 · fax: 0 62 21 / 14 83 99 e-mail: bestellung@dpunkt.de

www.dpunkt.de

Im Gespräch

Bezahlte Sicherheit Mit einem Bezahlmodell wollen die GMX-Gründer den Schutz von Kommunikationsdaten gewährleisten „Wir holen die Privatsphäre in die digitale Welt zurück!“, versprachen die GMX-Gründer im Sommer und kündig­ten den Launch einer vollständig verschlüsselten, integrierten App namens Brabbler an. Sie soll noch in diesem Jahr erscheinen und eine Alternative zu den herkömmlichen Angeboten bieten. Der Knackpunkt: Die App soll sich nicht über Werbung, sondern über die Bezahlung der Nutzer finanzieren. Christin Senftleben, Chefredakteurin des SQ-Magazins, befragte dazu die Brabbler-Hersteller Karsten Schramm, Eric Dolatre, 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 Datenspuren 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 Ursprung in den Anfängen des Internets. Die ersten Business-Modelle, die sich im Web vor knapp 20 Jahren etablierten, beruhten alle auf dem „Gratis-für-Werbung-Prinzip“. Der Konsument hat sich schnell daran gewöhnt und das fast zwei Jahrzehnte 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ährboden bietet.

Ausgabe 41 | Dezember 2016

Schramm: In Unternehmen erkannte man digitale Gefahren etwas früher. Hier steht ja nicht die Privatsphäre, sondern die Vertraulichkeit von Daten, geistigem Eigentum und Korrespondenz im Vordergrund. Digitale Spionage, Sabotage oder Hacker-Angriffe sind selbst bei kleinen Unternehmen schon lange ein Thema. Durch die rasante Digitalisierung in allen Branchen und Unternehmensgrößen wird das noch weiter an Bedeutung gewinnen. Das ist ein Grund, warum unsere Strategie je zur Hälfte auf Geschäftskunden und Endverbraucher setzt.

SQ: Was ist der Unterschied zu Konkurrenzangeboten 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 Termine, Dateien oder Kontakte. All diese Abläufe decken wir in einer einzigen App ab, so dass ein Nutzer nicht zwischen zahlreichen Anwendungen hin- und herspringen muss. Da unsere Mission die Wiederherstellung von Vertraulichkeit und Privatsphäre ist, haben wir auch gleich einen Passwort-Manager mit Passwort-Generator hinzugefügt. Denn schwache Passwörter stehen bei den Sicherheitslücken, die beispielsweise 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 Datenspeicherung, 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 standhalten würden. Unser Ansatz bietet einen Funktionsumfang, der dem bekannten ProduktivitätsSuiten am Arbeitsplatz ähnelt.

SQ: Wir verbringen täglich mehrere Stunden im Web, mobil per Smartphone und am PC. Die digitale Privatsphäre gerät zunehmend in Gefahr.

Dennoch tauschen Millionen Nutzer ihre persönlichen Daten bereitwillig gegen kostenfreie Angebote. Warum meinen Sie, wird ein Bezahldienst wie Brabbler Erfolg haben?

16

17

Die Brabbler-Gründer (v.l.n.r.) Peter Köhnkow, Jörg Sellmann, Eric Dolatre, Karsten Schramm wollen mit ihrer App unsere Kommunikation sicherer machen.

Dolatre: Wie Herr Sellmann bereits erwähnte, sehen wir einen Trend zu mehr Bewusstsein, nicht nur bei Unternehmen, sondern auch bei den Endverbrauchern. Diese Entwicklung begann um die Zeit der Snowden-Enthüllungen und hat seitdem kontinuierlich Fahrt aufgenommen. Die Zielgruppe derer, die sich bewusst mit dem Schutz der eigenen Daten und digitalen Privatsphäre auseinandersetzen, 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 Regierung könne noch stärker Gebrauch von den enormen Überwachungskapazitäten der NSA machen. Aktuell findet ein kollektives Umdenken 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ässigen Diensten. Diese bieten wir. Wir sind werbefrei, sammeln keinerlei Daten, verschlüsseln nicht nur beim Versand, sondern auch bei der Speiche-

Im Gespräch

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 Online-Werbung herausfiltern, verdoppelt. In Folge versuchen sich Verlage weltweit an Paid-ContentModellen 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 Übrigen zahlen Nutzer auch heute schon bares Geld für digitale Leistungen wie beispielsweise Premium-Mitgliedschaften bei XING oder FitnessApps. Im gewerblichen Kontext stellt sich die Frage der Zahlungsbereitschaft übrigens überhaupt 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 Privatsphä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 vorangetrieben haben. Wir sahen seinerzeit viel Potential

Ausgabe 41 | Dezember 2016

in diesem Ansatz. Doch das Ausmaß dessen, was heute mit den Daten von Nutzern geschieht, übersteigt alles, was wir uns damals für die Zukunft ausgemalt hatten, um ein Vielfaches. Wir garantierten unseren Mitgliedern, deren anonymisierte Daten ausschließlich innerhalb des Werbeträgers GMX zu nutzen. Eine Weitergabe war komplett ausgeschlossen. Was jedoch Anbieter von kostenlosen Diensten aktuell mit solchen Daten machen, ist bekannt. Aus gesellschaftlicher Sicht müssen wir insbesondere auch unsere Kinder vor der drohenden totalen Transparenz schützen. Somit 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 technisch möglich gewesen wäre, mitzulesen und auszuwerten. Heute verschwenden die weltbesten Datenanalysten ihr Potential für enorme Gehälter damit, personenbezogene Inhalte und Daten auszuwerten und zu Verbraucherprofilen zu verknüpfen, die möglichst zielgerichtete Werbung erlauben. Das ist absurd. Ich denke nicht, dass wir das damals so hätten vorhersehen können. Doch es ist nie zu spät, etwas zu ändern. Und genau das haben wir mit Brabbler vor.

18

Term ine to go

einfach aus

Schulungen 2017

der Hef tmitt

e heraus tren

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

Ort

nen

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

Tage

Anbieter

ASQF Certified Professional for Project Management 06.03.17 4 SQS ®

Frankfurt

20.03.17

Berlin

CMAP Mobile App Testing 16.01.17 2 Díaz & Hilterscheid Unternehmensberatung GmbH

4

SQS

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

Braunschweig

20.02.17

2

BREDEX GmbH

Hannover

27.02.17

2

Díaz & Hilterscheid Unternehmensberatung GmbH

Frankfurt

02.03.17

2

SQS

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

Braunschweig

20.03.17

2

BREDEX GmbH

Köln

30.03.17

2

SQS

Berlin

CMAP Mobile App Test Automation 18.01.17 3 Díaz & Hilterscheid Unternehmensberatung GmbH

Düsseldorf

22.02.17

3

CGI Deutschland Ltd. & Co. KG

Offenbach a.M.

22.02.17

3

Sogeti Deutschland GmbH

Hannover

01.03.17

3

Díaz & Hilterscheid Unternehmensberatung GmbH

Düsseldorf

15.03.17

3

Sogeti Deutschland GmbH

Berlin

iSQI ® Certified Agile Business Analysis 22.02.17 2 Díaz & Hilterscheid Unternehmensberatung GmbH

München

29.03.17

2

Sogeti Deutschland GmbH

Düsseldorf

30.03.17

2

CGI Deutschland Ltd. & Co. KG

München

iSQI ® Certified Agile Essentials 18.01.17 2 Loyal Team GmbH

Offenbach a.M.

06.02.17

2

Sogeti Deutschland GmbH

Berlin

09.02.17

2

Loyal Team GmbH

Hamburg

09.02.17

2

Loyal Team GmbH

Stuttgart

13.02.17

2

Sogeti Deutschland GmbH

Berlin

20.02.17

2

Díaz & Hilterscheid Unternehmensberatung GmbH

München

iSQI's CAT Certified Agile Tester ® 09.01.17 5 Sogeti Deutschland GmbH

Berlin

13.02.17

5

Díaz & Hilterscheid Unternehmensberatung GmbH

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

Düsseldorf

27.02.17

5

Sogeti Deutschland GmbH

Frankfurt

20.03.17

5

Integrata / CGI Deutschland Ltd. & Co. KG

Frankfurt

27.03.17

5

SQS

Wien

iSQI Certified Agile Test Driven Development (TDD) 14.03.17 3 ANECON

Düsseldorf

ISTQB ® Certified Tester – Foundation Level 09.01.17 4 Sogeti Deutschland GmbH

Berlin

04.01.17

3

Díaz & Hilterscheid Unternehmensberatung GmbH

München

09.01.17

4

ISARTAL akademie GmbH

Berlin

09.01.17

3

Díaz & Hilterscheid Unternehmensberatung GmbH

Erlangen

10.01.17

4

Method Park Consulting GmbH

Hamburg

16.01.17

4

SQS

STAND: November 2016

Köln

Hamburg

16.01.17

4

Díaz & Hilterscheid Unternehmensberatung GmbH

München

17.01.17

4

CGI Deutschland Ltd. & Co. KG

Stuttgart

17.01.17

4

Method Park Consulting GmbH

Berlin

23.01.17

3

Loyal Team GmbH

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

Düsseldorf

06.02.17

4

Sogeti Deutschland GmbH

München

06.02.17

4

SQS

Berlin

06.02.17

3

Díaz & Hilterscheid Unternehmensberatung GmbH

München

07.02.17

4

ISARTAL akademie GmbH

Wien

13.02.17

4

ANECON

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

München

20.02.17

4

Sogeti Deutschland GmbH

Frankfurt

20.02.17

4

SQS

Osnabrück

20.02.17

3

Díaz & Hilterscheid Unternehmensberatung GmbH

Frankfurt

21.02.17

4

CGI Deutschland Ltd. & Co. KG

Köln

22.02.17

3

Loyal Team GmbH

Hamburg

27.02.17

3

Loyal Team GmbH

München

27.02.17

3

Díaz & Hilterscheid Unternehmensberatung GmbH

Berlin

27.02.17

4

Díaz & Hilterscheid Unternehmensberatung GmbH

Berlin

01.03.17

3

Loyal Team GmbH

Frankfurt

06.03.17

3

Loyal Team GmbH

Offenbach a.M.

06.03.17

4

Sogeti Deutschland GmbH

München

06.03.17

4

ISARTAL akademie GmbH

Berlin / englische Sprache

06.03.17

4

Díaz & Hilterscheid Unternehmensberatung GmbH

Düsseldorf

07.03.17

4

CGI Deutschland Ltd. & Co. KG

Wien

07.03.17

4

OBJENTIS Software Integration GmbH

Hannover

13.03.17

4

SQS

Berlin

13.03.17

3

Díaz & Hilterscheid Unternehmensberatung GmbH

München

15.03.17

3

Loyal Team GmbH

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

Stuttgart

27.03.17

4

Sogeti Deutschland GmbH

Nürnberg

27.03.17

3

Díaz & Hilterscheid Unternehmensberatung GmbH

Berlin

ISTQB ® Certified Tester – Foundation Level Extension, Agile Tester 12.01.17 2 Díaz & Hilterscheid Unternehmensberatung GmbH

Frankfurt

19.01.17

2

Díaz & Hilterscheid Unternehmensberatung GmbH

Wolfsburg

23.01.17

2

sepp.med

Frankfurt

26.01.17

2

SQS

Stuttgart

26.01.17

2

Method Park Consulting GmbH

Bielefeld

26.01.17

2

Díaz & Hilterscheid Unternehmensberatung GmbH

Stuttgart

02.02.17

2

Díaz & Hilterscheid Unternehmensberatung GmbH

Berlin

09.02.17

2

Díaz & Hilterscheid Unternehmensberatung GmbH

Köln/Düsseldorf

16.02.17

2

Díaz & Hilterscheid Unternehmensberatung GmbH

Offenbach a.M.

22.02.17

2

Sogeti Deutschland GmbH

Osnabrück

23.02.17

2

Díaz & Hilterscheid Unternehmensberatung GmbH

Erlangen

27.02.17

2

Method Park Consulting GmbH

Hamburg

02.03.17

2

SQS

München

02.03.17

2

Díaz & Hilterscheid Unternehmensberatung GmbH

Frankfurt

09.03.17

2

Loyal Team GmbH

Köln

09.03.17

2

Loyal Team GmbH

Bremen

09.03.17

2

Loyal Team GmbH

Berlin

09.03.17

2

CGI Deutschland Ltd. & Co. KG

Berlin

09.03.17

2

Loyal Team GmbH

Berlin / englische Sprache

09.03.17

2

Díaz & Hilterscheid Unternehmensberatung GmbH

Düsseldorf

15.03.17

2

Sogeti Deutschland GmbH

Berlin

16.03.17

2

Díaz & Hilterscheid Unternehmensberatung GmbH

Hamburg

23.03.17

2

Loyal Team GmbH

Röttenbach

23.03.17

2

sepp.med

Dortmund

23.03.17

2

Díaz & Hilterscheid Unternehmensberatung GmbH

Nürnberg

30.03.17

2

Díaz & Hilterscheid Unternehmensberatung GmbH

Hamburg

ISTQB ® Certified Tester – Advanced Level, Test Manager 09.01.17 5 CGI Deutschland Ltd. & Co. KG

Berlin / englische Sprache

09.01.17

5

Díaz & Hilterscheid Unternehmensberatung GmbH

Wolfsburg

16.01.17

5

sepp.med

Stuttgart

30.01.17

5

Sogeti Deutschland GmbH

München

30.01.17

5

ISARTAL akademie GmbH

Stuttgart

06.02.17

5

Method Park Consulting GmbH

München

06.02.17

5

CGI Deutschland Ltd. & Co. KG

Frankfurt

06.02.17

5

Díaz & Hilterscheid Unternehmensberatung GmbH

Köln

13.02.17

5

SQS

Hamburg

20.02.17

5

SQS

Frankfurt

27.02.17

5

CGI Deutschland Ltd. & Co. KG

Bremen

01.03.17

5

Loyal Team GmbH

Frankfurt

06.03.17

5

SQS

Offenbach a.M.

13.03.17

5

Sogeti Deutschland GmbH

München

13.03.17

5

SQS

München

13.03.17

5

ISARTAL akademie GmbH

München

20.03.17

5

Sogeti Deutschland GmbH

Berlin

20.03.17

5

Díaz & Hilterscheid Unternehmensberatung GmbH

Wien

22.03.17

5 (exkl. Sa/So) ANECON

Düsseldorf

27.03.17

5

CGI Deutschland Ltd. & Co. KG

Berlin

29.03.17

5

Loyal Team GmbH

Hamburg

29.03.17

5

Loyal Team GmbH

Frankfurt

29.03.17

5

Loyal Team GmbH

Köln

29.03.17

5

Loyal Team GmbH

ISTQB ® Certified Tester – Advanced Level, Test Analyst 31.01.17 4 Loyal Team GmbH

Berlin Berlin

10.01.17

4

CGI Deutschland Ltd. & Co. KG

Hannover

23.01.17

4

Díaz & Hilterscheid Unternehmensberatung GmbH

Köln

23.01.17

4

SQS

Frankfurt

06.02.17

4

SQS

München

06.03.17

5

Method Park Consulting GmbH

München

07.03.17

4

CGI Deutschland Ltd. & Co. KG

Berlin

13.03.17

4

Díaz & Hilterscheid Unternehmensberatung GmbH

Hamburg

27.03.17

4

SQS

ISTQB ® Certified Tester – Advanced Level, Technical Test Analyst 16.01.17 3 Díaz & Hilterscheid Unternehmensberatung GmbH

Frankfurt Berlin

18.01.17

3

Loyal Team GmbH

Frankfurt

23.01.17

3

CGI Deutschland Ltd. & Co. KG

München

30.01.17

3

SQS

Erlangen

31.01.17

4

Method Park Consulting GmbH

Frankfurt

27.02.17

3

SQS

Berlin

06.03.17

3

Díaz & Hilterscheid Unternehmensberatung GmbH

München

15.03.17

3

CGI Deutschland Ltd. & Co. KG

München bei Isartal Akademie

20.03.17

4

Method Park Consulting GmbH

Köln

27.03.17

3

Loyal Team GmbH

Frankfurt

27.03.17

3

Loyal Team GmbH

Köln

27.03.17

3

SQS

Röttenbach Frankfurt München

ISTQB ® Certified Tester – Foundation Level Extension, Model-Based Tester 12.01.17 2 sepp.med 09.03.17

2

CGI Deutschland Ltd. & Co. KG

IREB ® Certified Professional for Requirements Engineering – Foundation Level 16.01.17 3 ISARTAL akademie GmbH

Frankfurt

23.01.17

3

SQS

Nürnberg

23.01.17

3

SOPHIST GmbH

Berlin

06.02.17

3

Díaz & Hilterscheid Unternehmensberatung GmbH

Frankfurt

06.02.17

3

SOPHIST GmbH

München

13.02.17

3

SOPHIST GmbH

München

20.02.17

3

ISARTAL akademie GmbH

Röttenbach

22.02.17

3

sepp.med

Hamburg

27.02.17

3

SQS

Frankfurt

01.03.17

3

SOPHIST GmbH

Wien

01.03.17

3

ANECON

Berlin

06.03.17

3

microTOOL GmbH

Berlin

20.03.17

3

Loyal Team GmbH

Hamburg

20.03.17

3

Loyal Team GmbH

Stuttgart

20.03.17

3

SOPHIST GmbH

München

27.03.17

3

ISARTAL akademie GmbH

Berlin

27.03.17

3

Díaz & Hilterscheid Unternehmensberatung GmbH

Berlin

IREB ® Certified Professional for Requirements Engineering – Advanced Level, Requirements Elicitation and Consolidation 20.03.17 3 Loyal Team GmbH

Hamburg

20.03.17

3

Loyal Team GmbH

Nürnberg

20.03.17

3

SOPHIST GmbH

Nürnberg Düsseldorf

IREB ® Certified Professional for Requirements Engineering – Advanced Level, Requirements Modeling 08.02.17 3 SOPHIST GmbH 28.02.17

3

SOPHIST GmbH

Berlin

20.03.17

3

Loyal Team GmbH

Hamburg

20.03.17

3

Loyal Team GmbH

IREB ® Certified Professional for Requirements Engineering – Advanced Level, Requirements Management 29.03.17 3 Methdo Park Consulting GmbH

München

ICPMSB Certified Professional for Medical Software 14.03.17 4 sepp.med

Röttenbach

27.03.17

Erlangen

4

Method Park Consulting GmbH

Köln

UXQB ® Certified Professional for Usability and User Experience, Foundation Level 13.03.17 3 ProContext Consulting GmbH

Köln

UXQB ® Certified Professional for Usability and User Experience - Advanced Level, User Requirements Engineering 13.03.17 4 ProContext Consulting GmbH 27.03.17

Nürnberg

Sonstiges 2

SOPHIST GmbH

AGILE

REQUIREMENTS ENGINEERING

SECURIT Y

MOBILE

SOF T WA RE TESTING

PROJECT MANAGEMENT

USABILITY

SPECIALISED

PRODUCT MANAGER

MEDICAL

WEITERE ANGEBOTE

Seminare 2017 Januar - März 2017

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

Seminartitel

Ort

Datum(Start) Tage Anbieter

Automotive SPICE - iNTACS™ certified Competent Assessor (englischsprachig)

Kornwestheim

23.01.17

5

KUGLER MAAG CIE GmbH

Automotive SPICE ® - iNTACS™ certified Provisional Assessor (englischsprachig)

Region Stuttgart

06.02.17

5

KUGLER MAAG CIE GmbH

Train-the-Trainer

München

13.02.17

3

ISARTAL akademie GmbH

Update zu Automotive SPICE v3.0 (deutschsprachig)

Kornwestheim

23.02.17

1

KUGLER MAAG CIE GmbH

GTB ® Certified Automotive Softwaretester

München

27.02.17

2

ISARTAL akademie GmbH

Agile in Automotive (deutschsprachig)

Kornwestheim

07.03.17

2

KUGLER MAAG CIE GmbH

360° Testautomatisierung

Wien

07.03.17

2

ANECON

TTCN-3 Training "Theory and Practice of TTCN-3" Automotive System Design nach ISO 26262 - TÜV Functional Safety Engineer ohne Prüfung (deutschsprachig) Automotive System Design nach ISO 26262 - TÜV Functional Safety Engineer mit Prüfung (deutschsprachig) Automotive SPICE ® - iNTACS™ zertifizierter Provisional Assessor (deutschsprachig)

Berlin

13.03.17

1

Spirent Technologies GmbH

Kornwestheim

14.03.17

3

KUGLER MAAG CIE GmbH

Kornwestheim

14.03.17

4

KUGLER MAAG CIE GmbH

Kornwestheim

27.03.17

5

KUGLER MAAG CIE GmbH

®

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

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

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

ANZEIGE

Ansprechpartner: Beatrice Michelis Trainings and Seminars Tel.: +49 331 231810-16 trainings@isqi.org

Alle Themen auch als Inhouse-Angebot buchbar!

SIE WOLLEN IHR SEMINAR AUCH IM NÄCHSTEN SQ-MAGAZIN BEWERBEN? Wir freuen uns über eine Nachricht. Bitte senden Sie uns Ihre Termine per E-Mail zu: trainings@isqi.org

STAND: November 2016

Das iSQI fungiert hier als Vermittler.

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

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

Testmanager (m/w)

Testspezialist (m/w)

netcare Business Solutions GmbH Frankfurt oder Neustetten

G. Muth Partners GmbH Wiesbaden

Senior IT Enterprise Architect (m/w)

IT & Process Support Specialist (m/w)

VON ESSEN GmbH & Co. KG Erlangen

netcare Business Solutions GmbH Neustetten

Consultant: Software Tester / Testautomatisierung (m/w)

Senior Software Quality Engineer (m/w)

Qytera Software Testing Solutions GmbH Eschborn

TecAlliance GmbH Ismaning

Testingenieur / System Test Engineer (m/w)

Software Tester - Quality Assurance

CORSCIENCE GmbH & Co. KG Erlangen

beQualified GmbH Köln

Senior IT Enterprise Architect (m/w)

Junior / Senior Softwaretester (m/w)

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

VON ESSEN GmbH & Co. KG Bankgesellschaft Essen

OMNINET GmbH Eckental

ckc group Braunschweig

Consultant: Software Tester – Testmanagement/ Software Testmanager (m/w) Qytera Software Testing Solutions GmbH Eschborn

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

Softwareentwickler (m/w) Medizintechnik CORSCIENCE GmbH & Co. KG Erlangen

Softwaretester / Mitarbeiter IT Qualitätssicherung (m/w) affilinet GmbH Hannover

Software Tester (m/w) Panasonic AVC Langen Langen

Technical Software Tester (m/w) im Bereich Testautomatisierung & Lastund Performance Tests netcare Business Solutions GmbH Neustetten

Hier könnte Ihre Anzeige stehen!

Schreiben Sie uns unter info@asqf.de

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

iSQI NEWS

Ausgabe 41 | Dezember 2016

24

iSQI gründet Start-up-Booster High5 Die Start-up-Metropole Berlin bekommt tatkräftige Unterstützung. Angetrieben vom erfolgreichen Start im vergangenen Jahr, legt die Start-upFörderinitiative „HIGHFIVE powered by iSQI“ nun mit einer eigenen Firmengründung namens High 5 – The Startup Booster nach. Ziel ist es, junge Unternehmen noch intensiver als bisher zu unterstützen. „Wir planen unter anderem, bei vielversprechenden Gründungen finanziell 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 International Software Quality Institute, Träger der Förderinitiative HighFive, seinen erfolgreichen Kurs fort. Die neue Niederlassung in Berlin ist ein konsequenter Schritt nach vorn. „Damit können wir gezielt vor Ort Start-

Aus dem iSQIKonferenzplaner 2017 05. - 09.12.2016 Agile Testing Days // Potsdam 07.12.2016 ASQF Quality Day // Berlin 07.12.2016 SIGIST 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.2017 UKStar // London 10.03. -19.03.2017 SXSW // Austin 20.03. - 22.03.2017 7th World Congress for Software Quality // Lima

ups im Bereich Mitarbeiteraus- und -weiterbildung beraten und fördern“, erklärt Stephan Goericke, „Erfahrungsgemäß 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 Abseits. Deshalb unterstützen wir mit High5 insbesondere die Weiterbildung und unabhängige Zertifizierung von (IT)-Fachkräften.“ Mehrere deutsche Start-ups hat die Initiative bereits erfolgreich unterstützt, u.a. bei der weltgrößten Digitalmesse 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 Das International Software Quality Institute (iSQI) hat im Oktober eine Kooperationsvereinbarung mit dem United Kingdom Testing Board (UKTB) für die Zertifizierung des Certified Mobile Application Professional (CMAP) unterzeichnet. 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 zusammensetzt. Der Standard wurde von mehreren der ISTQB® National Boards und Exam Provider weltweit angenommen und verabschiedet.

Debbie Archer, Managing Director der iSQI Ltd, sagt zu dem Kooperationsvertrag: „CMAP hat sich zu einem weltweiten Standard im Bereich mobi-

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

25

TMMi®-Zertifizierungen iSQI ist exklusiver Prüfungsanbieter Die TMMi® (Test Maturity Model Integration) Foundation hat das International Software Quality Institute (iSQI) zum exklusiven Prüfungsanbieter für die Zertifizierung zum TMMi® Professional 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 Einzelpersonen ein Höchstmaß an Servicequalitä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 Programms“, erklärt Les Murray, Chairman des TMMi® Foundation Board of Directors.

TMMi® Professional Certification eignet sich für alle, die ein Verständnis des TMMi® -Modells und die damit verbundene Verbesserung von Testprozessen entwickeln wollen. Inhaber des TMMi® Professional Certificate

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

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

Stephan Goericke zum Kurator des Fraunhofer Institut FOKUS berufen Das Kuratorium des Fraunhofer Institut für offene Kommunikationssysteme (FOKUS) hat Stephan Goericke, Geschäftsführer des Potsdamer International Software Quality Institute (iSQI GmbH), zu seinem neuen Mitglied berufen. Der 43-jährige wird in den kommenden Jahren gemeinsam mit hochrangigen Vertretern aus Politik, Wirtschaft und Wissenschaft das Fraunhofer FOKUS bei der strategischen Ausrichtung beraten.

FOKUS erforscht fortgeschrittene Technologien für eine barrierefreie Kommunikations-Infrastruktur. Es entwickelt städtische IT-Infrastrukturen und berät die Industrie, öffentliche

Verwaltungen und Organisationen bei der Konzeption und Umsetzung ihrer IT-Strategien. Mit rund 500 Mitarbeitern ist es eines der größten Fraunhofer-Institute. „Ich bedanke mich für das entgegengebrachte Vertrauen und freue mich auf viele spannende Projekte!“, erklärte das neue Kuratoriumsmitglied Stephan Goericke.

Goericke gilt als ausgewiesener Experte in der international standardisierten Ausbildung und Zertifizierung von IT-Fachkräften. Bereits seit 2005 leitet er als Geschäftsführer das weltweit tätige International Software Quality Institute mit Hauptsitz

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

Best Practice

Ausgabe 41 | Dezember 2016

Wenn die Digitalisierung die Usability herausfordert von Rudolf Grötz & Joachim Niederreiter Traurig, aber wahr: Usability war für Unternehmens-Anwendungen, die in den 2000er Jahren entwickelt wurden, das Letzte, worum sich die Entwickler Gedanken machten. Meist ging es nur darum, einen bestehenden manuellen Prozess 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 Transformation) bleibt auf der Strecke.

Es ist nicht immer möglich Anwendungen „Mobile First“ zu realisieren. Trotzdemw ist es sinnvoll, 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 umzubauen und fit für die neuen Herausforderungen zu machen. Auch die IT-­Anwendungen müssen diesen neuen Herausforderungen gerecht werden. Schließlich muss die IT-­Abteilung gemein-

Service Definition im neuen Design - Mobile Ready

sam mit den anderen Fachbereichen fachlich und technisch integrierte Gesamtlösungen definieren 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 Ready“ machen konnte.

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

26

27

Die grafische Benutzeroberfläche von Cisco ServiceGrid (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“ Anwendung wurde Funktionalität über Jahre nur hinzugefügt. Die Usability wurde nicht ausreichend berücksichtigt, speziell in Bezug auf mobile Endgeräte. Diese Versäumnisse kamen zutage, als es nach Jahren der klassischen Optimierung für Desktop-Webbrowser notwendig wurde, die Applikation für Tablets verfügbar zu machen. Um eine gute Usability auf mobilen Endgeräten zu ermöglichen, musste nicht nur die Benutzerschnittstelle angepasst werden. Es war auch notwendig, die wichtigsten Geschäftsprozesse der Anwendung an die Arbeitsweise der Zielgruppe (IT-­Administratoren) anzupassen.

Folgende Anforderungen galt es bei der Umsetzung zu berücksichtigen:

Rückwärtskompatibilität der bestehenden Backend-­F unktionalität, keine Beeinträchtigung der Release-Zyklen der bestehenden Legacy-­A pplikation, keine Beeinträchtigung der laufenden Entwicklungsprojekte der Legacy-­A pplikation, Berücksichtigung von iOS und AndroidTablets, Fast Feedback durch einen zweiwöchigen Release-Zyklus, Power-­User (Admin) müssen ihre Geschäftsprozesse schneller bedienen können, die Benutzeroberfläche muss den Workflow unterstützen und nicht umgekehrt.

weiter auf der nächsten Seite

Best Practice Für die Umsetzung all dieser Anforderungen waren neue Herangehensweisen 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 einen Ansatz via User-­Centered Design.

CSG-­IT verbrachte eine beträchtliche Menge Zeit vor dem Zeichenbrett, um die bestehenden Anwendungsabhängigkeiten zu verstehen, bevor die neuen und innovativen Ansätze eingeführt werden konnten.

Folgende Grundsätze für die Entwicklung wurden definiert: die Gestaltung beruht auf einem umfassenden Verständnis der Benutzer, Arbeitsaufgaben 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 Kenntnisse und Perspektiven vertreten.

Die Projektanforderung bestand in der Implementierung eines neuen Produkts mit dem Namen Cisco ServiceGrid 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 entschieden, 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 Benutzeroberfläche haben sich in den letzten Jahren stark verändert. Sie sind mitt-

Ausgabe 41 | Dezember 2016

lerweile eine der wichtigsten Herausforderungen bei der Gestaltung einer modernen Applikation. So können beim Redesign, bis hin zu einer mobilen Anwendung, die Prinzipien und das bestehende Layout der DesktopVersion nicht einfach in die mobile Welt übertragen werden.

CSG-­IT musste neue Wege beschreiten, um diesen Herausforderungen begegnen zu können. User-­ Centered Design, Contextual Inquiry, FokusGruppen und UX-­Prototyping sind nur einige der Schlagworte, auf die im Folgenden eingegangen wird.

Wichtigstes Ziel war es, den Benutzer in den Mittelpunkt der Anforderungen zu stellen und durch den Einsatz neuer Methoden und Techniken sicherzustellen, dass die User Experience den Erwartungen der Benutzer gerecht wird.

Im Ergebnis enstand eine Benutzeroberfläche, die komfortabler, bequemer und intuitiver zu bedienen ist.

28

fläche befragt. Es wurden Meinungen eingeholt, Wünsche und Bedürfnisse dokumentiert. In offenen Diskussionen innerhalb kleiner Gruppen wurden folgende Fragen erörtert: Wie kommen die Benutzer mit dem derzeitigen Produkt zurecht, was ist ihre subjektive Meinung?

Wie wird es aktuell genutzt und eingesetzt, welche Schwierigkeiten treten dabei auf?

Falls es mehrere Lösungsvarianten innerhalb der grafischen Oberfläche gibt, welche 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 SysContextual Inquiry (CI) tems, die Möglichkeiten es zu steuern. Hierzu gehört auch die RückmelContextual Inquiry ist ein benutzer-­ dungen an den Benutzer. zentrierter Ansatz, um die AnfordeDie Erkenntnisse aus den Fokus-Gruprungen an die Benutzerschnittstelle pen wurden anschließend mit Methozu erforschen. Interviews sind nicht den aus dem Interaction Design aufgeeignet, um implizites Wissen abgearbeitet. Nachdem das für CSA zurufen, deshalb wird bei Contextual Neuland war, wurden externe SpeziaInquiry der Benutzer bei seiner Arbeit listen in das Scrum-­Team aufgenombeobachtet. Parallel dazu werden mit men. Das ID hat seinen eigentlichen ihm die Tätigkeiten und Abläufe im Ursprung im Web-­und Grafik-­Design, Kontext diskutiert. und hat sich daraus ständig weiterentIm Rahmen von CI wurden u.a. folwickelt. Interaction Designer sind weit gende Sichten der Anwender betrachdavon entfernt, nur mit Texten und tet: Rollenteilung und Kommunikation, Grafiken zu arbeiten. Sie sind verantHandlungsstrategien und Vorgehen, wortlich dafür, jedes Element auf dem kulturelle und soziale Einflüsse und Bildschirm zu kreieren, mit dem der das physische Umfeld. Danach wurBenutzer agiert. den auf Basis dieser Informationen die Nutzerführung und die notwendiPersonas gen Funktionen des neuen Systems erarbeitet.

Personas sind prototypische Benutzer in Bezug auf das zukünftige Produkt.

Fokus-Gruppen Ihre Definition erfolgt aufgrund angenommener Ziele und VerhaltensweiMit Unterstützung sogenannter Fosen im Kontext des Produkts. kus-Gruppen wurden die Benutzer in Im vorliegenden Fall entwarf der Proden einzelnen Projektphasen zu ihren duct Owner Vorschläge und validierte Anforderungen an die grafische Oberdiese gemeinsam mit dem Team, um

29

festzustellen, ob diese die für das Produktdesign relevanten Eigenschaften der Benutzer widerspiegelten.

Personas wurden erstellt, um zum Zeitpunkt der Entwicklung der Benutzerschnittstelle die richtige Design-­ Entscheidungen treffen zu können.

Szenarien Szenarien beschreiben anhand realistischer Beispiele in einfachen Sätzen oder mittels Kärtchen an einer Pinnwand, wie ein Benutzer mit dem geplanten System interagieren wird. Es geht dabei stärker um inhaltlich richtige Aussagen als um formale Korrektheit, ähnlich wie bei Personas. Szenarien können interaktiv entwickelt oder in Workshops gemeinsam mit den Benutzern erarbeitet werden. Durch ihre hohe Verständlichkeit erleichtern sie die Zusammenarbeit zwischen Benutzern und Entwicklern in den Bereichen Erhebung und Validierung von Anforderungen, Spezifikation, Testszenarien und Schulung.

Benutzerperspektive Im Anschluss verwendete das Projektteam die Personas und Szenarien, um aus deren Blickwinkel das System zu betrachten. Die Diskussionen wurden dadurch aus der Sicht der Personas und nicht aus eigener Erfahrung geführt. Damit änderte sich auch der Inhalt der Diskussionen in den Workshops, er wurde objektiver. Im nächsten Schritt war es dann leichter, für jede Benutzergruppe die passende Benutzerschnittstelle zu entwerfen.

Das Produktmanagement begann zusätzlich etwaige Konkurrenzprodukte zu evaluieren und auch dort gewonnene Erkenntnisse einzubringen.

UX-­Prototyping

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 folgenden Fragen: Was sind die wichtigsten Gruppen von Inhalten?

Wo liegt die Struktur der Daten?

Wie sieht die grundlegende Visualisierung der Benutzer-­Schnittstelle und der Interaktion aus?

Rudolf Grötz ist Engineering Manager bei CISCO ServiceGrid Austria und verantwortlich für den Bereich Software Test.

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

Usability-Tests In Usability-­ Tests wurde die neu erstellte Benutzeroberfläche von ausgewählten, realen Anwendern getestet, um verifizieren zu können, wie einfach die Anwendung schlussendlich zu bedienen ist.

Die Anwender mussten Aufgaben (Szenarien) erledigen, während sie von Usability Engineers und dem Product Owner beobachtet wurden.

Dabei wurden auch Fragen beantwortet, 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 einen Entwickler oder Designer vorgenommen werden.

Für den eigentlichen Entwurf der Fazit Benutzerschnittstelle, wurde UX-­ Prototyping eingesetzt.

Das Ziel von User-­ Centered Design Im ersten Schritt wurden die grundist eine möglichst hohe Gebrauchslegenden Ideen auf Papier skizziert. tauglichkeit (Usability) des neuen

Joachim Niederreiter ist Senior Engineering Manager bei CISCO ServiceGrid Austria.

Produkts. Im Mittelpunkt steht der künftige Nutzer, seine Ziele, seine Aufgaben und seine Eigenschaften. Ein Prototyping Workshop gemeinsam mit Anwendern und Entwicklern mag unkonventionell erscheinen, die aufgewendete Zeit wird aber durch den Gewinn an wertvollen Einsichten und Erkenntnissen mehr als aufgewogen.

Im weiteren Verlauf des Projekts können dann Zeit und Kosten gespart und die Akzeptanz der Benutzer erhöht werden.

Im Rahmen von User-­ Centered Design finden neue, nutzerorientierte Vorgehensmodelle, wie Contextual Inquiry für die Business-Analysen und Fokus-Gruppen-Verwendung. Für die Modellierung und Spezifikation kommen neue Ansätze wie Interaction Design, Personas, Szenarien und UX-­ Prototyping zum Einsatz.

Titelthema

Ausgabe 41 | Dezember 2016

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

30

31

W

as genau verstehen wir unter „User Experience“? Und wie unterscheidet sich User Experience von Usability? Eines steht fest: Unternehmen, die IT-Systeme mit hoher Usability und User Experience herstellen, haben Erfolg.

Qualität = Nutzungsqualität x technische Qualität

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

Nutzungsqualität beschreibt alle Dimensionen, die Käufer und Benutzer von Produkten aktiv wahrnehmen.

Hierzu gehören:

duktqualität, die die Voraussetzung für Nutzungsqualität sind. Hierzu gehören: Funktionale Angemessenheit Performanz Kompatibilität (mit anderen Produkten) Zuverlässigkeit

Usability (dt. Gebrauchstauglichkeit) Der Begriff Qualität ist unstrittig. Jedes nachhaltig agierende Unternehmen, stellt die Qualität seiner Produkte und Dienstleistungen in den Mittelpunkt der Entwicklung. Doch bereits hier ist die Betrachtung von Usability und User Experience wichtig. Neue ISO-Standards unterscheiden zwischen Nutzungsqualität (Human-centred quality) und technischer Qualität (technology-centred quality).

Usability als Voraussetzung für User Experience Der Begriff „Usability“ (dt. Gebrauchstauglichkeit) hat in der Produktentwicklung bereits eine längere Historie als der Begriff „User Experience“.

Usability ist keine Frage des persönlichen Geschmacks. Die DIN EN ISO 9241-11 definiert Usability als „das Ausmaß, in dem ein Produkt durch bestimmte Nutzer in einem bestimmten Nutzungskontext genutzt werden kann, um bestimmte Ziele effektiv, effizient und zufriedenstellend zu erreichen“.

Effektiv heißt hierbei „die Genauigkeit und Vollständigkeit, mit der Benutzer ein bestimmtes Ziel erreichen“ Effizient heißt hierbei „der im Verhältnis zu Genauigkeit und Vollständigkeit eingesetzte Aufwand, mit dem Benutzer ein bestimmtes Ziel erreichen“ Zufriedenstellend bedeutet „Freiheit von Beeinträchtigungen und positive Einstellung gegenüber der Nutzung des Produkts“

Security Accessibility (dt. Barrierefreiheit) Wartbarkeit User Experience (dt. Benutzererlebnis) Portierbarkeit Avoidance of use-related risks (dt. Freiheit von Risiken, die aus der Nutzung resultieren können) Technische Qualität wiederum beschreibt alle Dimensionen von Pro-

Soweit, so gut. Im Grunde genommen können Benutzer mit den meisten Produkten das gewünschte Ziel genau und vollständig erreichen. Das eigentliche − nach wie vor bestehende − Problem bei der Benutzung von Produkten 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 schaffen. Die Konsequenz: Unzufriedenheit mit der Benutzung des Produkts und – im gewerblichen Kontext – hohe Kosten für ineffizientes Arbeiten…

Aber welche Faktoren sind es, die die Benutzung eines Produkts gezielt effizient machen und aus Nutzersicht „intuitiv“? Auch hier gibt es eine Norm, die DIN EN ISO 9241-110, die die sogenannten „Grundsätze der Dialoggestaltung“ beinhaltet sowie über 50 Empfehlungen für deren Umsetzung.

Sieben Faktoren bestimmen maßgeblich die effiziente Nutzung eines Produkts.

Effizienz aus Benutzersicht wird primär erreicht durch:

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

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 genau 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 unmittelbar benutzbar, es ist keine Schulung erforderlich.

Steuerbarkeit Der Benutzer kann bei der Erledigung seiner Aufgabe konsequent in die Richtungen gehen, die aus Sicht der Aufgabe erforderlich sind (ohne Umwege und „Neueinstieg an anderer Stelle“).

Titelthema

Ausgabe 41 | Dezember 2016

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

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

Fehlertoleranz Der Benutzer wird vom System vor Fehlern geschützt, beziehungsweise, wenn der Benutzer Fehler gemacht hat, kann er diese mit minimalem Aufwand beheben.

Individualisierbarkeit Der Benutzer kann das User Interface selbst anpassen und individuelle Voreinstellungen treffen, die seinen physischen Gegebenheiten gerecht werden (z.B. Schriftgröße) oder Spezifika seines Kontextes berücksichtigen (z.B. bestimmte Default-Einstellungen).

User Experience im Unterschied zu Usability Zunehmend wird in Entwicklungsprojekten nicht nur über „Usability“ diskutiert, sondern auch über „User Experience“. Aber seien wir ehrlich, so richtig weiß keiner, was der Unterschied ist, oder? Fragt man Beteiligte 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 gebrauchstauglicher interaktiver Systeme“ enthalten und wie folgt definiert: User Experience (Benutzererlebnis): Wahrnehmungen und Reaktionen ei-

Abbildung 1 illustriert den Zusammenhang zwischen Usability und User Experience. Platt gesagt betrachtet „Usability“ die tatsächliche Nutzungssituation selbst, während „User Experience“ darüber hinaus die antizipierte Nutzung und die Verarbeitung 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 potentiellen Käufers statt. Wenn das Produkt hierbei „durchfällt“, weil bestimmte Aspekte der Gestaltung aus Nutzersicht hinderlich eingeschätzt werden, dann wird das Produkt eben eher nicht gekauft, auch wenn es sich

32

in der Nutzung als gebrauchstauglich erweist. So lässt sich auch z.B. der Misserfolg vieler Universalfernbedienungen erklären, die beim bloßen Betrachten 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 bereits 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“ erlebt. Aber auch simple Aufgaben wie der Check-In bei Fluggesellschaften erfordern Methodiken der Anforderungsanalyse aus Benutzersicht und der User-Interface-Konzeption, um

33

einerseits „usable“ zu sein und andererseits hohe User Experience zu erreichen, sprich positive Wahrnehmungen und Reaktionen beim Benutzer.

Schauen wir uns als Beispiel eine App zum „Online Check-In“ für Flugreisende an. Zahlreiche Flugreisende checken 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 „geschlossen“ sind. Der typische Ablauf ist so, dass der Fluggast von seiner Fluggesellschaft rechtzeitig eine E-Mail erhält mit einem Link auf die Check-In-Möglichkeit. 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 Fluggesellschaft „verschaukelt“ fühlen, da zunächst die Information kommt, man könne sich einchecken, es dann aber (augenscheinlich) gar nicht geht. Dieses negative Benutzererlebnis (User Experience) beruht auf einem Usability-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ähigkeit).

Die Illustrationen in Abbildung 2 zeigen nur einen kleinen Ausschnitt aus einem insgesamt nicht aufgabenangemessenen, nicht selbstbeschreibenden und nicht erwartungskonformen Ablauf aus Benutzersicht, der in Summe zu negativer User Experience führt und den Online Check-In in seiner Leistungsfä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 Qualifikation derjenigen Mitarbeiter, die beim Herleiten der Nutzungsanforderungen, der Konzeption der User Interfaces und dem Testen der Usability Hand anlegen. 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 werden 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 vorbereitende Trainings der anerkannten Trainingsanbieter des UXQB ist zu finden unter http://uxqb.org/de/vorbereitende-trainings/ trainingskalender.

Im Fokus

Ausgabe 41 | Dezember 2016

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

Kann eine erweiterte Fault Seeding Methode die Fehlerfindungsrate steigern und zu einem geringerem Restrisiko beitragen? Diese Frage widmete sich Michael Altmann in seiner Masterarbeit „Weiterentwicklung der Fault Seeding Methode zur Steigerung der Testeffizienz“, die er unter der Leitung von Dr. Mohsen Ekssir an der Fachhochschule Wiener Neustadt 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 Effizienz verbessern kann. Wie aber die Testeffizienz gemessen wird und welche Faktoren dabei eine Rolle spielen, kann projekt­ abhängig unterschiedlich ausfallen. Generell treten bei den Testaufgaben und im Zuge des Testprozesses zwei große wichtige Fragen auf: Wie hoch ist der aktuelle Fehlerentdeckungsgrad 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?

34

35

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 Methode entwickelt und im Jahr 1972 veröffentlicht [1, S. 442]. Das Problem dabei ist, dass das Fault Seeding Ergebnis lediglich für eine allgemeine Einschätzung des aktuellen Standes des Fehlerentdeckungsgrades und der Restfehleranzahl ausreicht. Grund dafür ist der sehr begrenzte Datenbestand, der zur Auswertung gewonnen werden 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 wurden und welche nicht. Diese Ergebnisse 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 Fehlerentdeckungsgrad (Information über die Test-Qualität) und die Restfehleranzahl (Information über die Software-Qualität).

Nach dem Standardglossar der Testbegriffe des ISTQB®/GTB wird unter Fault Seeding das absichtliche Einfügen von künstlichen Fehlerzuständen in eine Komponente oder ein System verstanden. Das Ziel ist, aus dem Anteil der aufgedeckten künstlichen 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 verursachen. Die künstlichen Fehlerzustände können unterschiedlich eingebaut werden, wie z.B.:

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

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

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

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

Ersetzen einer Variable Einfügen einer Bomb-Anweisung (Produziert einen Fehlerfall) Ersetzen eines Parameters beim Methodenaufruf 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 bestimmen, ist aber ohne eine Vorstudie (Vorbereitungsphase) über die bisher gefundenen realen Fehler und deren Häufigkeitsverteilung nicht möglich.

Deswegen ist die Phase der Fehlermodellierung besonders wichtig.

Die Erweiterung der Methode Um die reale Fehlerverteilung auf Basis gemeldeter Software-Fehler bei diesem Forschungsprojekt zu bestimmen, mussten zuerst die SoftwareFehler, die im Zuge der Komponenten- und Integrationstests, gefunden wurden, nach mehreren Fehlertaxonomien klassifiziert werden. Da aber die bereits gefundenen Fehler nicht mit erforderlichen Informationen versehen waren, wurden sie im ersten Schritt neu analysiert und mit weiteren 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 Anforderungen 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 Informationen 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 bisherigen realen Fehlerverteilung des Systems liefert das Fundament für das Design und die Modellierung der einzupflanzenden künstlichen Fehlerzustände.

Diese erweiterte Fault Seeding Methode liefert mehr als zwei einzelne Zahlenwerte zur Beurteilung der Restfehleranzahl und des Fehlerentdeckungsgrades, 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 Weiterentwicklung von Fault Seeding als „Orthogonal Fault Seeding“ bezeichnet. [2, S.442] Orthogonal Fault Seeding-Methode Die Vorgehensweise für die Durchführung der Orthogonal Fault Seeding Methode wurde, wie in Abbildung 1 dargestellt, in fünf Phasen unterteilt: PHASE 1 FEHLERMODELLIERUNG Diese Phase beinhaltete die Modellierung der künstlichen Fehlerzustände, die später in die zu testende Software eingepflanzt wurden. Diese Aufgabe wurde manuell durch-

Im Fokus

Ausgabe 41 | Dezember 2016

Bei Fault Seeding gilt die Annahme, dass die Relation der Anzahl der gefundenen künstlichen Fehlerzustände zu der Gesamtanzahl der künstlichen Fehlerzustände und die Relation der Anzahl der gefundenen realen Fehlerzustände zu der Gesamtanzahl der realen Fehlerzustände gleich ist:

Planung und Vorbereitung durchführen Fehler modellieren

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

Ja

Durchgang Fehler injizieren

36

Tests durchführen

Weitere Durchgänge?

Primärergebnisse ermitteln

Nein Ergebnis interpretieren

Auswertung durchführen

Abbildung 1

geführt. Basis dafür war die reale Fehlerverteilung, die in der Vorbereitungsphase gewonnen wurde. Die Verteilung der künstlichen Fehlerzustä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 eingepflanzten 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 Fehlerzuständen.

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

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|

führten Tests auch eine bestimmte Anzahl von realen Fehlerzuständen entdeckt (|Frealfound|).

Die Relation der Anzahl der gefundenen künstlichen Fehlerzustände zu der Gesamtanzahl der künstlichen Fehlerzustände ist ein Indiz für den Fehlerentdeckungsgrad der Software-Tests.

PHASE 5 ANALYSE UND INTERPRETATION In dieser Phase wurden die ermittelten Zahlen analysiert und interpretiert. Die relevanten Variablen, wie in Abbildung 2 dargestellt, sind: |F seededtotal| Gesamtzahl der

künstlichen Fehlerzustände |F seededfound| Anzahl der gefundenen

künstlichen Fehlerzustände |F realtotal| Gesamtzahl der realen Fehlerzustände |F realfound| Anzahl der gefundenen

realen Fehlerzustände |F total| Anzahl der realen und künstlichen Fehlerzustände im System |F found| Anzahl der gefundenen realen und künstlichen Fehlerzustände F seededtotal

F realtotal

F seededfound

F realfound

Abbildung 2

F total F found

Die Restfehleranzahl ergibt sich dann aus der Differenz der gesamten realen Fehlerzustände und den davon gefunden Fehlerzuständen. Diese Restfehleranzahl bestimmt die Software-Qualität. Die Test-Qualität wird über den Fehlerentdeckungsgrad (FEG) ermittelt. 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 SoftwareProjekt des Unternehmens TechTalk eingesetzt. In diesem kamen automatisierte Komponenten- und Integrationstests zur Anwendung. Das Ziel der empirischen Untersuchung war, die Qualität der im Projekt verwendeten Testsuites zu bestimmen und Optimierungspotenziale in diesen zu identifizieren. Danach sollten Optimierungsmaßnahmen abgeleitet und umgesetzt werden, um die Testsuites weiter zu verbessern und die Testeffektivität zu erhöhen. Zu diesem Zweck wurde die empirische Untersuchung wie im Folgenden beschrieben abgearbeitet.

1. ORTHOGONAL FAULT SEEDING ZYKLUS Die Aktivitäten Fehlermodellierung, Fehlerinjizierung, Testdurchführung und Berechnung der Software-Metriken wurden durchlaufen. Am Ende standen folgende Software-Metriken zur Verfügung: Gesamtfehlerentdeckungsgrad Restfehleranzahl Fehlerentdeckungsgrad des Komponenten- und Integrationstests Fehlerentdeckungsgrad pro Klasse nach den Fehlertaxonomien Fehlerart, Schweregrad und Position im Code Auf Basis der im ersten Zyklus gewonnenen Informationen wurden Optimierungspotenziale in den eingesetzten 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 Software-Fehler vom eigenen Testteam aufgedeckt werden [3, S. 36]. Nach dieser Richtlinie stellt ein Fehlerentdeckungsgrad unter 80 Prozent ein Mangel in der Testsuite dar.

In der Abbildung 3 ist der Fehlerentdeckungsgrad pro Klasse nach der Fehlertaxonomie Fehlerart zu sehen.

Die Fehlerentdeckungsgrade von Anforderungs-, Datenfluss- und Schnittstellenfehler wurden als mangelhaft deklariert, da diese nur einen Wert von 60 Prozent erreichten.

Folgende Mängel konnten im Komponenten- und Integrationstest des Projektes identifiziert werden: Unzureichender Gesamtfehlerentdeckungsgrad Unzureichender Fehlerentdeckungsgrad von Anforderungs- und Schnittstellenfehlern beim Integrationstest Unzureichender Fehlerentdeckungsgrad von Blocker-Fehlern bei Komponentenund Integrationstest Unzureichender Fehlerentdeckungsgrad mancher Klassen bei Komponenten- und Integrationstest

Fehlerentdeckungsgrad [%]

37

100 80

Komponententest

60

Integrationstest

40

Gesamt

20 0 KF

A

DF

S

B

Abbildung 3

Diese Mängel bildeten die Grundlage für die Ableitung der Optimierungsmaßnahmen, wie die Änderung vorhandener Testfälle bzw. Hinzufügen zusätzlicher Testfälle im Integrationstest, die besonders auf die Entdeckung von Anforderungsfehlern, Datenflussfehlern, Schnittstellenfehlern und Blocker-Fehlern abzielten.

Aufgrund von Beschränkungen der personellen und zeitlichen Ressourcen zielten die Maßnahmen nur zur Verbesserung des Integrationstests ab. Der Komponententest wurde nicht verändert bzw. erweitert. Das Entwicklungs- bzw. Testteam hat von insgesamt 39 Integrationstestfällen sieben 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, inwiefern die umgesetzten Optimierungsmaß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 1. Fault Seeding Zyklus

2. Fault Seeding Zyklus

Gefunden vom Komponententest Gefunden vom Integrationstest Nicht gefunden

Abbildung 4

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

Ergebnis Abschließend lässt sich durch den empirischen Teil der Arbeit festhalten, dass die Weiterentwicklung Orthogonal Fault Seeding eine geeignete Methode im Software-Entwicklungs- und Testprozess darstellt, um die Effektivität der Testaktivitäten zu verbessern und eine höhere Software- und TestQualität zu erreichen.

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

LITERATUR: [1] S. L. Pfleeger and J. M. Atlee, Software Engineering Theory and Practice, Fourth Edition. Pearson Higher Education, 2010. [2] R. Chillarege, I. S. Bhandari, and J. K. Chaar, Orthogonal Defect Classification – A Concept For In-Process Measurements. IEEE Transactions on Software Engineering, Vol 18, No 11, 1992. [3] H. M. Sneed and S. Jungmayr, “Produktund Prozessmetriken für den Softwaretest,”InformatikSpektrum, vol. 29, no. 1, pp. 23–38, 2006.

Im Gespräch

38

Ausgabe 41 | Dezember 2016

Auszeichnung für den Branchennachwuchs Als erster Preisträger erhielt Stefan Meiler vor zehn Jahren den ASQFFörderpreis. Die mit 500 Euro dotierte Auszeichnung wird einmal im Semester an Studenten und/oder Absolventen verliehen und würdigt besonders gute Leistungen während des Studiums, eine kurze Studiendauer und eine Abschlussarbeit, die in besonderem Maße Praxisnähe und Software-Qualitätsaspekte berücksichtigt. In Kooperation mit verschiedenen Hochschulen wird der ASQF-Förderpreis derzeit an der FU Berlin, FH Brandenburg, BTU Cottbus, FH Nürnberg, Friedrich-AlexanderUniversitä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 nachgefragt.

Herr Meiler, Sie erhielten als Erster den ASQF-Förderpreis, der an besonders vielversprechende Nachwuchstalente vergeben wird. Was bedeutete die Auszeichnung für Sie? Ich habe mich über die Auszeichnung damals sehr gefreut. Der Förderpreis war eine schöne Abrundung eines

Stefan Meiler

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 kennenzulernen. 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 angefertigt 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 Siemens Healthineers gewechselt. Noch spannender als die Realisierung von IT-Systemen fand ich die Möglichkeit, Prozesse und Dienstleistungen zu entwickeln. Aktuell leite ich ein globales Team, das aus Daten Geschäftswerte generiert. Dabei harmonisieren wir Datenflüsse, generieren Transparenz durch KPI-Systeme, optimieren Prozesse und entwickeln innovative digitale Dienstleistungen. Da gibt es noch viel zu gestalten.

Was würden Sie heutigen Absolventen 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 bewegen kann. Für mich geht dabei weniger um das Programmieren, sondern viel mehr um das, was man damit erreichen kann.

Das Interview führte Christin Senftleben.

Fachgruppentermine: Dezember 2016 - März 2017 DEZEMBER

01.12.2016: FG Software-Test, NRW 18:00 – 20:00 Uhr

KW

07.12.2016: FG Software-Test, Berlin/Brandenburg 09:00 – 17:30 Uhr

48

Thema: Qualitätssicherung für das Internet der Dinge

49

5

6

15.12.2016: FG Automotive, Bayern-Süd, Ingolstadt 18:00 – 20:00 Uhr

50

12

51

19

52

KW

Thema: Der Einsatz von Open Source Tools für Safety and Security MÄRZ

DEZEMBER 2016

Thema: Zustandsbezogener Test: Methoden & Werkzeugdemonstration

Mo

Di

Do

Fr

Sa

1

2

3

4

7

8

9

10

11

13

14

15

16

17

18

20

21

22

23

24

25

26

27

28

29

30

31

Mo

Di

28.03.2017: FG Safety and Security, Rhein-Main 18:00 – 20:00 Uhr Vorankündigung

So

MÄRZ 2016

40

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

Mi

Mi

Do

Fr

Sa

1

2

3

4

So 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

Quiz

Impressum Sudoku HERAUSGEBER

5

ASQF e.V.

2

6

Die Lösung des letzten

4

Sudokus lautete:

Friedrich-Engels-Str. 24, 14473 Potsdam Tel

+49 331 231810-29

Fax

+49 331 231810-10

info@asqf.de, www.asqf.de REDAKTION V.i.S.d.P.: Stephan Goericke (Hauptgeschäftsführer)

8 6

7 1

9

Chefredaktion: Christin Senftleben Redaktionsteam: Julia Schirmer, Anja Schreinert, Isabel von Gustedt

3

Die Gewinner aus Heft 40 sind:

9 6

4

GEBURTSTAGSSPASS

1

Claas Henning Wrede, Bremen

7

2

3 9

Christian Odenthal, Köln

2

Peter Engelhardt, Mannheim

6

5

8

2

Sonja Kloppig, Ludwigsburg Thierry Dalon, Neutraubling

2

Friedrich-Engels-Str. 24, 14473 Potsdam Tel

+49 331 231810-56

Fax

+49 331 231810-10

redaktion@sq-magazin.de, www.sq-magazin.de

5 1

9 6

SATZ / LAYOUT Frenkelson Werbeagentur, Potsdam www.frenkelson.de FOTOS: ASQF e.V. und iSQI GmbH

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

Titel: ©Rawpixel_ shutterstock Seite 3: ©Karoline Wolf Seite 8-9: ©Rawpixel_ shutterstock 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: ©Rawpixel_ shutterstock Seite 34: ©Bubbers BB_ shutterstock

Alle Portraits und Grafiken mit freundlicher

Mitmachen und gewinnen!

Ein effizientes Requirements Engineering ist Grundlage für erfolgreiche Software-Projekte.

Dieses Buch zeigt, wie Workshops zur schrittweisen Ermittlung von Anforderungen effektiv gestaltet werden können. Der Autor geht dabei über eine theoretische Betrachtung allgemeiner Methoden hinaus und tief hinein in die Mühen der täglichen Arbeit als Product Owner, Projektleiter, Business

Analyst oder Requirements Engineer. Die einzelnen Schritte in der Anforderungsermittlung sind entlang einer durchgängigen Vorgehensweise 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-Moderationspläne.

Lösungswort des Gewinnspiels an info@asqf.de.

Gewinnen Sie eines von fünf Büchern.

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

Genehmigung der Autoren.

DRUCK: PRINTEC OFFSET, Kassel 2017

DRUCKAUFLAGE: 4.000 Stück INTERNETAUSGABE: www.sq-magazin.de MEDIADATEN Gern senden wir Ihnen unsere Mediadaten zu.

Richten Sie Ihre Anfrage an werben@sq-magazin.de Namentlich gekennzeichnete Beiträge müssen nicht mit der Meinung der Redaktion übereinstimmen. Die Redaktion behält sich das Recht auf sinngerechte Kürzung und Bearbeitung eingereichter Manuskripte vor. Wir machen darauf aufmerksam, dass Daten nicht an Dritte weitergegeben und ausschließlich zur internen Auswertung herangezogen werden können.

№ 42

erscheint im März 2017

SQ № 42 Thema: Mehr Qualität durch DevOps Anzeigenschluss: 22.02.2017 Redaktionsschluss: 01.03.2017

SQ-Themenschwerpunkte Im kommenden Jahr widmen wir uns den folgenden Themen: SQ 42 (Märzausgabe): Mehr Qualität durch DevOps SQ 43 (Juniausgabe): Qualitätssicherung in der Digitalisierung SQ 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