QA retro czy retro QA? 10 lat w testach manualnych – subiektywne studium przypadku

Niedawno żona zapytała mnie, czy patrząc z perspektywy czasu chciałbym coś zmienić. Z absolutnie szczerym i paskudnie parszywym uśmiechem odpowiedziałem: “Dzieciaki zostają, ale nad żoną się zastanawiam”. Szybki foszek, 5 minut burczenia, kawka i sprostowanie: “Czy chciałbyś coś zmienić w życiu zawodowym? W końcu na dniach pęknie Ci 10 lat w szumnie zwanym IT, większość tego czasu przy testach manualnych”.

I w sumie, czemu by nie zrobić pisanego retro? W końcu, jak (prawie) zawsze – miała rację. Jakby na to nie patrzeć to na dniach stuknie mi dekada w IT. Podszedłem do tematu jak do zwykłej retrospekcji sprintu – tyle, że troszkę dłuższego sprintu. Czy wyszło? Nie wiem – oceńcie proszę sami.

Na początku mojej przygody z testami jeden z devów powiedział mi: “Idź w inną ścieżkę IT, bo za 10 lat testerów manualnych już nie będzie. Widząc, jak się zmienia i rozwija IT, będą już rozbudowane automaty, które same będą analizować i testować kod. Albo frameworki będą tak wymuszać poprawność kodu, że wy już nie będziecie potrzebni i wyginiecie jak dinozaury”. Obydwoje trochę się pośmialiśmy (ja trochę mniej) i każdy wrócił do swoich obowiązków.
Utkwiło mi to w głowie dość mocno, ale czy z perspektywy czasu miał rację?

Przypuszczam, że na niektóre rzeczy patrzyłbym inaczej, gdybym od samego początku pracował tylko w testach manualnych. Zaczynałem jako manual QA. Później, w tej samej firmie ktoś mi zaufał i dał możliwość zbudowania całego zespołu świetnych testerów.

Czy byłem dobrym liderem – nie wiem. Wiem tylko tyle, że z kilkoma członkami wspomnianego zespołu mamy naprawdę dobry kontakt do dnia dzisiejszego, mimo, że żaden z nas nie pracuje już w firmie od co najmniej 5 lat. Byłem też analitykiem testów zarządzającym zespołem quality assurance w Indiach, scrum masterem z doskoku oraz pięciodniowym team leadem w kolejnej firmie. Serio – dostałem kontrakt na stanowisko manual test leada, po czym po pięciu dniach doszło do całkowitej i gruntownej reorganizacji firmy, więc zająłem się kontrolą jakości i koordynacją release’ów. W incydent managemencie też miałem przyjemność dłuższą chwilę popracować.

Jak widzicie, nie będzie to czyste QA retro, bardziej Il buono, il brutto, il cattivo (przyp. red. “dobry, zły, brzydki”, film Sergio Leone z 1966 r. ) dotyczące mojego doświadczenia w IT i nie tylko. Wolne przemyślenia.

Z mojej perspektywy niektóre tematy będą całkiem świeże, inne już naprawdę dojrzałe. Wydaje mi się, że każdy z nas zna poniżej opisane problemy, ale może mieć na ich temat całkowicie odmienne zdanie. Chciałbym skupić się na trzech głównych rzeczach.

Te które wyszły dobrze, te które wkur … nie były zbyt fajne oraz miejsca, gdzie widzę pole do popisu i usprawnień, moich bądź pracodawców.

Zobacz też

PM Kiedy podejmujesz decyzję, czy zostaniesz leadem zespołu, lista “za” i “przeciw” potrafi mieć zaskakująco dużo pozycji “przeciw”

il brutto – nie działa!

Cichy zabójca produktywności

Zacznę od absolutnego bestselleru – nuda i… dupogodziny.

Nuda nie wynikająca z braku innych zajęć, co to to nie. Nuda wynikająca z regresji i tylko regresji. Retesty potrafią być męczące, ale za każdym razem spodziewam się innego rezultatu. Liczę, że to już jest finalna wersja, sprawdzam i albo idzie z powrotem do poprawek albo zamykamy sprawę.

Zdecydowanie inaczej jest z regresją. Takie powtarzanie tych samych testów jest po prostu nudne i myślę, że każdy QA spotkał się z tym problemem. Nie regresji robionej drugi czy trzeci raz, ale tej robionej po raz 20. albo 40. Ale zaraz, pewnie można zautomatyzować? Może tak. Ale czasem się nie da, a czasem się po prostu nie opłaca. ROI jest tak złe, że to nie ma sensu. Więc, robisz tę regresję, mechanicznie czytasz po raz setny test case – sprawdzasz, następny test case – sprawdzasz.

I nagle, łapię się na tym, że owszem, sprawdziłem czy jest zgodnie z test planem, ale nic więcej. Wyświetla się prawidłowo? Tak – test case pass. Nawigacja w apce działa? Tak – test case pass. I już nawet nie spojrzałem na produkt przekrojowo, holistycznie. Nie zwróciłem uwagi, że może i jest zgodne ze specyfikacją, ale mimo wszystko wygląda bądź zachowuje się po prostu źle. Nieśmiertelny paradoks pestycydów z ISTQB jednak istnieje i jest straszną pułapką.

Można z niej oczywiście uciec. Przerabianie test case’ów, aktualizacja ich o nowe wymagania, wyciąganie wspólnych części testów do innych test planów itp.

Nuda i dupogodziny w tym przypadku się łączą. Nie zliczę godzin, w których po prostu musiałem czekać na “coś”. Na nowy build, na fix, na kolegę z zespołu, który ma swoje zadania zaplanowane, więc nie będę mu się wbijać w ciąg myślowy jak nad czymś pracuje i po prostu czekam, aż będzie miał chwilę i spojrzy na problem, który znalazłem, na PM/PO z którym chciałbym się skonsultować, że to faktycznie jest problem wynikający np. z błędnie rozpisanych wymagań.

Niestety, czekanie jest wliczone w naszą pracę. I w teorii, można zająć się czymś innym – jasne, napisać przypadki, zapoznać się z dokumentacją, ogarnąć inne bugi. Ale jak bardzo można być przygotowanym? Liczba dokumentacji i test case’ów do rozpisania też jest ograniczona. To może doczytam coś z biznesu? Albo ogarnę jakieś nowe technologie?

Fenomenalnie. Zacna idea panie prezesie. Wymagająca przeogromnych nakładów samozaparcia. Osobiście udało mi się zrobić kilka kursów na Udemy, kilka innych drobnych szkoleń i tyle. A jak już mi się znudziło robienie kursów, zostało czekanie… którego spożytkowanie w pracy w biurze jest mocno ograniczone.

A czekanie godzinę, półtorej w biurze, to naprawdę ciężki orzech do zgryzienia. Dupogodziny. Siedzisz i udajesz, że coś robisz, ale nic produktywnego z tego nie będzie. To taki cichy zabójca produktywności. Wiesz, że masz zaplanowane dużo następnych rzeczy, natomiast nie możesz ich zacząć, bo musisz poczekać, aż poprzednie zostaną zamknięte. Jak rozgrzebiesz pięć tematów, to nie skończysz żadnego.

Jak rozwiązać ten problem? Priorytetyzacja zadań. Codzienne sumienne sprawdzenie, co mogę, a czego nie uda mi się dziś zrobić i przede wszystkim trzymanie się tej listy. Oczywiście przed rozpoczęciem pracy, a nie po drugiej kawce.

Czy gdybym kodował testy, to uniknąłbym powyższych problemów? Może. Nie pracuję i nie pracowałem jako tester automatyzujący, ale wielokrotnie widziałem ich frustrację, przepalone godziny i problemy (również z regresją). Kłopoty w większości czasu wynikającą z problemu dopasowania rozwiązania ze Stack Overflow do ich własnego projektu.

I nie zrozumcie mnie źle – po co wymyślać koło od nowa, przecież są gotowe rozwiązania. Ale nie wiem, co jest bardziej męczące – robienie regresji raz na sprint czy co chwilę grzebanie w internetach i dopasowywanie rozwiązań z innych projektów. Uważam, że pisanie testów auto i ich utrzymywanie jest po prostu bardziej nudne.

Dobór metodologii

Jak zawsze, kto co woli. Jedni wolą mieć zaplanowane najbliższe 9 miesięcy średnio długiego projektu, inni – tak jak ja – odnajdują się w bardziej dynamicznych sytuacjach.

Osobiście zdecydowanie bardziej odnajduję się w projektach w metodologii zwinnej. Jeśli sprinty są dobrze zaplanowane, zespół dowozi, co ma, a klient nie zmienia swojej wizji pod koniec sprintu, to naprawdę widać postępy pracy. Ale! Wcale nie neguję projektów prowadzonych w waterfallu, one niejednokrotnie też są prowadzone w sposób przejrzysty i czytelny dla zespołu (i managementu). Po prostu sukces (albo porażka!) jest mocno rozciągnięty w czasie.

Rzeczą, która mi do tej pory przeszkadzała był zły dobór metodologii do projektu. W migracji kilku tysięcy raportów pomiędzy systemami można było jechać w kanbanie, a nie w waterfallu. Development już skończył raporty, przeszedł do innego projektu, a Ty weź bądź mądry i wyciągnij deva z jego obecnej pracy żeby naprawił błędy z poprzedniego projektu. Pozdro piąteczka. Ale i w drugą broszkę – bardzo długofalowy projekt, w którym sama definicja wymagań trwała z 5 miesięcy i zespół scrumowy, bo się management uparł, że tak będzie lepiej, bo przecież teraz wszyscy tak pracują.

W chwili obecnej pracuję w scrumie prowadzonym prawie wzorowo, ale o tym później.

il cattivo – paskudnie nie działa!

Nieomylny management

Gdy byłem team leadem, to było mi obojętne, jakie obowiązki zostały na mnie zrzucone, byleby zespół miał lepiej niż ja. Mogłem przerzucać bugi i je retestować ile fabryka dała, przerzucać gó… nawóz, chodzić na różne (nie)potrzebne spotkania itp. I najgorsze, co mogło mi się zdarzyć, to że nie liczono się z moim zdaniem. Przecież management wie lepiej, którego QA pchnąć do którego zespołu, jak nim zarządzać itp. Niestety, nieliczenie się ze zdaniem członka zespołu skutkuje złym działaniem zespołu. To po prostu wpływa na całościowe działanie naszego projektowego kolektywu.

Mówisz test managerowi, że trzeba puścić maila do zespołu testerów, bo zrobili fenomenalną robotę z ostatnim releasem. Oni naprawdę na to liczą i nie oczekują wiele (a tym bardziej hajsu). Chcą docenienia od głównego szefa QA. Naprawdę, wystarczy im mail: “Chapeau bas! Dzięki waszej pracy i dobrej kooperacji z developmentem dowieźliście release! Wyłapaliście błędy w paczce, zespół je naprawił, a klient już ich nie zobaczy. Inaczej by nam w poniedziałek urwał cojones.“

Nie, nie ma takiej potrzeby. Nie, bo nie, bo przecież to ich obowiązek. To może chociaż zróbmy niezależną integrację, taką tylko zespołową? Kręgle, burger, piweczko. A po co, przecież jesteście zespołem w pracy, nie musicie być super zintegrowani…

Jest to strasznie męczące, kiedy management ma swoją wizję na Twoją osobę. Zdarzały się sytuacje, w których nie było pytania, co chcesz robić bądź gdzie w firmie się najlepiej sprawdzasz. Jest dziura po kimś, a Twój profil w 20% pasuje? Wrzucimy Cię tam, bo w exceliku FTE muszą się zgadzać. Nie chcesz tego robić? Spoko, to tylko na chwilę, dopóki nie znajdziemy kogoś dedykowanego. Ale zaraz, przecież nawet nie szukacie i nie ma otwartej pozycji? Będzie. Za jakiś czas będzie. Kiedyś. Damy Ci znać…. No i nie dali. Ale też nie musieli – już mnie tam nie było.

I nie zrozumcie mnie źle. Mimo że powyższe brzmi naprawdę bardzo słabo, to ma olbrzymi wpływ na to gdzie teraz jestem, a trafiłem fenomenalnie! Pomogło w zdefiniowaniu, co mi się podoba a co nie, gdzie chcę być i co robić, a czego nie. Utwierdziło w przekonaniu że uwielbiam tą pracę, mimo że nadal jest bardzo dużo rzeczy, które potrafią mocno napsuć krwi.

il buono – działa!

Projekty – rzecz kluczowa

Są unikalne. I niekoniecznie tutaj, gdzie jestem – w .intent.

Każdy projekt, nad którym pracowałem do tej pory był nieszablonowy. Chociażby wspomniany wyżej projekt o migracji raportów między systemami. Z zespołem w Indiach sprawdziliśmy około 1500 raportów, czasami po 5 dziennie czasami po 40. Albo projekty dla firm ubezpieczeniowych w UK czy gry do kasyn online. Oczywiście, biorąc pod uwagę liczbę firm, start-upów i skończonych wariacji konkretnych rozwiązań nie jest to unikalność na skalę wszechświata, ale co najmniej na kontynentalną. Przy każdym projekcie trzeba się napracować, każdy projekt ma inne „to coś” i każdy mnie czegoś nauczył, dobrego bądź złego.

Wydaje mi się że nie ma co się bać kiepskich projektów, dla QA jest to niesamowita nauka. Im więcej problemów ma się na początku (też kariery), tym łatwiej jest później. Nie będę kłamał, że nie chciałem z takich projektów uciec. Jasne, że chciałem, ale najczęściej wygrywała wrodzona upartość i dostarczenie produktu aż na produkcję i zamknięcie elegancko drzwi, bez trzaskania i urazy.

Oferty pracy z

Project management

Rzecz, która mnie tu zachwyciła. PM-owie, którzy po prostu wiedzą i rozumieją.

Rozumieją potrzeby klienta, są w stanie prowadzić ciężkie projektowe rozmowy jak równy z równym. Rozumieją też nasze potrzeby. Wiedzą, jakie mamy ograniczenia, wiedzą, co możemy, a czego dostarczyć się nie da. Jesteśmy traktowani jak partnerzy w zbrodni, a nie jak podwykonawcy. Nasza opinia w oparciu o konkretne argumenty ma dla klienta niejednokrotnie kluczowe zdanie. Nie jesteśmy i nie chcemy być traktowani jak zleceniobiorcy. Jesteśmy w projekcie od startu do aż do końca, mając realny wpływ na to, co dzieje się w czasie życia produktu. Klient wręcz oczekuje od nas przedstawienia kilku rozwiązań, z czego on wybierze najbardziej dla niego satysfakcjonujące.

Do powyższego, PM-wie są wymagający, projekty prowadzą bardzo ambitnie. Wymagania są świetnie zdefiniowane, spotkania w scrum dopilnowane, retro ma realny wpływ na pracę zespołu, a daily rzadko kiedy wychodzi poza ramy 15 minut (wliczając 5 minut porannego nadgonienia ploteczek i ciekawostek).

Praca zdalna

Jest super, ale jak zawsze pod kilkoma warunkami. Firma musi być przygotowana na ten typ pracy. Zarząd również musi być przygotowany na pracę zdalną – może i on przede wszystkim. Dlaczego przede wszystkim? To kwestia zrozumienia i zaufania. Zrozumienia, że jesteśmy odpowiedzialnymi pracownikami, którzy z domu są w stanie pracować tak samo efektywnie, jak z biura. A nawet jeśli mniej, bo rozpraszaczy w domu jest dużo, to tu właśnie wchodzi kwestia zaufania, że plan będzie zrealizowany w stu procentach. Zamiast pracować osiem godzin w biurze, dzień pracy rozciąga się na 10-12h, ale wszystkie cele zostaną zrealizowane.

Nie przeczę – tacierzyństwo wypadło idealnie w czasie covidowego zamknięcia. Przed nim raczej nie miałbym szans pracować 100% zdalnie. Miałem niesamowitą okazję widzieć rzeczy, których bym nie widział, chodząc normalnie do pracy, do biura. Mogłem razem z żoną ogarniać dzieciaki. Stworzyć relację z dziećmi, której budowanie zajęłoby zdecydowanie więcej czasu, gdyby mnie w domu nie było. I mimo, że odbiega to znacznie od QA retro, to jednak wpływa na moje postrzeganie pracy zdalnej. Teraz, gdy dzieci są już odrobinę starsze i naprawdę potrafią dokazywać w domu, to byłoby zdecydowanie fajniej raz na tydzień pójść do biura. Całkowicie inna koncentracja, integracja, wyłączyć się i zrobić swoje nie martwiąc o “brązowy alarm”, który może nadejść w każdej chwili. Nawet wtedy jak prowadzisz prezentację dla klienta 🙂

A czy praca zdalna mnie czegoś nauczyła? Tak. Pełnej koncentracji na tym, co robię i wyłączeniu się z rzeczy dziejących się za plecami. Nie ukrywajmy, małe dzieci w domu to jeden wielki rozpraszacz. Żeby nie było, w biurze też zawsze ktoś coś mówi, tłumaczy, pokazuje itp. Chcesz się przyłączyć do rozmowy, dopytać bądź uzyskać odpowiedzi. Jednak dopiero będąc cały czas w domu nauczyłem się pełnego skupienia.

Masz wpływ na firmę?

Tu w .intent jest coś, czego nie spotkałem wcześniej. Tzn. spotkałem, ale nigdy nie widziałem realnego wpływu pracowników na działanie firmy. Przyznaję – sprawdza się to naprawdę dobrze. Badań satysfakcji czy opinii pracowników jest dużo. Zaczynając od tych dotyczących samopoczucia (realny problem zamknięcia po-covidowego) przez dopasowanie projektowe, zespołowe czy rozwojowe. Szefostwo chce z Tobą rozmawiać, liczy się z Twoim zdaniem, a w dodatku, jeśli wskażesz miejsca do poprawy, to bierze problem na tapet.

Lepiej zrezygnować z projektu, niż stracić cały zespół i oni to wiedzą! W końcu mam realny wpływ na to, co się dzieje w projekcie, zespole i wreszcie w firmie.

Bonus – il perfetto

Ludzie, współpraca, zespół!

Zespół – crème de la crème na (prawie) koniec. Jeśli projekt jest gówniany, za to zespół rewelacyjny – przerzucisz wszystko, co trzeba z uśmiechem na twarzy. W odwrotnej sytuacji – świetny projekt, ale zespół przeciętny, nieostrożnie dobrany pod względem charakteru bądź kompetencji – wyniki mogą być co najmniej różne. Wróżbitą JSONem nie jestem, ale moje doświadczenie pokazuje, że współpraca idzie wtedy dość przeciętnie.

Do tej pory wszędzie, gdzie miałem przyjemność pracować, współpraca międzyludzka szła bardzo dobrze. W jakichś sposób zawsze się docieraliśmy w zespole – czasem szybciej lub wolniej. Czy to przypadek? Dobrze dobrany zespół? Projekt? Nie wiem, ale myślę, że mógłbym spokojnie powiedzieć, że im większe problemy mieliśmy jako zespół, tym bardziej się jednoczyliśmy, aby znaleźć jak najlepsze rozwiązania. Jest coś takiego, że łączysz się w bólu i chcesz wypchnąć ‘ten’ projekt już na proda, byle dalej.

A w chwili obecnej zespół, w którym pracuję składa się z dwóch devów (senior i junior) oraz PM. Chyba najlepsze z możliwych połączeń. Mały, zgrabny, efektywny zespół będący w stanie dowieźć dobrze zaplanowany sprint. Project manager dostarcza świetnie zdefiniowane taski. Spisane na tyle dobrze, że (oczywiście w większości czasu) nie ma szans na niedomówienia. A acceptance criteria są więcej niż oczywiste.

I wiem, że nie powinno się komentować czyjejś aparycji, ale muszę, po prostu muszę to zrobić. Pracuję z zawodowym hitmanem, mordercą do wynajęcia. Gdybym spotkał Michała w bramie w nocy, to poszedłbym w długą jak Speedy Gonzalez albo Struś Pędziwiatr. Tatuaże, łysa glaca, kickboxer. A tymczasem jest to najbardziej elokwentny, najmilszy i chyba najbardziej cierpliwy misio dev, z jakim kiedykolwiek współpracowałem. Gdyby nie jego wiedza i sposób tłumaczenia spraw (jak krowie na miedzy), poległbym sromotnie w obecnym projekcie.

il finale

Wiecie co? Może kolega sprzed tylu lat miał rację? Może ja faktycznie jestem już retro QA i czas zmienić profesję? W końcu według niego jestem już jak żywa skamielina i czas wyginąć jak dinozaur. Tyle, że dla mnie to jeszcze nie teraz, to jeszcze nie ta kometa. A że po prostu kocham testować – łatwo tego nie odpuszczę!

10 lat temu znalazłem swojego konika – testowanie. Uwielbiam, jak dev mówi “gotowe do testów”. I mimo powielanego hasła: „płacą mi za czepianie się”, ja się naprawdę nie czepiam. W końcu błędy, które są robione, nie są robione na przekór bądź specjalnie. To są zwykłe błędy wynikające z presji czasu, błędu specyfikacji bądź po prostu innego spojrzenia na rzecz, która miała być dostarczona.

Abstrahując od tego, czy jest to łatwy wizualny bug czy nowy algorytm wyliczania kwoty za ubezpieczenie ze zniżkami, dodatkami i grupy inwalidzkiej czy nadchodzący release, który trzeba sprawdzić. Za każdym razem jest to coś emocjonującego i pobudzającego. Absolutnie wszystkie inne słabe strony schodzą na dalszy plan.

A jak jeszcze dołożymy do testów manualnych aspekt hardware’owy, jak tu w .intent, to jestem całkowicie utwierdzony w przekonaniu, że nasz czas – testerów manualnych – jeszcze nie dobiegł końca.

Dlaczego z całego wachlarza doświadczenia wybrałem akurat te rzeczy do omówienia? Ponieważ dla mnie osobiście są one kluczowe jako testera i na retro cały zespół mógłby się do nich ustosunkować, nie tylko ja. Oczywiście, mógłbym się rozpisać na temat błędów, które popełniłem (i czego mnie one nauczyły), potencjalnych rad dla nowych i obecnych QA – ale to chyba temat na osobny artykuł.

A, i przy okazji. Dajcie mi proszę znać jakie jest Wasze spojrzenie na przyszłość testerów manualnych? Rzućcie proszę słowem w komentarzach, może przekonacie mnie do czegoś innego? 🙂

Zobacz też

DevDebata Czy każdy programista powinien umieć testować? Devdebata

Zdjęcie główne pochodzi z unsplash.com.