Suche
Wie die Qualitätssicherung von morgen aussehen kann

Next Generation QA

André Neubauer, Manfred Rätzmann

Image licensed by Ingram Image

Die Entwicklung und der Betrieb von Software haben sich in den vergangenen Jahren deutlich verändert. Agile Vorgehensweisen, Test-driven Development, Continuous Integration und DevOps sind erwachsen geworden und werden in immer mehr Unternehmen eingesetzt. Wie positioniert sich aber die Qualitätssicherung (QA) in diesem stark veränderten Umfeld?

Mit dem Aufkommen und der Akzeptanz von agilen Methoden in der Softwareentwicklung wurde ein umfassender Veränderungsprozess eingeleitet, der sich häufig nicht nur auf die IT, sondern auch auf das restliche Unternehmen ausgeweitet hat.

Ein Ergebnis dieses Wandels ist ein verändertes Verständnis des Softwareentwicklungsprozesses. Die Silos Dev, QA und Ops sowie das „über den Zaun werfen“ neuer Softwareversionen gehören in einem modernen Verständnis von Softwareentwicklung der Vergangenheit hat.

Software Craftsmanship hat dazu geführt, dass Softwareentwickler mehr Verantwortung für ihren Code übernehmen. Dazu zählen unter anderem Praktiken wie Testautomatisierung und Continuous Integration. Gleichzeitig sorgt die DevOps-Bewegung dafür, dass der Weg in die Produktion nahtlos gangbar wird. Die (mehrfach) tägliche Auslieferung von Software in Produktion ist schon lange kein Zukunftsszenario mehr.

Dies alles führt dazu, dass der angestammte Platz der QA-Abteilung im Softwareentwicklungsprozess immer enger wird. Klassische Aufgaben wie das manuelle Software-Testing reduzieren sich, da große Teile davon bereits crossfunktionale Produktentwicklungsteams durch automatisierte Tests auf allen Ebenen erledigen. Bei Releases im Minutentakt kann sowieso nur noch automatisiert getestet werden. Was bleibt dann aber für die QA übrig? James A. Whittaker, einer der Autoren von „How Google Tests Software“, provozierte sein Auditorium bereits 2011 mit der Aussage: „Test is dead! Welche Rolle spielt QA also zukünftig in der Produktentwicklung?“

Dies ist allerdings nur die eine Seite der Medaille. Auf der anderen Seite ist Qualität in einer Welt, in der die Konkurrenz nur einen Klick entfernt ist, zu einem unverzichtbaren Attribut eines jeden Produkts geworden. Immer häufiger wird Qualität deshalb zu einem wesentlichen Differenzierungsmerkmal, das Unternehmen kontinuierlich ausweiten. So ist es zum Beispiel üblich geworden, Kunden nach der Benutzung des Produkts um Feedback zu bitten. Einige Unternehmen, wie zum Beispiel der Onlinehändler Zappos, gehen noch einen Schritt weiter und erheben Qualität zu einem zentralen Unternehmenswert.

Eine der wohl bekanntesten Untersuchungen zum Einfluss von Qualität auf Produkte lieferte Google 2009. Schon eine Verlangsamung der Google-Suche um Bruchteile einer Sekunde führte laut dieser zu einer reduzierten Nutzung der Suchmaschine um bis zu 0,5 Prozent – hochgerechnet auf alle Suchanfragen ist das eine deutliche Auswirkung.

Aus den beiden Strömungen ergibt sich ein scheinbarer Widerspruch. Während die Qualität eines Produkts immer mehr an Bedeutung gewinnt, schwindet in Unternehmen die Notwendigkeit von QA-Abteilungen. Unternehmen wie Facebook verzichten von vornherein auf eine gesonderte QA-Abteilung. Jeder Entwickler soll selbst dafür Sorge tragen, dass sein Code funktioniert und ausreichend getestet ist. Damit stellt sich die Frage, welche Rolle die QA künftig in der Produktentwicklung spielen wird.

Um diesen augenscheinlichen Gegensatz aufzulösen, muss man einen Schritt zurückgehen. Wenn man sich den Qualitätsbegriff selbst anschaut, stellt man schnell fest, dass sich das Verständnis von Softwarequalität grundlegend geändert hat.

Softwarequalität gestern und heute

Software war früher ein Werkzeug, mit dem in Branchen oder Wissenschaftszweigen ganz bestimmte, eng eingegrenzte Arbeiten erledigt wurden. Dabei wurde die dem Arbeitsablauf innewohnende Komplexität oder Kompliziertheit auf die Software übertragen. Software automatisierte diese Abläufe und wurde dadurch selbst als notwendigerweise komplex oder kompliziert angesehen. Es war ganz normal, dass man zum Verständnis einer Software eine ähnliche Lernkurve erklimmen musste wie zum Verständnis der fachlichen Domäne, die von der Software unterstützt wurde.

Deshalb wurde Softwarequalität früher hauptsächlich als Korrektheit, Robustheit und Effizienz von Software empfunden. Später kam die Benutzerfreundlichkeit hinzu. Als eher weiches Kriterium hatte es die Benutzerfreundlichkeit aber immer schon schwer, sich gegen die harten Kriterien Korrektheit, Robustheit und Effizienz zu behaupten. Wenn ein Tester umständliche Bedienung monierte, wurde das, und wird es auch heute noch, als Minor Error angesehen. Wer kennt nicht Aussagen wie „It works as designed!“ oder „Nun stellen Sie sich mal nicht so an. Der eine Klick mehr oder weniger ist doch völlig egal, da haben wir wichtigere Probleme“?

Anhand dieses klassischen Verständnisses lässt sich auch die Position von QA-Abteilungen im Produktentwicklungsprozess erklären. Qualitätssicherung erfolgte nach der Entwicklung und vor der Inbetriebnahme der Softwarelösung und konzentrierte sich vor allem auf die technische Umsetzung. Bedingt durch lange Releasezyklen war es oberstes Ziel, vor allem die harten Kriterien sicherzustellen.

Heute ist Software ein allgegenwärtiger Bestandteil unseres Lebens geworden und deshalb wird Softwarequalität auch ganz anders wahrgenommen. Softwarequalität ist kein Zustand, den man als letzten Schritt vor dem nächsten Release noch schnell in sein Produkt hineintesten kann. In einem offenen und komplett individualisierten Kundenmarkt gibt es keine Qualität an sich mehr. Qualität ist immer Qualität für eine konkrete Person. Qualität ist nicht einfach da oder fehlt – Qualität wird erlebt.

Eine ganzheitliche Sicht auf Softwarequalität

Die Qualität, die ein Kunde erlebt, speist sich aus seinen individuellen Bedürfnissen. Einen Ansatz zu einem ganzheitlichen Qualitätsbegriff bietet Maslows Hierarchie der menschlichen Bedürfnisse. Die Maslowsche Bedürfnispyramide (Abb. 1) lässt sich auch als Hierarchie unterschiedlicher Aspekte von Softwarequalität nutzen, die alle befriedigt werden müssen, um ein größtmögliches Qualitätserleben beim Kunden sicherzustellen.

Abb. 1: Softwarequalität, definiert an der Maslowschen Bedürfnishierarchie

Abb. 1: Softwarequalität, definiert an der Maslowschen Bedürfnishierarchie

In der Hierarchie der Bedürfnisse stellen die physiologischen Bedürfnisse die grundlegenden Bedürfnisse zum Beispiel nach Nahrung und Schlaf dar. Auf die Qualität einer Software bezogen bedeutet das, dass die Software zunächst einmal überhaupt verfügbar und lauffähig sein muss. Wenn ihr Funktionsumfang im richtigen Verhältnis zu den unterstützten Aufgaben steht und die Software diese Aufgaben ausreichend performant erledigt, wird dies bereits als generell vorhandene, grundlegende Qualität empfunden.

Die nächst höhere Stufe von Bedürfnissen umfasst die Sicherheitsbedürfnisse. Die Hierarchie in diesem Modell besagt nicht, dass die vorherige Bedürfnisstufe komplett befriedigt sein muss, bevor sich weitere, höhere Bedürfnisse einstellen. Vielmehr reicht es aus, wenn die grundlegenden Bedürfnisse zu einem Mindestmaß befriedigt sind, um neue Bedürfnisse entstehen zu lassen. Auf der anderen Seite lässt sich die Befriedigung einzelner Bedürfnisse aber auch quantitativ nicht beliebig weit treiben. Ein Vergleich hierzu: Wenn man ausgeschlafen und gesättigt ist, ist ein Mehr an Schlaf und Nahrung nicht das Bedürfnis, das gerade am stärksten motivierend wirkt.

Auf Softwarequalität bezogen bedeutet das zum einen, dass Robustheit, Sicherheit und Verständlichkeit erst dann relevant werden, wenn die Software auf dem Device des Kunden überhaupt lauffähig ist und das tut, was sie soll. Zum anderen heißt das aber auch, dass ein Mehr an Funktionalität beim Kunden oft nicht das erwartete Qualitätserlebnis auslöst, wenn auf dieser Bedürfnisstufe eine gewisse Sättigung erreicht ist, und die Kunden inzwischen weitergehende Qualitätsbedürfnisse entwickelt haben. Während für den potenziellen Kunden der Nutzen im Mittelpunkt steht, ist dieser für den nutzenden Kunden bereits bekannt, stattdessen wird Qualität erwartet. Dies ist auch der Grund, warum die häufig gestellte Frage „Features oder Qualität?“ von vielen Kunden mit „mehr Qualität“ beantwortet wird.

Die Sicherheitsbedürfnisse umfassen neben der Robustheit und Sicherheit im Umgang mit der Software auch Verständlichkeit. Das Gefühl von Einfachheit schützt den Nutzer vor der Angst vor Fehlern und dem eigenen Versagen. Auch der barrierefreie Zugang gehört in diese Kategorie.
Wenn die physiologischen Bedürfnisse und die Sicherheitsbedürfnisse zu einem gewissen Grad befriedigt sind, tauchen weitere, in ihrem Wesen soziale Bedürfnisse auf. Wichtig kann dann zum Beispiel sein, ob die eingesetzte Software in den Kreisen des Kunden anerkannt ist. Die Marktführerschaft eines Produkts ist in diesem Zusammenhang von höherer Bedeutung als der eigentliche Funktionsumfang. Für den eigenen Anwendungsfall besser geeignete Alternativen treten in den Hintergrund. Die Motivation hierfür liegt auch in dem Sicherheitsbedürfnis, sich bei Problemen an große Communitys oder soziale Netzwerke wenden zu können.

Aber auch das genau entgegensetzte Verhalten, eben nicht die Marktführersoftware einzusetzen und damit einen Wunsch nach Abgrenzung zu befriedigen, beschreibt ein soziales Bedürfnis. Für die bewusste Differenzierung wird auch gerne die eine oder andere Qualitätseinbuße auf niedrigerer Stufe in Kauf genommen. An diesem Beispiel ist sehr gut zu sehen, dass man bei dem vorgeschlagenen Modell nicht streng hierarchisch vorgehen kann. Einerseits müssen grundlegendere Bedürfnisse bis zu einem gewissen Grad befriedigt sein, damit höhere Bedürfnisse ins Spiel kommen können. Auf der anderen Seite haben die höheren Bedürfnisse für den Kunden aber auch häufig einen höheren Stellenwert, was dazu führt, dass grundlegendere Bedürfnisse zu Gunsten von höheren Bedürfnissen zurückgestellt werden.

Jenseits der sozialen Bedürfnisse liegen bei Maslow die Individualbedürfnisse: Esteem – in der direkten Übersetzung also Wertschätzung, Achtung oder Hochachtung. Hier geht es um den Wunsch nach Stärke und Unabhängigkeit, aber auch nach Prestige und Anerkennung. Bezogen auf Softwarequalität entspricht dies dem Bedürfnis, mithilfe der Software etwas tun zu können, was aus eigener Kraft nicht oder nicht so einfach möglich wäre.

Die fünfte und letzte Stufe in diesem Modell (später hat Maslow sein Modell verfeinert und um die Stufe „Transzendenz“ erweitert) bildet die Selbstverwirklichung. Eine Software, die es ermöglicht, eigene Wege zu gehen und eigene Ideen umzusetzen, wird grundsätzlich als qualitätsvoller angesehen als eine Software, die eng auf den vorgegebenen Lösungsansatz fixiert ist.

Während das klassische Verständnis von Softwarequalität hauptsächlich die physiologischen und Sicherheitsbedürfnisse berücksichtigt hat, muss ein Bemühen um Qualität heute vor allem auch die oberen Bedürfnisstufen im Blick behalten. Dadurch, dass Software in immer persönlichere Bereiche unseres Lebens vordringt, kommen neben einem erhöhten Sicherheitsbedürfnis auch neue soziale und individuelle Aspekte von Softwarequalität ins Spiel. Verfügbarkeit, Robustheit, passende Funktionalität werden hingegen einfach vorausgesetzt und führen mitunter zu massiven Beschimpfungen in App-Stores, wenn sie nicht in ausreichendem Maße vorhanden sind.

Das alles gilt nicht nur für den Consumer-Markt. Die Tatsache, dass alle zu ständigen Software-Consumern geworden sind, färbt auch auf die Erwartungshaltung gegenüber Businesssoftware ab. Dass eine Software sich auch ohne intensives und langwieriges Studium eines Benutzerhandbuchs bedienen lassen muss, ist inzwischen zur Selbstverständlichkeit geworden und entscheidet wesentlich über Erfolg und Misserfolg der Software.

Von der lokalen Qualitätssicherung zum ganzheitlichen Quality Engineering

Die aufgezeigte Änderung des Verständnisses von Softwarequalität zeigt auch den Weg aus dem oben beschriebenen Widerspruch auf: Weil sich das Qualitätsempfinden ganzheitlich aus den persönlichen Bedürfnissen speist, kann auch die Antwort nur vom Produkt als Ganzem gegeben werden. Der gesamte Prozess von der Produktidee über die Realisierung, den Betrieb bis hin zum Abschalten und zur Migration der Kunden auf ein Nachfolgeprodukt ist betroffen. In dieser Denkweise wird Qualitätsmanagement Teil des Produktmanagements. Aus einer lokalen Qualitätssicherung wird ein ganzheitliches Quality Engineering.

Quality Engineering meint Qualitätsmanagement und Qualitätssicherung über alle Stationen des Produktentwicklungsprozesses und Lebenszyklus, angefangen bei Product Discovery über Experience Design, Entwicklung und Betrieb, aber auch den notwendigen Aufräumarbeiten, wenn ein Produkt aus dem Markt genommen wird. In all diesen Phasen bietet die Hierarchie der menschlichen Bedürfnisse eine Orientierung für ein besseres, weil ganzheitliches Verständnis des Qualitätserlebens des Kunden.

Tabelle 1: Qualitätsaspekte

Tabelle 1: Qualitätsaspekte (zum Vergrößern bitte anklicken)

Product Discovery sollte nicht nur hinterfragen, welchen Nutzen ein Produkt zukünftigen Kunden bieten kann, sondern auch, welche Technologien (Cloud, Mobile, Wearables etc.) im anvisierten Kundensegment angenommen und welche eher abgelehnt werden, sowie welchen Stellenwert Sicherheit, Robustheit und Einfachheit für die zukünftigen Kunden hat. Die User Experience beschäftigt sich nicht nur mit möglichst intuitiven Abläufen, korrekt positionierten Buttons und allgemein verständlichen Formulierungen, sondern auch mit dem gerade angesagten Look and Feel, Vertrautheit der symbolischen Sprache und Dauer und Intensität des Nutzungserlebnisses. Somit erweitert sie das eigene Tätigkeitsfeld zu einem umfassenden Experience Design. Die Entwicklung und der Betrieb achten darauf, dass die entwickelte Software nicht nur robust, korrekt und performant ist, sondern verständlich, offen für Erweiterungen, jederzeit verfügbar und verknüpfbar mit anderen Anwendungen.

Gleichzeitig bilden die aufgeführten Phasen aber auch die Struktur einer modernen Software- oder Produktentwicklungsorganisation ab. Wenn Qualität das „True North“ einer Organisation ist, dann ist Quality Engineering der Weg dahin. Die Aufgabe einer umfassenden Qualitätssicherung in allen Phasen des Produktentwicklungsprozesses kann dabei nicht einer QA-Abteilung allein überlassen werden. Die ganze Organisation ist gefragt.

Die neuen Aufgaben der QA

Treiber für den notwendigen Wandel kann durchaus die QA-Abteilung sein. Dazu muss sie sich letztendlich noch nicht einmal selbst abschaffen. Sie muss sich allerdings verändern. Zwei Schwerpunkte lassen sich aus dem veränderten Qualitätsverständnis für eine Organisation ableiten.
Die Veränderung, die die Agiltität mit crossfunktionalen Teams schon gebracht hat, muss noch viel weiter gedacht werden. Der Quality Engineer im Team ist nicht nur dafür da, bei der Testautomatisierung zu unterstützen und das explorative Testen regelmäßig durchzuführen, sondern sämtliche Qualitätsbemühungen zu koordinieren und darauf zu achten, dass in allen Phasen des Entwicklungsprozesses das Qualitätserlebnis des Kunden den Ausschlag gibt. Sein Aufgabenbereich umfasst die Analyse von Benutzertests und die Unterstützung des Product Owners bei der Arbeit am Backlog ebenso wie die Zusammenarbeit mit dem Team bei der Qualitätssicherung der harten Kriterien neuer Features. Er achtet auf eine aktuelle und ausreichende Dokumentation des Domänenwissens sowie auch auf die technischen Entscheidungen und auf das Monitoring und die Weiterentwicklung der internen Kennzahlen.

Der Quality Engineer im Team ist am besten beschrieben als spezialisierter Generalist im Dienste des Kunden. Die Spezialisierung liegt im Fokussieren auf die ganzheitliche Struktur des Qualitätserlebnisses und der daraus resultierenden Aspekte von Softwarequalität. Diese Spezialisierung wird durch generelles Wissen um die Fallstricke und Notwendigkeiten in den einzelnen Phasen des Produkt- und Softwareentwicklungsprozesses ergänzt.

Darüber hinaus kann und sollte sich (je nach Größe des Unternehmens) aber auch eine übergreifende QA-Abteilung um Themen kümmern, die nicht im Fokus der Teams liegen, wobei die IT keine logische Grenze darstellen darf. Dazu gehören ein organisationsweites Wissensmanagement sowie die kontinuierliche Überprüfung der Qualitätsbemühungen und Einführung neuer Verfahren. Genauso ist aber auch die tagtägliche Lobbyarbeit im Unternehmen, um den Qualitätsgedanken im Unternehmen voranzutreiben, vergleichbar mit einem Scrum Master, der die agilen Werte vertritt, eine wesentliche Aufgabe.

Zusammenfassung

Es reicht also nicht, eine möglichst hohe Testabdeckung zu erzielen, neueste Architekturen und Technologien einzusetzen oder einen zertifizierten Qualitätsmanagementprozess zu implementieren. Die Qualität, die ein Kunde erlebt, speist sich aus seinen individuellen Bedürfnissen. Der Ausbruch der Software aus der reinen Arbeitswelt sowie die Individualisierung der Kunden rufen nach einem ganzheitlichen Qualitätsverständnis.

Mit agilen Methoden wird ein erster Schritt in diese Richtung getan. Automatisierung von Tests sowie von Build- und Deployment-Prozessen entlastet die QA-Abteilung und ermöglicht ihr, den Qualitätsanspruch im gesamten Unternehmen zu implementieren. Wer diesen Weg beschreitet, wird Qualität zu einem zentralen Wert der Organisation erheben und seinen Kunden einen noch besseren Service bieten.

Geschrieben von
André Neubauer
André Neubauer
André Neubauer leitet bei der E-POST das Geschäftsfeld „Digitales Büro“. Seit über fünf Jahren widmet er sich dem Thema Agilität und dem ganzheitlichen Einsatz in Unternehmen. Er ist regelmäßiger Sprecher auf Konferenzen, Autor von Fachartikeln sowie Koautor des Buchs „Agile Projekte mit Scrum, XP und Kanban im Unternehmen durchführen“.
Manfred Rätzmann
Manfred Rätzmann
Manfred Rätzmann leitet die Abteilung Qualitätssicherung beim E-POST Development am Standort in Berlin. Von Hause aus Softwareentwickler, hat er sich früh auf Qualitätssicherung und agile Vorgehensweisen spezialisiert. Er ist Autor diverser Fachartikel und Bücher sowie regelmäßiger Sprecher auf Konferenzen rund um die Themen Qualität und agile Vorgehensweisen.
Kommentare

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
400
  Subscribe  
Benachrichtige mich zu: