Mein Name ist Maria Snopok, ich bin die Leiterin der Automatisierungsabteilung in der Testabteilung der Entwicklungs- und Supportabteilung für Big Data-Produkte der X5 Retail Group. In diesem Artikel werde ich unsere Erfahrungen mit der Implementierung von Autotests und der Reduzierung der damit verbundenen Kosten teilen. Hoffentlich sind diese Informationen hilfreich für Teams, die Schwierigkeiten haben, auf automatisierte Tests umzusteigen.
Wie wir zu Autotests kamen
Vor dem Aufkommen der Automatisierung arbeitete ich als Testmanager in einem unserer Produkte. Als dort ein ziemlich großes Testmodell gebildet wurde, haben wir begonnen, den Pool der Regressionstests an das gesamte Entwicklungsteam zu verteilen. Wenn sie für die Veröffentlichung verantwortlich ist, testet sie auch. Eine solche Teamregression löste die folgenden Aufgaben:
- Entwickler, die sich zuvor mit ihren separaten Funktionen befasst hatten, konnten das gesamte Produkt sehen.
- Wir haben die Regression schneller gemacht und aus diesem Grund häufiger veröffentlicht.
- Wir haben den Rückgriff nicht mehr reduziert - die Qualität hat sich verbessert.
Aber es war teuer, weil die Tests von teuren Spezialisten - Entwicklern und Analysten - durchgeführt wurden und wir begannen, uns der Automatisierung zuzuwenden.
Rauchtests standen an erster Stelle - einfache Überprüfungen, um sicherzustellen, dass Seiten geöffnet, geladen, nicht abgestürzt und alle grundlegenden Funktionen verfügbar sind (bisher ohne Überprüfung der Logik und der Werte).
Wir haben dann positive End-to-End-Skripte automatisiert. Dieser Schritt brachte den maximalen Nutzen: Durch Tests konnte sichergestellt werden, dass die Hauptgeschäftsprozesse des Produkts funktionieren, auch wenn in negativen, alternativen und sekundären Szenarien Fehler aufgetreten sind.
Und schließlich kamen wir zur Automatisierung fortgeschrittener Regressionsprüfungen und alternativer Szenarien.
In jeder dieser Phasen waren wir mit einer Reihe von Schwierigkeiten konfrontiert, die den gesamten Prozess erheblich verlangsamten und komplizierten. Welche praktischen Lösungen haben uns geholfen, die Arbeit von Automaten zu beschleunigen und zu erleichtern?
Vier Möglichkeiten zur Kostensenkung bei Autotests
1. Vereinbaren Sie die Formate der Testattribute am Ufer
Entwickler und automatisierte Tester müssen sich im Voraus auf die Regeln für die Benennung von HTML-Elementen für ihre spätere Verwendung als Locators in Autotests einigen. Es ist wünschenswert, für alle Produkte das gleiche Format zu haben. Wir haben Anforderungen entwickelt, um zu verstehen, wie Attribute benannt werden, noch bevor das Feature in die Entwicklung übertragen wird. Dieses Verständnis besteht sowohl auf der Seite der Entwickler als auch auf der Seite der Tester. Wir waren uns einig, dass jedem sichtbaren HTML-Element ein benutzerdefiniertes data-qa-Attribut zugewiesen wird, mit dem der Tester danach sucht. Das Attribut wird nach folgendem Muster benannt:
[Bildschirmname] [Formular- / Tabellen- / Widgetname] [Elementname]
Beispiel:
data-qa = "plu-list_filter-popover_search-input"
data-qa = "common_toolbar_prev-state"
Es ist einfach, ein solches Attribut einfach aus der Dokumentation und dem Layout zu isolieren, und jeder weiß, was es bedeuten sollte. Wenn ein Entwickler eine Aufgabe zur Arbeit übernimmt, weist er nach diesen Regeln allen sichtbaren Elementen der Seite Daten-Qa-Attribute zu - Kopfzeilen, Schaltflächen, Links, Selektoren, Zeilen und Spalten von Tabellen usw. Als Ergebnis kann der Tester selbst bei der Entwicklung eines Features basierend auf dem Schreiben von Autotests beginnen nur zum Layout und zur Dokumentation, da es bereits weiß, wie die Attribute benannt werden.
Durch die Einführung von Testattributen konnten wir die Kosten für die Entwicklung und Unterstützung von Autotests im Vergleich zur Vorperiode um durchschnittlich 23% senken, indem wir die Kosten für die Aktualisierung von Tests und die Lokalisierung von Elementen für Autotests senkten.
2. Wir schreiben manuelle Tests, damit sie leicht zu automatisieren sind
Manuelle Tester und Automatisierungsingenieure leben in verschiedenen Universen. Manuelle zielen darauf ab, mehrere verschiedene Testobjekte in der Nähe mit einem Skript zu überprüfen. Auf der anderen Seite neigen Automaten dazu, alles zu strukturieren und nur Objekte desselben Typs in einem einzigen Test zu überprüfen. Aus diesem Grund sind manuelle Tests nicht immer einfach zu automatisieren. Als wir manuelle Fälle für die Automatisierung erhielten, hatten wir eine Reihe von Problemen, die es uns nicht ermöglichten, die resultierenden Skripte Wort für Wort zu automatisieren, da sie für eine einfache Ausführung durch eine lebende Person geschrieben wurden.
Wenn ein Automat tief in das Produkt eingetaucht ist, benötigt er keine "manuellen" Fälle, er kann sich selbst ein Skript für die Automatisierung schreiben. Wenn er "von außen" zum Produkt kommt (in unserer Abteilung bieten Teams neben Testern auch Tests als dedizierten Service an) und bereits ein Testmodell und Skripte von manuellen Testern erstellt wurden, könnten Sie versucht sein, ihn anzuweisen, Autotests zu schreiben die Grundlage dieser "manuellen" Testfälle.
Geben Sie dem nicht nach: Das Maximum, für das ein Automator manuelle Testfälle verwenden kann, besteht darin, zu verstehen, wie das System aus Sicht des Benutzers funktioniert.
Dementsprechend ist es notwendig, zunächst manuelle Tests vorzubereiten, damit sie automatisiert werden können , und um damit häufige Probleme zu lösen.
Problem 1: Vereinfachung manueller Fälle.
Lösung: Detaillierung der Fälle.
Stellen wir uns eine Beschreibung eines manuellen Falls vor:
- Öffnen Sie die Seite mit der Liste der Revisionsversionen
- Klicken Sie auf die Schaltfläche Erstellen
- Fülle das Formular aus
- Klicken Sie auf die Schaltfläche "Erstellen"
- Stellen Sie sicher, dass die Revisionsversion erstellt wurde
Dies ist ein schlechtes Szenario für die Automatisierung, da nicht angegeben wird, was genau geöffnet werden muss, welche Daten ausgefüllt werden müssen , was genau wir erwarten und in welchen Feldern sie angezeigt werden sollen. Die Anweisung "Sicherstellen, dass die Version erfolgreich erstellt wurde" reicht für die Automatisierung nicht aus - die Maschine benötigt bestimmte Kriterien, anhand derer sie vom Erfolg der Aktion überzeugt werden kann.
Problem 2: Fallverzweigung.
Lösung: Der Fall sollte nur ein lineares Szenario haben.
Konstruktionen mit "oder" erscheinen häufig in Handkoffern. Zum Beispiel: "Open Revision 184 unter Benutzer 1 oder 2". Dies ist für die Automatisierung nicht akzeptabel, der Benutzer muss klar angegeben werden. Konjunktionen "oder" sollten vermieden werden.
Problem 3: Fall irrelevant.
Lösung: Überprüfen Sie die Fälle, bevor Sie sie an die Automatisierung senden.
Für uns ist dies der größte Schmerz: Wenn sich die Funktionalität häufig ändert, haben Tester keine Zeit, Testfälle zu aktualisieren. Wenn ein manueller Tester jedoch auf einen irrelevanten Fall stößt, wird es für ihn nicht schwierig sein, das Skript schnell zu korrigieren. Ein Automat, insbesondere wenn er nicht in das Produkt eingetaucht ist, kann dies nicht: Er wird einfach nicht verstehen, warum der Fall nicht gut funktioniert, und wird ihn als Testfehler wahrnehmen. Wird viel Zeit für die Entwicklung aufwenden, danach stellt sich heraus, dass die getestete Funktionalität schon lange nicht mehr funktioniert und das Skript irrelevant ist. Daher sollten alle Skripte für die Automatisierung auf Relevanz überprüft werden.
Problem 4: nicht genügend Voraussetzungen.
Entscheidung:vollständiger Stapel von Hilfsdaten für die Fallausführung.
Manuelle Tester neigen dazu, ihre Augen zu verwischen, und als Ergebnis übersehen sie bei der Beschreibung der Voraussetzungen einige Nuancen, die für sie offensichtlich sind, für Automatiker, die mit dem Produkt nicht so vertraut sind, jedoch nicht offensichtlich sind. Zum Beispiel schreiben sie: "Öffnen Sie eine Seite mit berechnetem Inhalt." Sie wissen, dass Sie zur Berechnung dieses Inhalts ein Berechnungsskript ausführen müssen, und der Automat, der das Projekt zum ersten Mal sieht, entscheidet, dass etwas bereits Berechnetes verwendet werden muss.
Schlussfolgerung: Unter den Voraussetzungen muss eine vollständige Liste der Aktionen erstellt werden, die vor Beginn des Tests ausgeführt werden müssen.
Problem 5: Mehrere Prüfungen in einem Szenario.
Entscheidung:Nicht mehr als drei Überprüfungen pro Szenario (außer bei kostspieligen und schwer reproduzierbaren Szenarien).
Manuelle Tester haben sehr oft den Wunsch, Geld für Fälle zu sparen, insbesondere wenn sie schwer sind, und so viel wie möglich in einem Szenario zu testen, indem sie ein Dutzend Tests hineinstecken. Dies sollte nicht zulässig sein, da dieser Ansatz sowohl beim manuellen als auch beim automatisierten Testen das gleiche Problem verursacht: Der erste Test ist fehlgeschlagen, und alle anderen werden als nicht bestanden betrachtet oder starten bei der Automatisierung überhaupt nicht. Daher sind in Autotest-Skripten 1 bis 3 Überprüfungen zulässig. Ausnahmen sind wirklich schwierige Szenarien, die zeitaufwändige Vorberechnungen erfordern, sowie Szenarien, die schwer zu reproduzieren sind. Hier können Sie die Regel kompromittieren, obwohl es besser ist, dies nicht zu tun.
Problem 6: doppelte Prüfungen.
Lösung: Es ist nicht erforderlich, dieselbe Funktionalität immer wieder zu automatisieren.
Wenn wir auf mehreren Seiten dieselbe Funktionalität haben, z. B. einen Standardfilter, ist es nicht sinnvoll, sie während des Regressionstests überall zu überprüfen. Es reicht aus, an einer Stelle zu suchen (es sei denn, es handelt sich natürlich um eine neue Funktion). Manuelle Tester schreiben Skripte und testen solche Dinge auf jeder Seite, einfach weil sie jede Seite isoliert betrachten, ohne sich auf das Innenleben einzulassen. Aber Automatisten sollten verstehen, dass das wiederholte Testen derselben Sache Zeit- und Ressourcenverschwendung darstellt und es für sie recht einfach ist, solche Situationen zu erkennen.
Durch die Lösung der oben genannten Probleme konnten wir die Kosten für die Entwicklung von Autotests um 16% senken.
3. Synchronisation mit Produktteams zum Thema Refactoring, Redesign, wesentliche Änderungen der Funktionalität, um keine Tests "auf den Tisch" zu schreiben.
In unserer Big Data-Abteilung, in der 13 Produkte entwickelt werden, gibt es zwei Gruppen von Automaten:
- Automaten direkt in Produktteams;
- Ein Automatisierungs-Stream-Service außerhalb von Produktteams, der sich mit der Entwicklung des Frameworks und der gemeinsamen Komponenten befasst und Anforderungen von Produkten mit vorgefertigten Funktionstests bearbeitet.
Stream-Automaten sind anfangs nicht so tief im Produkt verankert, und zuvor haben sie nicht an täglichen Teambesprechungen teilgenommen, da dies zu viel Zeit in Anspruch nehmen würde. Sobald dieser Ansatz uns im Stich ließ: Wir haben versehentlich aus Quellen von Drittanbietern erfahren, dass ein Team sein Produkt überarbeiten (den Monolithen in Microservices zerlegen) würde, weshalb einige der von uns geschriebenen Tests an das Archiv gesendet werden. Es war sehr schmerzhaft.
Um dies in Zukunft zu verhindern, haben wir beschlossen, dass mindestens einmal pro Woche ein Automator aus dem Stream zu den Besprechungen des Entwicklungsteams kommt, um auf dem Laufenden zu bleiben, was mit dem Produkt geschieht.
Wir waren uns auch einig, dass Tests nur für die Funktionalität automatisiert werden, die für die Produktion bereit ist und keine häufigen Änderungen erfährt (Regression). Wir müssen sicher sein, dass zumindest in den nächsten drei Monaten kein Refactoring oder größere Überarbeitungen stattfinden werden, da die Automatisten sonst einfach keine Zeit für Tests haben.
Die Kosteneinsparungen, die sich aus der Umsetzung dieser Maßnahmen ergeben, sind schwieriger zu berechnen. Wir haben uns die Zeit genommen, Autotests als Basis zu entwickeln, die durch den geplanten Übergang eines Teils der Funktionalität zu Microservices an Wert verloren haben. Wenn wir diesen Übergang im Voraus kennen würden, würden wir die variable Funktionalität nicht mit Autotests abdecken. Der Gesamtverlust (auch als Einsparpotenzial bezeichnet) beträgt 7%.
4. Upgrade eines manuellen Testers auf einen Automatisierungstechniker
Es gibt nur wenige Testautomaten auf dem Arbeitsmarkt, besonders gute, und wir suchen aktiv nach ihnen. Wir aktualisieren auch aktiv die vorhandenen manuellen Tester, die einen Wunsch und ein grundlegendes Verständnis der Automatisierung haben. Zuallererst schicken wir solche Leute zu Kursen in der Programmiersprache, weil wir vollwertige Automaten und vollwertige Autotests brauchen, und von den Rekordern gibt es unserer Meinung nach mehr Nachteile als Vorteile.
Parallel zum Erlernen einer Programmiersprache lernt eine Person ab Punkt 2, korrekte, strukturierte Skripte ohne Probleme zu schreiben, die Ergebnisse von Autotest-Berichten zu lesen und zu analysieren, kleinere Fehler in Locators zu korrigieren, einfache Methoden anzuwenden, dann vorgefertigte Tests durchzuführen und erst dann ihre eigenen zu schreiben. Die gesamte Entwicklung erfolgt mit Unterstützung erfahrener Kollegen aus dem Stream-Service. In Zukunft können sie an der Fertigstellung des Frameworks teilnehmen: Wir haben eine eigene Bibliothek, die für alle Projekte skalierbar ist. Sie kann durch Hinzufügen einer eigenen Bibliothek verbessert werden.
Diese Richtung der Kostenreduzierung steckt noch in den Kinderschuhen, daher ist es noch zu früh, um die Einsparungen zu berechnen. Es gibt jedoch allen Grund zu der Annahme, dass die Schulung des Personals dazu beitragen wird, die Betriebskosten erheblich zu senken. Gleichzeitig bietet es unseren manuellen Testern die Möglichkeit, sich weiterzuentwickeln.
Ergebnis
Jetzt haben wir ungefähr 30% der Tests an fünf Produkten automatisiert, was zu einer zweifachen Verkürzung der Regressionstestzeit geführt hat.
Dies ist ein gutes Ergebnis, da die Zeit für uns von großer Bedeutung ist: Wir können nicht auf unbestimmte Zeit testen und das Produkt nicht ohne Überprüfung verschenken. Die Automatisierung hingegen ermöglicht es uns, das erforderliche Volumen an Produktprüfungen zum optimalen Zeitpunkt bereitzustellen. In Zukunft planen wir, den Prozentsatz der Autotests auf 80-90% zu erhöhen, um Releases so oft wie möglich zu veröffentlichen, aber gleichzeitig keine Projekte mit Autotests abzudecken, bei denen manuelle Tests noch rentabler sind.