Kodėl aš daugiau niekada rankiniu būdu nerašysiu bandomųjų scenarijų (ir jūs taip pat neturėtumėte)

Jei praleidote bet kurį laiką dirbdami su bandymo automatizavimu, žinote, ką daryti:

• Kiekvieną projektą pradedame turėdami geriausių ketinimų – pažadėdami sau parašyti švarų, prižiūrimą kodą
• Tačiau pasukite kelis mėnesius į priekį, o pusę savaitės praleidžiame taisydami nepatogius testus, ieškodami trapių lokatorių ir sprendžiame „pasikartojančių el. pašto“ klaidas mūsų CI / CD kanaluose.

Aš ten buvau. Mes visi ten buvome.

Pastaruoju metu automatizavimo bendruomenė šurmuliavo apie AI pagrįstą testavimą:

• Skaičiau straipsnius apie „Microsoft“ kūrėjų tinklaraštis ir TestGuild apie tai, kaip AI perima QA 2025 ir 2026 m
• Jei atvirai, buvau šiek tiek skeptiškas – daugelis AI testavimo platformų jaučiasi taip juodos dėžės
• Jie žada pasauliui, bet tu baigsi užrakintas savo ekosistemojeprarasdami tikrosios kodų bazės kontrolę

Bet tada pabandžiau Agentai dramaturgai. Tai nebuvo mokamas įvyniojimo įrankis; tai buvo gimtoji dramaturgo ekosistemoje Jau naudoju ir myliu.

Tai buvo maždaug prieš mėnesį. Nuo tada aš kasdien naudoju „Playwright Agents“ tiesioginiame projekte:

• Naujų komplektų rašymas
• Derinimo gedimai
• Komandos draugų priėmimas
• Stebėti, kaip agentai elgiasi per tikrus sprintus su realiais terminais

Šis įrašas nėra pirmojo įspūdžio apžvalga. Tai aš sužinojau po viso mėnesio, kai pasitikėjau šiais agentais gamybinio lygio darbuose. Štai mano sąžininga patirtis, kaip tai visiškai pakeitė mano požiūrį į testų rašymą.

Iššūkis: vartotojų valdymo modulis

Man reikėjo automatizuoti Vartotojų valdymo modulis mūsų CII-ESG diagnostikos platforma. Jei automatizavote vieną iš šių, automatizavote šimtą: kurkite, skaitykite, atnaujinkite ir ištrinkite naudotojus.

Tačiau norint tai padaryti teisingai, reikia laiko. Jei rašyčiau tai rankiniu būdu, štai kaip atrodytų mano savaitė:

• Praleiskite popietę spustelėdami programą ir parašykite bandymo planą
• Praleiskite kelias valandas rašydami puslapio objektų modelio (POM) klases
• Praleiskite kelias dienas kurdami laimingus kelius, formos patvirtinimus, klaidų būsenas ir kraštutinius atvejus.

Apskritai aš sudaryčiau biudžetą 11-17 valandų šiam moduliui.

Vietoj to, paleidau npx dramaturgų init-agentus, kad sukurčiau naują Modelio konteksto protokolas (MCP) mano redaktoriaus agentai ir nusprendžiau leisti dirbtiniam intelektui perimti vairą.

Susipažinkite su mano naujuoju programuotoju: planuotoju

Dramaturgui priklauso subagentas, vadinamas Planuotojas. Iš esmės aš jam pasakiau: „Ei, išsiaiškink, kaip veikia šis vartotojų valdymo modulis“. Pateikiau paprastą sėklų testą, kad jis galėtų prisijungti, o tada tiesiog žiūrėjau.

Tai ne tik kibo. Štai ką planuotojas iš tikrųjų padarė:

• Sistemingai tyrinėjo programą ir sugeneravo a žmogaus skaitomas Markdown testavimo planas
• Parašė ne tik „sukurti vartotoją“ laimingą kelią – jis atpažino Daugiau nei 90 skirtingų bandymų scenarijų skersai 8 apartamentai
• Planuojami testai vaidmenimis pagrįsti leidimaikas atsitiks, jei įvedu jau egzistuojantį el. pašto adresą ir kaip vartotojo sąsaja apdoroja labai ilgas įvestis
• Krašto atvejai suplanuoti per kelias minutes kad tinkamai dokumentuoti būčiau užtrukęs kelias valandas

Kodo rašymas: generatorius

Puiku turėti tekstinį failą, pilną bandymų planų, bet man reikėjo kodo. Įveskite Generatorius agentas.

Pateikiau bandymo planą ir jis pradėjo rašyti „TypeScript“. Labiausiai bijojau, kad jis parašys šiukšlyną, neprižiūrimą kodą, pavyzdžiui, uždelstų kodavimą (page.waitForTimeout(5000)) arba naudos baisius CSS ieškiklius (#div-child-3 > span).

klydau. Jo sukurtas kodas buvo tiksliai taip, kaip tai parašytų patyręs kokybės užtikrinimo inžinierius:

• Jis sukūrė puslapio objektų modelius: Atskyrė lokatorius nuo bandomosios logikos, suteikdama švarius CreateUserPage.ts ir UserManagementPage.ts failus
• Jai rūpėjo prieinamumas: Labai naudojami lokatoriai, pvz., page.getByRole(‘button’, { name: ‘Submit’ }), o ne pasikliauti trapiais klasių pavadinimais
• Jis suprato dinaminius duomenis: Kad būtų išvengta erzinančių „Vartotojas jau yra“ klaidų, kai bandymai vykdomi du kartus, jis automatiškai sugeneruojamas laiko žyme pagrįsti dinaminiai el (const unikalusEmail = test.user.${Date.now()}@example.com)

Tai perrašė 1500 eilučių funkcinio testo kodo tiems 90+ scenarijų.

Rezultatai sumuojami

Taigi, koks buvo galutinis rezultatas?

• Kas paprastai mane beveik pritraukia dvi dienos solidaus darbo buvo baigtas maždaug 1,5 valandos. Tai yra a 90% sutrumpėja kūrimo laikas
• Kai paleidau komplektą, gavau a 100% išlaikymo rodiklis – jokių klaidingų teigiamų rezultatų, jokių dribsnių

Ir štai kas iš tikrųjų svarbu: tie skaičiai išsilaikė visą mėnesį.

• Dabar per tą pačią darbo eigą perkėliau kelis modulius – Vartotojų valdymas, projektų kūrimas, vaidmenų leidimai
• The laiko taupymas ir išlaikymo procentas buvo nepaprastai nuoseklūs
• Tai nėra demonstracinės versijos rezultatas; tai a raštas, kurį mačiau kartojantis sprintą po sprinto

Priežiūros gelbėtojas: gydytojas

Visi žinome, kad blogiausia automatizavimo dalis yra ne testų rašymas – tai yra juos išlaikant:

• Kūrėjas pervadina mygtukų klasę arba pakeičia ID
• Staiga tavo visa CI vamzdynas nudažytas raudonai

Štai čia mane tikrai nustebino trečiasis agentas: Gydytojas.

Užuot praleidęs valandą ieškodamas pėdsakų žiūrovų, Gydytojas tiesiog įšoka:

• Kai bandymas nepavyksta, tai automatiškai atkuria nesėkmingus veiksmus
• Tikrina dabartinę tiesioginę vartotojo sąsają norėdami sužinoti, kur elementai persikėlė
• Išsiaiškina, kas pasikeitė ir tiesiogine prasme siūlo pataisą, pvz., atnaujintą ieškiklį, duomenų pataisymą arba pakoreguotą laukimą
• Pakartokite testą, kol jis praeis

Per pastarąjį mėnesį Gydytojas padarė sutaupė man daugiau laiko nei bet kuris kitas agentas:

• Mūsų frontend komanda reguliariai siunčia vartotojo sąsajos pakeitimus
• Buvo bent keliolika kartų kai kūrėjas pervardijo komponentą arba pertvarkė formą, mano CI vamzdynas tapo raudonas
• Kiekvieną kartą Gydytojas sugavo, pasiūlė pataisytiir aš ką tik peržiūrėjau skirtumą
• Tai, kas anksčiau buvo baisus pirmadienio ryto ritualas „sutvarkyti vamzdyną“, turi tyliai dingo iš mano kalendoriaus

Atrodo, kad jaunesnysis kokybės užtikrinimo inžinierius automatiškai per naktį įvertintų jūsų sugadintus testus, todėl jūs tiesiog turite tai padaryti peržiūrėkite jų siūlomus kodo pataisas ryto.

Didesnis paveikslas – ir kas bus toliau

Skaičiau straipsnį apie DEV bendruomenė Neseniai kūrėjas išbandė naujus „Playwright“ agentus su brangiomis, atskiromis AI testavimo platformomis. Jų išsinešimas puikiai atitiko mano patirtį: Nuosavybės reikalai.

Su dramaturgo agentais vis dar turiu savo kodą:

• Turiu standartinius TypeScript .spec.ts failus, kurie gyvena mano „GitHub“ atpirkimas
• Galiu juos paleisti CI/CD per Jenkinsas arba „GitHub Actions“, kaip ir bet kuris kitas dramaturgo testas
• Aš nemoku mėnesinio abonemento už stebuklingą platformą
• Aš tiesiog praplečiant mano įprastą darbo eigą su dideliu intelektu

Po viso mėnesio kasdienio naudojimo galiu drąsiai pasakyti: tai ne hype.

• The Planuotojas, generatorius ir gydytojas tikrai pakeičiau tai, kaip aš dirbu. Aš praleidau didžiąją savaitės dalį rašymas ir priežiūra bandymo kodas, skirtas praleisti laiką peržiūrint testo kodas – tai, tiesą sakant, yra daug geresnis kokybės užtikrinimo inžinieriaus smegenų panaudojimas
• mano bandymų aprėptis išaugo greičiau nei kada nors buvo bet kuriame projekte. The priežiūros našta sumažėjo beveik iki nieko

Ar kokybės užtikrinimo inžinieriai išeina iš darbo? Visiškai ne.

• Mūsų darbas nėra įvesti page.locator().click()
• Mūsų darbas yra kokybės užtikrinimas
• Dramaturgų agentai tiesiog susidoroja su varginančiu spausdinimu, suteikdami man savo laikas atgal kad galėčiau sutelkti dėmesį į sudėtingesnes, strategines testavimo problemas

Jei paskęstate neautomatinio testo kūrime, padarykite sau paslaugą:

• Atnaujinkite savo „Playwright“ CLI
• Paleiskite agentus ir pabandyk

Netikėkite mano žodžio dėl vienos popietės eksperimento – paleisti jį mėnesį kaip ir aš, ir esu įsitikinęs, kad tu niekada negrįši