7 grzechów testerów

Co testerzy mogliby robić w pracy lepiej? Co przysparza im trudności i powoduje obniżenie jakości… zapewniania jakości? Jakie powtarzalne problemy występują w branży? Poznajcie 7 grzechów testerów - z przymrużeniem oka.

Wpis został zainspirowany postem “7 grzechów programistów” fs.geek na Instagramie, który to profil polecam obserwować!

1. Niedokładne wykonywanie testów

Niekiedy wykonujemy testy “po łebkach”, mało dokładnie i bez dbałości o szczegóły. Mogą się do tego przyczynić na przykład chwilowe zmęczenie pracowitym dniem albo permanentne znużenie długo trwającym, monotonnym testowaniem regresji w jednym projekcie. W pierwszym przypadku warto zrobić przerwę i odpocząć, a do testowania wrócić następnego dnia - lepiej mniej pracy, ale lepszej jakości. W drugim przypadku można zastanowić się nad możliwością zautomatyzowania testów regresji albo zmianą projektu na nowy (powtarzalne wykonywanie manualnie tych samych przypadków testowych prędzej czy później prowadzi do znużenia i jeśli nie ma szans na automatyzację zmiana projektu jest rozwiązaniem rekomendowanym przez wielu specjalistów). Tester dzierży w swoich rękach sito wyłapujące defekty i jakość jego pracy jest bardzo ważna!

2. Zgłaszanie defektu przed zakończeniem testowania

Mam na myśli sytuację, w której jeszcze nie dokończyliśmy wykonywania przypadku testowego i nie upewniliśmy się, że występująca awaria jest faktycznie skutkiem defektu (a nie naszej własnej pomyłki albo złej konfiguracji), a już zgłaszamy defekt programistom. Może do prowadzić do sytuacji, w której w połowie przygotowywania raportu defektu orientujemy się, że nie jest on tak naprawdę defektem i tracimy czas.

3. Brak komunikacji

Testerzy i QA stanowią często pomost pomiędzy biznesem oraz częścią techniczną zespołu. Tym samym ich zdolności komunikacyjne są niczym smar w dobrze naoliwionej maszynie, którą jest w tym przypadku projekt. Im lepsze umiejętności komunikacji i jej inicjatywa, tym sprawniej działa zespół. Oczywiście nie każdy musi być od razu rozgadanym ekstrawertykiem - czasem wręcz mniej (ale jasno i konkretnie) znaczy lepiej.

4. Brak chęci rozwoju technicznego i domenowego

QA musi wiedzieć co nieco o wielu obszarach w projekcie. Nie musi znać się dogłębnie na wszystkim, ale pewna dozą wiedzy technicznej i biznesowej jest niezbędna do efektywnej pracy. Warto znać branżę, dla której produkujemy oprogramowanie, ale warto też poznać architekturę tegoż oprogramowania i rozumieć jak działa pod spodem. Wiedza domenowa pozwala na komunikację z biznesem, a wiedza techniczna - na dokładniejsze testowanie, w perspektywie także przykładowo na automatyzację testów.

5. Nieumiejętność stawiania granic

Dobrze, jeśli tester jest proaktywnym członkiem zespołu, ale należy znaleźć złoty środek. Branie na siebie zbyt wielu obowiązków i wchodzenie w zakres kompetencji innych członków zespołu powoduje chaos, przemęczenie i frustrację. Przykładowo debugowanie defektu (dodatkowo oprócz jego zgłoszenia) i naprawianie go (czyli wykonywanie zadania programisty) powoduje zanik niezależności testowania i developmentu, która to niezależność ma istotną rolę w projekcie i jest pożądana.

6. Poddanie się brakowi jakości

Nie raz widziałam sytuację, którą nazywam poddaniem się brakowi jakości. “Nie zgłaszaj tego, to nigdy nie działało”, “to się zepsuło pół roku temu, wszyscy już się przyzwyczaili”, “nie ma sensu drążyć”. Im dłuższy czas od momentu dołączenia do projektu, tym silniej działa ten mechanizm. Na początku jesteśmy pełni werwy i chcemy jak najlepiej, z czasem poddajemy się negatywnemu nastawieniu reszty zespołu. Oczywiście nie znaczy to, że każdy kosmetyczny defekt musi zostać od razu naprawiony. Priorytetyzacja jest ważna, zasoby są ograniczone i niemal nigdy nie osiąga się idealnego stanu. Jednak nie można też poddać się zupełnie i rezygnować z prób zapewniania jakości, “bo i tak wszyscy przywykli” do jej braku.

7. Niedocenianie siebie

“Ja tu tylko testuję”, “jestem klikaczem”, “tester to taki mniej zdolny developer”. W niektórych miejscach nadal pokutuje stereotyp testera albo QA jako osoby, która tylko przypadkiem pracuje w IT i właściwie nie zna się na niczym wartościowym :( Na szczęście jest to coraz rzadsze, natomiast nadal jest wiele do zrobienia w kwestii zmiany mentalności. Nie zbawimy całego świata, ale możemy zacząć od siebie samych i naszego zespołu. Pokażmy otoczeniu, że nasza praca jest cenna i że wnosimy wartość do zespołu!