Wprowadzenie do scenariusza testowego
Scenariusz testowy to połączenie dwóch słów, tj. Test i scenariusz. Test reprezentuje akt weryfikacji lub walidacji, a scenariusz przedstawia podróż użytkownika. Każda funkcjonalna funkcja jest nazywana scenariuszem testowym. Scenariusz testowy można opisać jako weryfikację lub walidację podróży użytkownika. Będzie to miało formę dokumentów, które zawierają wszystkie przypadki testowe napisane szczegółowo w celu przetestowania kompleksowej funkcjonalności aplikacji. Jest to jedna z wysokopoziomowych kategoryzacji wymagań, które można przetestować. Jest również znany jako możliwość testowa lub warunek testowy.
Dlaczego warto tworzyć scenariusze testowe?
Wiele scenariuszy testowych może być objętych jednym scenariuszem testowym. Dlatego relacja między scenariuszami testowymi a przypadkami testowymi jest jeden do wielu. Ale każdy scenariusz musi zostać rozwiązany przez testera podczas jego tworzenia. Testerzy tworzą ją w celu przetestowania aplikacji z punktu widzenia użytkownika końcowego. Testerzy szukają od wszystkich programistów, interesariuszy i klientów, aby przygotować ich krytycznych.
Powody ich tworzenia są następujące:
- Kompletne i prawidłowe pokrycie testu zapewnia stworzenie idealnych scenariuszy testowych.
- Ich stworzenie staje się niezbędne do zbadania kompleksowych funkcji programu.
- Najważniejsze i najistotniejsze transakcje typu end-to-end lub użycie aplikacji w czasie rzeczywistym można dobrze określić przy ich pomocy.
- Mogą być używane jako narzędzie do szybkiego określania siły roboczej, która dodatkowo pomaga klientom lub organizacjom w tworzeniu propozycji i organizacji siły roboczej do testowania skutecznie i wydajnie.
- Aby zapewnić dokładne i prawidłowe testowanie aplikacji, zatwierdzanie odbywa się na różnych poziomach, w tym klientów, analityków biznesowych, programistów itp.
Podobnie mogą istnieć pewne okoliczności, w których należy unikać jego tworzenia.
- Nie można go tworzyć w projektach zgodnych z metodykami zwinnymi, takimi jak Scrum itp.
- Gdy testowane aplikacje są niestabilne, zbyt skomplikowane lub gdy projekt znajduje się w stanie krytycznym, można go uniknąć.
- Można tego uniknąć w przypadku testów regresyjnych lub nowego błędu, ponieważ w projektach serwisowych ciężkie ich dokumentacje miałyby miejsce wcześniej w poprzednich cyklach testowych.
Jak można pisać scenariusze testowe?
Tester może wykonać następujące kroki w celu utworzenia scenariuszy testowych:
- Krok 1: Dokument wymagań, takich jak specyfikacja wymagań biznesowych (BRS), specyfikacja wymagań funkcjonalnych (FRS) i specyfikacja wymagań systemowych (SRS) testowanej aplikacji, należy dokładnie i dokładnie przeczytać. Instrukcje, podręczniki, przypadki użycia itp. Testowanej aplikacji można odnieść do tego samego.
- Krok 2: Wszystkie możliwe cele i działania użytkownika powinny zostać właściwie określone dla każdego wymagania. Należy również określić wszystkie cechy techniczne każdego wymagania.
- Krok 3: Wszystkie możliwe przyczyny włamania do systemu i oceny użytkownika powinny być wykonane z perspektywy hakera. Oceny użytkownika można dokonać, znajdując wszystkie możliwości obsługi aplikacji przez użytkownika.
- Krok 4: Pełna lista wszystkich możliwych przypadków testowych do weryfikacji wszystkich funkcjonalności aplikacji powinna zostać sporządzona po całkowitym przeczytaniu dokumentu zapotrzebowania i zakończeniu analizy.
- Krok 5: Po zarejestrowaniu wszystkich, aby zweryfikować wymaganie i jego scenariusz testowy są zgodne, należy utworzyć Matrycę identyfikowalności.
- Krok 6: Wszystkie utworzone scenariusze testowe są przeglądane i oceniane przez przełożonego. Jest również dalej weryfikowany przez wszystkie zainteresowane strony.
Zgodnie z procedurą projektu, każdy scenariusz testowy musi być dopasowany do co najmniej jednej historii użytkownika lub wymagania. Konieczne jest osobne zweryfikowanie każdego scenariusza testowego pod kątem jego wymagań, przed wieloma wymaganiami w jednym scenariuszu testowym. Dla uproszczenia można uniknąć złożonych scenariuszy testowych z wieloma wymaganiami. Cena jest wprost proporcjonalna do ich liczby. Dlatego zawsze zaleca się uruchamianie tylko wybranych i wymaganych zgodnie z priorytetem klienta.
Przykłady
Poniżej znajduje się kilka przykładów scenariusza testowego
Scenariusz testowy dla aplikacji do zakupów online Buykart
Scenariusze testowe, które można wziąć pod uwagę przy weryfikacji aplikacji do zakupów online Buykart, są następujące:
Scenariusz testowy 1: Sprawdzanie funkcjonalności logowania
Przypadki testowe, które można rozważyć przy tworzeniu, to:
- Zachowanie aplikacji podczas wprowadzania prawidłowego identyfikatora logowania i prawidłowego hasła można sprawdzić.
- Zachowanie aplikacji podczas wprowadzania prawidłowego identyfikatora logowania i nieprawidłowego hasła można sprawdzić.
- Zachowanie aplikacji podczas wprowadzania nieprawidłowego identyfikatora logowania i prawidłowego hasła można sprawdzić.
- Zachowanie aplikacji podczas wprowadzania nieprawidłowego identyfikatora logowania i nieprawidłowego hasła można sprawdzić.
- Można sprawdzić zachowanie aplikacji podczas logowania, wprowadzając sam identyfikator logowania bez hasła.
- Można sprawdzić zachowanie aplikacji podczas logowania, wprowadzając samo hasło bez identyfikatora logowania.
- Można sprawdzić zachowanie aplikacji podczas logowania bez podawania zarówno identyfikatora logowania, jak i hasła.
- Zachowanie aplikacji po wybraniu zapomnianego hasła.
Scenariusz testowy 2: Sprawdzanie funkcjonalności wyszukiwania
Przypadki testowe, które można rozważyć przy tworzeniu, to:
- Zachowanie aplikacji podczas wyszukiwania prawidłowego produktu.
- Zachowanie aplikacji podczas wyszukiwania nieprawidłowego produktu.
Scenariusz testowy 3: Sprawdzanie szczegółów produktu
Przypadki testowe, które można rozważyć przy tworzeniu, to:
- Zachowanie aplikacji po wybraniu produktu.
- Zachowanie aplikacji produkt jest na liście życzeń.
- Zachowanie aplikacji po dodaniu produktu do koszyka.
- Zachowanie aplikacji po wybraniu opcji Kup teraz.
- Zachowanie aplikacji po wprowadzeniu nieprawidłowego adresu.
- Zachowanie aplikacji po wprowadzeniu prawidłowego adresu.
- Zachowanie aplikacji, gdy zaznaczonych jest wiele opcji płatności.
Scenariusz testowy 4: Sprawdzanie funkcjonalności płatności
Przypadki testowe, które można rozważyć przy tworzeniu, to:
- Zachowanie aplikacji po wybraniu każdej opcji płatności.
- Zachowanie aplikacji po wybraniu prawidłowej opcji płatności.
- Zachowanie aplikacji po wybraniu nieprawidłowej opcji płatności.
- Zachowanie aplikacji, gdy płatność się powiedzie.
- Zachowanie aplikacji w przypadku odrzucenia płatności.
Scenariusz testowy 5: Sprawdzanie funkcjonalności szczegółów zamówienia
Przypadki testowe, które można rozważyć przy tworzeniu, to:
- Zachowanie aplikacji po wybraniu każdego zamówienia.
- Zachowanie aplikacji po wybraniu opcji Zwrot produktu.
- Zachowanie aplikacji po wybraniu opcji śledzenia produktu.
- Zachowanie aplikacji po wybraniu opcji Przejrzyj produkt.
Wniosek
Działa jako właściwy przewodnik dla testerów i pomaga im zwiększyć efektywność i wydajność testów. Pomaga w zmniejszeniu złożoności i redundancji testów. Każdy przypadek testowy jest napisany szczegółowo dla lepszego zrozumienia. To bardzo oszczędza czas testerów.
Polecane artykuły
To był przewodnik po scenariuszu testowym. Tutaj omawiamy sposoby tworzenia scenariuszy testowych z różnymi przykładami. Możesz także zapoznać się z następującymi artykułami, aby dowiedzieć się więcej -
- Stres związany z niepewnością pracy
- Zmotywowany i oddany
- Co to jest testowanie zwinne?
- Jak napisać przypadek testowy?