Grzechy QA – moje porażki

#Zgłaszanie błędów

intro

Jakiś czas temu miałem okazję gościć na TrojQA z wystąpieniem “XX rzeczy które jako QA zrobiłem/robię źle”. Była to swoistego rodzaju spowiedź ze swoich grzechów, ale też przyjrzenie się temu co robimy źle jako inżynierowie oprogramowania/testerzy/QA/developerzy. Z racji tego, że większość prelekcji mówi o tym, jak “powinno się” pracować a zdecydowanie mniej mówi się o porażkach, postanowiłem podzielić się kilkoma błędami i porażkami których doświadczyłem. Mając oczywiście nadzieję, że przynajmniej niektórzy z Was będą mogli ich uniknąć lub uświadomić sobie, że być może jesteście na dobrej drodze aby popełnić te błędy.

Z góry przepraszam wszystkich zainteresowanych tą prezentacją za tak późną jej publikację 😉 Jednak gwarantuję, że jej treść się nie zdezaktulizowała. W zasadzie wracam do tych błędów, ponieważ wciąż większa ich część występuje w dużych ilościach w środowiskach w których przebywam. Być może spojrzenie na jej treść z perspektywy czasu również wniesie coś do tematu.

PREZENTACJA

Spowiadam się więc z grzechów, a pierwszym grzechem zaczynam serię miniwpisów. Oto pierwszy z nich. Kolejne paragrafy zaczynamy zdaniem (piszę w swojej osobie dlatego używam męskiej formy):

Przynajmniej raz (oby raz!) w swojej karierze…”

… zgłosiłem błąd

który nie był błędem lub nie dało się go powtórzyć, nie dostarczyłem wystarczających informacji programiście, nie dodałem logu, nie sprawdziłem wystarczająco warunków jego wystąpienia, nie określiłem konfiguracji środowiska, mój opis był niezrozumiały (nawet dla mnie samego czytającego go 15 min później), testowałem na jakiejś starej wersji której już dawno nikt nie utrzymuje 🙂 (sic!), albo moja przeglądarka miała zainstalowany plugin który znacznie wpływał na zachowanie aplikacji itd.

Kto nigdy nie zgłosił zbyt szybko błędu bez pełnej informacji i narobił trochę chaosu, niech pierwszy rzuci kamieniem!

Kto nigdy nie rzucił kamieniem w programistę (…) – temu chwała 😉

Z innych obserwacji dotyczących zgłaszania błędów, spotykałem się na przykład z lenistwem, niechęcą, przerzucaniem odpowiedzialności, na przykład z powodu:

  • niechęci/nieumiejętności czytania logów (chyba, że nic nie można z nich odczytać – to inny problem) – ile razy np. okazywało się, mieliśmy złą konfigurację i połączenie do bazy nie zostało zainicjalizowane
  • obawy przed zrozumieinem stack trace`a – często praca testera kończy się na jego dostarczeniu tylko, pomimo, że stack trace pokazuje nam linijkę w kodzie występienia błędu i często można wywnioskować bezpośrednią przyczynę błędu
  • braku głąbszej analizy po której okazałoby się, że przyczyna piątego z rzędu błędu który dodajemy jest ta sama
  • braku minimalnych kompetencji technicznych aby sprawdzić czy błąd nie jest spowodowany przez awarie zależnych “serwisów”
  • przypinaniu sobie łatki testera manualnego – “nie będę patrzył do kodu bo kod jest dla programistów” – jasne, nie oczekuję, że każdy musi to robić, ale umiejętnośc prostego debuggowania aplikacji w wielu wypadkach może pomóc nam w testowaniu i znajdywaniu błedów

konsekwencje

Zgłaszanie błędów to jedna z podstawowych czynności w software developmencie. Częstym dialogiem w open spacach jest komiksowa wymiana zdań:

“- Nie działa!!!” / “Znowu nie działa!!!” / “<inwektywa ubliżająca kompetencjom developera>”

“- U mnie działa!!!” / “< inwektywa ubliżająca kompetencjom testera>”

Cóż, tak elokwentna dyskusja, mimo, że śmieszna jest zmorą naszych projektów. Ok – dla wielu pewnie też przykra. Wymiana zdań która nie prowadzi do sedna a jedynie wprowadza szum komunikacyjny i psuje atmosferę. Być może dlatego, że mamy bardzo emocjonalne podejście do naszej pracy – oczywiście nic w tym złego, to przynajmniej znaczy, że nam jeszcze zależy. Programiści do swojego kodu, a testerzy do cenionej jakości. Jednak kiedy emocje górują nad merytoryką mamy problem.

Warto pamiętać o tym, że w dużej mierze dostarczanie oprogramowania w godny sposób wymaga wymiany informacji wysokiej jakościu pomiędzy członkami zespołu. Testerzy dostarczają informacje o błędach, jest to kluczowa kompetencja nad którą warto pracować i której warto się przyjrzeć (oczywiście jeżeli nie pracujemy w organizacji gdzie ilość znalezionych błędów > ich jakość).

co robić -> żal za grzechy!

Też przeżyłem wstyd i upokorzenie swoją niestarannością. Nie ma nic gorszego od wzroku programisty spogladającego z uśmieszkiem. Czyli mój błąd nie jest błędem? ale jak to? 🙁

Po kilku takich wpadkach można stracić autorytet u ludzi z którymi współpracujemy, dlatego ważne jest aby poświęcić wystarczająco czasu na upewnienie się czy informacja którą dostarczamy jest zrozumiała i rzetelna. Z kolei zbyt długie wypieszczanie opisu błędu może skutkować tym, że zanim go zgłosimy to błąd będzie już dawno naprawiony. Dobrze wypracować sobie jakiś styl współpracy, na przykład spróbować określić z jakimi błędami przychodzimy od razu, jakie zgłaszamy w systemie, których w ogóle nie zgłaszamy itp.

Często w projektach wypracowuje się jakiś szablon błędu. To jest w porządku, dopóki nie kończymy z 20 polami do wypełnienia, które niekoniecznie czemuś sensownemu służą, lub nie są i tak wypełniane poprawnie, a opis błędu jest wciąż lakoniczny.

Innym rozwiązaniem które działało u mnie była bliska współpraca z programistami – parowanie się co jakiś czas aby spojrzeć na miejsca potencjalnych kandydatów na błędy. Często QA już na początku iteracji dobierał się z developerem do user story, dzięki czemu przez cały cykl mogli ściśle ze sobą współpracować, zaczynając od “kick offa” (gdzie przewidujemy wstąpienie błędu, jakie są ryzyka, na co trzeba uważać, co trzeba przestestować i jak), przez testowanie w trakcie kolejnych “commitów”. To tylko przykład, który w zasadzie pozwalał unikać błędów.

Z tyłu głowy trzeba mieć, że ważne jest działające oprogramowanie i jego ciągłe dostarczanie. Jeżeli błąd nie zaburzy działania systemu na produkcji w znaczny sposób, być może nie warto blokować wypuszczania nowej wersji w sztuczny sposób.

postanowienie poprawy

Zastanowiwszy się w jakim kierunku nabywania kompetencji powinniśmy skierować nasze zainteresowanie:

  • nauczyłbym się czytać logów, starał je zrozumieć (skąd się biorą, jak je analizować, jak zebrać je wszystkie, jakie mamy poziomy logowania, być może mamy podział logów na biznesowy i techniczny) – jeżeli logi są słabe – porozmawiałbym z programistami – logi są dla nas, jeżeli nic z nich nie wyciągamy to może je wyłączmy
  • często dochodzenie przyczyn błędów wymaga pracy ze zdalnymi maszynami, serwisami, umiejętności posługiwania się ssh czy podstawowymi komendami bashowymi, diagnozowanie systemu operacyjnego, czeytaniu event loga, pisanie prostych zapytań do bazy, odpytywanie serwisów – dlatego tutaj w kontekście mojego projektu popróbowałbym zebrać razem co mi jest potrzebne aby mieć “obraz” całości i się tego nauczyć
  • postarałbym się pamiętać o wersji oprogramowania wraz z zależnościami (baza, serwisy itp.), logach, screenshotach, warunkach wstępnych, krokach do powtórzenia, oczekiwany rezultat vs otrzymany rezultat, o innych warunkach które mogły mieć wpływ np. czas, język, środowisko
  • czytałbym dwa razy swój opis błedu i upewniał się, że rozumiem – na początek, można dać do przeczytania też innej osobie
  • wprowadziłbym albo ustalił terminologię tzn. jak nazywamy różne rzeczy w projekcie aby być jednoznacznym kiedy opisuje błąd
  • odrzuciłbym bariery blokujące poznawanie (np. “nie jestem techniczny”) – dopytywałbym i uczył tego co mi jest potrzebne aby pomagać zespołowi w diagnozie problemu

co od Ciebie?

A Ty jaki masz sposób na unikanie tego grzechu? a może w ogóle nie zgłaszasz błędów bo to przeżytek i wolisz im zapobiegać? 😉

Kolejny grzech już niedługo, a dotyczył będzie raportów z testów.

Stay tuned!

Po SC Wro#6 – Visual Testing – kiedy warto?

Pixabay at Pexels

SC Wro

W ubiegły czwartek odbyła się kolejna edycja meetupa Software Craftmanship events – SC Wro#6 poświęcona tym razem tematyce testów. Zostałem zaszczycony zaproszoniem do udziału w panelu dyskusyjnym za co dziękuję organizatorom 😉

Warto o tym wspomnieć, że panele dyskusyjne są stałym elementem na spotkaniach SC Wro i cieszą się powodzeniem. Sam mogłem się przekonać, że są ciekawą formą dyskusji która wyzwala dodatkową energię.

Visual testing

Opisy prezentacji znajdziecie na stronie wydarzenia. Obie były nagrywane wraz z panelem, więc jeżeli kogoś interesują szczegóły na pewno zajrzy na profil organizatora.Pomimo że obie prezentacje mówiły o automatyzacji wizualnej regresji to dotykały tematu w innym kontekście i inny sposób.

Ok, ale może od początku.

Czym są testy wizualne?

W tak szeroką nazwę wpada moim zdaniem wiele rodzajów testów. Prosta odpowiedź: są to testy interfejsu użytkownika. Trochę szersza odpowiedź: testy tego, czy interfejs wygląda poprawnie dla użytkowników. W tym momencie problem staje się złożony i pojawiają się pytania. Dla jakich użytkowników? Każdy przecież jest inny, ma inną percepcję tego co widzi, będzie inaczej używał naszej usługi, jeden woli klawiaturę, drugi myszkę, jeden lubi czekać, drugi nie, trzeci ma problem ze wzrokiem i potrzebuje większej czcionki, starszą osobę będą drażnić kolory tęczy a młodą ekskluzywne szarości, czwarty mieszka w Chinach, a piąty w strefie czasowej +3,30 UTC… itd. itp.
W zasadzie, jeżeli budujemy jakiś serwis publiczny to powinniśmy te aspekty uwzględniać prawda? Cóż … raczej uważałbym temat skazany na porażkę, aby zadowolić wszystkich 😉 Nie mniej, są obszary i zasady którym warto się przyjrzeć i przynajmniej wiedzieć których użytkowników zaspokoimy.

Z obszarów które według mnie wchodzą w worek „testów wizualnych” różniłbym kilka:

  • Testy “dostępności” –  czyli testy które sprawdzają zgodność z ciągle rozwijającym się Web Content Accessibility Guidelines (WCAG). W przeszłości moim zdaniem kojarzone głównie z dostępnością do usług strony przez osoby niepełnosprawne, a dzisiaj szeroko definiując temat również z poziomu użyteczności a nawet i bezpieczeństwa. Temat bardzo szeroki i nadający się na osobnego posta. Jednak zachęcam do spojrzenia do kilku ciekawych porad, aby uświadomić sobie jak złożony jest to temat lub jak bardzo spełniamy/nie spełniamy kryteria np. Error prevention. Między czasie, jeżeli kogoś temat nagli, krótki artykuł opisujący kilka narzędzi wspomagających development oraz testy dostępności
  • testy responsywności – innymi słowy – czy nasza strona wygląda tak samo na różnych urządzeniach i rozdzielczościach? czy elementy się skalują? czy pożądana funkcjonalność na danym urządzeniu jest dostępna?
  • testy użyteczności z użytkownikami – poznanie swojego użytkownika i zobaczenia na żywo jak korzysta z aplikacji jest z reguły drogą do sukcesu. Nie znam się na metodach przeprowadzania takich testów, ale brałem niedawno udział jako beta użytkownik i było to bardzo ciekawe przeżycie. Musiałem mówić co czuję i nad czym się zastanawiam. Byłem obserwowany! Mogłem być szczery i bez ogródek dzielić się spostrzeżeniami i trudami użytkowania! 😉 Jestem pewny, że dzięki takim testom start up poświęci jeszcze trochę czasu, aby przygotować „zjadalną” wersję swojego pomysłu 😉
  • testy A/B? – w wąskim zakresie, ale mimo wszystko powiedziałbym, że wpadają w ten worek. Jeżeli chcemy sprawdzić, czy danym użytkownikom podoba się A czy B to uznałbym to za „test wizualny”, jednak trzeba pamiętać, że testy A/B mają szerszy zakres
  • testy lokalizacji (i18n, l10n) – i znowu, w jakimś zakresie może się zdarzyć, że zawartość naszej strony będzie inaczej wyświetlana w zależności od strefy czasowej, języka, praw obowiązujących w danym kraju itd.
  • RODO? – sami pewnie zauważyliście, że stosowane są różnego rodzaju triki abyśmy nie tak łatwo zrezygnowali z akcpetacji udostępniania naszych danych … w każdym razie, mam tu na myśli wszelakie informacje prawne narzucone z góry. Prawo też jest różne w różnych krajach więc dochodzi globalizacja.
  • Trzymanie się zaleceń grafików –  jeżeli mamy klienta lub sztab grafików którzy po prostu wiedzą jak ma wyglądać interfejs (albo budujemy coś dla znanej marki gdzie szata graficzna jest z góry znana i narzucona, są standardy), wyznaczyli nam reguły, zestawy kolorów szaty graficzne to musimy w jakiś sposób zweryfikować czy przestrzegane są te zasady w całej aplikacji np. czy na wszystkich stronach przycisk OK jest po prawej stronie, ma wielkość 50 × 80 i kolor niebieski
  • … (miejsce na Twój komentarz ;))

Wizualne testy regresji

Zakładając, że nasz software jest rozwijany według powyżej wybranych kryteriów, ustaliliśmy sobie użytkowników i zawartość wyświetlaną w zależności od pory dnia, pogody itp. Kolejnym krokiem jest to, że chcielibyśmy zapewnić w procesie developmentu, że będziemy trzymali się tych zasad. Zostało ustalone co to znaczy “jakość” interfejsu dla naszych użytkowników.

Teraz chciałbym odwołać się do prezentacji, bo wprowadzają kontekst.

Pierwsza z nich prezentowana przez Łukasza mówiła w skrócie o tym w jaki sposób wybrali narzędzie Applitools (pomimo, że padł pomysł, aby napisać swoje, jednak taniej i szybciej jest wziąć coś gotowego) do wykrywaniu regresji w CMSie. Klient sam postawił wymaganie, aby testować interfejs użytkownika ponieważ irytowały go błędy na tym poziomie.

Updated: po napisaniu tego posta pojawił się pełniejszy artykuł który podesłał mi Łukasz.

Z kolei na drugiej prezentacji Mateusz mówił o tworzonym frameworku który mocno opierał się na operacjach wykonywanych na interfejsie użytkownika, ale też i interakcji z tym interfejsem. Kontekstem jednak jest tutaj deska rozdzielcza i oprogramowanie wbudowane w samochód.

Dyskusja

Te dwie różne prezentacje i sposoby testowania interfejsu stały się przyczynkiem do ciekawej dyskusji wsród panelistów 😉

Zgodnie z piramidą testów automatycznych (o której jeszcze nie raz napisze, bo zebrało się trochę chmur nad tym symbolem ;)) zgodziliśmy się na panelu dyskusyjnym wraz z Tomkiem Dubikowskim, że automatyczne testy regresji przez GUI to ZUO 😉 i oczywiście najlepiej ich nie robić za dużo albo w ogóle 😉 byliśmy w opozycji do Łukaszów i Mateusza.

Przypadek1

Biorąc kontekst pierwszego projektu i pierwszej prezentacji, gdzie budowany jest CMSa – trzeba byłoby się zastanowić jakie czekają nas konsekwencje tego, że kolory, przycisk, formatka nie będą idealne, pomimo tego, że funkcjonalnie będzie można wykonać operację biznesową?

Oczywiście sporo zależy od kolejnej warstwy kontekstu, tzn. co to za firma, jaką ma markę, jak ważna jest jakość dla tej firmy – trzeba byłoby umieć obliczyć stratę wizerunkową związaną z nieidealnym GUI. Kolejną minimalizacją ryzyka mógłby być dobry proces Continous Delivery a konkretniej szybkość wychodzenia na produkcję z poprawką po wykryciu takiego błędu.

Przypadek2

Oprogramowanie wbudowane w samochód. Deska rozdzielcza. Tutaj w większości produktem końcowym jest interfejs (zakładam, że w poprzednim produktem jest jednak logika biznesowa CMSa).

Jednocześnie odpowiedzialny za takie operacje jak płynność przewijania menu po dotyku, ale też prędkość, kontrolki alarmujące, czy klimatyzacja. Po niedługiej chwili zastanowienia 😉 czuję, że tutaj nasze GUI jest mega ważne. Patrzę na ryzyko, np. jakaś warstwa multimediów przykrywa mi kontrolkę poziomu oleju … hmm 😉 Z drugiej strony jest też potencjał na wykonanie „backdoora” – np. zatrzymuje nas policja a my pokazujemy deskę rozdzielczą i mówmy, że licznik zaczął pływać i dlatego przekroczyliśmy prędkość 😉

Dodając do tego czynnik, niekoniecznie płynnych deploymentów na produkcję, jeżeli chodzi o oprogramowanie embedded (w końcu nie każdy samochód to Tesla ;)) ryzyko nam wzrasta tak samo i jak i koszt potencjalnej naprawy.

Czy warto i jak warto?

Spora pokusa, aby powiedzieć „to zależy …”. Osobiście jestem przeciwnikiem testów które spowalniają proces. W podejściu pierwszego przypadku zabrakło mi konkretniejszego uzasadnienia biznesowego. Negocjowałbym z klientem czy na pewno potrzebuje takiej automatyzacji, a jeżeli tak, to próbowałbym wpleść zapewnianie testów regresji GUI w proces. Narzędzie Applitools wymaga stworzenia przez nas tzw. baseline czyli stanu początkowego który jest dla nas akceptowalny. Kolejno, testy to „inteligentne” porównanie z baseline. Nie spodobało mi się to, że dla każdej rozdzielczości i ustawienia, systemu, czy przeglądarki trzeba taki baseline osobno wygenerować. Bardzo dużo pracy. Z kolei w procesie developmentu mógłbym prosić programistów, aby uruchamiali test który sprawdza różnice z ostatnim GUI i aby ktoś akceptował zmiany go podobnie jak każdy inny kod w procesie Code Review. Brzmi utopijnie? ktoś już próbował.

W drugim przypadku powstał cały frawemork do testów (nie tylko GUI) a z racji technologii nie było na rynku takich narzędzi. Z kolei mnie przekonuje biznesowo wypełnienie takiej potrzeby. Gdyby tylko jeszcze takie testy były podpięcie w pipeline – życzę aby się to udało (aby mieć szybką odpowiedź zwrotną).

Na koniec

Oczywiście tych którzy się spodziewali, że omówię 20 narzędzi do testów wizualnych* bardzo przepraszam, nie to było celem, a szybkie googlowanie da Wam odpowiedź. Dla mnie ważniejsze tutaj jest zrozumienie, kiedy testowanie regresji wizualnie automatycznie ma sens, a kiedy nie. Przy okazji można pokłonić się nad WCAG … i klęknąć, bo implementacja tego jest wyzwaniem.

*myślę, że tutaj są najbardziej znane

A jak jest u Was? Tematy WCAG na pewno ciekawy, proszę o kontakt w komentarzach.

Kolejny post-blog będzie wynikiem próby rozbicia panelu dyskusyjnego pytaniem: „…a czy tester powinien umieć programować…?” 😉