Uncategorized

Jak dobrze pisać przypadki testowe?

Jednym z podstawowych zadań testera manualnego jest pisanie przypadków testowych. Panuje ogólne przekonanie, że jest to zadanie bardzo proste i żmudne, ale większość z nas przynajmniej raz złapała się za głowę czytając przypadki testowe swoich poprzedników. Warto zauważyć, że dobry przypadek testowy powinien przede wszystkim odpowiadać na pytanie: „Co tak naprawdę zamierzam przetestować”?

Definicja

Zanim zacznę analizować budowę przypadku testowego chciałabym przytoczyć definicję: „zbiór danych wejściowych, wstępnych warunków wykonania, oczekiwanych rezultatów i końcowych warunków wykonania opracowany w celu zweryfikowania zgodności działania programu z oczekiwanym rezultatem lub sprawdzenia warunku testowego”.[1] [2]

Prawidłowa budowa przypadku testowego

Wielu testerów bardzo nie lubi pisania przypadków testowych, co możemy odczuć analizując je. Niechęć bardzo często wynika z braku usystematyzowania wzorca oraz „automatyzacji” pewnych czynności, przez co pisanie zajmuje bardzo dużo czasu i jest żmudne.

Wzorzec przypadku testowego możemy podzielić na dwie części: niezbędną i opcjonalną. Do części niezbędnej zaliczamy:

  • Unikalny identyfikator – jest to bardzo dobra praktyka. Pomaga w zarządzaniu i przeszukiwaniu bazy przypadków użycia.
  • Nazwa – jest bardzo przydatna, gdyż dobrze sformułowana pozwoli nam szybko określić zawartość przypadku. Bardzo ważne jest aby nazwa była krótka, zwięzła, w postaci jednego zdania, które opisuje sedno przypadku. Moim zdaniem jest to najtrudniejsza część pisania przypadku, ale warto poświęcić jej chwilę czasu, gdyż potem ten czas zaoszczędzimy zarządzając bazą przypadków.
  • Opis – krótki parozdaniowy opis pozwoli nam na dokładne stwierdzenie czym dany przypadek testowy się zajmuje, co on tak naprawdę testuje. Pomoże to w ostatecznej identyfikacji przypadku testowego. Częstym błędem tutaj jest zbyt długi i kolorowy opis. Starajmy się wczuć w sytuację osoby czytającej, najczęściej jest to zmęczony tester, który ma jeszcze do przeglądnięcia masę innych przypadków. Więc nie narażajmy się na gniew, piszmy krótko, zwięźle i na temat.
  • Warunki wstępne – nazywane są również kryteriami wejścia. Jest to „zbiór ogólnych i szczególnych warunków, których spełnienie jest wymagane do kontynuacji procesu dla określonego zadania”,[3]
  • Opis kroków do wykonania – bardzo ważna część przypadku testowego. Najczęstsze błędy tutaj to skróty myślowe, tekst pisany wg myśli „wiem o co tu chodzi, będę pamiętał”, miejsce największej irytacji testerów, którzy dziedziczą przypadki testowe po kimś innym.
  • Oczekiwany rezultat – ważne jest opisanie oczekiwanego rezultaty, gdyż dzięki niemu będziemy wiedzieć czy wyklikany przez nas przypadek testowy zakończył się sukcesem czy porażką.
  • Warunek końcowy – warunek dzięki, któremu przedwcześnie nie zakończymy wykonywania przypadku testowego.

Do części opcjonalnej zaliczamy:

  • Dane testowe – dobrze jest zamieszczać dane testowe, gdyż ułatwiają one pracę w regresji, a także podpowiadają jaki format dane testowe powinny mieć.
  • Środowisko testowe – czasem w projektach mamy wiele środowisk testowych, sprecyzowanie, na którym środowisku powinny być testy przeprowadzone bardzo ułatwia pracę. Uniemożliwia też sytuację, że np. próbujemy testować funkcjonalność na środowisku, na którym nie została ona jeszcze zaimplementowana.
  • Kategoria – typ.
  • Priorytet.
  • Autor – fajnie wiedzieć komu możemy zadać pytanie, gdy potrzebujemy informacji , albo na kogo się denerwować.
  • Numer wersji.

Dobre rady

  1. Pamiętaj, że inne osoby będą czytały przypadki testowe Twojego autorstwa. Staraj się więc pisać jasno, zachowując ciąg myślowy. Unikaj przeskakiwania pewnych etapów, jeśli są one jasne tylko o nich wspomnij. Osoba, która pierwszy raz widzi przypadek testowy, powinna móc go wykonać.
  2. Pisz szczegółowo, bez skrótów myślowych, za 2 miesiące sam już nie będziesz pamiętał co miałeś na myśli.
  3. Trzymaj się jednej konwencji, jeśli piszesz pełnymi zdaniami lub równoważnikami zdań trzymaj tą konwencję we wszystkich przypadkach testowych.
  4. Uważaj na ortografię i interpunkcję.
  5. Planuj przypadki testowe zarówno pozytywne, jak i negatywne (najczęstszy błąd to zapominanie o przypadkach negatywnych).
  6. Zanim zaczniesz pisać przypadki testowe, zaplanuj je. Dzięki temu nie pominiesz żadnego ważnego przypadku. Przydatna tu jest np. mapa myśli.

Praca domowa!

W artykule „Jak rozpocząć przygodę z IT?” wspominałam, że każda porcja teorii powinna być poparta praktyką, dlatego nie obejdzie się bez pracy domowej! Wybierz swoją ulubioną stronę internetową, wybierz co chcesz przetestować i stwórz z tego przypadek testowy. I to nie jeden 😀

Miłej zabawy! Dajcie znać jak Wam poszła praca domowa! 😀

 

[1] Roman A., „Testowanie i jakość oprogramowania”, IEEE 610 IEEE Standard Glossary of Software Engineering Terminology, The Institute of Electricial and Electronics Engineers, New York, 1990.

[2] Po więcej szczegółów na temat teorii dot. przypadków testowych zapraszam do lektury artykułu „Co to są przypadki testowe?” (dostępny od wtorku 9.01)

[3] Roman A., „Testowanie i jakość oprogramowania”.

2 komentarze

  • Hania

    Świetna sprawa z tym, że jest mniej więcej pokazany przykład. Jest możliwość sprawdzenia ‚prayc domowej’? 🙂

    • Wisienka

      Tak, prace domowe są sprawdzane uczestnikom Cherry-IT: Zostań testerem 😀 Zapraszam na spotkania, na spotkaniu nr 2 akurat maglujemy przypadki testowe 🙂

Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *