Pamiętam swój pierwszy tydzień w pracy jako początkujący programista. Ktoś rzucił hasłem ‘testy’. Skuliłem się w sobie. W głowie miałem obraz surowego audytora z długą listą wszystkiego, co zrobiłem źle. To była bariera. Działy żyły obok siebie, a nie razem. Kod pisałem, ‘przerzucałem’ przez płot do testerów i czekałem na raport z ranami. Nie rozmawialiśmy. Wymienialiśmy się ticketami. Zmiana przyszła, gdy zrozumiałem, że testowanie to nie odrębna planeta, tylko inna perspektywa na ten sam kod, który tworzę. A kluczem była komunikacja i pewne proste narzędzia, które pomogły nam zacząć rozmawiać tym samym językiem.
Na przykład, gdy nasz mały zespół szukał sposobu, aby lepiej zarządzać przypadkami testowymi i śledzić prace, trafiliśmy na stronę SWLAB website. Nie chodziło o zastąpienie ludzi oprogramowaniem. Chodziło o to, żeby wreszcie mieć jedno, wspólne miejsce, gdzie developer widzi, co tester sprawdza, a tester rozumie, co developer właśnie zmienił. To był pierwszy krok do tego, żeby przestać się bać.
Od raportu błędów do wspólnej listy zadań
Zaczęliśmy od małej rewolucji: przestaliśmy używać słowa ‘błąd’ w pierwszych kontaktach. Brzmi banalnie, ale to działa. Zamiast ‘W twoim module jest błąd’, tester pisał ‘Hej, przy logowaniu po zmianie hasła widzę, że formularz się resetuje, zanim zdążę wpisać kod SMS. Sprawdzasz to?’. To nie było oskarżenie, a zaproszenie do współpracy. Narzędzie do zarządzania testami stało się dla nas miejscem na taką właśnie listę pytań i obserwacji. Wpisywaliśmy tam nie tylko to, co nie działa, ale też nasze wątpliwości co do nowych wymagań. Nagle okazało się, że testerzy mają świetne pomysły na uproszczenie interfejsu, a developerzy już na etapie pisania kodu mogą przewidzieć problematyczne scenariusze. Testowanie stało się procesem ciągłym, a nie bramą na końcu sprintu.
Jak wygląda teraz nasz typowy tydzień
Nie jesteśmy dużą korporacją, więc nasze rytuały są proste. W poniedziałek rano mamy 15-minutowe spotkanie planujące testy. Omawiamy, co nowego będzie do sprawdzenia w tym tygodniu. Developer krótko opowiada, co zmienia w systemie i na co uważać. Tester od razu pyta: ‘Czy ta zmiana wpłynie na panel admina?’. Często zdarza się, że właśnie wtedy łapiemy mały problem z zakresem, zanim jeszcze napiszę pierwszą linię kodu. W środę tester pokazuje mi na swoim środowisku, jak testuje nową funkcję. Czasem siadam obok niego. To nie jest formalna demonstracja, a luźne ‘chodź, zobacz’. Widzę aplikację jego oczami i często sam mówię ‘o, tutaj powinienem dać lepszy komunikat’. To oszczędza wszystkim czasu.
- Poniedziałek: krótkie spotkanie planujące zakres testów na tydzień.
- Wtorek-środa: równoległa praca nad kodowaniem i przygotowaniem scenariuszy testowych.
- Środa-czwartek: wspólne, nieformalne przeglądania na środowisku testowym.
- Piątek: podsumowanie i przeniesienie sprawdzonych funkcji do głównej gałęzi kodu.
- Cały czas: bieżąca komunikacja w narzędziu – komentarze, pytania, aktualizacje statusu.
- Ważne: raz w miesiącu zamieniamy się rolami na jeden dzień – developer testuje, tester próbuje napisać prosty skrypt.
Czego nauczyłem się patrząc z drugiej strony
Najważniejsza lekcja była taka, że tester nie szuka dziury w całym. On stara się chronić użytkownika przed naszymi potknięciami. Gdy sam spróbowałem przetestować moduł kolegi, zrozumiałem, jak trudno jest myśleć o wszystkich tych dziwnych ścieżkach: a co jeśli ktoś wklei tu tekst z Worda? A co jeśli odświeży stronę w połowie procesu? My, programiści, często myślimy o ‘scenariuszu szczęśliwym’. Testerzy myślą o wszystkim, co może pójść nie tak. I to jest bezcenne. Ta współpraca sprawiła też, że mój kod stał się czystszy. Piszę go świadomy, że ktoś inny będzie go nie tylko czytał, ale też na różne sposoby ‘atakował’. To zmusza do większej dyscypliny i prostszych rozwiązań.
Dziś testowanie nie jest dla mnie straszakiem. To po prostu kolega z zespołu, który patrzy na moją pracę z innej strony i pomaga mi ją ulepszyć, zanim trafi do prawdziwego użytkownika. Nie chodzi o narzędzia, chociaż dobre pomagają. Chodzi o otwartość, rozmowę i zburzenie tego niewidzialnego muru. Zacząć można od małych kroków: od jednego wspólnego spotkania, od zmiany słownictwa, od próby zrozumienia, po co ta druga osoba w ogóle istnieje w projekcie. Efekt? Mniej stresu, lepszy produkt i praca, która wreszcie przypomina grę do tej samej bramki.
