Typowe błędy początkujących testerów - część 1
Typowe błędy początkujących testerów - część 1
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ć.
6 mar 2018
2494
Other articles
Testowanie aplikacji za pomocą JUnit5 i JMock. Część 2
Jak przygotować się do certyfikacji IIBA. Wyzwania i hacki
Testowanie aplikacji za pomocą JUnit5 i Mockito. Część 2
Testowanie aplikacji za pomocą JUnit5 i Mockito. Część 1
Testowanie aplikacji za pomocą JUnit5 i EasyMock. Część 2
Testowanie aplikacji za pomocą JUnit5 i EasyMock. Część 1
Test Driven Development z użyciem JUnit 5. Część 6
Test Driven Development z użyciem JUnit 5. Część 5
Test Driven Development z użyciem JUnit 5. Część 4
Test Driven Development z uzyciem JUnit 5. Czesc 3
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ń:
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
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"

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