Co to jest macierz śledzenia wymagań (RTM)? Przykładowy szablon

Co to jest macierz identyfikowalności? (TM)

Macierz identyfikowalności to dokument, który jest powiązany z dowolnymi dokumentami z dwoma podstawami, które wymagają relacji wiele do wielu w celu sprawdzenia kompletności relacji.

Służy do śledzenia wymagań i sprawdzania, czy aktualne wymagania projektu są spełnione.

Co to jest macierz śledzenia wymagań?

Macierz śledzenia wymagań (RTM) to dokument, który odwzorowuje i śledzi wymagania użytkownika w przypadkach testowych. Przechwytuje wszystkie wymagania zaproponowane przez klienta i identyfikowalność wymagań w jednym dokumencie, dostarczanym po zakończeniu cyklu życia oprogramowania. Głównym celem macierzy śledzenia wymagań jest sprawdzenie, czy wszystkie wymagania są sprawdzane za pomocą przypadków testowych, tak aby podczas testowania oprogramowania żadna funkcjonalność nie została odznaczona.

W tym samouczku dowiesz się więcej o:

Dlaczego RTM jest ważny?
Jakie parametry uwzględnić w macierzy śledzenia wymagań?
Rodzaje macierzy testów identyfikowalności
Jak stworzyć macierz śledzenia wymagań
Zaleta macierzy śledzenia wymagań
Szablon macierzy śledzenia wymagań (RTM)

Dlaczego RTM jest ważny?

Głównym celem każdego testera powinno być zrozumienie wymagań klienta i upewnienie się, że produkt wyjściowy powinien być wolny od wad. Aby osiągnąć ten cel, każdy zespół zapewniający jakość powinien dokładnie rozumieć wymagania i tworzyć pozytywne i negatywne przypadki testowe.

Oznaczałoby to, że wymagania oprogramowania dostarczone przez klienta musiałyby być dalej podzielone na różne scenariusze i dalej na przypadki testowe. Każda z tych spraw musi być wykonana indywidualnie.

Pojawia się tutaj pytanie, jak upewnić się, że wymaganie jest testowane, biorąc pod uwagę wszystkie możliwe scenariusze / przypadki? Jak zapewnić, że żadne wymaganie nie zostanie pominięte w cyklu testowym?

Prostym sposobem jest prześledzenie wymagania za pomocą odpowiadających mu scenariuszy testowych i przypadków testowych. Jest to po prostu określane jako „macierz śledzenia wymagań”.

Macierz identyfikowalności jest zwykle arkuszem roboczym, który zawiera wymagania wraz ze wszystkimi możliwymi scenariuszami i przypadkami testowymi oraz ich aktualnym stanem, tj. Czy zostały zaliczone lub nie. Pomogłoby to zespołowi testującemu w zrozumieniu poziomu czynności testowych wykonywanych dla określonego produktu.

Jakie parametry uwzględnić w macierzy śledzenia wymagań?

Identyfikator wymagania
Typ i opis wymagania
Przypadki testowe ze statusem

Powyżej znajduje się przykładowa macierz identyfikowalności wymagań.

Ale w typowym projekcie testowania oprogramowania macierz identyfikowalności miałaby więcej niż te parametry.

Jak pokazano powyżej, macierz identyfikowalności wymagań może:

Pokaż pokrycie wymagań w liczbie przypadków testowych
Status projektu, a także status wykonania dla konkretnego przypadku testowego
Jeśli użytkownicy mają wykonać jakikolwiek test akceptacji użytkownika, status UAT można również zarejestrować w tej samej macierzy.
W tej samej macierzy można również wspomnieć o powiązanych defektach i aktualnym stanie.

Ten rodzaj matrycy byłoby zapewnienie One Stop Shop dla wszystkich działań testowych.

Oprócz oddzielnego utrzymywania Excela. Zespół testujący może również zdecydować się na śledzenie wymagań w dostępnych narzędziach do zarządzania testami.

Rodzaje macierzy testów identyfikowalności

W inżynierii oprogramowania macierz identyfikowalności można podzielić na trzy główne komponenty, jak wspomniano poniżej:

Identyfikowalność w przód : ta macierz służy do sprawdzania, czy projekt postępuje w pożądanym kierunku i dla właściwego produktu. Zapewnia, że każde wymaganie jest zastosowane do produktu i że każde wymaganie jest dokładnie testowane. Mapuje wymagania do przypadków testowych.
Identyfikowalność wsteczna lub wsteczna: służy do zapewnienia, czy bieżący produkt pozostaje na właściwym torze. Celem tego typu identyfikowalności jest sprawdzenie, czy nie rozszerzamy zakresu projektu o kod, elementy projektu, testy lub inne prace, które nie są określone w wymaganiach. Mapuje przypadki testowe do wymagań.
Śledzenie dwukierunkowe (do przodu + do tyłu): ta macierz identyfikowalności zapewnia, że wszystkie wymagania są objęte przypadkami testowymi. Analizuje wpływ zmiany wymagań, na które ma wpływ Wada w produkcie pracy i odwrotnie.

Jak stworzyć macierz śledzenia wymagań

Zrozummy koncepcję macierzy śledzenia wymagań poprzez projekt bankowy Guru99.

Na podstawie Dokumentu Wymagań Biznesowych (BRD) i Dokumentu Wymagań Technicznych (TRD) testerzy rozpoczynają pisanie przypadków testowych.

Załóżmy, że poniższa tabela to nasz dokument wymagań biznesowych lub projekt bankowy BRD dla Guru99 .

Tutaj scenariusz jest taki, że klient powinien być w stanie zalogować się do witryny bankowej Guru99 z poprawnym hasłem i identyfikatorem użytkownika, podczas gdy menedżer powinien mieć możliwość zalogowania się do witryny za pośrednictwem strony logowania klienta.

Podczas gdy poniższa tabela to nasz dokument wymagań technicznych (TRD) .

Uwaga: zespoły kontroli jakości nie dokumentują BRD i TRD. Ponadto niektóre firmy używają dokumentów wymagań funkcjonalnych (FRD), które są podobne do dokumentów wymagań technicznych, ale proces tworzenia macierzy identyfikowalności pozostaje taki sam.

Let's Go Ahead i stwórz RTM w testowaniu

Krok 1: Nasz przykładowy przypadek testowy to

„Zweryfikuj login, po wprowadzeniu prawidłowego identyfikatora i hasła powinno się pomyślnie zalogować”

Krok 2 : Zidentyfikuj wymagania techniczne, które weryfikuje ten przypadek testowy. W naszym przypadku testowym weryfikowane jest wymaganie techniczne T94.

Krok 3: Zanotuj to wymaganie techniczne (T94) w przypadku testowym.

Krok 4: Zidentyfikuj wymaganie biznesowe, dla którego zdefiniowano niniejsze TR (wymaganie techniczne-T94)

Krok 5: Zanotuj BR (wymóg biznesowy) w przypadku testowym

Krok 6: Zrób powyższe dla wszystkich przypadków testowych. Później wyodrębnij pierwsze 3 kolumny z zestawu testów. RTM w testach jest gotowy!

Zaleta macierzy śledzenia wymagań

Potwierdza 100% pokrycie testu
Podkreśla wszelkie brakujące wymagania lub niespójności dokumentów
Pokazuje ogólny stan defektów lub stanu wykonania, ze szczególnym uwzględnieniem wymagań biznesowych
Pomaga w analizowaniu lub szacowaniu wpływu na pracę zespołu QA w zakresie ponownego odwiedzania lub ponownego opracowywania przypadków testowych