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?

Wróżka estymuszka

Są różne metody estymowania czasu, jakie zajmie zrobienie i przetestowanie featurea. Możemy bazować na doświadczeniu, poprzednich projektach, wiedzy, czasu budżetu itp. Mamy nawet Planning pokera, który często wykorzystywany jest w projektach scrumowych.

Po drugiej stronie mamy jednak managerów, dla których wszystko wyestymowane jest źle. Za drogo, za dużo czasu, za dużo ludzi jest potrzebnych. Żeby trafić z estymacją, która zostanie zaakceptowana, trzeba być albo wróżką, albo myśleć jak Manager.

Autentyczna rozmowa między kolegami estymującymi projekt:

[Adam]: Podsumowując, ile czasu Wam to zajmie?

[Marcin]: 4 tygodnie nie damy rady krócej.

[A]: Ok, dobra, to chodźmy do Jarka (Managera), tylko powiedzmy mu, że zajmie to 6 tygodni bo na pewno będzie się pytał, czy nie da się tego skrócić. Pewnie będzie chciał obciąć, więc akurat zostanie tyle ile nam trzeba.

Spotkanie u managera:

[Jarek]: I jak macie już?

[M]: Tak, myślę, że w 6 tygodni damy radę

[J]: Tak długo? Adam, nie da rady tego jakoś zoptymalizować, praca na dwie zmiany, weekend work itp.? Co o tym myślisz?

[A]: Mmm… no w sumie możemy jeszcze coś tam wywalić i jak się chłopaki sprężą to na dwie zmiany powinni dać radę w 5 tygodni.

[J]: Marcin, dacie radę w 4? Macie mocny zespół, pociśniecie i będzie dobrze.

[M]: Adaś to jest realne?

[A]: Noo ostatecznie powinniście dać radę, wpadnij to mnie to pogadamy co i jak zoptymalizować

[M]: No dobra to spróbujemy w 4…

[J]: Super! Dzięki chłopaki!

Wnioski? Wnioski wyciągnijcie sami. Po co komuś scrumy, spotkania, analitycy biznesowi, skoro i tak Manager wie lepiej.