04/05/2023

IBM iX Quality Approach: Qualitätssicherung standardisieren

Services Technologie Trends Projekte IBM iX Ways of Working Blogartikel

Autor: Boris Arapovic

Illustration, die Qualitätssicherung, Planung und Konzept visualisieren soll.

In Zusammenarbeit mit dem Entwicklungsteam, Scrum Mastern und Product Ownern hat das IBM iX Quality Engineering Team ein Konzept für einen Quality Approach – Qualitätsansatz – entwickelt, der in jedem Softwareentwicklungsprojekt als Leitfaden zur Qualitätssicherung dienen kann.

Selten sind Unternehmen mit nur einem Projekt beschäftigt. In der Regel laufen viele parallel und befinden sich in unterschiedlichen Stadien – einige stehen gerade erst am Anfang, andere sind kurz vor dem Abschluss oder aber das Projektende ist noch gar nicht in Sicht. In diesem dynamischen Feld kann die Qualität der Projekte sehr unterschiedlich sein. Die Herausforderung besteht darin, den Spagat zwischen einheitlicher Qualitätssicherung und den notwendigen Freiräumen für effektives Arbeiten, zu schaffen. Die Definition von klaren und präzisen Richtlinien und Standards kann dabei helfen, bei allen Projekten ein bestimmtes Qualitätsniveau zu sichern.

Der Qualitätsansatz (Quality Approach)

Der Qualitätsansatz zeichnet sich durch die Integration von Best Practices aus. Die anwendungsnahe Annäherung unterstützt unsere Qualitätsingenieur*innen und -teams dabei, sich mit den neuen Standards vertraut zu machen und Erwartungen von vorneherein zu klären. Außerdem sind wir stets bestrebt, unseren Ansatz so schlank und einfach wie möglich zu halten und nur die Informationen aufzunehmen, die wirklich relevant sind. Der Quality Approach wird in der Regel von unseren Qualitätsingenieur*innen in die Projekte eingeführt und stellt sicher, dass alle Beteiligten an einem Strang ziehen:

Relevante Testarten

Um sicherzustellen, dass wir die richtigen Tests durchführen, kann das Team aus einer Liste von geeigneten Testarten, auswählen. Diese Testarten umfassen auch obligatorische Tests, die für jedes Projekt erfolgen sollten, wie z. B. Penetrations- oder Leistungstests. Um die Informationen verständlich zu machen, haben wir die Testarten anhand der agilen Testquadranten geclustert. Für jeden Testtyp enthält unser Blueprint detaillierte Beschreibungen und Empfehlungen, damit das Team genau weiß, was es zu tun hat. Die Liste ist dabei aber nicht in Stein gemeißelt.

Festgelegte Testtypen für die Automatisierung

Die Automatisierung ist ein wichtiger Bestandteil der Qualitätssicherung. Das Projektteam entscheidet, welche Testtypen genutzt und wie sie automatisiert werden sollen. Um dem Team den Einstieg zu erleichtern, stellen wir Boilerplate-Repositories zur Verfügung (z. B. ein Boilerplate für die UI-Testautomatisierung mit Cypress).

Erforderliche Testumgebungen

Um ein ordnungsgemäßes Testen eines Produkts zu gewährleisten, empfehlen wir mindestens zwei Testumgebungen – eine für das Testen neu entwickelter Funktionen während eines Sprints und eine weitere für das Testen vollständiger Versionen. Mehrere Testumgebungen ermöglichen gründliche Tests in verschiedenen Entwicklungsstadien und verringern das Risiko von Bugs und Fehlern.

Richtlinien für den Testentwurf

Unsere Projektteammitglieder können sich auf unsere Top-10-Testheuristiken stützen, um ihre Testbemühungen für eine bestimmte Funktion zu steuern. Diese Heuristiken stützen sich auf Elisabeth Hendricksons Buch „Explore It! Reduzieren Sie das Risiko und erhöhen Sie das Vertrauen mit Exploratory Testing“. Wenn ein Team beispielsweise ein Zahlenfeld, wie das Altersfeld, testen muss, kann es die „Null, Eins, Viele Heuristik“ aus den Testrichtlinien verwenden. Bei diesem Ansatz werden verschiedene Eingaben getestet, z. B. die Eingabe von keinem Alter, die Eingabe der Zahl 0, die Auswahl einer Zahl innerhalb des erwarteten Bereichs (29) und die Verwendung einer Zahl außerhalb des erwarteten Bereichs (1000).

Fehler-Management

Bugs können frustrierend sein, aber mit einer angemessenen Bug-Policy können sie effektiv verwaltet werden. Das Projektteam entscheidet über die Bug-Policy, aber auch hier kann die entwickelte Bug-Vorlage genutzt und den Zero-Bug-Policy-Prozess aus dem Blueprint wiederverwendet und angepasst werden.

Browser-Matrix

Das Testen auf verschiedenen Browsern und Geräten, der Browser Matrix, ist wichtig. Es soll damit sichergestellt werden, dass die Software auf den richtigen Browsern und Geräten getestet wird. Das Projektteam entscheidet, welche das sind, der Blueprint stellt dem Team eine Vorlage und unsere Best-Practice-Browser-Matrix zur Verfügung.

Warum brauchen wir einen Blueprint?

Unsere Entwicklungsteams konzentrieren sich stets darauf, Projekte höchster Qualität abzuliefern, und dies erfordert einen sorgfältigen Balanceakt. Bei IBM iX wissen wir nur zu gut, wie schwierig es ist, ein Gleichgewicht zwischen Qualitätssicherung und Freiheit zu finden. Aus diesem Grund haben wir gemeinsam mit unserem Quality Engineering Team ein Konzept entwickelt, das uns hilft, die Qualitätsstandards zu erfüllen und unseren Teams gleichzeitig die nötige Freiheit zu geben.

Was war uns wichtig?

Bei der Entwicklung des Qualitätskonzepts hatten wir klare Ziele vor Augen: Wir wollten Best Practices integrieren, Standards setzen, es einfach halten und an unterschiedliche Kontexte anpassen. Mit diesem Ansatz können wir die Qualität unserer Projekte sichern und gleichzeitig Innovationen fördern.

Wir sind der Überzeugung, dass es für die Förderung von Innovation und Kreativität entscheidend ist, unseren Teams die Freiheit zur Anpassung des Qualitätsansatzes an die Bedürfnisse ihrer spezifischen Projekte zu geben. Indem wir den Teams die Möglichkeit geben, den Ansatz an ihre Bedürfnisse anzupassen, können wir sicherstellen, dass sie über die Werkzeuge und Ressourcen verfügen, die sie für den Projekterfolg benötigen.

Letztlich hängt der Erfolg eines Softwareentwicklungsprojekts vom richtigen Gleichgewicht zwischen der Standardisierung, der Qualitätssicherung und dem notwendigen Freiraum für eine effektive Arbeit ab. Der Blueprint dient als Ausgangspunkt für jedes Projekt und umfasst Kernelemente wie relevante Testtypen, festgelegte Testtypen für die Automatisierung und erforderliche Testumgebungen. Mit diesem Ansatz wollen wir die Qualität unserer Projekte sicherstellen und gleichzeitig Innovation und Kreativität fördern.