Czy w firmie, w której pracujesz jest dział testerów? Jeżeli jesteś z Polski, to jest bardzo duże prawdopodobieństwo, że takiego działu nie masz. Co dziwniejsze jeszcze, że im większa i poważniejsza firma, tym mniejsze szanse na istnienie działu testerów! A to dziwne!
Poniżej prezentuję 5 najbardziej prawdopodobnych powodów, dla którego w firmie, w której pracujesz nie ma działu testerów, razem z komentarzem. Powody i uzasadnienia pochodzą w dużej mierze ze świetnego artykułu Joela Spolskyego (Top Five (Wrong) Reasons You Don’t Have Testers).
Więc zaczynamy.
1. Błedy w oprogramowaniu wynikają z lenistwa programistów.
“Zatrudnienie testerów w naszej firmie spowoduje, że programiści przestaną sami testować to co tworzą i w kodzie będzie więcej błędów” – Mogło by się wydawać… Błędy w oprogramowaniu (bugi) powstają w kodzie w związku z tym, że programista ich z jakiegoś powodu nie zauważył. Programista to też człowiek, a nie ma ludzi nieomylnych. Najczęściej wystarczy, aby druga osoba spojrzała na kod/produkt aby wyłapać większość błędów. Często zdarzają się sytuacje w których coś, działające na 100% u programisty nie działa u testera. Podczas konfrontacji okazuje się, że testerka podczas rejestracji w przykładowym systemie wybierała inną płeć niż programista co w efekcie implikowało różnice.
2. Moje oprogramowanie jest dostępne on-line. Mogę naprawiać błędy od ręki.
Mogłoby się wydawać… Prawdą jest, że wprowadzanie poprawek w systemach będących on-line jest z jednej strony nieco łatwiejsze niż w przypadku aplikacji desktopowych, jednak z drugiej jest znacznie trudniejsze, ponieważ działamy na żyjącym organizmie, w momencie kiedy wprowadzamy poprawki, użytkownicy korzystają z naszej aplikacji, używają naszego serwisu. Takie poprawki “na szybko”, najczęściej wykluczają przeprowadzenie testów regresywnych i bardzo często prowadzą do stworzenia kolejnych błędów. Błędy takie są widoczne od razu dla użytkowników, co zmniejsza ich satysfakcję i prowadzi do punktu następnego:
3. Użytkownicy przetestują mi oprogramowanie.
Nie powinno się tak nawet nikomu wydawać… Z takim podejściem nie wróżę sukcesu. Jeżeli coś użytkownikowi przestaje działać – idzie do konkurencji – to w najlepszym przypadku. W gorszym, idzie do konkurencji i zaczyna rozpowiadać o naszej firmie brzydkie rzeczy, co powoduje zmniejszenie przypływu nowych użytkowników, bądź utratę większej ilości aktualnych. W jeszcze gorszym przypadku, użytkownik podczas korzystania z naszej aplikacji traci swoje dane (jakąś swoją pracę), lub jego dane osobowe zostają np. przypadkowo wysłane mailem do 100000 innych użytkowników co prowadzi do sprawy w sądzie i innych kłopotów – a tego nie chcemy. Specjalnym przypadkiem są tutaj beta-użytkownicy – jednak jest to specjalnie wyselekcjonowana grupa użytkowników, którzy świadomie podejmują pracę na niefinalnej wersji oprogramowania.
4. Nikt z odpowiednimi kwalifikacjami nie chce pracować jako tester.
Nie jest to do końca prawdą. Z jednej strony trudno jest o dobrego testera. Z drugiej jednak testy funkcjonalne nie wymagają wysokich kwalifikacji. Najlepszymi testerami funkcjonalności, są ludzie nie związani bezpośrednio z IT, warto pomyśleć o zatrudnieniu studentów kierunków humanistycznych, którzy są w stanie znaleźć bardzo dużo problemów w tworzonym przez nas oprogramowaniu.
Jest prawdą natomiast, że trudno o pracowników potrafiących uruchamiać i przeprowadzać testy jednostkowe oraz inne testy wymagające znajomości specjalistycznego oprogramowania, platform i języków skryptowych. Z drugiej strony jednak sam znam kilku dobrych testerów, którzy bardzo chętnie będą kontynuować swoją karierę jako testerzy.
Ostatni z powodów, najpopularniejszy i najbardziej bzdurny:
5. Nie stać mnie na testerów.
I jednocześnie najłatwiejszy do obalenia. Testerami w firmie mogą być praktykanci, studenci odbywający praktyki oraz np. uczniowie szkół ponadpodstawowych za niewielkie pieniądze. Ile testerzy by nie kosztowali – zawsze są tańsi niż programiści (mówimy o testerach funkcjonalności, a nie np. specjalistów od przeprowadzania testów użyteczności). Nie opłaca się, aby programiści poświęcali swój czas na testowanie, skoro w tym czasie mogą poprawiać błędy, oraz rozwijać oprogramowanie.
W początkowym stadium “zespołu testowego” warto prowadzić rekrutację, mimo kompletu testerów, i szybko wymieniać tych, którzy nie nadają się na testerów. Poza tym średnio tester pracuje na swoim stanowisku ok. 3-4 miesięcy, więc rotacja w takim zespole jest spora.
Nie warto jednak proponować swoim przyszłym programistom stanowisko testera na czas “wdrożenia”, ponieważ mogą znudzić się zadaniami testowymi i możemy stracić dobrego programistę.
Dodatkową opcją są agencje pracy tymczasowej i pracy dla młodzieży (np. http://www.timework.pl), gdzie za niewielkie pieniądze można zatrudnić młodych ludzi do prostych prac.
