Žinios ir gairės

Playwright per pastaruosius metus tapo vienu populiariausių UI automatizavimo įrankių. Jo pranašumai prieš Selenium apima:

1. Auto-wait mechanizmas — nereikia rašyti explicit waits, Playwright automatiškai laukia elementų.
2. Multi-browser palaikymas — viena konfigūracija Chromium, Firefox ir WebKit.
3. Izoliuoti kontekstai — kiekvienas testas gali turėti savo browser kontekstą.
4. Įmontuotas tracing — detalūs vykdymo įrašai su screenshot'ais ir network logs.
5. Moderni API — TypeScript palaikymas, auto-complete, ir aiški dokumentacija.

Jei dar naudojate Selenium, dabar yra geriausias laikas planuoti migraciją.

Stabilus CI/CD yra skirtumas tarp "turime testus" ir "pasitikime leidimais". Azure DevOps pipeline'e svarbiausia ne tik paleisti testus, bet ir surinkti aiškius artefaktus bei suvaldyti flakiness.

Praktinis šablonas, ką verta turėti pipeline'e:

1. Aiški struktūra repo — atskirkite smoke ir regression, kad galėtumėte greitai paleisti kritinius testus.
2. Priklausomybės + browseriai — diekite Node deps ir Playwright browser binaries deterministiškai (lock failai, vienodas Node versijos valdymas).
3. Cache — kešuokite `node_modules`/package cache ir Playwright browser cache, kad pipeline laikas nekristų į 15–30 min.
4. Lygiagretus vykdymas — naudokite sharding/parallel jobs, kad sutrumpintumėte feedback laiką.
5. Artefaktai — visada publikuokite HTML report, trace, screenshot'us ir video (kai reikia) — kad klaidos analizė būtų 2–3 min, o ne valandos.
6. Flakiness kontrolė — riboti retry, atskiras flaky testų sąrašas/quarantine ir aiškus kriterijus kada testas blokuoja release.
7. Pranešimai — Slack/Teams pranešimai su nuoroda į report'ą ir trumpa santrauka (kas lūžo, kur, kiek kartų).

Ataskaita turi atsakyti į vieną klausimą: ką daryti toliau. Tam neužtenka vien "PASS/FAIL" — reikia konteksto ir įrodymų.

Gairės, kurios padeda padaryti ataskaitas naudingas visai komandai:

1. Santrauka viršuje — kiek testų praėjo/nepraėjo, bendra trukmė, TOP 3 dažniausios klaidos.
2. Grupavimas pagal priežastį — produkto regresija, test data problema, infrastruktūra, flaky.
3. Įrodymai — kiekvienam fail'ui: screenshot'ai, trace, log'ai, request/response (kai aktualu).
4. Greitas root-cause — nuoroda į konkretų testą, žingsnius ir laiką, kad dev'as per 1–2 min suprastų problemą.
5. Istorija — trend'ai per laiką (stabilumas, trukmė, flaky procentas), kad matytumėte, ar kokybė gerėja.

Tikslas: mažiau triukšmo, daugiau aiškių veiksmų.