O tym, jak firmy czasami podchodzą (a nie powinny) do testów

Mamo u Krzyśka to jest fajnie, on sprząta tylko w sobotę! A mama na to, synku „Co kraj to obyczaj”, a teraz bierz odkurzacz i zacznij od salonu. Dzisiaj właśnie o tym będzie wpis, czyli, że każda firma to inne testowanie. A dokładniej skupię się na tym, by pokazać Ci, jakie moim zdaniem niewłaściwe podejście do testów i testerów miałem okazję widzieć w mojej karierze.

Zanim jednak zaczniemy, podziękowania! Mateusz, dziękuję za komentarz z prośbą o rozwinięcie tematu zaczętego we wpisie o mitach w testowaniu oprogramowania. I tym samym zachęta, jeśli Ty czytelniku masz temat, który Ciebie interesuje, napisz o tym w komentarzu. A ja, postaram się go rozwinąć.

Jeżeli jesteś osobą obytą na rynku pracy, tzn. masz jakieś doświadczenie, pracowałeś u więcej niż jednego pracodawcy, to zapewne nie raz spotkałeś się ze słowami padającymi z ust Projekt Managera/HR-ów: „W naszej firmie zwracamy bardzo dużą uwagę na jakość – nie to, co w innych firmach”. Słowa te lub podobne usłyszysz w wielu firmach, które działają na rynku od lat i oczywiście częściowo mogą mieć rację, ale też nie do końca.

W ramach tego wpisu chcę Ci przybliżyć grzeszki, które się potrafią schować za tymi jakże ładnymi i obiecującymi słowami :).

Jedno na rozmowie co innego w rzeczywistości

Mam wrażenie, że bardzo często zdarza się uczestnikowi karuzeli rekrutacyjnej trafić na ofertę, w której oczekiwania względem kandydata są bardzo wysokie. Przykładowo wymagana znajomość Selenium, języka programowania, a koniec końców okazuje się, że wykonujesz testy manualne, projekt nie ma testów automatycznych, ale może kiedyś będą… znaczy plany są. Zdarza się dość często, że po zatrudnieniu będziesz wykonywać 30% tego, co jest weryfikowane na rozmowie kwalifikacyjnej. Nie byłoby to takie złe, jeśli nie zależało Ci na nauce automatyzacji, chciałeś tylko dostać pracę. Jeśli jednak chciałeś po zatrudnieniu ugruntować zdobytą samodzielnie wiedzę i rozwijać ją, to będziesz mocno zawiedziony czekającymi Cię obowiązkami.

Jakiś czas temu na rozmowie kwalifikacyjnej na stanowisko testera rekrutowałem bardzo zdolną dziewczynę. Jej rekrutacja przebiegła bardzo dobrze, byłem totalnie za tym, by ją zatrudnić. Było tylko jedno, ale, dziewczyna chciała iść w stronę automatyzacji, a mój obecny projekt to było „szambo”, które dodatkowo nie zobaczyłoby automatyzacji przez następne milion lat. Nasz PM stwierdził, że dobrym pomysłem jest okłamanie jej, że będziemy automatyzowali i robili fajne rzeczy, bo chciał ją mieć w zespole. Skutkiem tego było jej rozczarowanie i rezygnacja z pracy po 3 miesiącach.

Kiedy sam zaczynałem swoją przygodę z testowaniem i rekrutowałem się do jednej z Krakowskich firm, chciałem przede wszystkim się mocno rozwijać. Do jednej z firm rozmowa poszła całkiem dobrze, dostałem pracę. Po rozmowie byłem nastawiony na to, że będę się uczył. Natomiast po zatrudnieniu okazało się, że moje codzienne obowiązki nie miały wspólnego nic z obiecanym rozwojem, na który byłem nastawiony podczas rozmowy rekrutacyjnej.

Zrzucenie odpowiedzialności na testy

Na pewnym etapie pracy każdy chyba tester zmierzył się z pytaniami:

• „Dlaczego tego nie wyłapałeś?” – kiedy to klient znalazł błąd i go zgłosił.
• „Czemu tak późno?” – kiedy zgłaszasz błąd wysoki tuż przed wystawieniem wersji.
• „Dlaczego tak mało błędów zostało zgłoszonych?” – kiedy mimo testów, poświęconego czasu i nakładu pracy, zgłoszonych błędów jest mniej niż zazwyczaj.
• „Dlaczego tak dużo błędów zostało zgłoszonych?” – kiedy wprost przeciwnie błędy wyskakują jak grzyby po deszczu.

Czasami takie pytania prowadzą do zamknięcia działu testów, bo wiesz, nie ma testów, nie ma błędów ;).

Czasami następuje przesunięcie testów na dalszy etap wytwarzania oprogramowania, czyli na testy wykonywane przez użytkownika końcowego. Tego typu podejście ma bardzo często poważne konsekwencje. Koszt naprawy błędu rośnie i zależy od tego, jak wcześnie jest znaleziony.

Nie rozumienie testów

Na pewno zderzyłeś się z sytuacją, że Twój kumpel/znajomy/sąsiad miał coś, co Cię zainspirowało do tego, żeby nabyć to samo. Nabyłeś daną rzecz, mimo że wiedzy w danej dziedzinie nie miałeś.

Testowanie jest częścią procesu wytwarzania oprogramowania od bardzo dawna. W jednym projekcie jest ono bardziej zorganizowane, w drugim mniej zorganizowane. To, co bardzo często nie zmienia, to fakt, że firmy nie rozumieją, czym testowanie jest, nie potrafią przedstawić celów testowania, jak i nie potrafią sobie często zbudować procesu testowego.

Oczywiście nie wszędzie jest tak źle, niemniej pamiętaj, że jeżeli mamy 1000 firm na rynku to X% firm ma to jakoś poukładane a pozostałe nie. Zresztą w ramach tych firm, które mają pewne procesy poukładane, też nie wszędzie są one wdrażane (tu pojawia się tak zwane „to zależy” + mniej/bardziej priorytetowe projekty). Delikatny spojler na sam koniec – kolejnym wpisem będzie praca w kontraktorniach i ich plusy i minusy :).