Niniejszy samouczek wyjaśnia, czym jest scenariusz testowy wraz z jego znaczeniem, implementacją, przykładami i szablonami:
Każda funkcjonalność / funkcja oprogramowania, którą można przetestować, jest określana jako scenariusz testowy. Perspektywa użytkownika końcowego jest brana pod uwagę podczas pisania scenariuszy testowych.
Niniejszy samouczek pomoże ci odpowiedzieć na pytania: dlaczego scenariusze testowe są wymagane, kiedy scenariusze testowe są pisane i jak pisać scenariusze testowe.
Co to jest scenariusz testowy?
Rozważmy hipotetyczną sytuację: Jest ogromny ocean, przez który trzeba podróżować od jednego brzegu do drugiego. Na przykład, z Bombaju w Indiach do Kolombo na Srilance.
Do wyboru są następujące środki transportu:
(i) Drogi lotnicze: Lot do Kolombo
(ii) Drogi wodne: preferowany statek do Kolombo
(iii) Kolej: Podróż pociągiem do Srilanki
A teraz scenariusze testowe: Podróż z wybrzeża Bombaju do wybrzeża Kolombo to funkcjonalność, którą należy przetestować.
Scenariusze testowe obejmują:
- Podróżowanie liniami lotniczymi,
- Podróżowanie drogami wodnymi lub
- Podróżowanie koleją.
Te scenariusze testowe będą miały przypadki testowe.
Przypadki testowe, które można napisać dla powyższych scenariuszy testowych obejmują:
Scenariusz testowy: Podróżowanie liniami lotniczymi
Przypadki testowe mogą obejmować scenariusze takie jak
- Lot odbywa się zgodnie z zaplanowanym czasem.
- Lot nie odbywa się zgodnie z zaplanowanym czasem.
- Wystąpiła sytuacja awaryjna (intensywne opady deszczu i burza).
W ten sam sposób można napisać osobny zestaw przypadków testowych dla pozostałych scenariuszy.
Przejdźmy teraz do technologicznych scenariuszy testowych.
Scenariuszem testowym jest wszystko, co można przetestować. Możemy zatem stwierdzić, że każda testowana funkcjonalność oprogramowania może być podzielona na wiele mniejszych funkcjonalności i może być określana jako "scenariusz testowy".
Przed dostarczeniem jakiegokolwiek produktu do klienta należy ocenić jego jakość. Scenariusz testowy pomaga w ocenie jakości funkcjonalnej aplikacji, która jest zgodna z jej wymaganiami biznesowymi.
Scenariusz testowy to proces, w którym tester testuje aplikację z perspektywy użytkownika końcowego. Wydajność i jakość aplikacji są dokładnie oceniane przed wdrożeniem w środowisku produkcyjnym.
Znaczenie scenariusza testowego
- Jeden scenariusz testowy może mieć wiele "przypadków testowych". Można go wyobrazić sobie jako duży panoramiczny obraz, a przypadki testowe są małymi częściami, które są ważne dla uzupełnienia panoramy.
- Jest to jednowierszowe stwierdzenie, a przypadki testowe składają się z krokowego opisu, aby zrealizować cel stwierdzenia scenariusza testowego.
- Przykład:
Scenariusz testowy: Dokonaj płatności za wykorzystaną usługę taksówki.
Będzie to miało wiele przypadków testowych, jak opisano poniżej:
(i) Metoda płatności: PayPal, Paytm, karta kredytowa/debetowa.
(ii) Dokonana płatność powiodła się.
(iii) Dokonana płatność nie powiodła się.
(iv) W międzyczasie proces płatności został przerwany.
(v) Brak dostępu do metod płatności.
(vi) Aplikacja psuje się w międzyczasie.
- Scenariusze testowe pomagają zatem w ocenie aplikacji zgodnie z rzeczywistymi sytuacjami.
- Określone scenariusze testowe pomagają w rozdzieleniu zakresu testów.
- To rozwidlenie jest określane jako priorytetyzacja, która pomaga w określeniu ważnych funkcji aplikacji.
- Priorytetowe testowanie funkcjonalności w dużym stopniu pomaga w pomyślnym wdrożeniu aplikacji.
- Ponieważ scenariusze testowe otrzymują priorytety, najważniejsze funkcjonalności mogą być łatwo zidentyfikowane i przetestowane w pierwszej kolejności. Zapewnia to, że większość kluczowych funkcjonalności działa poprawnie, a defekty z nimi związane są należycie wychwytywane i usuwane.
- Scenariusze testowe określają przepływ procesów biznesowych oprogramowania, dzięki czemu możliwe jest kompleksowe testowanie aplikacji.
Różnica między scenariuszem testowym a przypadkiem testowym
| Scenariusz testowy | Przypadki testowe |
|---|---|
| Scenariusz testowy to koncepcja. | Przypadki testowe są rozwiązaniami weryfikującymi tę koncepcję. |
| Scenariusz testowy to funkcjonalność wysokiego poziomu. | Przypadki testowe to szczegółowe procedury testowania funkcjonalności wysokiego poziomu. |
| Scenariusze testowe wywodzą się z wymagań/opracowań użytkownika. | Przypadki testowe wywodzą się ze scenariuszy testowych. |
| Scenariusz testowy to "Jaka funkcjonalność ma zostać przetestowana". | Przypadki testowe to "Jak przetestować funkcjonalność". |
| Scenariusze testowe zawierają wiele przypadków testowych. | Przypadek testowy może, ale nie musi być powiązany z wieloma scenariuszami testowymi. |
| Pojedyncze scenariusze testowe nigdy nie są powtarzalne. | Pojedynczy przypadek testowy może być używany wielokrotnie w różnych scenariuszach. |
| Wymagana krótka dokumentacja. | Wymagana jest szczegółowa dokumentacja. |
| Sesje burzy mózgów są wymagane do sfinalizowania scenariusza testowego. | Wymagana jest szczegółowa wiedza techniczna na temat aplikacji |
| Oszczędność czasu, ponieważ nie są wymagane szczegółowe informacje. | Czasochłonne, ponieważ trzeba zadbać o każdy szczegół. |
| Koszty utrzymania są niskie, ponieważ wymagane zasoby są niewielkie. | Koszty utrzymania są wysokie, ponieważ wymagane są duże zasoby |
Dlaczego scenariusze testowe są niezbędne?
Scenariusze testowe wywodzą się z wymagań lub historyjek użytkownika.
- Weźmy przykład scenariusza testowego dla rezerwacji taksówki.
- Scenariusze mogą obejmować opcje rezerwacji taksówki, metody płatności, śledzenie GPS, mapę drogową wyświetlaną poprawnie lub nie, szczegóły dotyczące taksówki i kierowcy wyświetlane poprawnie lub nie itp.
- Załóżmy teraz, że scenariuszem testowym jest sprawdzenie, czy usługi lokalizacyjne są włączone, a jeśli nie są włączone, wyświetlenie komunikatu "Turn on-location services". Ten scenariusz został pominięty i nie jest wymieniony w szablonie scenariuszy testowych.
- Scenariusz "Usługa lokalizacji" powoduje powstanie innych scenariuszy testowych z nim związanych.
Mogą to być:
- Usługa lokalizacji wyszarzona.
- Usługa lokalizacji włączona, ale brak internetu.
- Ograniczenia dotyczące usług na miejscu.
- Wyświetlana jest nieprawidłowa lokalizacja.
- Brak jednego scenariusza może oznaczać utratę wielu innych kluczowe scenariusze lub przypadki testowe Może to mieć ogromny wpływ na negatywny wpływ Powoduje to znaczną utratę zasobów (terminów).
- Scenariusze testowe w dużym stopniu pomagają w unikanie wyczerpujących testów Zapewnia to przetestowanie wszystkich kluczowych i oczekiwanych przepływów biznesowych, co dodatkowo pomaga w kompleksowym testowaniu aplikacji.
- Oszczędza to czas, a także nie jest wymagany bardziej szczegółowy opis przypadków testowych - wystarczy jednolinijkowy opis tego, co należy przetestować.
- Scenariusze testowe są pisane po sesje burzy mózgów W związku z tym prawdopodobieństwo pominięcia jakiegokolwiek scenariusza (kluczowego lub mniej istotnego) jest minimalne. Odbywa się to z uwzględnieniem aspektów technicznych, a także przepływu biznesowego aplikacji.
- Co więcej, scenariusze testowe mogą być zatwierdzane albo przez klienta-analityka biznesowego, albo przez obie te osoby, które posiadają wyraźną wiedzę na temat testowanej aplikacji.
Scenariusze testowe są zatem nieodzowną częścią SDLC.
Wdrażanie scenariuszy testowych
Przyjrzyjmy się implementacji scenariuszy testowych lub sposobowi ich pisania:
- Tworzone są wymagania epickie/biznesowe.
- Przykład Epic Utwórz konto Gmail. Epic może być główną funkcją aplikacji lub wymogiem biznesowym.
- Epiki są podzielone na mniejsze historie użytkownika w sprintach.
- Historyjki użytkownika wywodzą się z Epic. Te historyjki użytkownika muszą być bazowe i zatwierdzone przez interesariuszy.
- Scenariusze testowe wywodzą się z historyjek użytkownika lub dokumentów BRS (Business Requirement Document), SRS (System Requirement Specification Document) lub FRS (Functional Requirement Document), które są finalizowane i bazowane.
- Testerzy piszą scenariusze testowe.
- Te scenariusze testowe są zatwierdzane przez kierownika zespołu, analityka biznesowego lub kierownika projektu, w zależności od organizacji.
- Każdy scenariusz testowy musi być powiązany z co najmniej jedną historią użytkownika.
- Należy zidentyfikować zarówno pozytywne, jak i negatywne scenariusze testowe.
- Historyjki użytkownika obejmują Kryteria akceptacji, takie jak :
- Kryteria akceptacji to lista warunków lub stan intencji dla wymagań klienta. Oczekiwania klienta, a także nieporozumienia są brane pod uwagę podczas pisania kryteriów akceptacji.
- Są one unikalne dla jednej historii użytkownika, a każda historia użytkownika musi mieć co najmniej jedno kryterium akceptacji, które powinno być niezależnie testowalne.
- Kryteria akceptacji pomagają w określeniu, które funkcje są w zakresie, a które są poza zakresem projektu. Kryteria te powinny obejmować zarówno funkcje funkcjonalne, jak i niefunkcjonalne.
- Analitycy biznesowi piszą kryteria akceptacji, a Właściciel Produktu je zatwierdza.
- W niektórych przypadkach właściciel produktu może sam napisać kryteria.
- Scenariusze testowe można uzyskać na podstawie kryteriów akceptacji.
Przykłady scenariuszy testowych
#1) Scenariusze testowe dla aplikacji Kindle
Kindle to aplikacja, która umożliwia e-czytelnikom wyszukiwanie e-booków online, pobieranie ich i kupowanie. Amazon Kindle daje czytnikowi e-booków prawdziwe doświadczenie trzymania książki w ręku i czytania jej. Nawet przewracanie stron jest ładnie symulowane w aplikacji.
Teraz zanotujmy scenariusze testowe. ( Uwaga: Poniżej wymieniono ograniczone scenariusze, aby uzyskać ogólny pomysł na napisanie scenariusza testowego. Na jego podstawie może powstać wiele przypadków testowych).
| Scenariusze testowe # | Scenariusze testowe |
|---|---|
| 1 | Sprawdź, czy aplikacja Kindle uruchamia się prawidłowo. |
| 2 | Sprawdź, czy rozdzielczość ekranu dostosowuje się do różnych urządzeń po uruchomieniu aplikacji. |
| 3 | Sprawdź, czy wyświetlany tekst jest czytelny. |
| 4 | Sprawdź, czy działają opcje powiększania i pomniejszania. |
| 5 | Upewnij się, że kompatybilne pliki zaimportowane do aplikacji Kindle są czytelne. |
| 6 | Sprawdź pojemność pamięci aplikacji Kindle. |
| 7 | Sprawdź, czy funkcja pobierania działa poprawnie. |
| 8 | Sprawdź, czy symulacja przewracania stron działa poprawnie |
| 9 | Sprawdź zgodność formatów eBooków z aplikacją Kindle. |
| 10 | Sprawdź czcionki obsługiwane przez aplikację Kindle. |
| 11 | Sprawdź żywotność baterii używanej przez aplikację Kindle. |
| 12 | Weryfikacja działania Kindle w zależności od łączności sieciowej (Wi-Fi, 3G lub 4G). |
Z każdego scenariusza testowego opisanego powyżej można wyprowadzić wiele przypadków testowych.
#2) Kryteria akceptacji dla Dokumentów Google
"Dokumenty Google" to aplikacja internetowa do tworzenia, edytowania i udostępniania dokumentów tekstowych, arkuszy kalkulacyjnych, slajdów i formularzy. Dostęp do wszystkich plików można uzyskać online za pomocą przeglądarki internetowej mającej połączenie z Internetem.
Utworzone dokumenty mogą być udostępniane jako strona internetowa lub dokument gotowy do druku. Użytkownik może ustawić ograniczenia dotyczące tego, kto może przeglądać i edytować dokumenty. Pojedynczy dokument może być wspólnie udostępniany i opracowywany przez różne osoby z różnych lokalizacji geograficznych.
Poniżej wymieniono ograniczone scenariusze testowe dla ogólnego zrozumienia. Dogłębne scenariusze testowe dla dokumentów Google mogą stanowić odrębny temat.
| Kryteria akceptacji # | Kryteria akceptacji |
|---|---|
| 1 | Word, Arkusze lub Formularze mogą być otwierane bez błędów. |
| 2 | Dostępne są szablony dokumentów, arkuszy i slajdów. |
| 3 | Dostępne szablony są dostępne dla użytkowników. |
| 4 | Używany szablon można edytować (np. czcionki, rozmiar czcionki, dodawanie tekstu, usuwanie tekstu, wstawianie slajdów). |
| 5 | Jeśli połączenie internetowe nie jest tymczasowo dostępne, plik może być przechowywany lokalnie i przesłany po uzyskaniu połączenia internetowego. |
| 6 | Zmiany dokonane przez wielu użytkowników nie są nadpisywane. |
| 7 | Wielu użytkowników może pracować nad jednym dokumentem. |
| 8 | Wykonana praca jest przechowywana w przypadku utraty połączenia internetowego podczas przesyłania pliku. |
| 9 | Ograniczenia udostępniania są stosowane prawidłowo. |
| 10 | Użytkownicy z ograniczeniami widoku nie mogą edytować dokumentów. |
| 11 | Dokumenty mogą być publikowane w Internecie dla ogółu społeczeństwa. |
| 12 | Zmiany dokonane w dokumentach są zapisywane wraz ze znacznikiem czasu i danymi autora. |
W przypadku Dokumentów Google liczba scenariuszy testowych będzie bardzo duża. W takich przypadkach zazwyczaj tylko kryteria akceptacji są ustalane i zatwierdzane przez interesariuszy, a członkowie zespołu pracują nad tymi kryteriami akceptacji. Pisanie przypadków testowych, a raczej scenariuszy testowych, może być wyczerpującym zadaniem dla dużych aplikacji.
Kryteria akceptacji odgrywają ważną rolę w iteracyjnym planowaniu procesu i nigdy nie powinny być pomijane. Zdefiniowanie ich wcześniej i z góry pozwala uniknąć niespodzianek lub szoków pod koniec sprintów lub wydań.
Biorąc pod uwagę warunek wstępny.
Kiedy aby wykonać akcję.
Następnie wynik jest oczekiwany.
Formaty Given, When i Then są pomocne przy określaniu kryteriów akceptacji.
Przykład szablonu scenariusza testowego
| Użyj identyfikatora historii # | Identyfikator scenariusza testowego # | Wersja # | Scenariusze testowe | # Liczba przypadków testowych | Znaczenie |
|---|---|---|---|---|---|
| USID12.1 | TSID12.1.1 | Kin12.4 | Sprawdź, czy aplikacja Kindle uruchamia się prawidłowo. | 4 | Wysoki |
| USID12.1 | TSID12.1.2 | Kin12.4 | Sprawdź pojemność pamięci aplikacji Kindle. | 3 | Średni |
Wnioski
W każdym testowaniu oprogramowania zrozumienie cyklu życia i określenie scenariuszy testowych jest bardzo istotnym elementem. Jakość oprogramowania można poprawić, mając dobre podstawy dla scenariuszy testowych. Często użycie przypadków testowych i scenariuszy testowych może być zamienione.
Zasadą jest jednak, że scenariusz testowy jest używany do pisania wielu przypadków testowych lub możemy powiedzieć, że przypadki testowe pochodzą ze scenariuszy testowych. Dobrze zdefiniowane scenariusze testowe zapewniają dobrą jakość oprogramowania.