Jak pisać przypadki testowe

Nie ma wątpliwości, że pisanie skutecznych Przypadków Testowych jest umiejętnością obowiązkową dla specjalistów QA. Jak każda umiejętność, można ją nabyć i doskonalić. Główne zasady i wskazówki dotyczące skutecznego pisania Przypadków Testowych zostaną omówione w tym artykule.

Zanim zaczniemy, pozwól nam w pełni zrozumieć, czym jest Przypadek Testowy. Wyobraźmy sobie, że musimy przetestować pewną funkcjonalność aplikacji. Powinieneś krok po kroku zainicjować sytuację, w której mogłaby ona zostać zaimplementowana.

Praktycznie rzecz ujmując, Przypadek Testowy to zestaw dobrze zaprojektowanych i łatwych do zrozumienia kroków (akcji) wykonywanych w celu zweryfikowania konkretnej cechy lub funkcjonalności Twojej aplikacji. Miej na uwadze „dobrze zaprojektowany” i „łatwy do zrozumienia”. Ma to ważne znaczenie, jak zobaczysz trochę później.

Więc, teraz możemy zacząć. Tutaj podzielimy Przypadek Testowy na części składowe i postaramy się przeanalizować, co powinno być zrobione, a co nie, aby napisać go z wysoką wydajnością.

Test Case ID

Jest to unikalny numer Przypadku Testowego w systemie zarządzania testami lub w dokumencie. Z reguły wszystkie nowoczesne systemy zarządzania testami, takie jak Jira, TestRail, czy Zephyr automatycznie przypisują ID do nowo utworzonego Przypadku Testowego. Nie ma więc możliwości popełnienia błędu w tym elemencie.

Należy jednak pamiętać, że w niektórych projektach do testowania nadal używa się Excela. Dlatego też zawsze należy pamiętać o zasadzie: „W systemie zarządzania testami nie ma przypadków testowych o tym samym ID. Nawet jeśli są to przypadki testowe z zakończonych projektów”.

Tytuł Przypadku Testowego

Strong Title jest obowiązkowym atrybutem efektywnego Przypadku Testowego. Co to znaczy? Kluczowymi cechami mocnego Tytułu są: łatwość zrozumienia i lakoniczność. Poza tym, Tytuł Przypadku Testowego musi reprezentować nazwę modułu lub obszaru funkcjonalnego, który zamierzamy zweryfikować.

Wyobraźmy sobie, że mamy za zadanie sprawdzić, co się stanie, jeśli w polu „e-mail” formularza rejestracyjnego Systemu Zarządzania Testami EasyQA wpiszemy nieprawidłowe symbole, takie jak $,&, *. Zgodnie z powyższymi zasadami, Tytuł Przypadku Testowego powinien wyglądać następująco: „E-mail field invalid input in the Registration form”.

Rozważmy przykład niezbyt mocnego tytułu. „E-mail field „$&*” symbols input in the Registration form of the „EasyQA”. Tutaj mamy co najmniej dwa błędy.

• Zbyt długi tytuł. Nie ma potrzeby wymieniać „EasyQA”, ponieważ ten przypadek testowy jest częścią Planu Testów dla tego Systemu Zarządzania Testami. Zatem wszystkie przypadki testowe dotyczą „EasyQA”.
• Skonkretyzowanie symboli specjalnych „$&*”. Inne nieprawidłowe symbole również mogą zostać wprowadzone w celu wykonania tego rodzaju przypadku testowego. Tak więc, „nieprawidłowe symbole” są bardziej odpowiednią definicją dla tego tytułu.

Niektóre systemy zarządzania testami, w tym EasyQA, upraszczają ten proces tworząc specjalne pole modułowe dla każdego Przypadku Testowego.

Plan Testowy podzielony jest na moduły, które zawierają poszczególne Przypadki Testowe. Dlatego też łatwiej jest stworzyć mocny tytuł dla przypadku testowego.

Opis przypadku testowego

Przed rozpoczęciem testów należy podać wszystkie szczegóły dotyczące tego, co będziemy testować. Są to: Dane Testowe, które będą użyte, Warunki Wstępne (Presteps), Szczegóły Środowiska Testowego, Narzędzia Testowe.

Jeśli podasz Dane Testowe, które będą użyte wszędzie tam, gdzie ma to zastosowanie dla Przypadku Testowego w ramach opisu Przypadku Testowego lub przy konkretnym kroku Przypadku Testowego, pomożesz nie tylko sobie, ale także swoim kolegom-testerom. Poważnym błędem jest pisanie Przypadków Testowych tylko dla siebie.

Warunki wstępne (Presteps) opisują różne rodzaje zależności związanych z wykonaniem testu:

• Wymagana jest jakaś specjalna konfiguracja
• Zależność od innych Przypadków Testowych – czy dany Przypadek Testowy musi być uruchomiony przed/po innym Przypadku Testowym
• Zależność od danych użytkownika – od której strony użytkownik powinien rozpocząć podróż; użytkownik powinien być zalogowany.

Środowisko testowe jest zestawem oprogramowania i sprzętu dla zespołów testowych do wykonywania przypadków testowych. Innymi słowy, wspiera ono wykonywanie testów za pomocą sprzętu, oprogramowania i skonfigurowanej sieci.

Gdy ludzie wspominają o narzędziach testowych, często sugerowane jest testowanie automatyczne. Oczywiście są one wcześniej związane z tym typem testowania. Ale są też proste narzędzia do testowania manualnego. Narzędzia do tworzenia map myśli, takie jak Xmind, menedżery zrzutów ekranu, takie jak Jing są łatwe w użyciu nawet dla początkujących w obszarze QA. W każdym razie, jeżeli jakieś specjalne narzędzie jest wymagane do testowania, powinieneś wspomnieć o nim w Opisie Przypadku Testowego.

Oczywiście, jeżeli to samo narzędzie jest używane do wykonania jakiejś grupy Przypadków Testowych, lepiej byłoby opisać je w Module/Podmodule Testowym lub nawet w Planie Testów.

Jest pewien rodzaj typowego błędu, na którym powinieneś się skupić. Niektórzy testerzy z mniejszym doświadczeniem mylą Steps z Presteps. Zwróć uwagę, że Prestepy to sposób na uzyskanie sytuacji, w której można rozpocząć wykonywanie Przypadku Testowego. Kroki są najbardziej efektywną drogą do uzyskania rzeczywistego wyniku wykonania Przypadku Testowego.

Na przykład, jeżeli mamy do przetestowania zdolności funkcjonalne zarejestrowanego użytkownika, błędem byłoby tworzenie specjalnych kroków rejestracji użytkownika dla każdego Przypadku Testowego w odpowiednim module. Właściwą decyzją jest wyświetlenie w Prestepach dla wszystkich modułów Test Suitów rejestracji użytkownika informacji: użytkownik powinien być zarejestrowany. Proces rejestracji jest weryfikowany w danym Pakiecie Testowym.

Jak już wcześniej wspomniano, Kroki są drogą do Oczekiwanego Wyniku. Kolejną rzeczą, którą należy przypomnieć jest to, że Kroki w skutecznym Przypadku Testowym są dobrze zaprojektowane i łatwe do zrozumienia. Te dwa punkty są podstawą do zrozumienia, jak planować Kroki dla swoich Przypadków Testowych.

Główne atrybuty dobrze zaprojektowanych Kroków:

1. Optymalna ilość Kroków. Nie ma potrzeby pisania dodatkowych kroków, jak również kroku „do jedzenia”. To, co dla Ciebie wygląda na oczywiste, nie może być tak jasne dla Twoich kolegów.
2. Jeden przypadek testowy obejmuje tylko jedną niezależną funkcjonalność. Błędem jest weryfikowanie różnych funkcjonalności w jednym Przypadku Testowym.
3. Kroki są łatwe do wykonania.
4. Kroki powinny obejmować nie tylko przepływ funkcjonalny, ale także każdy punkt weryfikacji, który musi być przetestowany.

Główne atrybuty łatwych do zrozumienia Kroków:

1. Kroki są do rzeczy. Nie powinieneś pisać eseju, aby opisać swoje Kroki.
2. Jasne wyrażenie. Powinieneś unikać dwuznaczności w swoich Krokach Przypadku Testowego.
3. Zrozumiałe nawet dla początkujących. Twoi koledzy, którzy prawdopodobnie nie są tak doświadczeni powinni być w stanie zrozumieć jak wykonać każdy Krok.

Wydajność aplikacji po wykonaniu powyższych kroków testowych jest wyświetlana w Oczekiwanym wyniku. Tak więc, przed napisaniem Przypadków Testowych, powinieneś w pełni rozpoznać, jakiej strony/ekranu oczekujesz po wykonaniu testu oraz jakich aktualizacji oczekujesz w systemach back-endowych lub bazie danych.

Mam nadzieję, że pamiętasz, że jeden Przypadek Testowy obejmuje jedną niezależną funkcjonalność. Dlatego błędem byłoby pisanie przypadków testowych z więcej niż jednym oczekiwanym wynikiem.

Komentarze/Warunki Post nie są obowiązkowymi składnikami przypadków testowych, ale naprawdę zwiększają efektywność twojego przypadku testowego. W tym miejscu możesz umieścić dodatkowe pomocne informacje, takie jak zrzuty ekranu i opisy, aby dostarczyć programistom informacji, których będą potrzebowali do poprawienia znalezionych błędów.

Post Conditions są również używane do podawania instrukcji przywracających system do pierwotnego stanu, aby nie przeszkadzał w późniejszym testowaniu. Na przykład, jest to całkiem przydatne, jeśli wspomina się o zmianach, które należy wprowadzić w Danych Testowych, aby można je było wykorzystać w późniejszym Przypadku Testowym dla tej samej funkcjonalności.

Różne systemy zarządzania testami oferują różne warianty pola Przypadku Testowego. Przypadek testowy w narzędziu EasyQA Test Management posiada następujące elementy:

1. Tytuł
2. Moduł – służy do wyboru modułu, którego dotyczy nasz Przypadek Testowy. – Jeśli naciśniemy przycisk Dodaj przypadek w module, pole to zostanie wpisane domyślnie.
3. Typ – należy wybrać typ przypadku testowego z listy rozwijanej zgodnie z poniższym opisem:

• Pozytywny – to przypadek testowy wykorzystujący tylko poprawne dane.
• Negative to przypadek testowy wykorzystujący nie tylko poprawne dane.
• Boundary to przypadek testowy wykorzystujący wartości max/min.
• Integration to komponent testów integracyjnych.
• UI to testowanie interfejsu graficznego użytkownika.
• Lokalizacja to testowanie lokalizacji, języków itp.

1. Pre Steps
2. Steps
3. Expected Result

Na tym obrazku możesz zobaczyć proces dodawania przypadku testowego z wypełnionymi polami.

Po dodaniu przypadków testowych możesz je wybrać za pomocą odpowiednich pól wyboru. Po wybraniu jednego lub kilku przypadków testowych możesz je przenieść tam, gdzie chcesz. Możesz je edytować lub usuwać.

Teraz, gdy masz już trochę wiedzy teoretycznej na temat pisania Przypadków Testowych, spróbuj ją wykorzystać przy podejmowaniu decyzji o następnym zadaniu.

Dane do zadania:

1. Istnieje System Zarządzania Testami „EasyQA” – https://geteasyqa.com/
2. Musisz zweryfikować zdolność zarejestrowanego użytkownika do stworzenia nowego Planu Testów dla projektu o nazwie „Blogger” zgodnie ze specyfikacją.
3. E-mail użytkownika to „[email protected]”, hasło to „gEORGe52”

Zastanówmy się, jak stworzyć każdy krok.

Oczywiście, unikalny identyfikator zostanie automatycznie przypisany przez system zarządzania testami, którego używasz.

Po pierwsze, powinieneś wybrać odpowiedni tytuł, moduł i scenariusz testowy dla przypadku testowego. Naturalnie, modułem może być „Zarejestrowany użytkownik”. I inne Przypadki Testowe testujące funkcjonalność zarejestrowanego użytkownika będą umieszczane w tym module. Mocny Tytuł wygląda jak „Możliwość tworzenia planu testowego”. Scenariusz testowy jest pozytywny.

Jak również musisz sprawdzić funkcjonalność zarejestrowanego użytkownika, musisz wyświetlić drogę do rejestracji w Krokach Wstępnych. Te kroki wstępne będą takie same dla wszystkich przypadków testowych w module „Zarejestrowany użytkownik”.

W polu Steps musisz pokazać, jak osiągnąć Oczekiwany rezultat.

Zdefiniujmy Oczekiwany Wynik jako „Zarejestrowany użytkownik ma możliwość tworzenia Planu Testów”.

Wyniki naszych działań możemy zobaczyć za pomocą narzędzi EasyQA Test Management.

Rozważmy kilka typowo Testowych Przypadków opartych na różnych scenariuszach.

Dane do zadania są prawie takie same jak w poprzednim zadaniu:

1. Istnieje System Zarządzania Testami „EasyQA” – https://geteasyqa.com/
2. Potrzebny jest formularz „Sign Up” do przetestowania.
3. Minimalna długość hasła to 6 symboli. Maksymalna długość hasła to 128 symboli
4. W polach „Login”, „Password”, „Confirm Password” można używać tylko liter alfabetu łacińskiego od A do Z oraz cyfr.

Tutaj rozważymy kilka przykładów tego rodzaju procesu tworzenia przypadków testowych.

Formularz „Sign Up” EasyQA posiada następujące pola obowiązkowe: „First name”, „Last name”, „Email”, „Password”, and „Confirm Password”. Oprócz tego istnieją inne pola, takie jak „Firma” i „Kraj”, które nie są obowiązkowe, ale również muszą być przetestowane. Dlatego powinieneś podzielić swój moduł „Sign Up” Test Suite na odpowiednie podmoduły.

Postaraj się przeanalizować kilka typowych scenariuszy: pozytywny, negatywny i graniczny.

Zgodnie ze scenariuszem pozytywnym, niezarejestrowany użytkownik wprowadza tylko poprawne dane do wszystkich pól. Nie będziesz miał więc problemów z tworzeniem tego typu przypadków testowych. Możesz zobaczyć jak to może wyglądać na poniższym obrazku.

Oczekiwany Wynik dla tego przypadku testowego to „W polu „Hasło” możliwe jest wpisanie liter i cyfr alfabetu łacińskiego”.

Ale co się stanie, jeśli użytkownik wpisze nieprawidłowe symbole w którekolwiek z wcześniej wymienionych pól? Możemy to sprawdzić wykonując Przypadki Testowe oparte na Scenariuszu Negatywnym. W rzeczywistości istnieje wiele wariantów nieprawidłowych danych wejściowych. Można by się nad nimi zastanowić w innym artykule. Oto tylko niektóre z nich:

• „&%$” wprowadzenie symboli
• Wprowadzenie spacji
• Wprowadzenie pustego pola
• Kombinacje nieprawidłowych i nieprawidłowych symboli
• Inne przypadki wprowadzenie liter itp.

Na poniższym obrazku przedstawiony jest przykład negatywnego przypadku testowego.

Oczekiwanym wynikiem dla tego przypadku testowego jest „Niemożliwe jest wprowadzenie nieprawidłowych danych w polu „Hasło””.

Zwróć uwagę na warunek – ograniczenie długości hasła (6-128 symboli). Czy jest możliwe zarejestrowanie się z hasłem składającym się tylko z 3 symboli? A co z hasłem o długości 150 symboli? Przypadki testowe napisane techniką projektowania testów wartości granicznych dadzą Ci odpowiedzi na te pytania.

Podstawową ideą w testach wartości granicznych jest wybieranie wartości zmiennych wejściowych w ich: minimum, tuż powyżej minimum, tuż poniżej maksimum, maksimum. W naszym przykładzie powinieneś napisać Przypadki Testowe dla sytuacji z:

• 5 symboli hasła
• 6 symboli hasła
• 128 symboli hasła
• 129 symboli hasła.

Spójrz na poniższy obrazek, aby zobaczyć jak wygląda Przypadek Testowy napisany zgodnie z tą techniką.

Oczekiwany Wynik dla tego przypadku testowego to „Wyświetlany jest komunikat informacyjny „Minimalna długość hasła wynosi 6 symboli””.

Różne funkcjonalności takie jak wyszukiwanie, ranking, stronicowanie również wymagają przetestowania. Te przypadki testowe również mogą być napisane według scenariuszy, które rozważaliśmy wcześniej. Weryfikują one prawidłowe działanie:

• Pola wyszukiwania
• Przyciski stron
• Strzałki
• Ranking według nazwy (od A do Z, od Z do A)
• Ranking według ceny (najniższa pierwsza, najwyższa pierwsza)
• Przyciski menu pulpitu i paska bocznego itp.

Powróć do Systemu Zarządzania Testami EasyQA i napisz prosty Przypadek Testowy sprawdzający funkcjonalność filtrowania przycisku „Zamknięte sprawy”. Oto on.

Oczekiwanym rezultatem dla tego przypadku testowego jest „Tylko zamknięte sprawy są wyświetlane w menu pulpitu nawigacyjnego”.

Testy bezpieczeństwa są często wykonywane przez specjalne narzędzia do testów automatycznych, takie jak Vega, Google Nogotofail, Wapiti itp. Ale używając twoich umiejętności aktywności umysłowej możesz napisać prosty Przypadek Testowy dla sprawdzenia niektórych parametrów bezpieczeństwa strony internetowej. Wróć ponownie do Systemu Zarządzania Testami EasyQA. Poniżej możesz zobaczyć przykład takiego Przypadku Testowego.

Zwróć uwagę na Kroki. Oczekiwanym rezultatem dla tego przypadku testowego jest „Formularz logowania do EasyQA jest wyświetlany po skopiowaniu/wklejeniu adresu URL z jednej przeglądarki do drugiej”. Zatem nie ma dostępu do konta użytkownika.

Istnieje wiele narzędzi do zarządzania testami, które pomagają testerom w ich pracy. EasyQA daje Ci szeroki wachlarz dodatkowych przydatnych funkcji:

1. Eksportuj przygotowany plan testów w formacie CSV za pomocą jednego przycisku
2. Importuj przygotowany plan testów do naszego systemu.
3. Wyświetlanie przypadków testowych według różnych kryteriów:
4. Raporty o awariach
5. Buduj dystrybucję
6. System śledzenia błędów
7. Wykonuj testy
8. Generuj raporty
9. Szybka i łatwa integracja z istniejącymi narzędziami.

Praktycznie rzecz ujmując, EasyQA to więcej niż system zarządzania testami. To środowisko do przyjemnej i efektywnej pracy.

1. Pamiętaj, że Przypadki Testowe są wykonywane także przez Twoich kolegów
2. Użyj mocnego tytułu
3. Zwróć uwagę na Kroki Wstępne i Warunki Wstępne
4. Przypadek Testowy obejmuje jedną funkcjonalność i
5. Przypadek Testowy ma tylko jeden Oczekiwany Wynik
6. Pisz dobrze zaprojektowane i łatwe do zrozumienia kroki
7. Pisz dobrzedobrze zaprojektowane i łatwe do zrozumienia kroki
8. Nie zapomnij umieścić wszystkich użytecznych informacji w Komentarzach lub Warunkach Post
9. Użyj ilustracji i prostych narzędzi testowych, jeśli jest to konieczne
10. Przypadek testowy musi być wielokrotnego użytku
11. Zacznij ćwiczyć

Chcesz pisać efektywne Przypadki Testowe? Po prostu zacznij to robić. A my z przyjemnością Ci w tym pomożemy.

TRY EASY QA