One bug story

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.

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.

Trudne decyzje, niełatwe rozwiązania.

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.