Sehen Sie sich das Video an, lesen Sie das Protokoll und schreiben Sie Ihre Meinung zu den geäußerten Fragen in den Kommentaren. Lassen Sie es uns gemeinsam herausfinden: sein oder nicht sein?
Diskussion Nummer eins
Timecodes
0:56 - Ist ein Test immer notwendig?
2:00 - Warum testen, wenn Sie Funktionen so schnell wie möglich auf den Markt bringen müssen?
3:24 - Ist es möglich, nur grundlegende Funktionen oder einen Teil der Anwendung zu testen?
5:29 - Kriterien zum Testen der Funktionalität
7:28 - Ab wann sollte ein Startup- oder Outsourcing-Unternehmen die Freigabe von Funktionen einstellen und Zeit mit dem Testen verschwenden
Das Treffen begann sofort mit einem heißen - mit Diskussionen. Deshalb werden wir die Teilnehmer in unserer Online-Diskussion vorstellen:
- Dmitry Voronin, leitender Ingenieur im Speed-Team (Avito).
- Yuri Chechetkin, mobiler Entwickler (Revolut)
- Dmitry Manko, Android-Entwickler (Citymobil)
- Nina Semkina, Senior Programmiererin (Yandex.Money)
- Vladimir Genovich, Hauptprogrammierer (Yandex.Money)
- Dmitry Zhakov, Tester (Yandex.Money)
Nina Semkina: Viele Leute sagen, dass Tests in Projekte eingeführt werden müssen ... Aber jeder versteht, dass es sehr teuer ist. Es ist sehr teuer, Entwicklern Zeit und viele Ressourcen zu widmen, um den gesamten Code mit Tests abzudecken. Müssen immer Tests durchgeführt werden?
Dmitry Manko: Was wirst du testen?
Nina Semkina: Android-Anwendung. Wann muss ich verstehen, dass 100% davon getestet werden müssen?
Dmitry Manko:Wenn der Markt nicht mit der Entstehung von Funktionen rechnet, kann das Testen aus Sicht der Entwicklung oder der Abdeckung vereinfacht oder vollständig vernachlässigt werden. Es hängt alles vom Produkt ab. Wenn wir einen Taschenrechner mit zwei Funktionen erstellen, haben wir höchstwahrscheinlich mehr als einmal eine Reihe von Testfällen durchlaufen. Somit können Tests weggelassen werden, die Anwendung kann schneller auf den Markt gebracht werden und die Markteinführungszeit kann verkürzt werden.
Nina Semkina:Wir haben immer ein Time-to-Market-Rennen, der Markt erfordert immer eine Reihe von Funktionen und wir können sie nicht verlangsamen. Insbesondere wenn es um ein gerade erst begonnenes Projekt geht, das sofort auf den Markt gebracht werden muss, haben wir keinen Namen, wir konkurrieren mit anderen Unternehmen. Was interessiert uns in diesem Moment am Testen? Wir müssen unsere Anwendung mit Funktionen versorgen und diese schneller entfernen, da sie sonst in 3 Wochen veraltet sind. Warum sie testen?
Dmitry Voronin:Tatsächlich beginnt die Entwicklungsgeschwindigkeit irgendwann von der Testabdeckung abzuhängen. Wenn ein Unternehmen beispielsweise architektonisch an einen Hauptbildschirm gebunden ist, auf dem sich alle Hauptfunktionen befinden, und dort viele, viele Male Änderungen vorgenommen werden, können Sie ohne Tests auch mit einer großen "Feature-Pipeline" langsamer dorthin gelangen. Sobald es Signale gibt, dass Sie häufig auf eine Regression zurückkommen, ist dies ein Grund, über die Tatsache nachzudenken, dass etwas mit der Beschichtung nicht stimmt und Sie keine reaktiven Maßnahmen ergreifen. Zum Beispiel bricht oft etwas, was bedeutet, dass dieser Ort nicht so getestet wird, wie er sollte.
Nina Semkina:Darf ich daraus schließen, dass Sie ständig nur die Grundfunktionen testen und die Funktionen "mit einem Punkt" verbinden müssen. Lassen Sie diese einzelnen Funktionen Fehler sein, aber vielleicht existieren sie heute und sie werden nicht morgen sein. Kann ich nur einen Teil der Anwendung testen?
Dmitry Manko: Ich würde eher sagen, dass die Schlüsselteile einen Test wert sind. Was ist aus geschäftlicher Sicht für dieses Produkt wichtig? Und wenn es Funktionen mit Fehlern gibt, befinden sie sich irgendwo separat und wirken sich nicht auf Gemeinsamkeiten aus. Schließen Sie sie idealerweise mit einem Fernbedienungsschalter. Und wenn Sie laut Analyse feststellen, dass es tatsächlich Fehler gibt und Benutzer sich beschweren, deaktivieren Sie diese Funktion.
Dmitry Voronin:Dima ging auf ein gutes Thema ein: Tests sind nicht das einzige Tool zur Qualitätskontrolle, über das ein Entwickler verfügt. Sie sollten immer daran denken, dass es neben Unit- und Integrationstests auch manuelle Tests gibt und überwachen sollte. Und es gibt Möglichkeiten, Ihre Änderungen einzuführen und zurückzusetzen. Wenn Sie über all diese Konstruktionspraktiken verfügen, können Sie im Prinzip einige Werkzeuge zugunsten anderer vernachlässigen, wenn die Geschwindigkeit davon profitiert. Im Allgemeinen wird es jedoch immer als gute Form angesehen, wenn der Entwickler eine Testkultur hat - dass es für ihn komfortabler und zuverlässiger ist, Änderungen zu liefern, damit er die Funktionalität getestet hat, die er ausführen sollte. In unserem Unternehmen ist es üblich, einen solchen Code zu hinterlassen, in dem Sie dann problemlos Änderungen vornehmen und schnell Tests durchführen können, um zu verstehen, dass Sie nicht das verdorben haben, was bereits geschehen ist.
Nina Semkina: Im Chat schreiben sie, dass Sie testen müssen, was Einkommen bringt. Und wenn die Testkosten geringer sind als mögliche Verluste durch nicht funktionierende Funktionen. Im Prinzip ist dies ein gutes Kriterium, um zu verstehen, was genau getestet werden muss. Können Sie andere Kriterien zum Testen bestimmter Funktionen nennen?
Dmitry Manko: Die Kriterien können mithilfe von Analysen identifiziert werden. Wenn Sie beispielsweise die am häufigsten verwendeten Funktionen korrigieren, ist es auch ratsam, sie zu testen, damit Benutzer so wenig wie möglich auf Fehler stoßen. Wenn die Fehler an seltenen Stellen auftreten, ist dies ein kleines Problem. Und wenn das Verbot auf dem Autorisierungsbildschirm angezeigt wird, ist es möglicherweise nicht kritisch, aber dennoch ein Fehler, den jeder sehen wird. Und das ist schon ein Reputationsrisiko.
Dmitry Zhakov:Tests im Allgemeinen sind im Allgemeinen erforderlich. Wir dürfen nicht vergessen, dass das Testen eine Überprüfung der Anforderungen ist, die wir an ein Produkt stellen. Wenn etwas nicht den Anforderungen entspricht, ist dies ein Problem, ein Fehler oder ein Problem. Alle Testfälle und Tests können automatisiert werden. Wenn nicht genügend Zeit vorhanden ist, lohnt es sich, zuerst die kritischen Momente und dann alles andere zu überprüfen. Wenn Sie beispielsweise morgen eine Version haben und Ihr Unternehmen morgen eine Funktion wünscht, überprüfen Sie die wichtigsten Funktionen. Und wenn Sie genug Zeit haben, können Sie es sich leisten, mittlere und niedrige Fälle zu überprüfen. Es geht eher darum, ob Ihre Tests manuell oder automatisiert durchgeführt werden. Ob es sich um Metriken oder UI-Tests handelt, die von einem Roboter vollständig überprüft werden können.
Nina Semkina:Wir sprechen jetzt alle für große Unternehmen mit vielen Ressourcen und Möglichkeiten. Und wenn wir den Standpunkt kleiner Unternehmen betrachten, Startups, die nur über begrenzte Zeit und Ressourcen verfügen. Ich denke, dass zuerst jeder dort Tests opfern wird. Ab wann können wir verstehen, dass dies der entscheidende Meilenstein ist, wenn wir die fortlaufenden Funktionen stoppen und stoppen und Ressourcen für Tests ausgeben sollten?
Dmitry Manko:Ich kann meine Meinung teilen, da ich von einem Outsourcing-Unternehmen komme. Beim Outsourcing geht es in erster Linie darum, wo Arbeitsstunden verkauft werden, und das Testen ist dort sehr teuer. Manchmal kostet es mehr als die Entwicklung der Funktionalität selbst. Solche Outsourcing-Unternehmen sind nicht für Tests bekannt, wenn der Kunde auf die Anwendung wartet und sie "an die Seite tritt". In unserem Team sind wir mit der folgenden Situation konfrontiert. Das Produkt ist ein Menü für Bars, in denen Werbeaktionen für eine Vielzahl von Fällen verwendet wurden (Geburtstag, 2 für 1, Schüler usw.). Und wir haben festgestellt, dass diese Aktienfunktionalität ein Jahr lang jeden Monat unterbrochen wurde. Und dann haben Unit-Tests im Idealfall alle Fälle beschrieben. Wir haben verstanden, wie alles funktioniert (es gab ungefähr 70 Testfälle). Wir haben dieses Produkt geschlagen, aber das wäre natürlich nicht überall möglich.
Yuri Chechetkin:Meine Erfahrung in der Arbeit in großen Unternehmen - Yandex, Alfa-Bank, Revolut - im Bereich Fintech, wo die Kritikalität eines Fehlers nur aus dem Rahmen fällt. Davon abgesehen habe ich Erfahrung in einem Startup, und selbst dort waren Tests absolut notwendig. Ich denke, es spielt keine Rolle, ob es sich um ein Startup handelt oder nicht, da der Entwickler für seinen Code verantwortlich sein muss und Tests eine Garantie dafür sind, dass dieser Code funktioniert. Ein Entwickler ist in erster Linie ein Ingenieur, der für das zu entwickelnde Produkt verantwortlich ist. Daher müssen Sie Tests nicht schreiben, weil Sie müssen, sondern weil sie Ihnen helfen sollten. Wenn dies Tests sind, die für die Show geschrieben wurden, kann dies die Entwicklung verlangsamen. Und wenn Sie Tests benötigen und diese selbst verstehen, müssen sie geschrieben werden. Wenn ein Entwickler Code schreibt und sicher ist, dass er ohne Tests funktioniert, ist dies ein Risiko und es ist seine Wahl. Aber ich denke immer nochdass der Entwickler dieses Risiko nicht eingehen und sich selbst abdecken und alles mit Tests abdecken sollte.
Nina Semkina: Also haben wir beschlossen, dass wir unseren Code irgendwie testen müssen. Wir werden dieses Thema genauer analysieren. Ich gebe jetzt Wladimir Genowitsch mit seinem Bericht das Wort .
Nummer zwei Diskussion
Timecodes
0:09 - Wie entferne ich die Regressionslast aus der Qualitätssicherung vor der Veröffentlichung? Haben Unternehmen eine Strategie zur Verbesserung der Anwendungsstabilität?
4:25 - Ist es sinnvoll, in UI-Tests Mocks oder gefälschte Objekte zu verwenden ?
8:05 - Testen an Benutzern: Ist dies akzeptabel oder nicht?
Nina Semkina: Während des Berichts haben wir im Chat eine Frage erhalten, und von ihm möchte ich unsere Diskussion fortsetzen. Wie entferne ich die Regressionslast aus der Qualitätssicherung vor der Veröffentlichung? Welche Praktiken wenden unsere Redner bei der Auswahl von Testorten an? Haben Unternehmen eine Strategie zur Verbesserung der Anwendungsstabilität und zur Auslagerung von QS-Spezialisten?
Dmitry Zhakov:Unsere Strategie ist, dass wir alles testen. Weil wir als Mitarbeiter vor Anwendern die letzte Grenze sind. Daher geben wir dem Kunden nur eine solche Anwendung, die immer und überall stabil funktioniert. Die Frage ist nur die Geschwindigkeit. Der manuelle Lauf hat anfangs lange gedauert - bis zu einer Woche. Dank der Automatisierung haben wir jedoch erreicht, dass die Veröffentlichung durchschnittlich 24 Stunden dauert. Wenn Sie Funktionen entwickeln, müssen Sie daher zustimmen, dass entweder Sie oder die Tester sofort Autotests schreiben. Einige mobile spezifische Fälle, die Sie nicht automatisieren können, müssen nur auf Regression überprüft werden, und der Roboter überprüft den Rest. Auf diese Weise werden Sie Tester entladen, sie werden an interessanteren Forschungsarbeiten beteiligt sein und Sie geben dem Roboter die gesamte Routine - das Klicken auf Skripte.
Yuri Chechetkin: Die meisten großen Unternehmen lehnen manuelle Tests zur Qualitätssicherung ab. Dies ist nicht gerade ein revolutionärer Weg, sondern ein Relikt der Vergangenheit. Und zum Beispiel wird in meinem Unternehmen, in dem ich jetzt arbeite, ein Wort wie Regression nicht einmal ausgesprochen. Wir haben überhaupt keine QS-Abteilung.
Vladimir Genovich: Sie haben es wahrscheinlich automatisiert?
Yuri Chechetkin: Nicht genau, er war erst in der Anfangsphase des Projekts und dann war er überhaupt weg.
Vladimir Genovich: Sie führen UI-Tests durch, richtig?
Yuri Chechetkin: Es gibt natürlich UI-Tests.
Vladimir Genovich: Und Unit-Tests? Das Ausführen dieser Tests bei Veröffentlichung ist also keine Regression?
Yuri Chechetkin:Ja, dies ist eine Regression, aber es gibt keine manuellen Tests, über die wir gewohnt sind. Und das ist ein ziemlich interessanter Ansatz. Es ernüchtert und verwandelt den Entwickler von einem "Kind", das Code schreibt und an Tester weitergibt, in einen reiferen und unabhängigeren Ingenieur, der für seinen eigenen Code verantwortlich ist. Was visuelle Dinge betrifft, kann die Überprüfung von einem Designer oder einer Bestellung durchgeführt werden. Und es gibt Dinge wie Screenshot-Tests - wie Facebook. So scheint es, dass Lebensmittelunternehmen jetzt auf Qualitätssicherung verzichten können. Und Tester selbst können interessantere Arbeit leisten. Natürlich sieht das Outsourcing etwas anders aus: Sie verkaufen Arbeitsstunden, und die Qualitätssicherung kann als zusätzlicher Service verkauft werden.
Dmitry Zhakov:Es stellt sich heraus, dass Sie eine Regression haben, diese einfach der Automatisierung übergeben wird und Sie Mitarbeiter haben, die mit der Recherche Ihrer Anwendung befasst sind. Das Testen kann nicht nur die Benutzeroberfläche sein, sondern auch anders.
Yuri Chechetkin: Ja, zum Beispiel beim Testen von Benutzern.
Nina Semkina: Bevor wir dieses sehr gefährliche Thema ansprechen , möchte ich die nächste Frage unserer Zuhörer lesen. Ist es sinnvoll, in UI-Tests Mocks oder gefälschte Objekte zu verwenden?
Dmitry Voronin:Es macht Sinn und ohne sie nirgendwo. Weil vollständig integrierte UI-Tests eine sehr unzuverlässige Sache sind. Und Sie können sich niemals auf einen Test mit 30 Systemen verlassen, bei denen jeweils eine Reihe von Fehlerquellen eine Pull-Anforderung ausführen. Solche Tests sind nicht durchführbar. Und niemand in einem Unternehmen konnte solche Dinge zum Laufen bringen. Daher sind UI-Tests der Fluch der mobilen Entwicklung. Wenn möglich, ist es besser, ohne Benutzeroberfläche zu testen. Aber aufgrund der Tatsache, dass wir gezwungen sind, mit einem Framework zu leben, und die einzige Alternative eine Art Robotik ist, und in iOS ist dies auch nicht der Fall. Und um die Interaktion mit mindestens einem der für uns wichtigen Systeme zu überprüfen, führen wir alles auf dem Gerät aus. Die Benutzeroberfläche ist insofern hier, als wir aufgrund unserer Unreife in der Entwicklung das Maximum erfassen möchten, um zu überprüfen, wie der Benutzer klickt - wir sind so ruhiger. Es scheint mir,dass dies nach einiger Zeit der Vergangenheit angehören wird und wir keine Angst mehr vor Verspottungen und Klicks haben werden und nicht gegen das System kämpfen werden, um alles so zu überprüfen, wie es sollte, weil wir sowieso nicht alles überprüfen werden. Möglicherweise gibt es visuelle Fehler, die von keinen UI-Tests überprüft werden. Daher glaube ich, dass Verspottungen in UI-Tests durchgeführt werden können und sollten, und das Hauptziel ist es, die Stabilität dieses Tools zu erhöhen, um es in einen Zustand zu bringen, in dem es nützlich ist. Der eigentliche Vorteil in diesem Fall besteht darin, sicherzustellen, dass es keine Regressionen gibt. Und jedes Instrument, das spült, wird zum zweiten "D" aus dem vorherigen Bericht von Vladimir Genovich, wenn wir aufhören zu vertrauen. Dies geschieht, wenn eine große Anzahl von Zufallswerten in unserem Test eintrifft. Und ein solcher Test gibt kein Selbstvertrauen, sondern nur falsche Hoffnung, dass etwas getestet wurde.
Dmitry Zhakov: Ungefähr 70% unserer Fälle sind automatisiert und sie verwenden kein einziges Modell in der Anwendung. Es ist möglicherweise einfacher, sie in das Backend zu migrieren. Wenn es sich beispielsweise um eine Kartennummer handelt, würden Sie erwarten, dass 3DS nicht von Ihnen angefordert wird. Das heißt, die Anwendung weiß nicht, dass sie gesperrt ist. Ich denke, das ist ein Infrastrukturproblem.
Nina Semkina: Bevor wir zum nächsten Bericht übergehen , möchte ich, dass wir ein schlüpfriges Thema erwähnen - Benutzertests. Viele sündigen dies: Sie wollen und spritzen immer ... Was denkst du darüber? Ist es möglich, es sich zu leisten, schlauen Benutzern die Möglichkeit zu geben, Abstürze von ihnen zu sammeln und selbst zu beheben? Und nachdem Sie sie getestet haben, rollen Sie gute vollwertige Versionen aus. Oder ist es generell unzulässig? Oder gibt es vernünftige Grenzen?
Yuri Chechetkin:Wir bei Revolut üben dies ein wenig in dem Sinne, dass es nicht direkt in die Schlacht geht, sondern an echten Benutzern. Die Demo ist auch ein Test für Benutzer, und während der Demo stellen sich Fragen zum Ablauf und so weiter. In dieser Phase können Fragen zum Design und zur allgemeinen Mechanik auftreten. Unter anderem gibt es internes Rolling - das Unternehmen ist groß, mehr als 1000 Mitarbeiter, und wir können unter Kollegen rollen. Dies ist ein Benutzertest, jedoch nicht extern, und scheint sicher zu sein. Und dann kann es für einen kleinen Prozentsatz realer Benutzer außerhalb bereitgestellt werden, jedoch mit der Möglichkeit, diese Funktion mit einem Umschalter zu schließen. Was könnte in diesen Phasen Ihrer Meinung nach schief gehen?
Dmitry Manko:In unserer Realität können Dinge schief gehen. Egal wie sehr wir uns bemühen, diese Phasen gut durchzuführen, in jedem Fall springen die Fälle, wenn wir die Crash-Analyse überwachen müssen. Die Veröffentlichung endet nicht damit, dass wir sie an den Laden geschickt haben, alle Phasen sind vorbei, bei uns ist alles in Ordnung. Sie müssen weiterhin beobachten, wie sich die Anwendung verhält.
Yuri Chechetkin: Auf jeden Fall ja. In unserem Fall haben wir eine Demo, einen internen Rollout und Tests für 5% der Benutzer anstelle von manuellen Tests. Natürlich müssen Sie nach der Veröffentlichung der Funktion nachsehen. Das Rollen sollte nicht sofort 100% sein - dies ist der Hauptverteidigungsmechanismus.
Dmitry Voronin:Das ethische Problem der Nutzertests wird von Google für uns behandelt. Apple scheint das nicht zu haben. Wie Sie wissen, gibt es spezielle Vertriebskanäle (Alpha, Beta ... Produktion). Jeder kann an Betatests teilnehmen und stimmt einem verständlichen Formular zu, das besagt, dass er sich durchaus einig ist, dass er möglicherweise eine instabile Version des Produkts erhält. Deshalb möchte er sich freiwillig melden und dem Unternehmen helfen, das Produkt besser zu machen. Sobald wir einer Person offen davon erzählen, denke ich, dass dieses Problem behoben werden sollte und wir keine Angst haben sollten, eine Version herauszubringen, in der wir uns nicht 100% sicher sind. Und es ist noch besser, wenn wir Feedback von dort haben, und mit jeder solchen instabilen Version verbessern wir diesen Prozess. Wenn ein Unternehmen über Prozesse verfügt, die Qualitätstrends in der Beta verfolgen, sollten die Dinge nur besser werden.Dies ist auch ein Plus für Benutzer - sie erhalten als erste Funktionen. Dies sind meist motivierte und treue Benutzer Ihres Produkts, und sie selbst möchten neue Dinge testen, die in der Anwendung erscheinen. Und sie werden sogar bereit sein, etwas dafür zu opfern.
Nina Semkina: Wir verstehen, dass ein loyales Publikum loyal ist, solange es seine persönlichen Interessen nicht berührt. Auf diese Weise können wir Funktionen mit zusätzlichen kleinen Brötchen ausrollen. Selbst wenn diese fallen, sind diese Benutzer nicht sehr verärgert. Aber selbst wenn diese Person bestätigt, dass sie bereit ist, die Testversion zu nehmen, aber etwas Ernstes mit ihr schief geht (zum Beispiel wird zusätzliches Geld abgeschrieben), wird sie nicht länger loyal sein. Und je größer das Unternehmen, desto härter reagiert der Benutzer auf das Produkt.
Vladimir Genovich:Aber was ist mit dem Early Adopter, der Sie liebt, egal wie das Unternehmen es vermasselt? Und höchstwahrscheinlich wird dieses Unternehmen in der Lage sein, die Verluste auszugleichen. Stimmen Sie zu, wenn wir etwas ausrollen, sagen wir dem Benutzer: „Hören Sie, wir haben große Angst. Und Sie können 1000 Rubel verlieren. Aber wir werden Sie erstatten. " Höchstwahrscheinlich wird ein solcher Benutzer dies auf eigene Gefahr und Gefahr tun, und wenn das Geld verloren geht, werden wir ihm später nicht sagen: "Nun, Sie selbst sind schuld." Daher denke ich, dass wir den Benutzern auch im Fall einer Bankanwendung helfen können.
Dmitry Zhakov:Und wenn Sie zu wenige Betatester haben, können Sie A / B-Tests mithilfe von Konfigurationsdateien verwenden, um einige Funktionen zu aktivieren / deaktivieren, sodass Sie im Falle eines Absturzes sofort etwas deaktivieren und bei Bedarf testen können. Wie wir uns erinnern, ist es sehr schwierig, ein Rollback in Mobilgeräten durchzuführen. Daher ist es besser, vor der Veröffentlichung alles auf das Maximum zu überprüfen.
Vladimir Genovich: Oder schreiben Sie in React Native))
Nina Semkina: Ich werde unser Gespräch unterbrechen, da die Zeit für den nächsten Bericht gekommen ist. Dima, ich gebe dir das Wort.
Nummer drei Diskussion
Timecodes
0:05 - Wie können Regressionstests verbessert werden? Wie und wann werden Tests in die Entwicklung von Funktionen eingeführt (Avitos Erfahrung) ?
10:43 - Wo jagen Unit-Tests: auf CI oder lokal, bevor sie gepusht werden?
Nina Semkina: Ich möchte Dima Voronin kontaktieren, um seine Meinung und seine Erfahrungen darüber zu erfahren, wie sie Regressionstests im Unternehmen verbessert haben und wann sie Tests bei der Entwicklung von Funktionen einführen.
Dmitry Voronin:Ich habe wirklich etwas zu teilen. Dies ist eine fünfjährige Geschichte des Umgangs mit manueller Regression. Und dies ist teilweise eine Fortsetzung der Antwort auf die Frage, die wir zwischen den ersten beiden Berichten hatten. In dieser Frage geht es darum, was zu tun ist, wenn Sie eine manuelle Regression haben. Weil nicht jeder die Revolut-Erfahrung wiederholen kann. Die Jungs sind großartig, sie haben sich von der Schulter geschnitten und es geschafft, es zuverlässig zu machen. Es erfordert viel Mut, eine gute Entwicklungskultur und vor allem das Verständnis für Entwicklungsleiter, die sich bei diesem Ansatz nicht wild fühlen. Dies geschieht, weil unsere Arbeit Trägheit aufweist und es schwierig sein kann, die Grundlagen zu ändern, insbesondere in großen Unternehmen. Das Revolut-Beispiel zeigt, dass es zumindest schneller als die manuelle Regression ist, wenn es funktioniert, und jeder Entwickler beginnt, sich die richtigen Fragen zu stellen.Das heißt, er beginnt, für den größten Teil des Veröffentlichungszyklus verantwortlich zu sein, dh erst, wenn er die Änderungen festlegt, aber wie jeder erwachsene Ingenieur führt er das Produkt auch in der Veröffentlichungsphase.
Was ist mit uns passiert? Wir waren an dem Punkt angelangt, an dem wir eine manuelle Regression hatten, die 12 Arbeitstage lang von 5 Personen durchgeführt wurde, und ohne die die mobile App nicht funktionieren würde. Es war 2015. Und zu diesem Zeitpunkt hatten wir keinen einzigen automatisierten UI-Test. Wir haben fast von Anfang an Unit-Tests geschrieben und ziemlich aktiv geschrieben. Vladimir sprach in seinem Bericht über 10 Sekunden und 1000 Tests - es ist beängstigend für mich, mir vorzustellen, wann wir 2014 einen solchen Moment verbracht haben. Jetzt haben wir 12.000 Unit-Tests, und sie dauern keine 10 Sekunden, dies ist auch kein kostenloses Stück. Obwohl alle Ingenieure Tests verstehen und schreiben, gab es einen schwierigen Moment. Alle diese Unit-Tests belegen kein einziges Gramm über Fehler in der Produktion und das Verhalten der Anwendung. Das heißt, das Testen erfasst das Verhalten, erleichtert das Vornehmen von Änderungen und gibt Feedback.machst du es richtig Das Problem ist, dass es eine QS-Abteilung gibt. Das ist natürlich nicht das Problem. Das Problem ist, dass sie die Aufgabe haben, ein bestimmtes Qualitätsniveau bereitzustellen. Und sie sind es gewohnt, dieses Niveau zu erreichen, sie übernehmen diese Verantwortung. Und es ist schwierig, diesen Moment zu drehen, wenn er nicht von Anfang an von Ihrem Produkt stammt. Welche Rezepte gibt es? Das Richtigste ist, den Hard-Modus nicht einzuschalten, wenn wir alle feuern und alles von der Automatisierung übernommen wird. Dies ist wahrscheinlich der gruseligste und unausgereifteste Ansatz, den ich je gesehen habe. Was stimmt damit nicht? Erstens geht die Qualität der Tests für einige Zeit verloren. Zweitens werden alle Prozesse zerstört und neue werden nicht schnell erstellt.Und sie sind es gewohnt, dieses Niveau zu erreichen, sie übernehmen diese Verantwortung. Und es ist schwierig, diesen Moment zu drehen, wenn er nicht von Anfang an von Ihrem Produkt stammt. Welche Rezepte gibt es? Das Richtigste ist, den Hard-Modus nicht einzuschalten, wenn wir alle feuern und alles von der Automatisierung übernommen wird. Dies ist wahrscheinlich der gruseligste und unausgereifteste Ansatz, den ich je gesehen habe. Was stimmt damit nicht? Erstens geht die Qualität der Tests für einige Zeit verloren. Zweitens werden alle Prozesse zerstört und neue werden nicht schnell erstellt.Und sie sind es gewohnt, dieses Niveau zu erreichen, sie übernehmen diese Verantwortung. Und es ist schwierig, diesen Moment zu drehen, wenn er nicht von Anfang an von Ihrem Produkt stammt. Welche Rezepte gibt es? Das Richtigste ist, den Hard-Modus nicht einzuschalten, wenn wir alle feuern und alles von der Automatisierung übernommen wird. Dies ist wahrscheinlich der gruseligste und unausgereifteste Ansatz, den ich je gesehen habe. Was stimmt damit nicht? Erstens geht die Qualität der Tests für einige Zeit verloren. Zweitens werden alle Prozesse zerstört und neue werden nicht schnell erstellt.Die Qualität der Tests geht für einige Zeit verloren. Zweitens werden alle Prozesse zerstört und neue werden nicht schnell erstellt.Die Qualität der Tests geht für einige Zeit verloren. Zweitens werden alle Prozesse zerstört und neue werden nicht schnell erstellt.
Was haben wir getan? Wir haben unsere Optimierung mit dem Schreiben von UI-Tests begonnen, die die Regression ersetzen. Das heißt, dies sind vollwertige Infrastrukturtests, die das Backend mit Testbenutzern berühren. Und tatsächlich war das Ergebnis dieser Arbeit, wie Sie wissen, alle möglichen populären Frameworks - zum Beispiel Kaspresso. Genau das haben wir gelegt, als wir angefangen haben. Wir haben eine Reihe von Artefakten zurückgelassen, die Entwicklern helfen können. Und so ist es jetzt einfacher, mit dem Testen zu beginnen. Wir haben auch verschiedene Läufer in Open Source aufgenommen, und jeder kann sehen, wie wir mit ihnen arbeiten. Wir haben jedoch nicht vergessen, manuell zu testen, zu optimieren und wie diese beiden Abteilungen zu einem effektiven Prozess verschmelzen. Wahrscheinlich ist Punkt B der Revolut-Zustand. Aber unser Weg von Punkt A nach Punkt B, wie viele andere Unternehmen,es dauert lange. Jetzt sind wir in der Phase, in der die Qualitätssicherung die Rolle der Forscher spielt, sie mehr in das Produkt eintauchen, an funktionalen Anforderungen arbeiten und Autotests schreiben.
Das Interessanteste an der Praxis der Verbesserung der manuellen Regression ist die Wirkungsanalyse. Das heißt, ein Versuch, die Frage zu beantworten: "Was hat sich in dieser Version geändert?" Und was können wir testen und was können wir beruhigt in die nächsten Phasen einführen? Die Auswirkungsanalyse ist eine schwierige Frage, denn wenn Sie einen großen Freigabezyklus haben, dh 2-3 Monate lang freigegeben sind, beantwortet die Auswirkungsanalyse Sie immer gleich, da in einer solchen Zeit kaum ein Teil der Anwendung berührt wurde. Wenn Sie diesen Veröffentlichungszyklus jedoch auf eine Woche oder noch besser auf einen Tag verkürzen, zeigt die Auswirkungsanalyse durchaus angemessene Dinge und hinterlässt Spuren, die zur Optimierung der manuellen Regression beitragen. Wir haben diese Praxis recht erfolgreich angewendet. Am Anfang gab es Fehler, aber wir haben die Anzahl der manuellen Tests einmal reduziert.
Die nächste Übung besteht darin, das Testmodell zu optimieren. Seltsamerweise, aber in Tests gibt es auch Legacy: Tests werden geschrieben, aber sie sind möglicherweise nicht sehr optimal, dann wurde dort etwas anderes hinzugefügt, und die Testfälle wurden dafür nicht verarbeitet ... Bei einer detaillierten Analyse stellte sich heraus, dass sie um ein Vielfaches reduziert werden können Anzahl der Testszenarien.
Diese drei Richtungen ermöglichten es uns, den Punkt zu erreichen, an dem wir es einmal am Tag für die Beta freigeben. Einmal pro Woche erreicht es 100% der Benutzer. Es gibt keine manuelle Regression. Ich hoffe, diese Geschichte wird die Unternehmen, die mit ihrem Veröffentlichungsstatus unzufrieden sind, zum Handeln motivieren - um in Zukunft nur noch den Freigabeknopf zu drücken, geht alles an die Benutzer, und jeder schaut nur auf die Charts.
Yuri Chechetkin:Dies sind natürlich nicht nur Revolut-Praktiken, sondern auch weltweit. Sie werden von Google, Facebook usw. verwendet. Ich stimme zu, dass dies ein reibungsloser Übergang sein sollte. Und wenn viele zu POs werden oder in die automatisierte Qualitätssicherung gehen, wird alles ein wenig verschwommen, entwickelt sich und verwandelt sich in etwas Gesagtes. Und in Russland fängt dieser Trend jedoch gerade erst an. Und wie Sie zu Recht sagten, sollte er so gesund wie möglich sein.
Nina Semkina: Es gab eine solche Frage. Wer hat Unit-Tests wo durchgeführt? Auf CI oder lokal vor dem Push?
Yuri Chechetkin: Es scheint, dass das Fahren vor Ort die Aufgabe des Entwicklers ist, das heißt, Sie sollten es nicht mit Gewalt tun. Mir ist klar, dass CI zu 100% vorhanden sein sollte.
Nina Semkina: Vielen Dank an alle Teilnehmer für die Diskussion! Ich gebe unserem Sprecher das WortDima Manko mit seinem Bericht.