Zadowolenie testerów miarą dojrzałości procesów

Świat IT bez tajemnic

Zadowolenie testerów miarą dojrzałości procesów

Chociaż ich liczba wydaje się sukcesywnie zmniejszać, nadal istnieją firmy, które wytwarzają oprogramowanie nieprzechodzące przez ręce testerów. Skutki tego są różne, podobnie jak przyczyny – czasem brakuje funduszy, innym razem osoby odpowiedzialne za podejmowanie decyzji nie widzą potrzeby zmieniania czegoś, co jakoś funkcjonuje od lat. Zdarza się jednak, że po serii niefortunnych zdarzeń, znanych w świecie IT pod wiele mówiącym osobom znającym angielski kryptonimem „fakapy”, zatrudnia się osoby, których zadaniem jest przeprowadzenie rewolucji i zaproponowanie rozwiązań, które powtórkom takowych „fakapów” zapobiegną. Do modnych kierunków zmian należy przejście na zwinne metodyki wytwarzania oprogramowania i zatrudnienie osób odpowiedzialnych za zapewnianie jakości. Jeśli więc firma dysponuje odpowiednio zasobnym portfelem, wystawia ogłoszenie o poszukiwaniu test managera i kilku specjalistów z dziedziny testowania, być może również scrum mastera (o ile nie zostanie nim w wyniku łapanki któryś z deweloperów, bo jeśli nie pracowało się nigdy w scrumie, trudno uwierzyć, że może to być pełnoetatowe zajęcie, które polega na czymś więcej niż tylko zaganianiu teamu na daily). Czy jednak sama obecność testerów i praca w sprintach wystarczą do stwierdzenia, że proces wytwórczy firmy osiągnął dojrzałość?

Zdecydowanie nie. Wręcz przeciwnie – powstał całkiem nowy proces, który dopiero zaczyna się kształtować i jeszcze wielokrotnie napotka przeszkody i opory. Nim osiągnie wysoki poziom skuteczności, praca osób w niego uwikłanych będzie trudna i frustrująca. Testerzy wydają się być przy tym grupą specjalistów, których dobrostan może służyć za papierek lakmusowy poziomu dojrzałości procesu. Dlaczego?

Chaos przed releasem

Czas przed wypuszczeniem oprogramowania na „produkcję” jest bolesny dla wszystkich, ale jeśli release odbywa się chaotycznie, testerzy cierpią szczególnie. Sprawdzają po godzinach szybkie poprawki, walcząc nieraz o to, żeby nie były one przepychane za ich plecami, bez testów, jak najszybciej. Wielokrotnie weryfikują to samo, żeby mieć pewność, że nagle wrzucona poprawka nie zepsuła czegoś, co dotychczas działało… A na koniec i tak coś w tym chaosie przeoczą i będą czuli, że zawalili.

Frustrujące obłożenie pracą na przemian z jej brakiem

Temu zjawisku z kolei mogą być winne sprinty, które planowane są przez osoby pracujące dotychczas w innych metodologiach. Zadania do wykonania nadal są wielkie, programiści siedzą nad nimi wiele dni i w efekcie przez pół sprintu tester nie ma co robić, by na koniec zostać zawalonym robotą, kiedy wszyscy nagle pokończą swoje „kobyły”.

Trudności z właściwym wykonaniem swojej pracy

Jeśli panuje dezinformacja co do wymagań, a programiści pracują na podstawie szczątkowej dokumentacji, skrawków informacji w komentarzach do zadania i paru maili od osób decyzyjnych, testowanie efektów ich pracy staje się błądzeniem po omacku. Szuka się informacji, co miało być zrobione, zgłasza błędy, po czym programiści przychodzą z pretensjami, że to nie błąd, tylko zmieniło się wymaganie i tak powiedział im … (tu padają dane analityka lub dowolnej innej osoby z uprawnieniami do podejmowania takich decyzji). Dobrze, jeśli udało im się zdobyć na to dowody na piśmie, na przykład w formie maila. Mail taki dorabia się wówczas zaszczytnego miana „dupokryjki” i może zostać wykorzystany również przez testera. Czasem jednak programiści twierdzą, że coś miało tak być, a tester wierzy i przepycha wszystko dalej jako zweryfikowane pomyślnie. Następnie inny analityk wraca z urlopu albo włącza się do dyskusji jeszcze ktoś inny (najgorzej, jeśli jest to klient już po otrzymaniu oprogramowania) i twierdzi, że to przecież miało być zupełnie inaczej.

Niska samoocena

Jedną ze znamiennych cech niskiej dojrzałości organizacyjnej jest poczucie wyższości, jakie programiści mają nad testerami. Często przychodzi to „z góry” w postaci dysproporcji w wypłatach i traktowania testów jako niepotrzebnego utrudnienia procesu, które można ewentualnie dopuścić, jeśli jest czas. Kiedy coś się „pali”, wpada się w panikę i wraca do korzeni, i na przykład zaczyna śledzić bugi w tabelkach w Excelu, ignorować zgłaszane błędy, o ile wszystko mniej więcej działa, przepychać poprawki za plecami testerów, bo przecież programista sobie przetestował i działało (a że innemu pół funkcjonalności przy tym wywaliło, to już pół biedy). Nieśmiałe uwagi dotyczące użyteczności są puszczane mimo uszu, no bo o co chodzi, skoro działa. Testerzy są też pierwsi do zwolnienia w przypadku cięć, a ci, którzy zostają, mają o wiele za dużo pracy, przez co nie spisują się do końca dobrze. Niechętne testerom środowisko upewnia się, że są oni niepotrzebni, skoro jakość i tak kuleje – i koło się zamyka.

Reasumując – jeśli team testerski snuje się po open space z nietęgimi minami, prawdopodobieństwo, że procesy wymagają podrasowania jest całkiem spore.

Dodaj komentarz

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