Hallo an alle, mein Name ist Sergey. Ich teste das Yandex.Market-Frontend. Ich weiß, dass es unter den Lesern von Habr viele IT-Spezialisten gibt, die in irgendeiner Weise mit dem Freigabeprozess und dem Testen verbunden sind. Ich habe eine Frage an Sie. Ist es in Ihrer Praxis schon einmal vorgekommen, dass die Funktionen in der Produktion für längere Zeit nicht funktionieren? Kennen Sie aufgeblähte Freisetzungen und deren Volumenprüfungen?
Ich denke, jeder hatte das. Ich bin vor 3 Jahren zu Yandex gekommen, unser Team war sehr jung, die Prozesse waren nicht vollständig etabliert. Und ich bin diesen Problemen von Angesicht zu Angesicht begegnet.
Wie war
Zu diesem Zeitpunkt hatten unsere Produktteams keinen bestimmten Verantwortungsbereich und waren nur mit dem Projekt befasst, für das sie erstellt wurden. Dann fielen sie auseinander. Das Testen war auch nicht an Entwicklungsteams gebunden. Es bestand als Dienst und war bei Bedarf mit dem Projekt verbunden.
Die Aufgaben wurden nur von Hand überprüft, die Integrationstests waren instabil, der Prozentsatz der Abdeckung mit Autotests war gering. Die Überprüfung dauerte sehr lange. Der Pool kalkulierbarer Aufgaben wuchs stetig und konnte enorme Ausmaße erreichen.
Bei den Releases war einer der Manager mit der Montage und Berechnung beschäftigt. Wir haben mit allen Managern Gespräche geführt und entschieden, was in die nächste Version fällt und was verschoben werden könnte.
Sie überprüften die Veröffentlichungen nach dem Zufallsprinzip: Wer auch immer die Zeit hatte, sie zu überprüfen, überprüfte er. Der Schwerpunkt lag auf manuellen Regressionstests, die mehrere Tage dauern können. Und das trotz der Tatsache, dass die Veröffentlichung eine Reihe von Autotests lief und es eine Abteilung gab, die sie schrieb und unterstützte.
Das gelöste Problem wurde getestet und konnte bis zu 2 Tage lang getestet werden. Dann stieg sie in die Freilassung ein, es wurde noch 4 Tage nachgeprüft. Die Aufgabe stellte sich bestenfalls in einer Woche heraus. Wenigen gefiel es, es musste etwas geändert werden. Und das Wichtigste, was geändert werden muss, sind die Prozesse.
Kontur
Als erstes haben wir eine Unterteilung in Konturen eingeführt - Teams von Spezialisten aus verschiedenen Bereichen. Im Gegensatz zu früheren Teams brechen die Konturen nach Projektende nicht auf. Sie generieren weiterhin neue Projekte und Ideen in ihrem Verantwortungsbereich.
In jedem Stromkreis sind 1 bis 3 Tester für die Prüfung verantwortlich. Jeder verantwortliche Schaltungstester ist in allen Phasen der Produktentwicklung von der Idee bis zur Nachbesprechung anwesend.
Im Dienst
Um die Arbeit von Releases zu strukturieren, haben wir zwei Rollen in unserem Testteam eingeführt: einen Release-Assistenten und einen Release-Tester. Als Release-Master haben wir 4 Tester gleichzeitig im Dienst, jeder ist am Release-Dienst beteiligt. Für jede dieser Rollen haben wir einen Dienstplan erstellt.
Aufgaben, die während des Betriebs auftreten, haben Vorrang vor dem Testen von Produkteigenschaften in Schaltkreisen. Damit die Tester nicht lange ohne Unterbrechung warten müssen, ist der Freigabedienst wie folgt geregelt: Eine Schicht ist von Montag bis Mittwoch im Einsatz, die zweite - von Mittwoch bis Ende Freitag. In jeder Schicht - 4 Personen, 2 Personen pro Plattform.
Die Dokumentation
Und was ist mit der Dokumentation? Wir haben nicht so viel, aber es ist. Beim Rollout von Features ermitteln wir beispielsweise zusammen mit den Entwicklern und dem Manager die optimale Anzahl von Autotests. Wenn wir etwas nicht automatisieren können oder wenn ein Feature eine sofortige Veröffentlichung ohne Autotests erfordert, schreiben wir einen Fall in die Testsuite aller Marktüberprüfungsfälle und nehmen ihn gegebenenfalls in die Release-Testsuite der Regressionstests auf.
Wenn wir die Fehlerbehebungen überprüfen und feststellen, dass der Autotest nicht für den Fehler geschrieben wurde, stellen wir auch die Aufgabe, ihn zu entwickeln, und die Bearbeitung beginnt sofort mit dem darauf geschriebenen Test.
Bei der Zusammenstellung jedes Experiments haben wir eine Checkliste, da wir nicht im Voraus wissen, ob das Experiment erfolgreich sein wird.
Eine Checkliste besteht aus einer Reihe positiver Überprüfungen der Merkmale eines Experiments. Der Release-Tester verwendet es bei jedem Release, während das Experiment ausgeführt wird. Diese Checkliste kann auch für zukünftige Automatisierungsaufgaben leer sein, wenn das Experiment erfolgreich ist und wir sie an 100% der Benutzer ausrollen.
Bei der Überprüfung von Releases verwenden wir je nach Komplexität und Fülle des Releases verschiedene Testkits. Wir haben sowohl kleine Testsuiten als auch Suiten mit der maximalen Anzahl von Testfällen. Welche Testsuite verwendet werden soll, entscheidet der Release-Tester.
In einigen Bereichen verwenden wir auch die Checkliste der positiven Prüfungen für Entwickler. Damit kann der Entwickler die Aufgabe selbst überprüfen und Engpässe bei der Entwicklung von Features vorhersehen. Wenn der Tester im Projekt gewechselt hat, hilft dies dem neuen Spezialisten, sich dem Projekt schnell anzuschließen. Checklisten werden vor dem Beginn der Entwicklung unmittelbar nach der Planung der Aufgabe erstellt.
Das ist alles für die Docks.
Wie wir Aufgaben testen
Wir verwenden verschiedene Testdesign-Techniken: Äquivalenzklassen, Grenzwerte, paarweises Testen, Benutzerszenarien. Das Fachwissen des Testers ist ebenfalls sehr wichtig. Der Markt ist eine große Maschine, und Sie müssen wissen, wie alle ihre Teile funktionieren, um etwas zu reparieren oder zu verbessern. Zum Beispiel haben wir 4 Arten von Warenkarten und 6 Arten von Warenproblemen. Ohne dies zu wissen, ist es einfach unmöglich, die Aufgabe der Änderung dieser Seiten qualitativ zu testen.
Eine wichtige Rolle bei der Überprüfung von Aufgaben spielen Autotests. Wir führen für jede Aufgabe, die wir implementieren, funktionierende Autotests durch, analysieren Abstürze und melden Fehler.
In besonderen Fällen, wenn die Aufgabe viele Komponenten des Marktes betrifft, führen wir auch Bildschirmtests durch - sie helfen uns, Fehler zu erkennen.
Wenn die Aufgabenüberprüfung abgeschlossen ist, hinterlassen wir einen Kommentar, dass alles in Ordnung ist und die Aufgabe freigegeben werden kann. Im Kommentar geben wir an, wie viele Tests geschrieben wurden, oder wir sagen, dass keine Tests erforderlich sind, und wir übersetzen die Aufgabe in den Status "ausstehende Freigabe".
Anschließend wird die Aufgabe vom Freigabeassistenten übernommen und zusammen mit anderen bewährten Aufgaben an die Freigabe gesendet. Wir versuchen, Releases mit Aufgaben zu füllen, damit diese innerhalb von 8 Stunden von 4 Testern überprüft werden können: 2 für die Touch-Version des Market und 2 für die Desktop-Version. Unser Ziel ist es, mindestens 5 Releases herauszubringen. Das heißt, die Geschwindigkeit, mit der die Aufgabe an das Produkt übergeben wird, hat sich im Vergleich zu ihrer ursprünglichen Geschwindigkeit um das Fünffache erhöht.
So prüfen wir Releases
Wir beginnen die Freigabe zu überprüfen, indem wir die automatischen Tests und Bildschirmtests überprüfen. Nachdem wir uns die Berichte angesehen haben, können wir sofort bis zu 90% der Probleme beheben. Wir analysieren den Absturz von Tests: Wenn sie auf einen Fehler zurückzuführen sind oder durch ein Ticket in der Version beschädigt wurden, suchen wir nach der Aufgabe, in der dieser Absturz reproduziert wird, und fordern eine Reparatur an. Wenn dies nicht getan wird, fällt die Aufgabe nicht in die Freigabe.
Tests können auch von selbst sterben. In diesem Fall deaktivieren wir den Test vom Autotest-Lauf und starten die Aufgabe, ihn zu reparieren und gegebenenfalls den Mox zu erstellen.
Abhängig von den Aufgaben in der Version können wir das vollständige Release-Testkit verwenden oder die manuelle Regression vollständig ablehnen. Die Entscheidung treffen die Release-Tester.
Wenn die Version mehrere kleine Änderungen enthält, wird die Aufgabenüberprüfung lokal durchgeführt und die manuelle Regression durch die Überprüfung der automatischen Testberichte ersetzt.
Unabhängig von der Vollständigkeit der Freigabe und der Aufgaben überprüft das Team der Freigabeprüfer die Experimente, die derzeit für verschiedene Prozentsätze der Benutzer in der Produktion gezeigt werden. Es wird eine von einem Testgerät erstellte Checkliste verwendet.
Wenn alle Überprüfungen abgeschlossen sind, hinterlässt der Release-Tester einen Kommentar, in dem er alle Release-Aktivitäten auflistet und gegebenenfalls Aufgaben zur Behebung fehlerhafter Tests schreibt.
Der Freigabestamm analysiert die Feuermeldungen (Lasttests) und startet sie neu, wenn er einen Anstieg der Fehler feststellt. Wenn dies nicht hilft, sucht er den Täter oder bittet den diensthabenden Entwickler um Hilfe.
Wenn mit den Aufnahmeergebnissen alles in Ordnung ist, öffnet der Veröffentlichungsassistent die Charts des Marktes und beginnt mit der Einführung der Veröffentlichung in die Produktion. Sie müssen den Diagrammen folgen, um das Anwachsen von Fehlern nicht zu verpassen.
Wenn das Release für das Anwachsen von Fehlern verantwortlich ist, wird es vom Release-Master zurückgesetzt, und die Gründe werden verstanden. Wenn die Zeitpläne normal sind, schließt er die Freigabe ab und beginnt, einen neuen von vorgefertigten Aufgaben zu sammeln.
Streben nach dem Besten
Trotz der Tatsache, dass alles gut funktioniert, sollten Sie immer das Beste anstreben. Wir stehen kurz vor einer besseren kontinuierlichen Lieferung, bei der Aufgaben parallel und ohne Zwischenstufe in Form einer Freigabe in der Produktion getestet und ausgerollt werden. Auf diese Weise können Sie sich bei Veröffentlichungen nicht von der Überwachung ablenken lassen und die Bereitstellung von Funktionen für Benutzer erheblich beschleunigen.
Wir beschlossen, schrittweise auf CD umzusteigen. Der erste Schritt war die Einführung eines Monorepositorys, bei dem die Funktionalität für beide Plattformen - Touch und Desktop - in einer Version bereitgestellt wird. Dieser Ansatz hat sowohl für die Entwicklung als auch für das Testen Vorteile. Wir verbringen viel weniger Zeit mit dem Testen der Komponente. Aufgaben sind jetzt an einem Ort, was die Navigation erleichtert. Für den Manager ist die Navigation einfacher, da er den genauen Zeitpunkt für das Ausrollen der Freigabeaufgabe im Produkt kennt und kein Spiel zwischen dem Ausrollen der Plattformen besteht.
Der nächste Schritt zur CD ist die Einführung der „grünen Wunde“. Für jedes vom Tester überprüfte Ticket werden zwei Testtypen für beide Plattformen gestartet: Funktionstests und Bildschirmtests. Alle Tests müssen Moki haben. Wenn die Tests für eine der Plattformen fehlschlagen, wird die Aufgabe nicht als verifiziert betrachtet. Wenn der Test abstürzt, müssen Sie verstehen, warum dies passiert ist. Nur wenn keine Falltests vorliegen und alle Überprüfungen erfolgreich abgeschlossen wurden, wird die Aufgabe an das Produkt gesendet.
Vielen Dank für Ihre Aufmerksamkeit. Ich hoffe, unsere Erfahrung hat Ihnen geholfen, ich warte in den Kommentaren auf Sie.