Przekonałem się o tym niedawno. Kilka dni temu odstawiałem auto do mechanika. To co się wydarzyło później zmusiło mnie do napisania tego tekstu. Myślę, że czasami tak samo dzieje się w przypadku projektów IT. Znalazłem pewną analogię do fixów i retestów. O tym będzie dzisiejszy wpis.

Zacznijmy od początku

W samochodzie miałem do zrobienia zawieszenie. Przy okazji chciałem, żeby zdiagnozowane zostały dziwne odgłosy tarcia pojawiające się w momencie przyśpieszania. Umówiłem się, pojechałem, wytłumaczyłem co i jak. Moje zgłoszenie, tłumacząc na postać zgłoszenia błędu, wyglądałoby mniej więcej tak.

Repro steps:

1. wsiadam do auta
2. uruchamiam silnik
3. jadę i podczas jazdy nasłuchuję pojawiających się odgłosów

Rezultat aktualny: przy przyśpieszaniu w zakresie 1800-2000 obrotów pojawia się odgłos tarcia. Podobnie dzieje się przy puszczeniu gazu w tym zakresie obrotów.

Rezultat oczekiwany: brak odgłosu tarcia podczas jazdy

Tak naprawdę w czasie tej wizyty oczekiwałem znalezienia przyczyny takiego stanu rzeczy lud stwierdzenia, że wszystko jest okej. Nie spodziewałem się szybkiego fixa.

Błędne założenie?

Wytłumaczyłem wszystko co i jak panu, który auto przyjmował. Od razu powiedział mi co może być przyczyną i wszystko rozrysował na kartce. Trochę się zdziwiłem, żeby tak bez odtworzenia błędu. No cóż, zakładałem jednak, że będą próbować powtórzyć sytuację na swoim środowisku, przedebugują, poszukają przyczyny, a jeśli będą potrzebować więcej informacji, w przypadku jakichś wątpliwości, to się ze mną skontaktują. Tak to chyba wygląda w większości zgłoszeń z produkcji w projektach IT. Takie jest moje doświadczenie.

Zgłoszenie

W momencie kiedy mam do czynienia ze zgłoszeniem od klienta, to za wszelką cenę dążę do odtworzenia tego problemu, znalezienia konkretnych warunków, w których problem występuje. Po pierwsze jest to moim zdaniem przydatne do zaaplikowania odpowiedniego fixa, który rozwiązuje dokładnie to, co zostało zgłoszone. Po drugie, daje to większe poczucie poprawnego przetestowania poprawki. W końcu po tym, jak jestem w stanie błąd wywołać, wiem już jakich danych użyć i jaką ścieżkę przejść. Często błędy zgłoszone przez klienta są dość słabo opisane, brakuje wielu informacji, co powoduje pewne trudności przy ich rozwiązaniu. Zdarza się, że chodzi o jakiś bardzo specyficzny przypadek, a nasza wiedza biznesowa może nie być wystarczająca, by mieć 100% pewności.

HINT – Fajne jest posiadanie dwóch środowisk – z fixem i bez fixa. To pozwala na dalsze poszukiwanie dodatkowych przypadków, gdyby były wątpliwości.

Czasami jest też tak, że z powodu pewnych ograniczeń (czasowych lub technicznych – brak odpowiednich danych, środowisk, itp) błędu nie da się odtworzyć. Wtedy retest robiony jest na czuja i bardziej sprawdza się czy poprawka nie jest przypadkiem popsujką. Czy nie psuje więcej niż naprawia. Robi się to, by zminimalizować ryzyko jej wypuszczenia.

Fix, retest

Wróćmy jednak do przypadku z samochodem. Po kilku godzinach dostałem informację, że auto jest do odbioru. Wcześniej kontaktowali się tylko po to, by potwierdzić pewne dodatkowe koszty, które wyszły. Tak jak zostałem poinformowany podczas przyjmowania samochodu, przyczyną tarcia były zużyte klocki hamulcowe.

Odebrałem auto – czas na retest na produkcji przeprowadzony przez klienta. Niestety retest failed.

Co może pójść źle? WSZYSTKO!!

Co poszło nie tak? Dlaczego przygotowany fix nie rozwiązał zgłoszonego problemu? Myślę, że przyczyną jest błędne założenie poczynione na początku oraz dążenie, by je potwierdzić, a nie znaleźć prawdziwą przyczynę. Mimo zapewnień, mam wrażenie, że nie było próby odtworzenia błędu, by zobaczyć w jakich warunkach i dlaczego coś jest nie tak. Prawdopodobnie organoleptyczne oględziny, potwierdziły założenie, że problem tkwi w klockach hamulcowych. Przypuszczałem, że jazda próbna w ogóle nie została wykonana. Co potwierdziło się podczas późniejszej rozmowy telefonicznej.

Czasami tak samo jest w projekcie IT. Mamy jakieś zgłoszenie, być może nie do końca idealnie opisane. Developer patrzy w kod i znajduje coś podejrzanego. Zakładamy wtedy, że to pewnie jest dokładnie to o co klientowi chodzi i na wszelki wypadek nie prosimy o dodatkowe informacje, by być w stanie zdiagnozować problem. W końcu jest coś w tym kodzie co z pewnością nie może działać. Czasami nawet dziwimy się, że dopiero teraz to wyszło. Znacie to?

Co się dzieje dalej? Programista naprawia i przekazuje fix do retestów. Sprawdzamy, wszystko działa. No to dalej na produkcję z tym. Jakież jest nasze późniejsze zdziwienie gdy klient mówi, że problem nadal występuje.

W przypadku auta zabrakło próby sprawdzenia co jest nie tak. W końcu klocki hamulcowe były do wymiany, co potwierdziło tylko pierwotną teorię. Mało tego, jestem przekonany, że nie było nawet retestu, czyli sprawdzenia czy ten fix coś zmienił. GO na produkcję. W końcu jakoś (nie jakość) to będzie.

No i klops. Fix nic nie poprawił, błąd jak był tak jest, a budżet przepalony bezpowrotnie.

Podsumowanie

Jak tego uniknąć? W przypadku zgłoszeń od klienta próbuj sytuację odtworzyć na swoim środowisku. Jeśli zgłoszenie jest słabej jakości, brakuje screenów, logów, innych informacji, za wszelką cenę próbuj je wyciągnąć od klienta. Nic nie zakładaj, pytaj, pytaj, pytaj. Odtwórz błąd, by poznać konkretne warunki, dane lub inne okoliczności, w których błąd występuje. Wtedy będziesz mieć pewność (a raczej z dużym prawdopodobieństwem) poprawności fixa.

Jak pisałem wcześniej dobrze jest mieć dwa środowiska – jedno z fixem, drugie z wersją bez fixa. To daje duże możliwości bardziej dogłębnych testów poprawki. Czasami fix jest szerszy niż, to co otworzyliśmy po zgłoszeniu od klienta. Dobrze jest mieć wtedy odpowiednie warunki do dalszej eksploracji.

Jest jeszcze jeden element tej całej układanki, o który warto zadbać. Mianowicie chodzi, o to by znać wpływ wprowadzanych zmian na funkcjonowanie aplikacji. W niektórych przypadkach sam retest zgłoszenia to za mało. Konieczne może być wykonanie dodatkowych testów, by sprawdzić obszary, na które fix może mieć wpływ.

A jakie są Twoje doświadczenia dotyczące retestowania defektów? Podziel się swoim doświadczeniem w komentarzu.