Vor einiger Zeit schrieb ich
einen Artikel über meine Erfahrungen bei der Organisation der Arbeit von QA Engineer an einem Projekt. Jetzt möchte ich dieses Thema fortsetzen, aber in einer engeren Richtung - Testautomatisierung. Es wird
ungefähr das gleiche Projekt sein , es ist klein, aber es entwickelt sich nach den Wünschen der Stammkunden. Vielleicht ist mein Ansatz für Teams mit Dutzenden von Mitarbeitern nicht sehr geeignet und jeder ist für seinen Teil verantwortlich (meiner Meinung nach sollte jedes Projekt streng reguliert werden, sonst ist es einfach unmöglich, einen solchen Koloss zu verwalten, obwohl sie ein gesundes Getreide finden). aber er wird sicherlich für diejenigen interessant sein, die wie ich einmal zu einem neuen Job gekommen sind und an einem Scheideweg standen, wie sie ihren eigenen Platz unter der neuen Sonne organisieren können.
Immer bereit zu lernen
Wie können Sie die Testautomatisierung für ein Projekt organisieren? Wenn Ihre Antwort darin besteht, das wunderbare Selen und eine Art Rahmen dafür und so weiter zu nehmen, dann würde ich es aus der Höhe von 13 Jahren Erfahrung im Testen nicht sicher tun. Muss neue Horizonte meistern.
Was ist mit dem Ansatz behaftet, "Zyklen in Selen zu fahren"? Und die Tatsache, dass Sie bereits mehr als einmal gelesen und gehört haben. Die Tatsache, dass diese Tests eine Benutzeroberfläche sind, ist teuer und langwierig, sowohl beim Schreiben als auch beim Ausführen und bei der Aufrechterhaltung der Leistung. Jeder weiß das, aber der ganze Schmerz dieser Wahrheit tritt nur auf, wenn er ignoriert wird. End-to-End-Autotests der Benutzeroberfläche sollten obligatorisch sein. Niemand außer ihnen gibt Ihnen die Gewissheit, dass das, was der Client nach der nächsten Bereitstellung
sieht, für ihn keine Enttäuschung darstellt. Sie sollten jedoch nicht zum Zentrum der Automatisierung Ihrer Tests werden.
Nehmen Sie die
Prinzipien der Testpyramide als Ihr Qualitätskontrollzentrum. Dieselben, über die bereits viel gesagt wurde, aber in der Praxis versteht nicht jede Qualitätssicherung, wie diese Pyramide angewendet werden kann.
Es ist so gezeichnet:
Und so:
Jeder findet eine Option für seine Architektur.
Testen der Prinzipien der Testpyramide in die Qualitätssicherung
Erstens, egal wie faul und ungewöhnlich es sein mag, meistern Sie die Tests mit der weißen Haut und werden Sie ein „Teilentwickler“.Erhöhen Sie das Projekt lokal, genau wie jeder Entwickler (das Projekt verfügt natürlich über eine Dokumentation dazu, finden Sie es). Sie werden wahrscheinlich ein Dutzend Mal aufhören, dieses Geschäft zu verfluchen, wenn Sie es zum ersten Mal tun, werden Sie eine Million Fragen und Probleme haben, aber wenn Sie dies tun, werden Sie bereits viel wissen: Was sind die architektonischen Ideen, welche Datenbank, woher wird sie weitergeleitet, wo sind die erforderlichen Konfigurationen und vor allem, wo Autotests gespeichert sind und wie sie ausgeführt werden.
Zweitens sollten Sie sich mit Autotests befassen, die von den Entwicklern selbst geschrieben wurden.Finden Sie ihren Platz in der Projektstruktur, welche Arten von Tests und Tools verwendet werden, wie sie gestartet werden. Bewerten Sie die Abdeckung des Projekts mit Autotests und lernen Sie, diese zu navigieren. Es gibt viele Tools für die automatische Abdeckungsbewertung. Sie können sie verwenden, aber darüber spreche ich jetzt nicht. Ich beschäftige mich mehr mit der Entwicklung Ihrer Instinkte: Nehmen Sie ein Stück Funktionalität und sehen Sie, wie es durch automatische Tests abgedeckt wird: gut oder schlecht. Wenn es gut ist, sollten Sie für diesen Teil ruhig sein. Wenn es schlecht ist, haben Sie eine Arbeitsfront für jene Tage gefunden, an denen keine dringenden Aufgaben auf der Tagesordnung stehen. Denken Sie in der Zwischenzeit daran, dass diese Stelle im Code bei jedem Lauf anfällig ist.
Drittens, nehmen Sie Mut und überprüfen Sie die Pull-Anfrage der Entwickler.Notieren Sie sich jedes Mal, wenn Sie mit der Entwicklung einer neuen Funktion beginnen, alle Testfälle dafür. Markieren Sie diejenigen, die Sie unbedingt automatisieren müssen, um nicht zum manuellen Testen dieser Funktionalität zurückzukehren. Überprüfen Sie die Pull-Anforderungen der Entwickler und fordern Sie vernünftigerweise die Implementierung der fehlenden Autotests. Oft bin ich auf sehr coole Entwickler gestoßen, die coole Tests geschrieben haben, aber selbst sie haben eine gute Qualitätssicherung erzielt, um zu verstehen, wie genau der Endkunde das Produkt höchstwahrscheinlich verwenden wird. Daher gibt es auch für erfahrene Spezialisten etwas zu empfehlen, wenn Sie Autotests schreiben.
Viertens, seien Sie noch mutiger und schreiben Sie Autotests direkt in den Produktcode.Ja, genau wie die Entwickler. Auf Augenhöhe mit ihnen. Jedes Mal, wenn Sie auf einen Testfall stoßen, der automatisiert werden muss, müssen Sie ihn nicht sofort mit separaten Tools implementieren, die nur innerhalb des QS-Teams verwendet werden. Stellen Sie sich zunächst die Frage: Kann sie durch Selbsttests von Einheiten / Integrationen im Produktcode automatisiert werden? Wenn ja, machen Sie genau das. Wenn es beängstigend ist, ist dies nur zum ersten Mal beängstigend, aber wie hoch sind Ihre Fähigkeiten, da erfahrene Programmierer Ihre Pull-Anforderungen überprüfen. Ja, zuerst wird alles, was Sie getan haben, in Stücke gerissen, aber die Entwicklung ist immer mit Schmerzen verbunden :) Aber am Ende erhalten Sie wunderbare Dividenden:
- Solche Tests werden vom gesamten Entwicklungsteam unterstützt
- Sie werden kontinuierlich, kontinuierlich und schnell arbeiten
- Sie werden in CircleCi integriert und jedes Mal ausgeführt, wenn sie automatisch bereitgestellt werden (sofern dies im Projekt implementiert ist).
- Löcher werden beim Testen gepatcht (Sie schreiben, was nicht vor Ihnen geschrieben wurde)
- Sie können Entwicklern beim Schreiben von Tests helfen, wenn sie keine Zeit haben
Fünftens: Erstellen Sie eine begrenzte Anzahl von End-to-End-Autotests für die Benutzeroberfläche, die die Aktionen eines Endbenutzers in einem Browser nachahmen.Dies sind Tests, die nur vom QS-Team unterstützt werden. Sie können verkörpert werden
- die beliebtesten, kritischsten Kundenszenarien
- die Tatsache, dass es bei Integrationstests im Hauptcode nicht möglich ist, beispielsweise die Arbeit mit Diensten von Drittanbietern vollständig zu implementieren
Und ja, Sie haben jetzt Zugriff auf das Projekt, und es kostet Sie nichts, das Front-End des Projekts zu aktualisieren, um bequeme und zuverlässige Locators für Selenium zu haben. Sie müssen nicht warten und nach jemandem fragen - öffnen Sie Pull-Anfragen im Hauptproduktcode.
Was kommt davon?
Jetzt arbeite ich an einem solchen Szenario. Infolgedessen befinden sich oben in meiner Testpyramide nur 9 End-to-End-Tests. Und ihre Unterstützung liegt in meiner Verantwortung. Alle anderen zehn und Hunderte von Tests leben mit dem Hauptproduktcode zusammen, beginnen ihre Arbeit auf dem lokalen Computer des Entwicklers und werden vom gesamten Ingenieurteam unterstützt.
Meine End-to-End-Tests funktionieren seit einiger Zeit, da sie Videodateien auf die Plattform hochladen und sie dann mit verschiedenen Parametern konvertieren, zur Verarbeitung an Dienste von Drittanbietern senden, auf eine Antwort warten usw. ohne Stubs. Daher gibt es bei Autotests viele Momente, in denen auf das Ende der Operation gewartet wird. Das Team mochte die Aussicht auf solche Tests in CircleCi nicht und muss es auch nicht. Also habe ich sie wie einen Job in Jenkins implementiert.
Wenn alle Testprüfungen im Produktcode abgeschlossen sind, stellen wir den getesteten Brunch in der Testumgebung bereit und führen mit Jenkins End-to-End-Tests durch. Ein paar weitere manuelle Funktionstests für mehr Genauigkeit bei der Qualitätssicherung und das ist alles, Sie können den Brunch im Master zusammenführen. Heute bin ich nicht der einzige, der Jenkins für Autotests in einer Testumgebung fährt. Entwickler starten sie ständig, wenn sie neue Testdaten generieren und Benutzeraktivitäten simulieren müssen. Es gibt nur wenige von ihnen, daher sind sie stabil und funktionieren immer. Bequem für alle.
Ich werde einen weiteren angenehmen Vorteil für den QS-Ingenieur bei einer solchen Implementierung der Testpyramide feststellen. Es stellt sich heraus, dass Sie Teil eines vollständigen Teams von Ingenieuren werden. Sie machen wirklich einen integralen Bestandteil einer einzelnen Arbeit - schreiben Sie Code mit allen, sehen Sie sich den Code der Entwickler an, kommunizieren Sie mit ihnen, und sie tun dasselbe mit Ihnen. Sie sehen die Arbeit des anderen, eine bessere Zusammenarbeit und eine stärkere Teambildung. Sie werden das Projekt nicht nur von außen verstehen, sondern auch von innen, das Respekt verdient, nicht wahr?
Endgültiger Abschied
Mein Artikel behauptet nicht, eine universelle Pille zu sein, die jederzeit und überall angewendet werden kann. Alle Projekte sind sehr unterschiedlich, alle Teams sind sehr unterschiedlich - jedes sollte seinen eigenen besten Weg selbst finden, oft ist dies die Quintessenz verschiedener Ansätze und Werkzeuge. Sogar das berühmte Scrum, wie viele Projekte ich gesehen habe, bekennt sich jeder auf seine Weise :) Ich glaube nicht an strenge Anweisungen, ich glaube, dass sie als Richtlinien benötigt werden, aber ich muss entsprechend der Situation handeln.
Die IT-Welt entwickelt sich jedoch weiter und es kommen immer mehr Menschen dazu. Ich bin sicher, dass es unter den Lesern dieses Materials sicherlich jemanden geben wird, zu dem meine kleinen Anweisungen mir helfen werden, den richtigen Weg zu wählen. Lächle mich in Kommentaren an, wenn es nützlich war :), Feedback wird mir angenehm sein!