Risikobasiertes Testen

Um die Qualität des Informationsprodukts in Medizin, Versicherungen, Banken und anderen Branchen sowie andere Testmethoden sicherzustellen, ist es wichtig, risikobasierte Tests zu verwenden. Zur Überprüfung werden die riskantesten Bereiche der zu erstellenden Software ausgewählt. Dies ermöglicht es uns, negative Szenarien zu antizipieren und die Geschäftsziele des Kunden erfolgreich umzusetzen.

In diesem Artikel erfahren Sie, wie wir bei SimbirSoft mit Risiken umgegangen sind (am Beispiel des Internet-Acquiring-Systems und anderer Projekte) und welche Methoden zur Risikobewertung und zum Risikomanagement wir in Kundenprojekten verwenden.

Risiken zu Beginn des Projekts

Zunächst geben wir ein Beispiel aus unserer Praxis in der Entwicklung für den Bankensektor.

Kundenvorschlag: Konzentration auf die Webversion der Bank für Privatpersonen.

Das Risiko, das wir identifiziert haben: ein möglicher Verlust des Publikums aufgrund der geringen Nachfrage der Webversion nach Einzelpersonen im Gegensatz zu einer mobilen Kundenbank.

Unsere Argumente: Statistiken der Benutzerpräferenzen basierend auf Bewertungen und Verteilung des Publikums nach Mobil- und Webversionen.

Schlussfolgerungen: Für Einzelpersonen ist die mobile Version bequemer, da das Telefon immer zur Hand ist. Der Betrieb ist schnell, das Autorisierungssystem ermöglicht Ihnen den Zugriff auf alle praktischen Dienste. In diesem Fall ist ein schneller Zugriff auf einen begrenzten Satz der beliebtesten Funktionen wichtig.

Für juristische Personen sind die Vollständigkeit der bereitgestellten Funktionen, die Fähigkeit zum Hochladen, Drucken und Arbeiten mit einer großen Menge von Informationen wichtig. Dafür ist die Webversion bequemer.

Unsere Lösung: sich auf die mobile Kundenbank für Privatpersonen konzentrieren.
Zu Beginn der Arbeit mit dem Projekt ist es wichtig, die Teststrategie richtig zu wählen. Schauen wir uns Beispiele an, warum es wichtig ist und wie man es auswählt.

Die Teststrategie muss die Geschäftsziele erfüllen

Früher oder später stehen alle Unternehmen vor der Notwendigkeit, den Testprozess zu organisieren und zu verstehen, dass die Entwicklung ihrer Strategie eine wichtige Phase in der Softwareentwicklung darstellt. Manchmal - durch ihre eigene bittere Erfahrung. Es ist besonders gefährlich, die Rolle von Tests und Strategieauswahl bei der Entwicklung von Großprojekten zu unterschätzen. Der Testprozess sollte gemäß den Geschäftszielen und -spezifikationen des Projekts ausgewählt werden, da er sonst weder in einem Monat noch in einem Jahr zu positiven Ergebnissen führt.

Testen Sie beispielsweise mobile und Webanwendungen für eine Bank. Zu Beginn des Projekts haben wir eine Strategie ausgewählt, die auf Anforderungen mit geringem Detaillierungsgrad basiert. Wir haben Checklisten verwendet, um die Testzeit zu verkürzen und die Testbasis zu unterstützen. Mit dem Wachstum der Funktionalität, der Hinzufügung von Erfassung, SMS-Autorisierung und Benachrichtigung, komplexeren Systemen, werden Checklisten ihrer Aufgabe nicht mehr gerecht. Im Laufe der Zeit schlossen sich immer mehr QS-Spezialisten dem Team an. Es war notwendig, Informationen zu übermitteln und ihre Aktionen zu koordinieren. Mit der Komplikation des Produkts kann jede Änderung verwandte Funktionen beeinträchtigen, dh das Risiko einer Regression steigt. Die Notwendigkeit zur Automatisierung von Regressionstests nahm zu, daher wechselten wir zu Testfällen.

Fazit: Je nach Projekt, Besonderheiten oder Entwicklungsstand ändert sich die Teststrategie.

Die Strategie muss für die Projektziele ausgewählt werden, um die beste Produktqualität zu gewährleisten. Sie beantwortet die Fragen „Was“, „Wo“ und „Wann“. Sie wissen jederzeit, zu welchem ​​Zeitpunkt Sie sich befinden und wohin Sie in Zukunft kommen werden - entsprechend der Strategie.

Ein Geschäftsziel kann darin bestehen, die Sicherheit der Kundendaten sowie der Software selbst in der Produktionsphase zu gewährleisten. Sicherheit beginnt mit dem Entwicklungsprozess und setzt sich in der Testphase fort.

Beispielsweise haben wir bei einem der Projekte eine sichere Umgebung für Entwicklung und Test geschaffen, eine Infrastruktur bereitgestellt, die alle Anforderungen erfüllt und zum Schutz der Daten beiträgt. Wir haben für jeden QS-Spezialisten zertifizierte Token und namensbasierte Flash-Laufwerke angefordert, um auf die Testinfrastruktur zugreifen zu können. So haben wir das Geschäftsziel des Projekts in der Software-Sicherheit sichergestellt und die Kunden- und Benutzerdaten vertraulich behandelt.

Aufgrund der Teststrategie kann der Schwerpunkt auf wirklich wichtige Aspekte für ein bestimmtes Projekt gelegt werden. Es ist logisch, dass die Veröffentlichung eines Handyspiels oder eines komplexen CRM-Bankensystems unterschiedliche Testansätze erfordert.

Bankenteststrategie

In unserer Praxis haben wir bei SimbirSoft die gesamte Bandbreite der Entwicklungsmethoden verwendet, aber flexible Technologien bleiben immer unsere Priorität. Und selbst wenn es aus einer Reihe von Gründen nicht möglich ist, sie zu verwenden, übernimmt das Team die Best Practices und wendet sie in der täglichen Arbeit an. Das Testen wird zu einem integralen Bestandteil des gesamten Prozesses und fügt sich in den gesamten Workflow ein. In diesem Fall ist es nicht nur für die Qualität des Produkts verantwortlich, sondern auch für die Qualität des gesamten Arbeitsprozesses.

Welche Technologien verwenden wir:

• flexible Planung und Vorbereitung interner Releases;
• User Story Vorbereitung;
• Abhalten von Kundgebungen;
• Durchführung von Retrospektiven.

In vollem Umfang zeigt sich die Teststrategie in Projekten mit komplexer Geschäftslogik. Zum Beispiel Software zur Informationsunterstützung von Banken, der Aufbau eines Internet-Acquiring-Systems, eine automatisierte Handelsplattform. Bei solchen Projekten ist es wichtig, eine geeignete Teststrategie anzuwenden, da der Preis einiger Fehler zu echten Verlusten führen und den Ruf des Unternehmens erheblich verschlechtern kann.

Außerdem können die Hauptziele des Testens - Fehlersuche und Softwareüberprüfung auf Konformität - zusätzlich hinzugefügt werden. Beispielsweise ist es für Banken wichtig, die neuen Anforderungen der Zentralbank schnell umzusetzen. Dies bedeutet, dass zeitnahe Tests mit der erforderlichen Qualität für kritische Aufgaben zum Hauptziel hinzugefügt werden.

Vor kurzem waren wir in einem Bankprojekt mit einer Änderung des Bundesgesetzes konfrontiert - einer Erhöhung des Mehrwertsteuersatzes von 18% auf 20%. Es wurden viele Vorarbeiten zur Anpassung an die Gesetzesänderung geleistet, da die Änderung nicht nur das Ersetzen von Formularen, Schnittstellen, sondern auch die Änderung der Logik mehrerer Berechnungsformeln betraf. Auf vielen Plattformen musste die korrekte Anzeige sichergestellt werden. Auch bei der Zahlungsaufschubfunktion musste die Übergangsfrist mit Sätzen von 18% und 20% berücksichtigt werden.

Jetzt werden wir detaillierter darüber sprechen, wie wir unsere Strategie entwickeln und warum wir uns häufig für risikobasierte Tests entscheiden.

Vorteile von risikobasierten Tests

Es gibt verschiedene Teststrategien, die für bestimmte Zwecke ausgewählt werden:

• basierend auf Anforderungen;
• methodisch;
• reaktive Strategien;
• Beratungsstrategien.

Bei der Arbeit mit Projekten mit komplexer Geschäftslogik müssen strenge Anforderungen beim Entwurf von Systemen festgelegt werden, auf denen das Testen basiert. Ein geeignetes Werkzeug ist das anforderungsbasierte Testen.

Eine Art von anforderungsbasierter Strategie ist das risikobasierte Testen. Darüber hinaus werden zuerst die Teile der Systemfunktionalität getestet, die am stärksten Risiken ausgesetzt sind. Das Risiko ist eine mögliche negative Folge eines fehlerhaften Systems. Die Folge ist ein Risiko bei Vorhandensein von zwei Komponenten wie Chance und Negativität.

Es gibt zwei Arten von Risiken:

1. Produktrisiko

Es kann verwaltet und nicht verwaltet werden. Im obigen Beispiel waren wir mit einem überschaubaren Risiko konfrontiert: schnelles Wachstum und Komplexität der Funktionalität, was die Wahrscheinlichkeit einer Regression erhöhte. Hier haben wir das Problem durch eine verständliche Testbasis und anschließende Automatisierung gelöst. Das Risiko, das wir nicht beeinflussen können, ist die Abhängigkeit von externen Systemen und deren Ausfall im Integrationsprozess. Hier legen wir die Maßnahmen fest, die ihre Auswirkungen auf unser System verringern. Verwenden Sie beispielsweise die Sicherung, behandeln Sie Ausnahmefälle und zeigen Sie Warnungen für den Benutzer an.

2. Projektrisiko

Bei einem Projekt waren wir beispielsweise mit der Tatsache konfrontiert, dass der Kunde zuvor nicht mit einem verteilten Team zusammengearbeitet hatte und der verwendete Workflow daher nicht den Anforderungen entsprach und zusätzliche Kommunikationsprobleme verursachte: Unverständnis, Doppelarbeit von Aufgaben, Ausführung sich gegenseitig ausschließender Aufgaben usw. Wir haben uns auf die Umstrukturierung und Verbesserung des Prozesses geeinigt - den Workflow überarbeitet, alle Teammitglieder vorgestellt, Kundgebungen, Präsentationen und Rückblicke abgehalten. Infolgedessen ging die Arbeit in die richtige Richtung.

Der risikobasierte Ansatz ermöglicht es Ihnen, eine bestimmte Anzahl von Risiken für kurze Zeit zusammenzustellen, um die Risiken mit hoher Priorität zu testen und dem Kunden außerdem Metriken zu liefern, wie gut sie getestet wurden, wobei die Anzahl der geplanten und abgeschlossenen Fälle und die Anzahl der Fehler angezeigt werden.

Die Umsetzung eines risikobasierten Ansatzes für ein Projekt erfolgt in vier Schritten:

Risikoidentifikation - In dieser Phase müssen Sie die Risiken identifizieren und eine Liste von ihnen erhalten.
Risikobewertung - hier analysieren wir die Liste und klassifizieren sie nach Priorität.
Risikominderung - In dieser Phase legen wir fest, wie gründlich wir die Risiken testen werden.
Risikomanagement - hier entscheiden wir, wie wir weiterhin mit ihnen zusammenarbeiten und sie durchgehen, um neue Risiken zu identifizieren.

Risiken werden von einer Gruppe von Stakeholdern während Brainstorming-Sitzungen identifiziert und bewertet. Das Team sollte Geschäftsanalysten oder Wissensträger über das System von Kunden, Entwicklern, Managern oder Projektmanagern, Architekten und QS-Spezialisten umfassen. Wir beschäftigen Informationssicherheitsspezialisten, Mitarbeiter, die direkt mit dem aktuellen System arbeiten, und Geschäftsanalysten, die in Prozesse zur Identifizierung und Bewertung von Risiken vertieft sind.

Betrachten Sie den risikobasierten Ansatz am Beispiel des Testens des Internet-Erfassungssystems.

Arbeiten Sie mit Risiken (am Beispiel eines Internet-Acquiring-Systems)

Wir stellen die folgenden Anforderungen heraus:
Stellen Sie 1000 gleichzeitige Verbindungen zum System pro Sekunde bereit.
D2. Transaktionssicherheit.
D3. Der Zugriff auf die Transaktion sollte nur der Person zur Verfügung stehen, die die Transaktion durchführt.
D4. Bereitstellung und Unterstützung des SET-Standards (Secure Electronic Transaction).

Als Produktrisiko können wir unterscheiden:
RP1. Systemabsturz bei gleichzeitigen Verbindungen.
RP2. Verwenden der SQL-Injection während der Transaktion.
RP3. Zugriff auf die Transaktion einer anderen Person, wenn Parameter in der URL geändert werden.
RP4. Datenverlust, wenn die Verbindung zur Bank zum Zeitpunkt der Transaktion unterbrochen wird.
RP5. Verwendung ungültiger Zertifikate bei der Bereitstellung des SET-Systems (Secure Electronic Transaction).

Als organisatorische Risiken:
RO1. Der Fall des entwickelten Systems aufgrund der Unzugänglichkeit externer Systeme.
RO2. Das Vorhandensein schwer zu reproduzierender Fälle, die in einer Testumgebung nicht erkannt werden können.

Somit folgt jedes Risiko logischerweise aus den Anforderungen, die im System vorhanden sind, ist jedoch nicht auf diese beschränkt. Risiken ergänzen die Anforderungen und identifizieren zusätzliche Fälle, die bei der Arbeit mit dem System auftreten können.

Risiken können je nach Projektziel und Systemanforderungen reduziert oder kompensiert werden. Es wird akzeptiert, dass das Risiko mindestens einmal durch den Testfall abgedeckt wird:

1. Für jedes Produktrisiko wird eine Reihe von Testfällen RP1-RP4 unter der Bedingung erstellt, dass jede Anforderung und jedes Risiko von mindestens einem Testfall abgedeckt werden sollte. Abhängig von den Testzwecken wird der Satz von Testfällen auf einen bestimmten Detaillierungsgrad erweitert.

2. Für jedes organisatorische Risiko wird eine Liste von Aktivitäten erstellt, mit denen die Auswirkungen des Risikos auf das zu entwickelnde Produkt verringert werden können.

Risikobewertung und Managementtechniken

Es gibt verschiedene Methoden zur Bewertung und zum Management von Risiken: leichte Methoden (PRAM, PRISMA) und formellere (FMEA, FTA).

Mit dem FMEA-Modell identifiziert das Projektteam alle Prozesse, Komponenten und Module des Systems, in denen ein Systemfehler oder -fehler auftreten kann, der zu einer Verschlechterung der Produktqualität führen kann. Während des Brainstormings werden die Risiken des Systems durch drei Indikatoren bestimmt: Schweregrad, Priorität, Wahrscheinlichkeit. Anschließend wird für jedes Risiko die Risikoprioritätszahl berechnet und in Abhängigkeit von den Indikatoren die Prüftiefe festgelegt.

Mit dem FTA-Modell werden alle Ursachen, die zu Fehlern in den Geschäftsprozessen des Systems führen können, schrittweise ermittelt. Die Analyse geht von der höchsten zur niedrigsten Ebene. Der Unterschied zwischen FMEA und FTA besteht darin, dass sich der erste Ansatz auf die Funktionalität des Systems und der zweite auf Geschäftsprozesse konzentriert.

Zusätzlich zu diesen formellen und umfangreichen Ansätzen gibt es flexiblere und informellere. Zum Beispiel die Methoden PRAM (Pragmatische Analyse und Risikomanagement) und PRISMA (Produktrisikomanagement). Sie kombinieren risiko- und anforderungsbasierte Strategien erfolgreich und einfach. Grundsätzlich verwenden diese Ansätze Anforderungsspezifikationen als Input, es können jedoch auch Stakeholder einbezogen werden.

Leichte Risikoanalysemethoden sind formalen sehr ähnlich. Sie konzentrieren sich auf technische oder kommerzielle Risiken und wägen die Eintrittswahrscheinlichkeit des Risikos und die diese Wahrscheinlichkeit beeinflussenden Faktoren ab.

Die einzigen zwei Faktoren, die von diesen Methoden verwendet werden, sind die Wahrscheinlichkeit des Risikos und seine Auswirkungen. Darüber hinaus verwenden diese Ansätze vereinfachte qualitative Beurteilungen und Skalen, um Entscheidungen zu treffen.

Unsere Teams verwenden flexible Leichtbaumethoden und passen PRAM- und PRISMA-Ansätze an ihre Ziele an.

Wie wir mit risikobasierten Tests arbeiten

Beispielsweise identifizieren wir in einem der Projekte Projekt- und Produktrisiken, die möglicherweise funktionieren. Zu diesem Zweck nehmen Analysten, Entwickler und die Qualitätssicherung an der Analyse teil - ein Vertreter des Teams.

Mit den Produkten wird eine Risikotabelle erstellt. Sie bestimmen die Einschätzung der Eintrittswahrscheinlichkeit eines Risikos und seiner möglichen Auswirkungen auf das System auf einer Fünf-Punkte-Skala. In Tabelle 1 - der stärkste Einfluss, 5 - der schwächste. Auch für Wahrscheinlichkeit 1 - hohe Wahrscheinlichkeit, 5 - niedrige Wahrscheinlichkeit.

Wie wir weiterhin mit Produktrisiken arbeiten

Ferner wird für jeden von ihnen die Risikodeckung des Produkts anhand von Testfällen verfolgt.

Wir wählen folgende Schecks aus:

TC1. Lastprüfung mit mehr als 1000 Verbindungen zum System
TC2. Lasttest mit 1000 Systemverbindungen
TC3. Geben Sie während der Transaktion die SQL-Injection ein
TC4. Geben Sie SQL Injection auf der Seite für erfolgreiche Transaktionen ein, indem Sie andere Daten ersetzen
TC5. Eingabe von XSS-Skripten (Cross-Site Scripting) in die verfügbaren Felder zur Eingabe bei einer Transaktion
TC6. Simulation einer getrennten Internetverbindung während einer Transaktion
TC7. Beenden einer Transaktionssitzung im Überprüfungsschritt
TC8. Validierung abgelaufener Zertifikate während der Transaktion



Somit sind Prioritätsprüfungen TC2, TC4, TC5.

TC6 und TC8 haben eine hohe Auswirkung, aber eine geringere Wahrscheinlichkeit, sodass die Priorität der Überprüfung geringer ist, aber auch Überprüfungen erforderlich sind.

TC7 gilt für keine der Anforderungen, erweitert jedoch den Test für ein negatives Szenario, was bei stabilem Betrieb des Systems möglich ist.

Wie wir weiterhin mit Projektrisiken arbeiten

Wir legen auch Maßnahmen für Projektrisiken fest, mit denen wir zusätzliche Maßnahmen und Entscheidungen zuweisen.

Auf Risiko “RO2. Das Vorhandensein schwer zu reproduzierender Fälle, die in der Testumgebung nicht erkannt werden können “, können Sie wie folgt feststellen:

• Bereiten Sie in Verbindung mit allen externen Systemen einen Vorproduktionsstand vor, der der realen Anwendungsumgebung so nahe wie möglich kommt.
• Schreiben Sie End-to-End-Testskripte, die alle benachbarten Systeme durchlaufen und die Transaktionsüberprüfung ermöglichen.
• Verwenden Sie nach Durchführung aller Prioritätsprüfungen die Fehlerschätztechniken gemäß den grundlegenden Anforderungen des Systems und der Skripte für zusätzliche Überprüfungen in der Rolle eines „Systemhackers“.

Notfallplan

Es ist wichtig, einen Aktionsplan zu haben, falls eines der Produkt- oder Projektrisiken funktioniert. Manchmal kann das Einrichten eines Sicherungssystems des Projekts gespeichert werden. Es ist nicht immer möglich, das Risiko auf ein Minimum zu reduzieren, aber es sollte möglich sein, zumindest seine Folgen zu reduzieren. Unser Beitrag „Weihnachtsgeschichte“ befasste sich mit diesem Thema: Wie ein Risiko funktionieren kann, dessen Wahrscheinlichkeit gegen Null geht.

Zum Beispiel müssen wir Datenverluste während einer Transaktion vollständig beseitigen, aber alle Fälle als zu mühsam betrachten. Daher müssen Sie Möglichkeiten haben, solche Fälle zu behandeln. Eine der Sicherheitsoptionen ist die Entwicklung einer detaillierteren Protokollierung. Dies bietet einen permanenten Rollback-Punkt für die vorherige Aktion, wenn während der Transaktion ein Fehler aufgetreten ist.

Fazit

Mit risikobasierten Tests können Sie die risikoreichsten Bereiche mit Testfällen abdecken und so deren Auswirkungen und die Wahrscheinlichkeit, ausgelöst zu werden, verringern. Dies ist die erfolgreichste Strategie für Systeme mit komplexer Geschäftslogik und hohen Fehlerkosten. Die Lösung eignet sich für den Bankensektor, Versicherungsunternehmen, komplexe interne CRM-Systeme eines medizinischen Profils. Mit einem risikobasierten Ansatz arbeiten wir auch mit Projektrisiken, was den Gesamtprozess des Testens und des Projektmanagements verbessert.