Gdyby zapytać testerów i testerki, szczególnie tych/te bardziej doświadczonych_ne, z kilkoma latami w zawodzie, co ich/je najbardziej wkurza, na pewno usłyszelibyśmy wiele bardzo ciekawych odpowiedzi. Niestety nie udało mi się znaleźć wyników takiej ankiety w necie, jeśli ktoś zna, chętnie je przeczytam. Znalazłam za to coś innego: mantrę szczęśliwego testera. I myślę sobie, że wielu testerów potwierdzi, że jest w tej mantrze wiele gorzkiej prawdy (choć wolelibyśmy czekoladę). Dziś będzie punkt 3: Akceptuję, że środowisko testowe nie będzie gotowe na czas.

Środowisko testowe (dla tych, co nie wiedzą, co to)

Tym razem bez metafor i porównań. Załóżmy, że testujemy sklep firmy BBB produkującej obuwie. Przygotowują oni właśnie nowe wydanie (release) z aktualizacją wprowadzającą kolekcję jesienną, w tym pewne piękne czerwone pantofelki w stylu mary jane (odsyłam do postu: Cykl życia obutowania…). Sklep ma stronę internetową www.BBB.pl. Jako tester_ka jesteś odpowiedzialny_a za sprawdzenie, czy wszystkie produkty zostały dodane, czy zgadzają się wszystkie dane, takie jak opis, cena, nazwa, kod, rozmiarówka, kolorystyka, kategorie itd. W pip roboty, wiadomo.

Aktualizacja pojawi się 10 sierpnia, czyli na stronie www.BBB.pl dane pojawią się dopiero tego dnia. To jest środowisko PRODUKCYJNE (tzw. prod), czyli to, które zobaczą klienci. Testy muszą zostać przeprowadzone wcześniej. Tylko jak, skoro wcześniej zmiany nie są widoczne?

I tu na całe na biało (powiedzmy) wjeżdża środowisko TESTOWE (tzw. test). Czyli taka wersja alfa, a często niestety pre-alfa. Czyli testy będą przeprowadzane na stronie www.test.BBB.pl albo na www.kotprzebieglmipoklawiaturze.BBB.pl. To w zależności od fantazji osoby odpowiedzialnej za to środowisko.

Kto jest za nie odpowiedzialny? Zależy od firmy. W niewielkich projektach zbudowanie środowiska może być zadaniem testera. W innych będą za to odpowiadać programiści. W jeszcze innych devopsi, testerzy automatyzujący itd. W bardzo dużych i skomplikowanych projektach odpowiedzialność za środowisko testowe bywa podzielona między zespoły odpowiadające za konkretne funkcjonalności, a samo budowanie jest powierzone odpowiednio przygotowanym mechanizmom i narzędziom.

Brzmi całkiem nieźle, prawda?

W teorii…

…bo w praktyce…

W mantrze jest mowa o gotowości środowiska na czas, co wiąże się z ogólną zasadą, że jeśli w planie było, że testy zaczynamy 20 lipca, to deweloperzy skończą programować 31. O obsuwach można dużo i długo, ale ogólna zasada jest taka, że ponieważ testy są zwykle ostatnim etapem, to właśnie czas na ten etap jest okrajany. Data wydania zwykle jest absolutnie nieprzesuwalna.

Jeśli pracujecie w scrumie, to pewnie macie z grubsza co sprawdzać, bo dostajecie na bieżąco wprowadzone zmiany. Ale jeśli lecicie waterfallem – no to dopiero 31. siadacie do testów.

W mantrze mowa jest tylko o aspekcie czasowym. Tymczasem…

… dawno, dawno temu, w mitycznej krainie płynącej informatycznym miodem i mlekiem, istniało niezawodne środowisko testowe. Ktokolwiek się z nim zetknął, już na zawsze zapamiętywał to doświadczenie, by potem móc o nim opowiadać.

Niezawodność oprogramowania

Na ten temat powstały książki. Serio! Niezawodność oprogramowania jest niesamowicie ważna, szczególnie, jeśli pracujecie w takich branżach jak medyczna, bankowa, lotnicza tudzież wszystkie inne, od których zależy dobro i życie człowieka (zawodność Cyber Panka była wkurzająca, ale raczej niczyje życie od niej nie zależało – no chyba że utopił oszczędności życia w akcjach, ale to inna historia). Niezawodność jest ważna. I tyle.

Ale nie środowisk testowych. Środowiska testowe są masakrycznie zawodne.

Przyczyną jest na przykład to, że przeznaczone jest dla nich stanowczo za mało zasobów. I na przykład: widziałam defekt, którego wyjaśnieniem okazało się przepełnienie testerskiej bazy danych. I to nie jeden, niestety. Na produkcji oczywiście nie powinno dość do takiej sytuacji. Ale na testach łatwiej jest oszczędzić.

Inną przyczyną może być brak prawidłowych procedur wrzucania gotowego kodu. I nagle okazuje się, że ostatnia poprawka spowodowała zawieszenie się całego systemu.

Kolejna rzecz – pracujemy na prototypach. A prototypy są niedopracowane, zamiast gotowych elementów są mockowane (mock to taka zaślepka, żeby nie było dziury w całym. Potem zastępuje się mocki docelowym kodem i powinno banglać). Jeśli nasz soft jest sprzężony z jakimś hard, albo wykorzystuje dowolne urządzenie (jakiekolwiek – pralkę, drona, termostat) – prawdopodobnie testerzy będą posiadali pierwszą wersję tego urządzenia. A jak coś jest prototypem, to nie ma prawa działać w 100% dobrze.

Dlaczego to takie irytujące?

Kiedy środowisko – z jakiegokolwiek powodu – nie działa, testerzy nie mają co robić. Nie da się testować, jeśli nie ma czego.

Testy czekają, czas ucieka. Środowisko leży.

Nie zrozumcie mnie źle. To nie jest tak, że testerzy oglądają wtedy jutuba i scrollują insta. Wykorzystują ten czas na uporządkowanie dokumentacji, zapoznanie się z kolejnymi wymaganiami, pisanie nowych przypadków, jeśli mogą to na przygotowanie danych testowych. Tej roboty jest dość. Ale sednem naszej pracy jest testowanie i to z niego jesteśmy rozliczani.

Na szczęście jest promyczek nadziei. Coraz częściej osoby decyzyjne rozumieją wartość testów i potrafią liczyć – i z tych wyliczeń wynika im, że koszty poniesione na dbanie o środowisko testowe szybko zwracają się, ponieważ testerzy (i nie tylko oni) nie robią pustych przebiegów.