Drogi odbiorco tego tekstu :) Za pomocą przewrotnego tytułu chcę zwrócić Twoją uwagę na pewien interesujący fakt.
Często zdarza się tak, że w zespołach zwinnych, czyli pracujących w metodyce zwinnej (agile) tester zajmuje się o wiele większą ilością spraw, niż poszukiwanie i zgłaszanie błędów, proponowanie usprawnień czy pisanie przypadków testowych.
Ktoś powie, że to oczywiste i nie ma o czym gadać. I że tak jest w każdej branży. Zaryzykowałabym jednak twierdzenie, że warto pochylić się nad tym tematem.
Jeśli jestem testerem, to jest moja główna rola i w tej profesji chcę się realizować, dlaczego miałabym dopisywać kod po programiście albo pilnować backlogu zamiast product ownera? A może spełniam obowiązki scrum mastera, bo moja firma nie przewidziała takiego stanowiska w swych strukturach? Czy zastanawiałaś/eś się kiedykolwiek, czy to co robisz w pracy jako tester albo co czytasz w ofertach pracy na testera to jest jakiś zestaw umiejętności i cech wspólny całemu rynkowi testerskiemu?
Gdzie jest granica między “moimi właściwymi obowiązkami”, a całą masą mniejszych lub większych zadań pobocznych? Z pewnością odkryjemy tą granicę, kiedy pochłonie nas już czeluść ASAPów i niedoczasów. Tylko czy warto do tego dopuścić?
Uwaga 1: w tekście używam rzeczownika “tester” w trzeciej osobie liczby pojedynczej rodzaju męskiego wedle reguł języka polskiego z czysto ergonomicznych względów :) Pod wyrażenie to można w zakresie całego tekstu podstawić rodzaj żeński tj. “testerka”.
Uwaga 2: pisząc ten artykuł odnoszę się do całości swojego doświadczenia, nie zaś do firmy, w której pracuję.
Zacznijmy od prostego, acz podchwytliwego pytania:
Czy tester musi być człowiekiem renesansu by przetrwać na rynku pracy?
Opcja 1: Nie,
Opcja 2: Nie. Ale nie zaszkodzi.
Opcja 3: Tak.
Opcja 4: To zależy (sic!).
Opcja 5: …
Z mojego doświadczenia wynika, że “tester” niejedno ma imię. Co firma to pod tym stanowiskiem kryje się nieco inny zestaw obowiązków.
Z czego to wynika? Czy to dobrze, czy to źle? Dlaczego nie przygotujemy i nie podbijemy pieczątką “jedynej słusznej listy obowiązków testerskich”? Czy da się stworzyć jakiś zbiór głównych kompetencji, którymi należy się wykazać, by być dobrym testerem?
W niniejszym tekście zastanowię się nad odpowiedziami na wspomniane pytania.
Zapewne “problem omnipotencji i uniwersalności” znany jest wielu branżom i zawodom, jednak w tym artykule skupię się na naszym testerskim podwórku.
Na pierwszy ogień wysunę tezę, iż unifikowanie obowiązków testerskich w jedną, nieelastyczną listę jest działaniem niewłaściwym.
Byłoby to wygodne, niemniej stanowczo ograniczałoby rynek i konkurencyjność firm. Mogłoby też grozić to tym, że zarabialibyśmy mniej, gdyż mielibyśmy mniej możliwości konkurowania kompetencjami. Skoro na liście jest tylko x punktów to w zakresie tej ilości można wykazać się podstawowym, ugruntowanym lub eksperckim poziomem znajomości poszczególnych punktów. I tyle, koniec, kurtyna. A przecież jest tyle technologii, tyle sposobów ich użycia i tyle firm.
Dodatkowo, sztucznie ograniczając zakres testerskich obowiązków firmom mogłoby być trudniej sprostać oczekiwaniom klientów, bo rzadko wiadomo od A do Z, jakim klientem okaże się dany kontrahent oraz czy projekt przebiegnie tak, jak został zaplanowany, z takim zestawem narzędzi i potrzebnych kompetencji, z jakim został zaplanowany.
Zatrudnienie zaś kogoś na szybko i krótko jest nieraz zadaniem karkołomnym i kosztownym więc rozwiązanie takie może okazać się nieopłacalne zarówno dla firmy, jak i dla klienta.
No i wreszcie:
Nie każdy tester jest freelancerem gotowym pracować w jednym projekcie 3 miesiące bez konkretnej dalszej perspektywy.
Zarobki zarobkami, ale jakie to byłoby smutne – musieć się ograniczać, kiedy naokoło kiełkują nowe podejścia, tworzone są nowe narzędzia albo odkrywane są nowe sposoby użycia starych narzędzi.
Jak zatem poradzić sobie z ustaleniem, co właściwie warto umieć i w czym się szkolić?
Odpowiedź na to pytanie przynosi niezawodnie doświadczenie. Niech początkujący testerzy nie wywracają teraz oczami.:) Mam tu na myśli zarówno “twarde”, komercyjne doświadczenie, jak i własne działania takie jak praktyki, chałupniczy bug-hunting oraz przeczesywanie internetu w poszukiwaniu webinarów, ofert pracy, szkoleń, publikacji.
Zawsze warto też zapytać bardziej doświadczonych koleżanek i kolegów po fachu, czy to podczas meetupów czy przez internet.
Przyjrzałam się swojemu oraz znajomych testerów doświadczeniu i zebrałam dla Ciebie, drogi Czytelniku, listę obowiązków testerskich, które miałam okazję ja lub moi znajomi okazję wykonywać.
Zaobserwowałam na przestrzeni kilkunastu różnych projektów, że da się wyodrębnić kilka głównych obszarów kompetencji testerskich, w których te obowiązki się mieszczą. Są to następujące obszary:
- Wymagania biznesowe i techniczne.
- Testy.
- Instancje/środowiska.
- Dane testowe.
- Dokumentacja.
- Komunikacja i proces testowy.
Ktoś spostrzegawczy powiedziałby może, że to dość spory rozstrzał kompetencji.
W takim razie czy tester to typ kaskadera, który wpada do projektu w dowolnej technologii i po kilku minutach czuje się jak ryba w wodzie i ..testuje?
Obraz, który zarysowałam jest nieco przerysowany, jednak trzeba przyznać, że rola testera jest dość pojemna. Zwłaszcza w projektach prowadzonych w metodykach zwinnych, takich jak scrum, kanban, XP (extreme programming), FDD (feature-driven development) itp.
Ktoś inny spostrzegawczy uznałby może, że wymienione przeze mnie elementy są niczym innym, jak frameworkiem, pewnymi ramami działania. I też może mieć rację. Zbiór kompetencji to w istocie pewnego rodzaju model, który może pomóc w rozwoju zawodowym.
Załóżmy, że mówimy o zespole, który zawiera programistów, testera, product ownera oraz koordynatora projektu. Nie mamy zatem praworządnej metodyki scrumowej, lecz jedną z wielu jej wariacji.
Rozwijając zarysowany wcześniej zestaw, przyporządkowałam głównym obszarom poboczne obowiązki im towarzyszące lub wiążące się z nimi. Lista ta nie jest żadnym standardem, nie doszukujcie się też tam nomenklatury ISTQB.
Sami oceńcie, czy udało mi się zobrazować pojemność stanowiska testera. :)
- Wymagania: praca z wymaganiami biznesowymi i technicznymi oraz standardami – zbieranie, analiza, walidacja i weryfikacja wymagań, analiza ryzyka, projektowanie strategii i planu testów, uczestniczenie w porównywaniu gotowych rozwiązań lub w projektowaniu nowych.
- Testy: testowanie, poszukiwanie przypadków testowych i scenariuszy alternatywnych, eksploracja, zgłaszanie błędów, proponowanie usprawnień, pisanie przypadków testowych (manualnych i/lub automatycznych), wykonywanie i utrzymywanie/aktualizacja przypadków funkcjonalnych i niefunkcjonalnych różnych typów i na różnych poziomach, weryfikacja zgodności z wymaganiami (sprawdzanie).
- Instancje/środowiska: przygotowanie środowisk, ich konfiguracja i utrzymywanie, a w szczególności kontrola wersji oprogramowania na środowiskach, zarządzanie lub nadzór nad kolejką wdrożeń; monitoring testów automatycznych oraz narzędzi ciągłej integracji; pisanie własnych narzędzi usprawniających pracę zespołu, czyli zadania, które można by nazwać “TestOpsowymi”.
- Dane testowe: przygotowanie, konfiguracja, utrzymywanie, aktualizowanie, sprawdzanie zgodności ich użytkowania ze standardami, ochrona (np.w kontekście przepisów prawnych o ochronie danych osobowych).
- Dokumentacja: pisanie i utrzymywanie/aktualizacja, dbanie o specyfikację.
- Komunikacja i proces testowy: dbanie o przepływ informacji w zespole i między zespołami, dokumentacja wniosków ze spotkań, komunikacja z klientem/“biznesem” i demonstrowanie wykonanej pracy zespołu, wsparcie klienta lub wsparcie product ownera albo project managera, “scrum-masterowanie” lub wsparcie scrum mastera, wdrażanie nowego pracownika do projektu, szkolenie zespołu; zarządzanie procesem testowym oraz zasobami i zadaniami testerskimi, przegląd kodu testów, przegląd przypadków testowych, przegląd kodu projektu (code review).
Zapewne jest to spis dość lakoniczny. Myślę, że rozwinięcie poszczególnych czynności w nim zawartych może być doskonałym pomysłem na nieco dłuższą wypowiedź pisemną.
Z pewnością część z tych obszarów nie wchodzi w skład obowiązków testera w firmach zatrudniających specjalistów zajmujących się danym obszarem (np. analityk wymagań, analityk testów, technical writer, programista testów, DevOps czy konfigurator środowisk). Odnoszę się jednak o sytuacji, kiedy takich specjalistów brak.
Niektóre z obszarów lub obowiązków (np. projektowanie strategii czy zarządzanie procesem) brzmią jakby mogły być wykonywane przez nieliczne osoby, które pracują na stanowisku menedżerskim (np. test lead, kierownik testów). Prawda jest jednak taka, że każdy z nas musi w jakiś sposób zorganizować swój czas pracy oraz testy, nawet jeśli jest to ograniczony zakres nakreślony przez wspomnianego kierownika testów.
No chyba, że pracujecie w firmie, gdzie otrzymujecie ściśle opisane zadania, niepozostawiające pola do interpretacji i kreatywności. W takim miejscu całe rozważania z tego artykułu są oczywiście mało przydatne.
Na koniec naszych rozważań nad istotą zawodu testera pochylmy się jeszcze nad jednym aspektem, również zawartym w moim spisie:
Jak to jest z programowaniem, pisaniem kodu testów?
Czy tester manualny i automatyzujący powinny być stanowiskami rozdzielnymi, tak jak to obecnie obserwujemy? Czy tak naprawdę jeden w ogóle nie dotyka kodu albo czy jest nietechniczny, a drugi siedzi cały czas w kodzie?
Z mojego doświadczenia wynika, że sprawdza się tu operowanie procentem czasu spędzonego nad automatyzacją (rozumianą jako pisanie kodu testów, np.w języku Java z pomocą frameworka Selenium WebDriver). Jedną z dobrych praktyk automatyzacji jest to, aby wykonywać ją mądrze (Yes,Mrs Obvious!), najlepiej zgodnie z piramidą automatyzacji (najwięcej testów jednostkowych, najmniej testów interfejsu graficznego czyli w przybliżeniu mówiąc naśladowania użytkownika w przeglądarce).
Jednak taki tester automatyzujący musi najpierw wiedzieć, jaki scenariusz powinien zautomatyzować. Nawet otrzymawszy od analityka testów “gotowce” w postaci rozpisanych przypadków testowych powinien ze zrozumieniem najpierw samodzielnie je przejść, zweryfikować, zobaczyć czy da się je w 100% zautomatyzować według zamysłu autora.
Zatem tester automatyzujący też w pewnym stopniu robi coś więcej niż tylko pisanie kodu.
Można więc zaryzykować stwierdzenie, że automatyzacja jest również wpisana w zestaw kompetencji testerskich i tylko konkretna sytuacja sprawia, czy ją realizujemy czy nie. Wpływ na to ma stadium projektu, budżet oraz kompetencyjna gotowość zespołu.
Podsumowanie
Po tych nieco przydługich rozważaniach pokuśmy się o drobne podsumowanie.
Otóż, czy aby być dobrym testerem oprogramowania, musisz być ninja-omnibusem?
Nie.
Oczywiście nie zaszkodzi uzyskać choć minimum kompetencji w kilku obszarach, jednak najważniejszą kwestią jest to, aby wiedzieć, w których obszarach mamy już wystarczającą wiedzę i umiejętności dla danego stanowiska w danej firmie. Jeśli nie, lepiej poznajmy najpierw dobrze nasze środowisko pracy i ekosystem technologiczny (“Know your stack!”). Jeśli codzienna praca staje się coraz mniejszym wyzwaniem, poszukaj jak możesz ją usprawnić. Zawędruj w świat nowych narzędzi (np. nowych dodatków do przeglądarki, sposobu pisania dokumentacji, biblioteki do automatyzacji, nakładki do terminala itd.), dowiedz się jakie są aktualnie technologiczne trendy na rynku. Nikt nie broni nam uczyć się kolejnych rzeczy. A potem dzielić się nimi z innymi w pracy i po pracy :)
Przy okazji tematu wszechstronności chciałabym zaapelować do nadzwyczajnie gorliwych i proaktywnych osób – pamiętajcie, że zademonstrowanie swoich wielu i wysokich kompetencji to jedno. Dawanie się eksploatować z powodu swej omnipotencji to drugie. Poszukajcie dynamicznej równowagi między pokazaniem swego profesjonalizmu, a tym, by nie okazało się w krótkim czasie, że robicie “wszystko za wszystkich”.
Na dłuższą metę nie możesz pracować jako testero-koordynator projektu, bo zwyczajnie się wypalisz i nie będziesz ani skutecznym testerem, ani koordynatorem, a może co gorsza przestaniesz być dobrym znajomym, matką, ojcem… Każdy z nas jest człowiekiem (nawet ci, którzy wierzą, że są nad-ludźmi!) i ma ograniczony zasób energetyczny :) Potrzebujesz choć minimalnej dawki harmonii i nie, nie możesz robić wszystkiego w projekcie. Dynamiczna harmonia w życiu i pracy jest istotna.
Nie zapominajmy, że nie tylko stanowisko testera charakteryzuje się większym spektrum obowiązków, niż to na pierwszy rzut oka się wydaje. Warto przyjrzeć się naszym “braciom i siostrom w IT” po drugiej stronie monitora (np. programistom czy analitykom). Prawdopodobnie jest to temat na osobny artykuł, a co najmniej na interesującą rozmowę.
Mam nadzieję, że ta lektura była dla Ciebie pomocna i przyda się co najmniej w wykazaniu innym jak wiele tester może wnieść do zespołu 😉
A jakie są Wasze doświadczenia zawodowe na stanowisku testerskim? Jaki jest zakres obowiązków testerskich w projektach prowadzonych w metodykach zwinnych? A jaki w innych metodykach, w których pracowaliście lub pracujecie? Czy metodyka pracy wpływa Waszym zdaniem na zakres testerskich obowiązków? Czy wielkość organizacji wpływa na stopień specjalizacji obowiązków? Jestem szczerze ciekawa. :)
