#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.
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!