Po co nam testerzy?
Przecież programiści sami mogą testować swój kod...
Nie ma co się oszukiwać. To programiści piszą kod, a z kodu wynikają wartościowe dla biznesu funkcjonalności - wytworzone oprogramowanie da się po prostu sprzedać. Teoretycznie testerzy są dodatkowym kosztem nie wpływającym na finalną wartość produktu. Przecież programiści sami mogą sprawdzić swoje zmiany. A mimo tego, rynek pracy dalej wchłania testerów i innych specjalistów od utrzymania jakości aplikacji. Z czego to wynika?
Obiektywne spojrzenie
Zgadzam się z tym, że programiści mogą sami sprawdzić wprowadzone modyfikacje - zresztą, często to robią (w tym miejscu chciałbym podziękować programistom, którzy nie oddają do testów od razu wywalającej się aplikacji 😄). Problem w tym, że oceniając własne dzieło, trudno zachować obiektywność. W takich sytuacjach najczęściej weryfikowane jest tylko podstawowe działanie oprogramowania, bez głębszej analizy tego, jak może zachować się użytkownik.
A wierz mi, użytkownicy potrafią wymyślić nieskończoną liczbę sposobów na "popsucie" aplikacji. Tutaj do gry wchodzi tester, którego zadaniem jest nie tylko sprawdzenie zgodności z założeniami projektowymi, ale także spojrzenie na oprogramowanie z perspektywy użytkownika. Tester nie może ograniczać się wyłącznie do testowania scenariuszy pozytywnych, lecz powinien również analizować przypadki negatywne.
Dodatkowo, testerzy pomagają znaleźć miejsca, w których interfejs lub funkcjonalności mogą być nieintuicyjne lub trudne w obsłudze, co pozwala na usprawnienie aplikacji z punktu widzenia użytkownika. Dział QA nie tylko szuka błędów, ale potwierdza, że oprogramowanie spełnia oczekiwania klientów. No wiesz, żeby można było powiedzieć: "będzie Pan zadowolony!" 😅
Przecież i tak są bugi!
I w tym miejscu rozbrzmiewają głosy: "mamy testerów, a i tak są bugi!". Tak, są. Często nawet na produkcji. Błędy były, są i będą - niezależnie od tego, ilu testerów jest w projekcie. Nawet szczegółowe testy regresji nie pokryją wszystkich ścieżek aplikacji - chyba, że mówimy o niezwykle małym produkcie (a to się rzadko zdarza w biznesowych projektach). Zawsze znajdzie się przynajmniej to jedno nieodkryte zachowanie oprogramowania.
Zadaniem testerów (czy ogólnie działu QA) jest ograniczenie bugów do akceptowalnego przez biznes minimum. Na początku wspomniałem o braku wpływu testerów na finalną wartość produktu. Jeśli wartość mierzymy wyłącznie poprzez liczbę funkcjonalności do sprzedania - to prawda, testerzy nie dodają nic nowego. Ale na zyski firmy wpływa też jakość oferowanego oprogramowania. Nikt nie chce korzystać z aplikacji wypełnionych błędami. Klienci wymagają sprawnie działających, intuicyjnych i odpowiadających im potrzebom produktów.
Zaufanie do produktu
Odpowiedź na pytanie zadane w tytule wpisu mógłbyć skrócić do jednego zdania - testerzy budują zaufanie do oprogramowania. Dział QA potwierdza, że aplikacja spełnia swoje funkcje i dba o to, by nie zostały sprawdzone wyłącznie happy pathy. Przełożenie wymagań taska na kod nie oznacza, że dana funkcjonalność rozwiązuje problem użytkownika - tu do akcji wkracza tester i wciela się w rolę klienta. Oczywiście, istotne są też kwestie techniczne, jak pisanie automatycznych testów E2E, czy ciągłe usprawnianie procesu utrzymania jakości.
Nie ma testów, nie ma problemu :D
Co o tym myślisz? Daj znać w komentarzu:
Chcesz być na bieżąco? Zapisz się do newslettera!
W każdy czwartek o 10:00 dam Ci znać o moich nowych wpisach.
Dorzucę też ciekawe artykuły, filmy czy inne materiały ze świata IT.
Po zapisie do newslettera, wyślę Ci darmowego ebooka z checklistami dla testerów.
Polecane wpisy:
Sprawdź też moje social media:
Dziękuję, że czytasz mojego bloga!
Masz jakieś pytania? Z chęcią odpowiem :)