Ucząc ludzi którzy robią swoje pierwsze kroki w zawodzie QA, regularnie napotykam te same typowe błędy, przez nich popełniane. W tym artykule chciałabym przeanalizować niektóre z nich i udzielić porad, jak można takich typowych błędów unikać.

Przede wszystkim, omówmy, w jaki sposób documentuje się defekty. Skoro to jest najczęściej występujący w testowaniu artefakt, każdy tester powinien umieć odpowiednio dokumentować pluskwy. Można obejść się bez przypadków testowych, jednak nie da się obejść bez defektów.

1. "Puste" summary

Dużo już powiedziano o tym, jak należy i jak nie należy pisać nazwy defektów, jednak początkujący popełniają te same błędy. Według popularnej rekomendacji, nazwa defektu ma odpowiadać na trzy pytania: "Co? Gdzie? Kiedy?". To bardzo dobra rada, ale czemu tak trudno do njej się stosować?

A więc, przede wszystkim trzeba pamiętać, że nazwa defektu ma opisywać sedno problemu. Z reguły robi się to za pomocą zdania, skonstruowanego zgodnie z regułami języka którym się posługuje. Pamiętasz lekcje gramatyki? Czym jest zdanie?

"Zdanie to jednostka tekstu, składająca się z jednego i więcej słów, które są powiązane gramatycznie i przekazują zrozumiałą treść." 

Ogólnie, krótki opis (summary) defektu powinien odpowiadać na pytanie, "Co jest nie tak?" czyli, innymi słowy, "Na czym polega problem?" Nazwa powinna zawierać w sobie informację, której by wystarczyło, aby zrozumieć problem. Żeby zrobić to w sposób zrozumiały, chociaż w przybliżeniu, powinieneś dać w nazwie odpowiedzi na każde z trzech pytań:

• "Co?" - Powinieneś chociażby opisać zachowanie oprogramowania, które uważasz za błędne, nie spełniające wymagań /standardów/oczekiwań. W uproszczeniu, to symptom.
• "Gdzie?" - W której części produktu lub systemu (moduł, strona, funkcjonalność)? Nazwijmy to lokalizacją.
• "Kiedy?" - Czyli w jakich warunkach defekt się powtarza. To jest trigger.

Spójrzymy na niektóre przykłady nazw defektów i zobaczymy czy odzwierciedlają sedno problemu.

"Incorrect Site Search" 

O czym jest ten opis? Da się tylko zrozumieć, że defekt jest związany z pewną funkcjonalnością, a mianowicie z funkcją wyszukiwania witryny. Odpowiada na zapytanie "Gdzie?" Ale co nie tak z funkcją wyszukiwania? Jak przejawia się błędne zachowanie? Jest to zagadka. W jakich warunkach powtarza się defekt? To następna zagadka.

Oto inne summary tej samej pluskwy: "The result of the action of the empty site search".
Już cieplej... Można zrozumieć, do której funkcji odnosi się pluskwa i nawet zidentyfikować warunki, w których się powtarza. Jednak ani słowa o tym, co idzie źle. Tylko "rezultat" - jakiś rezultat bez szczególów... A przecież to jest najciekawsze!

Żeby zrozumieć problem, trzeba przeczytać cały opis i spróbować powtórzyć pluskwę. W przypadku pustego zapytania wyszukiwawczego, przed listą produktów pojawia się okno z nazwami kategorii, w którym jeden obrazek jest za duży i nie mieści się w UI. Krótko możemy to opisać w następującym summary:
"After empty search request too large image is shown in "category-view" div" 

Oczywiście, do opisu tej pluskwy należy dołączyć screenshot.

Jeszcze jeden przykład:

"comment".
Tak, tyle to... Jedno słowo wskazujące obszar funkcjonalny.

Byłoby bardziej zrozumiałe w taki sposób:

"Fatal error: 463 on attempt to post review at product description page."

"broken layout" 
Opisuje to symptom, błędne zachowanie, a więc może być rozpatrywane jako odpowiedź (choć i bardzo przybliżona) na pytanie "Co (się dzieje)?" Ale gdzie dokładnie to sie dzieje? Na której stronie? Na każdej stronie? To nie jest oczywiste. I co trzeba zrobić, żeby układ został wadliwy? Ani wskazówki.

Poprawny krótki opis tej samej pluskwy:

"On 150% zoom images at all pages are superimposed".

I jeszcze jeden przykład:
"Registration with invalid email." 

Być może, tej nazwy wystarczyłoby dla przypadku testowego. Jest jasne, do której funkcjonalności odnosi się pluskwa - "registration", i znamy trigger - "invalid email" (oczywiście, trzeba uściślić, co tu oznacza słowo "invalid"). Ale o co chodzi w tym defekcie?

Bardziej właściwy opis wyglądałby tak:

"Registration is possible with invalid email address" 

Albo

"Email is not validated upon registration." 

W drugiej części naszego artykułu zwrócimy uwagę na kilka wskazówek, które pomogą w pisaniu dobrych summary defektów.

Victoria Slinyavchuk
Consultant on Software Testing