Tytuł dzisiejszego postu nie ma za bardzo sensu, ale dobrze brzmi. Choć z drugiej strony – trochę racji w nim jest.
Mówisz: tester, myślisz: bugi. Czy gdyby nie było testerów, nie było by bugów? Chyba nie muszę odpowiadać na to pytanie. W końcu my je tylko znajdujemy, a nie wytwarzamy. Z pewnością więc zgłoszeń defektów było by znacznie mniej. I dzisiejszy post mówi właśnie o zgłoszeniach, choć w tytule wykorzystałam powszechny skrót myślowy (przykłady: „Masz link do tego defektu?”, „Poczekaj, wkleję Ci ten defekt na czacie”).
O tym, jak stworzyć zgłoszenie defekt, napisałam w „Uprzejmie donoszę, że macie defekt”, zaś bogate życie osobiste defektów możecie poznać w „Sekretne życie robali”. Tu chcę się skupić na stosunku testerów do defektów. A ując go można krótko: to skomplikowane.
Zacznijmy od tego, że testowanie ma dwa cele: znalezienie błędów iii… potwierdzenie prawidłowego działania. I serio – to drugie jest znacznie przyjemniejsze.
Przede wszystkim zajmuje znacznie mniej czasu. Prosty przykład – mamy wykonać następujący test:
1. Dodać produkt do koszyka.
2. Zwiększyć ilość tego produktu do 4 sztuk.
3. Sprawdzić, czy wartość zamówienia pomnożyła się przez 4.
4. Zmniejszyć ilość do 2 sztuk.
5. Sprawdzić, czy wartość zamówienia zmniejszyła się o połowę.
Dość podstawowa opcja, przyznacie.
No to wrzucam do koszyka wodę toaletową Glow by JLo (jeśli czyta to mój mąż, a nie wie, co mi kupić w prezencie, to to jest sugestia). Wartość koszyka to 110 zł. Za pierwszym razem klikam 3 razy w plusik. Wartość koszyka: 440 zł. Klikam 2 razy w minusik. Wartość: 220. Zaczynam od początku, ale tym razem nie klikam w plusik, tylko wprowadzam ilość z klawiatury. Działa. Działa. Koniec testu, tester się spisał, można puszczać na produkcję i iść grać w piłkarzyki.
A teraz wersja potencjalnie zbugowana.
Wrzucamy flakonik do koszyczka. Cena: 110 zł. Klikamy 3 razy w plusik. Mamy w koszyku 3 produkty o wartości 330 zł. Fuck! Albo button nie złapał jednego kliknięcia, albo myszka coś nie teges, albo… w sumie to nie wiem, czy kliknęłam 3 razy, czy 2. No to jeszcze raz.
Wrzucamy perfumik do koszyka. Powoli klikamy na plusik. Raz, dwa, trzy. Fuck, znowu 3 sztuki. No to jeszcze raz, tym razem z klawiatury. Jest ok. Czyli bug jest tylko w wersji z klikaniem w guzik. No to lecimy z koksem.
Jeszcze raz powtarzamy scenariusz, bo trzeba porobić screeny. Trzeba by też logi wyciągnąć z systemu. Teraz zgłoszenie. Tytuł, opis, kroki reprodukcji, efekt oczekiwany i aktualny. Załączniki. Wyślij.
Bardzo prosty teścik, a już widać, że zgłoszenie błędu to ze trzy razy więcej roboty. A to dopiero początek. Nawet jeśli deweloper bez niczego uzna, że rzeczywiście jest błąd, to potem trzeba zrobić retest. A przecież często deweloperzy proszą o dodatkowe testy, dodatkowe dane, sprawdzenie tego czy tamtego. Jeśli retest nie jest pozytywny, trzeba powtórzyć cały proces.
Sami widzicie: defekty wymagają w huk roboty. Nasz wewnętrzny Garfield mówi: i po co ci to? Taka praca, nie ma co narzekać – jest błąd, trzeba go naprawić.
Ale zdarza się też tak. Piątek, godzina 15, na weekend przewidziano wdrożenie nowej wersji apki. A wy znajdujecie krytyczny błąd. O pani, jaka to jest satysfakcja. Niczym informatyczni superbohaterowie ratujecie firmę przed wypuszczeniem update’u, który zniszczyłby jej reputację, pogrążył notowania giełdowe, spowodował, że telefony do supportu będą się urywały, a czas oczekiwania na połączenie wynosił ponad 74 minuty. Cała firma was nienawidzi (a najbardziej ten deweloper, który już miał zaplanowany weekendzik na działce RODO przy grillu i browarku, a zamiast tego spędził dwa dni na łataniu dziury). A wy czujecie, że żyjecie XD*
Czy testerzy lubią wystawiać defekty? To skomplikowane. Defekty to clou naszego fachu. Bez nich byłoby nam znacznie łatwiej. Ale jak mówi klasyk: „Jest ryzyko, jest przyjemność”.
* Do czasu, aż usłyszycie „Not a defect. It’s a feature”.