Testing

Produkty procesu testowego – od podstawy do scenariusza testowego

Sierpień 13, 2020 0
Podziel się:

Co w przypadku, kiedy projekt dopiero się zaczyna i nie istnieje żadna podstawa testów? Jaka jest metoda działania w takiej sytuacji? W tym wpisie przybliżę procesy jakie zachodzą, w celu otrzymania gotowej dokumentacji testowej projektu. Innymi słowy – poznasz najważniejsze produkty testowania, tworzone podczas procesu testowego.

Na początku był… kontekst

Punktem wyjściowym każdego projektu, do którego implementujesz testowanie jest jego kontekst. Do wytwarzanego projektu należy opracować dobry proces testowy, który później zostanie uzupełniony odpowiednimi czynnościami i zadaniami testowymi oraz produktami prac testerskich. Kontekst zależny będzie przede wszystkim od dziedziny biznesowej, którą się zajmujesz oraz wszelkimi ograniczeniami związanymi z powodzeniem projektu, tj.:

  • budżet i zasoby,
  • harmonogramy,
  • złożoność,
  • wymagania związane z umowami i przepisami,
  • polityka i strategia obowiązująca w Twojej organizacji,
  • normy i standardy.

Wszelkie produkty prac testowych jakie opiszę poniżej, są ujęte przez sylabus ISTQB w procesie testowym. Dzielą się one na konkretne etapy:

  • planowanie testów,
  • monitorowanie testów i nadzór nad testami,
  • analiza testów,
  • projektowanie testów,
  • implementacja testów,
  • wykonywanie testów,
  • ukończenie testów.

Zgodnie z wybranym kontekstem projektu, niektóre z tych procesów mogą następować po sobie, nakładać się na siebie lub jak w przypadku monitorowania testów i nadzoru nad testami, występować przez cały czas jego trwania. Sam proces testowy jest jednak na tyle rozbudowany, że z pewnością zająłby dodatkowy wpis. Pozostańmy więc w obrębie produktów testowych. Zalążkiem dokumentacji testowej staje się więc podstawa testów.

Podstawa testów

Początkiem każdego procesu będzie ustalenie celów testowania. W tym miejscu znajdziemy wymagania i dokumentację dla projektu, który rozwijamy. Opierając się na wyżej wspomnianym kontekście, utworzona zostanie podstawa testów i kryteria osiągnięcia celu testowania. Takie wysokopoziomowe cele zostaną ujęte w harmonogramie, według którego będziesz pilnować wyznaczonych terminów. Pomocne w wytworzeniu mierzalnych efektów pracy, będzie narzędzie do zarządzania testowaniem takie jak Jira. Mierzalne efekty pracy to np. zebrane wymagania biznesowe aplikacjiwymagania funkcjonalneschematy przejśćprojekty środowisk oraz wszystkie  produkty, które sprawdzą zachowanie funkcjonalne i niefunkcjonalne testowanego systemu.

Najczęściej spotykaną przeze mnie formą dobrze opisanych produktów testowych są utworzone historyjki użytkownika, których grupy tworzą tzw. opowieści. Takie historyjki i opowieści objęte są śledzeniem, spełniając przy tym jedną z głównych ról dobrego procesu testowego – nieustannego monitorowania i sprawdzania poziomu ukończenia testów. Spisane wymagania biznesowe są następnie przeobrażane w przypadki testowe, produkt prac testowych który pozwala na bardziej techniczny zapis jak ma zostać oprogramowane wybrane wymaganie biznesowe. Do podstaw testów można również zaliczyć (opierając się na kontekście) wszystkie wspierane przez projektowany system urządzenia, jak np. modele konkretnych samolotów/elementów ich wyposażenia, modele telefonów, laptopów itp.

Unika się w tym miejscu wszelkich ryzyk, poprzez wnikliwe sprawdzenie pod kątem możliwych pominięć i niejasności.  Mogą one w późniejszym czasie mocno wpłynąć na testowalność systemu. Solidną podstawą testów można określić takie produkty, dla których określone zostały mierzalne kryteria pokrycia. Najczęściej spotykanymi wskaźnikami są Kluczowe Wskaźniki Wydajności.

Pierwsze warunki testowe

Warunek testowy jest nadrzędnym artefaktem przypadku testowego. Można nim nazwać każdy element testowy lub zdarzenie opisane w podstawie testów. Warunki testowe szereguje się według priorytetów, a następnie sprawdza się pokrycie elementów podstawy testów. Opierając się na dowolnym przykładzie, który będzie wymagał wnikliwego sprawdzenia możesz założyć, że w Twojej dokumentacji powinien istnieć przynajmniej jeden przypadek testowy dla jednego elementu podstawy testów. Często jednak będzie wymagana nawet większa ilość przypadków testowych dla jednego warunku testowego.

Rozpisane na przypadki testowe

W wyniku zaprojektowania warunków testowych powstają przypadki testowe. Każdy przypadek testowy to zbiór informacji, których zbieranie możesz pamiętać ze zgłoszenia defektu:

  • dane wejściowe/dane testowe,
  • warunki wstępne,
  • kroki do wykonania testu,
  • rezultat oczekiwany,
  • warunki końcowe.

Z przypadków testowych tworzy się zbiory przypadków testowych, które podobnie jak warunki testowe odpowiednio się je prioretyzuje. Dzielimy je na niskopoziomowe oraz wysokopoziomowe.

Przypadek testowy niskiego poziomu (konkretny)

W sytuacji pojawienia się wyżej wspomnianych, konkretnych danych testowych jak np. dane wejściowe, potrzebne do pokrycia warunku testowego i jego wyniki oczekiwane, którymi można zasilić przypadek testowy wysokiego poziomu, taki przypadek nazywany jest przypadkiem niskiego poziomu. Konkretne wartości są w stanie odpowiedzieć na konkretny cel warunku testowego.

Przykłady: a == ’42’; login: testuser; password: userpassword.

Przypadek testowy wysokiego poziomu (logiczny)

Przypadek testowy ma za zadanie sprawdzić wybrany element testowy np. poprzez zweryfikowanie pewnej ścieżki programu względem testowanego wymagania (podstawy testów). Nie każdy z nich zbudowany jest jednak z danych wejściowych i oczekiwanych rezultatów. W początkowej fazie, udokumentowane warunki testowe przekształca się w przypadki testowe wysokiego poziomu. Dane testowe nie są jeszcze zdefiniowane, wobec tego zapamiętaj ten typ przypadku testowego jako abstrakcyjny. Jego główną zaletą jest możliwość wielokrotnego wykorzystania z racji tego, że bardziej przypomina szablon przypadku testowego. Poprzez użycie różnych danych testowych możesz wykorzystać taki przypadek na wiele sposobów.

Przykłady: dowolna liczba z zakresu a: <0,…,100>; login; password.

Wszystkie powyższe produkty wiąże ważna cecha. Spełniają korzyść testowania na etapie projektowania i oceny podstawy testów, jaką jest wczesne znajdowanie defektów, które mogłyby wpłynąć na powodzenie projektu. Spełniają przy tym zasadę wczesnego testowania. Dzieje się tak dlatego, że na tym etapie najczęściej nie istnieje żadna linijka kodu, a więc wszelkie defekty w dokumentacji charakteryzują się relatywnie niskim kosztem naprawy.

Scenariusz testowy

Scenariusz jest niczym innym jak zapisem kilku przypadków testowych wymaganych do wykonania w określonej kolejności. Polega na szeregowaniu istniejących przypadków testowych w taki sposób, że warunki wyjściowe jednego przypadku testowego, będą warunkami wejścia dla kolejnego w celu pokrycia wybranego obiektu testów. Kilka takich scenariuszy zbiera się następnie w zestawy testów i umieszcza na etapie implementacji do dokumentu zwanego harmonogramem wykonywania testów. Na koniec wybrane zestawy testów będą uruchamiane według wspomnianego harmonogramu wykonywania testów.

Czy procedura testowa?

Sylabus ISTQB spotyka się w tym miejscu z faktyczną praktyką testerską, ponieważ scenariusze bardzo często występują w projektach. Potrafią mieć jednak zgoła inne nazewnictwo w dokumentacji testowej. Według sylabusa to co w codziennej pracy luźno nazywa się scenariuszem testowym określane jest procedurą testową. Nie jest to jednak ostateczna nazwa tego dokumentu, ponieważ rozwija się o dodatkowe określenie: specyfikacja procedury testowej.

Słowo specyfikacja ma za zadanie podkreślić, że procedura testowa (ale i wszystkie inne specyfikacje w sylabusie) to nic innego jak faktycznie istniejący przedmiot testowania, który jest udokumentowany i śledzony w narzędziach. Najłatwiej będzie przełożyć nazwę na “udokumentowany scenariusz testowy”.

Scenariusz testowy będzie charakteryzował się następującymi informacjami:

  • nazwa scenariusza,
  • opis,
  • warunki wstępne,
  • wymagania (do których się odnosi),
  • typ testu (pozytywny/negatywny),
  • ID kroku,
  • opis kroku,
  • oczekiwany wynik,
  • rzeczywisty wynik.

Po utworzeniu struktury z powyższych produktów i rozpoczęcia procesu wykonywania testów zgodnie z harmonogramem, oprócz statusów wykonania dla ww. procedur testowych produktami procesu będą również zgłoszenia defektów. Jak widzisz, zgłoszenie defektu, będące tak podstawową czynnością testerską, jest tak naprawdę jednym z ostatnich produktów testowych w procesie. Całość opisywanego procesu prezentuje się następująco:

remigiusz bednarczyk produkty testowe k8xjll6z - Produkty procesu testowego - od podstawy do scenariusza testowego

Wpis ma zadanie pokazać szerszą perspektywę powstawania produktów w procesie testowym. W dalszej jego części chcę Ci pokazać część praktyczną w odniesieniu do projektu tej strony internetowej. Sprawdź, jak rozpisałbym cele z podstawy testów, warunki testowe, przypadki testowe, scenariusze/procedury testowe.

Podstawa testów – przykłady

Zacznijmy od zebrania wymagań od interesariuszy. Po krótkiej rozmowie wynikły następujące wymagania, które rozpisano jako ogólne cele projektu. Możesz jednocześnie zobaczyć jak w praktyce wygląda ogólnikowy zapis historyjek (user stories) wspomnianych podczas omawiania podstawy testów. Zestaw poniższych historyjek nazywa się opowieścią (epic).

Charakteryzują się specyficzną formą zapisu, która wskazuje na konkretną korzyść po jej spełnieniu. Zwróć uwagę na model zdań:

Jako…(użytkownik) -> chcę…(mieć) -> aby…(uzyskać)

  1. Jako użytkownik, chcę mieć dostęp do strony głównej serwisu poprzez wpisanie adresu remigiuszbednarczyk.pl, aby uzyskać możliwość użytkowania serwisu.

Kryteria akceptacji:

  • istnieje domena remigiuszbednarczyk.pl.
  • strona główna istnieje.
  • na stronie głównej znajduje się górne menu z nawigacją do stron:
    • O mnie (Strona główna).
    • Jak zostać testerem.
    • Artykuły.
    • Kontakt.
  1. Jako użytkownik, chcę mieć dostęp do strony Jak zostać testerem, wtedy znajdę niezbędne informacje jak dokonać tego celu w jednym miejscu.

Kryteria akceptacji:

  • Strona Jak zostać testerem istnieje.
  • Na stronie głównej znajduje się menu z nawigacją do strony Jak zostać testerem.
  1. Jako użytkownik, chcę mieć możliwość dodawania komentarzy na stronie Jak zostać testerem. Serwis będzie posiadał opisaną politykę prywatności, aby sprostać krajowym normom w zakresie przetwarzania danych osobowych RODO. Odniesienie do strony Polityka prywatności będzie umieszczone w stopce.

Kryteria akceptacji:

  • strona Jak zostać testerem istnieje.
  • istnieje formularz komentarzy na końcu artykułu.
  • na stronie głównej znajduje się menu z nawigacją do strony Jak zostać testerem.
  • na stronie istnieje stopka.
  • strona Polityka prywatności istnieje. Informuje użytkownika jak gromadzone i wykorzystywane są dane osobowe w serwisie.
  1. Jako użytkownik, chcę mieć dostęp do strony Artykuły, gdzie znajdę pomocne publikacje na temat testowania oprogramowania.

Kryteria akceptacji:

  • strona Artykuły istnieje.
  • na stronie głównej znajduje się menu z nawigacją do strony Artykuły.
  1. Jako użytkownik, chcę mieć możliwość wysłania przygotowanego formularza ze strony Kontakt, aby móc kontaktować się z twórcą serwisu. Formularz posiada wymagane pola.

Kryteria akceptacji:

  • strona Kontakt istnieje.
  • na stronie głównej znajduje się menu z nawigacją do strony Kontakt.
  • na stronie Kontakt istnieje formularz wysłania wiadomości z polami: Twój e-mail [wymagane], Temat [opcjonalne], Treść [wymagane], przycisk Wyślij.

Warunki testowe – przykłady

Jak widać, niektóre z powyższych celi zawierają dodatkowe warunki testowe, które trzeba będzie ująć w oczekiwanych rezultatach (filtrowanie wiadomości, pola wymagane).

Lp. Nazwa Opis Oczekiwany rezultat
1 Widoczność strony głównej. Sprawdzenie dostępności strony strony głównej. Można przejść do strony strony głównej poprzez podanie adresu remigiuszbednarczyk.pl.
2 Nawigacja po stronie. Sprawdzenie funkcji nawigacji po stronach:
  • O mnie (Strona główna).
  • Jak zostać testerem.
  • Artykuły.
  • Kontakt.

z poziomu górnego menu.

Można przejść do strony:
  • O mnie (Strona główna).
  • Jak zostać testerem.
  • Artykuły.
  • Kontakt.
3 Widoczność strony Jak zostać testerem. Sprawdzenie dostępności strony Jak zostać testerem. Można przejść do strony Jak zostać testerem.
4 Komentowanie. Sprawdzenie funkcji tworzenia komentarza na stronie Jak zostać testerem. Można utworzyć komentarz na stronie Jak zostać testerem. Formularz komentarza filtruje wiadomości będące spamem.
5 Odnośnik do Polityki prywatności umieszczony w stopce strony. Sprawdzenie funkcji nawigacji do stron z poziomu stopki strony. Można użyć odnośnika Polityka prywatności stopce strony.
6 Widoczność strony Polityka prywatności. Sprawdzenie dostępności strony Polityka prywatności. Można przejść do strony Polityka prywatności.
7 Widoczność strony Artykuły. Sprawdzenie dostępności strony Artykuły. Można przejść do strony Artykuły.
8 Widoczność strony Kontakt. Sprawdzenie dostępności strony Kontakt. Można przejść do strony Kontakt.
9 Kontakt przez formularz. Sprawdzenie funkcji wysłania formularza na stronie Kontakt. Można utworzyć i wysłać formularz na stronie Kontakt. Formularz wiadomości posiada pola wymagane.

Przypadki testowe – przykłady

Tak rozpisane warunki testowe będą potrzebowały dodatkowych przypadków testowych:

  • na stronie głównej utworzono górne menu umożliwiające nawigację po stronach z wymagań.
  • formularz komentarza filtruje wiadomości będące spamem.
  • formularz wiadomości posiada pola wymagane.
  • istnieje strona Polityka prywatności.

Poniższa lista ma charakter poglądowy i wymienia przypadki testowe dla znanych warunków testowych. Zwróć uwagę, że poniższe przypadki testowe zostały zaprojektowane tak, aby pokryć jak najwięcej wymagań z podstawy testów:

Lp. Priorytet Nazwa Dane testowe Warunki wstępne Kroki wykonania Oczekiwany rezultat
1 1 Widoczność strony głównej. Domena remigiuszbednarczyk.pl istnieje i jest poprawnie skonfigurowana.
  1. Użytkownik przechodzi do strony remigiuszbednarczyk.pl.
Strona główna zostaje wyświetlona.
2 1 Możliwość nawigacji poprzez górne menu na stronie głównej. Strona główna istnieje. Utworzono górne menu umożliwiające nawigację.
  1. Użytkownik przechodzi do strony remigiuszbednarczyk.pl.
Strona główna zostaje wyświetlona.

Na górze strony wyświetla się menu nawigacji z odnośnikami do:

  • O mnie (Strona główna).
  • Jak zostać testerem.
  • Artykuły.
  • Kontakt.
3 1 Widoczność strony Jak zostać testerem. Strona Jak zostać testerem istnieje.
  1. Użytkownik przechodzi do strony remigiuszbednarczyk.pl.
  2. Z górnego menu strony wybiera przycisk Jak zostać testerem.

 

Strona Jak zostać testerem zostaje wyświetlona.
4 1 Dodawanie nowego komentarza na stronie  Jak zostać testerem. Treść komentarza:

Lorem ipsum dolor sit amet, consectetur adipiscing elit. Proin nibh augue, suscipit a, scelerisque sed, lacinia in, mi. Cras vel lorem.

Strona Jak zostać testerem istnieje.
  1. Użytkownik przechodzi do strony remigiuszbednarczyk.pl.
  2. Z górnego menu strony wybiera przycisk Jak zostać testerem.
  3. Przechodzi na dół strony.
  4. Wpisuje treść w pole komentarza.
  5. Wybiera przycisk Pisz.
Strona Jak zostać testerem zostaje wyświetlona. Komentarz zostaje dodany. Strona wyświetla nowy komentarz. Licznik komentarzy wzrasta o jeden punkt.
5 1 Dodawanie nowego komentarza na stronie  Jak zostać testerem o takiej samej treści. Treść komentarza:

Lorem ipsum dolor sit amet, consectetur adipiscing elit. Proin nibh augue, suscipit a, scelerisque sed, lacinia in, mi. Cras vel lorem.

Strona Jak zostać testerem istnieje.
  1. Użytkownik przechodzi do strony remigiuszbednarczyk.pl.
  2. Z górnego menu strony wybiera przycisk Jak zostać testerem.
  3. Przechodzi na dół strony.
  4. Wpisuje treść w pole komentarza.
  5. Wybiera przycisk Pisz.
Strona Jak zostać testerem zostaje wyświetlona. Na stronie pojawia się komunikat informujący o spamie. Komentarz nie zostaje dodany.
6 1 Widoczność stopki strony. Strona główna istnieje.

Utworzono stopkę strony.

  1. Użytkownik przechodzi do strony remigiuszbednarczyk.pl.
Strona główna zostaje wyświetlona.

Na dole strony wyświetla się stopka z możliwością nawigacji do strony Polityka prywatności.

7 1 Widoczność strony Polityka prywatności. Strona Polityka prywatności istnieje.
  1. Użytkownik przechodzi do strony remigiuszbednarczyk.pl.
  2. Ze stopki wybiera przycisk Polityka prywatności.
Strona Polityka prywatności zostaje wyświetlona.
8 1 Widoczność strony Kontakt. Strona Kontakt istnieje.
  1. Użytkownik przechodzi do strony remigiuszbednarczyk.pl.
  2. Z górnego menu strony wybiera przycisk Kontakt.
Strona Jak zostać testerem zostaje wyświetlona.
9 1 Wysłanie formularza na stronie Kontakt. Twój e-mail: test@remigiuszbednarczyk.pl

Treść:

Lorem ipsum dolor sit amet, consectetur adipiscing elit. Proin nibh augue, suscipit a, scelerisque sed, lacinia in, mi. Cras vel lorem.

Strona Kontakt istnieje.
  1. Użytkownik przechodzi do strony remigiuszbednarczyk.pl.
  2. Z górnego menu strony wybiera przycisk Kontakt.
Strona Kontakt zostaje wyświetlona. Formularz wysłania wiadomości jest widoczny na stronie Kontakt
10 1 Wysłanie formularza bez podania pola e-mail w formularzu na stronie Kontakt. Treść:

Lorem ipsum dolor sit amet, consectetur adipiscing elit. Proin nibh augue, suscipit a, scelerisque sed, lacinia in, mi. Cras vel lorem.

Strona Kontakt istnieje.
  1. Użytkownik przechodzi do strony remigiuszbednarczyk.pl.
  2. Z górnego menu strony wybiera przycisk Kontakt.
  3. Uzupełnia pole Treść.
Strona Kontakt zostaje wyświetlona. Pojawia się komunikat o wymagalności pola Twój e-mail. Formularz nie zostaje wysłany.
11 1 Wysłanie formularza bez podania pola treść w formularzu na stronie Kontakt. Twój e-mail: test@remigiuszbednarczyk.pl Strona Kontakt istnieje.
  1. Użytkownik przechodzi do strony remigiuszbednarczyk.pl.
  2. Z górnego menu strony wybiera przycisk Kontakt.
  3. Uzupełnia pole Twój e-mail.
Strona Kontakt zostaje wyświetlona. Pojawia się komunikat o wymagalności pola Treść. Formularz nie zostaje wysłany.
12 2 Widoczność strony Artykuły. Można przejść do strony Artykuły. Strona Artykuły istnieje.
  1. Użytkownik przechodzi do strony remigiuszbednarczyk.pl.
  2. Z górnego menu strony wybiera przycisk Artykuły.
Strona Artykuły zostaje wyświetlona.

Z racji tego, że na tym etapie powyższa lista składa się z niezależnych od siebie przypadków testowych, następuje spora powtarzalność treści, np. w warunkach wstępnych. Dzieje się tak dlatego, że przypadki nie zostały jeszcze ze sobą powiązane i każdy z nich musi przedstawiać całą napotkaną sytuację od nowa. Przypadki mogą być dodatkowo rozbudowane o wspomniane warunki końcowe, wtedy jeszcze łatwiej będzie zaprojektować procedurę testową.

Jest to jednocześnie jedna z wad projektowania przypadków testowych ze względu na dużą powtarzalność i czasochłonność projektowania. Odpowiedzią na ten problem stają się procedury testowe, które z racji ścisłego powiązania i uporządkowania przypadków testowych, mogą zoptymalizować listę opisywanych przypadków testowych i ich treść. Przykładowo, nie będzie potrzeby każdorazowo sprawdzać czy strona Jak zostać testerem istnieje.

PS. Uważny tester zauważy, że górne menu jest rozpisane w wymaganiach tylko na stronę główną. Jest to celowy zabieg dla zaoszczędzenia Twojego czasu, aby nie tworzyć dziesiątek dodatkowych wymagań i przypadków testowych dla każdej strony w serwisie. Jest to jednocześnie bardzo bezpieczne wymaganie, znacząco skracające listy do pokrycia.  Zważając na kontekst projektu i jego specyfikę (strona internetowa) powinniśmy mieć na uwadze, że menu nawigacji oraz stopka powinny znajdować się na każdej stronie serwisu. Jeśli nie ma tego sprecyzowanego w wymaganiach może to być defekt warty zgłoszenia.

Procedura testowa/Scenariusz testowy – przykłady

Zakładając, że procedura zawiera w sobie uporządkowane przypadki testowe, których warunki końcowe jednego przypadku są warunkami wstępnymi dla kolejnego, odnieśmy się do powyższych przypadków testowych. Naszym celem będzie stworzyć procedurę testową, która sprawdzi możliwość wysyłania formularza wiadomości z poziomu strony Kontakt. Mając to na uwadze, będziemy potrzebować przypadków testowych, które pokryją wymagane do pełnego odtworzenia ścieżki. W szczegółowej procedurze testowej, poza samą stroną Kontakt pojawią się więc następujące przypadki:

  • widoczność strony głównej.
  • możliwość nawigacji poprzez górne menu na stronie głównej.
  • widoczność strony Kontakt.
  • wysłanie formularza na stronie Kontakt.
  • wysłanie formularza bez podania pola e-mail w formularzu na stronie Kontakt.
  • wysłanie formularza bez podania pola treść w formularzu na stronie Kontakt.

Struktura takiej procedury będzie wyglądała następująco:

Nazwa: TS1. Wysłanie formularza na stronie Kontakt.

Opis: Ten test sprawdza możliwość kontaktu poprzez specjalnie przygotowany formularz na stronie Kontakt.

Warunki wstępne: Strona główna, górne menu strony, strona Kontakt, e-mail użytkownika, temat, treść wiadomości.

Wymagania: 1,5

Typ testu: pozytywny

Lp. Opis kroku Oczekiwany rezultat Rzeczywisty rezultat
1 Wejdź na stronę główną serwisu remigiuszbednarczyk.pl. Strona główna zostaje wyświetlona. Strona główna wyświetliła się.
2 Sprawdź, czy górne menu wyświetla wymienione przyciski:
  • “O mnie (strona główna)”.
  • “Jak zostać testerem?”.
  • “Artykuły”.
  • “Kontakt”.
Wymienione pola wyświetlają się:
  • “O mnie (strona główna)”.
  • “Jak zostać testerem?”.
  • “Artykuły”.
  • “Kontakt”.
Wymienione pola zostały wyświetlone:
  • “O mnie (strona główna)”.
  • “Jak zostać testerem?”.
  • “Artykuły”.
  • “Kontakt”.
3 Wybierz przycisk Kontakt z górnego menu strony. Użytkownik zostaje przeniesiony do widoku strony Kontakt. Użytkownik został przeniesiony do widoku strony Kontakt.
4 Sprawdź, czy wyświetlone są wymienione pola:
  • “Twój e-mail”.
  • “Temat”.
  • “Treść”.
  • przycisk “Wyślij”.
Wymienione pola wyświetlają się:
  • “Twój e-mail”.
  • “Temat”.
  • “Treść”.
  • przycisk “Wyślij”.
Wymienione pola zostały wyświetlone:
  • “Twój e-mail”.
  • “Temat”.
  • “Treść”.
  • przycisk “Wyślij”.
5 Wypełnij pola:
  • “Twój e-mail”.
  • “Temat”.
  • “Treść”.

danymi z warunków wstępnych.

Pola:
  • “Twój e-mail”.
  • “Temat”.
  • “Treść”.

zostają wypełnione.

Pola:
  • “Twój e-mail”.
  • “Temat”.
  • “Treść”.

zostały wypełnione.

6 Kliknij przycisk Wyślij. Wiadomość zostaje wysłana. Wiadomość została wysłana.

Uwagi odnośnie scenariusza TS1:

Sprawdziliśmy podstawową pozytywną ścieżkę przejścia. Jak widzisz sprawdzanie widoczności pól i przycisków wymaganych do wykonania testu jest tak wnikliwe, jak wymagania na których się opierają. Mamy więc dodatkową weryfikację pól, jednak nie pokrywa ona wymagań zweryfikowania pól wymaganych. W tym celu tworzymy następny scenariusz testowy:

Nazwa: TS2. Walidacja formularza na stronie Kontakt.

Opis: Ten test sprawdza wymagane pola formularza na stronie Kontakt.

Warunki wstępne: Strona główna, górne menu strony, strona Kontakt, e-mail użytkownika, treść wiadomości.

Wymagania: 1,5

Typ testu: negatywny

Lp. Opis kroku Oczekiwany rezultat Rzeczywisty rezultat
1 Wejdź na stronę główną serwisu remigiuszbednarczyk.pl. Strona główna zostaje wyświetlona. Strona główna wyświetliła się.
2 Sprawdź, czy górne menu wyświetla wymienione przyciski:
  • “O mnie (strona główna)”.
  • “Jak zostać testerem?”.
  • “Artykuły”.
  • “Kontakt”.
Wymienione pola wyświetlają się:
  • “O mnie (strona główna)”.
  • “Jak zostać testerem?”.
  • “Artykuły”.
  • “Kontakt”.
Wymienione pola zostały wyświetlone:
  • “O mnie (strona główna)”.
  • “Jak zostać testerem?”.
  • “Artykuły”.
  • “Kontakt”.
3 Wybierz przycisk Kontakt z górnego menu strony. Użytkownik zostaje przeniesiony do widoku strony Kontakt. Użytkownik został przeniesiony do widoku strony Kontakt.
4 Sprawdź, czy wyświetlone są wymienione pola:
  • “Twój e-mail”.
  • “Temat”.
  • “Treść”.
  • przycisk “Wyślij”.
Wymienione pola wyświetlają się:
  • “Twój e-mail”.
  • “Temat”.
  • “Treść”.
  • przycisk “Wyślij”.
Wymienione pola zostały wyświetlone:
  • “Twój e-mail”.
  • “Temat”.
  • “Treść”.
  • przycisk “Wyślij”.
5 Wypełnij pole “Twój e-mail”.

e-mailem z warunków wstępnych.

Pole “Twój e-mail” zostaje wypełnione. Pole “Twój e-mail” zostało wypełnione.
6 Kliknij przycisk Wyślij. Wiadomość nie zostaje wysłana. Formularz oznacza brakujące wymagane pole “Treść”. Wiadomość nie została wysłana. Pole “Treść” zostało oznaczone jako wymagane.
7 Odśwież stronę Kontakt. Strona Kontakt zostaje odświeżona. Formularz jest pusty. Strona Kontakt została odświeżona. Formularz jest pusty.
8 Wypełnij pole “Treść”.

treścią z warunków wstępnych.

Pole “Treść” zostaje wypełnione. Pole “Treść” zostało wypełnione.
9 Kliknij przycisk Wyślij. Wiadomość nie zostaje wysłana. Formularz oznacza brakujące wymagane pole “Twój e-mail”. Wiadomość nie zostaje wysłana. Wymagane pole “Twój e-mail” zostało oznaczone jako brakujące.
10 Odśwież stronę Kontakt. Strona Kontakt zostaje odświeżona. Formularz jest pusty. Strona Kontakt została odświeżona. Formularz jest pusty.
11 Kliknij przycisk Wyślij. Wiadomość nie zostaje wysłana. Formularz oznacza brakujące wymagane pola:
  • “Twój e-mail”.
  • “Treść”.
Wiadomość nie została wysłana. Formularz oznacza brakujące wymagane pola:
  • “Twój e-mail”.
  • “Treść”.

Uwagi odnośnie scenariusza TS2:

Jak widzisz test pokrywa wszystkie trzy możliwości błędnego wykorzystania formularza na stronie Kontakt. Nie ma tutaj oddzielnego przypadku testowego dla pola Temat, ponieważ nie podlega ono walidacji jako pole niewymagane.

W ten sposób pokryty został zarówno pozytywny, jak i negatywny test. Dodatkowo wykonanie tych procedur jednej po drugiej nie spowoduje żadnych konfliktów w działaniu systemu. Jest to więc dobry kandydat do zestawu testowego, który później zaplanowany będzie w harmonogramie wykonania testów. I na tym kończy się dzisiejszy artykuł. Zaczęliśmy od zarysu produktów testowych w procesie testowym, a kończymy na konkretnej dokumentacji opartej na działaniu tej strony internetowej.

5 / 5
Kategorie: Testing
Remigiusz Bednarczyk
Autor: Remigiusz Bednarczyk
W Sii jestem Inżynierem ds. Testów i Analiz dla ważnego klienta zajmującego się marketingiem baz danych. Projekt umożliwia mi rozwój w sektorze BI, hurtowni danych. Na codzień pracuję z zespołami ulokowanymi w USA, UK i w Polsce, co wiąże się z wyzwaniami zarówno w komunikacji, jak i ze zwiększonymi oczekiwaniami ze strony klienta. Testowanie oprogramowania jest jednocześnie moją pasją, którą staram się nieustannie rozwijać i dzielić z innymi. W niedalekiej przyszłości planuję zasilić kadrę trenerską Sii, co pozwoli mi na przekazywanie pozyskanej wiedzy i doświadczenia adeptom sztuki testowania. W wolnym czasie angażuję się w rozwój lubelskiej grupy biegaczy Sii, oraz zajmuję się treningiem metodą Hardstyle Kettlebell wg. metody Pavela Tsatsouline'a.

Imię i nazwisko (wymagane)

Adres email (wymagane)

Temat

Treść wiadomości

Zostaw komentarz