Dzisiaj chciałbym opowiedzieć Ci o rzadko omawianych grzechach czyli błędach, które tester może popełnić. Mówi się, że każdy może być testerem i każdy się do tego zawodu nadaje. Zgadzam się z tym, tylko z małym „ale”, mianowicie musi być to osoba, która Chce. Ogólnie rzecz biorąc „chce”, czyli robi dużo by osiągnąć cel. To chcenie nie może skończyć się w momencie otrzymania oferty pracy. Tester, któremu się nie chce, nie będzie dobrym testerem. W tym wpisie wymienię błędy, które mogą spowodować, że kandydat pomimo posiadania niezbędnej wiedzy na testera, będzie, jeśli nie najgorszym to przynajmniej średnim testerem.
Głównym grzechem, który jako tester możesz popełnić jest niedokładne zgłoszenie defektu
Opisując defekt, powinieneś zrobić to tak, by nawet niezaznajomiona z aplikacją osoba, była w stanie go odtworzyć. Nie powinno być zatem skrótów myślowych. Kroki testowe powinny prowadzić do celu, jakim jest błąd. Załączniki mają pokazywać, gdzie jest błąd i nie mogą być wycinkiem obrazu. O tym, jak poprawnie zgłosić błąd napisałem w jednym z artykułów, zachęcam do jego przeczytania. Jakiś czas temu popełniłem również artykuł dotyczący współpracy testera i programisty. Napisałem w nim, że najczęściej programiści narzekają na nas w kontekście zgłaszanych bugów. Żeby nie było, że statystyki były brane z tak zwanej czapy. Zapytałem o to programistów z czterech różnych firm w Krakowie.
Na fotelu siedzi leń, nic nie robi cały dzień.
Zapewne część z was czytających temu przytaknie, inni się obruszą „bo jak to tak, taki rynek chłonny, tylu chętnych na jedno stanowisko, to jakim cudem utrzymują się lenie w pracy?”. No tak. Prawda. Mimo tego są osoby pracujące w zawodzie testera, które większość czasu pracy spędzają na tym, by przeglądać Internet. Oczywiście zdarzyć się może każdemu, że ma okres mniej produktywny z powodu spraw osobistych. Wówczas współpracownicy przymykają oko na jakiś czas. Niemniej, jednak jeśli chcesz być dobry w tym czy jakimkolwiek (wydaje mi się) zawodzie, to przeglądanie Facebooka i Internetu zostaw na czas po pracy.
Nie czyń drugiemu co tobie niemiłe. Czyli o chamstwie.
Branża informatyczna ma to do siebie, że w zespołach panuje raczej luźna atmosfera i poziom humoru może być naprawdę zwariowany. Natomiast trzeba pamiętać o tym, że zwłaszcza w momencie, gdy wchodzimy do nowego zespołu, to zanim wyskoczymy z żarcikami, należy poczekać i wybadać jakie poczucie humoru ma nasz zespół. Wszystko tylko po to, żeby nie zepsuć relacji z nowymi ludźmi już na dzień dobry ;).
Ja chce sam! Czyli przesadna samodzielność.
W myśl powiedzenia czas to pieniądz patrz na samodzielność jako na obusieczny miecz. Przykładowo dostajesz zadanie, które sprawia ci bardzo duże problemy, ponieważ wcześniej czegoś takiego nie robiłeś. Oczywiście powinieneś spróbować sam podejść do zagadnienia i je rozwiązać. W sytuacji, gdy zajmuje Ci to więcej niż 15 min, powinieneś poszukać pomocy wśród kolegów z zespołu. Zasadę 15 min wprowadził mój poprzedni zespół, w którym pracowałem i zdecydowanie polecam to rozwiązanie.
JA! Niechęć do dzielenia się wiedzą.
Cudownie czyta się posty na grupach typu Testowanie oprogramowania czy też Tester oprogramowania – wsparcie na starcie o pomocy wzajemnej i szerzeniu wiedzy. Z mojego doświadczenia niestety wynika, że w realnym świecie tak pięknie nie jest. Zresztą spójrzcie na wymienione wyżej grupy. Przeważnie na nich wypowiadają się te same osoby +/- parę nowych. Zmierzam do tego, że niestety wśród tak wielu firm w branży niewiele osób ma chęć do szerzenia wiedzy.
Nadmierna pewność siebie.
Kolejna teoretycznie dobra cecha, która w nadmiarze może nas doprowadzić do popełniania wielu błędów. Skutkować może ona głównie przestrzałami w estymacji czasu pracy. Pracy po łebkach, ponieważ „moje ścieżki są najlepsze i się nie mylę”. Pamiętaj, że nawet jeżeli jesteś najlepszy i na swój sposób dajesz radę, to tak naprawdę na sukces końcowy aplikacji czy firmy składa się praca całego zespołu. Ten zawód nie jest dla solistów!
Brak umiejętności przyjmowania i przekazywania konstruktywnej krytyki.
Tutaj po raz kolejny odwołam się do ulubionego przeze mnie Scruma. Jednym z elementów Scruma jest Retrospekcja. Spotkanie, którego tematem jest omówienie zakończonego Sprintu i wymienienie minusów i plusów. Wady i zalety mogą być ogólne, ale i personalne, wówczas możesz usłyszeć, że „Za późno zabrałeś się za zadanie X, przez co cel Sprintu został zagrożony”. Nie ma co się obrażać. Praca w IT to ciągła nauka i sztuka wyciągania z niej wniosków. Jeżeli ktoś nam zwraca uwagę, to nie bierzemy tego do siebie, tylko spinamy poślady i walczymy o lepsze jutro! 😉
I wreszcie ostatni problem, jakim jest stagnacja.
Ciesz się, że masz pracę. Trzymaj się jej. Masz świetną posadę i nie powinieneś jej zmieniać. Czy słyszałeś kiedykolwiek od kogoś podobne rady? Stagnacja i zasiedzenie w jednej firmie. Dobre czy nie? Prawda leży pośrodku. Mówi się, że zmiana pracy zmusza do rozwoju. Ja się z tym zgadzam. Zmiana pracy to zmiana aplikacji testowanej, narzędzi, nowe standardy pracy. Może jednak być tak, że w aktualnym miejscu pracy będziesz mógł np. wdrożyć nowe narzędzie, nowy proces. I ta zmiana będzie rozwojem dla Ciebie i firmy. Dlatego uważam, że nie musimy zmieniać pracodawcy, żeby się rozwijać, możemy to robić również w ramach naszej organizacji. Z drugiej strony w sytuacji, gdy nie ma szans na rozwój, nie powinieneś się obawiać zmian i ruszyć się z własnej strefy komfortu.
Czy wiesz, że nie tylko znalezienie pierwszej pracy jako tester jest trudne, ale znalezienie drugiego pracodawcy też?
Większość osób myśli, że znalezienie pierwszej pracy jako tester jest najtrudniejsze, potem już jest dużo łatwiej. Niestety pierwsza zmiana pracy może okazać się równie mozolna i problematyczna. Wynika to z tego, że mamy zbyt mało obszerną wiedzę np. biznesową. Przykładowo, jeśli testowałeś aplikacje finansowe, to nie poradzisz sobie z aplikacjami sklepowymi. Kiedyś sam szukałem drugiej pracy. Na zarzut posiadania zbyt małej wiedzy odpowiedziałem „mam w tym zakresie drobne braki, ponieważ w poprzednim projekcie tego nie robiliśmy, lecz bez problemu szybko je nadrobię, np. ucząc się samodzielnie z Internetu”.
W odpowiedzi usłyszałem: „Niestety, ale braki wiążą się z tym, że musielibyśmy Panu pomagać, a tego nikt nie chce robić, bo każdy ma swoją pracę, pomoc wiązałaby się z nadgodzinami”. Dlatego uważam, że w tym zawodzie zasiedzenie w jednym projekcie, nieuczenie się nowych narzędzi i niebycie na bieżąco kończy się tym, że któregoś dnia nawet tester z kilkuletnim doświadczeniem siada do CV i nie wie co w nim wpisać.
Kilka słów na zakończenie
Chciałbym, abyś wiedział, że napisałem ten artykuł bazując na mojej własnej subiektywnej obserwacji i doświadczeniu. Nie musisz się ze mną zgadzać, że wymienione w nim błędy testerów są nimi w ogóle. Jeśli jesteś zainteresowany tym jakie cechy charakteru powinien mieć dobry tester, zachęcam Cię do przeczytania artykułu na ten temat, znajdziesz go na moim blogu.
