Czy to na pewno jest przetestowane?

Ostatnio czytałem świetny artykuł (If It’s Not Written Down, Did You Really Test It?), który przypomniał mi o pewnym niewinnie brzmiącym zdaniu: „Spokojnie, to jest przetestowane”. Problem zaczyna się, gdy dopytasz „ok, a jak?”. Jeśli zapada cisza, wiadomo już, że tak naprawdę polegamy na pamięci jednej czy dwóch osób i na tym, że „coś klikały”. Zdarzyło mi się być po obu stronach tej rozmowy i za każdym razem kończyło się to podobnie - szybkim gaszeniem pożaru 😅 Różnica między testowaniem a wrażeniem testowania jest widoczna dopiero wtedy, gdy coś wyleci w produkcji i nikt nie potrafi powiedzieć, czego właściwie zabrakło. Taki moment otrzeźwia szybciej niż dowolne retro.

W zwinnych zespołach łatwo jest wmówić sobie, że dokumentacja to biurokracja, więc zamiast krótkich notatek bierzemy na barki całą pamięć testową projektu. Na początku działa to całkiem sprawnie, szczególnie jeśli mamy jednego seniora, który „ma wszystko w głowie”. Tyle że przy pierwszym dłuższym urlopie, rotacji albo presji deadline’u ta głowa staje się wąskim gardłem, a zespół nagle odkrywa, że nie ma pojęcia, co było sprawdzone, co zostało pominięte i gdzie tak naprawdę jest ryzyko. To rzadko kończy się dyskusją o procesach - a częściej hotfixami po godzinach pracy.

Z drugiej strony nikt przy zdrowych zmysłach nie chce powrotu do piętnastostronicowych test planów pisanych dla jednego przycisku. Chodzi raczej o coś dużo bliższego praktyce: lekki, powtarzalny sposób na to, by testowanie zostawiało ślad. Taki, który nie dławi zwinności, tylko ją podtrzymuje. Testowanie bez zapisu potrafi wyglądać pozornie dobrze - szybko, „na bieżąco”, bez tabelek - ale to trochę jak praca developera bez repozytorium. Działa, dopóki działa, a przy pierwszym problemie mamy chaos.

Brak zapisu = brak dowodu. A bez dowodu nie ma jakości

Najczęściej moment „czy to było testowane?” pojawia się wtedy, kiedy mamy bug na produkcji i nikt nie pamięta, czy dany flow w ogóle przeszedł przez ręce QA. Jeśli nie ma żadnej notatki, żadnej sesji czy żadnej checklisty z testów eksploracyjnych, to odpowiedź brzmi: nie wiemy. A w sytuacji awaryjnej „nie wiemy” znaczy „tracimy czas na zgadywanie”. To właśnie w takich momentach wychodzi na jaw, że testowanie bez zapisu jest wiedzą nieudokumentowaną, trzymaną w głowach, nietrwałą i podatną na błędy. Gdy projekt jest młody, jeszcze to nie boli, ale im większy produkt i im bardziej rozproszony zespół, tym szybciej zamienia się to w loterię.

Co ciekawe, brak zapisu nie oznacza braku dobrej woli czy profesjonalizmu. Najczęściej wynika z presji: „weź przetestuj, bo zaraz wdrażamy”. Tester klika świadomie, zwraca uwagę na ryzyka, ale nie zapisuje wniosków, bo wydaje się, że nie ma na to czasu. Problem polega na tym, że test bez śladu jest niewidoczny - ani dla zespołu, ani dla PM-a, ani dla nowej osoby, która dołączy za trzy sprinty. Gdy przychodzi moment oceny ryzyka lub decyzji o release, zespół musi polegać na opinii, nie na danych. A opinia jest dobra tylko wtedy, gdy ma oparcie w konkretnym zapisie, choćby minimalnym.

W praktyce bardzo często widzę powtarzający się schemat: zespół jest szybki, dopóki nie trafi na regresję sprzed kilku sprintów. Pojawia się zdziwienie, że błąd wrócił, choć „kiedyś działało”. No działało, ale nikt nie zapisał, że ten fragment wymaga powtarzalnego sprawdzenia przy kolejnych zmianach. Regresje nie muszą być skutkiem braku kompetencji - częściej są skutkiem braku pamięci. A pamięć zespołu to nie rozmowy na Slacku, tylko udokumentowane testy i obserwacje.

Lekka struktura testowania: nie biurokracja, tylko stabilizator

Wystarczy niewielka zmiana, żeby testowanie zaczęło zostawiać ślad. Nie chodzi o rozbudowane przypadki testowe opisane krok po kroku, bo te sprawdzają się tylko przy stabilnych, powtarzalnych procesach biznesowych. W większości produktów lepiej działa kombinacja trzech elementów: krytycznych ścieżek użytkownika spisanych w krótkiej formie, mini test planu na sprint i notatek z sesji eksploracyjnych. W praktyce takie notatki mogą mieć formę prostego pliku w repo, komentarza albo wpisu w narzędziu testowym - cokolwiek, co pozwoli innym zobaczyć, co było sprawdzane i dlaczego.

Testy eksploracyjne, prowadzone świadomie z charterem, świetnie uzupełniają testy regresyjne. Charter to po prostu cel sesji, zakres i ograniczenia. Dzięki niemu eksploracja przestaje być „chaotycznym klikaniem”, a zaczyna być dokumentowalnym procesem. Na koniec sesji powstają krótkie notatki: co sprawdziliśmy, co nas zaskoczyło, co wymaga follow-upu. Te notatki, choćby nieformalne, robią ogromną różnicę - zespół wie, że coś zostało przetestowane, a jeśli wróci do tego za miesiąc, nie musi zgadywać, gdzie leży ryzyko.

Automatyzacja testów nie rozwiązuje problemu widoczności, jeśli jest tylko prywatnym folderem QA. Sam kod testowy to też dokument, ale dopiero opisanie, jakie scenariusze pokrywa i dlaczego, nadaje mu sens. I co najważniejsze: automaty nie zastąpią notatek z eksploracji, bo te ostatnie pokazują myślenie, a nie tylko wykonanie. Połączenie tych światów sprawia, że zespół ma przewidywalność, a jednocześnie zachowuje elastyczność.

Widoczność testowania zmienia postrzeganie jakości w zespole

Jedną z największych korzyści zapisu jest to, że testowanie przestaje być „czarną skrzynką QA”. Zespół może zobaczyć, co zostało sprawdzone, a co jest ryzykowne. PM może ocenić wpływ na release. Dev może podejrzeć kontekst zgłoszenia błędu bez wracania do QA z pytaniem „a jak to odtworzyć?”. To daje zupełnie inną dynamikę współpracy - jakość staje się wspólną odpowiedzialnością, a nie zadaniem jednej osoby.

Co ciekawe, w zespołach, w których testy są widoczne, szybciej dojrzewa praktyka testmindsetu - podejście, w którym myślimy nie o typach testów, lecz o ryzyku i użytkowniku. Zaczynają pojawiać się pytania „co przegapimy, jeśli zignorujemy ten flow?”, „co jest najważniejsze z perspektywy użytkownika?”, „czy znamy zachowania brzegowe?”. Bez zapisu takie pytania są abstrakcją, bo brakuje faktów. Z zapisem stają się naturalną częścią rozmowy o produkcie.

Widoczność testów wpływa też na onboarding. Nowa osoba nie musi liczyć na to, że ktoś „ma czas opowiedzieć, jak tu testujemy”. Zamiast tego dostaje historię decyzji testowych, powtarzalne scenariusze, kontekst ryzyka i wiedzę domenową zebraną w jednym miejscu. To oszczędza tygodnie i zmniejsza liczbę błędów wynikających z niedopowiedzeń.

Dlaczego to ma znaczenie i co z tego wynika

Testowanie bez zapisu jest jak prowadzenie samochodu po znanej trasie: wszystko działa, dopóki nie pojawi się objazd. W pracy QA objazdem jest awaria, duża zmiana w architekturze, rotacja w zespole albo presja dowiezienia sprintu o 17:00 w dzień wdrożenia. Wtedy brak dokumentacji testowej wraca jak bumerang. Nie chodzi więc o papierologię, ale o zdolność zespołu do powtarzalności, uczenia się i przewidywania ryzyk. To w dużej mierze decyduje o jakości.

Jeśli masz wątpliwość, czy coś było przetestowane, i nie jesteś w stanie tego udowodnić w minutę - to nie masz pewności. A niepewność jakości jest kosztowna. Dobra wiadomość jest taka, że sensowny zapis nie musi być ciężki. Kilka prostych zasad (lekkie notatki, mini plan, krytyczne ścieżki, widoczność automatyzacji) wystarczy, by testowanie stało się przewidywalne i wspólne, a nie oparte na tym, kto akurat jest dostępny na Slacku.

Chcesz być na bieżąco? Zapisz się do newslettera!

Polecane wpisy:

Sprawdź też moje social media: