Przeczytaj artykuł, aby dowiedzieć się, jak usprawnić proces testowania nawet wtedy, gdy jesteś jedynym testerem w zespole.
Na ścieżce kariery testera oprogramowania pojawiają się różne wyzwania. Jednym z nich jest dołączenie do zespołu deweloperów, który skupiony jest na rozwoju produktu cyfrowego. W takim przypadku klient będzie potrzebował kogoś, kto będzie w stanie zaprojektować i zarządzać procesem testowania. Często zdarza się, że dotąd nie było osoby odpowiedzialnej za weryfikację jakości oprogramowania, ale szybko okazało się to złym wyborem - przez nieudane, zbugowane deploymenty na produkcję można stracić klienta, bo będzie on miał dość dostarczania oprogramowania o słabej jakości.
Tester staje się wówczas kimś, kto ma zaopiekować się procesami w taki sposób, aby powstające oprogramowanie zawierało mniej błędów. I wykryć błędy, których nie znalazły testy automatyczne, jeśli były wcześniej zaimplementowane.
Tester manualny jako samotny wilk na pokładzie zespołu developerskiego
Podczas pracy jako testerka manualna często staję przed wyzwaniem usprawnienia procesu testowania w projekcie. Pracowałam też dla organizacji, która potrzebowała wdrożenia odpowiednich praktyk QA dla kilku jednocześnie realizowanych projektów.
W tym artykule chciałabym podzielić się z wami pięcioma wskazówkami, które pomogą wam odnaleźć się w podobnej sytuacji.
Jeśli dołączyłeś właśnie do takiej organizacji i zastanawiasz się, jak sprostać wyzwaniu, które przed tobą stoi, to zapraszam do lektury 5 porad, które pozwolą sprawnie wejść do zespołu oraz nie popełnić podstawowych błędów.
Jak zbudować proces QA?
1. Dowiedz się na czym polega biznes klienta
Kiedy rozpoczynasz pracę w nowym projekcie, możesz nie znać nie tylko ludzi, ale i branży klienta. Zrozumienie co w niej najważniejsze, pozwala łatwiej komunikować się z biznesem, oraz efektywniej testować, ponieważ będzie można skupić się na tych funkcjonalnościach, które mają kluczowe znaczenie dla prowadzonego biznesu.
To, co nam może wydawać się ważne, niekoniecznie musi iść w parze z wymaganiami biznesowymi. Nie raz zdarzyło mi się zgłaszać błędy, które dla mnie były oczywiste, czy to związane z funkcjonalnością, czy wyglądem strony, tylko po to, aby okazało się, że klient po prostu tak chce i nie mamy na to wpływu. Potrafi być to irytujące, ale to coś, z czym także musimy się liczyć. Nie zmienia to faktu, że jako nowy członek zespołu, mamy świeże spojrzenie na platformę, którą testujemy. To daje nam przewagę w proponowaniu potencjalnych rozwiązań, które mogą ulepszyć aplikację. Gdyż pozostała część zespołu, zaangażowana w rozwój oprogramowania od samego początku, może być skupiona na innych kwestiach. Dlatego też zawsze warto proponować usprawnienia, jeżeli potrafimy poprzeć je solidnymi argumentami. W końcu projekt to żywy organizm, który nieustannie będzie się zmieniał i rozwijał - a tester oprogramowania powinien mieć w tym swój udział.
2. Poznaj zespół, z którym będziesz współpracować
Poznanie osób, które na co dzień są związane z projektem to kluczowa i często trudna część codziennej pracy, szczególnie na samym początku. Tworzymy zespół, ale każdy jego członek jest indywidualną personą. Nie każdy mógł mieć wcześniej do czynienia z QA czy różnego rodzaju praktykami testerskimi, co może znacząco wpłynąć na sposób komunikacji i poziom zrozumienia.
Zapoznanie się z zespołem - deweloperami, PMem czy samym klientem wymaga czasu i rozgryzienie tego, na co możemy sobie pozwolić i jak rozmawiać z każdym z nich to praca, która może zająć tygodnie. Istotna jest cierpliwość, otwartość i zaangażowanie, pokazanie, że nie jesteśmy kimś, kto tylko wskazuje palcem na to, że coś nie działa, ale jest częścią większej całości, aktywnie działającym na rzecz rozwoju oprogramowania.
Musimy jednak pamiętać o tym, że ludzie są różni. Jeden deweloper będzie komunikatywny i świetny w kontakcie, ba, sam chętnie pomoże w testach czy wyjaśni funkcjonalność nad którą pracował i jej potencjalny wpływ na całą platformę. Drugi może być milczkiem, który chce, aby zostawić go w spokoju i nie życzy sobie, aby przeszkadzać mu w pracy. Umiejętność radzenia sobie z takimi sytuacjami i wypracowanie dobrych praktyk komunikacyjnych, jest niezbędna, jeśli zależy nam na tym, żeby procesy toczyły się sprawnie.
3. Uświadom pozostałych za co odpowiada tester oprogramowania
Najistotniejszy punkt to budowanie świadomości, że tester manualny to nie ktoś, kto wytyka innym błędy, bo lubi to robić. Weryfikowanie jakości oprogramowania i zgłoszenie w związku z tym błędów to proces, którego efektem końcowym ma być sprawniejsza aplikacja i zadowolony użytkownik. Zdecydowanie lepiej jest, aby błąd odkrył tester niż osoba, która będzie z oprogramowania korzystać.
W swojej karierze miałam przyjemność pracować z deweloperami, którzy naprawdę dbali o jakość i robili wszystko co mogli po swojej stronie, aby dostarczyć dobry produkt (pisanie testów jednostkowych, myślenie i przewidywanie scenariuszy, które mogą zajść i na które warto się uodpornić i sprawdzić je już na etapie implementacji, zanim trafi to do testowania, dyskusja o tym, co klient chce, a co my możemy zrobić, aby mu to dostarczyć w najlepszy możliwy sposób), ale nie każdy członek zespołu może tak do tego podchodzić.
Ponadto zdarzają się wyjątki, w których to wcale nie myśli się o QA. Kiedyś w jednym z projektów, w którym wdrażałam proces QA od zera miałam następującą sytuację. Rozmawiałam z człowiekiem, który zajmował się customer supportem (był w stałym kontakcie z klientem i w razie jakichkolwiek problemów na produkcji, ja byłam na pierwszej linii ognia w sprawie dyskusji o tym, czy ten błąd naprawde występuje itd.). Gdy usłyszał jaka ma być moja rola w zespole, zrobił wielkie oczy, bo nigdy nie słyszał o czymś takim jak Quality Assurance.
To pokazuje jak istotne jest wyjaśnienie zakresu swoich obowiązków oraz celów swoich działań. Chociaż testowanie stało się już ważną częścią pracy nad rozwojem oprogramowania, to wciąż można trafić na zespoły, w których świadomość dotycząca procesów QA jest na niskim poziomie. Wówczas ponosimy dodatkową odpowiedzialność i warto jest zadbać, aby pierwszy kontakt takich osób z testerami był pozytywny - pełen otwartości, profesjonalizmu i nastawiony na osiągnięcie celu, jakim jest stabilna wersja produktu cyfrowego.
4. Zaproponuj ramy testowania (równolegle z implementacją)
Wdrażanie dobrego procesu wytwarzania oprogramowania to nie rzecz, którą robimy raz a potem o niej zapominamy. To proces, który zmienia się wraz z rozwijającym się oprogramowaniem, a jedyne czego możemy być pewni to, że coś na pewno ulegnie zmianie (czy to od strony biznesu, czy w trakcie implementacji).
Należy wytłumaczyć zespołowi, że na testowanie także musimy mieć czas, dlatego nie można stawiać go na sam koniec. Testowanie powinno być procesem równoległym z implementacją deweloperską. Tester powinien też potrafić głośno mówić o tym, czego potrzebuje i jak długo zajmie mu przetestowanie konkretnej funkcjonalności.
Takie podejście pozwoli na wykształcenie procesu, w którym możemy być pewni, że wypuszczamy coś, co na pewno będzie działać. Oczywiście, każdy popełnia błędy i zawsze będzie coś, co nam ucieknie, ale proces implementacji i testowania powinien być ułożony tak, że kiedy dostarczaliśmy kolejny duży fragment aplikacji na produkcję, nie trzeba będzie się obawiać, że użytkownik będzie korzystał z niestabilnego produktu. Dzięki temu klient i zespół nabierze do nas zaufania, co ma olbrzymie znaczenie przy długoterminowej współpracy. Dzięki temu też klient będzie w stanie np. polecić nas swoim klientom, abyśmy my mogli dostarczyć im coś podobnego.
5. Wykaż proaktywną postawę
Jako ktoś, kto zawsze pracuje zdalnie dla klienta, zdaję sobie świetnie sprawę z ogromnego znaczenia bycia proaktywnym. Warto brać aktywny udział w spotkaniach zespołu. Przede wszystkim nie bójmy się mówić o tym, że coś nie działa. Jeśli uważasz, że coś może nie pójść tak, jak zostało zaplanowane, to należy o tym poinformować klienta. W projektach, w których jest się samotnym wilkiem, jednoosobowym okrętem testerskim, warto na bieżąco komunikować zarówno swoje przemyślenia, jak i uwagi do prowadzonych prac.
Jeżeli tester tego nie zrobi, to najczęściej myśl nie zostanie podniesiona przez kogoś innego na żadnym spotkaniu. Jak już wspomniałam, jako osoba z zewnątrz mamy pewną przewagę: świeże spojrzenie, dlatego nasze uwagi mogą mieć wielkie znaczenia dla rozwoju projektu.
Jako (potencjalnie) jedyna osoba, na której barkach ciąży proces testowania, jesteśmy odpowiedzialni za flagowanie wszelakich problemów. Zarówno tych z zachowaniem członków zespołu, nie dowożeniem funkcjonalności na czas przez deweloperów, jak i tych typowo komunikacyjnych, jeżeli są to rzeczy, których sami nie jesteśmy w stanie rozwiązać. Otwarta, szczera i wyrozumiała komunikacja to klucz do sukcesu.
Podsumowanie
Projekty, w których za testowanie oprogramowania odpowiedzialna jest jedna osoba są dużym wyzwaniem w pracy testera. Zwłaszcza, jeśli zespół deweloperski nie miał wcześniej do czynienia z dobrymi praktykami QA. Rola testera manualnego nabiera wtedy również edukacyjnego wymiaru. To od tego, jak inni postrzegają naszą pracę zależeć będzie jej komfort oraz pozycja jaką przyjmujemy w grupie. Dlatego warto od samego początku starać się znaleźć z zespołem nie tylko wspólny język, ale także zadbać o to, aby cele wszystkich współpracowników były spójne. Na szczęście wraz z rosnącym doświadczeniem testerowi łatwiej jest argumentować swoje racje, a także odwoływać się do wiedzy nabytej w innych projektach, co okazuje się zbawienne w trudnych sytuacjach zawodowych.
