Menu

Jak przeglądać dokument SRS i tworzyć scenariusze testowe - Szkolenie z testowania oprogramowania w projekcie na żywo - Dzień 2

how review srs document

Wypróbuj Nasz Instrument Do Eliminowania Problemów

To jest drugi samouczek w naszym „Bezpłatne szkolenie online z testowania oprogramowania w projekcie na żywo” seria. Jeśli jesteś tu nowy, zapoznaj się z pierwszym samouczkiem wprowadzającym: Kompletne szkolenie z testowania oprogramowania w projekcie na żywo.

Przejdźmy teraz do szczegółowej analizy tego, jak przebiega przewodnik SRS, co musimy zidentyfikować na tym etapie, jakie kroki wstępne musimy podjąć, zanim zaczniemy, z jakimi wyzwaniami możemy się zmierzyć itp. szczegółowy sposób.

Jak przeglądać dokument SRS i tworzyć scenariusze testowe_

Faza projektowania SDLC:

Kolejną fazą SDLC jest „Projekt” - to tutaj wymagania funkcjonalne przekładane są na szczegóły techniczne. W tym kroku zaangażowani są zespoły deweloperów, projektantów, środowiska i danych. Wynikiem tego kroku jest zazwyczaj dokument projektu technicznego - TDD.

Dane wejściowe to dokument SRS zarówno do stworzenia TDD, jak i dla zespołu QA do rozpoczęcia pracy nad aspektem QA projektu - który polega na przejrzeniu SRS i zidentyfikowaniu celu testu.

Czego się nauczysz:

Co to jest przegląd SRS?

SRS to dokument tworzony przez zespół programistów we współpracy z analitykami biznesowymi i zespołami ds. Środowiska / danych. Zwykle ten dokument po sfinalizowaniu jest udostępniany zespołowi ds. Kontroli jakości podczas spotkania, na którym ustalane jest szczegółowe omówienie.

Czasami, w przypadku już istniejącej aplikacji, możemy nie potrzebować formalnego spotkania i kogoś, kto oprowadzi nas przez ten dokument. Możemy mieć potrzebne informacje, aby to zrobić samodzielnie.

Przegląd SRS to nic innego jak przejrzenie dokumentu specyfikacji wymagań funkcjonalnych i próba zrozumienia, jaka będzie docelowa aplikacja.

Formalny format i próbka zostały wam wszystkim udostępnione w poprzednim artykule. Nie musi to oznaczać, że wszystkie SRS będą dokładnie w ten sposób dokumentowane. Zawsze forma jest drugorzędna w stosunku do treści .

Niektóre zespoły po prostu zdecydują się napisać listę punktowaną, inne będą zawierać przypadki użycia, niektóre zespoły dołączą przykładowe zrzuty ekranu (takie jak dokument, który mieliśmy), a inne po prostu opisują szczegóły w akapitach.

Wstępne kroki do przeglądu specyfikacji wymagań oprogramowania

Krok 1) Dokumenty przechodzą wiele poprawek, więc upewnij się, że mamy odpowiednią wersję dokumentu, do którego się odnoszą, SRS.

Krok 2) Ustal wytyczne dotyczące tego, czego oczekuje się po zakończeniu przeglądu od każdego członka zespołu. Innymi słowy, zdecyduj, jakich produktów oczekuje się na tym etapie - zazwyczaj wynikiem tego etapu jest identyfikacja scenariuszy testowych. Scenariusze testowe to nic innego jak tylko jeden wiersz wskazujący „co przetestować” dla określonej funkcjonalności.

Krok 3) Ustal także wytyczne dotyczące sposobu prezentacji tego produktu - mam na myśli szablon.

Krok 4) Zdecyduj, czy każdy członek zespołu będzie pracował nad całym dokumentem, czy też podzieli go między siebie. Zdecydowanie zaleca się, aby wszyscy przeczytali wszystko, ponieważ zapobiegnie to koncentracji wiedzy z niektórymi członkami zespołu.

Jednak w przypadku dużego projektu, w którym dokumenty SRS mają prawie 1000 stron, podejście polegające na mądrym rozbiciu modułu dokumentu i przydzieleniu go do poszczególnych członków zespołu jest najbardziej praktyczne.

gdzie są przechowywane apki na Androida

Krok 5) Przegląd SRS pomaga również w lepszym zrozumieniu, czy istnieją jakieś szczególne warunki wstępne wymagane do testowania oprogramowania.

Krok 6) Produktem ubocznym jest lista zapytań, w przypadku których niektóre funkcje są trudne do zrozumienia lub w przypadku konieczności włączenia większej ilości informacji do wymagań funkcjonalnych lub w przypadku wykrycia błędów w SRS.

Czego potrzebujemy, aby zacząć?

  • Prawidłowa wersja dokumentu SRS
  • Jasne instrukcje, kto będzie nad czym pracował i ile czasu ma.
  • Szablon do tworzenia scenariuszy testowych.
  • Pozostałe informacje - z kim się skontaktować w przypadku pytań lub do kogo się zgłosić w przypadku niezgodności dokumentacji

Kto dostarczy te informacje?

Kierownicy zespołów są generalnie odpowiedzialni za dostarczenie wszystkich elementów wymienionych w powyższej sekcji. Jednak wkład członków zespołu jest zawsze ważny dla powodzenia całego przedsięwzięcia.

Kierownicy zespołów często pytają - jakiego rodzaju dane wejściowe? Czy nie byłoby lepiej przypisać określony moduł komuś, kto jest nim zainteresowany, niż członkowi zespołu, który nie jest? Czy nie byłoby miło zdecydować o docelowym terminie na podstawie opinii zespołu, niż narzucić mu decyzję? Również szablony są ważne dla powodzenia projektu.

Z reguły szablony mają wyższy wskaźnik wydajności, gdy są dostosowane do wygody i komfortu konkretnego zespołu. Należy zatem zauważyć, że liderami zespołu są przede wszystkim członkowie zespołu. Włączanie zespołu do codziennych decyzji ma kluczowe znaczenie dla sprawnego przebiegu projektu.

Czy szablon jest wymagany do scenariuszy testowych?

Po co szablon scenariuszy testowych - czy nie wystarczy, jeśli zrobimy tylko listę?

Tak jest. Jednak projekty oprogramowania nie są pokazami „jednoosobowymi”. Angażują Praca zespołowa .

Wyobraź sobie czteroosobowy zespół, jeśli każdy z nich zdecyduje się przejrzeć po jednym module specyfikacji wymagań oprogramowania. Członek zespołu A sporządził listę na kartce papieru. Członek zespołu 2 użył arkusza Excela. Członek zespołu 3 używał notatnika. Członek zespołu 4 użył słowa doc. Jak na koniec dnia skonsolidować całą pracę wykonaną w ramach projektu?

Ponadto, jak możemy zdecydować, który z nich jest standardem i jak możemy powiedzieć, co jest słuszne, a co nie, jeśli nie stworzyliśmy reguł, na początek?

Oto czym jest szablon: Zbiór wytycznych i uzgodniony format zapewniający jednolitość i zgodność dla całego zespołu.

Jak stworzyć szablon scenariuszy testów QA?

Szablony nie muszą być skomplikowane ani nieelastyczne.

Wszystko, czego potrzebują, to wydajny mechanizm do tworzenia użytecznych artefaktów testowych. Coś prostego, takiego jak to, które widzimy poniżej:

szablon scenariuszy testowych

Nagłówek tego szablonu zawiera miejsce wymagane do przechwycenia podstawowych informacji o projekcie, bieżącym dokumencie i dokumencie, do którego się odwołuje.

Poniższa tabela pozwoli nam stworzyć scenariusze testowe. Uwzględnione kolumny to:

Kolumna 1) Identyfikator scenariusza testowego
Każdy podmiot w naszym procesie testowania musi być niepowtarzalnie identyfikowalny. Dlatego każdy scenariusz testowy musi mieć przypisany identyfikator. Należy określić zasady, którymi należy się kierować podczas nadawania tego identyfikatora.

Na potrzeby tego artykułu będziemy postępować zgodnie z konwencją nazewnictwa jako TS (prefiks oznaczający scenariusz testowy), po którym następuje „_”, nazwa modułu MNIE (Moduł My Info projektu Orange HRM), po którym następuje „_”, a następnie podsekcja ( Na przykład, MNIE dla modułu My Info, P. dla fotografii itp.), po którym następuje numer seryjny. Przykładem może być: „TS_MI_MIM_01”.

Kolumna 2) Wymaganie
Pomocne jest to, że kiedy tworzymy scenariusz testowy, powinniśmy być w stanie odwzorować go z powrotem do sekcji dokumentu SRS, z której go wybraliśmy. Jeśli wymagania mają identyfikatory, możemy tego użyć. Jeśli nie, numery sekcji lub nawet numery stron dokumentu SRS, na podstawie których zidentyfikowaliśmy testowalne wymaganie, będą wystarczające.

Kolumna 3) Opis scenariusza testowego
Jedna linijka określająca, „co należy przetestować”. Odnosilibyśmy się również do tego jako celu testu.

Kolumna 4) Znaczenie
Ma to dać wyobrażenie o tym, jak ważna jest określona funkcjonalność dla AUT. Do tego pola można przypisać wartości takie jak wysokie, średnie i niskie. Możesz także wybrać system punktowy, na przykład 1-5, przy czym 5 jest najważniejsze, a 1 jest mniej ważne. Niezależnie od wartości, jaką może przyjąć to pole, należy z góry zdecydować.

Kolumna 5) Liczba przypadków testowych
Zgrubne oszacowanie liczby indywidualnych przypadków testowych, które moglibyśmy napisać w tym jednym scenariuszu testowym. Na przykład, Aby przetestować logowanie - uwzględniamy następujące sytuacje: Poprawna nazwa użytkownika i hasło. Poprawna nazwa użytkownika i złe hasło. Prawidłowe hasło i zła nazwa użytkownika. Tak więc sprawdzenie funkcjonalności logowania spowoduje 3 przypadki testowe.

Uwaga: Możesz rozwinąć ten szablon lub usunąć pola według własnego uznania.

Na przykład , w nagłówku możesz dodać „Sprawdzone przez”, usunąć datę utworzenia itp. Również w tabeli można umieścić pole „Utworzone przez”, aby wyznaczyć testera odpowiedzialnego za określony scenariusz testowy lub usunąć pole „Nie. przypadków testowych ”. Wybór nalezy do ciebie. Wybierz to, co działa najlepiej dla całego zespołu.

Przejrzyjmy teraz nasz dokument Orange HRM SRS i utwórzmy scenariusze testowe

Wskazówka dla profesjonalistów: sprawdź spis treści w przykładzie SRS, który dostarczyliśmy w pierwszych samouczkach, aby dowiedzieć się, jak będzie wyglądał każdy dokument i ile pracy może wymagać.

Sekcja 1 jest celem dokumentu. Brak testowalnych wymagań.

Sekcja 2.1 : Przegląd projektu - Odbiorcy - tam też nie ma wymagań do przetestowania.

Sekcja 2.2 : Sprzęt i hosting - w tej sekcji omówiono sposób hostowania witryny Orange HRM. Czy te informacje są ważne dla nas, testerów? Odpowiedź brzmi: tak i nie. Tak, ponieważ podczas testów potrzebujemy środowiska podobnego do środowiska czasu rzeczywistego.

To daje nam wyobrażenie, jak to powinno być. Nie, ponieważ nie jest to wymaganie testowalne - rodzaj warunku wstępnego przeprowadzenia testów.

Sekcja 3: Tutaj znajduje się ekran logowania i szczegóły typu konta, które musimy mieć, aby wejść na stronę. Jest to wymaganie, które można przetestować. Dlatego musi być częścią naszych scenariuszy testowych.

Zapoznaj się z dokumentem dotyczącym scenariuszy testowych, w którym dodano scenariusze testowe dla kilku sekcji SRS. W ramach praktyki dodaj pozostałe scenariusze w podobny sposób. Jednakże przechodzę od razu do sekcji 4 dokumentu.

Sekcja 4: Wymagania i wytyczne dotyczące estetyki / HTML - Ta sekcja najlepiej wyjaśnia, w jaki sposób niektóre wymagania mogą nie mieć sensu dla zespołu testowego w czasie przeglądu SRS, ale zespół powinien jednak zanotować je jako wymagania testowalne.

Jak je przetestować i czy potrzebujemy konkretnej konfiguracji / pomocy jakiegokolwiek zespołu, aby to zweryfikować, są to szczegóły, których możemy nie znać w tym momencie. Ale uczynienie ich częścią naszego zakresu testów jest pierwszym krokiem, aby upewnić się, że ich nie przegapimy.

Przykładowe scenariusze testowe dla aplikacji OrangeHRM: (kliknij, aby powiększyć obraz)

szablon scenariuszy testowych

=> Proszę zapoznać się z i pobierz dokument Scenariusze testowe po więcej informacji.

Kilka ważnych uwag dotyczących przeglądu SRS

# 1) Żadne informacje nie mogą być odkryte.
#dwa) Przeprowadź analizę wykonalności, aby sprawdzić, czy dane wymaganie jest poprawne, czy nie, a także czy można je przetestować, czy nie.
# 3) O ile nie istnieje oddzielna wydajność / bezpieczeństwo lub jakakolwiek inna forma zespołów testowych - naszym zadaniem jest upewnienie się, że wszystkie niefunkcjonalne wymagania muszą być wzięte pod uwagę.
# 4) Nie wszystkie informacje są skierowane do testerów, dlatego ważne jest, aby wiedzieć, na co zwrócić uwagę, a na co nie.
# 5) Znaczenie i nie. przypadków testowych dla scenariusza testowego nie musi być dokładnych i można je wypełnić przybliżoną wartością lub pozostawić puste.

Podsumowując, przegląd SRS skutkuje:

  • Lista scenariuszy testowych
  • Przegląd wyników - błędy dokumentacji / wymagań znalezione podczas statycznego przeglądania / weryfikacji dokumentu SRS
  • Lista pytań dla lepszego zrozumienia - w przypadku jakichkolwiek
  • Wstępny pomysł, jak powinno wyglądać środowisko testowe
  • Identyfikacja zakresu testów i przybliżony pogląd na to, ile przypadków testowych możemy mieć - czyli ile czasu potrzebujemy na dokumentację i ostatecznie wykonanie.

Ważne uwagi:

# 1) Scenariusze testowe nie są produktami zewnętrznymi (nie są udostępniane analitykom biznesowym ani zespołom deweloperskim), ale są ważne dla wewnętrznej kontroli jakości. To nasz pierwszy krok w kierunku osiągnięcia 100% pokrycia testami. Po zakończeniu scenariusze testowe są poddawane wzajemnej ocenie, a po jej zakończeniu wszystkie są skonsolidowane.

domyślna brama nie jest dostępna poprawka systemu Windows 10

Więcej informacji o tym, jak sprawdzane są dokumenty z kontroli jakości, znajdziesz w artykule: Jak przeprowadzić przegląd dokumentacji testowej w 6 prostych krokach.

#dwa) Moglibyśmy użyć narzędzia do zarządzania testami, takiego jak HP ALM lub qTest do tworzenia scenariuszy testowych. Jednak tworzenie scenariuszy testowych w czasie rzeczywistym jest czynnością ręczną. Moim zdaniem wygodniej jest zrobić to ręcznie. Ponieważ jest to krok 1, nie musimy jeszcze wyciągać dużych dział. Najlepszym sposobem na to są proste arkusze Excela.

Następnym krokiem w tej serii jest to - będziemy pracować nad tworzeniem przypadków testowych i przejść dalej do fazy projektowania testów. Wcześniej zajmiemy się także - Co to jest planowanie testów?Gdzie pasuje do całego projektu kontroli jakości? Jak zawsze, pracuj z nami, aby uzyskać najlepsze wyniki.

Szkolenie QA, dzień 3: Jak napisać dokument SRS od podstaw.

Prosimy o dalsze pytania i komentarze. Doceniamy wasze czytelnictwo!

rekomendowane lektury

^