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

Opublikowany przez

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.

Trudne decyzje, niełatwe rozwiązania.

Opublikowany przez

Zigi jak co wieczór siedział przed komputerem. Jednak tym razem na ekranie nie było widać żadnej strony internetowej, ani żadnej gry. Spotify też był wyłączony, co znaczyło, że Zygfryd potrzebuje całkowitego skupienia, a jego chwilowa inteligencja przewyższała nawet możliwości Kuby Wędrowycza.

Zamierzał zrobić to już od dłuższego czasu, jednak jakaś wewnętrzna siła, cały czas powstrzymywała go od decyzji. Wiedział, że jest na to gotowy. Miał doświadczenie, chwytliwy temat i gotową prezentacje. Dlaczego więc wciąż się wahał? Jeszcze raz spojrzał na daty. Deadline wypadał 18 czerwca. Jeszcze był czas, jednak co będzie jak jego zgłoszenie zostanie odrzucone? Co jeśli jego prezentacja zostanie słabo oceniona? W chwilach takich jak ta, Zigi odwoływał się do wyższych wartości. W momentach zwątpienia zadawał sobie jedno pytanie: Co by zrobiłby Geralt z Rivii?

Odpowiedź była prosta! Nie zważając na przeciwności, nie oglądając się na innych prezenterów Geralt by to zrobił. Wysłałby swoje zgłoszenie w odpowiedzi na Call for Papers na konferencę TestWarez 2018. Zygfryd powoli chwycił myszkę, najechał na ikonę przeglądarki i dwukrotnym kliknięciem otworzył Internet Explorer. Chwila refleksji przyszła szybciej, niż zdążyło się otworzyć okno przeglądarki. Zigi szybko zamknął IE i otworzył Chroma. Jak adres URL podał www.testwarez.pl.

Był zdecydowany. Wiedział, że teraz jest jego chwila. W jego głowie nie tylko Geralt, ale i inni bohaterowie podpowiadali mu, że teraz jest jego chwila.  Wypełnienie formularza zajęło mu niecałe 5 minut. Oto on: tester, mąż, gracz, prezenter na konferencji TestWarez 2018.

Trudna sztuka udzielania feedbacku

Opublikowany przez

Zigi od rana był w dobrym humorze. Jego testy automatyczne chodziły bez zastrzeżeń, jego forma na treningu rosła z dnia na dzień, a cena piwa kraftowego systematycznie malała. Jednym słowem powodów do narzekań Zygfryd – nie miał.

Z dużą dawką optymizmu powitał więc nowego maila, który przyszedł na jego skrzynkę. Była to wiadomość od jednego z liderów zespołów testowych. Z treści wynikało, że zbierał on informacje o jednym z jego kolegów z zespołu, w celu dokonania uczciwej oceny roczne. Prosił więc on Zigiego o feedback, aby móc, bądź co bądź w sposób uczciwy, ocenić kolegę Zigiego – Tomka.

Zygfryd akurat miał zrobić sobie zasłużoną przerwę, jednak zdecydował się popracować jeszcze 5 minut i szybko odpisać liderowi. Rozsiadł się wygodnie w fotelu i wytężył mózgownicę.

Co można było powiedzieć o Tomku? Robił swoje, przykładał się do pracy, większych wpadek nie zanotowano. Polecam tego allegrowicza? Bez sensu. Przecież to samo można by powiedzieć o każdym! Zygfryd zastanowił się jeszcze chwilkę, chcąc wyciągnąć ze swojego zrelaksowanego mózgu jakiekolwiek konstruktywne informacje o Tomku. Nic…pustka…Dobry humor zaczął być zastępowany przez zirytowanie i gniew. Wizja przerwy oddalała się z minuty na minutę a do wachlarza emocji doszło wkurzenia, poddenerwowanie i lekki wkurw. 30 minut później w treści maila jedyne co istniało to adres nadawcy i stopka z danymi Zigiego, która dodawała się do każdej wiadomości automatycznie.

Rezygnacja była czynnością, który Zygfryd nie wykonywał zbyt często. Jego ambicja nie pozwalał na zbyt szybkie rezygnowanie z zaczętych rzeczy. Nie inaczej było tym razem. Bliski rozpaczy Zigi odpalił Google i w polu wyszukiwarki wpisał: Jak udzielać konstruktywnego feedbacku. Na ekranie zobaczył linki prowadzących do najwybitniejszych coachów polskich. Coaching. Na samą myśl o słuchaniu tych bzdur zrobiło mu się niedobrze. Gadanie o strefach komfortu, wyjścia z cienia, pracy nad uczuciami powodowała u niego odruchy wymiotne. Jednak tym razem nie miał innego wyjścia. Z drżeniem serca odpalił pierwszy znaleziony filmik. Gęba, jaką zobaczył, już sama w sobie była wyrocznią, jakiego rodzaju feedback na temat obejrzanego materiału zostawi w komentarzach.

Ważne i ważniejsze

Opublikowany przez

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 🙂

Selenium NIE dla początkujących

Opublikowany przez

Zigi pełen niepokoju usiadł przed komputerem. Pełen zgrozy i umiarkowanego optymizmu chwycił za mysz i kliknął w ikonkę Eclipsa na swoim Windowsem. Po chwili jego oczom ukazał się ekran główny jego świeżo zainstalowanego środowiska programistycznego. Dwa kliknięcia później na ekranie już widoczna była pusta, biała strona, a u samej góry wesoło migał kursor, zachęcając do napisania pierwszej linijki kodu. Ten dzień w końcu nadszedł. Zygfryd zaczął uczyć się automatyzacji testów.

Ten dzień był nieunikniony, jednak Zigi odwlekał go jak tylko mógł. Przecież był testerem – nie programistą. Dlaczego więc ma się uczyć jakiegoś języka programowania? Jakby chciał zostać developerem, to wybrałby inne studia i inaczej pokierował swoja karierą. Tymczasem w firmie, gdzie pracował, przesłanie było proste: Nie automatyzujesz – nie pracujesz.

Niepocieszony, że musi wyjść ze swojej strefy komfortu, Zygfryd wpisał w Google: Selenium dla początkujących i zaczął czytać. Godzinkę później był już w stanie napisać parę pierwszych linijek kodu. Sam koncept nie wyglądał na skomplikowany. Otwórz stronę, znajdź element i wykonaj na nim jakąś akcję. Raptem pare komend, nic trudnego. Driver, get URL, Select by ID, click i enter!! Jego pierwszy program zaczął się kompilować. Po chwili na ekranie otworzyła się przeglądarka Chrome, a w pasku zaczął wpisywać się adres strony głównej Google. Chwila prawdy zbliżała się nieubłaganie. Zygfryd zacisnął kciuki i z skoncentrował wzrok na polu wyszukiwarki. Sekundę później ukazał się w niej tekst: „asdfasdfadsf”, a dwie sekundy później został wciśnięty przycisk szukaj. Widząc sukces swojego pierwszego projektu Zigi aż podskoczył z radości. Chyba zbyt pochopnie ocenił i przestraszył się automatyzacji. Teraz wystarczyło nauczyć się dostawać do elementów po xPath, CSS, klasie itp. i właściwie tyle. Wszystko inne wydawało się proste.

Zadowolony z pierwszych sukcesów, nasz tester automatyczny, jak w myślach zaczął na siebie mówić, przerzucił się w Google na swój docelowy projekt. Na szczęście element, do którego chciał się dostać miał nadany ID. 10 minut później był gotowy do odpalenia kolejnego programu. 11 minut później zdruzgotany niepowodzeniem Zigi przeklinał automaty i wszystkich programistów. Jego program nie zadziałał. Diagnoza według jego kumpla: AJAXy się nie załadowały, trzeba nadpisać metodę wait, tak żeby czekała na załadowanie wszystkich elementów na stronie. Poza tym, należy stworzyć osobne klasy na lokatory, executory, zapoznać się z Page Object Pattern i PageFactory i zrobić całkowity refactoring kodu.

Smutny i pełen nienawiści do programowania i samego siebie Zigi zamknął IDE i w Google ponownie wpisał: Selenium dla początkujących. Zapowiadał się długi dzień.

Dobra zmiana

Opublikowany przez

Nic tak nie pobudza mózgu do pracy, jak robienie czegoś nowego. W momencie, gdy wydaje nam się, że przestaliśmy się rozwijać, a testowanie czy BJJ przestały sprawiać przyjemność to znak, że najwyższy czas na zmianę. Nie drastyczną, nie na stałe, tylko po to, żeby pobudzić mózg do działania i za jakiś czas wrócić do pierwotnych zajęć z pełną werwą.

BJJ nie jest jedyną słuszną sztuką walki. Boks tajski, MMA, Kickboxing, a może siłownia? Każda z tych aktywności będzie miłą odmianą od treningu parterowego. Inne mięśnie zostaną zaprzęgnięte do pracy, inaczej trzeba będzie balansować ciałem. Zdobędziemy nowe umiejętności, poprawimy koordynację i przekonamy się, czy forma zdobyta ma macie ma przełożenie na inne sporty.

Co powinien zrobić tester w chwilach stagnacji? Zacząć programować? Blogować? Kręcić filmy na YT. Tutaj odpowiedź nie jest prosta. Ciężko jest zacząć programować tak, żeby już od samego początku mieć z tego radość. Blogowanie to też nie jest zajęcie na 2 tygodnie. Może zacząć się uczyć nowego języka obcego? Rozpocząć naukę gry na instrumencie? Każda aktywność jest dobra, byle tylko oderwać się od rutyny testowania.

No dobrze, a co z aktywnościami biernymi? Może lepiej odpuścić sobie sporty i zacząć oglądać seriale? Tyle fajnych filmów jest do obejrzenia i książek do przeczytania. Już nie wspomnę ile rodzajów piwa jest do spróbowania! Wszystko jest dla ludzi, jeśli używa się tego z rozsądkiem. Możesz wypić dwa piwa, iść na trening, potem pouczyć się chińskiego i na końcu obejrzeć serial w HBO. Jeśli tylko to pobudzi Cię do działania, to droga jest otwarta. Ty znasz siebie, wiesz jak reagujesz na dany bodziec. Cokolwiek robisz, rób to z głową. Ja wybrałem boks tajski i język hiszpański.

 

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

Opublikowany przez

„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!

Tłumaczenia – uroki pracy testera

Opublikowany przez

Zygfryd z nietęgą miną spoglądał na tłumaczenia dostarczona przez klienta. Sześć języków: angielski, niemiecki, hiszpański, francuski, włoski i grecki, z czego Zigi rozumiał tylko angielski. Myśl, że już jutro developerzy podmienią tłumaczenia na docelowe i wrzuca cały projekt do testów przerażała go bardziej niż kolumna samochodów BOR jeżdżąca na sygnale przez miasto. Pięć stron A4 tłumaczeń, w tym język grecki, który wygląda jak pismo, jakim posługują się Obcy z zaświatów. I jak tutaj dobrze i sumiennie sprawdzić, czy wszystkie tłumaczenia wrzucone przez devsów, zgadzają się z tymi, które dostarczył klient?

Na drugi dzień Zigi z jeszcze bardziej podłym humorem usiadł przy biurku i odpalił PC. Wiadomość na Slacku, że tłumaczenia są już gotowe do sprawdzenia, nie była dla niego żadnym zaskoczeniem. Z niesmakiem odpalił pierwszą stronę aplikacji, na drugim ekranie otworzył excela z tłumaczeniami i słowo po słowie zaczął porównywać teksty. Na pierwszy ogień poszedł hiszpański.  Po godzinie sprawdzania miał już serdecznie dość. „Zostań testerem mówili, będzie fajnie mówili” – narzekał sam do siebie w myślach. „A trzeba było iść na operatora koparki. Wszyscy się z tego pomysłu śmiali, ale kasa, jaką oferowali dla operatorów, z pewnością nie jednego przekonałaby do zmiany zawodu” – kontynuował rodzinną tradycję marudzenia.

Z ciekawości Zigi otworzył jeszcze tłumaczenia dla języka niemieckiego i francuskiego. Pierwsze, co rzuciło się mu w oczy to fakt, że część tekstów jest pogrubiona. Z niepokojem otworzył wszystkie tłumaczenia i sprawdził pobieżnie całość.  Okazało się, że dla różnych języków, różne teksty w różnych miejscach są pogrubione. Czy tak wynika z kultury danego języka? Czy to jest błąd? Czy developerzy powinni do aplikacji również wrzucić pogrubione teksty? Ilość potencjalnych problemów rosła w zastraszającym tempie.  Nawet heroiczna próba skopiowania testów z aplikacji do Notepada++ i użycie wtyczki Compare okazała się nieskuteczna.  Co robić, jak żyć?

W tym momencie Zigi zauważył, że na skrzynkę mailową przyszła nowa wiadomość email. Kątem oka Zygfryd zauważył tylko jedno słowo – praktykanci. W tym momencie Zygfryd poczuł, jak nowa, co by nie mówić wręcz wspaniała, myśl, przychodzi mu do głowy. W końcu każdą osobę da się zastąpić skończoną ilością praktykantów. Tak strasznie wszyscy chcą zostać testerami. Przecież to takie, łatwe, proste i przyjemne. Parę kliknięć myszką i po pracy. No to teraz zobaczymy jaką będą mieć minę, jak zobaczą 30 stron tłumaczeń do sprawdzenia.

Zadowolony z siebie, jak nigdy wcześniej, Zigi kliknął na maila prawym przyciskiem myszy i z listy wybrał słówko -Odpowiedz. W nowym oknie przeszedł do pola z wiadomością i zaczął pisać: Hej, będę miał robotę dla praktykantów…

Klient – władca wymagań

Opublikowany przez

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?

Opublikowany przez

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.