Woher wissen wir, wann wir unsere Tests beenden sollten?

Die Software-Qualitätssicherung strebt nach Perfektion, aber sie zu erreichen ist nicht nur kaum möglich, sondern selten machbar. Also, wann hört man eine Software-Testing auf? Finden Sie heraus und erhalten Sie eine Checkliste unten

when to stop testing

Ist das Pareto-Prinzip gut genug?

Vor allem für nicht an der Qualitätssicherung Beteiligte mag es verlockend sein, einfach das gute alte Pareto-Prinzip anzuwenden. Demnach würde das Testen von Software bereits bei 20 % des Prozesses eingestellt, da man zu diesem Zeitpunkt bereits 80 % der Probleme gefunden haben müsste.

Leider sind die Dinge nicht so einfach. Je nach Branche kann es einfach zu viele (potenziell) kritische Probleme geben, um den QS-Aufwand um 80 % zu reduzieren. Es mag verlockend sein, die Kosten zu senken und Funktionen schneller freizugeben, aber das Testen von Banksoftware setzt voraus, dass alles, was auch nur im Entferntesten unsicher ist, erkannt wird. Dann ist da noch die Sache mit der Regression. Man kann die Entwickler nicht einfach eine Runde von Korrekturen durchführen lassen und darauf vertrauen, dass sie keine neuen Fehler verursacht haben.

Auch wenn die 80/20-Regel nicht auf die Software-Qualitätssicherung angewandt werden kann, ist es dennoch notwendig, ein Gleichgewicht zwischen den Ressourcen und dem Ergebnis herzustellen – hoffentlich ein relativ fehlerfreies Softwareprodukt. Wie macht man das in der Qualitätssicherung? Die Antwort ist das Hinzufügen von Ausstiegskriterien in den Testplan.

Definition von Ausstiegskriterien

Ausstiegskriterien in einem Testplan leiten Sie wie bei einer Checkliste. So wie das Fehlen von besonders wichtigen und/oder geliebten Produkten dazu führt, dass man in den Lebensmittelladen geht, ist das Erreichen aller Ausstiegskriterien ein Stoppzeitpunkt beim Testen von Software. Schauen wir uns einige von ihnen an.

testing exit points

Zeit

Irgendwann ist es an der Zeit, mit dem Testen aufzuhören. Die moderne agile Entwicklung wird durch sehr kurze Iterationen vorangetrieben, was bedeutet, dass Sie einen festen Termin haben, der nicht verschoben werden kann. Ja, eine Funktion, die noch zu unfertig ist, um in Produktion zu gehen, wird verschoben. Was die Sprintplanung betrifft, so müssen Sie die Qualitätssicherungsbemühungen vorerst noch einstellen.

Test-Budget

Das ist das einfachste Ausstiegskriterium für Systemtests. Wenn Sie nicht die Mittel haben, um weiterzumachen, müssen Sie sich mit den Problemen begnügen, die das QS-Team bisher gefunden hat.

Abdeckung der Anforderungen

Es ist eine Sache, die Qualitätssicherungsarbeit abzubrechen, weil man nicht die Zeit hatte, alles gründlich genug durchzugehen. Wir haben erörtert, warum dies unumgänglich und sinnvoll ist. Auf der anderen Seite sollten Ihre Bemühungen umfassend genug sein, um zumindest eine Vorstellung davon zu haben, wie alle wichtigen Softwarekomponenten funktionieren.

Testabdeckung

Anders als bei der Bedarfsdeckung ist es nicht notwendig, die 100 %-Marke zu erreichen. Dennoch sollte die absolute Mehrheit des Codes, der für die Produktion vorgesehen ist, mit Testfällen abgedeckt werden, vorzugsweise in Form von Testszenarien, um die Qualitätssicherung zu erleichtern. Auch automatisierte Testwerkzeuge oder Lösungen, die Sie bei der Verwaltung unterstützen, wie z. B. aqua, sind eine große Hilfe.

Schweregrad des Fehlers

Verschiedene Unternehmen verwenden unterschiedliche Skalen für die Bewertung von Fehlern. Es gibt auch eine große Diskussion über den umgangssprachlichen Unterschied zwischen Schweregrad und Priorität und den faktischen Unterschied. Für die Zwecke dieses Artikels wollen wir die folgende Klassifizierung der Fehlerschwere verwenden:

Schweregrad des Fehlers

1

Kritische Fehler

2

Hauptfehler

3

Nebenfehler

4

Gerinfügiger Fehler

Wann sollte man also aufhören zu testen? Ganz einfach, wenn Sie alle kritischen Fehler und Hauptfehler behoben haben. Es gibt sowohl in der Softwareentwicklung als auch in den Kundenbeziehungen Gründe, die neue Version Ihres Produkts nicht instabiler zu machen als die vorherige. Wenn Sie alle Fehler der zwei höchsten Schweregrade beheben, schaffen Sie das.

Weitere Kennziffern

Qualitätssicherungsteams verfolgen eine Vielzahl von Kennziffern, um den Zustand des Produkts, den Fortschritt bei der bevorstehenden Veröffentlichung sowie die allgemeine Produktivität und den Erfolg des Teams zu analysieren. Diese Kennziffern können auch verwendet werden, um Kriterien für die Beendigung der Tests zu definieren.

  • Schwellenwert für offene Fehler (beliebiger Schweregrad)
  • Fehlerquote in Prozent
  • Quote Bestanden/Nicht bestanden von Testfällen

Erfolgreiche Funktionstests

Obwohl die Erfolgsquote der Testfälle nicht 100 % betragen muss, sollten alle Funktionstests grün sein, bevor eine neue Version des Produkts in Betrieb genommen wird. Es spielt keine Rolle, ob etwas ein wenig schiefgegangen ist, denn dafür sind Nebenfehler und geringfügige Fehler gedacht. Die Schlüsselfunktionen sollten jedoch weiterhin funktionieren, auch wenn die Benutzerszenarien nicht funktionieren.

Ein gutes Beispiel hierfür ist die Qualitätsprüfung im Versicherungswesen. Eines der primären Versicherungsmodelle bedeutet eine automatische Deckung in den Partnerkliniken, wobei die Dokumentation durch eine Gesundheitseinrichtung erfolgt und kein Geld ausgetauscht wird. Es gibt auch Leistungen, die bei Nicht-Partner-Kliniken eine teilweise oder vollständige Kostenerstattung vorsehen, bei denen der Kunde einen Versicherungsantrag stellen muss.

Die Einreichung von Versicherungsansprüchen ist eine Schlüsselfunktion der Software von Versicherungsunternehmen, und Sie können keine neue Version veröffentlichen, wenn die Kunden damit keine Erstattung beantragen kann. Ihre QS-Spezialisten könnten jedoch feststellen, dass die App die Antragsdaten nicht auf der Grundlage des Fotos einer Rechnung ausfüllt, der Benutzer kann aber trotzdem alles manuell eingeben und den Antrag absenden.

Entscheidung Go/No Go

Zu guter Letzt gibt es eine „Go/No Go“ Besprechung. Die Techniker entscheiden, ob Sie die neue Version freigeben können. Wenn die vorangegangenen Ausstiegskriterien darauf hindeuten, dass die QS ihre Aufgaben erledigt hat, ist das der Zeitpunkt, an dem Sie aufhören.

Checkliste für die Beendigung der Tests

Hier sind Beispiele für Ausstiegskriterien. Sie können gerne Kriterien ausschließen, weitere hinzufügen oder Werte ändern:
time to stop software testing

Zum Thema passende Artikel

Fällt es Ihnen schwer, Ihre Qualitätssicherung mit dem Tempo und den Arbeitsabläufen Ihrer Entwicklung in…

photo
Denis Matusovskiy
17 mins read

Das Testen der Benutzeroberfläche ist wohl der wirkungsvollste Typ des Testens, jedenfalls für B2C-Unternehmen. Es…

photo
Robert Weingartz
11 mins read

In der schnelllebigen Zeit, in der wir leben, bedeuten langsame oder bröckelnde Websites und Anwendungen…

photo
Denis Matusovskiy
9 mins read