5 mitów o testowaniu oprogramowania
Testy? A na co to komu? Czyli słów kilka o mitach w naszej branży.
Mity są naturalną częścią naszego życia, więc nic dziwnego, że dotarły też do branży IT czy bardziej konkretnie - testowania oprogramowania. Nieznajomość danego tematu sprawia, że zaczynają wokół niego krążyć nieprawdziwe informacje. Czasami powodem jest niewiedza, a czasami złośliwość (nieśmiało kieruję teraz palec w stronę "ludzi od biznesu" i programistów 😅). Nie ma co się obrażać, trzeba obalać! Przed Wami 5 mitów o testowaniu oprogramowania i moje próby obalenia ich.
Automatyzacja może zastąpić testy manualne
Nie da się ukryć, że automatyzacja niezwykle wzbogaca proces testowy. Wpływ testów automatycznych jest szczególnie widoczny podczas regresji. Pokryte przypadki testowe nie muszą być za każdym razem sprawdzane ręcznie, co przyspiesza przebieg testów. Ale automaty kompletnie nie sprawdzają się w testach UX (User Expierence), gdzie weryfikowana jest użyteczność oprogramowania. Każda aplikacja powinna być atrakcyjna dla użytkownika i przyjazna w użyciu - a to można sprawdzić wyłącznie manualnie.
Poza tym testy automatyczne nie mogą istnieć bez testów manualnych. Nawet jeśli chcemy pokryć dany przypadek testowy automatami, to najpierw musimy skontrolować go ręcznie. Kolejna sprawa - nie wszystko da się zautomatyzować. Niektóre funkcjonalności oprogramowania są na tyle złożone, że automatyzacja ich przypadków użycia jest po prostu nieopłacalna. Często lepszym rozwiązaniem są testy manualne, a nie czasochłonne testy automatyczne.
Testowanie jest łatwe
Niestety, sporo osób wchodzących do branży IT traktuje testowanie jako trampolinę do innych stanowisk (zazwyczaj związanych z programowaniem). Z takiego zachowania wyrósł mit mówiący, że testowanie jest łatwe. Używając klasyka - nic bardziej mylnego! Jasne, nie będę się upierał, że bezmyślne podążanie za napisanymi przez kogoś scenariuszami testowymi jest skomplikowane. Ale zakres obowiązków testerów jest znacznie szerszy (nie wspominając już o takich pozycjach jak QA Engineer).
Dalej zdarzają się dyskusje, czy testy w ogóle są potrzebne. Przecież programiści mogą sprawdzać swoje zmiany. Oczywiście, że mogą. Ale czy zrobią to dobrze? Jestem pewien, że nie. Testowanie swojej pracy nigdy nie jest obiektywne. W takich sytuacjach zazwyczaj sprawdzane są tylko podstawowe przypadki - a zadaniem testerów jest wynajdowanie ścieżek, które nie przyszły do głowy twórcom. Co więcej, tester powinien też wcielić się w role klienta i ocenić, czy aplikacja jest przyjazna dla użytkowników. Temat ten rozwinąłem w osobnym wpisie - po co testujemy oprogramowanie?.
Testerzy opóźniają wdrożenia
Na końcu mit dotyczący głównie biznesu - czyli potocznej nazwy na nietechniczną część organizacji podejmującej decyzje o tworzonym produkcie. Wiadomo, firma musi zarabiać, a jedną ze składowych wpływających na wysokość zarobku jest szybkość dostarczenia oprogramowania klientowi. Biznes więc delikatnie nas naciska, aby prace dobiegały końca. Zbliżamy się do fazy wdrożenia (czyli dostarczenia zmian lub całej aplikacji klientowi), testerzy przeprowadzają ostatnie testy, a tu nagle - nowe błędy! No cóż, to nie wina testerów, że w oprogramowaniu znajdują się błędy. Swoją drogą, lepiej, że zostały one znalezione przez nas, a nie przez klienta - bo każdy błąd ma swoją cenę.
Przede wszystkim, w dzisiejszych czasach raczej ciężko złapać pracę jako "klikacz". Firmy wymagają przynajmniej podstawowych umiejętności technicznych - praktycznej znajomości protokołu HTTP, analizowania logów czy biegłości w testowaniu API. Jest też sporo narzędzi do opanowania, a i wiedzę domenową warto rozwijać - bez ciągłej nauki i adaptacji jest ciężko. Powyżej widzicie kilka przykładów - jest tego sporo, no nie?
Testerzy wykonują prace na końcu
Kolejny mit wynika z przestarzałego podejścia do pracy testerów. W zamierzchłych czasach testerzy otrzymywali gotowy produkt, a ich jedynym zadaniem było przeklikanie go i wyszukiwanie potencjalnych błędów. Czasy się jednak zmieniły, więc obecnie testerzy uczestniczą w cyklu życia oprogramowania od samego początku. Tzw. shift-left testing (przesunięcie testowania w lewo, czyli do wczesnego etapu tworzenia aplikacji) zakłada, że testowane są już nawet wymagania biznesowe! Zadaniem dzisiejszych testerów jest ocena, czy planowane oprogramowanie będzie miało sens w praktyce.
Testy? A komu to potrzebne?
Chcesz być na bieżąco? Zapisz się do newslettera!
W każdy czwartek o 10:00 wyślę Ci wiadomość o moich nowych wpisach. Oprócz tego, dorzucę ciekawe artykuły, filmy czy inne materiały ze świata IT - oczywiście, związane głównie z testowaniem oprogramowania. To świetny sposób na naukę i ciągłe zdobywanie wiedzy.
Dziękuję, że czytasz mojego bloga!
Masz jakieś pytania? Z chęcią odpowiem :)
