V & V bedeutet nicht Vendetta

In den letzten sechs Jahren habe ich eine Vielzahl von Anwendungen in Bezug auf Komplexität und Größe für die Durchführung und Aufrechterhaltung klinischer Studien entwickelt und akzeptiert. Big Data, eine Vielzahl von Visualisierungen und Ansichten, Data Warehousing, ETL und dergleichen. Das Produkt wird von Ärzten, Führungskräften und Personen verwendet, die an der Kontrolle und Überwachung der Forschung beteiligt sind.

Für Anwendungen, die sich direkt auf das Leben und die Gesundheit von Patienten auswirken oder auswirken können, ist ein formaler Abnahmetest erforderlich. Die Ergebnisse der Abnahmetests werden zusammen mit dem Rest des Dokumentationspakets der FDA (Food and Drug Administration, USA) zur Prüfung vorgelegt. Die FDA genehmigt die Verwendung des Antrags als Instrument zur Überwachung und Durchführung klinischer Studien. Insgesamt hat mein Team mehr als 30 Anwendungen entwickelt, getestet und in die Produktion geschickt. In diesem Artikel werde ich kurz über Akzeptanztests und die Entwicklung von Werkzeugen in einer kleinen Gruppe sprechen.

Hinweis: Ich gebe nicht vor, die ultimative Wahrheit zu sein, und ich verstehe, dass das meiste, worüber ich schreibe, der Monolog des Kapitäns ist. Ich hoffe aber, dass sich das Beschriebene sowohl für den Einsteiger als auch für die Teams, die im Arbeitsalltag darauf stoßen, als nützlich erweisen wird, oder zumindest für diejenigen, die einfachere Abläufe haben.

FDA

Klinische Studien auf der ganzen Welt sind ein wesentlicher Schritt in der Entwicklung von Arzneimitteln, die der Registrierung und der weitverbreiteten medizinischen Verwendung vorausgehen. In klinischen Studien wird ein neues Medikament untersucht, um Daten zu seiner Wirksamkeit und Sicherheit zu erhalten. Wikipedia

Mit anderen Worten, damit eine Pille „vom Kopf“ irgendwo in Brighton Beach zu einer Apotheke gelangt, durchläuft sie drei Phasen menschlicher Versuche, in denen bestimmt wird, wie viel Wirkstoff in der Tablette enthalten sein sollte, wie sicher sie ist und ob sie überhaupt heilt Kopfschmerzen.

Was ist die FDA für uns und wie wirkt sie sich auf den Entwicklungsprozess und den Veröffentlichungszyklus aus?

Die Food and Drug Administration (FDA, USFDA, Schreiben. Food and Drug Administration) ist eine Behörde des US-amerikanischen Gesundheitsministeriums und einer der Exekutivabteilungen des Bundes. Die Abteilung befasst sich mit der Qualitätskontrolle von Lebensmitteln, Pharmazeutika, Kosmetika, Tabakwaren und einigen anderen Warengruppen und überwacht auch die Einhaltung der Rechtsvorschriften und Normen in diesem Bereich. Wikipedia

Die FDA kümmert sich praktisch nicht um den Entwicklungsprozess selbst. Wir arbeiten an dem üblichen SCRUM (oder besser gesagt, nicht ganz SCRUM - man sagt, es ist jetzt in Mode, einen solchen "modifizierten SCRUM" zu nennen) mit einem nicht sprintenden Release-Zyklus. Wir gehen am Ende des Sprints (und sogar am Ende von drei Sprints und sogar zehn, wenn die Zeitleiste 15 Sprints umfasst) nicht zum Produkt, das heißt, wir haben aus Sicht der Lieferung an den Endbenutzer etwas Wasserfallartiges.

Die Tests in unserem Fall sind in zwei unabhängige Teile unterteilt, mit unterschiedlichen Zeitplänen, unterschiedlichen Schätzungen und unterschiedlichen Prozessen. Der erste Teil ist der übliche In-Dev-Test, bei dem der Tester fester Bestandteil des Entwicklungsteams ist und die Sprints zusammen mit der Entwicklung beendet. Der zweite Teil ist die eigentliche Abnahmeprüfung und Wartung (falls erforderlich). Der Prozess ist nach der V & V-Methodik aufgebaut: Benutzer- und Funktionsanforderungen am Eingang, Tests und ein Paket mit unterstützender Dokumentation am Ausgang.

Der Release-Zyklus hängt vom Arbeitsvolumen ab, Releases durchlaufen im Allgemeinen keine Iterationen. Nach der Veröffentlichung kann die Anwendung für eine lange Zeit unverändert bleiben, dh eine Pause zwischen Veröffentlichungen - von einigen Monaten bis zu einem Jahr oder mehr.

V & V

Was für ein Tier ist das, V & V, und wie spiegelt sich dies im Akzeptanzprozess wider?

„Bei Softwareprojektmanagement, Softwaretests und Softwareentwicklung wird durch Verifikation und Validierung (V & V) überprüft, ob ein Softwaresystem den Spezifikationen entspricht und den beabsichtigten Zweck erfüllt. Es kann auch auf eine Softwarequalitätskontrolle Bezug genommen werden. Es liegt normalerweise in der Verantwortung der Softwaretester im Rahmen des Softwareentwicklungslebenszyklus. In einfachen Worten lautet die Softwareverifizierung: "Unter der Annahme, dass wir X erstellen sollten, erreicht unsere Software ihre Ziele ohne Fehler oder Lücken?" Auf der anderen Seite lautet die Softwarevalidierung: "War X das, was wir hätten erstellen sollen? Erfüllt X die hohen Anforderungen? » Wikipedia

Freie Übersetzung:

„Beim Projektmanagement, Testen und Entwickeln von Software wird durch Verifizieren und Validieren (V & V) überprüft, ob die entwickelte Software den Spezifikationen entspricht und die beabsichtigte Funktion erfüllt. Dies kann auch der allgemeinen Qualitätskontrolle zugeschrieben werden. In der Regel sind Testingenieure für die Verifizierung und Validierung des Softwareentwicklungslebenszyklus verantwortlich. Mit einfachen Worten kann die Softwareverifizierung folgendermaßen beschrieben werden: „Angenommen, wir müssen System X entwickeln. Haben wir das Ziel ohne Fehler und Annahmen erreicht?“ Andererseits lautet die Softwarevalidierung „Entwickeltes System X ist wirklich etwas Was wollten wir bekommen? Erfüllt System X die höchsten Anforderungen? “

Mit anderen Worten:
Überprüfung: Machen wir das Produkt richtig?
Validierung: Machen wir das richtige Produkt?

Dies bedeutet, dass wir die Funktions- und Anwenderspezifikationen mit der notwendigen und ausreichenden Vollständigkeit prüfen müssen. Das erste V wird für uns zur Abnahmeprüfung (SIT), das zweite zur Wartung (UAT).

• SIT - Systemintegrationstest
• UAT - User Acceptance Testing

Die Visualisierung der Bedarfsdeckung erfolgt in der Rückverfolgbarkeitsmatrix (eine reguläre Tabelle in Excel oder Word, auf die ich später noch eingehen werde), die die Rückverfolgung von den Anforderungen bis zum Test und zurück ermöglicht. Bei Verwendung der elektronischen Dokumentenverwaltung wird die Matrix automatisch erstellt, die Tests werden mit den Anforderungen verknüpft, die zusammen mit den Tests gespeichert werden (zusammen = HP ALM, natürlich nicht in Haufen gespeichert). Falls der Bedarf nicht gedeckt ist und nicht gedeckt wird, erklären wir warum.

Wann ist eine Deckungspflicht nicht erforderlich?

Zum Beispiel enthält CFR Part 11 (die von der FDA festgelegten Regeln für elektronische Aufzeichnungen und Signaturen ) eine Vielzahl von Anforderungen, die bereits von Microsoft abgedeckt werden. Wenn wir Windows AD für die Authentifizierung verwenden, müssen wir sie nicht erneut behandeln.

Letztendlich besteht das Wesen der Abnahmeprüfung darin, das Produkt auf Übereinstimmung mit den Anforderungen und Anforderungen an die Produktkonformität zu prüfen.

Rollen

An dem Prozess ist eine relativ große Anzahl von Rollen beteiligt, die in der einen oder anderen Form allen an der Softwareentwicklung Beteiligten bekannt sind: Entwickler (Junior, Middle, Senior, Lead), Unit Tester, SIT Tester, technischer Product Owner, geschäftlicher Product Owner, Scrum Master , Projektmanager, Business Analyst, technischer Leiter, SIT-Testleiter, UAT-Testleiter, globale Qualitätskontrolle, Support, Deployment Engineer und andere.

Unsere spezifische Rolle ist die globale Qualitätskontrolle . Dies ist die Person auf Kundenseite, die für die Einhaltung der Anforderungen des Prozesses - Software Lifecycle und alle Arten von Standard Operational Procedures (SOP) auf Kundenseite - während der Entwicklung und Abnahme verantwortlich ist und außerdem ein Paket von Dokumenten für die externe Prüfung bereitstellt.

Abnahmeunterlagen

Im Rahmen der Produktversion wird ein Dokumentationspaket mit einer großen Anzahl von Verschachtelungsebenen erstellt, einschließlich der Dokumentation darüber, wie das Produkt getestet wurde, warum es auf diese Weise und nicht auf andere Weise getestet wurde und was speziell getestet wurde und was ausgelassen wurde:

Validierungsplan und Teamliste - PM ist für das Schreiben und Genehmigen des Dokuments verantwortlich. Ein Dokument enthält normalerweise eine Beschreibung des Systems, eine Liste der Artefakte, die während der Entwicklung und des Testens erstellt werden, eine Validierungsstrategie und eine Liste der Rollen mit Verantwortlichkeiten.

Teststrategie - Ein Dokument, das nicht für eine bestimmte Anwendung gilt, sondern für einen separaten Produktzweig oder für einen separaten Testzweig erstellt wird. Zum Beispiel, wie und warum wir bestimmen, was wir automatisieren und was nicht; welche Technologien; wie wir manuelle Tests arrangieren (Checklisten oder Testskripte oder beides zusammen oder etwas völlig anderes); wie wir entscheiden, ob wir die Last fahren oder nicht; und so weiter und so fort.

Testplan - für UAT- und SIT-Teams üblich. Enthält eine kurze Beschreibung des Testobjekts, mögliche Einschränkungen, Umgebungsbedingungen, Timing, Testsuiten usw.

Test Suite - Eine Reihe von Tests oder Checklisten, die nach Funktionsbereich, Testtyp oder anderen Merkmalen zusammengestellt sind.

Rückverfolgbarkeitsmatrix - Rückverfolgbarkeitsmatrix von der Anforderung bis zum Test. Die Rückverfolgung als Nachweis der Abdeckung ist ein wichtiger Teil des Prozesses. Indem Sie eine Anforderung identifizieren, können Sie einen bestimmten Schritt finden, in dem diese Anforderung bestätigt wird, und dem Prüfer Nachweise (Screenshot, Datei usw.) für eine bestimmte Version der Anwendung (oder für jede Version, in der diese Anforderung formell abgedeckt wurde) vorlegen. Verknüpfen, verknüpfen und verknüpfen Sie daher die Tests erneut mit den Anforderungen (Aufgaben), auf deren Grundlage Sie das erwartete Ergebnis erhalten, auch wenn dies nicht von Ihnen gefordert wird. Wenn dies aufgrund der Verwendung verschiedener nicht integrierender Tools nicht möglich ist, können Sie in den Aufgaben / Tests immer Kommentare hinterlassen, eine Matrix (wie oben erwähnt in Excel) erstellen oder eine primitive Datenbank mit drei Tabellen ablegen.

PDS - Product Design Specification, ein von einem technischen Berater oder Projektarchitekten entwickeltes Dokument, im Wesentlichen eine Kombination aus High-Level- und Low-Level-Anwendungsarchitektur (HLA und LLA).

FRS & URS oder BRS sind Funktions- und Benutzeranforderungen, in der Regel in Form von zwei separaten Dokumenten, manchmal jedoch auch in der Business Requirements Specification zusammengefasst.

Fehlerprotokoll - Ein Protokoll der beim Testen festgestellten Fehler (Anwendungsfehler und Anforderungen).

Minor Issues Log - ein Protokoll mit geringfügigen Fehlern in Tests (Tippfehler, fehlende / unnötige Anforderungen usw. - alle Fehler, die die Bedeutung des Tests grundsätzlich nicht ändern).

Test Summary Report - Bericht über die Testergebnisse. TSR ist das Abschlussdokument für den Testplan und enthält:

• Informationen zu den getesteten Baugruppen (einschließlich Versionsnummern und Bereitstellungsdaten), Anzahl der Testzyklen und Testergebnisse.
• Beschreibung der Verstöße gegen den Testplan und die Testverfahren (SOP), die vom Unternehmen zur Ausführung freigegeben wurden.
• Liste der offenen Fehler, in der die Gründe für die Übertragung auf die nächste Version erläutert werden.
• Verknüpfen Sie mit dem Fehlerprotokoll oder dem Protokoll selbst.
• Ein Link zum Testfehlerprotokoll oder zum Protokoll selbst.
• Eine Empfehlung für eine Entscheidung zum Einbau in die Produktion.

Bereitstellungsplan - Ein Dokument, für das Support und Integration verantwortlich sind. Es wird während der Installation in der SIT-Umgebung erstellt und anschließend zum Bereitstellen der Version in der Produktion verwendet.

Validierungszusammenfassungsbericht - Abschlussdokument für den Validierungsplan.

Dokumentengenehmigung

Jeder Prozess zur Genehmigung der Dokumentation ist in drei Phasen unterteilt:

• Vorbereitung des Dokuments.
• Rückblick
• Aussage.

Betrachten Sie das Beispiel der Test Suite.

Um Testskripte zu schreiben und zu Testsuiten zu kombinieren, verwenden wir eine vom Kunden genehmigte Standardvorlage.

Die Komponenten des Testkits:

• Der Name des Projekts und der Anwendung.
• Release-Version.
• Der Name und die eindeutige Kennung des Sets.
• Beschreibung (was wir testen, welche Arten von Tests verwenden wir).
• Tests.
• Liste der Genehmigenden.

Jeder Test umfasst wiederum:

• Name und eindeutige Kennung innerhalb des Sets.
• Beschreibung
• Voraussetzungen.
• Nachbedingungen.
• Rückverfolgung (im Test abgedeckte Anforderungsnummern).
• Ausführungsmerkmale (z. B. Anweisungen zum Maskieren vertraulicher Daten).
• Schritte (erforderliche Maßnahmen, erwartete und tatsächliche Ergebnisse).
• Das Ergebnis des Tests.
• Vollbracht
• Revuever.

Der normale Lebenszyklus eines Tests ähnelt einem Feedback-Wasserfall und sieht folgendermaßen aus:

1. Rechtschreibung
   Anforderungsanalyse. Definition und Anwendung von Testdesign-Techniken für die bestmögliche Abdeckung der Funktionalität. Schritte schreiben.
2. Testpassage / Passagen auf Jungfrauen
   In dieser Phase wird bewertet, inwieweit die Anwendung die Anforderungen erfüllt, und der Großteil der möglichen Fehler, einschließlich der Anforderungsfehler, wird ausgeglichen.
3. Projektmanager Review (SIT-Teamleiter)
   Stilistische und logische Überprüfung.
4. Testdurchgang / SIT-Umgebung weitergeben
   In dieser Phase werden Fehler im Zusammenhang mit der Installation, Umgebung und Konfiguration der Umgebung abgefangen (standardmäßig wird davon ausgegangen, dass die SIT-Umgebung PROD genau oder fast vollständig wiederholt). Ein erfolgreicher Abschluss dieser Phase bedeutet, dass die umschlossene Version stabil ist und die Veröffentlichung als Kandidat betrachtet werden kann.
5. Kundenbewertung (globale QC)
   Die globale Qualitätskontrolle überprüft, ob die Anforderungen erfüllt sind und ob schriftliche SOP-Tests beim Unternehmen vorliegen.
6. Genehmigung (globale QC, technische Bestellung, geschäftliche Bestellung).
7. Formale Testausführung in SIT-Umgebung (Release Candidate Version)
   Nach der Genehmigung der Tests für den Durchgang (S. 6) und dem erfolgreichen Abschluss der Testdurchgänge in der SIT-Umgebung (S. 4) wird der Test in der SIT-Umgebung mit der formellen Festlegung des Ergebnisses formell durchgeführt. Wenn die in Testdurchläufen gefundenen Fehler nicht formalisiert und einfach in Jira eingegeben werden, wie dies während des Entwicklungsprozesses geschieht, wird für jeden im formalen Durchlauf gefundenen Fehler ein separates Fehlerformular erstellt, das im Ausgabedokumentationspaket für das Produkt enthalten ist.
8. Überprüfung der Ergebnisse der für das Projekt verantwortlichen Passage (SIT-Teamleiter).
   Ähnlich wie in Punkt 3 wird der Füllungsstil überprüft und die Ergebnisse analysiert.
9. Kundenbewertung (globale QC)
   Global QC prüft die Richtigkeit und Vollständigkeit des Ausfüllens der Ergebnisse, eventuelle Fehler, Vorhandensein von Bestätigungen (zB Screenshots). Ein wichtiger Punkt, da es die globale Qualitätskontrolle ist, die für die Bereitstellung eines Pakets von Dokumenten für ein externes Audit (von der FDA oder von Kunden) verantwortlich ist.

Arbeit mit persönlichen Daten

Angesichts der Tatsache, dass die Forschung nach der Doppelblindmethode * durchgeführt wird, ist dies das geringere unserer Probleme. Die Daten von Ärzten, Firmennamen, Forschungsprotokollnummern usw. usw. müssen jedoch geändert werden. Aus formaler Sicht müssen wir sensible Daten auf den Screenshots maskieren, wenn wir sie nicht entfernen können, aber dies ist eine recht normale und verständliche Situation.

* Doppelblind - Doppelblindmethode. Die Patienten werden nach dem Zufallsprinzip in zwei Gruppen eingeteilt, von denen eine das Studienmedikament und die zweite ein Placebo oder Medikament mit nachgewiesener Wirksamkeit erhält. Gleichzeitig wissen weder der Arzt noch der Patient, welcher Gruppe der Patient zugeordnet wurde. Dies beseitigt die Verzerrung des Arztes und den Placebo-Effekt. Im Zusammenhang mit der Arbeit mit personenbezogenen Daten bedeutet dies, dass die Identität des Patienten in den meisten Fällen nicht anhand von Daten identifiziert werden kann, die in der Datenbank gespeichert sind oder auf die der Benutzer zugreifen kann.

Die Tatsache, dass dies das geringste unserer Probleme ist, bedeutet jedoch nicht, dass es keine Probleme bereiten kann. Hier sind ein paar Rechen, mit denen wir bei unseren Projekten angefangen haben:

Ein Schein des Spaßes: Ein Globus

In einer der Anwendungen zur Erzeugung eines Wow-Effekts mussten wir nicht nur wirklich einen interaktiven Globus erstellen, den Sie mit der Maus drehen, Tag / Nacht wechseln und so weiter können. Auf dem Globus befinden sich Markierungen auf den Adressen, die abhängig von den Werten und Bereichen, in die diese Werte fallen, farblich gekennzeichnet sind (z. B. Farbcodierung). Nach der Anonymisierung der Datenbank in der Demoumgebung, zwei Stunden vor der Demo, blieben uns dank des Anonymisierungsskripts keine Postleitzahlen mit allen Konsequenzen.



Moral: Berühren Sie die Daten nicht zwei Stunden vor der Demo.

Geschichte Nummer zwei: "Über Anonymisierung"

Hintergrund: Daten werden aus einer Vielzahl von Quellen im Repository gesammelt, Daten gehören zu verschiedenen Domänen, sind jedoch durch Bezeichner miteinander verbunden.

Verlauf: Daten wurden in das Repository hochgeladen und anonymisiert, bevor sie für Testzwecke verwendet wurden. Es stellte sich heraus, dass die Daten nicht aus allen erforderlichen Quellen heruntergeladen wurden. Dann luden sie das fehlende Teil. Es war nicht möglich, den zweiten Teil der Daten (noch nicht anonymisiert) mit dem bereits anonymisierten ersten Teil zu verknüpfen. Infolgedessen wurde der Beginn der Arbeiten an der SIT-Umgebung um zwei Wochen verschoben, und die Bereitstellungs- und Supportteams haben die Daten korrigiert.

Moral: Bevor Sie anonymisieren, sollten Sie sicherstellen, dass die Datenbank alles enthält, was darin enthalten sein sollte, oder im Voraus über die Anwendbarkeit des Anonymisierungs- und Verschleierungsmechanismus nachdenken.

Elektronischer vs. Papier-Workflow in der Praxis

Derjenige, der mit HP ALM gearbeitet hat, lacht nicht über den Zirkus.

Die elektronische Dokumentenverwaltung vereinfacht die Kommunikation und den Überprüfungs- und Weitergabeprozess aus Sicht der manuellen Arbeit etwas, erschöpft jedoch im Kontext der Zeit für die Vorbereitung auf die Prüfung und deren Ausführung praktisch nicht die Zeit. Nachfolgend sind die Vor- und Nachteile des elektronischen Workflows im Vergleich zu Papier am Beispiel von HP ALM aufgeführt.

Vorteile:

• Es ist einfach, die neueste Version auf dem neuesten Stand zu halten.
• Weniger handgemacht.
• Alle Teammitglieder haben jederzeit Zugriff auf den aktuellen Stand eines bestimmten Tests.
• Ändern Sie die Geschichte.
• Passage Geschichte.
• Sie können die zum Abschließen des Tests benötigte Zeit verfolgen.
• Es ist einfacher, die Zeit für weitere Pässe zu planen.
• Wir müssen versuchen, die falsche Version des Tests für die Passage zu verwenden.
• Elektronische Unterschrift.

Nachteile (speziell für HP ALM):

• Es wird viel Zeit für die Formatierung von Tests aufgewendet.
• Regelmäßige Probleme mit dem Tool selbst.
• Fehlen einer normalen Rechtschreibprüfung.
• Unbequeme Schnittstelle.
• Der Zeitaufwand für das Schreiben und Überprüfen der Tests entspricht praktisch dem in Word.
• Kosten.

Fallstudie zu Papierkram und manuellen Signaturen: „The Nightmare Before Release“

Für einen Abend schrieb ich 450 Mal: ​​„Die Farbe der Punkte in der Grafik entspricht der in den Anforderungen angegebenen, der Nachname ist der Name des Datums.“ Und setzte eine Unterschrift ein - einfach, weil wir auf einem Schwarzweißdrucker druckten und die Farbe der Punkte in der Grafik von Bedeutung war.



Moral: Die Wahl der Mittel sollte im Einklang mit den Zielen stehen.

Geschichte Nummer zwei: "Schwerkraft ist gut, Schwere ist zuverlässig"

Papier-Workflow ist Papier (wer würde bezweifeln). Für den Empfang eines weitaus größten Antrags kann es sich im Bereich von fünf Kilogramm herausstellen.



Das Fazit, das sich aus den obigen (und vielen unsagbaren) Geschichten ergibt: Trotz der aufgeführten und nicht aufgeführten Nachteile der elektronischen Dokumentenverwaltung - wenn Sie wählen können, dann entscheiden Sie sich definitiv für die elektronische, auch wenn HP ALM (nicht mehr HP).

Automatisierung

Eine große Anzahl von Visualisierungen ermöglicht es nicht, Anwendungen stabil zu automatisieren. Daher haben wir uns im Rahmen des anfänglichen Ansatzes auf Unit-Tests (auch auf der Basisseite) und API-Tests beschränkt, ohne dass versucht wurde, auf E2E umzusteigen.

Wie und warum sind wir zu einer zumindest teilweisen Automatisierung gekommen?

Die erste Aufgabe bestand darin, uns zu erklären, dass wir in einigen Fällen wirklich Zeit gewinnen würden. Ja, das ist verständlich: Nicht jeder glaubt an Automatisierung und oft rechtfertigt sich deren Verwendung nicht - weil sie falsch verwendet wird, nicht dort und nicht dafür, aber dies ist ein Thema für einen separaten Bericht, von dem es etwas weniger gibt als "Automatisierung muss haben !!!" ", Aber immer noch in Menge.

Die zweite besteht darin, dem Kunden zu erklären, dass er Zeit gewinnen wird und dass dies aus formaler Sicht ausreichend zuverlässig und akzeptabel ist. Die Branche wird aus einem bestimmten Grund kontrolliert.

Drittens und hauptsächlich: um den Algorithmus zu bestimmen, mit dem wir bewusst eine Entscheidung über die Automatisierung des Testens einer bestimmten Anwendung oder eines Teils der Anwendung treffen und die Zustimmung zur Automatisierung einholen können. Dies ist wichtig, da im Lichte des oben beschriebenen Genehmigungsprozesses für die Dokumentation am Beispiel der manuellen Testsuite deutlich wird, dass der Automatisierungsprozess nicht weniger kontrolliert werden sollte.

Nachdem wir uns und dem Kunden die ersten beiden Punkte erklärt und begründet hatten, haben wir eine Teststrategie erstellt, die Geschäftsanalysten gebeten, zusätzliche Felder zu den Anforderungen hinzuzufügen, und eine Reihe von Fragen erstellt, die von den Antworten abhängen, auf die Sie ein Set für die Automatisierung einrichten können.

Die Liste der Fragen in unserem Fall:

1. Ist es möglich, das Testen in diesem speziellen Fall zu automatisieren?
2. Soll das Testen der Komponenten * automatisiert werden, um stabil zu sein?
3. Wie oft sollten wir Tests ausführen, die für eine Komponente geschrieben wurden?
4. Ist diese Funktionalität für das Geschäft von entscheidender Bedeutung? **
5. Wie schwierig ist es, Tests zu automatisieren?

* Stable = Komponente hat sich seit einiger Zeit nicht geändert und Änderungen an Komponenten sind für kommende Releases nicht geplant.
** Sie wird abhängig vom Wert des Feldes angebracht, das den Anforderungen des Geschäftsanalysten hinzugefügt wurde.


Im Allgemeinen sieht der Entscheidungsprozess wie folgt aus:

1. Der Eingang erhält die Anforderungen des FRS.
   Es wird eine Entwurfsmatrix erstellt, in der jede Zeile eine Anforderung von FRS ist. Als Spalten:
   
   • Anforderungsbeschreibung
   • Fragen 1-5
   • Teamentscheidung
   • Geschätzte Schreibzeit
   • Genehmigung
   • Kommentare
2. Das Team gibt Antworten auf Fragen und entscheidet anhand der erhaltenen Daten, ob es sich lohnt, das Testen einer bestimmten Anforderung / Anforderungsgruppe ganz oder teilweise zu automatisieren.
3. Der Kunde überprüft die vorgeschlagene Lösung und genehmigt die endgültige Version.
4. Nach Freigabe durch Design Matrix werden Autotests geschrieben. Skripte für Autotests werden auf Gherkin beschrieben und einer ähnlichen Überprüfung unterzogen wie manuelle Tests (globale Qualitätskontrolle, technischer Eigentümer, Geschäftsinhaber). Schrittdefinitionen, Seitenobjekte usw. werden im Anforderungspool überprüft, auch von einem technischen Spezialisten des Kunden. Autotest-Ergebnisse und generierte Berichte werden von Seiten der globalen Qualitätskontrolle erwartet.

In den zwei Jahren seit der Einführung haben wir auf die teilweise Automatisierung der Abnahmeprüfung von zwei Anwendungen für das Herunterladen, Konfigurieren und Anzeigen von Daten im Data Warehouse umgestellt, und in naher Zukunft planen wir, den kombinierten Ansatz, wenn möglich, für andere für den Kunden entwickelte Produkte weiter zu verwenden.

Fazit

Abschließend möchte ich festhalten, dass formale Abnahmetests nicht beängstigend oder nutzlos sind, wie es vielen scheint. Sie ermöglicht es, unter vollständiger Ausnutzung des Szenarioansatzes für das Testen das Testen zukünftiger Versionen zu vereinfachen, die erforderliche und ausreichende Qualität der Software zu bestätigen und den Kunden letztendlich zu beruhigen. Und was, wenn nicht die Gewissheit des Kunden, ist für die kundenspezifische Entwicklung wichtig?