Jak współpracować z innymi dostawcami pracując nad jednym produktem

Wbrew temu co można sądzić, testerzy wciąż są niedoceniani przez firmy zamawiające usługi IT. Programista – ok, tworzy kod, coś konkretnego. BA – zbiera i określa wymagania. PM – trzyma to wszystko w kupie. Tester? Po co nam tester?

Pewnie z podobnego założenia wyszedł klient, dla którego mam przyjemność pracować. Oprócz mojego obecnego pracodawcy zatrudnił 3 inne firmy (z Polski, Indii i Hiszpanii). Ich zadaniem było dostarczenie kolejnych funkcjonalności i usprawnień, których my po prostu nie zdążylibyśmy wprowadzić w wyznaczonym czasie. Problem polegał na tym, że inni dostawcy nie posiadali w swoich szeregach działu QA. Niosło to następujące konsekwencje:

  • wpuszczaliśmy obce osoby do swojego kodu, nie bardzo wiedząc jaki jest zakres ich zmian
  • nie wiedzieliśmy czy wprowadzone zmiany nie wpłyną na resztę naszego kodu
  • wprowadzenie nieprzetestowanych zmian mogło być powodem dużej ilości błędów
  • kto w takim razie będzie odpowiedzialny za jakość aplikacji?
  • czy powinniśmy testować nie swój kod?

Z tymi wszystkimi rzeczami musieliśmy się zmierzyć określając dalsze warunki współpracy.

Ostatecznie udało się wypracować następujące wnioski:

  • Każda a firm jest odpowiedzialna za swój kod
  • Zespół developerów z mojej firmy będzie odpowiedzialny za kod review innych vendorów
  • Zespół QA nie ponosi odpowiedzialność za nowe funkcjonalności  od builda XYZ, gdzie zostały one wprowadzone
  • Zespół QA może wykonywać testy nowych funkcjonalności, za które oczywiście klient zapłaci, z zaznaczeniem że nie mając dokumentacji/mocków/designów testy mogą nie pokrywać wszystkiego i w żaden sposób nie świadczą o jakości ( mieliśmy w końcu swoje własne zadania związane z naszymi funkcjonalnościami)

Jak to zwykle w życiu bywa problemy zaczęły się już od pierwszego builda. W ciągu tygodnia powstało ponad 80 bugów, większość krytycznych. Nie łatwiej mieli programiści, którzy bezlitośnie punktowali każdą słabość kodu. Oczywiście klient był na bieżąco informowany o całej sytuacji, widział listę błędów i doskonale zdawał sobie sprawę z niskiej jakości kodu dostarczonego przez innych dostawców. W końcu doszło do sytuacji, gdy zostaliśmy poproszeni przez klienta o poprawienie bugów w kodzie jednego z dostawców. Niosło to za sobą wiele konsekwencji i pytań:

  • wykonując to zadanie pokazalibyśmy się jako rycerz na białym koniu, który w trudnych chwilach  potrafi wyjść i znaleźć rozwiązanie w rudnych chwilach
  • z drugiej strony przyzwyczailibyśmy klienta do tego, że można brać tańszych dostawców, a dopiero w sytuacji kryzysowej wziąć nas droższych, którzy ugaszą pożar
  • czy robiąc poprawkę w nieswoim kodzie, zaczynamy być za niego odpowiedzialni pod względem QA?

Bardzo ważne we współpracy okazało się jasne przedstawienie granic i odpowiedzialności. Z jednej strony nie mogliśmy zostawić klienta z niedziałającą aplikacją, z drugiej chcieliśmy pokazać, że taniej nie zawsze znaczy lepiej i czasami nie ma co skąpić na zespół QA. Warto też być asertywnym i nie dać się wykorzystywać przez dostawców. Oczywiście pomagaliśmy im wykonując testy, natomiast prośby pisane personalnie z pominięciem klienta w stylu: „Czy moglibyście nam wysłać WSZYSTKIE strony z całej aplikacji, na których występuje błąd” spotykały się z naszą odmową. Co najwyżej robiliśmy krótkie sesje eksploracyjne, gdzie staraliśmy się wyłapać ile się dało.  Natomiast nie chcieliśmy robić testów za plecami klienta, za które nie mielibyśmy zapłacone.

Podsumowując, warto zawsze określić granicę odpowiedzialności. Warto też przemyśleć jak bardzo chcemy wpuszczać innych do swojego kodu i czy warto testować nie swoje zmiany. Każda z tych decyzji niesie za sobą konsekwencje, które wpływają na relacji z klientem.

Ważne i ważniejsze

Robimy dla klienta aplikację. Zarówno Android jak i iOS. Problemem jest to, że designy dostarcza nam zewnętrzna forma od strony klienta. W ten oto sposób mamy designy, mocki, wersje na iOS i wersję na Androida…. każdą inną.

A bo tutaj kolor jest trochę inny. na iOS jest przycisk przesuniety, a bo kalendarz trzeba było zrobić natywnie i już nic się nie zgadza. Problemów bez liku, ale nie poddajemy się. Zgłaszamy błędy skupiając się głównie na funkcjonalności, ewentualnie zgłaszamy grube błędy w designach.

Przychodzi czas na pierwsze demo, potem drugie demo i okazuje się, że klienta ma gdzieś, że aplikacja działa. Dla niego ważne jest żeby wyglądała, „ładnie”. Tam literka, tu kropeczka, przecineczek i kolorek mają teraz bugi z ważnością critical. A to, że coś tam się nie działa? kogo to obchodzi. W końcu klienta nasz PAN 🙂

To mała poprawka, nie ma sensu tego dokładnie sprawdzać.

„To tylko mała poprawka.” „Drobny improvement, nic wielkiego, szkoda czasu na testy” Ile to razy słyszymy to z ust programistów? Prawda jest taka, że testerzy muszą być czujni na każdym kroku i pamiętać, że jak coś jest źle przetestowania, to pewnie nie zadziała.

Klient zażyczył sobie małe ulepszenie wyszukiwarki: Obok pola szukaj, damy pole hotel i samochód, które będą przerzucać do nowych stron, gdzie będzie sobie można wyszukać hotel, lub wypożyczyć samochód. Estymacja ze strony developerów: 6h. Czyli projekt bardzo malutki.

Testy zrobione po macoszemu i na szybko – w 30 minut. Klik – przenosi na stronę hotelu. Powrót na stronę główną, klik na drugą zakładkę – przenosi do wypożyczali aut. Jeszcze z przyzwoitości wciskamy F12, żeby sprawdzić wersję represywną – działa. Przynajmniej dla Iphona 6.Powtarzamy to samo dla każdego obsługiwanego języka i po 30 minutach projekt może iść na testy akceptacyjne do klienta.

Godzinę później pierwszy email: Strona hotelu i wypożyczalni są również w kliku językach, więc w zależności od wyboru języka, powinna nowa strona otwierać się w danym języku, a nie tylko po angielsku. Patrzymy do wymagań: Po kliknięciu ma przenosić na stronę cars.com i hotels.com. Brak jakiejkolwiek wzmianki o wersjach językowych.

Pół godziny później kolejny mail: Po wyłączeniu zakładek rozjeżdża się rysunek pod spodem. Sprawdzamy lokalnie: u nas działa. Prosimy więc o screena: faktycznie – rozjechany. Jaka jest różnica? U klienta nie ma panelu do zmiany waluty, ponieważ ma IP z kraju, gdzie jest Euro. U nas okienko z walutą domyślnie jest. Wyłączamy – faktycznie obrazek rozjechany. Na szczęście problem jest po stronie grafika klienta.

W końcu dostajemy nową grafikę. Szybki fix developerów i można wysyłać. Tym razem jednak siadamy do testów raz jeszcze, w większą ilość osób. Sprawdzamy wersje językowe, linki, responsywność itp.  Okazuje się, że na Iphonie 5 dla języka greckiego słowo „Auto” nie mieści się  w ramce…a miał być mały, szybki projekt. Bijemy się w piersi. Podeszliśmy do tematu po macoszemu i  na odwal się –  NIGDY WIĘCEJ!

Klient – władca wymagań

Niezwykle modnym (wręcz obecnie jedynym słusznym!) podejściem do wytwarzania oprogramowania jest podejście zwinne. Kod, testy oraz wymagania cały czas dynamicznie się zmieniają. Daleko nie szukając: Mail od klienta precyzujący wymagania, wysłany o 11:37:

„…process must assign passengers…”

W zespole panika, ponieważ przetestowany I oprogramowane było zachowanie zupełnie odwrotne. Pożar na całego, gdy nagle o 11:49 przychodzi kolejny mail od klienta:

„ Let me correct the last sentence. … process should not assign passengers…”

I jak tu nie lubić tej pracy…

Kto jest odpowiedzialny za jakość oprogramowania?

Kto stoi na straży jakości oprogramowania? Wiadomo – tester. Do czego sprowadza się więc jego rola? Wytykania gdzie developer popełnił błąd? Marudzenia, że znowu nie ma dokumentacji technicznej? Zdawania trudnych pytań klientowi? Co tak naprawdę sprawia, że możemy nazywać siebie strażnikami jakości?

Czy projekt informatyczny mógłby się udać bez udziału testera? Teoretycznie tak. Co do jego jakości możnaby się wspierać, ale nie ma przeciwskazań, żeby wypuścić software nieprzetestowany.

Natomiast czy można stworzyć software bez udziału programistów? Nie. Więc to programiści, jako niezbędny element projektu informatycznego powinni być odpowiedzialni za jakość. Powinni, ale nie są. Co innego jest napisać kod, a co innego napisać działający kod zgodnie z życzeniem klienta, spełanijący dane reguły biznesowe itp. Dlatego też niezbędna jest tu rola testera.

   Programista jest osobą konieczną, ale niewystarczającą aby projekt informatyczny miał szansę powodzenia.

Najlepiej, gdy programista i tester uzupełniają się nawzajem. Wygląda na to, że testerzy i programiści uzupełniają się nawzajem. Jeden ma wiedzę domenową, drugi ma pogląd na całość projektu. Programista wie CO ma działać, tester wie JAK to coś ma działać. Ostatecznie oboje są odpowiedzialni za jakość dostarczanego produktu. Od ich podejścia zależy, jaka będzie ostateczna ocena ich pracy.

Jeśli po zgłoszeniu błędów programista zaklnie i zwyzywa, że te łajzy znowu się czepiają, a przecież tłumaczył im, że to tak ma działać to zacząłbym się martwić o powodzenie projektu. Z drugiej strony tester wyzywający, że znowu w tym samym miejscu, ta sama funkcjonalność nie działa, też nic dobrego nie osiągnie.

Kluczem do sukcesu jest komunikacja, wzajemne zrozumienie i wyjście na piwo raz na jakiś czas. Nic tak nie rozwiązuje problemów jak kufel dobrej craftowej IPY.

Projekt ławka

Jak to w każdej większej firmie zdarza się, że testerzy „siedzą na ławce”. Innymi słowy: projektu nie ma i póki co nie będzie. Co wówczas robić, gdy musimy siedzieć 8h w pracy bez konkretnych zadań? Możliwości jest klika:

Self learning:

Czyli to, co właściwie powinniśmy robić. Testowanie jest olbrzymim obszarem więc każdy powinien znaleźć tutaj coś dla siebie. Frontend, Backend, aplikacje mobilne, wydajność, bezpieczeństwo itp. Tematów można by mnożyć. Minusy? Ileż można!? Dzień, dwa, tydzień nauki bez przerwy? Każdy by oszalał. Ponadto czas upływa powoli…bardzo powoli. Gdy praca do wykonania jest konkretna, wówczas czas zdaje się płynąć szybciej.

Granie w gry:

Opcja niebezpieczna, lecz kusząca. Szefowie raczej nie będą patrzeć przechylnym okiem, ale z drugiej strony, gdy w biurze jest 100 osób, to wówczas nie tak łatwo wyizolować tę, która nic nie robi. Ponadto gry rozwijają. Artykułów na ten temat też jest dość sporo. Zresztą, nie trzeba grać w gry na konsoli, zawsze są planszówki.

Work from home:

Ma sens. Skoro I tak się uczę, to czemu nie uczyć się z domu, gdzie rozpraszaczy jest dużo mniej. Warunki bardziej sprzyjają a i baza wiedzy bywa większa. Pytanie, czy ten czas pracy z domu na pewno poświęcimy rzeczywistej nauce.

Retrospektywa i porządki:

Skończyliśmy projekt, nie mamy nowego, ale może jednak warto podsumować nasze dotychczasowe dokonania. Zawsze znajdzie się obszar, w którym coś nam nie poszło, gdzie moglibyśmy cos poprawić. Warto więc zrobić porządek zarówno w dokumentacji jak i na biurku.

Oglądać YouTube:

Ilość filmów z kotami wystarczy nam na długie miesiące siedzenia na ławce. Może i nic się nie nauczymy, za to będziemy szczęśliwi. Zresztą, nie tylko koty są w internetach.

Załatwiać rzeczy prywatne:

Trzeba zrobić przelew, opłacić rachunki, zamówić prezenty, pojechać przypilnować malarza itp. Brzmi znajomo? To codzienność tych, którzy nie mają projektu. Niech kwestią naszego sumienia pozostanie jak bardzo będziemy chcieli wykorzystywać firmę do własnych potrzeb.

Zmienić pracę:

Nic tak nie demotywuje jak monotonia. Gdy czas spędzony na ławce jest zbyt długi, czasem warto po prostu poszukać innej pracy. Krok drastyczny, ale czasami konieczny.

Programistyczna Wieża Babel

Developerzy w danym projekcie programują w jednym języku programowania. Java, C#, .NET, nie ma znaczenia – zawsze jest to jeden konkretny język. Dzięki temu są oni ekspertami w swojej dziedzinie znając wszystkie tajniki, jak również za i przeciw danego rozwiązania.

Ile języków programowania powinien znać tester? Żadnego, bo przecież jest testerem manualnym? A jak jest automatykiem? To góra jeden. Selenium + Java. Bo teraz wszystko jest pisane w Selenium. BDD + find.by i wystarczy. Czy aby na pewno?

Czasami jest tak, że testerzy przypisani do projektu muszą sobie radzić sami z całym projektem, niezależnie od tego jakie są technologie i potrzeby, bo akurat ławka testerska jest pusta. I tak: Mamy Web aplikacje, no to piszemy Selenium+ C#, bo przecież Framework już jest i nie będziemy wymyślać koła na nowo. Web serwisy? POSTMAN/SOAPUI nie ma znaczenia, i tak będziesz pisać w Java Scripcie. Klient chce aplikacje mobilną? Developerzy zabierają się za Xamarina, więc nie masz wyboru. Musisz użyć Calabasha, a w jakim języku pisze się w Calabashu? Rubym. Do tego jeszcze na początku projektu, kiedy wydawało się, że klepania kodu w ogóle nie będzie, programik do generowania linków pisałeś w Pythonie. Potem dla klienta developerzy piszą cały backed od nowa. No to w czym piszemy testy? REST assured – czyli w Javie.  Razem daje nam to pięć różnych języków programowania. Jednak tester to cwana i pojęta bestia.

Soft skills – hit czy kit?

Czy w branży IT ważne są umiejętności miękkie? Czy dobry programista, bez umiejętności komunikacji będzie postrzegany jako gorszy i zarabiać mniej? Opinii na ten temat jest tyle, ile odpowiadających. Moim zdaniem umiejętności miękkie są równie ważne co umiejętności twarde.

Zdarzało Wam się rozmawiać z kimś na jakiś temat, po czym po 15 minutach wymiany zdań okazuje się, właściwie mówicie o dwóch różnych rzeczach? A co z kontaktami z programistami? W jednym z projektów, gdy po kolejnym wypuszczeniu softu, po raz n –ty ten sam błąd był widoczny pewien tester lubił mówić:” Kur*a ten debil znowu nie naprawił tego buga, co za osioł. Mówiłem mu że to i to nie działa, co za zjeb!” – po czym pisał maila eskalacyjnego dodając do wątku PMa, i inne osoby decyzyjne. Efekt? Żaden. Powstał dodatkowy konflikt, w który zaangażowani musieli zostać liderzy i menadżerowie z obu stron. Przykład ten pokazuje wyraźny brak umiejętności miękkich. Komunikacji – brak. Brak też było jakiejkolwiek inicjatywy zrozumienia, dlaczego problem występuje. Zero empatii, pomysłu na rozwiązanie problemu.

Po drugiej stronie mogę przytoczyć sytuacje z innego projektu, gdy developer dziękował za znalezienie błędu! Był to dla mnie szok, ponieważ nigdy wcześniej się z czymś takim nie spotkałem. Z drugiej strony po zakończeniu projektu programiści udzielili kiedyś feedbacku, na temat zespołu testerskiego. Był od dość cierpki, ale bardzo merytoryczny i oparty na faktach. Można było zareagować na niego w dwojaki sposób: Stwierdzić, że nie mają racji, nie znają się na naszej pracy, kazać im się odwalić i strzelić focha, po czym dać równie ostrą informację zwrotną, niezależnie od tego, czy byłaby ona prawdziwa. Innym sposobem, który zresztą został wybrany, było przeanalizowanie tego, co zostało powiedziane. Bez emocji, oczerniania, wszystko na spokojnie. Przeanalizowaliśmy fakty, zrobiliśmy szybkie 5-why i wyciągnęliśmy wnioski. Od razu wprowadziliśmy pewne akcje w życie, dzięki czemu nasza praca stała się prostsza i lepiej widoczna. Powstała też checklista, w której umieściliśmy wskazówki, co i jak testować i na co zwracać uwagę, bazując na naszym doświadczeniu i znając „buggy zone” w projekcie. Mała pomoc dla przyszłych testerów. Efekt: wszyscy zadowoleni. W końcu jeśli mamy się rozwijać, musimy wiedzieć co robimy źle. Pochlebstwa w żaden sposób nie wpłyną na nasz rozwój i poprawienie jakości pracy. Jest to najczęstsza bolączka juniorów, którzy boją się mówić źle o kolegach z zespołu i strasznie oburzają się na negatywny feedback na temat ich pracy.

W komunikacji codziennej umiejętności miękkie są niemalże konieczne. Problem, który można by rozwiązać w 5 minut, ciągnie się godzinami na Skype, ponieważ jedna i druga strona stara się udowodnić, że ma rację. Zero próby zrozumienia, za to wzajemne przeszkadzanie i wykrzykiwanie ciągnące się w nieskończoność.

Oczywiście poza komunikacją mamy jeszcze inicjatywę, elastyczność, umiejętność pracy w grupie, kreatywność itp. Ale to pojęcia na osobny wpis.

 

Przychodzi programista do testera.

W ogromnych korporacjach, gdzie nad jednym projektem pracuje grubo ponad 1500 programistów, nie ma zespołów Scrumowych. Testerzy tworzą osobną grupę, natomiast developerzy, w zależności od technologii formują własne, na które testerzy zgłaszają błędy.

Więc siedzisz sobie w fotelu i testujesz. W pewnym momencie jest i on. Bug o ważności Major. Więc robisz szybką inwestygację, przeglądasz logi, z których nic nie wynika i wystawiasz błąd na tą, co zawsze grupę developerską. Bo przecież ostatnie 20 błędów też musiała ta jedna konkretna grupa poprawić. Ty, co prawda pracujesz w firmie krótko, ale jak wszyscy mówią, żebyś się nie przejmował i wystawiał, to to robisz. Pięć minut później zgłoszenie jest już widoczne, więc zadowolony z siebie idziesz na kawę.

Piętnaście minut później, słyszysz jak ktoś idzie. Jest jeszcze daleko, ale Ty już wyczuwasz złe fluidy. Zbliża się do Ciebie, już wiesz jak się czuł muminek, gdy podchodziła do niego Buka. To developer przyszedł „porozmawiać” o Twoim zgłoszonym błędzie. W pewnym momencie zaczyna mówić. I nie są to teksty w stylu – „Ej wiesz co, chyba wystawiłeś błąd nie na tą grupę co trzeba. Chodź przejrzymy logi raz jeszcze, pokażę Ci, dlaczego popełniłeś błąd.” To jest cierpki i konkretny opierdol. A ty siedzisz skulony i nie wiesz, co zrobić, bo się boisz. Bo to kobieta na Ciebie krzyczy. Czujesz się jakby sam Terminator przyszedł i chciał Cię zabić. Więc grzecznie słuchasz i przytakujesz. Potem przepraszasz i obiecujesz, że już więcej błędu nie popełnisz. Tłumaczysz, że pracujesz krótko i nie masz jeszcze tyle doświadczenia.

Dziesięć minut później jesteś wolny. Fala hejtu rozlała się po całym piętrze a ty spocony masz w końcu chwilę, żeby złapać oddech. Kumple siedzący obok śmieją się z Ciebie, bo takie wizyty to dla nich normalność. W końcu zbierasz się do kupy, bierzesz największych testerskich wymiataczy i razem analizujecie to, co głosiłeś. Czytacie, przeglądacie i chwile później okazuje się, …że miałeś jednak rację! Błąd jest i to w części, którą napisała ta jedna konkretna grupa, na którą go zgłosiłeś. Otwierasz więc zgłoszenie, uzupełniasz analizę, dodajesz nowe screeny i wysyłasz raz jeszcze na grupę developerską. Na wszelki wypadek to samo piszesz w mailu, dodając do odbiorców Twojego oprawcę i jej managera.

Godzinę później sprawdzasz status błędu. In pogress… przewidywany czas naprawy – dwa dni. W tym momencie radość wypełnia Twe serce. Wiesz, że dobrze wykonałeś swoją pracę.  W duchu liczysz, że Terminator przyjdzie Cię przeprosić, ale wiesz, że do tego nie dojdzie. Ty i tak triumfujesz. Kim jesteś? Jesteś zwycięzcą!

Co zrobić z błędami znalezionymi na produkcji?

„Bug happens” – parafrazując słynny slogan. Nasuwa się wówczas pytanie: Co robić? Jak żyć?

Metod reagowania na błędy znalezione na produkcji jest kilka.

Pierwsza to: Olać. Skoro klient nie zgłasza problemów, system działa to po co dotykać czegokolwiek?

Druga: Zwalimy to na drugą firmą, która dostarcza grafikę i powiemy, że to wina layoutów.

Trzecia: Przygotujemy po cichu poprawkę i wrzucimy ją przy okazji kolejnego releasa softu, ale klientowi nie powiemy ani słowa.

Czwarta: Gramy w otwarte karty, klient ma prawo wiedzieć, że w sofcie są błędy. Powiemy co znaleźliśmy, zaproponujemy rozwiązanie , przeprosimy i poczekamy na decyzje. Będziemy proaktywni. To takie modne teraz. I to bez coachingu!

Która metoda jest najlepsza?