Testen in großen Unternehmen, in Unternehmen, ist oft eine komplizierte und undankbare Aufgabe. Die Kluft zwischen Geschäftsbereichen und IT ist groß: Wenn ein Entwickler eine Vision auf Codeebene hat und die Verifizierung auf der Ebene von Komponententests erfolgt und der Kunde denkt, dass er arbeitet oder nicht, auch nicht mit Services, sondern mit ganzen Prozessen, die über ein Entwicklungsteam oder sogar das Ganze hinausgehen Abteilungen \ Unternehmen. Und er bittet darum, Geschäftstests oder End-to-End-Tests oder Tests basierend auf Szenarien von Anfang bis Ende (Ende 2 Ende) zu organisieren.
Beginnen wir von vorne - von den beiden Säulen, aus denen diese berüchtigten „End-to-End-Geschäftstests“ stammen, nämlich von der Testpyramide und dem ISO9000-Standard.
Pyramide testen
Die Testpyramide ist wahrscheinlich jedem Tester bekannt, der seinen Beruf beherrscht und bei der Kommunikation mit verwandten Einheiten Unebenheiten angesammelt hat. Besonders oft ist es notwendig, sich bei der Begründung der Testautomatisierung darauf zu berufen. Welche Tests sind billiger und wichtiger zu entwickeln? Und rennen?
Das Wesentliche der Testpyramide ist nicht schwierig: Das Testen sollte auf den einfachsten und schnellsten Tests beim Schreiben und Ausführen basieren - Unit-Tests. Natürlich ist es für den Kunden kaum möglich, die Schnittstellen von Klassen und Funktionen zu überprüfen, aber ohne diese starke, monolithische und störungsfreie Grundlage ist es kaum möglich, etwas Höheres zu bauen. In der Regel implementieren mehrere Dutzend Funktionen, Methoden und Klassen eine Art von Funktionalität für den Kunden, und tatsächlich können ein Dutzend Komponententests auf einige Tests der obersten Ebene reduziert werden. Der Kunde braucht bereits eine schöne Wohnung mit Dekoration, aber es ist unwahrscheinlich, dass er zufrieden ist, wenn sich die schrägen Fenster in seiner Wohnung nicht mehr öffnen und der Boden und die Decke durch die erste Brise Risse bekommen. Es ist jedoch möglicherweise nicht die beste Idee, wenn der Kunde selbst in die Wohnung geht und deren Qualität überprüft. Stimmen Sie zu, es ist für den Benutzer schwierig, die Qualität des Betons im Fundament zu überprüfen und alle Wetterbedingungen zu reproduzieren. Beim Testen sind natürlich Tests auf höchster Ebene erforderlich, und zwar nur dann, wenn wir Unit-Tests ausgearbeitet haben, ebenso wie Tests auf höherer Ebene.
Es ist schwieriger, Tests auf höherer Ebene zu entwickeln und länger durchzuführen - Integrationstests, die den korrekten Betrieb gleichzeitig arbeitender Module überprüfen, an denen das gesamte Team gearbeitet hat, und deren Produkt (System) freigeben. Das heißt, die Integration des Codes wird überprüft, das System wird getestet, ohne die Interaktion mit externen Systemen zu berücksichtigen. Solche Tests implizieren bereits eine Überprüfung auf hoher Ebene, höchstwahrscheinlich durch einen Aufruf des Systems über die System-API oder sogar eine GUI (Front). Die Arbeit mit dieser Art von Test ist schwieriger - um alle Zweige und Nuancen des Codes abzudecken, müssen Sie höchstwahrscheinlich eine große Anzahl stark überlappender Überprüfungen verschiedener Testdaten durchführen und während der Automatisierung häufig eine ganze Reihe von Bedingungen und Zweigen in Skripten entwickeln. Das heißt, einerseits haben wir uns bereits an den Benutzer gewandt, was das Leben schwierig macht, andererseits ist es für uns immer noch schwierig, eine gemeinsame Sprache zu finden, es kostet uns mehr und die Qualität der Überprüfungen reicht immer noch nicht aus. Das heißt, wir können den Kunden in eine neue Wohnung einführen, er kann alles überprüfen, ohne jedoch die Interaktion mit anderen Bewohnern, Wetterbedingungen und Versorgungsunternehmen zu berücksichtigen. Stimmen Sie zu, der Sinn einer idealen Welt, eines Modells, im wirklichen Leben ist in der Regel nicht viel.
Wenn wir diese Bedingungen hinzufügen, werden wir sehen, wie unser System mit externen Systemen interagiert - Lieferanten und Verbraucher, mit unserer Umgebung, dh wir führen Systemtests durch, dann können wir leicht erkennen, dass die Komplexität der Tests ebenfalls zunehmen wird. Wir müssen die gleichzeitige Funktionsfähigkeit aller interagierenden Systeme erreichen, allerdings ohne die Einbeziehung von Spezialisten. Im Moment reicht es aus, nur einige Daten von unseren Lieferanten zu akzeptieren und unsere Daten an unsere Verbraucher zu übertragen. In der richtigen Reihenfolge und im richtigen Format. Das weitere Schicksal der Daten stört uns nicht. Hauptsache, unser System funktioniert in der richtigen Umgebung einwandfrei. Und hier wäre alles in Ordnung - für unseren Kunden können wir bereits eine umfassende Demonstration durchführen, aber nur im wirklichen Leben sind nicht alle Erfolgskriterien für unsere Entwicklung. Natürlich ist es gut, dass der Kunde seine Wohnung in einem soliden Haus hat, aber wenn Sie davon kommen müssen, über den Stacheldraht klettern und dann mit Krokodilen in schlangenreichen Hütten den See entlang fahren, dann haben wir vielleicht nicht Recht war da?
Daher besteht die erste Idee für End-to-End-Tests darin, nicht nur unsere Umgebung zu überprüfen, sondern auch alle miteinander verbundenen Systeme, über die von unserem System empfangene oder gesendete Daten übertragen werden. Und dies bedeutet wiederum, dass wir mehrere dieser "Testpyramiden" miteinander kombinieren müssen. Der Bau einer fragilen Brücke, über die wir die für den Benutzer wertvollen Daten am Griff halten.
Die Frage ist nur, wie das geht. Wer sollte das tun? Wie zusammenstellen?
ISO9000
Eine Reihe von Standards, die das Qualitätsmanagementsystem beschreiben, einschließlich der Tatsache, dass jeder Prozess in der Organisation beschrieben und dokumentiert werden sollte, selbst wenn es sich um die Ausgabe eines Rechen im Herbst an den Hausmeister handelt. Und wenn ja, kann kein einziger Prozess beschrieben werden, der innerhalb der in der Organisation verwendeten und entwickelten Software stattfindet. Die Frage ist, wie das geht? Die beste Beschreibung aus Sicht von BDD ist natürlich die Beschreibung des Verhaltens durch Tests, unter denen die Testpyramide liegen wird. Wir werden jedoch sofort zu unserem Dilemma zurückkehren, indem wir mehrere Pyramiden mit dünnen Seilen von oben nach oben kombinieren, entlang derer unser Seiltänzer und seine Benutzer ohne Versicherung gehen.
Der Prozessansatz ist eine Managementstrategie, bei der Unternehmen ihre Prozesse und die Interaktionen zwischen ihnen verwalten müssen. Daher müssen Sie jeden wichtigen Prozess des Unternehmens und seine unterstützenden Prozesse berücksichtigen.
Daher ist es am einfachsten, Abstraktionen zu verwenden - erstellen Sie mindestens ein Prozessdiagramm und geben Sie dessen Ein- und Ausgänge an, machen Sie den Prozess kontrolliert und messbar und stellen Sie die Verbindung mit übergeordneten und untergeordneten Prozessen gemäß ISO9000 sicher
Alle Prozesse haben:
• Eingänge;
• Ausgänge;
• Betriebskontrolle;
• angemessene Messung und Überwachung.
Jeder Prozess verfügt über Unterstützungsprozesse, die die Realisierung des Prozesses unterstützen und ermöglichen
Geschäftsdiagramme eignen sich am besten für diesen Zweck, und am häufigsten werden Standards wie UML, BPMN, ARIS usw. verwendet. Die Prozesse selbst werden zu Flussdiagrammen mit darauf angeordneten "Cubes". Es gibt eine Interaktion zwischen den „Cubes“. Im BPMN-Standard handelt es sich um einen Aktionsfluss und einen Nachrichtenfluss. Und genau das brauchen wir!
Jedes Unternehmen, das ein Zertifikat haben möchte und dem ISO9000-Standard folgt, hat höchstwahrscheinlich solche Systeme erworben und sie sind ein wesentlicher Bestandteil der Anforderungen auf höchster Ebene. Wenn das Unternehmen über gute Analysten verfügt, werden die Verknüpfungen zu den Anforderungen für einzelne Maßnahmen aus den Programmen höchstwahrscheinlich auf die Anforderungen auf niedriger Ebene zurückgeführt. Wir brauchen sie.
Tatsächlich können wir in den Diagrammen den gesamten Prozess sehen und verstehen, welches Szenario wir erstellen müssen und welches System / Team mit welchen Daten zu welchem Zeitpunkt ausgeführt werden soll.
Ich unterschätze nicht die Arbeit von Entwicklern, die kompetenten Code schreiben, der Nachrichten zwischen verschiedenen Teilen von Software- und Hardwaresystemen sendet, aber es ist unmöglich, alles im Auge zu behalten. Und wenn der Prozess in vielen anderen Prozessen verwendet wird, ist es besser, eine solche „Karte“ bei sich zu haben, um kompetente Tests durchzuführen, und noch mehr, um ein Testmodell zu erstellen.
Was in der Praxis
Wir haben also zwei einführende - jedes Team \ System sollte eine Pyramide von Tests vorbereitet haben - von den kleinsten Komponententests über komplexe Systemtests bis hin zur Tatsache, dass wir innerhalb der Organisation die Anforderungen in Form eines Geschäfts beschreiben müssen -Prozesse. Diese Tatsache ermöglicht es uns, dem Kunden schnell zu antworten, welcher Geschäftsprozess funktioniert und zu welchem Zeitpunkt er abbricht, und wir selbst führen, wenn wir Fehler aus dem industriellen Betrieb erhalten, schnell eine Ursachenanalyse durch (Analyse der Ursachen von Fehlern). In der Theorie.
In der Praxis liegt jedoch wieder alles beim Tester - wie kann man aus einem Stapel von Tests, insbesondere ausländischen, die richtigen auswählen, sie in einer Kette zusammenstellen und die Eingabe jedes Systems durchführen, um die erforderlichen Daten zu übermitteln und mit dem korrekt ermittelten erwarteten Ergebnis zu vergleichen?
Am einfachsten ist es, zunächst Tests zu entwickeln, die auf Geschäftsmodellen basieren, und Teams in Projekte zu unterteilen, die einen bestimmten Geschäftsprozess implementieren. Zu diesem Zweck ist es in einigen Testverwaltungstools bereits möglich, BPMN-Schemata zu laden (z. B. für HPE ALM - das Laden im XPDL-Format wird unterstützt). HP ALM selbst unterteilt das Schema in eine Reihe von Anforderungen (Aktionen) und erstellt bei Bedarf eine Hierarchie von Anforderungen (Modul Anforderungen-> Geschäftsmodelle). Als nächstes ist es unsere Aufgabe, die Anforderungen mit Tests abzudecken und dann die Anforderungen und damit die Tests in Ketten zu erstellen, die unseren Geschäftsprozess abdecken. Diese Ketten in HPE ALM werden als "Pfade" bezeichnet und ermöglichen es Ihnen, alle Kombinationen von Sequenzen anzuzeigen. Auf Wunsch können die Ketten sofort in Tests umgewandelt werden.
Aber selbst wenn Sie keine Testtools verwenden, müssen Sie dennoch Ketten aus dem Geschäftsprozess erstellen. Insbesondere angesichts der Unvollkommenheit der Werkzeuge (nicht alles ist so rosig) sowie der Tatsache, dass das Testmodell höchstwahrscheinlich post-factum zusammengestellt und in Form einer Regression von einem „gemeinsamen Team“ ausgeführt werden muss, das nicht an neuen Projekten festhält.
Wie viele Wege kann ein Eichhörnchen eine Beule erreichen?In diesem Fall müssen wir die Tests jedes Teams öffnen, diejenigen finden, die mit den Anforderungen im Geschäftsmodell verknüpft sind, und daraus Ketten erstellen, um sie in einem „gemeinsamen Raum“ zu speichern. Das Erstellen eines gemeinsamen Raums ist eine Art Ersatz, sollte es aber auf jeden Fall sein, selbst in Form eines Scheunenbuchs, eines Excel oder eines Projektbereichs in einem Testmanagement-Tool. Wenn wir noch einmal über HPE ALM sprechen, ist das BPT-Modul (Business Process Testing) für diese Funktionalität verantwortlich, mit der Sie gleichzeitig die Ergebnisse eines Tests auf die Parameter eines anderen übertragen können. Wenn Sie jedoch HPE ALM wünschen und hart daran arbeiten möchten, können Sie dies implementieren, indem Sie die Testsätze (Testsatz) im Ausführungsfluss (Ausführungsfluss) neu erstellen. Wenn Sie dann den vollständigen Satz starten, werden nacheinander die Tester aufgerufen, die für das Übergeben der einzelnen Komponenten des End-to-End-Skripts verantwortlich sind.
Und leider reicht es nicht aus, nur zu testen. Aus meiner Praxis weisen fast alle Tools einige schwerwiegende Mängel auf. Wenn Sie also die Phase der Testautomatisierung in einem Geschäftsprozess erreichen, werden Sie ein Skript erstellen, mit dem Tests in der richtigen Reihenfolge ausgeführt werden.
Infolgedessen können zwei Schlussfolgerungen gezogen werden:
1) Für End-to-End-Szenarien ist es sehr wahrscheinlich, dass zuvor entwickelte Tests für jedes der in der Geschäftsprozesskette enthaltenen Systeme verwendet werden (Szenario).
Es ist möglich, alle vollständigen Testsuiten eines Unternehmens in Form einer spärlichen Matrix darzustellen, in der die Tests für jedes System in Spalten (der Einfachheit halber - Systemtests) und Geschäftsprozesse in Zeilen verteilt sind. Das heißt, für bestimmte Geschäftsprozesse müssen Sie Tests auswählen, die den Geschäftsprozess abdecken, und Beziehungen herstellen. Wenn keine Abdeckung vorhanden ist, ist dies eine Gelegenheit, die Lücken im Testmodell zu schließen oder sicherzustellen, dass die Qualität durch andere Testebenen (Integrationstests, Komponententests, Codeüberprüfung und Ausführen durch Analysegeräte) sichergestellt wird.
2) Zum Überwachen, Verfolgen und Aktualisieren des Geschäftsprozesses für die Synchronisation mit dem Testmodell wird ein Tool benötigt.
Und wenn Testtools mehr oder weniger erträglich mit der Erstellung eines Testmodells fertig werden, ist beim Aktualisieren alles sehr schlecht. Es ist oft einfacher, das Modell erneut zu erstellen, als zu versuchen, Änderungen im Prozess und im Testmodell zu erkennen. Die Erfahrung realer Teams legt nahe, dass es besser ist, eine Live-Visualisierung der Architektur zu erstellen. Der einfachste Weg, dies zu tun, ist im Gemeinschaftsbereich mit einer einfachen Markierungstafel und Aufklebern. Dann können Teams, die am Geschäftsprozess teilnehmen, deutlich sehen, wie der Prozess geändert wird (Verbindungen werden entfernt und hinzugefügt, Aktionen werden entfernt und hinzugefügt). Die Hauptsache ist, dass jeder Zugang zum Board hat. Beachten Sie außerdem, dass, wenn der Prozess Nachrichten zwischen Systemen umfasst, in der Regel mindestens zwei Tests von jedem System durchgeführt werden müssen - zum Senden und Empfangen von Daten. Anstelle von Aufklebern können Sie jedoch eine ganze Lego-Stadt (aus großen Blöcken) oder etwas noch Kreativeres verwenden. Die Hauptsache hier ist eine Sprache und ein Informationsraum, was im Unternehmen sehr fehlt.
Abschließend
Das Organisieren visueller und ordnungsgemäßer Tests von Geschäftsprozessen ist eine komplexe und sehr teure Sache. Bitte beachten Sie, dass E2E-Tests nicht nur Akzeptanz sind, sondern Benutzertests, die der Kunde durchführen wird, sondern eine Brücke bauen, wobei alle möglichen Situationen berücksichtigt werden, denen der Kunde folgen und die Benutzer in den Fuß führen wird.
Noch einmal - E2E - dies ist kein Spaziergang auf Lada Kalina über die Brücke und nicht einmal zwei Kamaz-Durchgänge. Dies ist eine komplizierte technische Arbeit, bei der Brücken mit Sensoren abgewogen und alle möglichen Überprüfungen und Situationen durchgeführt werden - zumindest eine Beschreibung dieser Szenarien.
Ob Ihr Unternehmen einen so idealen Finishing-Lauf benötigt oder nicht, hängt ausschließlich von Ihren Zielen und Anforderungen ab. Wie bei jedem Test sollten Sie immer die potenziellen Risiken fehlender Fehler in dieser Phase sowie die Kosten für die Vorbereitung und Durchführung von End-to-End-Tests bewerten. Um zu bewerten, was Sie mehr davon kostet und erst dann zu handeln. Bei End-to-End-Tests von Geschäftsprozessen ist jedoch zu beachten, dass dies ohne eine solide Grundlage in Form von Einheitentests mit 100% Passrate (~ 90-100% Abdeckung) und ohne Integrationstests (~ 60-80% Abdeckung, 90-) keinen Sinn ergibt. 100% Passrate), ohne Systemtests (20-40% Abdeckung, 80-100% Passrate). Die Festlegung von Erfolgskriterien (Quality Gates) ist mehr als eine Voraussetzung für die Qualität des Produkts. Hierbei ist vor allem zu beachten, dass das Volumen der E2E-Tests nur die Spitze der Pyramide ist (1-2% Abdeckung, ~ 99% Passrate), die nicht größer als die Basis sein sollte Gleichzeitig ist ein Lochstopfen aus den vorherigen Schritten. Dies ist eine Ergänzung, die a priori in den vorherigen Phasen als geschlossen betrachtet wurde.
Die Organisation solcher Tests besteht hauptsächlich in der Vorbereitung und Synchronisierung von Testfällen und Daten (Testanalysen) sowie in einer Reihe von organisatorischen Maßnahmen, mit denen Teams gleichzeitig an einem Ort an einem funktionsfähigen Teststandort synchronisiert werden. Vor diesem Hintergrund sollte man nicht versuchen, dem Kunden „End-to-End-Tests“ im Voraus zu zeigen, um nicht sofort eine große Anzahl von Personen zu verschwenden, ohne dass alle Arbeitskomponenten zusammengebaut sind.
PS beschrieb sowohl Tools als auch Praktiken - zum Beispiel hat sich der Autor nicht das Ziel gesetzt, Produkte zu bewerben und diesen Ansatz für End-to-End-Tests als den einzig wahren Weg zu erklären.