Redakcja
Sukces w IT możemy porównać do teatru. Kiedy po udanej premierze opada kurtyna, oklaski zbierają zazwyczaj aktorzy pierwszego planu. W IT są to zazwyczaj programiści i product managerowie. Tymczasem za kulisami, z dala od pierwszego planu, stoją ci, którzy przez tygodnie czy miesiące pracowali nad tym, by przedstawienie przebiegło bez zarzutu, czyli zespoły testerów.
Paradoks uznania
Ten paradoks uznania w branży testerów nie jest nowym zjawiskiem, ale niedawna dyskusja na forum Reddit odsłania jego głębsze warstwy. "Kiedy feature jest wydany i klienci go kochają, Product i Dev dostają wszystkie zasługi. Czasami Design jest wspomniany, ale QA? Prawie nigdy" - pisze doświadczona testerka. Jej gorzka obserwacja znajduje odbicie w wielu głosach społeczności QA.
Szczególnie wymowna jest wypowiedź jednego z testerów: "Mentalnie wykańczamy się, sprawdzając każdy możliwy scenariusz i dostarczając produkt najwyższej jakości, a mimo to nigdzie nie jesteśmy wymieniani". To symptomatyczne dla szerszego zjawiska - im bardziej efektywna jest praca testera, tym bardziej staje się ona niewidzialna. Paradoksalnie, testerzy są najczęściej zauważani nie wtedy, gdy zapobiegają problemom, ale wtedy, gdy coś jednak wymknie się spod ich kontroli.
Ten mechanizm przypomina nieco pracę redaktorów książek czy kuratorów wystaw. Ich sukces mierzy się tym, jak płynnie i naturalnie prezentuje się końcowy efekt, a nie widocznością ich własnego wkładu. Jednak w przypadku zespołów zapewnienia jakości ta "niewidzialność" niesie ze sobą realne ryzyko deprecjacji roli całych zespołów.
Spojrzenie doświadczonych testerów
Szczególnie cenne są w tym kontekście głosy „weteranów” branży. "Pracuję w QA od ponad 15 lat" - pisze jeden z uczestników dyskusji. "To naprawdę zależy od firmy. Pracowałem w miejscach, gdzie […] jeśli feature wychodzi i wszystko jest dobrze, to PM/Devs dostają uznanie. Ale jeśli coś pójdzie nie tak, wtedy ludzie zdają się pamiętać, kim jesteśmy. Ale to było w moich wczesnych dniach QA w nie najlepszych firmach".
Głębsza analiza wypowiedzi uczestników dyskusji ujawnia też istotną transformację w samopostrzeganiu roli testera. Jak zauważa jeden z ekspertów: "W nowoczesnej roli testera 'quality advocacy' jest naprawdę użyteczną umiejętnością". To fundamentalne przesunięcie perspektywy od reaktywnego wykrywania błędów do proaktywnego kształtowania kultury jakości.
"Quality Assurance jest odpowiedzialne za gwarantowanie jakości naszej pracy" - podkreśla inny uczestnik dyskusji. "Nie tylko testujemy produkt. Walidujemy design i upewniamy się, że produkt jest wszystkim tym, czym firma chciała, by był. Bez dobrej pracy QA, wymagania są tylko listą życzeń, a produkt rzadko spełniałby oczekiwania interesariuszy".
Szczególnie interesujące jest systemowe podejście opisane przez jednego z menedżerów. Wdrożył on szereg praktyk organizacyjnych, w tym prowadzenie demo sprintowych przez testerów czy włączenie ich w proces onboardingu. Jak sam wyjaśnia: "Podczas spotkań menedżerskich byli wdzięczni za metryki QA, ponieważ udało mi się poprowadzić narrację i pomóc im zrozumieć znaczenie planu ryzyka i jego łagodzenia. Nietechniczni interesariusze lepiej rozumieją nietechniczne aspekty. QA, będąc ewangelistami produktu, wypełniają tę lukę znacznie lepiej niż analitycy biznesowi".
W całej dyskusji pojawia się też głębsza refleksja nad naturą jakości w świecie oprogramowania. "Jakość nie jest obiektywna" - zauważa jeden z uczestników. "Każdy ma nieco inną definicję". Ta obserwacja otwiera nową perspektywę na rolę testerów, którzy stają się już także mediatorami między różnymi wizjami "dobrego" oprogramowania.
Metafora dementorów
Ciekawą metaforę przedstawia jeden z młodszych testerów, porównując się do dementorów z Harry'ego Pottera: "Wykonuję swoją pracę, trzymając złe bugi z dala... a kiedy podchodzę do biurka developera, czuję, jak szczęście odpływa z twarzy bohatera. Ale wszystko staje się lepsze, gdy bug jest bezpiecznie zabezpieczony, a oni doceniają to, gdy stres mija, a feature jest wydany". Taka ironiczna obserwacja celnie oddaje złożoną dynamikę relacji między testerami a resztą zespołu.
Te różnorodne głosy pokazują, że środowisko testerów dojrzewa do bardziej wyrafinowanego myślenia o swojej roli i miejscu w całym ekosystemie IT.
Metafora łabędzia
Specyfikę pracy zespołów QA dobrze oddaje też metafora łabędzia na jeziorze. Gdy patrzymy na produkt od strony użytkownika, widzimy przede wszystkim spokój i harmonię, interfejs, który reaguje przewidywalnie, funkcje, które działają tak, jak powinny oraz cały ten pozorny wysiłek bez wysiłku, który składa się na dobre doświadczenie. To jest właśnie tafla wody: gładka, przejrzysta, uspokajająca.
Ale każdy, kto miał okazję spojrzeć na łabędzia od spodu, wie, że ta elegancja jest tylko jedną stroną rzeczywistości. Pod powierzchnią nogi pracują szybko, zdecydowanie i bez przerwy, utrzymując kierunek, równowagę i tempo. I choć ta część pracy jest niewidoczna, to właśnie ona decyduje o tym, czy łabędź sunie po jeziorze pewnie, czy też dryfuje chaotycznie.
Z pracą testerów jest dokładnie tak samo. To, co widoczne na zewnątrz (stabilność, bezpieczeństwo, niezawodność) jest jedynie efektem końcowym. Cała reszta dzieje się "pod taflą": analiza ryzyk, powtarzalne testy, weryfikacja wymagań, rozmowy o szczegółach, wychwytywanie nieoczywistych zależności, przewidywanie scenariuszy, które komuś innemu nawet nie przyszłoby do głowy. Jest w tym ogrom koncentracji, myślenia i dbałości o szczegóły, ale większość użytkowników (i część zespołów projektowych) nigdy tego nie zobaczy.
Dlatego metafora łabędzia tak dobrze wybrzmiewa w kontekście testerów: przypomina, że "bezawaryjność" czy "płynność działania" nie są naturalnym stanem rzeczy, ale rezultatem nieustannego, często niewidzialnego wysiłku. To właśnie ta cicha praca pod powierzchnią utrzymuje produkt w ruchu i sprawia, że wszystko wygląda gładko, nawet wtedy, gdy chwilę wcześniej pod spodem wrzało.
Z całością rozmowy zapoznacie się tutaj.
