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.
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.
Wenn Sie weitere Eingaben zur QA-Strategie suchen, brauchen Sie nicht weiter zu schauen als unsere Vorlage. Wir haben 20 Jahre unserer Erfahrung im Bereich Qualitätssicherung genutzt, um eine einfache, leicht anpassbare Vorlage zu erstellen, die die Behandlung von Fehlern und vieles mehr aufschlüsselt.
Holen Sie sich eine Vorlage für eine Teststrategie, die es uns ermöglicht, Software 2 Mal so schnell zu veröffentlichen
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:
Schlussfolgerung
Die Kriterien für die Beendigung von Tests helfen Ihnen dabei, das richtige Gleichgewicht zwischen der Abdeckung der Anforderungen und der Vermeidung von übermäßigem Aufwand zu finden. Nutzen Sie die oben genannten Ideen, wenden Sie die spezifischen Anforderungen Ihres Produkts an und berücksichtigen Sie die gesetzlichen Vorschriften, um geeignete Ausstiegskriterien zu definieren.
Eine Möglichkeit, zu viel Zeit für die QS zu sparen, ist der Einsatz von künstlicher Intelligenz. Der KI-Copilot von aqua kann ganze Tests durchführen, um Randfälle schnell abzudecken und/oder eine Testabdeckung von nahezu 100 % zu erreichen. Die Testfallverwaltungsfunktionen von aqua eignen sich auch für jede Art von KI-Integration.
Ein Weg, um nicht zu viel Zeit für QA aufzuwenden, ist künstliche Intelligenz. aquas KI-Copilot kann komplette Tests erstellen, um schnell Randfälle abzudecken und/oder nahezu 100% Testabdeckung zu erreichen. Die Testfallverwaltungsfunktionen in aqua eignen sich hervorragend für jede Art der KI-Integration.
KI-Tests auf dem Weg von der Machbarkeit zur maximalen Testabdeckung
