Opnieuw proberen is geen reparatie
Slagen bij de tweede poging wist de eerste fout niet. Bewaar dat resultaat, bereken het herhaalde werk en wijs een eigenaar aan voor de instabiele test.
Vertaalde editie. Technische identificatiegegevens blijven in hun oorspronkelijke vorm.
Denk eens aan een illustratieve releaserun: een checkout-test mislukt, wordt opnieuw uitgevoerd en slaagt. Het dashboard is groen. Niemand doet onderzoek. De volgende release herhaalt het patroon. U heeft het aantal rode dashboards verminderd zonder te weten of het afrekenen betrouwbaar is.
Playwright onderscheidt drie uitkomsten in zijn gids voor nieuwe pogingen: geslaagd bij de eerste poging, schilferig na een mislukte poging, gevolgd door succes, en mislukt na de beschikbare pogingen. Dat zijn verschillende bewijsstukken. Een gegenereerde suite moet het onderscheid behouden in plaats van elke uiteindelijke overgang naar succes af te vlakken. Het praktische artefact voor dit artikel is een grootboek voor nieuwe pogingen dat de uiteindelijke dashboardkleur overleeft.
Wat een nieuwe poging eigenlijk verandert
Een nieuwe poging geeft dezelfde test nog een kans om te worden uitgevoerd. Het repareert geen zwakke controle, repareert geen selector, of scheidt twee accounts niet die elkaars instellingen overschrijven. Playwright gooit een mislukt werkproces weg en begint een ander. De gedocumenteerde voorbeelden laten zien dat de hook beforeAll opnieuw wordt uitgevoerd in de nieuwe worker. Het opzetten en opruimen hoort daarom bij de kostenberekening, en niet alleen bij de seconden die in de testinstantie worden doorgebracht.
Een nieuwe browser betekent niet noodzakelijkerwijs een nieuwe database. Als bij de eerste poging een bestelling is aangemaakt maar deze mislukte, kan de volgende poging die bestelling tegenkomen. Bekijk de gegenereerde tests op externe bijwerkingen en bepaal of het opruimen veilig is om te herhalen. Het opnieuw proberen van een aankoop tegen productie is geen acceptabel experiment; gebruik staginggegevens en een begrensd testaccount.
Het grootboek dat naast CI moet worden bewaard
Noteer voor elke test de stabiele identificatie, het resultaat van de eerste poging, het uiteindelijke resultaat, het aantal pogingen, de bewijslink, de vermoedelijke oorzaak, de eigenaar en de datum van de volgende beoordeling. Behoud de mislukking van de eerste poging, zelfs als de laatste poging slaagt. Een team zonder toegewijde QA-ingenieur kan het eigendom toewijzen aan de ontwikkelaar die eigenaar is van de stroom, in plaats van de automatisering een wachtrij te laten creëren die geen eigendom is.
Het grootboek is ook een nuttig beoordelingsoppervlak voor door agenten geschreven tests. Vraag de agent om een scenario op te stellen en laat vervolgens een mens de opzet, controle en opruiming ervan controleren. Een beleid voor opnieuw proberen is een runner-instelling en geen vervanging voor die beoordeling. De openbare pagina van AnyTest beschrijft URL-geleide verkenning en een beoordeling door mensen; er wordt niet vastgelegd hoe uw specifieke CI-budget voor nieuwe pogingen moet worden gekozen.
Zet cijfers op het herhaalde werk
Gebruik een illustratieve berekening met expliciete aannames. Stel dat tien tests elk één extra poging nodig hebben, die twintig seconden duurt, en dat het opnieuw starten van de installatie vijf seconden per poging toevoegt. Dat zijn tien keer vijfentwintig seconden, oftewel 250 seconden extra uitvoeringswerk. Het is niet noodzakelijkerwijs 250 seconden wandklokvertraging, omdat parallelle werkers elkaar kunnen overlappen. Registreer zowel het runnerwerk als de verstreken pijplijntijd als het onderscheid van belang is voor uw factuur- of vrijgaveperiode.
Voeg vervolgens de tijd toe die iemand besteedt aan het lezen van vage rapporten. Als een agent een uur aan schrijven bespaart, maar een uur aan terugkerend onderzoek overhoudt, beschrijft het auteursnummer alleen geen besparing. Voor een bestaand QA-team is het doel minder herhalingswerk en meer tijd voor risicoanalyse. Voor een klein team zonder QA is het doel een bruikbare dekking die een ontwikkelaar daadwerkelijk kan behouden.
Een vrijgaveregel die je kunt uitleggen
Begin met een kleine, beperkte instelling voor opnieuw proberen en een zichtbare, schilferige categorie. Escaleer herhaalde mislukte pogingen in plaats van de limiet stilletjes te verhogen. De juiste drempel is afhankelijk van het product- en vrijgaverisico; er is geen universele telling die een wankele kassa acceptabel maakt. Voeg een reparatie-eigenaar en bewijsmateriaal toe voordat u een uitzondering accepteert.
De vraag bij de beoordeling is eenvoudig: heeft de tweede poging nieuw bewijsmateriaal opgeleverd, of slechts een kleur die we verkozen? Bewaar de mislukte poging totdat iemand kan antwoorden.
Veelgestelde vragen
Is een test die bij een nieuwe poging slaagt, een geslaagde test?
Toneelschrijver classificeert een mislukte eerste poging, gevolgd door een succesvolle nieuwe poging, als onbetrouwbaar, en niet als een geslaagde eerste poging. Behoud dat onderscheid in de releaserapportage.
Hoe moet een team de kosten voor nieuwe pogingen meten?
Tel extra pogingen, testuitvoering, herhaalde configuratie en beoordelingstijd. Runner-werk en wall-clock-pijplijnvertraging verschillen wanneer pogingen elkaar overlappen.
Moeten nieuwe medewerkers van Playwright de servergegevens resetten?
Een vervangende medewerker en browser wissen de externe applicatiestatus niet automatisch. Ontwerp herhaalbare configuratie en opschoning voor het faseren van gegevens.