Der ultimative Leitfaden für risikobasiertes Testen: Risikomanagement beim Testen von Software

ultimate guide risk based testing

Der ultimative Leitfaden für risikobasiertes Testen, Risikomanagement und seinen Ansatz mit Beispielen:

Was ist risikobasiertes Testen?

Risikobasiertes Testen besteht darin, Tests durchzuführen oder die Szenarien so zu entwerfen und auszuführen, dass die vom Kunden identifizierten Top-Geschäftsrisiken, die sich negativ auf das Geschäft auswirken, zu Beginn des Lebenszyklus in seinem Produkt oder Merkmal entdeckt werden durch die Umsetzung von Minderungsmaßnahmen gemildert werden.

=> Klicken Sie hier, um die vollständige Testplan-Lernserie anzuzeigen

Die negativen Auswirkungen können Kostenauswirkungen, unzufriedene Kunden, schlechte Benutzererfahrung und sogar das Ausmaß des Kundenverlusts umfassen.

Mit anderen Worten, der RBT-Ansatz besteht darin, sicherzustellen, dass die Tests so durchgeführt werden, dass selbst wenn ein Benutzer findet einen Fehler Dies hindert ihn in der Produktion nicht daran, die Software zu verwenden, oder wirkt sich nicht ernsthaft auf das Geschäft aus.

RBT testet basierend auf Produktrisiken. RBT muss frühzeitig herausfinden, wie hoch das Risiko des Ausfalls eines bestimmten Merkmals oder einer bestimmten Funktionalität in der Produktion und dessen Auswirkungen auf das Geschäft in Bezug auf Kosten und andere Schäden ist, indem eine Priorisierungstechnik für die Testfälle verwendet wird.

Risikobasierte Tests verwenden daher das Prinzip von Priorisierung der Tests der Merkmale, Module und Funktionen eines Produkts oder einer Software. Die Priorisierung basiert auf dem Risiko der Wahrscheinlichkeit eines Ausfalls dieser Funktion oder Funktionalität in der Produktion und ihrer Auswirkungen auf die Kunden.

Was du lernen wirst:

• Risikobasierte Tests und ihre Relevanz für Agile & DevOps
  • Risikobasierter Testansatz
    • Wann verwenden wir den RBT-Ansatz?
    • Beispiel für einen RBT-Ansatz
  • Möglichkeiten zur Risikoanalyse
  • Risikoanalyseverfahren
  • Risikoanalysemethode
    • Schritt 1) ​​Verwenden eines 3X3-Rasters
    • Schritt 2) Wahrscheinlichkeit und Auswirkung eines Ausfalls
    • Schritt 3) Testen des Prioritätsgitters
    • Schritt 4) Details des Testens
  • Wie ist RBT für Agile und DevOps relevant?
  • Vorteile des risikobasierten Testansatzes
• Risikomanagement während der Testplanung
  • Risikomanagement-Prozess
    • # 1) Risikoidentifikation
    • # 2) Risikobewertung / Risikoauswirkungsanalyse
    • # 3) Risikominderung
  • Fazit
• Risikomanagement in der Testdurchführungsphase (mit Beispiel)
  • Risikomanagement - mit Fokus auf das AUT
  • Wie finden Risikobasis-Tests statt?
  • Fazit
  • Literatur-Empfehlungen

Risikobasierte Tests und ihre Relevanz für Agile & DevOps

Dreihundert Stunden für die Entwicklung von Software können in nur 30 Sekunden unbrauchbar gemacht werden, wenn ein einzelner Fehler in der Produktion festgestellt wird.

Dies kann wiederum den Zweck des gesamten Produkts ruinieren, ohne dass eine andere Option besteht, als es vom Markt zu nehmen. Und das ist die Bedeutung und Notwendigkeit von „Qualitätsprüfungen“.

Mit dem rasanten technologischen Wachstum wird die Software in der Cloud gehostet und unterstützt mehrere Betriebssysteme, mehrere Plattformen, komplexe IT-Infrastrukturen usw. Die Endbenutzer werden immer pingeliger in Bezug auf die Funktionen, Optionen und gehen keine Kompromisse bei der Kundenzufriedenheit ein .

Heutzutage wird „Qualität“ zu einem entscheidenden Faktor bei der Softwarebereitstellung, bei der kontinuierliche Verbesserungen vorgenommen werden, um die Qualität zu verbessern und die Kunden zufrieden zu stellen.

Wir bemerken oft, dass es ein häufiges Problem für fast alle Tester ist, unter enormem Druck zu stehen, dass ihr Testfenster zusammengedrückt wird und der Build ihnen normalerweise in letzter Minute zum Testen übergeben wird. Sie haben nicht genügend Zeit und Ressourcen, um alle von ihnen entworfenen Tests durchzuführen, und die Automatisierungsabdeckung ist nicht immer 100% und hat ihre eigenen Herausforderungen.

Der Lieferzeitplan kann nicht übersehen werden und gleichzeitig kann auch die Qualität nicht beeinträchtigt werden. Was auch immer der Plan B, zusätzliche Testressourcen hinzuzufügen, indem er sich aus den anderen Teams zurückzieht, nicht funktioniert, Plan C, alle anderen Aktivitäten einzustellen und die Anstrengungen allein darauf abzulenken, hilft nicht wirklich. Allerdings funktioniert eine Menge zusätzlicher Testressourcen am Ende nicht.

Es gibt keine andere Möglichkeit, als nur begrenzte und wichtige Tests innerhalb der verfügbaren Zeit und Ressourcen durchzuführen.

Wie entscheiden wir also, welcher Test in dieser Phase wichtig ist? Was auch immer ein Tester für wichtig hält, ist für die Kunden möglicherweise nicht wirklich wichtig. Aus wessen Perspektive wird die Bedeutung des Merkmals oder einer Funktionalität entschieden? Wer entscheidet, welche Tests wichtig sind? Und viele andere Fragen tauchen immer wieder auf.

Um all diese Fragen zu beantworten und die oben genannte Situation effektiv zu bewältigen, wird ein Testansatz aufgerufen „Risikobasiertes Testen“ , kurz angerufen 'RBT' entstand, wo das Team die Testszenarien anhand der Kriterien des „Projektrisikos“ klar geplant und identifiziert hat.

Obwohl das QS-Team ein klares Bild der wichtigen Tests hat, ist RBT eine bewährte Methode, um die entscheidenden und wichtigen Tests aus Kunden- und Geschäftssicht durch a zu identifizieren 'Risikoanalyse' Verfahren .

Im Gegensatz zu der herkömmlichen Methode, die Fehler in der Software einfach zu identifizieren, haben sich der QS-Ansatz und das QS-Ziel im Laufe der Zeit aufgrund der Änderung der Technologie, der Zunahme des Wettbewerbs auf dem Markt für die Veröffentlichung einer Qualitätssoftware und der Einführung von geändert 'Alles automatisieren' und vollständige Einführung der Agile- und DevOps-Praxis, die Software über einen Zeitraum von wenigen Stunden bereitzustellen.

Der derzeitige Trend des „Testprinzips“ besteht daher nicht nur darin, die Mängel zu identifizieren, sondern auch darin,

# 1) Konzentrieren Sie sich auf den Bereich des Produkts, in dem aufgrund von Fehlern oder hoher Ausfallwahrscheinlichkeit in der Produktion erhebliche Auswirkungen auf das Geschäft auftreten.

#zwei) Konzentrieren auf Identifizierung der Mängel frühzeitig und einem Team ermöglichen, das Problem so früh wie möglich zu beheben, und damit der Software / dem Produkt oder der Funktion zu ermöglichen ‘Fail Fast’.

#3) Der wichtigste Aspekt des Service des QS-Teams besteht nun darin, sich auf den Kunden zu konzentrieren, um dem Kunden einen Mehrwert zu bieten, indem der Fokus auf erhöht wird „End-to-End-Kundenerfahrung“.

Risikobasierter Testansatz

Es ist immer so, als würde man sich auf eine Prüfung vorbereiten, man kann nicht sagen, dass das Testen ausreicht und es gibt keine Fehler mehr in der Software, selbst wenn sie eine große Anzahl von Tests entwerfen und ausführen.

Es gibt einen Punkt, an dem die Software-Stabilität nicht doppelt gewährleistet werden kann, wenn nur die Anzahl der Testfälle erhöht wird. Zu diesem Zeitpunkt geht es nicht nur um die Anzahl der Tests, sondern auch darum, was der Kunde tatsächlich von der Veröffentlichung erwartet.

Daher ist es wichtig, bei der Optimierung der Tests ein Gleichgewicht zu finden, um mit dem angemessenen Testaufwand den maximalen Nutzen zu erzielen. Dies ist umso wichtiger, wenn die Testzeitpläne sehr eng sind und nicht genügend Ressourcen zur Verfügung stehen, um ausreichende Tests durchzuführen.

In diesem Fall spielt der RBT-Ansatz daher eine Schlüsselrolle bei der Optimierung des QS-Aufwands und der Maximierung des Testnutzens bei minimalem Geschäftsrisiko.

Wenn wir uns also auf den oben genannten Aspekt konzentrieren, wird die Arbeit einer Qualitätssicherung sehr erleichtert. Sie müssen ihre Wochenenden nicht im Büro verbrennen, die Software kontinuierlich testen und sich über alle S4- (Schweregrad 4) und P4-Fehler (Priorität 4) Sorgen machen, die sich aus den Tests ergeben.

Nun, 4 wird als die niedrigste Priorität und Schwere der Testfehler angesehen. Sie können ihre Zeit besser in andere nützliche Aspekte des Projekts investieren.

Um die Haupttreiber des Ansatzes „Risikobasiertes Testen“ zusammenzufassen:

• Um zu testen, was Kunden aus geschäftlicher Sicht wollen.
• Den Zeitplan mit der erwarteten Qualität einhalten.
• Optimierung des QS-Aufwands.

Wann verwenden wir den RBT-Ansatz?

Dies wird in den folgenden Szenarien verwendet:

• Der RBT-Ansatz kann verwendet werden, wenn Zeit, Kosten und Ressourcen eines Projekts begrenzt oder eingeschränkt sind und wenn die Ressourcen optimiert werden müssen.
• Der RBT-Ansatz wird verwendet, wenn das Programm komplexer ist und neue Technologien anpasst und daher viele Herausforderungen mit sich bringt.
• Wenn es sich bei dem Programm um ein F & E-Projekt handelt und es sich um ein Programm erster Art handelt und das Projekt eine Reihe von Unbekannten und Risiken enthält.

Beispiel für einen RBT-Ansatz

In der IT-Branche werden verschiedene risikobasierte Analyseansätze verwendet, um die Risiken der Produktion und ihre Auswirkungen zu überwinden.

Nachstehend ist ein solcher Ansatz aufgeführt:

Dieser Ansatz von RBT umfasst die Identifizierung der „lebenswichtigen Funktionen oder Schlüsselmerkmale“ des Produkts und die Bewertung der Risiken, denen jede dieser Funktionen in der Produktion ausgesetzt ist, sowie die Umsetzung geeigneter Minderungsmaßnahmen zur Verringerung oder Minderung des Risikos.

Daher umfasst der RBT-Ansatz das Testen der Funktionen, die die Ausfallwahrscheinlichkeit und die höchsten Auswirkungen auf das Geschäft haben. Die Arten von Fehlern können betriebliche oder geschäftliche, technische, externe usw. sein.

Möglichkeiten zur Risikoanalyse

Es gibt keinen Standardprozess oder eine Standardvorlage, die als solche definiert ist, um die Risikoanalyse in Softwaretests für jedes einzelne Merkmal eines Produkts durchzuführen. Verschiedene Organisationen verwenden ihren eigenen Ansatz für Risikoanalysemethoden.

An verschiedenen Projektpunkten kann eine Risikoanalyse durchgeführt werden, um die Risiken zu identifizieren und einen RBT-Ansatz für die Analyse zu implementieren. Diese Elemente umfassen,

• Eigenschaften
• Funktionen
• Benutzergeschichten
• Bedarf
• Anwendungsfälle
• Testfälle

In diesem Fall konzentrieren wir uns nur auf Testfälle, um die Implementierung des risikobasierten Testansatzes zu verstehen.

Risikoanalyseverfahren

Die Risikoanalyse umfasst die Einbeziehung relevanter Programmbeteiligter aus dem Bereich „ Technisches Team und Geschäftsteam “ Dazu gehören der Eigentümer des Produkts, Produktmanager, Geschäftsanalysten, Architekten, Tester und Kundenvertreter.

In Brainstorming-Sitzungen, an denen diese Stakeholder beteiligt sind, wird die Diskussion durchgeführt, um die Bedeutung der einzelnen Merkmale eines Produkts zu ermitteln und sie anhand des Ausfallrisikos und ihrer Auswirkungen auf die Endbenutzer in der Produktion zu priorisieren.

Verschiedene „Projektdokumente“ wie Anforderungsdokumente, technische Spezifikationsdokumente, Architektur- und Konstruktionsdokumente, Geschäftsprozessdokumente, Anwendungsfalldokumente usw. werden als Eingabe für die Brainstorming-Sitzung verwendet.

Das Wissen der Stakeholder über das Produkt und das auf dem Markt vorhandene Produkt wird ebenfalls ein Inputfaktor für die Diskussion sein.

Nur wenige andere Eingabequellen können auch Folgendes umfassen:

• Sammeln von Eingaben zu den am häufigsten verwendeten Funktionen.
• Eingaben aus der Beratung eines Domain-Experten.
• Daten aus der vorherigen Version des Produkts oder eines ähnlichen Produkts auf dem Markt.

Während der Brainstorming Sitzung werden die Risiken für jedes dieser Merkmale identifiziert. Die Arten von Risiken können betriebliche, technische oder geschäftliche Risiken sein. Die damit verbundenen Tests und Szenarien werden gewichtet und die Risikowerte anhand der Wahrscheinlichkeit des Eintretens eines Risikos und der Auswirkungen des Risikos bewertet.

Die „Wahrscheinlichkeit des Eintretens eines Risikos“ kann folgende Ursachen haben:

• Schlechtes Verständnis der Funktion durch das Produktentwicklungsteam.
• Unsachgemäße Architektur und Design.
• Unzureichende Zeit zum Entwerfen.
• Inkompetenz des Teams.
• Unzureichende Ressourcen - Menschen, Werkzeuge und Technologie.

Die „Auswirkung des Risikos“ ist die Auswirkung eines Versagens der Benutzer und des Unternehmens, wenn es auftritt. Die Auswirkungen könnten sein,

• Kostenauswirkungen, die zu einem Verlust führen.
• Auswirkungen auf das Geschäft, die zum Verlust des Geschäfts oder zum Verlust von Marktanteilen führen, Gerichtsverfahren, Verlust der Lizenz.
• Auswirkungen auf die Qualität, die zu einer minderwertigen oder inkompetenten Produktfreigabe führen.
• Schlechte Benutzererfahrung, was zu Unzufriedenheit und Verlust eines Kunden führt.

Der Schwerpunkt der Bewertung des Risikos eines Merkmals oder Produkts kann sein:

• Geschäftsbereich Kritikalität der Funktionalität.
• Am häufigsten verwendete Funktionen und wichtige Funktionen.
• Fehleranfällige Bereiche
• Funktionalität, die die Sicherheitsauswirkungen trägt.
• Bereich des komplexen Designs und der Architektur.
• Änderungen gegenüber früheren Versionen.

Risikoanalysemethode

Lassen Sie uns die „risikobasierte Testmethode“ jetzt im Detail verstehen.

Der risikobasierte Testansatz verwendet RISIKO als Kriterium in allen Testphasen des Testzyklus, d. H. Testplanung , Testdesign, Testimplementierung, Test Ausführung und Testberichte. Idealerweise kann man eine Vielzahl möglicher Testszenario-Kombinationen entwerfen.

Daher umfasst der RBT-Ansatz eine Rangfolge der Tests basierend auf der Schwere der Risiken, um den fehlerhaftesten oder riskantesten Fehlerbereich herauszufinden, der einen hohen Einfluss auf das Geschäft hat.

Das Hauptziel der Risikoanalyse ist die Unterscheidung zwischen dem 'Hochwertig' Artikel wie Produktmerkmale, Funktionen, Anforderungen, benutzergeschichten und Testfälle und Niedriger Wert' und daher später, um sich mehr auf Testfälle mit hohem Wert zu konzentrieren, indem Sie sich weniger auf Testfälle mit niedrigem Wert konzentrieren. Dies ist der erste Schritt der Risikoanalyse vor Beginn der risikobasierten Tests.

Die Hauptaufgabe der Kategorisierung oder Gruppierung von Testfällen in High Value & Low Value und der Zuweisung des Prioritätswerts zu jedem dieser Testfälle umfasst die folgenden Schritte:

Schritt 1) ​​Verwenden eines 3X3-Rasters

Die Risikoanalyse wird mithilfe eines 3X3-Rasters durchgeführt, in dem jede Funktionalität, Nichtfunktionalität und die zugehörigen Testfälle von einem Team von Stakeholdern auf ihre „Wahrscheinlichkeitdes Scheiterns “und„ Auswirkungen des Scheiterns “.

Die Wahrscheinlichkeit eines Ausfalls jeder Funktionalität in der Produktion wird im Allgemeinen von einer Gruppe von „technischen Experten“ abgerufen und entlang der vertikalen Achse des Rasters als „wahrscheinlich ausfallen, sehr wahrscheinlich und unwahrscheinlich“ eingestuft.

Funktionsprüfung und nicht funktionale Prüfung

In ähnlicher Weise wird die „Auswirkung eines Ausfalls“ dieser Merkmale und Funktionen in der Produktion vom Endkunden erfahren, wenn sie nicht getestet wird, und von einer Gruppe von bewertet ' Business Specialists “und sind entlang der horizontalen Achse des Rasters in die Kategorien„ Minor, Visible and Interruption “eingeteilt.

Schritt 2) Wahrscheinlichkeit und Auswirkung eines Ausfalls

Alle Testfälle werden in den Quadranten des 3 x 3-Gitters positioniert, basierend auf den identifizierten Werten der Ausfallwahrscheinlichkeit und der Auswirkung des Ausfalls, die in der folgenden Abbildung als Punkte dargestellt sind.

Offensichtlich sind in der oberen rechten Ecke des Gitters eine hohe Ausfallwahrscheinlichkeit und eine hohe Ausfallwahrscheinlichkeit (Unterbrechung) zusammengefasst, was von hoher Bedeutung ist. Daher wird festgestellt, dass die Tests mit hohem Wert und die Tests mit niedrigem Wert in der Gruppe zusammengefasst sind untere linke Ecke, die für den Kunden am wenigsten oder gar nicht wichtig ist, wobei diese Funktionen oder Testfälle nur geringfügig berücksichtigt werden können.

Schritt 3) Testen des Prioritätsgitters

Basierend auf der obigen Positionierung der Testfälle im Raster werden die Tests priorisiert und mit den Prioritäten 1, 2, 3, 4 und 5 gekennzeichnet und gegen jeden von ihnen markiert. Die wichtigsten Tests sind in einer 1 positioniert^stRaster, denen Priorität 1 zugewiesen wurde, und ähnlich weniger wichtige Raster werden als 2, 3, 4 und 5 eingestuft.

Schließlich werden alle Testfälle anhand ihrer Prioritätsnummern sortiert und in der Reihenfolge ihrer Priorität zur Ausführung abgeholt. Die mit hoher Priorität werden zuerst zur Ausführung aufgenommen, und diejenigen mit niedriger Priorität werden entweder später ausgeführt oder ohne Gültigkeitsbereich.

Schritt 4) Details des Testens

Der nächste Schritt besteht darin, den Detaillierungsgrad des Tests für den definierten Testumfang festzulegen. Die Tiefe des Testumfangs kann auf der Grundlage der obigen Rangfolge gemäß dem folgenden Raster festgelegt werden.

Tests mit hoher Priorität und Rang 1 werden „gründlicher“ getestet. Dementsprechend werden Experten eingesetzt, um diese Funktionen mit hoher Kritikalität und die zugehörigen Testfälle zu testen. In ähnlicher Weise können Testfälle mit Priorität 2, 3 und 4 getroffen werden. Es kann eine Entscheidung getroffen werden, die Funktionen und Tests der Priorität 5 auf der Grundlage der verfügbaren Zeit und Ressourcen zu deaktivieren.

Der Ansatz der Detailgenauigkeit des Testens zur Priorisierung der Merkmale und ihrer Testfälle hilft den Testern daher nicht nur, die 'hochwertigen Tests' zu identifizieren, sondern führt sie auch dazu, auf der Grundlage dieser Prioritätsrangfolge und ihrer 'Detailteststufe' zu entscheiden hilft ihnen, bessere Tests durchzuführen und reduziert die Testkosten durch den Optimierungsprozess.

Wie ist RBT für Agile und DevOps relevant?

Nachdem man nun den risikobasierten Testansatz verstanden hat, die Tests basierend auf der Priorisierung von Tests in Abhängigkeit vom „Ausfallrisiko“ eines bestimmten Features und dessen „Auswirkungen auf den Kunden“ im Leben durchzuführen, würde man natürlich die Frage aufwerfen die Relevanz des risikobasierten Testansatzes in agilen und DevOps-Praktiken.

'Alles automatisieren', 'Alles testen', 'Kontinuierlich testen', 'Wiederholt testen' sind die Schlüsselkonzepte dieser Praktiken.

Jedes Mal, wenn sich der Code ändert oder eine Version vorliegt, werden alle entworfenen Tests automatisiert ausgeführt Kontinuierliche Integration (CI) /. Kontinuierliche Lieferung (CD) Pipeline schnell und wiederholt, unabhängig von ihrer Priorisierung.

Wie ist dann die Beziehung zwischen RBT und DevOps? Wo würde RBT in Agile und DevOps passen und relevant werden?

# 1) Ja, wie ich bereits sagte, ist es nicht so, dass jede Branche und jedes Produkt eine 100% ige Automatisierungsabdeckung für ihre Testausführungen hat. Wenn das Team also die Priorisierung für die Testausführung aus der Auswahl manueller Testfälle auswählen muss und die Energie und den Aufwand der Testressourcen für andere Aktivitäten sparen möchte, ist RBT die beste Wahl.

Der risikobasierte Ansatz ist auch eine bessere Wahl, um automatisierte Tests mit hoher Priorität durchzuführen und frühestens zu testen.

#zwei) Das QA-Team kann den RBT-Ansatz während der Anforderungsanalyse effektiver anwenden, indem es die Anforderungen analysiert und einen Vorabbericht über die wahrscheinlichen Risiken der Produkte und der Merkmale erstellt, damit das Programmteam proaktiv geeignete Maßnahmen ergreifen kann, um diese zu mindern.

#3) Der RBT-Ansatz kann effektiv bei der Gestaltung der Testfälle und -szenarien auf der Grundlage eines hohen Risikos verwendet werden, sodass der Schwerpunkt stärker auf risikoreiche Merkmale und Funktionen gelegt werden kann.

# 4) Durch die Identifizierung der Bereiche mit hohem Risiko kann das QS-Team seine Testbemühungen auf diese Bereiche konzentrieren, um mithilfe von hochqualifizierten Testern gründlicher zu testen.

# 5) Wie wir alle wissen, ist 'Fail Fast' das Konzept von 'Agile' und 'DevOps', bei dem der RBT-Ansatz hilft, die 'Hochrisiko' -Bereiche in der Software zu identifizieren, die Fehler frühzeitig zu erkennen und sie schnell und fehlerhaft ausfallen zu lassen zuerst und lassen Sie das Team es reparieren.

# 6) Das ultimative Ziel von Agile / DevOps ist die Kundenorientierung. Daher ermöglicht der RBT-Ansatz der Qualitätssicherung, sich auf das Kundenerlebnis zu konzentrieren und nicht nur Fehler zu finden.

Vorteile des risikobasierten Testansatzes

Wir haben bereits den Zweck und die Verwendung des RBT-Ansatzes zur Analyse der Anforderungen, zum Entwerfen und Ausführen der Testszenarien verstanden. RBT bietet mehrere Vorteile.

Wir können die Vorteile von risikobasierten Tests wie folgt konsolidieren und auflisten:

• Hilft bei einer effizienteren und optimierten Nutzung von Testressourcen.
• Hilft bei der Erleichterung der QS-Arbeit, des Testens, des Testdesigns und der Testentwicklung sowie der Testvorbereitungsaktivitäten durch Priorisierung.
• Hilft bei der besseren Verwaltung der QS-Ressourcen, indem die Schlüsselressourcen auf Bereiche mit hohem Fokus verteilt werden.
• Es hilft bei der effektiven Nutzung von Ressourcen und lenkt ihre Zeit und Energie auf bessere Dinge im Projekt.
• Hilft dem QS-Team bei der Planung der Testbemühungen auf der Grundlage der Risikobewertung und Identifizierung volatiler und risikoreicher Bereiche.
• Es hilft dem Team, die durchzuführenden Tests je nach Wichtigkeit zu optimieren und daher in Übereinstimmung mit den Stakeholdern Tests mit geringem Wert zu deaktivieren.
• Insgesamt hilft es bei der Kostensenkung durch optimierte und reduzierte Testaktivitäten.
• Der RBT-Ansatz ermöglicht es dem QS-Team, zuerst die Bereiche mit hohem Risiko zu testen, und ermöglicht es dem Produkt, schnell zu versagen und schnell zu reparieren.
• Der RBT-Ansatz trägt dazu bei, Klarheit in die Testabdeckung' und den „Testumfang“ für die gesamte Gruppe der Interessengruppen.
• Das Team kann sich stärker auf Bereiche mit hohem Risiko konzentrieren und sich weniger auf Bereiche mit niedrigem Risiko konzentrieren.
• Mit RBT kann das Team frühzeitig über die Umsetzung der effektivsten Methode zur Minderung der Produktrisiken entscheiden.
• RBT hilft dabei, die Auswirkungen der unangemessenen Umsetzung von Minderungsmaßnahmen zu vermeiden.
• Risikobasierte Tests ermöglichen es dem Team, geeignete Maßnahmen zu ergreifen, um entweder die Kontingenz zu verringern oder zu planen oder eine Problemumgehung zu positionieren, um den Fehler zu überwinden oder seine Auswirkungen zu verringern, wenn das Risiko in Live auftritt.
• RBT hilft bei der Minimierung des Restrisikos bei der Freisetzung.
• Es hilft dabei, die „verbesserte Qualität“ durch kostengünstigere Produktionsfehler zu erreichen.
• Hilft letztendlich bei 'Verbessertes Kundenerlebnis' und 'Zufriedener Kunde'.

Als Nächstes lernen wir, wie Sie Risiken in den Phasen Testplanung und Testausführung des Software-Testlebenszyklus verwalten.

Risikomanagement während der Testplanung

So verwalten Sie Risiken während der Testplanungsphase:

Das Leben ist voller Risiken, ebenso wie ein Softwareprojekt. Alles kann jederzeit schief gehen. Wir sind immer bemüht, die Dinge richtig zu machen - aber wie wäre es, wenn wir sicherstellen, dass nichts schief geht und wenn genau, wissen wir genau, was zu tun ist? Enter Risk Management - Dies ist ein Teil eines Software-Testprojekts, das uns darauf vorbereitet, Risiken zu verhindern, zu verstehen, zu finden und zu überwinden.

Ein Risiko ist einfach ein Problem, das wahrscheinlich auftritt, und wenn es auftritt, verursacht es einen Verlust.

Der Verlust kann alles sein - Geld, Zeit, Mühe oder ein Kompromiss bei der Qualität. Der Verlust ist niemals gut. Egal wie viel Spin wir geben, es ist nicht positiv - und wird es auch nie sein. Deshalb Risikomanagement ist ein wesentlicher Bestandteil von Softwareprojekten, um sicherzustellen, dass wir mit Risiken umgehen und Verluste verhindern / reduzieren.

Risikobasiertes Testen :: Da wir eine QS-Community sind, sollten wir uns ausschließlich auf Risiken und den damit verbundenen Prozess in unserer QS-Welt konzentrieren. Risiken werden grob in 2 Phasen unserer bewertet und gesteuert Software-Test-Lebenszyklus . STLC kann in drei Phasen unterteilt werden: Testplanung, Testdesign und Testdurchführung.

Der Risikomanagementprozess findet zweimal statt, während:

1. Testplanung
2. Testfalldesign (Ende) oder manchmal in der Testausführungsphase

In Fall 1 ist dies obligatorisch, in Fall 2 handelt es sich jedoch eher um eine „bedarfsgerechte“ Situation.

Zweiteilige Artikelserie:

Obwohl der zugrunde liegende Prozess der gleiche ist, ist der Arten von Risiken in beiden Bereichen angesprochen sind völlig unterschiedlich. Um ihnen individuell gerecht zu werden, werden wir sie als zweiteilige Serie anders behandeln.

In diesem Abschnitt geht es um „Risikomanagement während der Testplanung”.

Risikomanagement-Prozess

Der generische Prozess für das Risikomanagement umfasst drei wichtige Phasen:

1. Risiko-Einschätzung
2. Risiko-Auswirkungsanalyse
3. Risikominderung

Testen von Risiken und Beispiele zur Schadensminderung:

# 1) Risikoidentifikation

Wie gesagt, der erste Schritt zur Lösung eines Problems besteht darin, es zu identifizieren. In dieser Phase wird eine Liste aller Elemente erstellt, die möglicherweise auftreten und den normalen Ereignisfluss stören können.

Das Hauptergebnis dieses Schritts ist eine Liste von Risiken.

Dieser risikobasierte Testschritt wird üblicherweise vom QS-Leiter / Manager / Vertreter geleitet. Der Lead allein kann jedoch nicht die gesamte Liste erstellen - der Beitrag des gesamten QA-Teams hat einen enormen Einfluss. Wir können sagen, dass dies eine kollektive Aktivität ist, die von der QS-Leitung geleitet wird.

Was Sie sehen, ist das, was Sie als Web Builder erhalten

Außerdem sind die Risiken, die während der Testplanungsphase identifiziert werden, eher auf die Ausrichtung des Managements ausgerichtet. Dies bedeutet, dass wir uns mit allen Aspekten befassen, die sich auf den Zeitplan, den Aufwand, das Budget, Änderungen der Infrastruktur usw. des QS-Projekts auswirken können nicht die AUT, sondern die Art und Weise, wie die QS-Phase weitergeht.

Risiken bei der Testplanung: Beispiele für risikobasierte Tests

Im Folgenden finden Sie eine Beispielliste der Risiken, die während der Testplanungsphase aufgeführt werden können. Bitte beachten Sie, dass das AUT und seine Funktionalität hier nicht im Mittelpunkt stehen.

1. Der Testplan ist eng. Wenn sich der Teststart aufgrund von Entwurfsaufgaben verzögert, kann der Test nicht über das geplante UAT-Startdatum hinaus verlängert werden.
2. Nicht genügend Ressourcen, Ressourcen werden zu spät eingebunden (der Vorgang dauert ca. 15 Tage.)
3. Defekte werden in einem späten Stadium des Zyklus oder in einem späten Zyklus gefunden; Spät entdeckte Mängel sind höchstwahrscheinlich auf unklare Spezifikationen zurückzuführen und zeitaufwändig zu beheben.
4. Umfang nicht vollständig definiert definiert
5. Naturkatastrophen
6. Nichtverfügbarkeit von Independent Test Umgebung und Zugänglichkeit
7. Verzögertes Testen aufgrund neuer Probleme

An diesem Punkt können Sie je nach verfügbarer Zeit so gründlich sein, wie Sie möchten.

Sobald alle Risiken aufgelistet sind, fahren wir mit der Risikobewertung / Risikoauswirkungsanalyse fort.

# 2) Risikobewertung / Risikoauswirkungsanalyse

Ist Ihre Risikoanalyse so ähnlich? :) :)

Risikoanalyse beim Testen von Software : In diesem Schritt werden alle Risiken quantifiziert und priorisiert. Die Wahrscheinlichkeit (Eintrittswahrscheinlichkeit) und Auswirkung (Verlustmenge, die bei Eintritt dieses Risikos entstehen würde) jedes Systems wird systematisch ermittelt.

Hoch Mittel Niedrig Die Werte werden sowohl der Wahrscheinlichkeit als auch der Auswirkung jedes Risikos zugeordnet. Die Risiken mit „hoher“ Wahrscheinlichkeit und „hoher“ Auswirkung werden zuerst behandelt, und dann folgt die Reihenfolge.

Risikoauswirkungsanalyse-Tabelle:

Nach diesen Schritten würde die Risikoauswirkungsanalysetabelle für die oben aufgeführten Risiken ungefähr so ​​aussehen (alle Werte sind hypothetisch und dienen nur dem Verständnis):

# 3) Risikominderung

Der letzte Schritt in diesem risikobasierten Testprozess (RBT) besteht darin, Lösungen zu finden, um zu planen, wie mit jeder dieser Situationen umgegangen werden soll. Diese Pläne können von Unternehmen zu Unternehmen, von Projekt zu Projekt und sogar von Person zu Person unterschiedlich sein.

Risikominderungstechniken:

Hier ist ein Beispiel dafür, in was sich die Risikotabelle nach Abschluss dieser Phase verwandelt:

Einige Punkte zu beachten:

1. Je früher das Risikomanagement in einer QS-Projektplanungsphase beginnt, desto besser.
2. Von allen 3 Schritten Die Risikoidentifikation ist das Wichtigste . Wenn etwas nicht aufgeführt und für weitere Schritte berücksichtigt wird, bleibt das Risiko unbehandelt.
3. Versuchen Sie, einen idealen Zeitrahmen für diese Aktivität zu finden. Denken Sie daran, dass zu viel Planung zu wenig Zeit lässt.
4. Wenn nach dem Risikomanagementprozess eine neue Situation eintritt, kann der Risikomanagementplan geändert oder aktualisiert werden, um den aktuellsten Zustand widerzuspiegeln.
5. Historische Daten kann für den Erfolg dieses Prozesses sehr nützlich sein.

Fazit

Dies bringt uns zu einem Ende des Risikomanagements in der Testplanungsphase. Obwohl die zugrunde liegenden Schritte und Prinzipien ähnlich sind, konzentriert sich der Risikomanagementprozess in der Testdesign- / Ausführungsphase stärker auf das AUT.

In unserem nächsten Abschnitt werden wir behandeln - Risikomanagement in der Testdurchführungsphase.

Risikomanagement in der Testdurchführungsphase (mit Beispiel)

Auf unserem Weg zum Verständnis des Risikomanagementprozesses haben wir darüber gesprochen, wie es ausschließlich im Testplanungsphase für risikobasierte Tests . Wir haben auch den allgemeinen Prozess verstanden, der Folgendes umfasst: Risikoidentifizierung, Risikobewertung und Risikominderungsplan.

So managen Sie das Risiko in der Testentwurfs- oder Testausführungsphase:

Es gibt eine andere Form von Risikomanagement (manchmal auch bezeichnet als, Risikobasierte Tests ), die je nach Situation während der Testentwurfs- oder Testausführungsphase auftritt. Über welche Situation sprechen wir jetzt? Versuchen wir zuerst, das zu verstehen.

Wir alle wissen, dass unsere Testarbeit reaktiv ist. Keine Anforderungen (oder Umfang definiert), wir können keine Machbarkeitsanalyse durchführen und Testszenarien schreiben oder Testaktivitäten planen.

Wenn der Code noch nicht fertig ist, müssen wir nichts testen, unabhängig davon, wie viel Vorarbeit wir in Bezug auf Testfälle, Testdaten usw. geleistet haben. Außerdem ist das Testen der einzige verbleibende Schritt, bevor das Produkt in Betrieb genommen wird wohnen.

Risikomanagement - mit Fokus auf das AUT

Lassen Sie uns dies anhand eines Beispiels besser verstehen:

Wenn die Tests an diesem Datum beginnen sollen, am 1. Januar^stund musste bis zum 14. Januar weitermachen^th- Wenn der Test abgeschlossen ist, wird das Go-Live-Datum des Produkts normalerweise sofort festgelegt. Sagen wir, 15. Januar^thder Einfachheit halber. In einer perfekten Welt würden die Dinge genau wie geplant verlaufen. Aber wir alle kennen die Realität.

Nehmen wir in diesem Fall an, dass die Tests aus irgendeinem Grund erst am 7. Januar begonnen haben^thDas heißt, wir haben die Hälfte unserer Testzeit verloren. Wir benötigen jedoch 14 Tage, um das Produkt gründlich zu testen. Wir könnten das Go-Live-Datum jedoch um 7 Tage weiter verschieben. Dies ist normalerweise keine Option. Weil versprochen wird, dass das Produkt zu einem bestimmten Zeitpunkt auf den Markt kommt und Verzögerungen nicht gut für das Geschäft sind.

Normalerweise müssen wir Testteams die Verzögerungen absorbieren, irgendwie kompensieren, mit der verfügbaren Zeit arbeiten und sicherstellen, dass das Produkt gut getestet wird. Harte Arbeit, nicht wahr?

Hier wird wieder der Risikomanagementprozess eingesetzt.

• Nun, wenn Verzögerungen werden im Voraus erwartet Noch bevor der Test beginnt, findet der Prozess in der Testentwurfsphase statt.
• Wenn Verzögerungen treten während eines Testausführungsphase das normal gestartet wurde - der Prozess wird während der Testausführungsphase verfolgt.
• Die Schritte und die Methode sind gleich, egal in welchem ​​Stadium.

Was ist der Prozess?

Das Risikomanagement bestimmt, welche Bereiche des AUT (Application Under Test) einen maximalen Fokus benötigen. Dies sind in der Regel die Funktionsbereiche (Module oder Komponenten), die für den Erfolg des Endprodukts entscheidend und am anfälligsten für Ausfälle sind.

Lesen Sie auch=> Die Fehlermöglichkeits- und Auswirkungsanalyse (FMEA) ist eine Risikomanagementtechnik

Wer führt es durch?

Da es sich um die AUT handelt, ist das Wissen darüber nicht nur bei der Qualitätssicherung, sondern bei allen anderen Teams - Dev, BA, Client, Projektmanagement-Teams usw. -. Daher handelt es sich um eine gemeinsame Anstrengung, die vom Testteam vorangetrieben wird.

Wie finden Risikobasis-Tests statt?

Schritt 1) Risiko-Einschätzung

Identifizieren Sie alle Funktionsbereiche des AUT. Dies beinhaltet einfach das Erstellen einer Liste.

Schritt 2) Risikoabschätzung

In diesem Schritt werden alle Risiken quantifiziert und priorisiert. Bei der Quantifizierung wird einfach jedem Risiko in der Liste eine Nummer zugewiesen, die einen Hinweis auf die Priorität gibt, mit der es angegangen werden muss.

Die Wahrscheinlichkeit (Eintrittswahrscheinlichkeit) und die Auswirkung (Verlustmenge, die bei Eintritt dieses Risikos entstehen würde) werden entschieden.

Die typische Methode besteht darin, die Bewertungen zuzuweisen. Zum Beispiel, Die Wahrscheinlichkeit kann die Werte 1 bis 5 annehmen. 1 ist die Wahrscheinlichkeit des Auftretens, die niedrig ist (wahrscheinlich überhaupt nicht) und 5, die hoch ist (wird höchstwahrscheinlich passieren).

In ähnlicher Weise kann Impact auch eine Bewertung von 1 bis 5 zugewiesen werden. 1 ist eine geringe Auswirkung (selbst wenn dieses Risiko eintritt, ist der Verlust minimal) und 5 ist eine hohe Auswirkung (große Verluste, wenn dies geschieht).

Schritt 3)

Erstellen Sie ein Tabellenformat und verteilen Sie es an alle Teamvertreter - Dev, BA, Client, PM, QA und alle anderen relevanten Personen.

Schritt 4)

Weisen Sie jedes Team an, die Werte basierend auf ihrer Bewertung für Wahrscheinlichkeit und Auswirkung einzugeben.

Da die Wahrscheinlichkeits- und Auswirkungswerte numerisch sind, wird die Berechnung des „Risikofaktors“ erleichtert.

Risikofaktor = Wahrscheinlichkeit X Auswirkung. Je höher der Risikofaktor, desto schwerwiegender ist das Problem.

Ein Beispiel::

Bitte beachten Sie, dass dies zu diesem Zeitpunkt einfach das Ergebnis der Bewertung eines Teams ist. Für ein Projekt, an dem 5 verschiedene Teams beteiligt sind, würde das QS-Team 5 verschiedene Tische haben.

Schritt 5)

Nehmen Sie einen Durchschnitt der Risikofaktorwerte. Zum Beispiel, Wenn es 5 Teams gibt, addieren Sie für jedes Modul alle Risikofaktorwerte und teilen Sie sie durch 5. Dies sind die endgültigen Werte, mit denen wir uns befassen werden. Angenommen, dies sind die gemittelten Risikofaktoren:

Je höher der Risikofaktor, desto mehr muss das Modul getestet werden.

Modul 5 und 2 sind daher für den Erfolg des Unternehmens von entscheidender Bedeutung. Teilen Sie die Ergebnisse mit allen Teams.

Schritt 6)

Risikominderungsplan : Dies ist der Schritt, der sich von Projekt zu Projekt ändert. Wir haben festgestellt, dass die Module 5 und 2 diejenigen sind, auf die man sich am meisten konzentrieren muss.

Beispieledes Plans könnte sein:

1. Die Module 5 und 2 werden gründlich getestet, indem sichergestellt wird, dass alle damit verbundenen Testfälle getestet werden. Die anderen Module werden explorativ getestet.
2. Die Module 5 und 2 werden zuerst getestet und dann werden je nach verfügbarer Zeit die anderen betreut.

Sobald ein Plan erstellt wurde, treffen alle Teams eine Vereinbarung und befolgen diese, um das Produkt unter Berücksichtigung des Risikofaktors zu testen.

Das ist es!

Einige wichtige Punkte zu beachten:

• Da dies eine kollektive Aktivität ist, die dauert die Meinung aller berücksichtigen ;; Die Chancen, dass es genau und effektiv ist, sind höher.
• Das ist keine formale Methode und muss nicht Teil jedes QS-Projekts sein.
• Manchmal, selbst wenn das Team keine Tabellen zeichnet und keine Werte zuweist - a einfache Brainstorming-Sitzung Mit allen Anwesenden kann das QS-Team eine gute Anleitung für das weitere Vorgehen geben.
• Das Input des Entwicklungsteams ist sehr wichtig, da sie das Produkt erstellen, damit sie wissen, was möglicherweise funktioniert und was möglicherweise zusätzliche Überprüfungen erfordert. Achten Sie darauf, dass Sie danach Ausschau halten.
• Obwohl der Prozess mehrere Schritte umfasst, Die Durchführung nimmt nicht viel Zeit in Anspruch . Vor allem, wenn alle Teams zusammen sitzen und gleichzeitig arbeiten können.
• Denken Sie an diesen Prozess und sein Ergebnis ist nur die Alternative . Wenn Sie so viel Zeit wie geplant für Tests haben, ist dies der beste Weg, um die QS-Aktivität durchzuführen.

Fazit

Der risikobasierte Testansatz zeigt deutlich, dass der Fokus des Testers nicht nur darauf liegt, die Fehler unabhängig von Schweregrad und Priorität weiter zu untersuchen. Jetzt haben sich die Dinge geändert und Tester müssen intelligent arbeiten und die klaren „Bedürfnisse des Kunden und Wünsche des Benutzers“ verstehen.

Sie müssen das Produkt gründlich untersuchen und verstehen, welches Merkmal in der Produktion am häufigsten verwendet wird, welcher der kritischste Weg für die Umsatzgenerierung ist und wie die Kunden vor Produktionsproblemen und Geschäftsbedrohungen geschützt und geschützt werden können.

Daher lehrt der RBT-Ansatz die 3 Tester eindeutig, dass nur das Testen von allem oder das ausgiebige Testen nicht bedeutet, dass das Testen abgeschlossen ist oder dass das Produkt keine Mängel aufweist. Effektives Testen in einer festgelegten Zeit und Sicherstellen, dass kritische und wichtige geschäftliche Auswirkungen zunichte gemacht werden, und das ist für den Tester sehr wichtig.

Daher sind risikobasierte Tests das effizienteste Instrument für das QS-Team, um die Projektbeteiligten anhand der Projektrisiken zu steuern. Der RBT-Ansatz hilft dem QS-Team bei der kontinuierlichen Identifizierung von Risiken und deren Lösung, die die Erreichung der allgemeinen Projektziele und -ziele gefährden könnten, und hilft bei der Erreichung des Endziels der QA-Gruppe.

P.S. Die Wörter QS und Testing wurden im gesamten Dokument synonym verwendet.

Über den Autor: Dieser Artikel wurde von mehreren STH-Teammitgliedern verfasst - Gayathri Subrahmanyam und Swati S.

Gayathri ist ein KMU für Softwaretests mit mehr als zwei Jahrzehnten Erfahrung im Bereich Softwaretests. In mehreren Projekten hat er den Ansatz des „risikobasierten Testens“ im Rahmen der Testindustrialisierung umfassend übernommen und die Vorteile der Optimierung von Testressourcen und Qualitätsprüfungen erkannt.

War das risikobasierte Testen für Sie eine Herausforderung? Haben Sie interessante Fakten, die Sie unserem Tutorial hinzufügen können? Fühlen Sie sich frei, Ihre Gedanken in den Kommentaren unten auszudrücken!

=> Besuchen Sie hier für eine vollständige Testplan-Tutorialserie

Literatur-Empfehlungen

• Kontinuierlicher Integrationsprozess: So verbessern Sie die Softwarequalität und reduzieren das Risiko
• Fehlermodus- und Auswirkungsanalyse (FMEA) - Analyse von Risiken für eine bessere Softwarequalität und zufriedene Kunden!
• Der ultimative Leitfaden für risikobasiertes Testen: Risikomanagement beim Testen von Software
• Top 10 Tools und Techniken zur Risikobewertung und -verwaltung
• Arten von Risiken in Softwareprojekten
• Einige interessante Fragen zu Softwaretests
• Wählen Sie Software-Tests als Ihre Karriere
• Feedback und Bewertungen zum Softwaretestkurs