Sie können nie alles testen, deshalb müssen Sie darüber nachdenken, welche Geschäftsrisiken in Ihrem Entwicklungsprojekt bestehen. Mit diesem Ausgangspunkt können Sie die Reihenfolge planen, in der Sie testen, wie Sie die Risiken rund um die Tests minimieren und wie die Tests priorisiert werden, sodass Sie die kritischsten zuerst testen. Ihre Teststrategie hat dann dieselbe Geschäftspriorität, die für das gesamte Entwicklungsprojekt gilt. In diesem Blogbeitrag beschreibe ich, wie Sie beim risikobasierten Testen denken sollten.
Es gibt eine geschäftliche Perspektive darauf, wie wichtig das Testen ist. Auch die Branche, in der Ihr System entwickelt wird, ist wichtig. Wenn Ihr Projekt beispielsweise im Bank-, Versicherungs-, Medizintechnik- oder Behördenbereich angesiedelt ist, hat das Unternehmen den Ruf, dass es korrekt funktionieren sollte. Selbst wenn der Fehler nur ein Rechtschreibfehler ist, kann er das Vertrauen in das gesamte Unternehmen mindern. In anderen Fällen kann es für das Unternehmen, für das Sie arbeiten, von größter Bedeutung sein, ein Produkt vor allen anderen auf den Markt zu bringen, sodass es für sie möglich sein kann, die Tatsache zu akzeptieren, dass die erste Version des Produkts einige Fehler enthält. Bei allen Projekten gibt es normalerweise eine Priorität zwischen Zeit, Kosten und Qualität. Wenn Sie Qualität priorisieren, wirkt sich dies auf Zeit und Kosten aus. Wenn Zeit am wichtigsten ist, wirken sich Kosten und Qualität aus.
Mit anderen Worten sind Zeit-, Kosten- und Qualitätsfaktoren ebenfalls wichtige Parameter für Ihre Testplanung. Es besteht tatsächlich die Möglichkeit, dass Sie im Verhältnis zur Gesamtpriorität des Projekts „zu viel“ testen. Dies ist wichtig, damit die Testbemühungen mit demselben Ziel stattfinden, an dem das gesamte Projekt gemessen werden soll. Wenn Sie Ihre Tests planen, erstellen Sie Ihre Testfälle, Testszenarien oder die Voraussetzungen für explorative Tests und erhalten eine Liste mit allem, was getestet werden soll. Aber nicht alle Tests sind gleich wichtig, es gibt immer Funktionen im System, die oft ausgeführt werden, während andere Funktionen weniger oft ausgeführt werden. Es gibt auch andere Faktoren, die steuern, ob eine Funktion im System mehr oder weniger Tests erfordert. Wie komplex eine Funktion in Bezug auf Anforderungen und Entwicklung ist, hat viel Gewicht bei Ihrer Priorisierung der Tests.
Ein risikobasierter Test stützt sich auf eine Risikoanalyse, die in der Regel bestimmt, welche Aspekte innerhalb einer bestimmten Testebene, wie etwa einem Systemtest oder einem Sprint, getestet werden sollen. Die Art der Risikoanalyse, die Sie wählen, ist nicht sehr wichtig. Wichtig ist, dass Sie die Wahrscheinlichkeit und Konsistenz der vom Projekt ausgewählten Aspekte berücksichtigen, wie z. B. geschäftskritisch, Implementierungskomplex, Datenkomplex und mehr. Berücksichtigen Sie auch die oben genannten Zeit-, Kosten- und Qualitätsfaktoren.
Eine risikobasierte Testanalyse kann auf verschiedene Arten durchgeführt werden. Dies ist ein Vorschlag, der zeigt, wie Sie dies tun können. Dies ist möglicherweise nicht das Richtige für Sie und Ihr Projekt, aber wir geben Ihnen einige gute Tipps, die Sie verwenden können.
2. Zunächst müssen die Risiken im Rahmen des Auftrags identifiziert werden, was auf klassische Weise mithilfe von „gelben Notizen“ erfolgen kann. Oder warum nicht Mind Mapping verwenden, bei dem Sie Risiken aufschreiben – hohe und niedrige. Dies geschieht am besten in einer Gruppe, zum Beispiel in einem Gemeinschaftsraum, damit Sie sich gegenseitig inspirieren, kreativer werden und über den Tellerrand hinausblicken können.
3. Wenn die Risikosammlung abgeschlossen ist, müssen sie gruppiert werden, was normalerweise nach Funktionen oder Bereichen geschieht. Es kann jedoch auch andere Möglichkeiten geben, die Risiken zu gruppieren, die besser zur Mission passen. Die Gruppierung wird vom Risikomanager durchgeführt.
4. Der Risikomanager beruft ein neues Meeting zur Risikoanalyse ein, in dem er die Risiken und ihre Gruppierung vorstellt. Nun können die Teilnehmer Kommentare abgeben und neue Risiken hinzufügen, bei Bedarf können die Risiken detaillierter aufgeschlüsselt werden. Nach diesem Meeting muss die Risikokarte fertig sein und die Voraussetzungen müssen identifiziert werden, um eine Risikoanalyse durchzuführen, in der die Wahrscheinlichkeiten und Konsequenzen bewertet werden.
5. Der Risikomanager beruft einen neuen Workshop ein, in dem die Risikoanalyse selbst durchgeführt wird. Beispiele für Teilnehmer sind Testleiter, erfahrener Tester, Kunde, Architekt, Projektmanager, Produktbesitzer/Systemmanager, erfahrener Entwickler.
6. Für jedes Risiko müssen Wahrscheinlichkeit und Konsequenz abgewogen werden. Beginnen Sie damit, die Eintrittswahrscheinlichkeit des Risikos auf einer Skala von 1 bis 4 zu bewerten und tragen Sie diese Bewertung in die Tabelle ein.
Bei der Bewertung der Wahrscheinlichkeit berücksichtigen wir verschiedene Faktoren, die das Risiko beeinflussen können, dass das Ereignis eintritt.
Wägen Sie weiterhin die Konsequenzen für jedes Risiko ab. Blenden Sie die Spalte „Wahrscheinlichkeit“ aus, damit sie die Gewichtung der Konsequenz nicht beeinflusst.
Hier ist es wichtig, alle relevanten Stakeholder zu identifizieren und darüber nachzudenken, ob einige davon wichtiger sind als andere und wenn ja, wie sie gewichtet werden sollten.
7. Multiplizieren Sie die Wahrscheinlichkeit mit der Konsequenz und Sie erhalten einen Risikowert. Verteilen Sie die Risiken entsprechend ihrem Risikowert:
8. Entscheiden Sie, wie Sie die Risiken eliminieren:
Ob Sie alle Risiken auf einmal eliminieren, indem Sie mit denen mit dem höchsten Risikowert beginnen und nach unten eliminieren
Ob Sie von der jeweiligen Funktion/dem jeweiligen Bereich ausgehen und dann die Risiken eliminieren
Ob Sie von Lieferungen/Sprints ausgehen
Ob Sie für die Risiken mit einem niedrigen Risikowert überhaupt Testfälle/Szenarien schreiben/Bedingungen für explorative Tests bereitstellen?
9. Beginnen Sie mit der Arbeit an den Risiken mit dem höchsten Risikowert:
Prüfen Sie, ob das Risiko mit einer Anforderung oder Ähnlichem verknüpft werden kann, und notieren Sie es in der Spalte „Zugeordnete Anforderung“
Identifizieren Sie einen oder mehrere Testfälle/Szenarien/Bedingungen für explorative Tests oder Ähnliches, die prüfen, ob das Risiko eliminiert ist. Schreiben Sie sie auf Kopfebene, um einen Gesamtüberblick über den Umfang der Testarbeit zu erhalten.
10. Dann ist es an der Zeit, Testfälle/Szenarien/Voraussetzungen für explorative Tests auf detaillierter Ebene zu schreiben.
Benennen Sie für jeden Testfall/jedes Szenario/jede Bedingung für explorative Tests Verantwortliche.
Schreiben Sie zunächst auf Kopfebene, um ein Gefühl dafür zu bekommen, wie viele Tests durchgeführt werden sollen. Es wird empfohlen, dies in einem Testtool zu tun, oder alternativ die Excel-Tabelle weiter zu erweitern, was sehr komplex sein wird.
Schreiben Sie die Testfälle/Szenarien/Voraussetzungen für explorative Tests auf detaillierter Ebene.
Überlegen Sie, ob der Testfall/das Szenario automatisch oder manuell ausgeführt werden soll.
Die Testfälle/Szenarien sollten vor ihrer Ausführung überprüft werden.
Falls möglich, sollte die Reihenfolge der Testfälle, Szenarien oder explorativen Tests festgelegt werden. Es wird empfohlen, Tests mit hohem Risikowert zuerst durchzuführen. Allerdings kann es auch erforderlich sein, grundlegende Funktionen zunächst zu überprüfen, um deren einwandfreie Funktion sicherzustellen, bevor die weiteren Tests beginnen.
11. Wenn Sie eine vollständige Anforderungsabdeckung wünschen, können Sie parallel zu den detaillierten Tests überprüfen, wie gut die Anforderungen getestet werden. In Punkt 9 wurden Risiken, Anforderungen und Tests abgebildet. Jetzt können Sie prüfen, ob es Anforderungen gibt, für die keine Tests definiert sind. Wenn es Anforderungen gibt, die nicht durch Testfälle/Szenarien/explorative Tests abgedeckt sind, notieren Sie diese und geben Sie sie ein, vorzugsweise unter einer neuen Registerkarte im Excel-Blatt.
12. Wenden Sie die Schritte 3 bis 10 auf die Anforderungen an, die nicht durch die Risikoanalyse abgedeckt wurden. Verwalten Sie diese Anforderungen wie die Risiken, indem Sie einen Risikowert festlegen, der Ihnen bei der Planung der Reihenfolge hilft, in der die Tests erstellt und durchgeführt werden sollen.
13. Jetzt verfügen Sie über ein System, das vollständig gemäß den Anforderungen getestet wurde, und Sie haben alle hohen Risiken beseitigt, indem Sie Testfälle, Szenarien und explorative Tests durchgeführt haben, um sicherzustellen, dass alle wesentlichen Funktionen abgedeckt sind.
14. Wenn es an der Zeit für die nächste Lieferung oder den nächsten Sprint ist, sollte die vorherige Risikoanalyse überprüft werden, um sich folgende Fragen zu stellen:
Kann die Wahrscheinlichkeit/Konsequenz des Risikos geändert werden? Haben wir das Risiko mit den entwickelten/durchgeführten Tests eliminiert oder teilweise eliminiert?
Gab es neue Risiken oder Anforderungen, die in der oben beschriebenen Weise behandelt werden müssen?
15. Gehen Sie bei der Planung der nächsten Lieferung/des nächsten Sprints genauso vor wie oben beschrieben, aber auch hier müssen Regressionstests identifiziert werden. Ein Tipp ist dann, Testfälle/Szenarien/Explorationstests auszuwählen, bei denen Abweichungen gefunden und korrigiert wurden, und Testfälle/Szenarien/Explorationstests mit einem hohen Risikowert auszuwählen.
—
Wir hoffen, dies hilft Ihnen schnell weiter. Da alle Tests unterschiedlich sind, müssen Sie gegebenenfalls Anpassungen vornehmen, um sie an die Organisation, das Testniveau oder die Art der Sprints, mit denen Sie arbeiten, anzupassen.