Wyślij zapytanie Dołącz do Sii

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.

Etapy

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.

Historyjki użytkownika

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 priorytetyzuje. 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”.

Co charakteryzuje 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.

Całość procesu

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.NazwaOpisOczekiwany rezultat
1Widoczność strony głównej.
Sprawdzenie dostępności strony strony głównej.
Można przejść do strony strony głównej poprzez podanie adresu remigiuszbednarczyk.pl.
2Nawigacja 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.
3Widoczność strony Jak zostać testerem.Sprawdzenie dostępności strony Jak zostać testerem.Można przejść do strony Jak zostać testerem.
4Komentowanie.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.
5Odnoś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.
6Widoczność strony Polityka prywatności.Sprawdzenie dostępności strony Polityka prywatności.Można przejść do strony Polityka prywatności.
7Widoczność strony Artykuły.Sprawdzenie dostępności strony Artykuły.Można przejść do strony Artykuły.
8Widoczność strony Kontakt.Sprawdzenie dostępności strony Kontakt.Można przejść do strony Kontakt.
9Kontakt 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.PriorytetNazwaDane testoweWarunki wstępneKroki wykonaniaOczekiwany rezultat
11Widoczność 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.
21Moż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.
31Widoczność 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.
41Dodawanie 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.
51Dodawanie 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.
61Widoczność 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.
71Widoczność 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.
81Widoczność 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.
91Wysłanie formularza na stronie Kontakt.Twój e-mail: test@remigiusz-bednarczyk
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
101Wysł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.
111Wysłanie formularza bez podania pola treść w formularzu na stronie Kontakt.Twój e-mail: test@remigiuszbednarczyk.plStrona 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.
122Widoczność 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 krokuOczekiwany rezultatRzeczywisty rezultat
1Wejdź na stronę główną serwisu remigiuszbednarczyk.pl.Strona główna zostaje wyświetlona.Strona główna wyświetliła się.
2Sprawdź, 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”.
3Wybierz przycisk Kontakt z górnego menu strony.Użytkownik zostaje przeniesiony do widoku strony Kontakt.Użytkownik został przeniesiony do widoku strony Kontakt.
4Sprawdź, 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”.
5Wypeł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.
6Kliknij 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 krokuOczekiwany rezultatRzeczywisty rezultat
1Wejdź na stronę główną serwisu remigiuszbednarczyk.pl.Strona główna zostaje wyświetlona.Strona główna wyświetliła się.
2Sprawdź, 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”.
3Wybierz 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”.
5Wypeł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.
6Kliknij 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.
7Odśwież stronę Kontakt.Strona Kontakt zostaje odświeżona. Formularz jest pusty.Strona Kontakt została odświeżona. Formularz jest pusty.
8Wypełnij pole „Treść”.  
treścią z warunków wstępnych.
Pole „Treść” zostaje wypełnione.Pole „Treść” zostało wypełnione.
9Kliknij 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.
10Odśwież stronę Kontakt.Strona Kontakt zostaje odświeżona. Formularz jest pusty.Strona Kontakt została odświeżona. Formularz jest pusty.
11Kliknij 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.

***

Chcesz lepiej zrozumieć aplikacje i systemy, które testujesz? Dołącz do ModernTester, poznaj najpotrzebniejsze narzędzia, frameworki oraz języki programowania i ćwicz na specjalnie przygotowanych środowiskach testowych: Platforma e-learningowa ModernTester

Ocena:
Autor
Avatar
Remigiusz Bednarczyk

W Sii pracuję jako Test Development Engineer. Jestem Test Leadem w dwóch projektach związanych z procesowaniem ETL. Na codzień pracuję z zespołami ulokowanymi w USA, Szwajcarii 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 jako trener techniczny, twórca szkoleń e-learningowych i rekruter. 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.

Komentarze

Twój adres e-mail nie zostanie opublikowany.

Może Cię również zainteresować

Pokaż więcej postów

Bądź na bieżąco

Zapisz się do naszego newslettera i otrzymuj najświeższe informacje ze świata Sii.

Otrzymaj ofertę

Jeśli chcesz dowiedzieć się więcej na temat oferty Sii, skontaktuj się z nami.

Wyślij zapytanie Wyślij zapytanie

Get an offer

Natalia Competency Center Director

Dołącz do Sii

Znajdź idealną pracę – zapoznaj się z naszą ofertą rekrutacyjną i aplikuj.

APLIKUJ APLIKUJ

Join Sii

Paweł Process Owner

ZATWIERDŹ

This content is available only in one language version.
You will be redirected to home page.

Are you sure you want to leave this page?