Uwaga - artykuł z przymrużeniem oka!
Jako programista, który swoje już przesiedział przy klawiaturze, miałem do czynienia z wieloma testerami. Czasami praca z nimi była czystą przyjemnością, a czasami… no cóż, bywa różnie.
Jak każdy deweloper wiem, że nie ma po co testować mojego kodu, skoro spodziewam się, że działa. A gdy ktoś wskazuje mi, że jestem w błędzie… to bardzo dobrze, ale często jest to odbierane negatywnie.
Na co więc testerzy powinni uważać, żeby nie wkurzać swoich kolegów-programistów bardziej niż to konieczne? Oto kilka przykładów:
1. (Nie)krytyczne wrzutki.
“U mnie nie działa.”
~ Niemalże każdy tester, 3 razy w tygodniu
Na maila programisty trafia P0, błąd krytyczny, wymagający natychmiastowej uwagi. Layout sklepu internetowego totalnie się rozjechał. Nie ma czasu na wstępną analizę, trzeba natychmiast łatać.
Odrywamy się więc od pracy nad P1 (nie działają komentarze pod produktami), oraz P2 (nie wyświetlają się podpowiedzi zbliżonych produktów), by natychmiast uratować świat.
Świat nie zauważa jednak naszego poświęcenia. Tylko jeden z dziesięciu dostępnych layoutów kolorystycznych nie działał poprawnie. Jedynie na wersji Firefoxa sprzed 2 lat.
Problem dotknął zapewne tylko testera.
Świat i klient za to z pewnością zauważą opóźnienia związane z nierozwiązanym P1 oraz P2.
Morał? Najważniejsze jest właściwe ustalenie priorytetów. .
2. Wszystkie błędy są krytyczne.
“Wiem, że zgłaszanie błahych problemów oraz tych poważnych jako P0 jest niewłaściwe.
Gdyby tylko istniał priorytet wyższy niż P0.”
~ Anonimowy tester, wyssane z palca, rok 2024
W idealnym świecie każdy błąd jest ważny i powinien być niezwłocznie usunięty (no dobra, jeszcze lepiej gdyby ich nie było wcale). Niestety moce przerobowe zespołu są zwykle ograniczone.
Tak naprawdę nie ma znaczenia, czy wszystkie (bądź niemalże wszystkie) bugi będą zgłoszone jako P0, P1, czy P4. Jeśli wszystko ma ten sam priorytet - cały system priorytetów robi się bezcelowy.
Priorytety są BARDZO ważne.
3. Zgłaszanie bugów, które błędami (programisty) nie są.
“No ja ….. Powinno wyjść inaczej.”
~ Junior tester stykający się z absurdalnymi założeniami po raz pierwszy
Zdarza się, że tester zgłasza problem: "Nie działa to i to", a…. po prostu aplikacja tak ma działać.
Pół biedy gdy problem można samemu zreprodukować, wtedy szybko dotrzemy do źródła nieporozumienia. Ale co, gdy problem występuje jedynie u testera na drugim końcu globu?
Nurkujemy do kodu, szukamy dlaczego “przycisk nie reaguje”, po drodze kilka razy zastanawiając się nad zmianą fachu.
Finalnie okazuje się, że jedyne racjonalne wyjaśnienie, to brak połączenia z siecią. Kilka godzin zmarnowane, przybyło kilka siwych włosów, a przycisk działa (czyli nie działa) tak, jak powinien w trybie offline.
Na usprawiedliwienie zgłaszającego “buga”. Czasami w takiej sytuacji rzeczywiście mamy do czynienia z błędem. Na etapie zbierania wymagań od klienta, bądź projektowania UX interfejsu użytkownika.
4. Testowanie niewłaściwego softu.
“U mnie działa.”
~ Niemalże każdy programista, 3 razy w tygodniu
Dlaczego u programisty nie reprodukują się problemy zgłaszane przez testerów? Często są już zwyczajnie naprawione. Nadspodziewanie często testerzy zgłaszają błędy znalezione w starszych wersjach oprogramowania.
Zespół deweloperski szybko by wskazał jako przyczynę zgłaszanych bugów nieaktualne środowisko testowe…. gdyby raport informował dokładnie o testowanej wersji oprogramowania.
Dziwnym trafem raporty mają tendencję do wskazywania poprawnego środowiska, nawet jeśli dotyczą tego nieaktualnego. A wystarczy, by oddawały rzeczywistość.
5. Raporty dłuższe niż kod.
“Długi raport, widać solidnie przetestowane.”
~ Niejeden menedżer IT, rok 2024
Nie wiem, skąd bierze się u testerów tendencja do pisania kilometrowych raportów. Czasami
dostaję zgłoszenie, które ma pół strony tekstu, a problem to „literówka w tekście na
przycisku”. Serio? Oczywiście - opis sytuacji jest ważny, ale bez przesady. Gdy muszę
czytać raport dłużej, niż trwa naprawienie problemu, to zaczyna się robić niezbyt przyjemnie.
Oczywiście czasami zdarza się druga skrajność.
6. Niedostateczne raporty.
“Jak do tego doszło - nie wiem.”
~ Tester Zenon, rok 2024
Nawet kilometrowy raport może nie być wystarczający, gdy nie zawiera kluczowej informacji - w jakich warunkach błąd się reprodukuje.
Prawie (naprawdę prawie) wszystkie zgłoszenia błędów zawierają dokładny opis błędu oraz obecnego stanu systemu.
“W ustawieniach aplikacji, w zakładce konfiguracji ustawień sieci, elementy na liście dostępnych sieci WiFi są zduplikowane”
To, czego często brakuje to sekwencja wydarzeń, która do tego doprowadziła oraz jak często błąd się reprodukuje.
“Błąd pojawia się średnio raz na 10 restartów urządzenia, po restarcie - należy wejść i wyjść
z ustawień aplikacji kilkanaście razy”
Bez tych kluczowych informacji programista stara się to zreprodukować 2-3 razy po czym wraca z komentarzem “U mnie działa”🙂.
7. Crunch? Poproszę!
“Firma to Twój drugi dom”
~ Przeciętny CEO w gamedev
Deadline nie zawsze musi oznaczać stres. Gdy Twój zespół poprawił wszystkie zgłoszone bugi na najdrobniejsze nawet detale, a programiści z nudy dokumentują swój kod - wszyscy śpią spokojnie.
Chyba, że nagle kluczowa funkcjonalność okazuje się kompletnie nie działać. Ale skąd ta nagła regresja?
Okazuje się, że aplikacja od tygodni nie działa. Ale nikt tego nie testował. Testy tej funkcjonalności zaplanowano dopiero na kilka dni przed release.
Zapewne aplikacja mogła iść do klienta z drobnymi defektami wizualnymi, które pieczołowicie naprawiłeś. Ale nie z błędem funkcjonalnym.
Zgadnij… kto będzie siedział po godzinach?
Podsumowanie
Czy testerzy nas wkurzają? Jasne. Tak to już bywa w drużynie🙂. Zazwyczaj źródłem frustracji są nieporozumienia. Ale hej – to działa w obie strony! Jeśli obie grupy będą lepiej rozumiały swoje potrzeby i ograniczenia, to praca stanie się o wiele bardziej efektywna (i mniej stresująca).
Stay tuned! Już wkrótce artykuł o tym, co najbardziej wkurza testerów w programistach!
Będzie trochę śmiechu, trochę prawdy – i sporo wzajemnego zrozumienia (a przynajmniej mamy taką nadzieję)!