Polityka E2E — browser evidence dla zmiany widocznej dla użytkownika
Zmiany interfejsu wymagają dowodu na poziomie, na którym doświadcza ich użytkownik. Przebieg wsparty przeglądarką może eksplorować zmieniony flow i zebrać screenshots, traces, błędy konsoli oraz obserwacje accessibility. Krytyczne zachowanie musi potem trafić do deterministycznych testów CI. Obserwacja agenta uzupełnia testy unit i integration; nie zastępuje ich ani nie czyni oceny wizualnej autorytatywną.
Q12 · Bramki jakości Dowód na maksymalny wynik: browser run z kryteriów akceptacji i zachowanymi dowodami, a krytyczne ścieżki przeniesione do powtarzalnych testów CI.
Zdefiniuj politykę według klasy zmiany
Dział zatytułowany „Zdefiniuj politykę według klasy zmiany”| Zmiana | Minimalny dowód |
|---|---|
| Copy lub treść statyczna | route load, screenshot właściwego viewportu, kontrola linków i accessibility |
| Zachowanie komponentu | skupiony test component/integration plus browser run |
| Nowy user flow | przebieg z kryteriów plus deterministyczny happy path i główny failure path |
| Auth, payment, destructive lub privacy | deterministyczny E2E, przypadki negatywne, review specjalisty, nazwana ludzka bramka |
Zespół może używać Playwright bezpośrednio albo połączyć wspierającego agenta przez oficjalny serwer Playwright MCP. Pinuj integrację, używaj izolowanych kont testowych i danych syntetycznych, a produkcyjne writes trzymaj poza agentem browser.
- Zamień kryteria w obserwowalne zachowanie. Zdefiniuj starting state, rolę, viewport, akcje, oczekiwane UI, efekt backend i prohibited outcome.
- Przygotuj kontrolowany stan. Użyj seeded accounts i deterministycznych danych; jawnie ustaw cleanup oraz idempotency.
- Uruchom i zachowaj dowód. Zapisz komendę, środowisko, wersję, screenshots lub trace, błędy konsoli i sieci oraz wynik każdego kryterium.
- Promuj krytyczne dowody. Zamień stabilne krytyczne ścieżki i odtworzone regresje w deterministyczne testy utrzymywane z feature.
- Bramkuj według ryzyka. Człowiek ocenia niejednoznaczną jakość wizualną i konsekwentne zachowanie przed merge lub produkcją.
Prompty do weryfikacji browser
Dział zatytułowany „Prompty do weryfikacji browser”Zamień kryteria akceptacji w checklistę browser ze starting state, rolą, viewportem, akcjami, obserwowalnymi wynikami, efektami backend, przypadkami negatywnymi i dowodami do zachowania.Uruchom tylko zmieniony flow na syntetycznych danych testowych. Zbierz screenshots lub trace, console i failed network requests oraz wynik pass/fail każdego kryterium. Nie zmieniaj danych produkcyjnych.Na podstawie browser run wskaż zachowanie stabilne i krytyczne dla deterministycznego CI. Napisz najmniejszy test Playwright i opisz pozostały ludzki osąd wizualny.Dowody akceptacyjne
Dział zatytułowany „Dowody akceptacyjne”- CI uruchamia właściwą aplikację i failuje zamiast podłączyć się do obcego lokalnego serwera.
- Tożsamość testowa, dane, środowisko i cleanup są jawne.
- Dowody mapują się jeden-do-jednego na kryteria i nie zawierają sekretów ani danych klientów.
- Flaky tests trafiają do jawnej kwarantanny z ownerem i terminem; retry nie zamienia ich milcząco w zieleń.
- Visual review zapisuje viewport i ownership baseline; accessibility używa checków semantycznych oraz człowieka tam, gdzie to potrzebne.
Wzorzec awarii: screenshots bez kontraktu
Dział zatytułowany „Wzorzec awarii: screenshots bez kontraktu”Screenshot może wyglądać wiarygodnie, gdy akcja nie zadziałała, użyto złego stanu konta albo backend się nie zmienił. Łącz dowód wizualny z obserwowalnym stanem, kontrolą console i network, asercjami deterministycznymi oraz zaakceptowaną specyfikacją.
Dalej: etap test
Dział zatytułowany „Dalej: etap test”Użyj kanonicznego etapu Test dla macierzy dowodów, a findings przekaż do Automatyzacji review PR.