KIEDY TESTER NIE ŚPI, POMYSŁY SIĘ RODZĄ

Duża żarówka na tle nocnego rozgwieżdżonego nieba.

Niedawno dostaliśmy buga z UAT. Po północy występuje błąd podczas przesyłania requestu. Okazało się, że frontend i backend mają inny format daty i gdy jeden system twierdzi, że jest 00:01 to drugi nadal rozumie to jaki 23:01. Podczas prac deweloperskich szukałam odpowiedniego podejścia do testów. Przecież moje zrównoważone lenistwo nie pozwala na dopuszczenie myśli o siedzeniu po północy i robieniu testów…

Podejście pierwsze:

Po wielu konsultacjach (tu okazuje się, że oprócz internetów warto mieć bardziej doświadczonych ludzi w firmie, do których można zwrócić się o szybką poradę) miałam możliwość przestawienia czasu na maszynach Azurowych, do tego przestawiłam czas na swoim komputerze. Nadszedł czas na testy! Niestety, okazało się, że zewnętrzne systemy, z którymi się komunikujemy, w takich warunkach wysypują się. Po głębszej analizie okazało się, że tak tego nie ogarniemy…

Podejście drugie:

Moje zrównoważone lenistwo zostało zachwiane i przez dwa dni z rzędu robiłam testy po północy. Okazało się, że poprawki nie okazały się wystarczające i czekają mnie kolejne takie testy. To zrodziło kolejne przemyślenia na temat optymalizacji takich testów. To poprowadziło do…

Podejście trzecie:

Napisać test automatyczny, który odpali się po północy. Rano przyjdę wyspana i szczęśliwa do pracy i będę wiedzieć, czy bug został naprawiony czy jeszcze nie. Jest tylko jeden mały problem. Nie potrafię tego zrobić. I tak nocne testowanie doprowadziło mnie do wniosku: mimo że testowanie manualne sprawdza się w wielu projektach (m.in. w tych, w których miałam okazję pracować), jednak czasami trafi się na problem, przy którym napisanie testu automatycznego bardzo ułatwi pracę i życie 🙂 Czas się w takim razie wziąć do dalszej nauki.

Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *