Entwicklung sollte Tests schreiben (?)

Hallo! Es gibt einen alten Holivar zum Thema, wer Tests schreiben soll: Entwickler oder Tester. Es scheint, als ob es Tester im Team gibt, dann ist es logisch, dass sie die Tests schreiben, oder? Andererseits wissen die Leute von der Entwicklung (zusätzlich zur Entwicklung selbst) genau, wie ihr Code funktioniert und wie er sich in bestimmten Situationen verhält. Zumindest nehmen sie an.

Haftungsausschluss: Mein Name ist Eric Burygin. Ich arbeite seit langer Zeit als Tester. Ich unterrichte Studenten im Kurs "Test Engineer" . Es scheint also, dass der Tester nur eine Arbeit an die Entwickler übertragen möchte. Tatsächlich hat der beschriebene Ansatz sowohl Vor- als auch Nachteile, so dass der Artikel unter anderem umstritten ist. Ich würde mich freuen, die Meinungen von Entwicklern und Testern in den Kommentaren zu sehen.

Wenn die Entwicklung Tests schreibt, können Sie mehrere Probleme gleichzeitig lösen, zum Beispiel:

• Beschleunigen Sie den Freigabezyklus spürbar.
• Test entladen.

In den meisten Befehlen sieht der Prozess ungefähr so ​​aus:

1. Der Entwickler erstellt neue Funktionen und vervollständigt vorhandene.
2. Der Tester testet dies alles und schreibt verschiedene Testfälle.
3. Der Automator, der den Titel der Position begründet, automatisiert alles gemäß den schriftlichen Testfällen aus Abschnitt 2.

Alles scheint einfach zu sein.



Dieses Paradigma weist jedoch Schwächen auf.



Angenommen, ein Entwickler hat seine Funktion abgeschlossen und zum Testen sicher bestanden. Aber das Feature erwies sich als nicht mittel selten, aber ehrlich gesagt roh. Dies führt zu einer erneuten Entdeckung des Problems und zusätzlichen Korrekturen. Abhängig von der Größe dieser Funktion, ihrer Komplexität, den Auswirkungen auf verwandte Prozesse und der Gewissenhaftigkeit des Entwicklers selbst kann es zu einer bis zu N Iterationen kommen. Und auch darüber, wie Ihre Prozesse im Prinzip innerhalb der Entwicklung angeordnet sind, wie sorgfältig Pull-Anfragen aussehen, ob die Anwendung gestartet wird, bevor sie zum Testen gesendet wird.



Im Allgemeinen gibt es genügend Variablen.



Nachdem die Aufgabe getestet und zur Veröffentlichung bereit ist, müssen Tests für die gesamte Funktionalität von Testfällen geschrieben werden. Dann zurücktreten / rauchen und schließlich loslassen.



Nach Erhalt der schriftlichen Testfälle deckt der Automator die Funktionalität mit Tests ab. Es besteht eine ziemlich hohe Wahrscheinlichkeit, dass die Aufgabe in einer vorhandenen Warteschlange landet, sodass die Tests mit Verzögerung geschrieben werden.

- Brauche nur mehr Entwickler

Leider kein Allheilmittel. Ganz im Gegenteil. Je mehr Entwickler Sie in diesem Schema haben, desto stärker ist die Testlast. Infolgedessen wird entweder der Freigabezyklus oder das Testteam selbst erhöht.



Und dies erhöht nach dem Domino-Prinzip die Belastung der Automaten, die immer mehr Testfälle verarbeiten müssen, die beim Testen auf sie fallen. Es wird eine Spiegelsituation geben: Entweder erhöht sich die Testabdeckungszeit oder das Automatisierungspersonal.



Auf acht Entwickler kommen normalerweise zwei Tester und ein Automatisierungstechniker. Gleichzeitig ist die Automatisierung nicht direkt in den Release-Zyklus eingebunden, sondern befindet sich in der Nähe. Und es stellt sich die Frage: Wie können die beschriebenen Prozesse effektiver gestaltet und sogar nicht an Qualität verloren werden?



Versuchen wir, die Automatisierungsphase vom dritten auf den ersten Platz in die Entwicklungsphase zu verschieben.

Was geschieht

Sie erhalten sofort eine Reihe von Vorteilen, siehe:

• Entwickler schreiben Tests gleichzeitig mit dem Schreiben des Features selbst, wodurch die Qualität erheblich verbessert wird.
• Die Belastung der Tests nimmt ab: Die Tester müssen sich nun die Testergebnisse ansehen und beurteilen, ob die Aufgabe durch die Tests ausreichend abgedeckt ist.
• Eine manuelle Regression im Schema ist nicht mehr erforderlich.

Was ist mit Testern?



Der Tester bleibt auch im aktualisierten Paradigma ein Testexperte - er ist es, der sowohl die Qualität als auch die Vollständigkeit der Autotest-Abdeckung eines bestimmten Merkmals überprüft und komplexe und ungewöhnliche Probleme analysiert. Dank der reduzierten Belastung hat der Tester nun einen Teil seiner Zeit frei und kann Prozesse verarbeiten.



Gleichzeitig müssen Sie verstehen, dass manuelle Tests immer noch nirgendwohin führen - Sie haben immer etwas, das aus irgendeinem Grund entweder nicht automatisierbar oder nicht sinnvoll ist.



Also zu einem neuen Paradigma. Cool? Ja, implementieren Sie es zumindest jetzt. Wenn Sie zwei Dinge tun können.

1. Verkaufen Sie diese Idee an die Entwicklung. Weil nicht jeder Entwickler sofort Tests schreiben möchte, weil es langweilig sein kann oder er einfach nicht will: Haben Sie tatsächlich Tester für was?
2. Verkaufen Sie diese Idee an Manager. Mit anderen Vorteilen erhöhen Sie die Entwicklungszeit für jede Funktion.

Was sind die Nachteile hier können Sie erwarten.

1. Die meisten Entwickler wissen einfach nicht, wie sie testen sollen, weil sie Entwickler und keine Tester sind. Und das ist okay. Hier können Sie ihnen entweder das Testen beibringen, was nicht die trivialste Aufgabe ist, oder einfach Testfälle für sie schreiben. Was de facto den Prozess selbst bricht.
2. Zu Beginn wird die Automatisierung mehr Zeit in Anspruch nehmen, da es keine Testcodebasis, Infrastruktur und übliche Ansätze gibt - die Aufgabe ist neu.
3. Zum Testen werden klare Berichte benötigt. Aber denken Sie daran: Selbst der verständlichste Bericht kann nicht immer sofort richtig gelesen werden.
4. Sie können nicht jedes Problem einfach und schnell mit Tests abdecken. In einigen Fällen müssen Sie mehr Zeit für Tests als für die eigentliche Implementierung der Funktion aufwenden.
5. Es wird schwierig sein, große Aufgaben gleichzeitig mit Tests zu erledigen, es nimmt viel Zeit in Anspruch.
6. Für dieselben umfangreichen und komplexen Aufgaben müssen Sie noch Zeit einplanen, um sie einfach zu untersuchen, da es keine andere Möglichkeit gibt, die Richtigkeit der von den Entwicklern geschriebenen Tests zu überprüfen.

Was ist zu tun?

Grundsätzlich hat jedes Problem eine Lösung.

1. Entwickler wissen nicht, wie sie testen sollen. →
   
   Sie können sie frühzeitig konsultieren, um das Verständnis zu verbessern.
2. , . →
   
   . .
3. . →
   
   , , .
4. . →
   
   : .
5. , . →
   
   , — . .
6. . →
   
   . .

Ein Ansatz mit all seinen Vor- und Nachteilen hat ein Recht auf Leben. Wenn Sie die Prozesse auch korrekt eingerichtet haben, können Sie den Freigabezyklus beschleunigen und den Status nicht aufblasen (: