W pierwszej części artykułu mówiliśmy o pisaniu właściwego opisu summary defektu. W drugiej części zwrócimy uwagę na jeszcze kilka wskazówek i trików, które pomogą w pisaniu lepszego summary defektu.

Krótko, ale nie za krótko.

Pamiętajmy, że summary to krótki opis, a więc nie trzeba pisać w tym polu krótkiego eseju. Z zasady, wystarcza 7-10 słów (nie licząc przyimków i rodzajników). Ale nie trzeba przesadzać, bo nie da się opisać pluskwę w sposób jasny za pomocą 1-3 słów.

Żadnych słów-wypełniaczy, żadnej wody.

Na przykład: "The opening of each new image when viewed on a new tab."
Wiele słów, jednak opisany jest tylko symptom, do tego niezrozumiale.

A chodzi tu o to, że każdy obrazek, gdy klika się na niego, otwiera się w nowej karcie, a to nie jest bardzo wygodne i nie spełnia rozsądnych ocekiwań użytkowników. To samo można byłoby wyrazić w sposób krótszy i jaśniejszy: "On click each image opens in a new tab." 

Byłoby też dobrze sprecyzować, w której sekcji witryny do się zdarza (oczywiście nie we wszystkich).

Jeszcze jeden przykład:
"Entering the purchase section on the site, an error occurs when trying to give feedback."
"Otwierając okno, zatrzasnęły się drzwi." Lepiej nie używaj imiesłowów, jeżeli nie umiesz. I w ogóle, lepiej unikać masywnych konstrukcji.

Dodanie "on the site" jest całkiem zbędne. Wszystkie pluskwy powstające w projekcie oprogramowania, dotyczą tej witryny, więc po co o tym wspominać w opisaniu defektu?

Skracamy:
"Error when trying to give feedback." Przy okazji, jakiego typu błąd? Byłoby dobrze jakoś go zidentyfikować - klasę, kod... Oczywiście nie ma potrzeby powtarzania całego komunikatu o błędzie w summary pluskwy.

Zgłoszenie defektów o niezrozumiałych nazwach tworzy trudności dla samych testerów. Zanim logować defekt, dokonaj wyszukiwania w systemie śledzenia defektów, żeby upewnić się, że nie jest duplikatem... Tu potrzebujemy krótkich, jasnych i jednoznacznych nazw defektów.

2. Brak oczekiwanych rezultatów

Gdy testerzy logują defekt, z pewnością mają pojęcie o tym, co ma być poprawne. Jednak istnieje pułapka: deweloperzy, tak samo jak wszystkie istoty ludzkie, nie są jasnowidzami! I jeżeli oczekiwane rezultaty nie zostały wyraźnie opisane, zawsze istnieje ryzyko nieporozumienia.

Jest jeszcze jedno ryzyko. Deweloper może wyciągnąć swoje własne wnioski o tym, co ma być poprawne, po czym "poprawić" kod i wysłać go dla weryfikacji. I tu powstanie kontrowersja: "Jest poprawiony!" - "Nie jest!" - "Przecież zmieniliśmy tu!" - "Nie trzeba było tego robić!" W wyniku stracono czas i wysiłki kilku ludzi... 

Znacznie łatwiejsze byłoby od początku wytłumaczyć, jakich rezultatów oczekujemy. Nawet jeżeli wydaje się to oczywiste i klarowne dla wszystkich. Według jednego z praw Murphy'ego, "Wszystko co może być źle zrozumiane będzie źle zrozumiane." Poradziłabym początkującym testerom wyrobić sobie nawyk opisywania oczekiwanych rezultatów wyraźnie. (Jeszcze lepiej byłoby dołączyć do opisu odniesienie do konkretnego wymagania.)

3. Newyraźne kroki odtwarzania

Zabrzmi to banalnie, ale kroki lepiej opisywać krok po kroku: jedna linia - jeden krok, numerowany czy nienumerowany, jak chcesz. Nie pisz wszystkiego w jednym długim akapicie, nagromadzając when, while, which, then itp. Patrząc na tak długie i skomplikowane zdanie, trudno będzie odtworzyć defekt. Nawet bardzo prostą rzecz można skomplikować jeżeli opisać w taki sposób:

"When purchasing products, when you press a button to buy, pop-up window, which when pressed to continue shopping, throws on the orders page"

Tę sytuację można byłoby opisać następująco:

"Continue shopping" button redirects to "Orders page" 

Oczywiście, przycisk nie musi przekierowywać na stronę zamówienia, użytkownik ma zostawać na początkowej stronie, aby kontynuować zakupy. Te szczegóły już można opisać w Description.

4. Screenshot zamiast faktycznego rezultatu

Oczywiście, dodawanie screenshotów do opisu defektu jest bardzo przydatne, szczególnie w przypadku opisywania probleów UI. Ale! Żaden screenshot nie zastąpi zrozumiałego opisu tekstowego.
"Actual result: "Request failed validation (see screenshot)" 

Nie powinno się robić w taki sposób. Moje doświadczenie pokazuje, że bardzo rzadko zdarzają się sytuacje, gdy rezultatu faktycznego nie da się opisać słowami. Tak, natrafiałam na takie pluskwy, z którymi trzeba było nagrać wideo, żeby zilustrować problem. Ale do tego doszło parę razy w ciągu 10 lat. Jeżeli masz jakieś trudności, najprawdopodobniej nie do końca rozumiesz, co się dzieje. Screenshot to zawsze dodatkowe źródło informacji.

A propos, w tym przypadku, jeżeli screenshot został stracony z jakichś powodów, nie da się dowiedzieć, o co chodziło w tym defekcie.

Czasem sam screenshot trzeba udoskonalić, szczególnie jeżeli interfejs jest złożony. Zdarza się, że dopiero po długim wpatrywaniu się można zobaczyć, gdzie jest pluskwa. Można narysować strzałkę, zakreslić czy podkreślić ją, aby wyznaczyć miejsce, w którym występuje. A czasem warto po prostu odciąć niepotrzebne elementy i zostawić tylko przydatne do prezentacji pluskwy.

Ogólnie rzecz biorąc, testowanie można traktować jako serwis informacyjny: naszym zadaniem jest przedstawienie jasnej i bezstronnej informacji o jakości produktu. Nie wystarczy wskazać defekt, trzeba umieć poprawnie go opisać. A zatem testerzy powinni być zdolni do wyrażania swoich myśli w sposób logiczny, zrozumiały, bez zbędnych słów, ale precyzyjnie.

Ciąg dalszy nastąpi...

Victoria Slinyavchuk
Consultant on Software Testing