Artykuł będzie traktować o tym, jak zgłaszać i analizować defekty, nawiązując do technik analizy i syntezy stosowanych przez największych detektywów popkultury: Sherlocka Holmesa, Dr House’a czy Herkulesa Poirota. Przekażę, jak wykorzystanie różnych perspektyw oraz narządzi analitycznych wspiera raportowanie defektów. Podpowiem, czego my – testerzy – możemy się nauczyć z kryminałów oraz jak przygotować się i przeprowadzić śledztwo w sprawie defektu.
Wstęp. Teza – metody analityczne stosowane przez policję i detektywów mogą pomóc w pracy testera
Znajdowanie defektów jest najważniejszą częścią pracy testera. Jest jak praca detektywa: w obu przypadkach mamy poszlaki, sprawę do rozwiązania, raport do napisania. Korzystamy z podobnych lub tych samych technik przy zgłaszaniu defektów i analizowaniu specyfikacji. Zobaczmy, jak możemy wzbogacić swój warsztat testerki, korzystając z narzędzi, które wykorzystują słynni detektywi.
Aby zaraportować defekt, jak słynni detektywi, będziemy posiłkować się następującą metaforą:
Potraktujmy stan systemu (defekt) jako miejsce zbrodni. Tutaj rozpoczyna się nasza analiza, a następnie synteza i zestawienie wszystkich informacji w raporcie. Zaczynamy od zbadania miejsca zbrodni, następnie weryfikujemy, czy zebrane dowody są wystarczające. Potem sprawdzamy poszlaki i rekonstruujemy defekt. Gdy go przeanalizujemy, możemy dokonać syntezy i wysłać raport.
Defekty w oprogramowaniu mogą być jak tajemnicze sprawy kryminalne. Każdy z nich ma swoje przyczyny, symptomy i skutki.
Dedukcja i logika – Sherlock Holmes
Człowiek obdarzony umysłem prawdziwie logicznym – pisał autor – może z kropli wody wywieść możliwość istnienia Atlantyku lub Niagary, choć o nich poprzednio nie wiedział.
Artur Conan Doyle, Sherlock Holmes. Studium w szkarłacie
Sherlock Holmes, naczelny detektyw popkultury, w swoich śledztwach opierał się na zbieraniu danych, wnioskowaniu i tworzeniu hipotez. Mistrz dedukcji, który nawet z najmniejszych szczegółów potrafił wyciągać zaskakujące wnioski. Zobaczmy, jak możemy wykorzystać jego doświadczenie opisane przez sir Artura Conana Doyle’a w naszej pracy testera.
Zbieranie danych
Słynny detektyw z Backer Street 221B korzystał z rozumowania abdukcyjnego i dedukcyjnego na podstawie zebranych faktów. Tak jak on, podczas raportowania defektów korzystamy ze zebrania wszystkich możliwych informacji tj.
- logi systemów,
- logi dodatkowych narzędzi,
- rekordy w bazie danych,
- stan systemu.
Przy zbieraniu danych będą nas interesować wszelkie parametry mające wpływ na zachowanie systemu tj.
- ruch sieciowy,
- obciążenie systemu,
- konfiguracja użytkownika,
- konfiguracja systemu,
- wersja systemu,
- licencje 3rd party,
- przeglądarka,
- procesy działające w tle.
Wnioskowanie i tworzenie hipotez
To szare komórki, mózg (…) jest tym organem, na którym należy polegać. Zmysły mogą zawieść. Prawdy należy szukać nim, a nie poza nim.
Agatha Christie, Poirot prowadzi śledztwo
Abdukcja jest procesem wyjaśniania stanu, który jest wiadomy (np. skoro jest kura, było jajko). Możemy sprawdzić na podstawie zebranych danych, jakie procesy musiały zostać wykonane przez system. Nieodzowna dla tego rodzaju analizy będzie wiedza o budowie testowanego systemu, jego połączeniach i użytej architekturze.
Na podstawie abdukcji sceny zbrodni oraz zebranych poszlak nasz Sherlock Holmes dedukował, co mogło być przyczyną/motywem defektu/zbrodni. Najważniejsze w metodzie analizy abdukcyjnej jest wykorzystanie wiedzy domenowej oraz znajomości architektury systemowej.
Na podstawie zaistniałego defektu możemy również wydedukować ewentualne obszary w systemie, które należy poddać regresji (w przypadku systemów, w których występuje kod spaghetti, jest to utrudnione lub niemożliwe) lub zgadnąć, jakie defekty mogą wystąpić. Możemy też posilić się sztuczną inteligencją, która może odgadnąć defekty za nas.
Diagnostyka – dr House
Kolejnym detektywem, którego pracy się przyjrzymy, jest dr House. Może nie rozwiązuje zagadek kryminalnych, tylko stawia diagnozy, ale mimo to, warto spojrzeć na jego metody pracy i zastanowić się, jak te mogą nam służyć w raportowaniu defektów.
Eliminacja fałszywych przyczyn
Ponieważ defekty są w dużej mierze zależne od specyficznej konfiguracji, my też, zgłaszając defekt, powinniśmy sprawdzić, jakie parametry miały wpływ na wystąpienie defektu.
Według Rexa Blacka (dostęp 19.01.2025) powinniśmy najpierw wykluczyć, czy defekt, który zamierzamy zgłosić, jest zależny od środowiska (generalizacja) czy też danych testowych (odizolowanie), najlepiej wykonując test przy innych ustawieniach.
Tak jak dr House, wykluczamy fałszywe przyczyny oraz – jak Sherlock Holmes – weryfikujemy swoje hipotezy.
Praca zespołowa
Cuddy: Czy ty właśnie wziąłeś dwa Vicodiny?
House: Nie. To był antydepresant. Kazano mi brać dwa za każdym razem, gdy wchodzisz do pokoju.Dr House, S03E16 Ściśle tajne
Jednym z kluczowych momentów rozwiązywania zagadki – czy to kryminalnej, czy diagnozy lekarskiej – jest wsparcie się pracą zespołu: grupy specjalistów – diagnostyków (jak u dra House’a) lub wiernych przyjaciół (jak u Holmesa).
Nasz zespół, o ile go mamy, może nam pomóc w powtórzeniu (zrekonstruowaniu) defektu z innymi ustawieniami, na innym środowisku, dzięki czemu możemy wykluczyć błędy związane tylko z daną instancją systemu. Warto też poprosić kolegę/koleżankę z zespołu o przegląd naszego defektu, aby sprawdzić, czy nasz opis jest czytelny, informacje kompletne, a tytuł przykuwa uwagę interesariuszy.
Root Cause Analysis
Analiza przyczyn źródłowych jest niezwykle ważnym narzędziem w procesie zarządzania cyklem defektów. Oczywiście – pełna analiza przyczyny pierwotnej bez patrzenia w kod jest trudna, dlatego jeżeli mamy tylko taką możliwość, prześledźmy, co mogło spowodować wystąpienie defektu. Jest to nieodzowny element doskonalenia organizacji. Możemy pomóc w analizie przyczyny źródłowej (RCA), eliminując najczęstsze przyczyny niewynikające z kodu.
Najczęstszymi przyczynami wystąpienia defektów (za geeksforgeeks.org, dostęp 19.01.2025) są:
- problemy z wymaganiami (niejasne, niekompletne, niewłaściwe),
- problemy z designem (słaba architektura systemu, niewystarczające inspekcje designu, kod spaghetti),
- problemy z kodem (brak standardów kodowania, nietrzymanie się definicji wykonania, brak inspekcji kodu),
- brak pokrycia testami (niewystarczające pokrycie testami jednostkowymi, brak testów automatycznych, brak regresji),
- czynniki ludzki (problemy z komunikacja, brak znajomości tematu).
Różne perspektywy – Herkules Poirot
Wiedza z różnych dziedzin oraz rozeznanie w psychologii i ludzkiej naturze pomoże nam zaraportować defekt. Porównałbym przygotowanie samego raportu do klasycznej sceny, kiedy wszyscy podejrzani zostają zebrani w jednym pomieszczeniu, a Poirot opowiada o tym, co się wydarzyło, kto jakie miał intencje, a morderca przyznaje się do winy. Zobaczmy, co ma do zaoferowania ten sławny detektyw z nienagannymi manierami i wąsikiem.
Empatyzowanie z użytkownikiem
Tak jak Herkules Poirot, który w rozwiązywaniu swoich zagadek empatyzował w każdym podejrzanym. Dzięki zrozumieniu ich intencji i potrzeb, potrafił odkryć motyw i sprawcę zbrodni. Wchodzenie w rolę klienta i zrozumienie jego potrzeb jest kluczowe w wykonaniu testów klienckich oraz w znalezieniu defektów, które, choć nieoczywiste z perspektywy klienta, są istotne. Moim zadaniem, póki robimy oprogramowanie dla ludzi, póty empatia będzie naszą kluczową kompetencją – niezzastępowalną przez maszyny.
Więcej na temat person i wchodzenia w role (Persona – testowanie z wykorzystywaniem technik z gier RPG) oraz na temat testów klienckich (Organizowanie testów akceptacyjnych u klienta) napisałem już wcześniej w poprzednich artykułach blogowych.
Myślenie systemowe
– Co ci zawsze mówiłem?! – wybuchnął mój przyjaciel. – Nie wolno nic pomijać. Jeżeli jeden szczegół nie pasuje do teorii, lepiej odrzucić teorię.
Agata Christie, Tajemnicza historia w Syles
Kolejnym cennym narzędziem z zasobnika Herkulasa Poirota jest myślenie systemowe, przyglądanie się całości procesu i systemu. Sprawdźmy, czy defekt, który raportujemy, wpływa na główną funkcjonalność bądź inne procesy biznesowe. Sprawdź, czy powiązane systemy mogą być dotknięte przez jego występowanie. Ta informacja jest kluczowa w ustaleniu wpływu i priorytetu zgłoszenia, nad którym pracujemy.
Analiza historyczna
Spójrzmy za radą Poirota na historyczne dane, na najczęściej występujące defekty i defekty, które zaaportowali nasi koledzy. Być może już ktoś wykonał za nas pracę, a nasz defekt nie zostanie odrzucony jako duplikat. Na postawie danych historycznych możemy przewidywać, czy podobny defekt wystąpi w przyszłości lub zaprojektować nasze testy tak, aby uniknąć efektu pestycydów oraz przetestować system w inny sposób.
Miejsce Honorowe: agent Dale Cooper – Intuicja
Nie wiem, dokąd nas to zaprowadzi, ale mam przeczucie, że będzie to miejsce jednocześnie piękne i dziwne.
Dale Cooper, Miasteczko Twin Peaks
15 stycznia tego roku odszedł wielki artysta, legendarny reżyser David Lynch. W wyreżyserowanym przez niego kultowym serialu „Miasteczko Twin Peaks” agent Dale Cooper używał intuicji na równi z innymi metodami analitycznymi. Intuicja jest doskonałym narzędziem w budowaniu hipotez, wyciąganiu nieoczywistych wniosków. Intuicja jest niezbędna do ocenia poprawności, rzeczy subiektywnych – takich jak estetyka, użyteczność.
No i warto pamiętać o tym, żeby za przykładem agenta Coopera każdego dnia niespodziewanie, nieplanowanie zrobić sobie prezent.
Podsumowanie
Wszystkie wymienione techniki stosujemy w naszej codziennej pracy. Celem tego artykułu było podsumowanie najważniejszych narzędzi analitycznych i zachęta do używania ich na co dzień. Dziękuje detektywom i diagnostom, którzy byli moimi przewodnikami po najważniejszych zagadnieniach analizowania i syntezowania.
Call-to-action
Spróbuj wprowadzić techniki śledcze do swojej codziennej pracy testera. Zapisz swoje wnioski i podziel się swoimi doświadczeniami w komentarzach!
Bibliografia
- Artur Conan Doyle, Sherlock Holmes. Studium w szkarłacie
- Agatha Christie, Poirot prowadzi śledztwo
- Agata Christie, Tajemnicza historia w Syles
- Rex Black, The Bug Reporting Processes (dostęp 16.01.2025)
***
Artykuł ten dedykuje pamięci Davida Lyncha.
Zostaw komentarz