Design for Testing – Wie, wir müssen das noch testen?

In der Mikroelektronik wird bei der Chipentwicklung der Ansatz des „Design for Testing“ genutzt. Um Fehler zu vermeiden, wird bereits frühzeitig in der Designphase an der späteren Testbarkeit der Schaltungen gearbeitet. Dieses Vorgehen führt zu einer Erhöhung der Testbarkeit der Baugruppen und damit auch zu einer Reduktion der Kosten. Die Empfehlungen des „Design for Testing“ lassen sich auch auf Softwareentwicklungsprojekte übertragen. Dieser Beitrag stellt zwei Werkzeuge vor, die es den Entwicklungsteams ermöglichen, sich frühzeitig Aspekten der Qualitätssicherung zu nähern und das auf einem einfachen und spielerischen Wege.

Meist stehen bei Entwicklungsprojekten die Überlegungen zur Funktionalität und der Mehrwert für den Kunden im Vordergrund. QA und Testbarkeit kommen dadurch bei der Planung zu kurz. So treten während der Testphase Hürden für das Team auf, welche sich durch eine gewisse Voraussicht bei der Planung der QA-Aufgaben umgehen lassen. Tester haben für die Planung der höheren Teststufen bereits ein geeignetes Vorgehen: ein detailliertes Testkonzept, welches die Testziele dokumentiert sowie entsprechende Maßnahmen und eine Zeitplanung festlegt (Abb. 1).

Abbildung 1: Aspekte der Teststrategie / Inhalte eines Testkonzepts

Diese Detailtiefe eignet sich aber nicht für agile Projekte und Entwicklungsteams. Trotzdem sollte sich das Team vor dem Start eines Projektes über die meisten Aspekte, die im Testkonzept genannt werden, Gedanken machen. Darum haben wir ein Hilfsmittel entwickelt, welches es den Teams ermöglicht, alle Maßnahmen für eine optimale Testbarkeit in Softwareprojekten mit einzubeziehen. Das Hilfsmittel berücksichtigt sowohl die Fragen „Was ist zu testen?“ als auch „Wie und wo wollen wir testen?“.

Um die erste Frage „Was ist zu testen?“ im Hinblick auf Softwareprodukte zu beantworten, ist die Ausprägung der Qualitätskriterien der umzusetzenden Anforderungen ausschlaggebend. Die unterschiedlichen Qualitätskriterien sind in der ISO 25010 „Qualitätskriterien und Bewertung von System und Softwareprodukten (SQuaRE)“ enthalten (Abb. 2).

 
Abbildung 2: Qualitätskriterien nach ISO 25010

Je nachdem wie stark die umgesetzten Anforderungen auf die Qualitätskriterien einzahlen, ergibt sich die Notwendigkeit, diese Qualitätskriterien mit einer entsprechenden Testart zu prüfen. So verlangen Apps mit hohem Datendurchsatz nach Effizienztests und Webshops sollten auf Kompatibilität in verschiedenen Browsern geprüft werden.

Um den Teams den Einstieg in das Thema zu erleichtern, nutzen wir den QA-Oktant. Folgend der ISO 25010 beinhaltet der QA-Oktant die Qualitätskriterien für Softwaresysteme. Sie geben aber auch einen Hinweis auf die notwendigen Testarten, welche sich aus der gesetzten Gewichtung der unterschiedlichen funktionalen und nichtfunktionalen Kriterien ergeben (Abb. 3).

Abbildung 3: Der QA-Oktant mit gewichteten Qualitätskriterien

Durch die einfache Visualisierung und Gewichtung der unterschiedlichen Qualitätskriterien kann der QA-Oktant für die Planung genutzt werden. Product Owner können damit die Übersicht über relevante Anforderungen behalten und das Team kann gemeinsam mit dem Product Owner die Anforderungen anhand der Qualitätskriterien einordnen. Durch die Gewichtung im Team können unterschiedliche Meinungen besser wahrgenommen und eine gemeinsame Einordnung anschaulich dokumentiert werden. Aus dem Ergebnis lassen sich die notwendigen Testarten ableiten.

Um die zweite Frage „Wie und wo wollen wir testen?“ zu beantworten, müsste das Team den gesamten Entwicklungsprozess nach Test- und QA-Aspekten durchforsten und diese dokumentieren. Je nach Projekt kann der Entwicklungsprozess unterschiedlich ausgeprägt sein und damit die Fragestellung schnell recht komplex werden lassen (Abb. 4).

Abbildung 4: Entwicklungs- und QA-Prozess

Um auch hier den Teams einen mühelosen Einstieg in das Thema zu geben, haben wir die QA-Karte entwickelt. Die QA-Karte bietet dem Team eine praktische Möglichkeit, die Maßnahmen für eine optimale Testbarkeit der Projekte zu planen und zu dokumentieren. Ziel ist es, bereits zu einem frühen Zeitpunkt alle QA-relevanten Fragen für die Teams und Entwicklungsprojekte durch einen spielerischen Ansatz zu ermitteln. In Planungsrunden können gemeinsam alle Aspekte der Teststrategie wie Testarten und Werkzeuge visualisiert, diskutiert und priorisiert werden. Neben der Planung dient die QA-Karte mit ihrer plakativen Darstellung auch als Erinnerung oder schneller Einstieg in die Teststrategie des Teams.

Zusammengesetzt ergeben der Oktant und die Karte den QA-Schlachtplan, der sich als Wandbild platzieren lässt (Abb. 5).
Abbildung 5: Der QA-Schlachtplan (mit Oktant und Karte) als Wandbild

Mit dem QA-Schlachtplan haben die Entwicklungsteams ein visuelles Hilfsmittel, mit dem sie frühzeitig die planerischen Aspekte der Qualitätssicherung beurteilen können. Dabei kann der QA-Schlachtplan innerhalb der Projektlaufzeit auch als Referenz des aktuellen Vorgehens und als Ansatz für potenzielle Verbesserung genutzt werden.

Der QA-Schlachtplan steht Ihnen hier zum Download bereit. Gerne senden wir Ihnen unseren QA-Schlachtplan auch in Originalgröße (700 x 1000 mm) zu. Schreiben Sie uns dazu einfach eine E-Mail mit Ihrer Adresse an qa-schlachtplan@saxsys.de. Viel Erfolg beim Testen!

Kay Grebenstein ist Diplom-Informatiker und arbeitet als Testmanager für die Saxonia Systems AG, Dresden. Er hat in den letzten Jahren in klassischen und agilen Projekten unterschiedlicher fachlicher Domänen (Telekommunikation, Industrie, Versandhandel, Energie, …) Qualität gesichert und Software getestet. Die gewonnenen Erfahrungen und Erkenntnisse stellt er auf Konferenzen, in Publikationen und auf vielen anderen Wegen vor.

Twitter LinkedIn Google+ Xing