Asercja, która była prawdziwa, zanim kliknąłeś
Zielony e2e nie zawsze znaczy, że UI zrobił to, co myślisz. Część asercji jest prawdziwa już na spinnerze albo na złej zakładce - zanim kliknięcie cokolwiek zmieni.
Ograniczam ryzyko dostaw: QA, automatyzacja i jaśniejsze decyzje w procesie dostaw
Jestem niezależnym inżynierem QA i automatyzacji (B2B, ponad 10 lat): testy i automatyzacja wpasowane w Wasz sposób wydawania oprogramowania, z krótkim, czytelnym kontekstem dla QA przy każdej zmianie - zakres i ryzyko, zanim przeprowadzicie pełną regresję. Oprócz automatyzacji wykonania współpracuję z zespołami przy częstych, przewidywalnych wdrożeniach.
Ostatnie wpisy na blogu
Ile naprawdę kosztuje „ogarnięcie” jednego PR-a? Jira, diff i zakres zanim padnie słowo „testy”
Zanim odpalisz testy, ktoś czyta zgłoszenie, diff i ustala, co faktycznie sprawdzić. Ten czas rzadko trafia do raportów, a przy wielu PR-ach robi się z niego realny tygodniowy koszt - często zanim w ogóle zacznie się mowa o pokryciu czy narzędziach.
Pipeline, który dokłada wątpliwości zamiast jasnego sygnału
Gdy pipeline częściej budzi wątpliwości niż daje jasny werdykt, „zrób rerun” zastępuje diagnozę. QA traci uwagę na szum zamiast na zmianę.
Raportowanie wyników Playwright w Azure DevOps
Czytelne wyniki Playwrighta w Azure DevOps: publikacja raportu w formacie JUnit, widoczne niepowodzenia w podsumowaniu potoku oraz układ kroków, który ułatwia diagnozę - w parze z analogicznym wpisem o Cypressie.
Playwright i CI z Azure DevOps
Jak uruchomić testy Playwrighta w Azure DevOps: przygotowanie potoku i środowiska pod przeglądarki, trzymanie adresów aplikacji i API w zmiennych oraz ten sam ogólny przepływ co w artykule o Cypressie, przy prostszej konfiguracji po stronie Playwrighta.
Co testować, zanim odpalisz testy
Większość narzędzi optymalizuje wykonanie, trudniejsze jest wskazanie, co naprawdę wymaga uwagi. Pomagam zawęzić lukę między zmianami w kodzie a decyzjami QA - uporządkowane briefingi z PR i kontekstu, jaśniejsze ryzyko i obszary wpływu, mniej niespodzianek na produkcji. Chodzi o realne ograniczenie ryzyka operacyjnego, a nie modę na kolejne gadżety.
Większość narzędzi optymalizuje wykonanie, trudniejsze jest wskazanie, co naprawdę wymaga uwagi. Pomagam zawęzić lukę między zmianami w kodzie a decyzjami QA - uporządkowane briefingi z PR i kontekstu, jaśniejsze ryzyko i obszary wpływu, mniej niespodzianek na produkcji. Chodzi o realne ograniczenie ryzyka operacyjnego, a nie modę na kolejne gadżety. Doprecyzowujemy, co wchodzi w minimalny zestaw weryfikacji przy danej zmianie, a co można odłożyć lub pokryć warunkowo - żeby skracać pełną regresję tam, gdzie jest zbędna, i utrzymywać ją tam, gdzie historia zmian naprawdę tego wymaga.
Automatyzacja wpasowana w pipeline
Utrzymywalne frameworki pod API i usługi, spięte z CI/CD, żeby feedback był ciągły. To solidna baza sama w sobie - i fundament pod kolejne warstwy: sensowniejszą interpretację wyników, flaky testy czy doprecyzowanie zakresu w tym samym pipeline’ie.
Utrzymywalne frameworki pod API i usługi, spięte z CI/CD, żeby feedback był ciągły. To solidna baza sama w sobie - i fundament pod kolejne warstwy: sensowniejszą interpretację wyników, flaky testy czy doprecyzowanie zakresu w tym samym pipeline’ie. Projektuję to tak, żeby nowi członkowie zespołu mogli szybko dodać scenariusz bez rozwalania całej struktury, a raporty i artefakty były czytelne dla osób, które nie piszą testów na co dzień. Ten sam pipeline może później karmić metryki stabilności i decyzje o priorytetach - bez osobnego „równoległego świata” automatyzacji.
Jakość end-to-end w cyklu życia
Od wymagań i projektu testów po wykonanie i release. Praktyki jakości spinam z Twoim toolchainem - briefingi, checki i automatyzacja tam, gdzie i tak pracują deweloperzy, a nie w osobnym silosie.
Od wymagań i projektu testów po wykonanie i release. Praktyki jakości spinam z Twoim toolchainem - briefingi, checki i automatyzacja tam, gdzie i tak pracują deweloperzy, a nie w osobnym silosie. Chodzi też o spójność: te same źródła prawdy (ticket, PR, kontrakt API) prowadzą przez projekt pokrycia, wykonanie i decyzję o wydaniu. Dzięki temu nie duplikujemy pracy między narzędziami i łatwiej audytować, co zostało sprawdzone przy danej wersji.
Dostarczam na czas
Przewidywalny rytm pracy na kontrakcie: jasne kamienie milowe, proaktywna komunikacja i zakres dopasowany do Twojego pociągu wydań. Mniej gaśnic pod koniec sprintu, więcej przestrzeni na decyzje, które realnie obniżają ryzyko.
Przewidywalny rytm pracy na kontrakcie: jasne kamienie milowe, proaktywna komunikacja i zakres dopasowany do Twojego pociągu wydań. Mniej gaśnic pod koniec sprintu, więcej przestrzeni na decyzje, które realnie obniżają ryzyko. W praktyce oznacza to wczesne sygnały o blokadach i o tym, gdy zakres trzeba przyciąć albo przesunąć, zamiast komunikatu w ostatniej chwili. Stawiam na jawność: co jest w trakcie, co czeka na decyzję produktu, a co jest gotowe do wydania.
Informuję na bieżąco
Przejrzystość na każdym etapie: status, ryzyko i wyniki pracy widoczne tam, gdzie zespół już je śledzi - w tym przy zmianach w repozytorium i pipeline’ie. Bez niespodzianek, z kanałami, które utrzymują wspólny obraz postępu.
Przejrzystość na każdym etapie: status, ryzyko i wyniki pracy widoczne tam, gdzie zespół już je śledzi - w tym przy zmianach w repozytorium i pipeline’ie. Bez niespodzianek, z kanałami, które utrzymują wspólny obraz postępu. Stosuję krótkie podsumowania po istotnych merge’ach, rozróżnienie regresji blokującej i informacyjnej oraz spójny język statusu w narzędziach, których i tak używacie - żeby PM i dev nie tłumaczyli sobie nawzajem, co oznacza „zielone” w CI.
