Dla niektórych osób przychodzi moment, w którym zaczynają kwestionować swoją karierę: to swego rodzaju zawodowy kryzys wieku średniego. Tak samo było ze mną. Zmiany i ciągłe uczenie się czegoś nowego zawsze były dla mnie ważne. Dlatego też przeszłam małą ewolucję od strony zawodowej: zaczęłam pracę na stanowisku account managerki w internetowej agencji reklamowej, potem zostałam project managerką, product managerką w marketingu online, a wreszcie CRM managerką. Ale zawsze czegoś mi brakowało do 100% satysfakcji.

Z każdym rokiem doświadczenia zawodowego coraz bardziej interesowało mnie zajrzenie za kulisy tego, co dzieje się we frontendzie. Zawsze byłam dobra w zadawaniu pytań – ku zgrozie moich kolegów. Zapytałam moją sieć kontaktów, kto w branży IT zatrudniłby osoby zmieniające karierę  i tak trafiłam do QualityMinds.

Po Meet the Minds Day, podczas którego musiałam przetestować swój gen testerski w praktyce, stało się jasne: chcę być testerką oprogramowania! Mogę wreszcie kwestionować rzeczy krytycznym i badającym okiem – i wszyscy będą z tego zadowoleni. Podczas tej wstępnej fazy poznałam nowe narzędzia i nabyłam wstępną wiedzę testerską i poznałam np. mapę myśli, za pomocą której miałam zapisać swoją strategię testową dla obiektu testowego. Od razu przeprowadziłam swój pierwszy „prawdziwy” test, używając programu Excel jako narzędzia do zgłaszania błędów, aby dokumentować bugi, robić zrzuty ekranu i zapisywać kroki testowe, które deweloperzy mają odtworzyć. Po naprawieniu błędów zostały one ponownie przetestowane.

Odkryłam, że Excel nie jest tak niezwykły jako narzędzie do raportowania. W jednym z moich projektów środowisko projektowe nie było jeszcze wystarczająco „dojrzałe”, aby poradzić sobie z profesjonalnymi narzędziami. Dlatego na przykład istniejący zestaw testowy był tylko w Excelu, a raport o błędzie został sporządzony za pośrednictwem Jira, co było również jedynym sposobem na komunikację z programistami w Wielkiej Brytanii. W związku z tym nowe przypadki testowe nie były rejestrowane w biletach lub były jedynie szczątkowe, co również sprawiało, że test regresji nie zawsze był łatwy. W tym projekcie najpierw musiałam stworzyć żywą strukturę i rejestrację metryk pod kątem testowania, co dało mi swobodę pójścia własną drogą jako testerka eksploracyjna. Dlatego też, o ile smoke testy na środowisku (przed)produkcyjnym nie były w toku, zwykle korzystałam z podejścia sesyjnego, co pozwoliło mi przetestować konkretny obszar oprogramowania w bardzo ukierunkowany sposób.

W innym projekcie poznałam coś przeciwnego: tutaj były ustalone zasady dla (prawie) wszystkiego. Dodatkowo miałam tam po raz pierwszy styczność ze zwinnymi metodami pracy. Podczas codziennych spotkań (daily) dyskutowaliśmy o tym, co zrobiliśmy dzień wcześniej, co było dzisiaj do zrobienia i czy były jakieś przeszkody. Pakiety robocze były następnie przetwarzane w określonych 2-tygodniowych sprintach. Na koniec sprintu funkcjonalności były prezentowane i pokazane w demonstracji systemu. Te zawsze dobrze pokazywały, czy nasze oszacowanie funkcji było realistyczne, czy też nie można było opracować i przetestować wszystkiego. Dla mnie jako testerki wymagania były jasno określone przez kryteria akceptacji przechowywanych w historiach Jiry, co pomogło mi w projektowaniu testów. Ponadto mogłam wyciągnąć dalsze informacje z koncepcji technicznej i wykorzystać je w koncepcji testowej.

W tym projekcie wszystkie napisane przeze mnie przypadki testowe zostały udokumentowane w narzędziu „Aqua”, połączone z odpowiednimi wymaganiami w narzędziu, a następnie skompilowane i wykonane w scenariuszu testowym. W ten sposób było jasne dla mnie, właściciela produktu i kierownictwa, która funkcja jest testowana z jaką intensywnością w jakim środowisku. Ta możliwość śledzenia została uzupełniona na poziomie przypadku testowego lub funkcji o własną funkcję raportowania narzędzia, która może oceniać i graficznie wyświetlać szeroką gamę metryk.

Kolejnym cennym doświadczeniem była możliwość bezpośredniej wymiany informacji z programistami, ponieważ pracowaliśmy razem w zespole scrumowym. Dzięki regularnemu ustawianiu stałych okien czasowych, w których testowałam określoną funkcję, a programista odpowiadał bezpośrednio na moje pytania i uwagi, można było nie tylko szybko poprawić jakość oprogramowania, ale także lepiej zrozumieć sposób myślenia drugiej osoby, dzięki czemu współpraca była bardziej produktywna.

Aby ułatwić mi rozpoczęcie testowania jako osobie zmieniającej ścieżkę kariery, moi koledzy i koleżanki nie tylko dużo mi tłumaczyli przed rozpoczęciem projektów, ale także dali mi bardzo pomocne i praktyczne informacje, które zawarli w szkoleniu „Testowanie dla nie-testerów”. Rodzaje testów, procedury testowe, zarządzanie testami, poziomy testów i cykle tworzenia oprogramowania: te nowe terminy stopniowo poznawałam i używałam podczas tego szkolenia. Ponadto zawsze pomagało to, że moi koledzy pokazywali mi podobieństwa do moich poprzednich stanowisk, ponieważ zapewnienie jakości było ważne na każdym z nich. A testowanie nie dotyczy niczego innego jak poprawy jakości produktu. Szybkie rozpoczęcie mojego pierwszego projektu dla klienta pomogło również zastosować w praktyce to, czego się nauczyłam – oprócz zakuwania do certyfikacji ISTQB.

Patrząc wstecz, mogę powiedzieć, że kiedy w końcu zmieniłam ścieżkę kariery, wszystko poszło dobrze i miałam szczęście, że miałam okazję to zrobić w QualityMinds. Codziennie uczę się więcej nie tylko dlatego, że poznaję nowe konteksty, od oprogramowania bankowego po platformę do wynajmu pojazdów, ale także dlatego, że moi bardziej doświadczeni koledzy i koleżanki chętnie dzielą się ze mną swoją wiedzą. W międzyczasie zdobyłam solidne podstawy z zakresu testów eksploracyjnych, technicznych, zarządzania testami i projektowania testów, które teraz mogę stale poszerzać i pogłębiać. A obecnie mogę spróbować moich sił w automatyzacji testów i zajmować się Gherkinem, Javą i Cucumberem – więc nudno nie jest nigdy.