Get best of the week

Denken Autotests an elektrische Fehler?

In jüngster Zeit wurde die Testautomatisierung aufgrund aller Probleme des Projekts als "Silberkugel" bezeichnet. Viele Menschen beginnen die Automatisierung sehr spontan und leichtfertig, ohne alle Vor- und Nachteile, Vor- und Nachteile, Wartung und Amortisation zu berechnen. 

Im Allgemeinen ist die Testautomatisierung ein sehr teures und spezifisches Werkzeug. Daher muss mit dem richtigen Reifegrad des Codes und des Projekts selbst angegangen werden. Andernfalls können Sie Millionen von Stunden und Geld ausgeben, und der Effekt ist mikroskopisch oder überhaupt nicht.

In diesem Artikel habe ich versucht:

  • die "Wunden der Kinder" des Testmanagements zu beleuchten und alles zu automatisieren, was nicht fixiert ist,
  • Erläutern Sie, wie die Testautomatisierung dem Projektbudget zugute kommen kann, ohne den Umfang und die ordnungsgemäße Vorbereitung detailliert zu analysieren.
  • Erstellen Sie eine Roadmap, um sich auf die Projektautomatisierung vorzubereiten.

Quelle 

Der Trend geht dahin, dass jetzt in allen Projekten Automatisierungsstopfenlöcher getestet werden, wobei Nägel tatsächlich mit einem Mikroskop genagelt werden. Es kommt zu dem Punkt, dass es für einen Tester ohne Automatisierungsfähigkeiten schwierig wird, einen Job zu finden, weil In den meisten offenen Stellen fehlen Kenntnisse in Testanalyse und Testdesign, aber Erfahrung in der Automatisierung von etwas ist erforderlich.

Ich möchte glauben, dass wir alle im Laufe der Zeit den zwanghaften Wunsch haben werden, alles auf einmal zu automatisieren, aber im Moment würde uns eine Checkliste sehr helfen, festzustellen, ob Autotests im Projekt erforderlich sind und ob das Projekt für sie bereit ist. 

Mit diesen Gedanken machte ich eine Präsentation zu „Strike-2019“ und schrieb dann diesen Beitrag darauf basierend.

Wir werden über große, seriöse End-to-End-Autotests sprechen, die die Regression in Bezug auf Benutzeroberfläche und Webdienste automatisieren. Und auch was damit verbunden ist. Wir werden nicht auf das Thema Unit-Tests eingehen, die Entwickler schreiben oder schreiben sollten. Dies ist eine separate Ebene des Selbsttests, und viele Artikel wurden bereits darüber geschrieben:

 
Ich werde das Projekt nicht benennen, ich werde nur sagen, dass dies ein Informationssystem ist, das für mehrere zehn Millionen Benutzer entwickelt wurde. Es ist in mehrere staatliche Portale sowie in Dutzende, wenn nicht Hunderte von regionalen und kommerziellen Portalen integriert. Daher die gestiegenen Anforderungen an Zuverlässigkeit, Fehlertoleranz und Sicherheit. Nun, im Allgemeinen, damit sich alles "dreht und nicht fällt". 

Unser Credo bei allen LANIT-Testprojekten ist die kontinuierliche Verbesserung. Im Allgemeinen spart alles, was es uns ermöglicht, schneller, besser, höher und stärker zu testen, den Testern Zeit und Mühe und damit das Budget. Wir haben bei diesem Projekt wahrscheinlich alle Best Practices implementiert, die es uns ermöglicht haben, Termine und Aufgaben einzuhalten. Infolgedessen blieb von den großen nicht realisierten Chips nur die Regressionsautomatisierung übrig. Dieses Thema selbst lag lange Zeit in der Luft, und wir lehnten es lange Zeit ab und ruhten uns auf all unseren Gliedern aus, weil der Gewinn nicht sehr klar war. Aber am Ende entschieden sie sich für die Automatisierung. Und dann gab es einen längeren Sprung ins kalte Wasser.
 

Ein kleiner Exkurs. Automatisierungsmethoden


Es gibt zwei Möglichkeiten, das Testen der Benutzeroberfläche zu automatisieren. 

Quelle

Automatisierung durch Handprüfer


Für Beispiele muss man nicht weit gehen - alles ist auf Habré. Ich werde die Firma nicht nennen. Diejenigen, die sich für das Thema interessierten, sahen wahrscheinlich diese eineinhalbstündigen Webinare, wie cool sie sind, wie cool sie sind, wie das gesamte Team von Handheld-Testern Java von ihnen gelernt hat, automatisiert hat, alles abgedeckt ist, alles großartig ist, alles funktioniert, eine glänzende Zukunft ist bereits gekommen. Es gibt einen solchen Ansatz. 

Designansatz


Und es gibt einen zweiten Ansatz: Ein Team von Autotestern wird rekrutiert - mit Erfahrung, Wissen und Fähigkeiten in OOP, und die Automatisierung wird direkt von den Kräften dieses Teams durchgeführt, und ein Team von manuellen Testern fungiert als Kunden und Experten. Ja, sie können nach dem Training und der Auswahl in das Automatisierungsteam einfließen, aber sie kombinieren niemals zwei Rollen gleichzeitig.

Im Folgenden habe ich die Merkmale dieser Ansätze beschrieben, sie jedoch nicht speziell als „Pluspunkte“ oder „Minuspunkte“ gekennzeichnet - jeder wird das Vorzeichen für sich selbst bestimmen.

Merkmale der Automatisierung "auf eigene Faust"


Quelle

1) Wenn wir mit Hilfe von manuellen Testern automatisieren, erhalten wir einen schnellen Effekt: "Schauen Sie, dieser Test hat einen Tag zuvor gedauert, jetzt kann ich ihn durch einen Roboter ersetzen, es dauert 2 Tage, aber ich nehme hier nicht teil." Dies verbessert natürlich die Qualifikation und erweitert den Horizont der Spezialisten: Sie beginnen, den Code zu verstehen. Es gibt jedoch kein klares, greifbares Ergebnis für das Unternehmen. Wie viele Stunden wurden für die Entwicklung aufgewendet und wie viel könnte ausgegeben werden, wenn eine Person mit Erfahrung dies tun würde? Wie viele Stunden werden gespart? Wie oft wird der Testfall gestartet? Wo? Wen begleiten? Wie viel kostet das? Das ist nicht sehr gut für mich, weil ich leider noch keine Kunden gesehen habe, die bereit sind, endlos Geld zu zahlen - für den Prozess. Daher ist mir immer ein klares, greifbares Ergebnis wichtig.

2) Keine Fristen. Einerseits ist es gut: Niemand ermutigt das Team, "lasst uns schnell alles automatisieren, lasst uns schnell lernen", die Spannung in einer Person wächst nicht. Er testet weiter mit seinen Händen und taucht ruhig in die Automatisierung ein. Auf der anderen Seite gibt es keine Fristen, wir können nicht nach den Ergebnissen fragen und wir verstehen nicht, wann sie fertig sein werden.

3) Es gibt keine Codeunterstützung und Kontinuität. Einerseits führen unterschiedliche Ansätze und Umfragen zu besseren Schreibmethoden. Manchmal können Sie den Autotest mehrmals beschleunigen, indem Sie ihn von Grund auf neu schreiben. Aber es ist Megatrack. Wer wird das alles begleiten, wenn die Spezialisten das Projekt verlassen, und dies geschieht, wenn sie in einen anderen Geschäftsbereich oder ein anderes Team aufbrechen? Auch nicht sehr klar.

Merkmale des Projektansatzes


Quelle

1) In diesem Fall sprechen wir bereits über das Projekt. Und das Projekt ist was? Das sind Ressourcen, Zeit, Geld. Dementsprechend wird hier das Budget unter Berücksichtigung aller Nuancen in diesem Projekt berechnet. Alle Risiken werden berechnet, alle zusätzlichen Arbeiten werden berechnet. Und erst nachdem das Budget vereinbart ist, wird eine Entscheidung zum Start getroffen.

2) Auf dieser Grundlage dürfte die Vorbereitungsphase nicht schnell sein, da die Budgetberechnung für etwas erstellt werden sollte.

3) Natürlich werden erhöhte Anforderungen an die Spezialisten gestellt, die an dem Projekt teilnehmen werden. 

4) Hier werde ich auch komplexe Infrastrukturlösungen aufschreiben, aber dazu später mehr. 

5) Modernisierung bestehender Test- und Freigabeprozesse. Weil Autotests ein neues Element des Teams sind. Wenn es zuvor nicht bereitgestellt wurde, müssen Sie es in den Prozess integrieren. Autotester sollten nicht rechts, links am Projekt hängen.

6) Der Projektansatz bietet Regelmäßigkeit und Konsistenz, obwohl seine Umsetzung andererseits langsamer sein kann als die Umsetzung des ersten Ansatzes.

7) Nun, Berichterstattung. Viel Berichterstattung. Denn für jedes Budget werden Sie gefragt. Dementsprechend sollten Sie verstehen, wie Autotests funktionieren (schlecht, gut), welche Trends, welche Trends, was erhöht werden muss, was verbessert werden sollte. Dies wird durch Berichterstattung gesteuert.

Langer Weg in eine bessere Zukunft


Haftungsausschluss: Wir waren sofort so schlau (eigentlich nicht).

Quelle

Hier ist eine Klassifizierung der Probleme, auf die wir gestoßen sind. Ich werde jeden einzeln analysieren. Ich werde dies absichtlich tun, damit Sie diesen "Rechen" berücksichtigen. Da diese Probleme, die zu Beginn des Projekts nicht gelöst werden, sich zumindest direkt auf die maximale Dauer auswirken, erhöhen sie das Budget oder können das Projekt sogar schließen.

Quelle

  • Unterschiedliche Teams - unterschiedliche Ansätze.
  • Schwaches Eintauchen der Automatisierung in die Funktion.
  • Nicht optimale Struktur von Testfällen.
  • Dokumentation des Frameworks.
  • Kommunikationsprobleme.
  • Rechtzeitiger Kauf von Lizenzen.

Verschiedene Ansätze zur Automatisierung


Quelle 

Folter mehrmals


Der erste Versuch, den wir hatten, war nach dem ersten Modell (siehe Methode Nr. 1). Eine kleine (aber stolze) Initiativgruppe von Testern entschied sich für die Automatisierung. Im Großen und Ganzen wollten wir uns ansehen, was dabei herauskam. Jetzt würden wir das natürlich nicht tun, aber dann gab es keine Erfahrung und wir beschlossen, es zu versuchen. 

Quelle

Wir hatten einen Teamleiter mit Automatisierungserfahrung, 3 mit dem Wunsch, den Tester zu automatisieren, und viel Wunsch, diesen Weg zu meistern. Zwar war Timlid ein Neuling und konnte nicht viel Zeit für das Projekt aufwenden, aber der positive Effekt seiner Arbeit war, dass wir unser eigenes Framework geschrieben haben. Wir haben uns die Frameworks angesehen, die dort waren, sie waren teuer und cool oder kostenlos, und die Anweisung „an die Datei angehängt, um nach dem Zusammenbau zu schmecken“ wurde ihnen beigefügt. Im Allgemeinen konnten wir sie aus einer Reihe von Gründen nicht verwenden. Dementsprechend haben wir beschlossen, unser eigenes Framework zu schreiben. Die Wahl selbst und der Schreibprozess sind ein Thema für einen separaten Artikel oder gar keinen.

Um nicht zu sagen, dass dieser Versuch ein Fehlschlag war, er überlebte sich einfach selbst und endete. Als wir feststellten, dass wir ein Budget brauchten, brauchten wir zusätzliche Kräfte, wir brauchten Fähigkeiten, wir brauchten eine andere Teamorganisation. Wir haben ungefähr 100 Fälle automatisiert, festgestellt, dass es funktioniert, und abgerundet.

Versuch Nummer zwei


Quelle 

Nichts winkt wie ein gebissenes Sandwich.

Nach einer Weile kehrten wir wieder zum Thema Automatisierung zurück.

In Erinnerung an das erste Experiment wechselten wir jedoch zu Methode Nr. 2. Hier hatten wir bereits ein ziemlich „geschicktes“ Team, das mehr als ein Projekt automatisierte. Aber hier stehen wir vor einer weiteren Katastrophe. Dieses Team folgte der Führung des UI-Testteams. Wie ist es passiert?

"Wir wollen das automatisieren!"
- Vielleicht denken wir darüber nach.
- Nein, wir wollen nichts denken, wir wollen diese Autotests.

Mit titanischen Anstrengungen automatisierten sie es und es funktionierte sogar. Mit der Zeit nahm die Stabilität der Starts jedoch ab, und als wir unser eigenes Team von Automatisierungsingenieuren zusammenstellten und ihnen das Projekt übergaben, stellte sich heraus, dass die Hälfte der Tests an Krücken durchgeführt wurde, die Hälfte prüfte, was die Maschine beabsichtigte und nicht, was der manuelle Tester wollte. 

Und das alles, weil Autotests mit Rohcode ausgeführt wurden, der täglich korrigiert wurde. Jene. Die anfängliche Reihe von Fällen war nicht korrekt. Wir mussten uns in die Themen stürzen, die wir automatisieren wollen, unter dem Gesichtspunkt ihrer Automatisierung (im Folgenden: Butter). Es ist sehr wichtig, sich den Fällen zu nähern, die wir zur Automatisierung verschenken, und irgendwann einige davon zu verwerfen, einige davon zu trennen und so weiter. Aber wir haben es nicht getan. 

Was ist das Ergebnis. Wir haben ein weiteres Stück automatisiert, ungefähr 300 Fälle, nach denen das Projekt endete, weil Es gab keine Stabilität der Starts und auch kein Verständnis dafür, wie dies zu begleiten ist. Und wir haben verstanden, wie man es nicht macht ... zum zweiten Mal.

Versuch Nummer drei


Quelle 

Beim dritten Versuch näherten wir uns wie ein schüchternes Reh einer Wasserstelle. 

Rund sah Risiken (und Aufschlüsselungen der Bedingungen). Sie gingen zunächst kritisch auf Testfälle und ihre Autoren - UI-Tester - als Prozesskunden ein. Wir fanden das gleiche kritisch denkende Team von Automatisierungsingenieuren und starteten ein normal berechnetes (wie wir dachten), vollständig vorbereitetes (ha ha) Projekt.

Der Rechen lag bereits und wartete auf uns.

Schwaches Eintauchen der Automatisierung in die Funktion


Quelle 

In der ersten Phase (im Folgenden als dritter Versuch bezeichnet), als die Kommunikation noch schlecht aufgebaut war, arbeiteten Autotester hinter einem bestimmten Bildschirm: Sie erhielten Aufgaben, sie automatisierten dort etwas. Wir haben Autotests durchgeführt. Wir haben Statistiken gesehen, dass bei uns alles schlecht ist. Autotest-Protokolle graben. Und dort ist beispielsweise ein Rechtschreibfehler im Namen der hochgeladenen Datei aufgetreten. Es ist klar, dass der Tester, der diese Funktionalität mit seinen Händen getestet hat, ein Moll startet und springt, um weiter zu prüfen. Der Autotest fällt und schlägt die gesamte Kette, die auf ihrer Basis basiert. 

Und als wir anfingen, die Autotester in die Funktion einzutauchen, um zu erklären, was genau wir in Fällen überprüfen, begannen sie, diese "Kinder" -Fehler zu verstehen, wie man sie vermeidet, wie man sie umgeht. Ja, es gibt Tippfehler, es gibt einige Inkonsistenzen, aber der Autotest fällt nicht ab, er protokolliert sie einfach.

Nicht optimale Testfallstruktur


Quelle 

Dies ist wahrscheinlich unser größter Kopfschmerz. Sie gab die meisten Probleme, die meisten Zeitkosten, die meisten Stunden und das meiste Geld, das wir dafür verloren haben. Infolgedessen werden wir jetzt zunächst ein solches Problem lösen, wenn wir etwas anderes automatisieren.

Unser Projekt ist ziemlich groß, mehrere Dutzend Informationssysteme drehen sich darin, sie werden von Arbeitsgruppen vereint. Und es scheint, dass die Standards für das Schreiben von Fällen für alle gleich sind, aber in einer Gruppe heißt dieses Stück "Funktion", in einer anderen "Autorität", und der Autotester liest sowohl "Funktion" als auch "Autorität" und gerät in einen Stupor. Dies ist nur ein Beispiel. Tatsächlich gab es Hunderte solcher Situationen. Ich musste das alles standardisieren, meine Haare kämmen.

Was haben Sie außer solchen Unklarheiten noch erlebt? Wir haben keine atomaren Testfälle gefunden. Dies sind Testfälle, die in einigen Schritten variabel ausgeführt werden können. In der Bedingung heißt es beispielsweise "Sie können Schritt 2 unter einer solchen Autorität und unter einer solchen Autorität ausführen", und in Schritt 3 drücken Sie beispielsweise abhängig von der verwendeten Autorität entweder die Taste "A" oder die Taste "C". Aus Sicht eines manuellen Testers ist alles in Ordnung. Der Tester versteht, wie man es besteht, der Autotester versteht nicht, wie man es besteht. In einer schlechten Version wird er selbst den Weg wählen, in einer guten wird er mit Klarstellung kommen. Wir haben ziemlich viel Zeit damit verbracht, nichtatomare Testfälle zu konvertieren.   

Rahmendokumentation


Quelle

Sie müssen immer an diejenigen denken, die nach Ihnen kommen. Wie sie Ihren Code analysieren, analysieren usw. Es ist gut, wenn es kompetente Ingenieure und Programmierer gibt. Schlecht, wenn sie nicht sind. Dann können Sie sich auch der Tatsache stellen, dass Sie das Erbe vergangener "Siege" zerlegen, erneut dokumentieren, zusätzliche Personen anziehen und zusätzliche Zeit verbringen müssen.

Kommunikationsprobleme


Quelle  

1. Fehlende Vorschriften für die Interaktion.

Ein Team von Automatisierungsunternehmen kam, sie wissen nicht, wie sie mit dem Team für manuelle Funktionstests kommunizieren sollen, und niemand weiß tatsächlich, um welche Art von Personen es sich handelt. Ja, es gibt Leads, die miteinander kommunizieren, und alle anderen sind nur Projektnachbarn. 

2. Das Vorhandensein von Vorschriften für die Interaktion

Dann wurden die Vorschriften geschrieben, aber die Jungs arbeiteten einige Zeit ohne einander, und als die Vorschriften geschrieben wurden, nahmen sie dies als das einzige Werkzeug für die Interaktion. Alles, was darüber hinausging, wurde ignoriert. 

Das heißt, zuerst wussten die Jungs einfach nicht, wie sie miteinander kommunizieren sollten, es scheint, dass sie sich in denselben Chatrooms befanden, aber ob sie hier Fragen stellen können oder nicht, wissen sie nicht. Und als sie schon einige Zeit unter solchen Bedingungen gearbeitet hatten, entwickelten sie ihre eigenen informellen, geschlossenen Gemeinschaften: Wir sind „Handwächter“, wir sind Automaten. Wie man kommuniziert? Hier haben wir die Regelung - gemäß der Regelung. 

Rechtzeitiger Kauf spezialisierter Softwarelizenzen


Irgendwann stellte sich heraus, dass wir für die Entwicklung einiger Fälle noch kostenpflichtige Software benötigen, aber es gibt keine Lizenz dafür. Ich musste es in einem Feuerauftrag kaufen (wieder zusätzliche Kosten in Geld und Ausfallzeiten). 

Roadmap


Istonik 

Dementsprechend haben wir jetzt eine Roadmap, wie man solche Projekte startet. Sie besteht in der Tat aus Phasen, wobei jede Phase in bestimmte Punkte unterteilt ist.

Vorstufe


Quelle 

Wir brauchen einen Teamleiter


Timlid, ein Architekt im Allgemeinen, derjenige, der den ganzen Weg bei uns sein wird, derjenige, der Automatisierung versteht, der technisch versiert und kompetent ist. Es ist wünschenswert, dass dies ein Entwickler mit 5 Jahren Erfahrung in bestimmten Programmiersprachen ist, die in unserem Projekt verwendet werden. Denn auf die eine oder andere Weise wird unser Framework mit unserem Projekt zusammenarbeiten. Dementsprechend ist es am besten, wenn sowohl das Framework als auch das Projekt denselben Technologie-Stack verwenden.

Es muss eine Fokusgruppe geben


Darüber hinaus sollte dies keine Fokusgruppe der Automatisierung sein. Dies sollten Personen sein, die in Zukunft Entscheidungen treffen werden. Es ist besser, sie gleich zu Beginn zu Freunden zu machen, damit verstanden wird, welche Entscheidungen sie treffen, warum und warum.

Bewertung des Status der Testfallbasis


Ich habe bereits oben über die Bewertung des Zustands der Testfallbasis gesprochen, dies geschieht ebenfalls bereits in der sehr vorläufigen Phase.

Wir finden heraus, was nicht automatisiert werden kann


Oft besteht der Wunsch, alles zu automatisieren, was sich bewegt (und alles, was sich nicht bewegt, bewegt und automatisiert). Tatsächlich sind etwa 40% der Testfälle in der Regel so teuer zu implementieren, dass sie sich im Prinzip nie auszahlen. Daher müssen Sie hier sehr klar sein, was Sie wollen: um alles zu automatisieren und in das Rohr zu fliegen, oder Sie möchten eine bestimmte Funktionstestung automatisieren, die Ihnen hilft.

Evaluierung eines Pilotprojekts


Wir bewerten das Pilotprojekt in der Vorphase (wie viel es kosten wird) und führen es in den schwierigsten Fällen durch.

Pilot


Quelle 

Normalisierung von Testfällen


Der gesammelte Fallpool unterliegt einer Normalisierung. Mehrdeutigkeiten und unnötige Voraussetzungen werden beseitigt. 

Rahmenvorbereitung


Wir schreiben unser Framework, fügen das vorhandene hinzu oder verwenden eine Art gekauftes.

Infrastruktur


Wir bereiten Infrastrukturlösungen vor.

Hier ist es sehr wichtig, nicht zu verlieren: Sie werden den unwiderstehlichen Wunsch haben, in der ersten Phase eine Art Heimcomputer unter dem Tisch zu verwenden, um Autotests durchzuführen. Dies ist nicht erforderlich (die Tests werden langsamer und fallen ab, wenn jemand versehentlich einen Computer ausschaltet oder Kaffee darauf verschüttet). Es ist notwendig, vorgefertigte Infrastrukturlösungen und virtuelle Maschinen zu verwenden und die Anwendungspraxis zu beobachten. Berechnen Sie dementsprechend sofort die Leistung sowohl für dieses als auch für das nächste große Projekt. Dazu benötigen wir einen Automatisierungsspezialisten.

Zwischensummen und Anpassungen


Wir schreiben die ersten Fälle. Wir bewerten die Geschwindigkeit all dieses Glücks. Wir bewerten den zusätzlichen Bedarf an Menschen, da wir bereits wissen, wie stark diese Fälle automatisiert werden. Das heißt, wir haben fünf Teile automatisiert. Jetzt müssen wir verstehen, wie viele Personen wir benötigen, um bedingt weitere fünftausend zu automatisieren. Einige zusätzliche Lizenzen, Hardware für den Stand, sowohl für den Stand, an dem Autotests ausgeführt werden, als auch für den Stand der Anwendung selbst. Nun, und in der Tat die Notwendigkeit, Testfälle abzuschließen - wie schlimm alles ist.

Den Piloten zusammenfassen


Wir fassen zusammen, schreiben einen Bericht und treffen eine Entscheidung, ob wir in die Automatisierung gehen oder nicht.

Ich habe bereits früher geschrieben, dass es passieren kann, dass wir nicht gehen. Das heißt, wenn sich die Amortisation beispielsweise 18 Jahre beträgt und die Laufzeit Ihres Projekts 5 Jahre beträgt, sollten Sie darüber nachdenken, warum Sie es benötigen.

Startphase


Quelle 

Artikel aufgelistet nacheinander, aber in der Tat sollten sie alle parallel durchgeführt werden.

  • Wir beginnen mit der Auswahl des Teams.
  • Wir bestimmen die Leads.
  • Lassen Sie uns die Fallstudien priorisieren.
  • Wir normalisieren Testfälle.
  • Wir lösen "Infrastrukturprobleme".
  • Wir schreiben Vorschriften und Anweisungen, stellen Kommunikationen her und beseitigen Engpässe.
  • Wir verbessern den Rahmen für die gleichzeitige Arbeit mehrerer Autotests und die Parallelisierung von Gruppen laufender Tests.
  • Wir erstellen ein Berichts- und Statistikmodul (einmalig und kumulativ).
  • Wir beginnen Autotests zu schreiben.

Hauptbühne


Quelle 

In der Hauptphase ist alles einfach (haha): Autotests werden geschrieben, schriftliche Unterstützung bereitgestellt, Startergebnisse ausgewertet, Managemententscheidungen getroffen, Befugnisse verschärft, Streams hinzugefügt und tatsächlich Kommunikation und erneut Kommunikation mit dem UI-Team. Jeder sollte im selben Boot segeln und in eine Richtung rudern.

Escort Bühne


Quelle 

Die Escort-Stufe unterscheidet sich geringfügig von der Hauptbühne. Ein wesentlicher Unterschied besteht in der Dauer. Darüber hinaus wird ein viel geringerer Prozentsatz neuer Autotests entwickelt. Nach unseren Schätzungen 6-10% pro Release, ansonsten ist es der Hauptstufe sehr ähnlich.

Was ist das Ergebnis?


Wir haben rund 1.500 End-to-End-Fälle automatisiert. Die Stabilität erfolgreicher Starts hat mehrere Veröffentlichungen bei etwa 92-95% gehalten.

Die Kosten für den Rückgriff verringerten sich um fast das 2,5-fache. Die Läufe selbst finden in 3-4 Stunden statt, dies erfolgt nachts, damit am Morgen fertige Ergebnisse erzielt werden.

Details zur technischen Implementierung werden in einer Reihe von Artikeln meiner Kollegen beschrieben:


Wenn wir jetzt anfangen und alles berücksichtigen, worüber ich geschrieben habe, werden wir unsere Nerven, Zeit und unser Budget erheblich sparen.

Vielen Dank für Ihre Aufmerksamkeit. Stellen Sie Fragen, wir werden diskutieren. 

Quelle 

Und wir warten auch auf unser Team junger Tester!
, , .

More articles:


All Articles