Definition des risikobasierten Testens
Die Definition des risikobasierten Testens ist in sich selbst geschlossen: Es handelt sich um einen Ansatz, bei dem Sie Ihre QS-Priorisierung auf die Risiken stützen, die durch unzureichende Tests entstehen. Dies ist besonders wichtig für große Projekte, bei denen die Anzahl der QS-Mitarbeiter nicht mit der Anzahl der zu testenden Funktionen Schritt halten kann. In vielen Fällen steigt die Softwarekomplexität exponentiell an, sodass die Einstellung weiterer Tester ohnehin keine Lösung ist.
In diesem Zusammenhang kann das Risiko als die Wahrscheinlichkeit definiert werden, dass ein unentdeckter (=ungelöster) Fehler die Software negativ beeinflusst. Die Realität ist ein wenig komplizierter, denn nicht jeder Fehler hat die gleichen negativen Auswirkungen. Ein Text, der über das Textfeld hinausgeht, kann in der deutschen Version Ihrer Software ein häufiges Problem sein, das aber kaum funktionale Probleme verursacht. Andererseits werden seltene Fälle von Doppelzahlungen immer ein großes Problem darstellen, insbesondere wenn Zahlungsanbieter die Transaktionspauschale auch nach einer Rückerstattung einbehalten.
Wesentliche Merkmale risikobasierter Tests
Das risikobasierte Testen hat eine Reihe von Schlüsseleigenschaften, die es vom traditionellen Testen unterscheiden:
- Testen, was wichtig ist, nicht alles testen ist der wichtigste Grundsatz des risikobasierten Testens. Beim traditionellen Testen gibt es immer Randfälle, die so selten vorkommen, dass selbst die Tester nicht immer an sie denken. RBT geht noch einen Schritt weiter: Auch wenn Sie die Testfälle bereits haben, sollten Sie sich nicht damit aufhalten, sie alle auszuführen, wenn Sie keine Zeit dafür haben.
- Die Risikobewertung wird bei der Verwendung von RBT zu einem wichtigen Teil der Qualitätssicherung. Risiken mit geringer Wahrscheinlichkeit, aber großen Auswirkungen erfordern mehr Ressourcen als Probleme, die häufig auftreten und geringe Auswirkungen haben. Das klingt in der Theorie hart, aber es gibt praktische Möglichkeiten, Risiken zu kategorisieren, die wir später in diesem Artikel behandeln werden.
- Die Synergie mit der unternehmensweiten Risikomanagementpolitik erweitert den Wert des risikobasierten Testens über die Softwareentwicklung hinaus. Die Banken verdienen einen guten Teil ihres Geldes mit Transaktionsgebühren, sodass das Ausbleiben von Transaktionen ein großes Risiko darstellt. Folglich ist ein Ausfall der 3DS-Verifizierung bei Online-Zahlungen ein kritisches Risiko für die Webanwendung der Bank.
Vorteile des risikobasierten Testens
Hier einige Vorteile risikobasierter Tests.
- Die Nutzung der Ressourcen ist der Hauptgrund für die Anwendung risikobasierter Tests. Realistischerweise geht es bei der QS-Planung darum, wie viele Stunden dem Team zur Verfügung stehen, und nicht darum, wie viele Funktionen und Code-Ergänzungen es zu validieren gilt. Nur die Komponenten zu testen, bei denen ein Ausfall am wahrscheinlichsten oder am schmerzhaftesten ist, ist eine gute Möglichkeit, den Wert Ihrer Tester zu maximieren.
- Auch die Optimierung der Automatisierung ist ein großer Vorteil. Es mag den Anschein haben, dass die Testautomatisierung die Begrenzung der Arbeitsstunden umgeht, aber es muss immer noch jemand automatisierte Tests schreiben, pflegen und auf dem Laufenden halten. Hinzu kommen die Serverkosten, die eine 100%ige Testautomatisierung rund um die Uhr für KMUs und oft auch für große Unternehmen nicht realisierbar machen. Das Wissen darüber, welche Ziele mit Skripten zu erreichen sind, ist eine hervorragende Ergänzung zu einer Liste von Prioritäten aus manuellen Tests.
- Eine nachweisbare Qualitätsverbesserung ist sowohl für das Vertrauen der Nutzer als auch der Interessengruppen in das Produkt von großer Bedeutung. Bei einem risikobasierten Ansatz beim Testen geht es nicht nur darum, die Ressourcen für triviale Probleme zu reduzieren – es bedeutet auch, mehr Zeit für das Wesentliche aufzuwenden. Wenn ein Nutzer sieht, dass eine Anwendung nicht mehr alle paar Stunden abstürzt, wird er eine Verbesserung feststellen. Wenn Sie RBT verwenden, um eine App zu veröffentlichen, die nie abstürzt, bieten Sie einen größeren Wert als die Behebung kosmetischer Mängel.
- Die frühzeitige Erkennung von Problemen ist im Allgemeinen großartig, aber sie funktioniert noch besser, wenn risikobasierte Tests in agilen Teams angewendet werden. Wenn Sie kritische Komponenten zuerst testen, werden Sie wahrscheinlich schon früh auf wichtige Probleme stoßen. So kann jeder im Team seinen Zeitplan anpassen und Prioritäten setzen, damit diese Komponenten neben den wichtigsten Neuerungen des neuen Builds funktionieren. Alternativ hätten sich die Entwickler auf „Nice-to-have“-Funktionen konzentriert und hätten keine Zeit für Fehlerbehebungen gehabt.
- Die vereinfachte Einhaltung von Vorschriften ist ein großer Vorteil für jedes Unternehmen, das in einer sensitiven Branche tätig ist. Die Aufsichtsbehörden erwarten oft, dass Sie Ihren Ansatz für Softwaretests gut begründen können. RBT (=Risikobasiertes Testen) ist ein sehr vernünftiger Ansatz, der Sie vor Problemen bewahrt, falls doch etwas scheitert.
Wann sollte man den risikobasierten Testansatz anwenden?
Im Folgenden sind einige Situationen aufgeführt, in denen Sie risikobasierte Tests vorziehen sollten. Es mag den Anschein haben, als ob diese Situationen im Grunde jedes Softwaretestprojekt betreffen, das existiert. Das stimmt bis zu einem gewissen Grad: Sie sind nicht zu RBT verpflichtet, aber die meisten Teams sind mit negativen Faktoren konfrontiert, die durch diesen Ansatz gut gemildert werden.
- Begrenzte Ressourcen sind überall ein Problem, außer in Start-ups, aber nur, weil sie oft keine eigene Qualitätssicherung haben. Wenn Sie keine Zeit haben, alle Tests auszuführen und zu pflegen, um Ihre hohe Testabdeckung zu verfolgen, ist das risikobasierte Testen die Lösung.
- Komplexe Projekte bedeuten, dass manuelle Regressionstests zu viel Zeit in Anspruch nehmen, um auch auf andere Probleme zu testen. Während die Testautomatisierung den Aufwand weitgehend reduzieren kann, ist das risikobasierte Testen eine gute Möglichkeit, die wiederholten Tests für dieselben kleinen Probleme zu reduzieren.
- Unternehmenskritische Anwendungen dürfen nicht versagen, und risikobasierte Tests sind wohl der beste Weg, um mehr Ressourcen für kritische Probleme bereitzustellen. Sie werden auch eine sachliche Rechtfertigung haben, die Sie mit internen Interessengruppen und Regulierungsbehörden teilen können.
- Altsysteme sind von ihrer Konzeption her zu umfangreich, um sie angemessen mit Tests abzudecken. Sie werden wahrscheinlich nicht nur mit schlechter Optimierung, sondern auch mit fehlender Dokumentation und Kompatibilitätsproblemen zu kämpfen haben. Wenn Sie sich auf die wichtigsten Komponenten konzentrieren, wird die Integration und Wartung einer Altsysteme-Lösung einfacher und effizienter.
- Zeitdruck kann der größte Faktor sein, wenn man sich auf risikobasierte Testmetriken verlässt, um die Ziellinie zu überqueren. Manche Produktnischen tauchen so schnell auf, dass es schon zu spät sein kann, wenn man den richtigen Qualitätssicherungszyklus durchläuft. Dann gibt es Meilensteine für Investoren, wie etwas zu entwickeln, das gut genug funktioniert, bevor über eine Seed-Investition verhandelt wird. Wann immer Sie schneller als erwartet arbeiten müssen, ist „Requirement Based Testing“ (RBT, anforderungsbasiertes Testen) der richtige Weg, um die negativen Auswirkungen zu minimieren.
Wer führt die risikobasierten Tests durch?
An risikobasierten Tests sind die gleichen technischen Spezialisten beteiligt wie an traditionellen Tests.
QS-Spezialisten führen den Großteil der risikobasierten Tests durch. Sie setzen Prioritäten bei den Risiken, erstellen und pflegen Tests, um diese Risiken abzusichern, führen die Tests durch und senden Fehlerberichte an die Entwickler. Ähnlich wie beim herkömmlichen Testen werden Entwickler und andere Beteiligte einbezogen, um die Zusammenarbeit zu verbessern und die Übereinstimmung mit den Unternehmenszielen zu gewährleisten.
Von Entwicklern wird heutzutage erwartet, dass sie Einheitstests schreiben und ausführen. Diese Tests umfassen kurze Codeschnipsel, um grundlegende Fehler zu erkennen. Diese Fehler werden dann umgehend vom Entwickler behoben. Der Code wird erst dann an die QS weitergeleitet, wenn die Einheitstests keine Fehler mehr liefern. Dies passt hervorragend zu risikobasierten Tests, da die QS-Spezialisten mehr Zeit haben, sich auf komplexe Probleme zu konzentrieren.
Endbenutzer, die Benutzerakzeptanztests durchführen, sind technisch gesehen ebenfalls Teil der risikobasierten Tests. Sie gehen die wahrscheinlichsten Anwendungsfälle durch und erkennen Probleme, damit diese bei der Abnahme der Software nicht das Erlebnis verderben.
Welche Arten von Risiken gibt es während des Softwareentwicklungsprozesses?
Risiken in der Softwareentwicklung werden in der Regel nach ihrem Einflussbereich kategorisiert. Zu den wichtigsten Typen gehören:
- Funktionale Risiken stellen eine direkte Bedrohung für den Betrieb der Software (und möglicherweise des Unternehmens) dar. Einzelne Komponenten und die gesamte Software können fehlerhaft arbeiten oder sogar ganz ausfallen. Risiken im Zusammenhang mit kritischen Funktionen oder dem vollständigen Ausfall der Anwendung haben die größten Auswirkungen
- Technische Risiken beziehen sich auf die infrastrukturellen Risiken für Ihre Software. Sogar Amazon Web Services kann technisch abstürzen, ganz zu schweigen von billigeren Cloud-Lösungen. Tech-Schulden können eines Tages zu einem starken Anstieg der Abwanderungsrate führen und nicht nur Ihre App, sondern auch Ihr Geschäftsmodell ruinieren.
- Sicherheitsrisiken sind mit Nachlässigkeit zum Schutz Ihrer Lösung verbunden. Datenlecks sind ein Paradebeispiel, da Verstöße sowohl den Ruf des Unternehmens schädigen als auch zu finanziellen Verlusten führen. Die Geldbußen werden immer teurer, vor allem in der EU.
- Leistungsrisiken spiegeln eine potenzielle Verschlechterung der Dienste für bestehende und potenzielle Kunden wider. Ihre Lösung sollte in Spitzenzeiten einsatzbereit sein und nicht unter einer Welle von Neuanmeldungen zusammenbrechen.
- Prozessrisiken umfassen potenzielle Probleme, die bei der Arbeit am Produkt auftreten können. Eine neue Test- oder Entwicklungsmethodik kann den Output sowohl kurzfristig als auch langfristig verringern oder verschlechtern. Eine neue Version kann fehlschlagen, sodass Sie sich um ein Rollback bemühen müssen. Auch die einfache Nichteinhaltung eines Entwicklungszeitplans kann ein Prozessrisiko darstellen.
- Geschäftsrisiken werden durch die Marktgegebenheiten, in denen das Unternehmen tätig ist, verursacht. Das Produkt kann plötzlich aus der Mode kommen oder ins Hintertreffen geraten. Die Aufsichtsbehörden können gegen Sie vorgehen, wenn Sie die neuesten Anforderungen nicht erfüllen. Ein Softwarefehler wirft einen Schatten auf das gesamte Unternehmen, auch wenn es sich nur um eine isolierte Einheit mit demselben Namen handelt.
Wie lassen sich Risiken bei Softwaretests definieren und bestimmen?
Die Risiken werden in der Regel in einem frühen Stadium der risikobasierten Prüfung definiert. Der Prozess umfasst Daten aus der Vergangenheit und Beiträge von allen Beteiligten. Eine unternehmensweite Risikomanagementstrategie kann eine großartige Inspirationsquelle sein, da Sie wissen, welche Ereignisse am wichtigsten sind, um sie zu mindern.
Phasen der risikobasierten Prüfung
-
1Die Produktanalyse ist der früheste Teil des Aufbaus risikobasierter Tests. Die Techniker müssen die wichtigsten Funktionen ermitteln und die Projektinfrastruktur untersuchen. Es ist auch wichtig, externe Faktoren wie das geschäftliche Umfeld, die Anforderungen der Regulierungsbehörden und die nichttechnischen Einschränkungen des Projekts zu berücksichtigen
-
2Bei der Risikoidentifizierung kommen Interessenvertreter, Entwickler und Tester zusammen, um potenzielle Risiken zu besprechen. Sie nutzen ihr Wissen über das Projekt, historische Informationen über ähnliche Projekte und ihre Branchenkenntnisse, um mögliche Probleme zu erkennen. Im Allgemeinen möchten Sie kreativitätsfördernde Methoden wie Brainstorming anwenden. Ziel dieser Phase ist es, Risiken zu erkennen und nicht sofort zuzustimmen oder zu verwerfen, was andere vorgeschlagen haben
-
3Die Risikoanalyse ist die wichtigste Phase. Da risikobasiertes Testen nach dem Prinzip der 100%igen Konzentration auf die höchsten Risiken erfolgt, müssen Sie diese richtig definieren. Dazu gehört auch die Bewertung der Wahrscheinlichkeit und der Auswirkungen der einzelnen Risiken. Wenn Sie beides haben, berechnen Sie das Risikopotenzial durch Multiplikation der Werte. Anhand dieses Ergebnisses können Sie in erster Linie die Risiken einstufen, die bei den Tests abgedeckt werden sollen.
-
4Die Testplanung beim risikobasierten Testen ist ähnlich wie bei der traditionellen QS. Sie müssen immer noch eine Teststrategie erstellen, aber diese sollte die von Ihnen ermittelten und priorisierten Risiken enthalten. In den ersten Zyklen ist es üblich, schnell zu handeln und Tests für Risiken mit hoher Priorität zu erstellen. Dies ist besonders wichtig, wenn Sie risikobasierte Tests für ein bestehendes Projekt einführen – es gibt viele bestehende Tests, die kleinere Dinge abdecken.
-
5Bei der Testdurchführung führen Sie Testfälle aus, reichen Fehlerberichte ein und arbeiten mit den Entwicklern zusammen, um Probleme zu beheben. Dabei können Sie Risikomuster erkennen, die durch Maßnahmen zur Risikominderung auf Team-, Projekt- oder sogar Unternehmensebene angegangen werden sollten.
-
6Überprüfen und Lernen ist eine wichtige Phase in Ihrem Zeitplan. Hier kommen alle Beteiligten noch einmal zusammen, um zu besprechen, wie der Testzyklus verlaufen ist. Die Gültigkeit der Risikopriorisierung, die entdeckten Muster, mögliche Maßnahmen zur Risikominderung und andere Verbesserungsvorschläge werden diskutiert. Die Hauptakteure erstellen dann Aktionspunkte für jede Partei.
-
7Durch Überwachung und Anpassung können Sie die geänderte Teststrategie kontinuierlich beobachten und bei Bedarf Korrekturen vornehmen. Sie fügen neue Testfälle hinzu, aktualisieren oder entfernen weniger relevante Tests und fügen auch neue Risiken hinzu und ordnen sie den ursprünglichen Risiken zu
Beispiele für risikobasierte Tests
Zur besseren Veranschaulichung des Ergebnisses sind hier einige Beispiele für Risiken, die Unternehmen aus verschiedenen Branchen identifizieren könnten:
RBT-Beispiel für Banken
- Risiken mit hoher Priorität: fehlgeschlagene Transaktionen, falsche Transaktionsgebühren, Fehlfunktion des Währungsumtausch-Algorithmus
- Risiken mittlerer Priorität: Ausfall der Lifestyle-Funktionalität, verzögerte Transaktionsmeldungen, nicht funktionierende Ausgaben-Dashboards
- Risiken mit geringer Priorität: Tippfehler, seltene App-Abstürze, die sich nicht auf Transaktionen auswirken, vorübergehende Unmöglichkeit des Zugriffs auf die Transaktionshistorie für mehr als 1 Jahr
RBT-Beispiel für den elektronischen Geschäftsverkehr
- Risiken mit hoher Priorität: Artikel können nicht in den Warenkorb gelegt werden, Preisfehler, Fehler bei der Versandberechnung, Fehler an der Kasse, betrügerische Zahlungen
- Risiken mittlerer Priorität: Fehler in der Benutzeroberfläche, Ausfall der Website während exklusiver Veröffentlichungen mit hoher Nachfrage, Fehler im Algorithmus zur Blockierung von Verkäufen über das verfügbare Volumen hinaus
- Risiken von geringer Priorität: geringfügige Fehlfunktion der Filter, leicht abnormale Ladezeiten bei der Anzeige von 100 Waren
RBT-Beispiel für die Automobilindustrie
- Risiken mit hoher Priorität: Ausfall der Hardware-Software-Funktionalität des Fahrzeugs, Zero-Day-Software-Schwachstelle, Umgehung der Abonnementanforderungen für Leistungsmerkmale des Fahrzeugs
- Mittlere Risiken: keine Verbindung mit einem Telefon, Fehler bei der Medienwiedergabe:
- Kleinere Risiken: schlechte Schriftarten in der Übersetzung für einzelne Märkte, unübersichtliche Menüführung
Metriken für risikobasierte Tests
Die Metriken für risikobasierte Tests überschneiden sich mit den traditionellen Tests, aber es gibt auch einige einzigartige Metriken, die Sie berücksichtigen sollten.
- Ermittelte Risiken
- Schwere & kritische Risiken teilen
- Kritische Risiken offen
- Beim Testen übersehene Risiken (nach Schweregrad)
- Fehlendes Risiko im Verhältnis zu den ermittelten Risiken (Anteil)
- Testabdeckung
- Testabdeckung nach Anwendungsbereich (sollte bei hohem Risiko größer sein)
- Defektdichte
- Defektdichte nach Anwendungsbereich (zur Validierung der Risikobewertung)
Beste risikobasierte Testverfahren
Da das eigentliche Testen recht ähnlich abläuft, beziehen sich die risikobasierten Testverfahren meist auf die Vorarbeiten zu den Risiken des Projekts. Nachstehend finden Sie einige Techniken.
Techniken zur Risikoidentifizierung
Brainstormings sind wohl das geeignetste Mittel, um Risiken zu ermitteln. Jeder Beteiligte kann seine Meinung frei äußern, ohne Angst haben zu müssen, zu viele Themen zu nennen.
Zusätzliche Techniken zur Risikoerkennung stützen sich meist auf Daten aus der Vergangenheit, um Ihnen zusätzliche Ideen zu geben. Checklisten mit Risiken für ähnliche Projekte sind eine unmittelbare Quelle der Inspiration. Historische Daten könnten ebenfalls nützlich sein, insbesondere wenn es sich um ein ähnliches Projekt handelt und/oder Sie mit dem/den gleichen Ingenieurteam(s) zusammenarbeiten.
Techniken der Risikoanalyse
Die Risikomatrix ist die visualisierte Version Ihrer Risikoeinstufung. Es gibt verschiedene Ansätze, aber ein sehr gängiger ist die Farbcodierung. Sanftere Farben (z. B. grün oder gelb) kennzeichnen weniger häufige und weniger einschneidende Risiken. Schärfere Farben (z. B. braun oder rot) weisen auf hochfrequente, hochwirksame Risiken hin.
Auch die Fehlermöglichkeits- und Einflussanalyse (FMEA) befasst sich mit pessimistischen Szenarien und eignet sich hervorragend für unternehmenskritische Software. Sie können auch eine starre Brainstorming-Sitzung auf der Grundlage der Structured What If Technique (SWIFT) durchführen, um Risiken in sensiblen Branchen schneller als mit der FMEA zu bewerten.
Techniken zur Risikominderung
Automatisierte Tests für bekannte Risiken sind die wichtigste Technik zur Risikominderung. Je mehr Sie automatisieren können, desto mehr Zeit haben Sie, um Risiken mit niedrigerer Priorität abzudecken. Sie können diese Zeit auch für exploratives Testen nutzen, das potenziell mehr Risiken auf sehr praktische Weise aufdeckt.
Techniken zur Risikoüberwachung
KPIs sind die beste Lösung zur Überwachung von Risiken. Wenn Sie feststellen, dass eine QS-Kennzahl abnormal ist, sollten Sie entweder Ihre Testsuite, Ihre Teststrategie oder Ihre Risikobewertung überprüfen.
Die moderne Art, mit KPIs umzugehen, ist die Einrichtung von KPI-Warnungen. Mit dieser Funktion werden Sie automatisch benachrichtigt, wenn eine Anomalie in Ihren Metriken auftaucht. Diese Funktion wird in aqua angeboten, einer 100 % rückverfolgbaren, KI-gestützten Testmanagementlösung für jeden Maßstab.
Erhalten Sie KPI-Alarme für eine zuverlässige Risikoüberwachung
Wie lassen sich risikobasierte Verfahren zur Priorisierung von Testfällen und -plänen einsetzen?
All diese Techniken werden zu einer besseren Risikobewertung führen. Hier sehen Sie, wie Sie dies als Teil der risikobasierten Prüfung nutzen können:
- Erstellen Sie zunächst Tests für Hochrisikobereiche
- Priorisierung der Testdurchführung nach Risikostufe
- Nutzen Sie die Testautomatisierung, um den manuellen Aufwand für risikoärmere Bereiche weiter zu reduzieren.
- Verwenden Sie KI-fähige Lösungen für das Testmanagement (aqua kann hier helfen), um Tests für Grenzfälle zu erstellen
- Setzen Sie Analysen ein, um Ressourcen neu zuzuweisen, wenn Sie feststellen, dass kritische Bereiche häufiger oder seltener ausfallen.
Zu vermeidende Fehler bei risikobasierten Tests
Risikobasiertes Testen hört sich zwar spannend an, aber wenn man es falsch macht, wird der QS-Output geringer und manchmal werden sogar mehr Probleme eingeführt.
- Eine voreilige Risikoidentifizierung macht das Bild unvollständig. Auch wenn es Ihnen gelingt, alle anderen Risiken zu bewerten und zu mindern, werden später mehr oder weniger schwerwiegende Probleme auftauchen. Stellen Sie sicher, dass Sie ausreichend Zeit einplanen und warten Sie auf die Beteiligten, wenn sie nicht verfügbar sind.
- Die Vernachlässigung von Risiken mit geringer Priorität bedeutet eine wachsende Verschuldung, die sich einmal rächen wird. Es könnte auch eine zunehmende Art von Frustration für Entwickler und Endbenutzer sein. Auch wenn Sie nicht alles reparieren können, sollten Sie Risiken mit geringer Priorität im Auge behalten.
- Statisches Risikomanagement bedeutet, dass risikobasierte Tests nur für ein paar Monate, wenn nicht Wochen, gültig sind. Sie müssen ständig Prioritäten setzen, analysieren und neue Risiken hinzufügen, die von Geschäftsleuten, Projektbeteiligten und technischen Teams ermittelt werden.
- Eine unzureichende Ressourcenzuweisung kann die Vorteile der risikobasierten Tests zunichte machen oder sogar noch mehr Probleme verursachen. Wenn Sie nicht aggressiv genug vorgehen, verschwenden Sie immer noch zu viel Zeit mit Risiken von geringerer Priorität. Wenn Sie zu enthusiastisch sind, ruinieren einige Risiken mittlerer Priorität Ihren Tag. Analyse und Erfahrung sind die Antworten.
Die besten Tools für das risikobasierte Testen
In diesem Abschnitt befassen wir uns mit Lösungen für das Testmanagement, die sich für das risikobasierte Testen eignen. Auch wenn Sie einen separaten Risiko-Tracker einsetzen, benötigen Sie die Ergebnisse mit einem TMS, um die Risiken zu mindern.
- aqua ist das funktionsreichste und risikobewussteste Tool auf der Liste. Die Einhaltung von Vorschriften wird von Dutzenden Kunden aus den Bereichen Behörden, Versicherungen und Banken bestätigt. Die KI-Testerstellung zur Abdeckung von Grenzfällen ist die fortschrittlichste Lösung auf dem Markt. Das Tool verfügt über einen übersichtlichen Abschnitt zur Testabdeckung auf dem Anforderungsbildschirm, der anzeigt, ob eine Anforderung abgedeckt ist, und eine Vorschau für Tests bietet, welche die Anforderung abdecken. Auch KPI-Warnungen werden automatisch ausgegeben.
- Das Jira-Plugin für QS Xray und ein weiteres Jira-Plugin namens Risikomanagement können zusammenarbeiten. Leider verfügt Xray über extrem unzureichende Analysen, hinkt bei den erweiterten QS-Funktionen hinter den Mitbewerbern her und akzeptiert keine Kunden mehr, die Jira On-Premise einsetzen (Atlassian stellt es im Januar 2024 ein).
- Kualitee ist eine gute Option für risikobasiertes Testen, da es über gute Dashboards und solide QS-Funktionen verfügt. Leider bietet es nur eine unterdurchschnittliche Anzahl an nativen Integrationen, keine KPI Alarme und keine Workspace-weite Protokollierung für 100%ige Rückverfolgbarkeit.
aqua übertrifft die anderen Optionen in einem anderen Aspekt: Berichterstattung. Risikobasierte Tests erfordern eine umfangreiche Visualisierung, und hier kommt der benutzerdefinierte Berichtsassistent von aqua ins Spiel. Sie können alle Daten aus Ihrem Arbeitsbereich verwenden und sogar externe Texte und Bilder einfügen. Das automatische Sammeln von Daten, ihre Umwandlung mit Skripten und ihre Aufbereitung machen risikobasierte Tests jederzeit transparent und effizient.
KI-gestütztes, analytisches Tool für risikobasierte Tests
Schlussfolgerung
Beim risikobasierten Testen ändert sich das Paradigma vom Testen, um die meisten Fehler zu finden, zum Testen, um die Fehler zu finden, die am wichtigsten sind. Die Einrichtung erfordert eine gemeinsame Anstrengung des technischen Teams, der nichttechnischen Interessengruppen, der Geschäftsleute und möglicherweise des gesamten Teams. Das Ergebnis ist jedoch, dass Sie mit denselben Ressourcen objektiv besser testen und die Qualität Ihrer Software steigern können.
