Beim Lesen von Artikeln zum Thema Webtests tauchen zwei Themen unter bestimmten Bedingungen auf: 1) Manuelle Tests sterben aus, Autotests (im Folgenden als Autotests bezeichnet werden Selenium UI- und REST-Tests) sind unser Alles; 2) Automatische Tests sind kein Allheilmittel, manuelle Tests sind unverzichtbar. Gleichzeitig besteht aus den Artikeln eine Tendenz zu einem Anstieg der Anforderungen an die Softwarequalität und die Geschwindigkeit der Produktentwicklung. Wrike ist nur dann der Fall, wenn diese Anforderungen kritisch sind.
Das Produkt ist bereits 12 Jahre alt, wächst aber immer noch aktiv. Bereitstellungen erfolgen einmal am Tag und manchmal zweimal. Daher ist es für uns von entscheidender Bedeutung, dass die Regression ausschließlich bei Autotests durchgeführt wird. In Wrike (im Unternehmen) gibt es jedoch über 30 Scrum-Teams, und die Mitarbeiter des Automatisierungsteams sind nicht aus Gummi. Unter solchen Umständen sind ein oder zwei Sprints keine Option, um bestenfalls eine Automatisierung manueller Szenarien zu erwarten. Die Erfahrung unseres Unternehmens zeigt, dass ein manueller Tester Autotests unabhängig von bestimmten Nuancen schreiben kann. In dem Artikel werde ich darüber berichten und warum diese Fähigkeit meiner Meinung nach nicht nur dazu beiträgt, mit den Trends Schritt zu halten, sondern auch für den Tester selbst nützlich sein wird.
Standardverfahren
An welchen Prozess sind viele Teams gewöhnt? Es variiert von Fall zu Fall, aber die gemeinsamen Merkmale sind ungefähr gleich. Es gibt Abteilungen für automatische und manuelle Tests. Manuelle Tester können auf Scrum-Befehle verteilt werden. In diesem Fall hat die Automatisierung in der Regel keine Beziehung zu einem bestimmten Team.
Bei der Arbeit mit neuen Funktionen erstellt der Tester Testskripte, von denen er einige für Automaten auf eine vorgegebene Weise markiert. Wenn es bereits Fälle gibt, in denen Anpassungen vorgenommen werden, werden diese auch notiert, um den Code zu aktualisieren. Anschließend werden die markierten Tests an die Automatisierungsabteilung übertragen. Ein Team von Automatisierungsingenieuren übernimmt die Aufgabe, aktuelle und neue Autotests in einem der folgenden Sprints zu korrigieren. Neben der Programmierung von Testszenarien gehören zu den Aufgaben des Automators das Ausführen von Autotests, die Analyse der Ergebnisse sowie die Unterstützung und Entwicklung des Testprojekts. Es stellt sich heraus, dass die Automatisierungsabteilung als Outsourcing-Executor fungiert und manuelle Tester eine Art Kunden sind.
Der Kunde verbringt außerdem viel Zeit damit, eine detaillierte und genaue TOR zu erstellen, die Implementierungsmethoden regelmäßig zu besprechen und die erforderlichen Tests auszuwählen. Es besteht auch das Risiko, dass während des Fehlens von Autotests Fehler übersprungen werden. Vergessen Sie nicht, dass es eine Reihe technischer Probleme gibt, die nur bei automatischen Tests behoben werden können, was viel Zeit sparen würde. Solche Aufgaben müssen in dem Teil, in dem die Automatisierung noch fehlt, von Hand überprüft werden.
Der Auftragnehmer, der nicht sehr in die Funktionalität des Teams vertieft ist, wird sich Zeit nehmen, um oberflächlich in die Aufgabe und das Bewusstsein des TOR einzutauchen. Gleichzeitig ist es wahrscheinlich, dass der Test nicht genau in den Code übersetzt wird, wodurch nicht überprüft wird, was wir möchten. Dementsprechend wird die Effizienz der Testbasis verringert.
Das Automatisierungsteam, das als einziger am Testprojekt beteiligt ist, hat die volle Kontrolle über seine Codebasis, sodass es problemlos in jede Richtung entwickelt werden kann. Die Zeit dafür wird jedoch aufgrund der zunehmenden Belastung durch andere Teams nicht ausreichend. Das Problem kann durch die Erweiterung des Personals gelöst werden, aber dann werden die Kosten für die Automatisierung die Effektivität übersteigen. Selbst wenn Sie einen Teil der Last entfernen und manuellen Testern die Möglichkeit geben, Tests durchzuführen und heruntergefallene zu analysieren, führt dies nicht zum richtigen Ergebnis. Da sie keine Tools zum Debuggen von Tests haben, verstehen sie möglicherweise nicht, dass der Test aufgrund einer Änderung von xpath usw. abgestürzt ist.
Dementsprechend erhalten wir bei der Ausgabe, dass die Autotests mit diesem Schema nicht mit dem Wachstum des Produkts Schritt halten, was zu einer schlechten Abdeckung des Codes führt. Aufgrund einer ungenauen Interpretation von TK können Tests Fehler überspringen. Wenn sie für längere Zeit veraltet sind, werden die gefallenen nicht sofort repariert, und es ist für manuelle Tester schwierig, sofort zu erkennen, welcher Teil des Systems von der Automatisierung gut abgedeckt ist. Autotests werden zu einer Art Black Box, der Tester misstrauisch gegenüberstehen. Daher nimmt die Anzahl unnötiger manueller Überprüfungen zu, die Aufgabenbereiche werden gestreckt und die Qualität nimmt langfristig ab.
Sie können mit diesen Mängeln arbeiten, aber je größer das Produkt und das Unternehmen sind, desto schmerzhafter sind die Teilnehmer am Prozess, und vor allem ist es schwierig, dem Trend zu folgen, die Geschwindigkeit zu erhöhen und die Qualität zu verbessern. Der Tester selbst wird zur Geisel der Routine und bleibt praktisch nicht auf der Entwicklung der Zeit.
Falscher Weg
Also, wie es am Beispiel des Teams funktioniert, in dem ich arbeite. Es gibt automatische und manuelle Testteams. Die anfänglichen Daten sind immer noch ähnlich, aber dann beginnen die Unterschiede. Manuelle Tester werden auf ihre Scrum-Teams verteilt. Jedes Scrum-Team hat einen eigenen Autotester. Manchmal kann es nicht einem, sondern zwei Teams zugewiesen werden, wenn die Last dies zulässt.
Bei der Arbeit mit neuen Funktionen schreibt der Tester Checklisten, nach denen er dann manuelle Prüfungen durchführt. Der minimal erforderliche Teil der Tests aus dieser Checkliste ist automatisiert. Der Tester selbst schreibt diese Autotests zu dem Zeitpunkt, an dem sich die Funktion in der Entwicklung oder im Test befindet. Ferner wird der schriftliche Code dem Prüfer zur Prüfung übergeben. Mit seltenen Ausnahmen kann keine Aufgabe ohne Autotests ausgegeben werden.
Natürlich ist es in Wrike nicht erforderlich, Autotests von manuellen Testern zu schreiben. Dies liegt im Ermessen des Teams. Sie können alles für die Automatisierung geben. Sie können sich darauf beschränken, fehlerhafte Tests zu beheben und / oder neue Tests analog zu schreiben, und komplexere Aufgaben (Erstellen neuer Tests oder Erweitern alter Back-End-Handles, Seitenobjekte oder Testschritte und -klassen) an ein spezielles Automatisierungstool delegieren. Es hängt alles von Ihnen ab, aber es ist dumm, die Vorteile zu verpassen, die das unabhängige Schreiben automatischer Tests bietet.
Unsere gesamte Regression basiert auf Autotests. Zu den Aufgaben manueller Tester gehört das Ausführen und Analysieren von Autotestfehlern. Für jede Niederlassung, an der das Team arbeitet, führen sie als erster und letzter Qualitätsgarant automatische Tests durch. Daher ist es für diejenigen, die selbst Autotests schreiben, viel einfacher zu verstehen, warum ein Test, der auf ihrem Zweig ausgeführt wird, abgestürzt ist. Manchmal reichen Tools wie das erneute Ausführen und ein Bericht in
Allure wirklich aus, um den Grund für den Testabsturz anhand des Screenshots und der Schritte zu verstehen. Der beste Assistent ist jedoch häufig die Möglichkeit, Tests lokal auszuführen, mit Schritten herumzuspielen oder sie im Debug-Modus auszuführen und den erwarteten und tatsächlichen xpath anzuzeigen. Ohne Erfahrung in der Arbeit mit einem Testprojekt nimmt dies viel Zeit in Anspruch, oder es ist erforderlich, das dedizierte Automatisierungstool abzulenken.
Darüber hinaus ermöglicht das unabhängige Schreiben von Autotests, diese bereits vor der Veröffentlichung der Funktion auszuführen. Der Tester kennt immer den Grad der Abdeckung seines Teils des Systems, und technische Aufgaben werden nur bei automatischen Tests ausgeführt, was Teamzeit und Ressourcen erheblich spart. Die Tests selbst sind immer relevant, da Abstürze vor der Veröffentlichung angepasst werden. Defekte Tests werden sofort in demselben Zweig korrigiert, in dem neue geschrieben werden.
Der manuelle Tester ist maximal in die Aufgabe des Teams eingetaucht, daher wird das erforderliche Minimum an automatischen Tests ausgewählt, das die meisten Fälle abdeckt. Das Beispiel wird während des Tests mehrmals überarbeitet, da bei manuellen Überprüfungen die Funktionalität mit allen Nuancen genauer untersucht wird. Dementsprechend wächst die Effizienz solcher Tests. Durch das Schreiben von Autotests können Sie die Architektur der Anwendung, die verwendeten Komponenten und die Front-End-Interaktion mit dem Back-End besser verstehen. Letztendlich hilft dieses Wissen bei einem bewussteren und effektiveren Ansatz beim Testen von Produkten. Wenn beispielsweise ein Befehl Änderungen an der allgemeinen Komponente vornimmt, wissen Sie mit größerer Wahrscheinlichkeit im Voraus, ob Ihr Bereich betroffen ist oder nicht, da Sie bei der Arbeit mit xpath verstehen, welche Komponenten in Ihrem Teil der Anwendung verwendet werden.
Es kann argumentiert werden, dass das Schreiben von Autotests Zeit braucht. Ja, Aufgaben werden ein bis drei Tage später als gewöhnlich freigegeben, aber auf lange Sicht zahlt es sich aus. Darüber hinaus gibt es Optimierungsmethoden. Während sich eine Funktion in der Entwicklung befindet, können Sie beispielsweise die erforderlichen Checklisten erstellen und ein Leerzeichen für Tests erstellen, wodurch Zeit gespart wird. Wenn Sie über ein vorgefertigtes Funktionsframework verfügen, können Sie vorhandene xpaths hinzufügen oder korrigieren, bei Bedarf ein neues Seitenobjekt erstellen oder die Schritte anpassen. In der Phase des Schreibens von Autotests müssen Sie nach manuellen Überprüfungen nur noch die Codeblöcke in der richtigen Reihenfolge hinzufügen.
Dank des von unserem Automatisierungsteam entwickelten Frameworks repräsentiert das Schreiben von Autotests größtenteils das Kompilieren von Code aus Blöcken - wie Lego. Diese Einfachheit ermöglicht es Ihnen, sich schnell an manuelle Tester anzupassen und Autotests analog zu vorhandenen zu schreiben. Aus eigener Erfahrung habe ich gesagt, dass es ungefähr zwei Wochen vom Moment meiner Arbeit bei Wrike bis zu den ersten Autotests, die ich zusammen mit anderen Aufgaben geschrieben habe, gedauert hat.
Die Qualitätskontrolle schriftlicher automatisierter Tests erfolgt durch Codeüberprüfung. Kein einziger Testzweig wird ohne Überprüfung in die Version aufgenommen. Dies ist ein guter Trainingsmoment, da der Tester nützliche Informationen aus den Kommentaren zu seinem Code bezieht und die Erfahrung guter Lösungen aufbaut: Beispielsweise verwaltet er die Standard-Java-Bibliothek effizienter oder definiert xpath genauer. Das nächste Mal wird klar sein, wie man am besten mit einer bestimmten Situation arbeitet.
Natürlich beanspruchen die Entwicklung eines Testprojekts, eines Frameworks und die Schulung manueller Tester die Ressourcen der Automatisierung, insbesondere in der Anfangsphase, aber es scheint mir, dass sich diese Bemühungen voll auszahlen. Wir haben viele Verbesserungen in der automatisierten Testumgebung, die unsere Arbeit erleichtern. Das Produkt selbst hat eine gute Abdeckung, sodass Sie sich auf die Regression verlassen können. Dies beschleunigt die Einführung von Funktionen in der Benutzerumgebung und schützt die Nerven der Tester erheblich.
Nach den Erfahrungen unseres Teams ist dies einer der besten Prozesse für die Arbeit mit einem großen und sich schnell entwickelnden Produkt in einem großen Unternehmen. Darüber hinaus entspricht es den aktuellen Trends zur Verbesserung der Qualität von Software und der Geschwindigkeit ihrer Lieferung an Benutzer. Der Tester selbst wird die Routine praktisch los, entwickelt sich in verschiedene Richtungen und betrachtet die Anwendung aus verschiedenen Blickwinkeln.
Kurz über die Hauptsache
Der Einfachheit halber werde ich die Vorteile eines manuellen Testers an einer Stelle hervorheben, damit es einfacher ist, ihre Bedeutung einzeln oder alle zusammen zu erkennen:
- Es wird ein vollständigeres Bild über den Grad und die Qualität der Automatisierung Ihrer Bereiche erstellt.
- Autotests sind verfügbar, bevor die Funktion veröffentlicht wird, sodass die Qualität jederzeit schnell überprüft werden kann.
- Die Effizienz von Autotests steigt ebenso wie die Effizienz von Tests im Allgemeinen.
- Ein informierterer und effektiverer Testansatz wird entwickelt.
- Monotone manuelle Regressionen und lange Bewertungstests loswerden;
- Persönliches Wachstum und Entwicklung von Kompetenzen.
Zusammenfassend
Natürlich gibt es keine Silberkugel. Was für ein Unternehmen geeignet ist, kann von einem anderen Unternehmen scharf abgelehnt werden. Im Fall von Wrike wächst das Produkt extrem schnell und es bleibt keine Zeit für langwierige manuelle Regressionen und Bewertungstests. Wir haben diese Rolle bei Autotests, die fast alle Komponenten eines riesigen Produkts abdecken. Dies hilft, die Qualität zu erhalten, Ressourcen zu optimieren und Benutzern schneller neue Funktionen bereitzustellen.
Die schlechte Nachricht ist, dass es nicht ohne Fehler auskommen kann, aber in unserem Fall handelt es sich meistens um extreme Fälle. Die gute Nachricht ist, dass Fehler während der Korrekturen auch mit Autotests überwachsen sind.
Aus irgendeinem Grund ist es in der Community so üblich geworden, dass die Idee, Autotests von manuellen Testern zu schreiben, abgelehnt wird. Es gibt zwei populärste Argumente von Testern: "Sie zahlen dafür nicht extra" und "Wir haben bereits genug Arbeit." Für mich persönlich fallen beide Argumente auseinander, wenn ich feststelle, dass ich zum Zeitpunkt der Entwicklung eines Features Selbsttests durchführen und in kurzer Zeit verstehen kann, wie es richtig funktioniert. Es ist viel wert. Unsere Aufgabe ist es, die Qualität des Produkts zu verbessern und aufrechtzuerhalten, damit jede Gelegenheit genutzt wird, um es zu erleichtern. Von dem Moment an, als ich anfing, Autotests zu schreiben, wurde die Routine in meiner Arbeit immer weniger bewusst.
PS Dieser Artikel spiegelt nur die Erfahrung unseres Teams wider und entspricht möglicherweise nicht Ihren Überzeugungen. Daher freue ich mich über die Ansätze, die Sie bei Ihrer Arbeit leiten. Ich freue mich auch über gesunde Kritik und die Möglichkeit, den Artikel in den Kommentaren zu diskutieren.