Tko je odgovoran za matricu sljedivosti zahtjeva?

Primarna odgovornost za održavanje RTM-a obično leži na QA timu ili testerima. Međutim, poslovni analitičari definiraju zahtjeve, programeri povezuju kod s tim zahtjevima, a voditelji projekata nadziru točnost. U praksi, RTM je zajednička odgovornost među timovima, osiguravajući da se zahtjevi prate i validiraju u svakoj fazi.

Koristi li se RTM u Agileu?

Da, RTM se široko koristi u agilnim projektima. Umjesto formalnih SRS dokumenata, zahtjevi često dolaze iz korisničkih priča ili zaostataka proizvoda. Agilni timovi mapiraju te priče na testne slučajeve u RTM-u, osiguravajući da je svaka priča validirana. Dobro se prilagođava iterativnoj prirodi Agilea uz održavanje potpune pokrivenosti.

Što je matrica sljedivosti zahtjeva (RTM) u testiranju?

⚡ Pametni sažetak

Matrica sljedivosti zahtjeva (RTM) je strukturirani dokument koji povezuje zahtjeve projekta s njihovim odgovarajućim testnim slučajevima, osiguravajući potpunu pokrivenost i validaciju. Igra ključnu ulogu u testiranju softvera sprječavanjem propuštenih funkcionalnosti, podržavanjem usklađenosti i pružanjem vidljivosti među dionicima.

Započnite RTM rano u životnom ciklusu projekta kako biste osigurali potpunu usklađenost sa zahtjevima.
Redovito ažurirajte matricu kad god se promijene zahtjevi ili testni slučajevi.
Koristite jasne, jedinstvene ID-ove za učinkovito mapiranje zahtjeva, scenarija i testnih slučajeva.
Surađujte s testerima, programerima, analitičarima i menadžerima radi zajedničke odgovornosti.
Iskoristite alate za automatizaciju (npr. Jira, Zephyr) kako biste smanjili ručni rad i poboljšali skalabilnost.

Opširnije

Što je Matrica sljedivosti (TM)?

Matrica sljedivosti je dokument koji povezuje bilo koja dva osnovna dokumenta koja zahtijevaju odnos "mnogo-prema-mnogo" kako bi se provjerila potpunost odnosa.

Koristi se za praćenje zahtjeva i provjeru jesu li ispunjeni trenutni zahtjevi projekta.

Što je matrica sljedivosti zahtjeva?

Matrica sljedivosti zahtjeva (RTM) je dokument koji mapira i prati korisničke zahtjeve s testnim slučajevima. Zabilježava sve zahtjeve koje je predložio klijent i sljedivost zahtjeva u jednom dokumentu, isporučenom na kraju Životni ciklus razvoja softveraGlavna svrha Matrice sljedivosti zahtjeva je potvrditi da su svi zahtjevi provjereni putem testnih slučajeva, tako da nijedna funkcionalnost nije neprovjerena tijekom testiranja softvera.

Zašto je RTM važan?

Glavni cilj svakog testera trebao bi biti razumijevanje zahtjeva klijenta i osiguranje da je izlazni proizvod bez grešaka. Kako bi se postigao taj cilj, svaki QA stručnjak trebao bi temeljito razumjeti zahtjeve i stvoriti pozitivne i negativne testne slučajeve.

To bi značilo da se softverski zahtjevi koje je dostavio klijent moraju dalje podijeliti u različite scenarije i dalje u testne slučajeve. Svaki od ovih slučajeva mora se izvršiti pojedinačno.

Ovdje se postavlja pitanje kako osigurati da je zahtjev testiran, uzimajući u obzir sve moguće scenarije/slučajeve? Kako osigurati da nijedan zahtjev ne bude izostavljen iz ciklusa testiranja?

Jednostavan način je pratiti zahtjev s njegovim odgovarajućim testnim scenarijima i test slučajeviTo se naziva 'Matrica sljedivosti zahtjeva'.

Matrica sljedivosti je obično radni list koji sadrži zahtjeve sa svim mogućim testni scenariji i slučajeve i njihovo trenutno stanje, tj. jesu li prošli ili nisu. To bi pomoglo timu za testiranje da razumije razinu aktivnosti testiranja provedenih za određeni proizvod.

Kome treba RTM?

A Matrica sljedivosti zahtjeva (RTM) nije samo za testere - vrijedan je za sve koji su uključeni u isporuku visokokvalitetnog softvera ili projekata.

QA i testeri → Osigurajte 100%-tnu pokrivenost zahtjeva dobro mapiranim testnim slučajevima.
Poslovni analitičari → Pratite zahtjeve iz SRS-a/Korisničkih priča kroz izvršenje.
Voditelji projekata → Steknite uvid u opseg, napredak i propuštene zahtjeve.
Developeri → Razumjeti kako se značajke povezuju s poslovnim ciljevima.
Regulirane industrije (Zdravstvo, Automobilska industrija, Zrakoplovstvo, Financije) → Dokažite usklađenost i prođite revizije s jasnom sljedivošću.
Klijenti i zainteresirane strane → Dobijte uvjeravanje da su njihovi zahtjevi implementirani i testirani.

👉 Ukratko, svatko tko je odgovoran za izgradnja, validacija ili odobravanje softverskih zahtjeva koristi od RTM-a.

Koje parametre uključiti u matricu sljedivosti zahtjeva?

ID zahtjeva
Vrsta zahtjeva i Description
Testni slučajevi sa statusom

Gore je primjer matrice sljedivosti zahtjeva.

Ali u tipičnom testiranje softvera projekta, matrica sljedivosti imala bi više od ovih parametara.

Kao što je gore ilustrirano, matrica sljedivosti zahtjeva može:

Prikažite pokrivenost zahtjeva u broju testnih slučajeva
Status dizajna kao i status izvršenja za određeni testni slučaj
Ako postoje testovi prihvatljivosti korisnika koje korisnici trebaju provesti, tada se UAT status također može uhvatiti u istoj matrici.
Povezani nedostaci i trenutno stanje također se mogu spomenuti u istoj matrici.

Ova vrsta matrice bi pružila Sve na jednom mjestu za sve aktivnosti testiranja.

Osim zasebnog održavanja Excela, tim za testiranje može se odlučiti i za praćenje zahtjeva dostupno u alatima za upravljanje testiranjem.

Vrste matrice testa sljedivosti

U softverskom inženjerstvu, matrica sljedivosti može se podijeliti na tri glavne komponente kao što je navedeno u nastavku:

Mogućnost sljedivosti: Ova se matrica koristi za provjeru napreduje li projekt u željenom smjeru i za pravi proizvod. Osigurava da se svaki zahtjev primjenjuje na proizvod i da se svaki zahtjev temeljito testira. Preslikava zahtjeve u testne slučajeve.
Sljedivost unatrag ili obrnuto: Koristi se kako bi se osiguralo da trenutni proizvod ostaje na pravom putu. Svrha ove vrste sljedivosti je provjeriti da ne proširujemo opseg projekta dodavanjem koda, elemenata dizajna, testiranja ili drugog rada koji nije naveden u zahtjevima. Preslikava testne slučajeve na zahtjeve.
Dvosmjerna sljedivost (naprijed+natrag): Ova matrica sljedivosti osigurava da testni slučajevi pokrivaju sve zahtjeve. Analizira utjecaj promjene zahtjeva na koje utječe Mana u proizvodu rada i obrnuto.

Kako stvoriti matricu sljedivosti zahtjeva

Razumimo koncept matrice sljedivosti zahtjeva kroz bankarski projekt Guru99.

Temeljem dokument o poslovnim zahtjevima (BRD) i Dokument tehničkih zahtjeva (TRD), testeri počinju pisati testne slučajeve.

Pretpostavimo da je sljedeća tablica naš Dokument poslovnih zahtjeva ili BRD za Guru99 bankarski projekt.

U ovom slučaju, klijent bi se trebao moći prijaviti na Guru99 bankarsku web stranicu s ispravnom lozinkom i korisničkim imenom, dok bi se menadžer trebao moći prijaviti na web stranicu putem stranice za prijavu korisnika.

Donja tablica je naša Dokument tehničkih zahtjeva (TRD).

Bilješka: QA timovi ne dokumentiraju BRD i TRD. Također, neke tvrtke koriste Dokumenti o zahtjevima za funkciju (FRD), koji su slični Dokumentima s tehničkim zahtjevima, ali proces izrade Matrice sljedivosti ostaje isti.

Krenimo naprijed i stvorimo RTM u testiranju

Korak 1) Naši uzorak testnog slučaja is

„Potvrdi prijavu: Kada se unesu ispravan ID i lozinka, prijava bi se trebala uspješno izvršiti.“

Korak 2) Odredite tehnički zahtjev koji ovaj testni slučaj provjerava. Za naš testni slučaj, provjerava se tehnički zahtjev T94.

Korak 3) Zabilježite ovaj tehnički zahtjev (T94) u testnom slučaju.

Korak 4) Identificirajte poslovni zahtjev za koji je definiran ovaj TR (Tehnički zahtjev-T94)

Korak 5) Obratite pažnju na BR (poslovni zahtjev) u testnom slučaju

Korak 6) Učinite gore navedeno za sve testne slučajeve. LaterIzdvojite prva 3 stupca iz svog testnog paketa. RTM u testiranju je spreman!

Prednosti matrice sljedivosti zahtjeva

Potvrđuje 100% pokrivenost testom
Naglašava sve zahtjeve koji nedostaju ili nedosljednosti u dokumentu
Prikazuje ukupne nedostatke ili status izvršenja s fokusom na poslovne zahtjeve
Pomaže u analizi ili procjeni utjecaja na rad QA tima u pogledu ponovnog pregledavanja ili prerade testnih slučajeva.

Najbolje prakse i savjeti za korištenje RTM-a

Matrica sljedivosti zahtjeva (RTM) je najučinkovitija kada je jednostavan, dosljedan i redovito ažuriranEvo najboljih praksi koje će timovima omogućiti da osiguraju potpuna pokrivenost, minimalne prerade i povećano povjerenje u isporuku projekta:

Počnite rano → Izradite svoj RTM na samom početku projekta.
Držite ga ažuriranim → Ažurirajte matricu kad god se promijene zahtjevi ili testni slučajevi.
Koristite jasne ID-ove → Dodijelite jedinstvene ID-ove zahtjevima i testnim slučajevima radi lakšeg praćenja.
Pokrijte pozitivne i negativne slučajeve → Osigurajte da je svaki zahtjev validiran iz više kutova testiranja.
Surađujte među timovima → U održavanje RTM-a uključite testere, razvojne inženjere, poslovno asistentne stručnjake i voditelje projekata.
Iskoristite alate → Umjesto proračunskih tablica, razmislite o alatima za upravljanje testiranjem (poput Jire, HP ALM-a ili Zephyra) radi skalabilnosti.
Kontrola verzije → Čuvajte povijesne verzije kako biste pratili promjene i održali usklađenost.
Usredotočite se na jednostavnost → Izbjegavajte preopterećenje matrice; istaknite samo bitne parametre.
Revizija redovito → Povremeno pregledajte RTM kako biste uočili nedostatke prije rokova testiranja.
Poveznica s poslovnom vrijednošću → Povežite zahtjeve s poslovnim ciljevima kako biste prikazali povrat ulaganja.

Uobičajeni RTM izazovi i rješenja

Izazov: Održavanje ažuriranosti RTM-a
Zahtjevi i testni slučajevi se često mijenjaju, što RTM brzo čini zastarjelim.
Rješenje: Koristite automatizirane alate za upravljanje testiranjem koji sinkroniziraju zahtjeve, testne slučajeve i nedostatke u stvarnom vremenu.
Izazov: Prekomjerna složenost
Dodavanje previše parametara otežava održavanje i interpretaciju RTM-a.
Rješenje: Održavajte RTM elegantan fokusirajući se samo na bitna polja kao što su ID-ovi, opisi i status.
Izazov: Loša timska suradnja
Različiti timovi se možda neće slagati oko vlasništva ili ažuriranja.
Rješenje: Definirajte jasne uloge, uključite testere, razvojne programere i analitičare te zakažite redovite RTM preglede.
Izazov: Nepotpuno pokrivanje zahtjeva
Nekim zahtjevima mogu nedostajati testni slučajevi, što dovodi do propuštene funkcionalnosti.
Rješenje: Redovito provjeravajte pokrivenost, koristite dvosmjernu sljedivost i provodite revizije prije glavnih izdanja.
Izazov: Ručni rad u velikim projektima
Upravljanje RTM-om u proračunskim tablicama postaje dugotrajno za složene sustave.
Rješenje: Usvojite RTM alate poput Jire, HP ALM ili Zephyr-a za automatizaciju mapiranja i izvještavanja.

Naučimo RTM na primjeru u videu

Kliknite ovdje ako video nije dostupan

Predložak matrice sljedivosti zahtjeva (RTM).

Kliknite dolje za preuzimanje RTM predloška u Excelu

Preuzmite RTM predložak Excel(.xlsx)

Pitanja i odgovori:

RTM se koristi kako bi se osiguralo da je svaki zahtjev projekta povezan s odgovarajućim testnim slučajevima. Pomaže u provjeri potpune pokrivenosti, praćenju promjena, smanjenju nedostataka i pružanju dokaza o validaciji. Mapiranjem zahtjeva na testove, RTM poboljšava osiguranje kvalitete, usklađenost i povjerenje dionika tijekom cijelog životnog ciklusa razvoja.

Postoje tri glavne vrste RTM-a: Sljedivost unaprijed (mapira zahtjeve na testne slučajeve), Sljedivost unatrag (preslikava testne slučajeve natrag u zahtjeve) i Dvosmjerna sljedivost (kombinira oba smjera). Zajedno, ovi pristupi osiguravaju potpunu pokrivenost, sprječavaju nepotrebno proširenje opsega i potvrđuju da su svi zahtjevi temeljito testirani.

Matrica sljedivosti zahtjeva obično se priprema rano u projektu, nakon što su zahtjevi dokumentirani u SRS-u, BRD-u ili zaostatku. Razvija se tijekom životnog ciklusa, ažurirajući se kad god se zahtjevi ili testni slučajevi promijene. Rana priprema RTM-a osigurava usklađenost, minimizira propuštenu funkcionalnost i podržava učinkovito planiranje testiranja i analizu pokrivenosti.

Primarna odgovornost za održavanje RTM-a obično leži na Tim za osiguranje kvalitete or testera. Međutim, poslovni analitičari definirati zahtjeve, programeri povezati kod s tim zahtjevima i voditelji projekta nadzirati točnost. U praksi, RTM je zajednička odgovornost među timovima, osiguravajući da se zahtjevi prate i validiraju u svakoj fazi.

Za korištenje RTM-a, navedite zahtjeve projekta uz njihove odgovarajuće testne slučajeve. Pratite status izvršenja, nedostatke i pokrivenost. Timovi ga koriste za provjeru jesu li zahtjevi testirani, identificiranje nedostataka i procjenu utjecaja promjena. Postaje živi dokument koji pruža vidljivost i kontrolu tijekom testiranja i životnog ciklusa projekta.

Da, RTM se široko koristi u agilnim projektima. Umjesto formalnih SRS dokumenata, zahtjevi često dolaze iz korisničke priče or zaostatci proizvodaAgilni timovi mapiraju ove priče u testne slučajeve u RTM-u, osiguravajući da je svaka priča validirana. Dobro se prilagođava iterativnoj prirodi Agilea uz održavanje potpune pokrivenosti.

Da, RTM se može automatizirati pomoću alata za upravljanje testiranjem kao što su Jira, HP ALM ili ZephyrAutomatizacija smanjuje ručni napor, osigurava ažuriranja u stvarnom vremenu i pruža bolju sljedivost zahtjeva, testnih slučajeva i nedostataka. Automatizirani RTM-ovi posebno su korisni u velikim ili reguliranim projektima gdje su usklađenost i spremnost za reviziju ključni.

RTM i RACI služe različitim svrhama. RTM prati zahtjeve i testne slučajeve kako bi se osigurala pokrivenost i validacija. RACI je matrica dodjele odgovornosti koja pokazuje tko je odgovoran, tko je odgovoran, tko je konzultiran i tko je informiran u projektu. RTM se fokusira na zahtjeve i testiranje, dok RACI pojašnjava uloge i odgovornosti tima.