We wcześniejszym artykule wspominaliśmy o relacjach między testerami i programistami oraz opisaliśmy różne strategie pomocne w komunikacji i osiągnięciu konstruktywnej informacji zwrotnej, głównie w odniesieniu do tzw. umiejętności "miękkich". Druga część poświęcona jest wskazówkom i poradom, które pomogą w udoskonaleniu aspektu technicznego informacji zwrotnej.

Problematyczne błędy

Wiele nieporozumień, a nawet konfliktów między testerami i programistami wynika z powodu konkretnych defektów. Czasem programiści odrzucają defekt lub są niezadowoleni ze sposobu, w jaki został opisany. Teraz tylko od testerów zależy, czy przyjmą krytykę w sposób adekwatny i konstruktywny. Przyjrzyjmy się niektórym typowym sytuacjom.

BŁĘDOFEMIA - RODZAJ OBRAŹLIWEGO LUB LEKCEWAŻĄCEGO DZIAŁANIA, SŁOWA LUB INTENCJI W ODNIESIENIU DO BŁĘDU, KTÓRY OPISAŁEŚ.

"To nie błąd, to feature" 

Prawdopodobnie każdy tester spotkał się z taką sytuacją. Jesteś przekonany, że to błąd, jednak programista tak nie uważa. Co robić? Zgodzić się czy sprzeczać?

Prawdopodobnie nie dostarczyłeś wystarczających dowodów na istnienie błędu. Pomyśl o tym, co każe Ci myśleć, że to błąd. Przejrzyj ponownie podstawę testów, przeczytaj jeszcze raz wymagania, spójrz na matrycę śledzenia. Może po dokładnym przejrzeniu wszystkiego przyznasz programiście rację. Jeśli nadal się nie zgadzasz, postaraj się poprzeć swój punkt widzenia większą ilością argumentów.

Czasem zdarza się, że programista i tester przeczytali te same dokumenty, lecz zrozumieli je w inny sposób. Pozostaje pytanie: kto zrozumiał je właściwie, a kto błędnie. Możliwe, że obaj są w błędzie i powinno to zostać wyjaśnione w komunikacji na żywo. Jeśli dalej nie można osiągnąć porozumienia, włącz osoby trzecie − może to być analityk biznesowy, kierownik projektu lub każdy inny człowiek, który jest dla Was autorytetem i którego decyzję jesteście w stanie przyjąć.

"Błąd jest niepowtarzalny" 

Żaden tester nie może znieść sytuacji, kiedy błąd jest wydawany z tym stwierdzeniem, ponieważ zawsze wymaga to dalszej analizy. Może to być sygnałem dla Ciebie, że problem tkwi w środowisku.

Możliwe jest także, że programista sprawdził inną wersję produktu, w której wprowadzono zmiany, co należy wyjaśnić.

Jest także bardzo prawdopodobne, że nie opisałeś wszystkich kroków wystarczająco szczegółowo lub zapomniałeś zawrzeć któregoś z warunków wstępnych. Może być też tak, że błąd nie zawsze jest powtarzalny, jednak tego nie zauważyłeś. To następna sytuacja, której nikt nie lubi...

Mimo wszystko, trzeba znaleźć rozwiązanie. Jednak argument w stylu "u mnie to działa" jest zbyt słaby i nie może służyć jako wymówka dla zostawienia błędu. Jeśli błąd jest wielokrotnie powtarzany w wersji testowej i Twoim środowisku testowym, powinieneś nalegać, aby programista mimo wszystko poświęcił temu trochę czasu. Dodaj dowody w postaci screenshotów i logów. W bardziej złożonych przypadkach będziesz potrzebował rozbudowanego logowania.

Źle opisany defekt

Nieprawidłowy opis defektu także może być przyczyną powstania konfliktu. Punkt "oczekiwane rezultaty" (expected results) jest często omijany. Programista patrzy na specyfikację i nie rozumie, dlaczego coś jest błędem. Jak powinno być prawidłowo? Co miałeś na myśli? Zawsze dodawaj ten punkt, nawet jeśli wydaje Ci się, że jest trywialny i oczywisty. To nie zajmie zbyt wiele czasu, za to pomoże uniknąć niepotrzebnych dyskusji.

Nieprawidłowe priorytety

Zbyt wysoki priorytet lub ważność (severity) określona dla defektu może być iskrą zapalną wśród programistów. Kiedy przychodzi do nich defekt z ważnością: "critical", są w stanie rzucić wszystko i zaczynają szukać źródła problemu. Gdy okazuje się, że ważność defektu jest nawet niższa niż "major", irytacja i złość programisty jest całkiem zrozumiała: zostali rozproszeni przez drobiazg. Szczerość jest bardzo ważną cechą w pracy testera. Nie zawyżaj ważności defektów! Nie powinieneś jej także zaniżać, w przeciwnym razie może dojść do zaniedbania ważnego problemu.
Najlepszym wyjściem jest posiadanie wspólnie zaakceptowanej przez testerów i programistów klasyfikacji ważności defektów. Możesz użyć standardowego systemu lub stworzyć swój własny − najważniejsze jest, by wszyscy się z nim zgadzali. Oczywiście, wszyscy testerzy powinni o nim wiedzieć i umieć z niego korzystać.

Powtarzalność nie jest określona

Programiści mogą czasem narzekać na opis defektu, jeśli nie wskazano, że defekt nie zawsze jest powtarzalny. Szczególnie, jeśli priorytet defektu jest bardzo wysoki.

"Reproducibility", jako standardowe pole w opisie defektu, nie występuje we wszystkich systemach śledzących pluskwy. Jest na przykład w Mantis, gdzie można wybrać jeden z następujących wariantów:

• Always - Zawsze
• Sometimes - Czasem
• Random - Rzadko
• Have not tried - Nie sprawdzono
• Unable to duplicate - Nie można odtworzyć

Być może warto dodać tego typu opcjonalne pole do swojego systemu śledzenia pluskiew. Nawet jeśli nie masz osobnego pola, należy wskazać powtarzalność defektu w opisie, jeśli jest inna niż "always/zawsze".
Inną możliwością jest tymczasowe przypisanie defektu do siebie i kontynuowanie testowania do czasu, kiedy znajdzie się prawidłowość i/lub zgromadzi się niezbędne informacje na temat zachowania defektu.

Victoria Slinyavchuk
Consultant on Software Testing