One bug story

Opublikowany przez

Once upon a time

…there was a bug, hidden in the software. But he was different, because he, unlike all other bugs, wanted to be found. He knew that his existence might cause a lot of evil and panic in the human world. That’s why he was upset, when his line of code wasn’t found during code review. All static analysis has been done slovenly and inaccurately. That was probably the reason, why he and his buggy friend haven’t been found yet. All hope lies QA team. He believed that their tests will do the trick and he will be located. He will finally be able to disappear, not harming anyone. Because he was not a hero – he was a bug.

Our little monster was so happy when he saw a group of testers starting their job. His buggy heart had beaten faster, when he saw how new Test Cases started to appear on the screen. But wait… – he looked at the screen incredulously- those tests were incorrectly implemented! They only checked random cases, and the description was so brief. They will never find him if they continue in this manner! Our bug knew what would happen if he was sent into production. He crossed his fingers, hoping that they will come up with other ideas. He noticed how other lines of code lighting up from time to time, indicating that they were being tested. However, to his despair, his line remained dark. All of a sudden, a bug saw a new person walking into QA team’s direction.The Tester took a peek at the Test Cases and started to write something on board. Yes! He proposed Pairwise technique as an extension to standard Test Cases. Bug jumped, full of joy, knowing for sure, that he shall finally be found. However, when he glanced at the blackboard, his enthusiasm burst as a bubble. Cases mentioned in the table were insufficient… The Tester did not even point all the required pairs. Although he chose the good technique, he didn’t know how to use it properly. Bug realized that he will not be found. So, when QAs finally implemented the table, he was sitting there on his line, lonely and full of sadness, knowing that there’s no chance they will spot him. Not this time.

Next morning, some noise woke him up. This was the sound of lines of code being run! Was it possible? There was no QA team in the room. Nevertheless, tests were running with high speed and accuracy, checking more and more lines of code. That might be it! That were automation tests, going through another iteration. They were supposed to run all night, so they had to find him finally. But his enthusiasm did not last long. Why are they testing the same condition over and over again? And yes, his colleagues were being found one by one, but he was still there in the code!  Meanwhile, the testers who came to work were happy as their tests glowed green. That meant that they worked well. Or so they thought… So little they knew! Automated tests might have been fast. They might have even checked plenty of scenarios. But it didn’t matter since they were testing the same things repeatedly! Our bug started to be frustrated. How hard was it to find him?! He was in the same place all this time, didn’t even move a bit. And yet, they still didn’t notice him.

Day in, day out, testing technique has been changing. But out hero, full of sorrow, was still sitting on his line of code. Suddenly something sparked his interest- buzz-words that the people in the room were talking about. Did he hear well? “Exploration” and “testing in pairs”. That might be it! He had heard many good things about both of these techniques. Exploratory testing- for some it was the only useful technique, for the others it was too chaotic and unacceptable. And testing in pairs – “two heads are better than one”, as they say in the human world. Hope returned! When QA guys were sitting together in front of a computer, he was sure, that soon he will go to the better world, where he’ll join other solved bugs. Oh what a joy it would be! He was excited, when he saw lines of code around him, once immersed in the darkness, now starting to shine for a first time. It was the day! It was now or never. With raising excitement, he was waiting, until his line will be finally tested. But suddenly, number of lines under testing was getting smaller and smaller. Meanwhile, at the screen instead of software, some funny cat picture, football shortcuts and other interludes showed up. QA has a lot of fun in the intervals between films, checking the selective part of the software. That is how exploratory session looks like, when you are not prepared accurately. Without any elements of idea or thoughts. Hope disappeared like a flame on a match.

Current sprint passed and our bug was finally released into production. As he suspected, nobody noticed him during UAT. Because it doesn’t matter how many techniques you are using. If you are using them wrong, you will never find what you’re looking for.

SCRUM – lek na całe (domowe) zło

Opublikowany przez

O zwinnym prowadzeniu projektów informatycznych napisano już chyba wszystko. Ilość książek, konferencji i artykułów na ten temat sprawia, że temat jest wciąż modny i aktualny.

Oczywiście popularność SCRUMA nie bierze się znikąd. Większość ludzi związanych z wytwarzaniem oprogramowania nie wyobraża sobie pracy w innej metodologi. Ja natomiast postanowiłem pójść krok daje i zaproponowałem żonie, aby w SCRUMie prowadzić cały dom:)

Na początku wyobraźcie sobie, że musicie osobie nietechnicznej wytłumaczyć czym jest SCRUM i dlaczego jest on taki fajny. Jednocześnie musicie znieść widok niezadowolenia, gdy tłumaczycie, czym jest task ( u nas było to proste zadanie do zrobienia w czasie krótszym niż 1 dzień) i sprint ( u nas – tydzień), a Wasza sytuacja wcale się nie poprawia, gdy rysując tabelę na białej folii do pisania, okazuje się, że markery przebiły i zabrudziły ścianę. Jednak wszystko to znika gdzieś, gdy całe dzieło jest skończone, a na ścianie w kuchni dumnie prezentuje się tabela z kolumnami TO DO, IN PROGRESS i DONE.

Na potrzeby domowe zrezygnowałem z codziennych meetingów ( w końcu i tak rozmawiamy) natomiast planowałem od czasu do czasu zrobić retrospektywę. Tymczasem na żółtych karteczkach na tablicy zapisałem pierwsze taski:

  • wyrzucić śmieci
  • posprzątać kuchnię
  • zrobić zakupy
  • ugotować obiad

Uznałem, że na początek nie ma sensu rozdrabniać zadania na mniejsze, chciałem bowiem sprawdzić jak zadziała to wszystko w praktyce. Dumnie więc na żółtej karteczce z napisem zrobić zakupy napisałem swoje imię i przeniosłem ją do kolumny IN PROGRESS. Żonie wytłumaczyłem, że każdy może brać dowolnego taska z kolumny TO DO, jak skończy wówczas weźmie następnego, aż wszystkie zadania będą w kolumnie DONE.

Nawet nie wiecie jakie było moje zdziwienie, gdy po powrocie do domu okazało się, że wszystkie taski są przypisane… do mnie. Okazało się, że moja żona uznała, że i tak mam za dużo czasu więc mogę zrobić całą resztę (i mówiła to z uśmiechem i zadowoleniem na twarzy). Wytłumaczyłem więc, że to tak nie działa i poprosiłem, aby przypisała jakieś zadanie na siebie. Na to usłyszałem, że „ale ona nie chce”. Przyznacie, że argument trudny do zbicie? Czarę goryczy przelał w pracy mój PM, który zapytał, czy jak nie zdążymy zrobić obiadu, to chodzimy głodni a obiad przenosimy do następnego sprintu. Na zaczepkę, czy może sprowadzimy sobie teściową jako scrum mastera nie zareagowałem. Chyba to jeszcze wszystko przemyślę.

 

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!