"Za pogardę dla bogów, nienawiść śmierci i umiłowanie życia zapłacił niewypowiedzianą męką: całe istnienie skupione w wysiłku, którego nic nie skończy. Oto cena, jaką trzeba zapłacić za miłość do testowania." - Albert Camus, Mit Syzyfa*
Za każdym razem, gdy mówimy lub piszemy o testerach stawiamy ich w pozycji swoistych strażników jakości produktu. Moim zdaniem etos pracy testera wymaga, aby zawsze ostatecznym kryterium, którym kieruje się w swojej pracy, było zadowolenie użytkowników, dla których tworzymy oprogramowanie. To tester jest osobą, która mówi sakramentalne „tak” zanim programiści będą mogli wypuścić nową wersję softu na produkcję. Skoro może powiedzieć „tak”, jego obowiązkiem jest powiedzieć „nie” kiedy sytuacja tego wymaga. To właśnie tutaj, zaczynają się schody i wszelkie odcienie szarości, które rozmywają coś co wydawałoby się być na pierwszy rzut oka czarno-białym.
W idealnym świecie prace nad nową funkcją systemu powinny trwać tak długo, aż osiągniemy stan pełnego działania. Wymagania, które otrzymał zespół zakładają pewien UX nowego fragmentu interfejsu użytkownika. Przygotowany backend powinien działać w sposób niezawodny. Tester, powinien potwierdzić, że wszystko to pracuje bez błędów, a całość została wykonana zgodnie z ustaloną wcześniej specyfikacją. Gdy tak się stanie zespół powinien zdeployować wykonany fragment oprogramowania i przejść do następnych zadań. Gdyby po drodze pojawiły się jakieś błędy bądź odchylenia od przygotowanych uprzednio mock-upów tester powinien je wykryć i zasygnalizować, a programiści poprawić. To tyle, jeżeli chodzi o świat naszych marzeń.
W rzeczywistym świecie staramy się dążyć do opisanego powyżej ideału, jednak na naszej drodze zawsze staje czas, który wszystko psuje. A konkretniej - jego brak. Niestety, zawsze działamy w jakiś ograniczonych ramach czasowych i bardzo często musimy jako zespół iść na pewne kompromisy. Mogą mieć one bardzo różny charakter, np. możemy ograniczyć zakres nowego featura i zaimplementować tylko jego najważniejsze fragmenty. Innym sposobem oszczędności czasu – szczególnie bolesnym dla UX/UI designerów – jest zubożenie albo uproszczenie interfejsu graficznego nowej funkcji. Możemy także spróbować uprościć backend, olać pewne edge-case’y stwierdzając, że są one „highly unlikely” (jak to lubi mówić architekt oprogramowania, który z nami pracuje na co dzień) i po prostu pogodzić się z tym, że jak się pojawią będziemy mieli trochę pracy z naprawami na produkcyjnej bazie danych.
Jest jeszcze jeden sposób, któremu chciałem poświęcić trochę więcej miejsca w dzisiejszym artykule. Zespół może zdecydować, że nie implementuje poprawek zasugerowanych przez testera, poza tymi, które są absolutnie krytyczne, bo bez nich nowa funkcja by po prostu nie zadziałała. Stoi to oczywiście w jawnej sprzeczności, z tym co napisałem na początku, że tester jest strażnikiem jakości i powinien mówić twarde „nie” gdy zajdzie taka potrzeba. Niestety, życie wygląda tak, że często nikt tego „nie” nie posłucha.
W naszym zespole śmiejemy się, że Andrzej, nasz tester, ma swój osobisty backlog**, do którego lecą wszystkie jego sugestie odłożone na kiedy indziej. Ciężko mi określić jak realnie wygląda proporcja uwag od Adrzeja, które wykonujemy w stosunku do tych, które odkładamy na potem, ale wydaje mi się, że przy większości ticketów, które testuje zawsze parę takich pomysłów wpadnie do backloga. Jak znosi to Andrzej? Na zewnątrz wydaje się, że ze zrozumieniem – ale co siedzi tam głęboko w jego testerskim serduszku to wie tylko on jeden.
I tu przechodzimy do meritum tego problemu. Życie czasami tak po prostu wygląda i moim zdaniem nie jest to wcale jednoznacznie złe. Ciężko mi sobie wyobrazić, że można by budować cokolwiek bez jakiś ograniczeń czasowych i w ogóle być w stanie dojść do momentu, w którym stwierdzimy: „tak! Dzieło jest gotowe!”. Ile by to trwało? Ile by kosztował taki produkt? Czy bylibyśmy w stanie utrzymać zespół bez dokonywania – czasami bardzo trudnych – kompromisów? W moim przekonaniu nie.
Dlatego rola testera jest szczególnie trudna pod tym względem. Dobry tester musi umieć godzić się na kompromisy, a jednocześnie nigdy nie stracić ducha do tego, by zawsze starać się wskazać każde możliwe ulepszenie testowanego przez siebie oprogramowania. Czasami ta praca może wydawać się takim Syzyfowym wtaczaniem głazu pod górę, tylko po to, by ten głaz spadając wylądował na dnie głębokiego jak samo piekło backloga. Starannie przygotowane tickety zesłane na wieczne niezaimplementowanie. Oto właśnie droga, którą musi kroczyć każdy tester.
Ale nie ma co się przesadnie dąsać, wszystkie te niespełnione pomysły zostaną sowicie wynagrodzone przez poczucie satysfakcji za każdym razem, gdy uratujecie produkcję przed zniszczeniem znajdując jakiegoś przyczajonego buga. W wielu sytuacjach wasze sugestie dotyczące możliwych usprawnień zostaną też po prostu zaimplementowane albo przynajmniej poddane dyskusji. Cokolwiek by się nie stało, zaangażowany tester, który nigdy nie traci ducha walki jest niezwykle cennym składnikiem każdego zespołu.
* prawdziwa treść cytatu: ”Za pogardę dla bogów, nienawiść śmierci i umiłowanie życia zapłacił niewypowiedzianą męką: całe istnienie skupione w wysiłku, którego nic nie skończy. Oto cena, jaką trzeba zapłacić za miłość do tej ziemi”
** Backlog – lista zadań lub pomysłów, które zostały odłożone na potem bez konkretnej daty ich wykonania – praktyka wygląda tak, że rzadko kiedy jest czas, żeby wrócić do bacloga i skończyć cokolwiek co się w nim znalazło