Hallo! Mein Name ist Alyona Isakova, ich bin eine führende Testerin in Avito und ich möchte Ihnen über meine Erfahrungen bei der Einführung von Agile-Tests in das Team berichten. Als ich Artikel über Agile-Tests und ATDD las, die auf Russisch verfügbar waren, hatte ich den Eindruck, dass ich "nicht in Mode" war, "nicht über Agile". Es schien, dass dies eine Art komplexe Struktur war, die die Einbeziehung von Entwicklern erforderte, und bevor sie angewendet wurde, musste ich immer noch "pflügen und pflügen".

Eine Weile lebte ich mit dieser Idee, schrieb eine Checkliste mit Aufgaben während der Festlegung von Aufgaben, sammelte Besprechungen des „Feature-Teams“, zu denen PM, QA, Frontend und Backend eingeladen wurden, um die Nuancen der Aufgabe vor der Implementierung zu besprechen.

Diejenigen, die verstehen, wovon sie sprechen, haben den Haken bereits bemerkt, nicht wahr?

Wenn Sie googeln, was „Agiles Testen“ ist, können Sie Vorschläge für die Teilnahme an Kursen sowie einige Artikel mit Ansichten zum Ansatz und zur Definition auf Wikipedia einbringen:

"Agiles Testen ist eine Software-Testpraxis, die den Prinzipien der agilen Softwareentwicklung folgt. An agilen Tests sind alle Mitglieder eines funktionsübergreifenden agilen Teams beteiligt. Die Tester bringen spezielles Fachwissen ein, um sicherzustellen, dass der vom Kunden gewünschte Geschäftswert in regelmäßigen Abständen in einem nachhaltigen Tempo erzielt wird. Die Spezifikation anhand eines Beispiels wird verwendet, um Beispiele für gewünschtes und unerwünschtes Verhalten und Leitcodierung zu erfassen. "

Ich weiß nichts über dich, aber ich habe diese Definition beim ersten Mal nicht zu Ende gelesen. Ich wurde von Sehnsucht angegriffen. In der Tat ist nicht alles so trocken. Das Fazit ist, dass agiles Testen ein solcher Ansatz für den Testprozess ist, bei dem der Tester im Gegensatz zum Waterfall-Ansatz viel stärker in die ersten Phasen der Aufgabe involviert ist und in letzteren weniger (oder gar nicht).

Wie war unser Aufgabenablauf angeordnet?

Es ist erwähnenswert, dass unser Team anfangs an dem strengen SCRUM gearbeitet hat. Entschuldigen Sie den Ausdruck, der offensichtlich gut zu agilen Tests passt. Man kann sagen, dass dies impliziert.

1. Aussage des Kunden (PM annehmen)

Zu diesem Zeitpunkt wurde die Formulierung des Problems für uns gemäß dem Schema User Story, Akzeptanzkriterien, Anwendungsfall durchgeführt. Eine solche Aussage, offensichtlich Agile, ist kein Zufall - es ist ein Verdienst meiner Kollegin in der Einheit, die bereits Agile-Tests in ihrem Team eingeführt hat. Warum ich nicht einfach die Erfahrung eines benachbarten Teams ausleihen konnte, werde ich Ihnen später in diesem Artikel erläutern.

2. Überprüfung der Problemstellung durch den Tester

Zu diesem Zeitpunkt wurde die Aufgabe auf Eindeutigkeit, Konsistenz und Nützlichkeit überprüft. In meinem Fall habe ich hier auch das Element "Tests" hinzugefügt, in dem zusätzliche Testfälle (z. B. negativ) beschrieben wurden, die für das Schreiben im Anwendungsfallformat ungeeignet waren. Zu diesem Zeitpunkt war mir nicht vollständig bewusst, wie Akzeptanzkriterien verwendet werden, daher habe ich nur versucht, dem Entwickler maximale Eingaben für meine zukünftigen Überprüfungen zu geben.

3. Diskussion der Aufgabe durch alle Interessierten oder "Feature-Team"

Die Bühne wurde nach Bedarf durchgeführt. Wenn der Tester nach der Überprüfung feststellte, dass die Aufgabe klar ist und keine zusätzlichen Diskussionen erforderlich sind, fahren wir mit dem vierten Absatz fort.

Wenn die Bühne notwendig war, wurde auf dem Treffen Klarheit über die Anforderungen geschaffen, zusätzliche Arbeit. Oft wurde die Aufgabe zerlegt, die Testbedingungen wurden während des unabhängigen Betriebs von Frontend und Backend besprochen.

4. Die in einem Rückstand verfolgte Aufgabe wurde geplant, ausgeführt, ausgerollt und brachte Nutzen und Glück

Es scheint, dass nicht alles so schlecht ist, aber es gibt etwas zu verbessern: Zumindest können Sie ein paar zusätzliche Schritte entfernen, da wir nicht verstehen, warum sie sind.

Was wurde getan, um sich zu verbessern?

Der Entwickler und ich verspürten den unstillbaren Wunsch, uns zu verbessern, und bestanden eine interne Meisterklasse zum Thema Agiles Testen. Es stellte sich heraus, dass das Team nur die Terminologie ändern und die Schrauben unseres Custom-Bikes ein wenig festziehen muss, um den Ansatz vollständig einzuhalten.
Die Einführung des Ansatzes und die Beobachtung der Teams, in denen er bereits existiert, reicht nicht aus. Sie benötigen einen Wissensblock und eine Bewusstseinsstufe, die in meinem Fall von einer Meisterklasse gegeben wurde. Ein großes Plus war die Tatsache, dass wir mit dem Entwickler trainiert haben, was ich jedem sehr rate. Es ist schwierig, seine Hilfe zu überschätzen. Sie beide (Tester und Entwickler) sind ein notwendiges und ausreichendes Minimum, um mit der Implementierung des Ansatzes zu beginnen. Darüber hinaus ist jedes Team und Produkt individuell. Um diese Methode für sich selbst zu verfeinern, müssen Sie es zumindest versuchen.

In einem benachbarten Team gibt es beispielsweise Erfahrung in der nützlichen Verwendung von Komponententests mit einer vorläufigen Beschreibung in einem Tool zum Speichern von Testfällen und anschließender Automatisierung. Unser Team hat beschlossen, die erforderliche Überprüfung zunächst konzeptionell zu ermitteln, zu automatisieren und anschließend die Fälle automatisch aus dem Code in ein Speicherwerkzeug auszuwählen. Möglicherweise haben Sie Ihre eigene Art der Interaktion.

Ich erkläre nicht, dass es ohne ein besonderes Ereignis auf keinen Fall möglich ist, einen Ansatz einzuführen. Aber Sie müssen sich Zeit nehmen, um zu verstehen, das Team zu motivieren und sich zu verändern und zu verändern. Seien Sie darauf vorbereitet, dass nicht jeder die Zunahme der Zeit, die für die Aufgabe mit offenen Armen aufgewendet wird, sofort akzeptieren wird. Ich hatte diesbezüglich Glück.

Was zu diesem Thema zu lesen

„Agiles Testen. Schulungskurs für das gesamte Team “, Janet Gregory und Lisa Crispin. Das Buch wurde kürzlich in russischer Übersetzung veröffentlicht und ist auf Ozone erhältlich.

Was genau hat sich geändert

1. Bei unseren Treffen zur Klärung des Rückstands (PBR) wurde ich wie ein nerviger, ausgezeichneter Schüler, der alles und jedes fragte: „Was passiert, wenn der Dienst eines Drittanbieters ausfällt?“, „Was passiert, wenn wir null und nicht 0 zurückgeben?“, „A. Warum nennen wir das und nicht dort drüben? "," Und was ist, wenn wir nicht alle Daten erhalten? "," Was ist, wenn der Planet von rebellischen Dinosauriern gefangen genommen wird? " Nur ein Scherz, nur wichtige Fragen, keine "Null" und "0".
   Im Laufe der Zeit stellten die Jungs fest, dass in einer solchen Diskussion mehrere Fälle entstehen, die im Voraus nicht berücksichtigt wurden und die sie jetzt vorhersehen können. Zuvor Fragen wie "Was passiert, wenn alles auseinander fällt?" Ich habe mich in der Testphase und jetzt in der Einstellungsphase gefragt.
2. Anstelle des Elements "Tests" in Aufgaben schreiben wir detailliert und bewusst "Akzeptanzkriterien" und bestimmen auch die Anzahl und das Niveau zukünftiger Autotests.
   Um ehrlich zu sein, ist es erwähnenswert, dass wir nicht in 100% der Fälle die Anzahl der Autotests im Voraus kennen. Es gibt Zeiten, in denen wir dies technisch nicht können oder es länger dauert als bei der Besprechung. In der Praxis ist es oft nicht möglich, dramatisch zu handeln. Und das ist zulässig - mit der Zeit wird etwas kommen.
3. Die Punkte "Überprüfung der Problemstellung durch den Tester" und "Feature-Team" führen wir derzeit nicht durch. Wir lösen alle Probleme bei PBR-Meetings, da bereits alle erforderlichen Personen anwesend sind und die Akzeptanzkriterien dabei besprochen werden.
4. Der Tester wird dem Überprüfungscode für den Komponententest hinzugefügt, um zu bestätigen, dass genügend Überprüfungen vorhanden sind.
5. Anstelle der üblichen Funktionsprüfung werden am Ende des Entwicklungsprozesses Autotests (auf allen Ebenen) durchgeführt und nur Forschungstests durchgeführt.
   Im Idealfall sollten Tests natürlich überhaupt nicht vorhanden sein. In unserer Praxis haben wir jedoch festgestellt, dass es einfacher und korrekter ist, Forschungstests hinzuzufügen, wenn Sie Änderungen an einem von vielen Teams entwickelten Produkt vornehmen.

Welche Schwierigkeiten hatten Sie?

1. Was ist ein Unit-Test?

Wir sind mit der Tatsache konfrontiert, dass wir, die Qualitätssicherung, nicht verstehen, welche Komponententests getestet werden, und ihnen daher nicht vertrauen. Als Hommage an unsere Wachsamkeit schreiben wir Tests auf einer höheren Ebene und mit einem klopfenden Absatz: "Um zu automatisieren, können Sie keine Gnade haben."

Wie entschieden:
Wir saßen mit unserem von Agile ausgebildeten Entwickler (danke ihm und seiner Geduld) in der Ecke und er erklärte mir eine Stunde lang an den Fingern, was Unit-Tests sind, womit sie essen und warum sie "diese Scheiße" noch nicht überprüfen können. Als Ergebnis unseres Leidens wurde ein erstaunliches Dienstprogramm geboren: Sie haben es so gezeichnet, dass sie es selbst verstanden haben.

Ein ausgewählter Pfeil - eine Auslösung - eine Prüfung im Unit-Test

Infolgedessen schreibe ich nach ein paar Monaten selbst ein paar Unit-Tests und lösche redundante Prüfungen auf den oberen Ebenen. Dies ist natürlich hauptsächlich Kopieren-Einfügen, aber bewusst!

Vielleicht verstehen Sie die Essenz von Unit-Tests bereits gut und müssen keine Zeit mit diesem Thema verbringen. Wenn nicht, sollten Sie Ihren Entwickler in einer ruhigen Umgebung unterkautifizieren und ihn mit Fragen angreifen.

2. In der aktuellen Implementierung können nicht alle Tests ohne Änderungen weggelassen werden

Wie entschieden:
Unnötige Datensätze von e2e-Tests wurden entfernt, indem die Anzahl der Komponententests erhöht wurde.
Wir haben die implementierten Unit-Tests bereits überarbeitet und aufgeschrieben, welche Prüfungen wir von ihnen erwarten. Danach stellte sich erwartungsgemäß heraus, dass uns einige Schecks fehlten.
Nachdem wir festgelegt haben, was und auf welcher Ebene wir wollen, stellen wir Aufgaben für die Zukunft.
Nachdem wir geschult hatten, was bereits vorhanden ist, nahmen wir die eigentliche Anwendung des Ansatzes auf und begannen, Überprüfungen von Methoden zu schreiben, die noch nicht verfügbar sind. Es war schon schwieriger.

Schlussfolgerungen

• Die Besonderheit dieses Ansatzes besteht darin, dass er natürlich ist und aus folgenden Dingen hervorgeht: „dem Benutzer Wert vermitteln“, „manuelle Qualitätssicherung reduzieren“, „Abdeckung bieten“. Wie genau Sie dies tun werden, ist eine andere Frage, aber dieser Ansatz hat Ihnen etwas zu bieten und schlägt vor, welche Hauptschlüssel Sie verwenden sollen, um Ihr Leben zu vereinfachen und nichts zu verlieren.
  Zum Beispiel sind "Agile Testpraktiken" vorgefertigte Werkzeuge für die Anwendung, und "Werte" und "Prinzipien" sind das, was der Tester eines gesunden Menschen versteht, aber es lohnt sich immer noch, sie sich und Ihrem Team wiederholt zu sagen, weil ich aus Erfahrung weiß : Sie werden im Hochlastmodus häufig in den Hintergrund gedrängt.

  
  

• Die Hauptsache in der ATDD-Methodik ist, dass Sie, bevor Sie etwas tun, ein Kriterium für die geleistete Arbeit und ein Kriterium für die korrekte Arbeit erstellen müssen. Grob gesagt bestimmt der Ansatz den Zeitraum, in dem Sie dem Team zustimmen. Der Rest geht mit dem Stück einher.

  
  

Sie stellen beispielsweise fest, dass Sie unter Ihren Bedingungen die Integrationsschicht von Tests nicht unterscheiden können - das ist in Ordnung. Beginnen Sie mit den ersten Schritten des Ansatzes: Schreiben Sie die Akzeptanzkriterien auf, definieren Sie die Tests und ihre Ebenen und erstellen Sie eine Aufgabe für eine bessere Zukunft. Die nützlichste Phase hier ist die Definition von Überprüfungen im Voraus anhand Ihrer akribischen Fragen in der Phase der Aufgabenstellung - das schnellste positive Ergebnis, das Ihrem Team beweist, dass Sie keine Zeit verschwenden.

• Im Allgemeinen ergeben sich der agile Testansatz und die darin vorgeschlagenen Werte, Prinzipien und Praktiken aus ganz offensichtlichen Dingen, wie mein Lieblingslehrer für höhere Algebra sagte: „Aber hier müssen Sie den gesunden Menschenverstand anwenden.“ Dies lohnt sich nicht nur beim Testen.

Einmal, mitten in einer Diskussion, stellten das Team und ich fest, dass wir zu viele Bedingungen überprüft haben, und dies führte uns zu der Frage: "Rufen wir die Methode genau für diesen Parameter auf?" Es stellte sich heraus, dass die Formulierung des Problems grundlegend vereinfacht werden kann, indem die Essenz selbst und nicht die Logik über der Ebene davon genannt wird. Das heißt, die Bedingungen, unter denen wir eine abhängige Entität haben, aber es gibt keine Entität selbst, sie existiert nicht. Es hat uns das Leben leichter gemacht.

Durch die Bestimmung des Niveaus des Testfalls ist dies ein separater Holivar. Wenn Sie anfangen, Schmerzen zu spüren, versuchen Sie, die Literatur zu konsultieren. Und denken Sie daran, dass Übung dort angewendet werden muss, wo sie das Problem wirklich löst und das Leben erleichtert. Alles Gute, viel Glück und Robben!