V & V nicht für Vendetta

In den letzten sechs Jahren habe ich mich mit der Entwicklung und Abnahme von Anträgen zur Durchführung und Unterstützung klinischer Studien befasst. Anwendungen unterschiedlicher Größe und Komplexität, Big Data, eine Vielzahl von Visualisierungen und Ansichten, Data Warehousing, ETL usw. Die Produkte werden von Ärzten, dem Management klinischer Studien und Personen verwendet, die an der Kontrolle und Überwachung der Forschung beteiligt sind.

Für Anwendungen, die einen direkten Einfluss auf das Leben und die Gesundheit von Patienten haben oder haben 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 an die Produktion geschickt. In diesem Artikel werde ich kurz auf Akzeptanztests und die Verbesserung der dafür verwendeten Tools eingehen.

Hinweis: Ich gebe nicht vor, die ultimative Wahrheit zu sein, und verstehe vollkommen, dass das meiste, worüber ich schreibe, ein Monolog von Captain Obvious ist. Ich hoffe aber, dass das Beschriebene sowohl für den Einsteiger als auch für die Teams, die sich im Arbeitsalltag damit auseinandersetzen, nützlich sein kann oder zumindest diejenigen glücklich macht, die einfachere Abläufe haben.

FDA

Klinische Studien sind Experimente oder Beobachtungen, die in der klinischen Forschung durchgeführt wurden. Solche prospektiven biomedizinischen oder verhaltensbezogenen Forschungsstudien an menschlichen Teilnehmern sollen spezifische Fragen zu biomedizinischen oder verhaltensbezogenen Interventionen beantworten, einschließlich neuer Behandlungen (wie neuartiger Impfstoffe, Medikamente, Ernährungsoptionen, Nahrungsergänzungsmittel und Medizinprodukte) und bekannter Interventionen, die weitere Studien erfordern und Vergleich. Klinische Studien liefern Daten zur Sicherheit und Wirksamkeit. Wikipedia

Mit anderen Worten, damit die Kopfschmerzpille irgendwo in Brighton Beach in eine Apotheke gelangt, durchläuft sie drei Phasen menschlicher Versuche, in denen bestimmt wird, wie viel Wirkstoff in der Tablette enthalten sein soll, wie sicher sie ist und ob es überhaupt Kopfschmerzen heilt.

Was ist die FDA in Bezug auf das, was wir tun, und wie wirkt sich dies auf den Entwicklungsprozess und den Veröffentlichungszyklus aus?

Die Food and Drug Administration (FDA oder USFDA) ist eine Bundesbehörde des US-amerikanischen Gesundheitsministeriums, einer der US-amerikanischen Exekutivabteilungen. Die FDA ist verantwortlich für den Schutz und die Förderung der öffentlichen Gesundheit durch die Kontrolle und Überwachung der Lebensmittelsicherheit, von Tabakprodukten, Nahrungsergänzungsmitteln, verschreibungspflichtigen und rezeptfreien Arzneimitteln (Medikamenten), Impfstoffen, Biopharmazeutika, Bluttransfusionen, Medizinprodukten und elektromagnetischer Strahlung Emittierende Geräte (ERED), Kosmetika, Tierfutter und Tierarzneimittel. Wikipedia

Tatsächlich hat die FDA praktisch nichts mit dem Entwicklungsprozess selbst zu tun. Wir arbeiten nach dem üblichen SCRUM (um ehrlich zu sein, es ist nicht ganz SCRUM - sie sagen, dass es jetzt in Mode ist, einen solchen Prozess als „modifizierten SCRUM“ zu bezeichnen) mit einem nicht-modifizierten SCRUM. Sprint-Release-Zyklus. Wir liefern nicht an die Produktion am Ende jedes Sprints (und sogar am Ende von drei Sprints und sogar zehn, wenn die Zeitachse 15 Sprints umfasst), das heißt aus Sicht der Lieferung an den Endverbraucher Wir haben eine wasserfallähnliche Methodik.

In unserem Fall ist der Test in zwei unabhängige Teile mit unterschiedlichen Zeitplänen, unterschiedlichen Schätzungen und unterschiedlichen Prozessen unterteilt. 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 tatsächliche Abnahmeprüfung und Wartung der zugehörigen Aktivitäten (falls erforderlich). Der Prozess ist nach der V & V-Methodik aufgebaut: Benutzer- und Funktionsanforderungen an die Eingabe, Testskripte und ein Paket mit unterstützender Dokumentation an der Ausgabe.

Der Release-Zyklus hängt vom Projektumfang ab, Releases sind in der Regel nicht iterativ. Nach der Veröffentlichung kann die Anwendung für lange Zeit unverändert bleiben. Eine Unterbrechung zwischen den Veröffentlichungen kann von einigen Monaten bis zu einem Jahr oder mehr variieren.

V & V

Was ist V & V und wie wirkt sich dies auf den Akzeptanzprozess aus?

„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

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

Dies bedeutet, dass wir die Funktions- und Benutzerspezifikationen mit der notwendigen und ausreichenden Vollständigkeit prüfen müssen. Das erste V wird für uns zum Technical Acceptance Testing (SIT), das zweite zur Unterstützung von 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 umgekehrt 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 vertauscht). Falls der Bedarf nicht abgedeckt ist und nicht abgedeckt werden würde, begründen wir, warum wir ihn nicht abdecken.

Wann ist die Bedarfsdeckung nicht erforderlich?

Beispielsweise enthält CFR Part 11 ( FDA-Regeln für elektronische Aufzeichnungen und elektronische Signaturen ) eine Reihe von Anforderungen, die bereits von Microsoft abgedeckt wurden. Wenn wir also Windows AD zur Authentifizierung verwenden, müssen wir diese Anforderungen nicht erneut abdecken.

Letztendlich besteht das Wesen der Abnahmeprüfung darin, das Produkt auf Übereinstimmung mit den Anforderungen und den Anforderungen an die Übereinstimmung mit dem Produkt 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, Business-Produkt Inhaber, Scrum Master, Projektmanager, Business Analyst, technischer Leiter, SIT-Testleiter, UAT-Testleiter, globale Qualitätskontrolle, Support, Deployment Engineer und andere.

Die für uns spezifische Rolle - Globale Qualitätskontrolle . Dies ist die Person auf der Kundenseite, die dafür verantwortlich ist, die Anforderungen für den Prozess - Software Lifecycle und alle Arten von Standard Operational Procedures (SOP) auf der Kundenseite - während der Entwicklung und Abnahme einzuhalten und zu erfüllen. Außerdem stellt sie ein Paket von Dokumenten bereit für externe Prüfung.

Abnahmedokumentation

Im Rahmen der Produktfreigabe erstellen wir ein Dokumentationspaket, das eine Vielzahl von Verschachtelungsebenen enthält, einschließlich einer Dokumentation darüber, wie das Produkt getestet wurde, warum es auf diese Weise getestet wurde und nicht anders, was speziell im Testumfang enthalten war und was war nicht:

Validierungsplan und Teamliste - PM ist für die Erstellung und Genehmigung der Dokumente verantwortlich. Das Dokument enthält normalerweise die Systembeschreibung, eine Liste der Entwicklungs- und Testartefakte, eine Validierungsstrategie sowie eine Liste der Rollen und Verantwortlichkeiten.

Teststrategie - das Dokument, das nicht zu der spezifischen Anwendung gehört, sondern für den Produktzweig oder einen Testzweig vorhanden ist. Zum Beispiel, wie bestimmen wir, welcher Teil der Tests automatisiert werden soll, was wir für die Automatisierung planen, wie wir manuelle Tests durchführen wollen, ob wir Checklisten, Testskripte oder beides verwenden wollen sonst; Wie planen wir zu entscheiden, ob Leistungstests / Lasttests / Volumentests durchgeführt werden sollen oder nicht? und solche Sachen.

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, Testart oder anderen Merkmalen zusammengestellt sind.

Rückverfolgbarkeitsmatrix - eine Matrix mit Spuren von Anforderungen bis zu Tests. Die Nachverfolgung von Anforderungen als Nachweis der Deckung ist ein wichtiger Teil des Prozesses. Unter Verwendung der Kennung einer Anforderung können Sie einen bestimmten Schritt finden, in dem diese Anforderung getestet wird, und dem Prüfer (Screenshot, Datei usw.) Nachweise für eine bestimmte Version der Anwendung (oder für jede Version, in der diese Anforderung bestand) vorlegen formal abgedeckt). 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 von Ihnen nicht verlangt wird, da dies Ihr Leben in Zukunft vereinfachen würde. Wenn dies aufgrund der Verwendung verschiedener nicht integrierender Tools nicht möglich ist, können Sie jederzeit Kommentare in Aufgaben / Tests hinterlassen, eine Matrix (wie oben erwähnt in Excel) erstellen oder eine primitive Datenbank mit drei Tabellen erstellen.

PDS - Product Design Specification, Tech Lead oder System Architect ist für die Dokumentenerstellung verantwortlich. Tatsächlich handelt es sich um eine Art Kombination von Architekturdokumenten auf hoher und niedriger Ebene (HLA und LLA).

FRS & URS oder BRS - Funktions- und Benutzeranforderungen. Normalerweise gibt es zwei separate Dokumente, aber manchmal gibt es eine Business-Anforderungsspezifikation, die beide Spezifikationen enthält.

Fehlerprotokoll - Ein Protokoll der Fehler, die in der Anwendung und / oder den Anforderungen während der formellen SIT identifiziert wurden.

Minor Issues Log - Ein Protokoll der geringfügigen Änderungen an den Testskripten (Tippfehler, verbleibende oder überflüssige Anforderungen, Fehler).

Testzusammenfassungsbericht - Ein Bericht über die Ergebnisse der Testphase, der Folgendes umfasst:

• Informationen zu den für den Test verwendeten Builds (einschließlich Build-Nummern und Bereitstellungsdaten mit Informationen zu Gründen für die Bereitstellung), Anzahl der Testzyklen und Testergebnisse (bestanden / nicht bestanden).
• Eine Beschreibung der Diskrepanzen von SOPs.
• Die Liste der offenen Mängel mit Begründung.
• Der Link zum Fehlerprotokoll oder zum Fehlerprotokoll selbst.
• Der Link zum Protokoll kleinerer Probleme oder zum Protokoll selbst.
• Eine Empfehlung zur Bereitstellung in der Produktionsumgebung.

Bereitstellungsplan - Das Dokument, das für die Bereitstellung in der Produktion verwendet wird, enthält eine Beschreibung der Rollbacks.

Validierungszusammenfassungsbericht - das Abschlussdokument für den Validierungsplan.

Genehmigung der Dokumentation

Jeder Genehmigungsprozess für die Dokumentation kann in drei Phasen unterteilt werden:

• Dokumentvorbereitung.
• Rückblick
• Genehmigung

Schauen wir uns das Beispiel einer Testsuite an.

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

Absätze der Testsuite:

• Name des Projekts und der Anwendung.
• Release-Version.
• Name und eindeutige Kennung der Suite.
• Beschreibung (Was testen wir und welche Arten von Tests verwenden wir?)
• Testskripte.
• Liste der Genehmigenden.

Jeder Test besteht wiederum aus:

• Name und eindeutige Kennung des Testskripts.
• Beschreibung
• Voraussetzungen.
• Nachbedingungen.
• Rückverfolgbarkeit Referenzen.
• Anweisung zur Ausführung (z. B. Anweisung zum Maskieren sensibler Daten).
• Schritte (Verfahren, erwartete und beobachtete Ergebnisse).
• Testergebnis für das Skript.
• Tester.
• Gutachter

Der normale Lebenszyklus des Tests ähnelt einem Wasserfall und sieht folgendermaßen aus:

1. Schreiben
   Anforderungsanalyse. Definition und Anwendung von Testdesign-Techniken für die bestmögliche Abdeckung der Funktionalität. Schritte schreiben.
2. Trockenlauf auf Entwicklungsumgebung
   In dieser Phase versuchen wir herauszufinden, wie die Anwendung die Anforderungen erfüllt, und finden die meisten möglichen Fehler, einschließlich Anforderungsfehler.
3. Überprüfung der verantwortlichen Person (SIT-Teamleiter)
   Stilistische und logische Überprüfung.
4. Trockenlauf im Sitzen
   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 bereitgestellte Version stabil ist und die Version als Kandidat betrachtet werden kann.
5. Kundenbewertung (Global QC)
   Die globale Qualitätskontrolle überprüft, ob die Anforderungen erfüllt sind und ob die schriftlichen Tests den SOPs des Unternehmens entsprechen.
6. Genehmigung (globale QC, technische Bestellung, geschäftliche Bestellung).
7. Formale Testskriptausführung in einer SIT-Umgebung (Release Candidate Version)
   Nach der Genehmigung der Tests für die Ausführung (S. 6) und dem erfolgreichen Abschluss von Testläufen in der SIT-Umgebung (S. 4) wird der Test in der SIT-Umgebung mit der formellen Festlegung des Ergebnisses formell ausgeführt. Wenn die in den Testläufen gefundenen Fehler nicht formal sind und einfach in Jira eingegeben werden, ähnlich wie dies während des Entwicklungsprozesses geschieht, wird für jeden in der formalen Ausführung gefundenen Fehler ein separates Fehlerformular erstellt, das in der Ausgabedokumentation enthalten ist Paket für das Produkt.
8. Überprüfung der Skriptausführung (SIT-Teamleiter).
   Gleiches zu Punkt 3.
9. Kundenbewertung (Global QC)
   Die globale Qualitätskontrolle überprüft die Richtigkeit und Vollständigkeit der Angaben, eventuelle Fehler und das Vorhandensein von Beweisen (z. B. 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.

Mit personenbezogenen Daten arbeiten

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. 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 - Die Patienten werden nach dem Zufallsprinzip in zwei Gruppen eingeteilt, von denen eine das Studienmedikament und die zweite ein Placebo oder ein 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 (nicht zweimal zu betätigen), die wir für unsere Projekte bekommen haben:

Kann lustig sein (momentan nicht für uns): “The Globe”

In einer der Anwendungen mussten wir einen interaktiven Globus erstellen, den Sie mit der Maus drehen, Tag / Nacht wechseln und so weiter können, um nicht nur einen Wow-Effekt zu erzielen. Auf dem Globus befinden sich Markierungen auf den Adressen, die abhängig von den Werten und Bereichen, in die diese Werte fallen, farbig sind (eine Art 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.

Die Geschichte: Daten wurden in die Datenbank 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 verbinden. 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, und im Voraus über die Anwendbarkeit der Anonymisierungs- und Verschleierungsmechanismen nachdenken.

Elektronischer vs. Papier-Workflow in der Praxis

Der elektronische Workflow vereinfacht die Kommunikation und den Überprüfungs- und Weitergabeprozess aus Sicht der manuellen Arbeit ein wenig, bringt jedoch praktisch keinen Gewinn hinsichtlich der Zeit für die Vorbereitung auf die Prüfung und deren Ausführung. Nachfolgend sind die Vor- und Nachteile des elektronischen Workflows im Vergleich zu Papier am Beispiel von HP ALM aufgeführt.

Vorteile:

• Einfach zu unterstützen.
• Weniger Handarbeit.
• Alle Teammitglieder haben jederzeit Zugriff auf den aktuellen Stand eines bestimmten Tests
• Änderungshistorie.
• Hinrichtungsgeschichte.
• Sie können die zum Abschließen des Tests benötigte Zeit verfolgen.
• Einfach zu planende zukünftige Läufe.
• Es ist schwer, eine falsche Version des Testskripts zu verwenden.
• Elektronische Unterschrift.

Nachteile (speziell für HP ALM):

• Viel Zeit für die Formatierung der Skripte.
• Regelmäßige Probleme mit dem Tool selbst.
• Nicht die beste Rechtschreibprüfung.
• Unbequeme Schnittstelle.
• Der Zeitaufwand für das Schreiben und Überprüfen der Tests entspricht praktisch dem in Word.
• Kosten.

Eine wahre Geschichte im Zusammenhang mit Papierkram und manuellen Signaturen: „Ein Albtraum vor der Veröffentlichung“

Eines Abends schrieb ich 450 Mal: ​​„Die Farbe der Punkte in der Grafik entspricht der in den Anforderungen angegebenen. Name, Vorname, Datum “und Unterschrift - einfach, weil wir auf einem Schwarz / Weiß-Drucker gedruckt haben und die Farbe der Punkte in den Diagrammen eine Rolle spielte.



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

Eine andere Geschichte: „Schwer ist gut, schwer ist zuverlässig.“ ©

Bei Papier-Workflows geht es um Papier (wer würde das bezweifeln). Die Akzeptanztestphase für eine weit von der größten Anwendung entfernte Phase kann etwa fünf Kilogramm Papier betragen.



Das Fazit, das sich aus den obigen (und vielen unsagbaren) Geschichten ergibt: Trotz der aufgeführten und nicht aufgeführten Nachteile des elektronischen Workflows - wenn Sie sich entscheiden 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 Komponententests (einschließlich datenbankseitiger Tests) und API-Tests beschränkt, ohne zu versuchen, 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 eine gesonderte Diskussion, von der dort die Rede ist sind ein bisschen weniger als "Automatisierung muss haben !!!", aber immer noch viel.

Zweitens muss dem Kunden erklärt werden, dass er Zeit gewinnen wird und dass dies aus formaler Sicht ausreichend zuverlässig und akzeptabel ist. Die Branche wird kontrolliert und es gibt Gründe dafür.

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 klar ist, dass der Automatisierungsprozess nicht weniger kontrolliert werden sollte als der beschriebene Prozess für die manuellen Testskripte.

Nachdem wir uns und dem Kunden die ersten beiden Punkte erklärt und begründet hatten, schrieben wir eine Teststrategie, baten die Geschäftsanalysten, den Anforderungen zusätzliche Felder hinzuzufügen, und stellten eine Reihe von Fragen, je nachdem, auf welche Fragen wir eine Reihe bilden können für die Automatisierung.

Die Liste der Fragen in unserem Fall:

1. Ist es möglich, das Testen in diesem speziellen Fall zu automatisieren?
2. Ist es eine stabile * Komponente?
3. Wie oft müssen wir Testskripte für diese Komponente ausführen?
4. Ist es eine geschäftskritische Funktion? **
5. Wie schwer ist es, das Testen zu automatisieren?

* Stabil = Die Komponente hat sich seit einiger Zeit nicht geändert, und Änderungen an Komponenten sind für die nächsten Releases nicht geplant.
** Sie wird abhängig vom Wert des Feldes ausgefüllt, das der Business Analyst den Anforderungen hinzugefügt hat.


Im Allgemeinen ist der Entscheidungsprozess wie folgt:

1. Am Eingang haben wir Anforderungen von FRS.
   Wir erstellen eine Entwurfsmatrix, in der jede Zeile die FRS-Anforderung und die Spalten die folgenden sind:
   
   • Anforderungsbeschreibung
   • Fragen 1-5
   • Teamentscheidung
   • Ungefähre Schätzung
   • 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 der Design Matrix werden Autotests geschrieben. Skripte für Autotests sind in der Gherkin-Notation geschrieben und werden einer ähnlichen Überprüfung unterzogen wie manuelle Tests (globale Qualitätskontrolle, technischer Eigentümer, Geschäftsinhaber). Schrittdefinitionen, Seitenobjekte usw. werden in Bezug auf die Pull-Anforderungen überprüft, auch von einem technischen Spezialisten des Kunden. Autotest-Ergebnisse und generierte Berichte werden auf der Seite der globalen Qualitätskontrolle überprüft und genehmigt.

Innerhalb von zwei Jahren ab dem Moment der Implementierung haben wir zwei Anwendungen, die mit dem Herunterladen, Konfigurieren und Anzeigen von Daten im Data Warehouse zu tun haben, auf die teilweise Automatisierung des Abnahmetests umgestellt Produkte, die nach Möglichkeit für den Kunden entwickelt wurden.

Fazit

Abschließend möchte ich darauf hinweisen, dass die formale Abnahme nicht beängstigend oder nutzlos ist, wie es vielen Branchenvertretern erscheint. Sie ermöglicht es, unter vollständiger Ausnutzung des Szenario-Testansatzes 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 ist bei der Outsourcing-Entwicklung wichtig, wenn nicht die Gewissheit des Kunden?