Radek Smilgin
Choć niesnaski i potyczki są częścią współpracy testerów oraz programistów, to jednak w dużej mierze są one często podkoloryzowane i przesadzone. Stworzyły one na przestrzeni lat pewną granicę, o którą nieustannie toczą się bitwy ról. Regularnie zdarza się raz jednym (tester zostaje programistą), a raz drugim (programista zostaje testerem) zmieniać strony i często te role zaczynają się przenikać (programujący tester i testujący programista). Nikt jednak do tej pory - z taką skutecznością, walcząc swoją medialnością - nie wziął się za zacieranie granic i szukania pola współpracy. Medialność nie jest tu wcale zarzutem, bo Ola Kunysz "umi" w social media i świetnie wykorzystuje je do budowania marki osobistej, przy okazji wprowadzając pokój w świecie IT.
Obserwując działania Oli można było się spodziewać, że eksplorując kanały dotarcia ze swoim przesłaniem, w jej przyborniku narzędziowym w końcu pojawi się również książka. I pojawiła się - "Kierunek jakość. Jak unikać błędów w projekcie".
Książka zawsze ma jeden podstawy cel – trafić do czytelnika. Zazwyczaj tak się dzieje, jeśli oprócz niesienia nowych treści czy emocji, jest również do niego dopasowana. Musi mówić jego językiem, po części potwierdzać jego własne postrzeganie świata i pozwalać mu utożsamić się z głównym bohaterem. Bohater musi być nam bliski, ale jednocześnie musi być skomplikowaną figurą. Musi zmagać się z problemami, ale musi mieć też szansę je rozwiązać. Takim bohaterem tej książki jest jakość w projekcie. Już początkowy rozdział pokazuje nam, że jakość niejedno ma imię i że nie jest to formułka do wykucia. Jakość w książce Oli Kunysz to niekończące się dążenie do osiągnięcia celu.
Wydaje mi się, że te prawie 200 stron to fragment układanki, którą Autorka ciągle buduje, odwołując się do przeszłych webinarów „Rozmów o jakości”. Możemy z pewnością założyć, że i podczas każdych kolejnych będzie również wracać do swojej publikacji. Książka nie jest zamknięciem pewnego etapu, ale raczej wprowadzeniem do dalszych rozmów o "jakości", które mają prowadzić do jej realnego osiągnięcia w każdym z projektów.
W pierwszym rozdziale książki Ola Kunysz daje nam odpowiedź na pytanie dlaczego czasami testerzy i programiści nie są w stanie się dogadać i zrzuca to na nasz kompleks superbohatera z przerośniętym ego. To ono podszeptuje nam, że zamiast powalczyć o jakość, zaczynamy przerzucać się odpowiedzialnością, w efekcie tę jakość jeszcze bardziej pogrążając razem z projektem, w którym pracujemy. Cały początek książki wydaje się depresyjny, bowiem przeglądamy się w lustrze własnych problemów projektowych i organizacyjnych, jak to, że jesteśmy zamknięci w jednej technologii czy, że otaczają nas wszechobecni maruderzy. Jednak z każdą stroną zaczyna być jasne, że te opisy rzeczywistości mają nam pokazać, iż zmiana na lepsze jest jednak możliwa.
I taką zmianę Autorka nam wskazuje. Nie jest to jednak "najlepsza praktyka" do zastosowana wszędzie, a po prostu praktyka, która może sprawdzić się także u Ciebie. Nie chcąc spoilerować powiem tylko, że w kolejnych rozdziałach poczytać możemy o wartości komunikacji, o pracy zespołowej i uczeniu się na własnych błędach. Nie są to jednak komunały, a ciekawe praktyki podbite własnymi doświadczeniami.
Wtedy pojawia się rozdział piąty, opowiadający o jakości dla programistów. Tutaj też bardzo wyraźnie widzimy, kto jest odbiorcą książki. Z perspektywy doświadczonego testera nie znajduję tu niczego, czego bym sam nie wiedział i nie użył w projekcie. Domyślam się jednocześnie, że programiści mogą być zaskoczeni. Wspominam jedną z konferencji, która dedykowana była właśnie koderom, podczas której pełna sala z zapartym tchem słuchała o najpoważniejszych i najbardziej spektakularnych defektach w historii oraz o tym, jak można było im zapobiec. Pamiętam swoje zaskoczenie tym, że to przecież nuda i że są to absolutne testerskie podstawy. Sala jednak przez cały czas siedziała oniemiała, by na koniec podziękować gromkimi brawami. Pytań do prezentera po prelekcji nie było końca. Z tego patentu korzysta Autorka, kończąc całość historiami o defektach.
Taki jest też ten rozdział, zawierający nagłówki żywcem wyciągnięte z sylabusa poziomu podstawowego, tylko zaserwowanego w praktyczny i przyjazny deweloperom sposób.
Podobnie jest też z kolejnymi rozdziałami, które jeszcze bardziej uderzają w struny tak znane i tak znienawidzone przez większość programistów – legacy code czy utrzymanie systemu.
Dwa ostatnie rozdziały to klamra, dzięki której wracamy znów do jakości oraz naszej współodpowiedzialności za nią, bez względu na pełnioną rolę.
Książka wydana przez wydawnictwo Helion, dostępna jest do kupienia na ich stronie >>
