Hallo Habr. Auf der letzten BackendConf sprach Anton Olievsky, unser Leiter der Abteilung für Softwaretests und Qualitätskontrolle, über das vielleicht wichtigste - eine bewusste Einstellung zur Arbeit.
Hier ist das Ding. Die Geschwindigkeit der Umsetzung von Geschäftsideen ist zu einem Schlüsselfaktor geworden. Diese Geschwindigkeit in SJ wird durch die durchschnittliche Zeit geschätzt, die zum Ausführen der Aufgabe benötigt wird. In der Firma betrug diese Zeit 65 Tage. Ja, 2 Monate vom Erstellen einer Aufgabe bis zum Senden an den Benutzer.
Anton sagt, dass sie die Prozesse dank bewusster Tests um das Dreifache beschleunigen konnten. Jetzt werden wir Ihnen sagen, was es ist und wie genau.
Wie war es vorher?
Der Prozess war wie folgt:
- 5 Tester für 40 Entwickler;
- Jede Aufgabe wird separat getestet.
- Abgeschlossene Aufgaben werden in den Release-Zweig integriert.
- Bei der Freigabe werden Abnahmetests durchgeführt.
Dann Integration.
Wenn das Ergebnis erfolgreich war, wurde die Version an die Benutzer gesendet, und 50 bis 60 Aufgaben, die auf Tests warteten, hingen ständig an der Tafel.
Wie haben Sie mit der Aufgabe gearbeitet:
- Von der Entwicklung an wurde die Aufgabe getestet und ging in der bodenlosen Liste der anderen Wartenden verloren.
- In der Liste konnte sie von ein paar Tagen bis zu einem Monat durchhängen;
- Dann wurde die Aufgabe vom Tester überprüft, es wurden Fehler gemacht und sie wurde an die Entwicklung zurückgeschickt.
- Der Programmierer hat Fehler behoben und die Aufgabe erneut für einen Test zurückgegeben.
Der Zyklus wurde wiederholt und die Aufgabe konnte in der Testphase mehrere Monate lang einfrieren. Aus technischer Sicht war alles in Ordnung, nur Funktionen wurden langsam veröffentlicht und das Geschäft war unglücklich. Die Tester hörten ständig zu, dass die Entwicklung sehr langsam voranschreitet, die Fristen brechen und das Geschäft Geld verliert.
Wie alle normalen Tester lasen die Jungs intelligente Bücher über Tests und dachten, dass die Hauptsache die Qualität des Produkts ist. Sie müssen so viele Fehler wie möglich finden und sie alle beheben. Aber nein.
Warum nicht?
Da wir keine Fehler beheben müssen, sondern dem Geschäft helfen müssen, ging Anton zum Produkt Dima, um sich mit der Situation zu befassen. Dort entschieden sie, dass die Hauptsache die Geschwindigkeit der Veröffentlichung von Funktionen ist. Tatsache ist, dass Unternehmen nicht gerne Geld für die Entwicklung und Reparatur von Projekten verlieren, was unklar ist, ob dies Vorteile bringt. Daher ist es besser, ein unvollkommenes Projekt freizugeben und anhand der Ergebnisse seines Erfolgs zu entscheiden, ob es zum Ideal gebracht oder minimiert werden soll. Die Tester versammelten sich und versuchten zu verstehen, wie die Release-Geschwindigkeit erhöht werden kann. Es stellte sich heraus, dass alles offensichtlich ist.
SJ hat eine Akzeptanz (eine Reihe von Fällen in den Hauptfunktionsbereichen für die Überprüfung des gesamten Produkts, z. B. Benutzerautorisierung, Stellenvermittlung usw.), die aus 150 Fällen besteht und 1,5 Tage vom Tester dauert. Es ist zu lang
Im Ernst, dies sind ungefähr 1,5 Tage manuelle Überprüfungen zweimal pro Woche. Was ist mit wiederholten manuellen Überprüfungen zu tun? Automatisieren.
Es stellte sich heraus, dass 100 Fälle automatisiert wurden. Unrentable Fälle für das Teilen über Automatisierung, das Senden von Briefen und das Empfangen von SMS blieben unrentabel. Die Tester waren begeistert, da weniger regelmäßige Kosten für das Testen von Releases anfielen - 3 Stunden statt 1,5 Tage. Zweitens geben Autotests ein schnelles Feedback darüber, ob eine Veröffentlichung überhaupt angesehen werden soll, und ermöglichen das Abfangen von Fehlern, noch bevor eine Aufgabe in eine Veröffentlichung aufgenommen wird.
Fast alles war entschieden, aber dann kam CTO.
Was ist sonst noch falsch?
Er kam und sagte, dass wir sehen müssen, wohin die Überdosis Arbeitszeit noch geht. Die Jungs saßen da und erkannten, dass die sich wiederholenden Aktionen nur bei Veröffentlichungen stattfanden - es war Akzeptanz und Integration.
Was ist mit Integration? Kurz gesagt, es gab eine Situation, in der sie eine Veröffentlichung schickten und Dims Produkt empört davonlief, dass die versprochene Aufgabe nicht in den Kampf kam. Sie begannen herauszufinden, wohin sie gegangen war. Es stellte sich heraus, dass beim Halten von Aufgaben im Release-Zweig ein Commit verloren ging und die Aufgabe für Benutzer visuell verloren ging.
Devops begann, Build-Skripte zu reparieren, und Tester überprüften die Fälle für jede Aufgabe in der Version noch einmal, um sicherzustellen, dass alles zusammenpasste und alle Aufgaben vorhanden waren. Es scheint so schwierig zu sein, die Aufgaben zu überprüfen, die bereits ausgesehen haben. Es stellte sich jedoch heraus, dass es in der Version ungefähr 5 Aufgaben für jeden Tester gab und komplexe Fälle auftraten, z. B. das Ändern von Daten in der Datenbank, das Ausführen eines Skripts und das Überprüfen des empfangenen Briefes. Diese gesamte Etappe hat viel Zeit in Anspruch genommen: 2 bis 10 Stunden Arbeit aller Tester.
Die Jungs haben mehrere Monate lang Statistiken über diese Übung erstellt und es stellte sich heraus, dass es keine Fälle mehr mit einem schlechten Build der Veröffentlichung gab und zu diesem Zeitpunkt nur ein paar Mal unkritische Fehler, die beim Testen der Aufgaben übersehen wurden. Wog alle Vor- und Nachteile ab und beschloss, diese Phase aufzugeben.
Jetzt ok?
Nicht in Ordnung. In der IT-Welt kann man nicht lange Erfolg haben, weil es immer etwas zu verbessern gibt. In unserem Fall waren dies 2 Mal pro Woche Veröffentlichungen. Zum Beispiel haben Tester die Aufgabe am Mittwochmorgen überprüft und zur Freigabe gesendet, und sie wird erst am Dienstag nächster Woche an den Benutzer gesendet.
Was sonst? Zu viele Hotfixes aus dem Geschäft. Das Unternehmen hatte geplant, ein Feature für einen bestimmten Zeitpunkt zu veröffentlichen, es anzukündigen und eine Werbung zu starten. Die Tester waren: "Wurf, schwul, wir haben hier Veröffentlichungen geplant und die Aufgabe wird erst nächste Woche eingeführt." Daher griff das Produkt Dima für jede dieser Aufgaben auf sie zurück.
Und jeder weiß, wenn Dima in die Entwicklung kommt, dann warte auf das Dringende. Solche Überfälle haben die Entwickler und Tester satt. Ist das nicht ein Grund, wieder in den Besprechungsraum zu gehen ?! Sie alle haben sich zusammengeschlossen und entschieden, dass das Unternehmen häufiger veröffentlicht werden muss. Sie müssen also noch mehr automatisieren, die Version in drei Stunden überprüfen, den täglichen Build der Version automatisieren und den Start von Autotests für die Version konfigurieren und die Akzeptanz jeden Tag durchführen.
Dies war ein kleiner Sieg, da die Funktionen nach dem Testen des Maximums am nächsten Tag nicht mehr verfügbar sind. Es gab weniger Probleme mit Hotfixes, einige wurden an die aktuelle Version gesendet und einige warteten auf die morgige Veröffentlichung. Dies ermöglichte es den Testern, sich von diesen Überprüfungen nicht ablenken zu lassen und Zeit zum Testen neuer Aufgaben zu gewinnen. Die Statistiken über verpasste Bugs sind übrigens unverändert geblieben.
Dann kam die Testerin Julia zu Anton und sagte, dass sie es satt habe. Mach gerne, was du willst, aber sie kann nicht mehr jeden Tag eine Akzeptanz durchführen, da sich gemäß der Hauptfunktionalität selten etwas ändert und es keine Fehler findet. Deshalb bot Julia an, einmal pro Woche eine Annahme durchzuführen.
Okay, Schwule.
Und wie ist es
Sparen Sie Zeit - 12 Stunden pro Woche, um neue Aufgaben zu testen, weniger Demotivation bei monotonen Überprüfungen. Von den Minuspunkten können Bugs bis zu 5 Tage ab dem Datum des Auftretens leben. Es wurde viel getan, um zu beschleunigen, aber gleichzeitig hatten die Jungs wenig Einfluss auf das Wichtigste - die durchschnittliche Zeit, die für die Ausführung einer Produktionsaufgabe benötigt wurde.
Sie näherten sich dem Ziel, erreichten es aber nicht. Ja, Tester konnten ihre Zeit neuen Aufgaben widmen, aber für die Geschwindigkeit des Durchgangs war es ein Tropfen auf den heißen Stein.
Anton ging, um zu überlegen, welche Aufgaben getestet werden, und erkannte, dass fast alles. Und der Strom ist riesig, wie der Marianengraben, sodass es unmöglich ist, alles zu verarbeiten. Daher wurde beschlossen, Prioritäten zu setzen. Zu diesem Zeitpunkt half Produkt Dima, das zusammen mit Anton alles überprüfte, was für das Geschäft unwichtig war.
Es blieben nur Punkte übrig, die in direktem Zusammenhang mit Geld und kritischen Dingen für die Benutzer standen.
Kurz gesagt, von einer Liste mit 300 Artikeln sind nur noch 50 übrig.
Damit können Sie bereits arbeiten. Welche Boni gibt die Webentwicklung übrigens?
- Die Fähigkeit, schnell auf im Kampf gefundene Fehler zu reagieren;
- Online-Überwachung von Problemen;
- Technischer Support in Kontakt mit Benutzern.
Nun das Wichtigste. Ja, in Testbüchern lernen Sie, wie man alles testet, aber alle Umstände sagten Anton, dass nicht alles getestet werden muss. Laut Anton fühlte er sich in diesen drei Tagen des Nachdenkens wie Hamlet mit seiner Frage "Sein oder Nichtsein".
Er sammelte seinen ganzen Willen zur Faust und entschied, was er sein sollte. Und er weigerte sich, unwichtige Funktionen zu testen. Die Tester begannen, diese 250 Punkte nach der Entwicklung sofort in die Veröffentlichung zu integrieren. Im Ernst.
Nicht jedes Unternehmen würde einem solchen Schritt zustimmen, und fast alle Tester, die sich weigerten, zu testen, verletzten das Gerücht. Diese Entscheidung ermöglichte es jedoch, sich auf das wirklich Wichtige zu konzentrieren.
Das Nicht-Testen ist ein verantwortungsbewusster und gefährlicher Schritt.
Wenn Sie dies auch tun möchten:- Die Liste der kritischen Funktionen ist öffentlich verfügbar, damit Entwickler darauf zugreifen können.
- Um den neuen Ansatz zu bewerten, fügen Sie Jira die Beziehung "generiert in => gespawnt" hinzu. So können Sie verfolgen, wie viele Fehler bei nicht testbaren Aufgaben auftreten.
- Da es nicht sehr dumm ist, die meisten Aufgaben zu testen, überprüfen Sie einige Hauptfälle in ihnen, aber in der Freigabe, um das Gießen nicht zu verlangsamen.
- Kritische Funktionalität zum Testen nach dem alten Schema.
Was wird sich ändern?- Die meisten Aufgaben werden während der Testphase nicht mehr schleudern.
- Tester werden sich nur mit geschäftskritischen Aufgaben befassen.
- Das Wichtigste wird beim Testen schneller berücksichtigt, da das Unwichtige jetzt nicht mehr in das Board eingreift.
Was ist so schlimm?- Bei echten Benutzern treten mit größerer Wahrscheinlichkeit kleinere Fehler auf.
- Die Belastung des technischen Supports nimmt zu, da verpasste Fehler von Benutzern ausgehen.
War es verletzt?
Die Jungs haben alle beschriebenen Schritte innerhalb von sechs Monaten abgeschlossen. Ja, es tat weh, aber die Ausgabe war die folgende:
Die durchschnittliche Zeit für die Ausführung einer Aufgabe wurde auf 19 Tage reduziert und nimmt ständig ab.
Der Fluss der Testaufgaben wird reduziert. Die Tester bereiteten sich darauf vor, wichtige Funktionen parallel zur Entwicklung zu testen.
Produkt Dima ging nicht mehr zu Anton.
Anstelle von Schlussfolgerungen
Verwenden Sie unseren Ansatz nicht in der Medizin oder im Flugzeugbau. Testen Sie in Situationen, die nicht mit einem Lebensrisiko verbunden sind, Ihre Entscheidungen und Ansätze.
Glauben Sie Büchern nicht und hören Sie auf zu testen, um sie zu testen, einfach weil sie irgendwo geschrieben sind.
Fragen Sie sich, ob Sie die Erwartungen des Unternehmens erfüllen und ob jeder Punkt auf Ihrer To-Do-Liste wirklich nützlich ist.
SuperJob war bei dir. Bewusstsein für alle!