Na skróty
- W jakim celu piszemy przypadki testowe?
- Z jakich elementów składa się przypadek testowy?
- Czy zawsze powinniśmy pisać przypadki testowe?
- Jakich narzędzi możemy używać do pisania przypadków testowych?
- Jakie możliwości dają nam przypadki niskopoziomowe vs wysokopoziomowe.
- Na końcu wpisu znajdziesz kilka przykładów przypadków nisko i wysoko poziomowych.
Wyobraź sobie, że dzwonisz na infolinię banku. Twoje połączenie jest automatycznie odebrane przez maszynę, głos w słuchawce mówi „Wybierz 0, by połączyć się z konsultantem. Wciśnij 1, by zmienić termin spotkania…”.
Czy wiesz, że ten automat właśnie recytuje przypadki testowe? Pierwszy dotyczyłby weryfikacji czy po wybraniu 1 jestem połączony z właściwym działem. Drugi tego, czy po wciśnięciu 0 zostałem przekierowany do konsultanta. Najprostszymi słowami można powiedzieć, że przypadek testowy jest to lista czynności do wykonania w celu sprawdzenia prawidłowości działania funkcjonalności.
W jakim celu piszemy przypadki testowe?
Przypadki testowe piszemy, aby udokumentować w przejrzysty sposób różne możliwości obsłużenia modułów w ramach danej aplikacji. Dobre pokrycie przypadkami testowymi oprogramowania daje nam pewność podczas testów, że nie pominęliśmy żadnej ważnej funkcjonalności. Po zakończeniu testów, na podstawie przypadków testowych możemy budować nasze raporty z wykonanych testów. Dla nowo przyjętych do zespołu ludzi przypadki testowe mogą stać się bardzo dobrym źródłem informacji o niej. Przypadki testowe można również wykorzystać w kontekście testów akceptacyjnych w celu potwierdzenia działania aplikacji zgodnie z oczekiwaniami. Jak widać na powyższych przykładach, przypadki testowe (Test case) są bardzo istotne! Z tego powodu często w trakcie rozmów rekrutacyjnych na testera manualnego pada pytanie właśnie o nie.
Z jakich elementów składa się przypadek testowy?
Każdy przypadek testowy będzie mógł inaczej wyglądać oraz może być inaczej generowany w zależności od narzędzia, za pomocą którego piszemy taki test case. O narzędziach przeczytasz poniżej, tymczasem elementy (pola) przypadku testowego omawiam na przykładzie TestLink.
| ID | Unikalny numer nadawany automatycznie przy tworzeniu przypadku testowego. |
| Twórca | Wartość nadawana automatycznie w momencie utworzenia przez użytkownika przypadku testowego. |
| Tytuł | Krótko zwięźle i na temat co ma być przetestowane. |
| Cel | Cel wykonania testu. |
| Warunek początkowy | Najprościej mówiąc, są to dane potrzebne do wykonania testu. Mogą być to zarówno informacje na temat konta użytkownika, jego uprawnień, jak i miejsca w aplikacji, gdzie znajduje się zalogowany użytkownik. |
| Kroki | Opis co wykonujemy krok po kroku, aby dotrzeć do celu przypadku testowego. |
| Rezultat | Rezultat wykonania kroku/kroków testowych. |
| Priorytet | Istnieje możliwość nadawania priorytetów przypadkom testowym, pozwala to w wypadku braku czasu zdefiniować, które testy zostaną wykonane w pierwszej kolejności. |
| Wykonanie Manualne/Automatyczne | Wartość w polu oznacza, czy dany przypadek ma być wykonywany ręcznie, czy jest pokryty kodem. |
| Czas na wykonanie | Czas, jaki zgodnie z naszą wiedzą powinien zostać poświęcony na weryfikację przypadku testowego. |
Czy zawsze powinniśmy pisać przypadki testowe?
Z jednej strony przypadki testowe dają nam jasny obraz sytuacji w aplikacji plus pozwalają łatwo przechowywać dane odnośnie do wykonanych testów.
Z drugiej strony, jeżeli projekt, w którym pracujemy jest bardzo mały, wtedy raczej nie powinniśmy pisać przypadków testowych. Wynika to z prostej zasady, mały projekt to mały budżet i zwykle krótki czas. Samo napisanie przypadków wymaga sporego nakładu czasu, co za tym idzie, by on się zwrócił, konieczne jest kilkukrotne wykonanie testów.
Narzędzia, których możemy użyć do pisania przypadków testowych.
Program na licencji GNU, całkowicie darmowy. Zapewni nam podstawowe możliwości tworzenia, jak i zarządzania przypadkami testowymi. TestLink możemy zsynchronizować z Jira, ale niestety w ograniczony sposób. Program ten jest popularny i często używany przez testerów.
Więcej na temat TestLink znajdziesz w serii wpisów na temat TestLink na tym blogu.
Jedno z narzędzi komercyjnych. Jest to nakładka do Jira umożliwiająca tworzenie przypadków testowych, zarządzanie nimi.
HP QC
Narzędzie dedykowane tworzeniu i zarządzaniu przypadkami testowymi, komercyjne, lecz minusem może być brak synchronizacji z bugtrackerem np. Jira.
Excel
Niektóre firmy do tworzenia i zarządzania przypadkami testowymi wykorzystują arkusze w Excelu. Nie jest to najprzyjemniejsze narzędzie, ale jednak jest wykorzystywane.
Niskopoziomowe vs wysokopoziomowe przypadki testowe
Przypadki niskopoziomowe mają od razu na starcie sprecyzowane dane wejściowe, jak i rezultat wykonania testu. Natomiast przypadki testowe wysokopoziomowe mają dane wejściowe, i wyjściowe nie sprecyzowane. Jakie daje nam to możliwości?
W przypadku pisania przypadków testowych niskopoziomowych musimy dużo więcej czasu poświęcić na to, żeby dobrze pokryć daną funkcjonalność testami. Tego typu przypadków piszemy z reguły więcej by przetestować jedna funkcjonalność. W przypadku pisania przypadków wysokopoziomowych napiszemy tych przypadków mniej jednocześnie pokrywając większą ilość wymagań niż w wypadku przypadków niskopoziomowych. Dodatkowo przypadki wysokopoziomowe mogą być jednym z działań, jakie pozwolą nam na niedopuszczenie do Paradoksu pestycydów.
Przy ogólnych danych wejściowych oraz ogólnych danych wyjściowych istnieje mała szansa, że testerzy będą powielali swoje testy.
Przypadki testowe – przykłady
Mechanizm logowania w aplikacji Allegro – przykłady niskopoziomowego i wysokopoziomowego przypadku testowego.
PRZYPADEK NISKOPOZIOMOWY 1
Tytuł: Logowanie do aplikacji za pomocą konta użytkownika.
Cel: Weryfikacja możliwości zalogowania do aplikacji za pomocą poprawnych danych.
Warunki początkowe:
– W aplikacji istnieje aktywne konto użytkownika.
– Użytkownik znajduje się na ekranie logowania do aplikacji.
| Krok | Rezultat |
|---|---|
| 1. Wprowadź poprawne dane w pole Login i Hasło | 1. Pola zostały uzupełnione. |
| 2. Naciśnij przycisk Zaloguj | 2. Użytkownik został zalogowany do aplikacji. |
| Priorytet: Wysoki | |
| Wykonanie: Manualne | |
| Estymowany czas: Minuta |
PRZYPADEK NISKOPOZIOMOWY 2
Tytuł: Logowanie do aplikacji za pomocą konta Facebook.
Cel: Weryfikacja możliwości zalogowania do aplikacji za pomocą konta połączonego z kontem na portalu Facebook.
Warunki początkowe:
– W aplikacji istnieje aktywne konto użytkownika połączone z kontem na portalu Facebook.
– Użytkownik znajduje się na ekranie logowania do aplikacji.
| KROK | REZULTAT |
|---|---|
| 1. Naciśnij przycisk Zaloguj przez Facebook. | 1. Użytkownik został zalogowany do aplikacji. |
| Priorytet: Wysoki | |
| Wykonanie: Manualne | |
| Estymowany czas: Minuta |
PRZYPADEK NISKOPOZIOMOWY 3
Tytuł: Logowanie za pomocą konta Facebook bez konta w aplikacji.
Cel: Weryfikacja przeniesienia użytkownika na ekran uproszczonej rejestracji przy próbie logowania za pomocą konta Facebook niezsynchronizowanego z kontem w aplikacji.
Warunki początkowe:
– Użytkownik posiada konta w aplikacji Facebook niezsynchronizowane z aplikacją Allegro.
– Użytkownik znajduje się na ekranie logowania do aplikacji.
| KROK | REZULTAT |
|---|---|
| 1. Naciśnij przycisk Zaloguj przez Facebook. | 1. Użytkownik został przeniesiony na ekran uproszczonej rejestracji. |
| 2. Uzupełnij pola Daty urodzenia poprawnymi danymi. | 2. Pola daty zostały pozytywnie uzupełnione. |
| 3. Zaznacz wymaganą zgodę, a następnie naciśnij przycisk Zarejestruj. | 3. Checkbox ze zgodą na warunki regulaminu został zaznaczony. Użytkownik został zarejestrowany i przeniesiony do aplikacji. |
| 4. Wyloguj się z aplikacji. | 4. Użytkownik został Wylogowany. |
| 5. Naciśnij przycisk „Zaloguj się”. | 5. Użytkownik został przeniesiony na ekran logowania. |
| 6. Naciśnij przycisk Zaloguj przez Facebook. | 6. Użytkownik został zalogowany do aplikacji. |
| Priorytet: Wysoki | |
| Wykonanie: Manualne | |
| Estymowany czas: Minuta |
PRZYPADEK WYSOKOPOZIOMOWY 1
Tytuł: Logowanie do aplikacji.
Cel: Weryfikacja możliwości zalogowania się do aplikacji.
Warunki początkowe:
– W aplikacji istnieje aktywne konto użytkownika połączone z kontem na portalu Facebook.
– W aplikacji istnieje aktywne konto użytkownika połączone z kontem gmail.
– Użytkownik znajduje się na ekranie logowania do aplikacji.
| KROK | REZULTAT |
|---|---|
| 1. Zweryfikuj możliwość logowania się do aplikacji za pomocą poprawnych danych. | 1. Weryfikacja pozytywna. |
| Priorytet: Wysoki | |
| Wykonanie: Manualne | |
| Estymowany czas: 5 Minut |
PRZYPADEK WYSOKOPOZIOMOWY 2
Tytuł: Logowanie do aplikacji.
Cel: Weryfikacja braku możliwości zalogowania się do aplikacji przy niepoprawnych danych.
Warunki początkowe:
– W aplikacji istnieje nieaktywne konto użytkownika.
– W aplikacji istnieje zablokowane konto użytkownika.
– Użytkownik znajduje się na ekranie logowania do aplikacji.
| KROK | REZULTAT |
|---|---|
| 1. Zweryfikuj brak możliwości zalogowania się do aplikacji przy użyciu niepoprawnych danych. | 1. Użytkownik nie został zalogowany pojawił się komunikat o błędzie. |
| Priorytet: Wysoki | |
| Wykonanie: Manualne | |
| Estymowany czas: 5 Minut |
jestem mało zorientowana w temacie, więc chciałabym zapytać o coś co może się wydawać oczywiste osobom bardziej doświadczonym.
Jeśli mamy szczegółową specyfikację, to czy pisanie przypadków testowych w takim wypadku, nie jest parafrazowaniem specyfikacji ?
Z jednej strony tak a z drugiej nie, ponieważ przypadki testowe traktujemy jako coś odrębnego. Dzielącego nam specyfikacje na mniejsze części i jednocześnie pozwalające nam potwierdzić jak ona działa. Jednym słowem często nie bierzemy specyfikacji 1 do 1 tylko przerabiamy ją a niejednokrotnie rozbudowujemy jeszcze bardziej.
Bardzo dobry i konkretny artykuł z dobrymi przykładami. Dzięki! 🙂
dzieki bardzo za info i przyklady ! 🙂