Kako ustvariti matriko sledljivosti zahtev (RTM): primer in vzorčna predloga

how create requirements traceability matrix

Kaj je zahteva matrika sledljivosti (RTM) pri testiranju programske opreme: vodnik po korakih za ustvarjanje matrice sledljivosti s primeri in vzorčno predlogo

Današnja vadnica govori o pomembnem orodju za nadzor kakovosti, ki je preveč poenostavljeno (branje prezrto) ali preveč poudarjeno - tj. Matrica sledljivosti (TM).

Najpogosteje izdelava, pregled ali izmenjava matrike sledljivosti ni eden od glavnih rezultatov procesa zagotavljanja kakovosti - zato ni v glavnem osredotočen na to, kar povzroča premalo poudarka. Nasprotno, nekatere stranke pričakujejo, da bo TM razkril zemeljske razsežnosti o svojem izdelku (v preskusu) in so razočarani.

'Če se uporablja pravilno, je matrika sledljivosti lahko vaš GPS za vaše QA potovanje'.

Kot je splošna praksa pri STH , v tem članku bomo videli vidike »Kaj« in »Kako«.

Kaj se boste naučili:

• Kaj je matrika sledljivosti zahtev?
  • Zakaj je potrebna sledljivost zahteve?
  • Vrste matrike sledljivosti
    • Sledljivost naprej
    • Sledljivost nazaj
    • Dvosmerna sledljivost
  • Primeri RTM
• Preizkusite pokritost in sledljivost zahtev
  • Kaj je testna pokritost?
  • Vrste specifikacij zahtev
    • # 1) Poslovne zahteve
    • # 2) Dokument s specifikacijami zahtev za programsko opremo (SRS)
    • # 3) Dokumenti projektne dokumentacije (PRD)
    • # 4) Uporabite dokument o primeru
    • # 5) Dokument o preverjanju napak
    • # 6) Zgodbe uporabnikov
  • Izzivi za zbiranje zahtev
  • Kako lahko pomaga sledljivost zahtev
  • Prednosti RTM in testne pokritosti
  • Izzivi v testni pokritosti
• Kako ustvariti matriko sledljivosti zahtev
  • Pomembne točke, ki jih je treba upoštevati
  • Zaključek
  • Priporočeno branje

Kaj je matrika sledljivosti zahtev?

V Matriki sledljivosti zahtev ali RTM smo vzpostavili postopek dokumentiranja povezav med uporabniškimi zahtevami, ki jih je predlagal odjemalec, do sistema, ki se gradi. Skratka, dokument na visoki ravni za preslikavo in sledenje uporabniškim zahtevam s testnimi primeri zagotavlja, da je za vsako zahtevo dosežena ustrezna raven testiranja.

Postopek pregleda vseh testnih primerov, ki so opredeljeni za katero koli zahtevo, se imenuje sledljivost. Sledljivost nam omogoča, da ugotovimo, katere zahteve so med testnim postopkom povzročile največ napak.

Poudarek vsakega preizkusnega dela je in bi moral biti največja pokritost s preskusi. S pokritostjo preprosto pomeni, da moramo preizkusiti vse, kar je treba preizkusiti. Cilj katerega koli preskusnega projekta mora biti 100% pokritost s preskusi.

Matrica sledljivosti zahtev vzpostavlja način, kako zagotoviti, da preverjamo vidik pokritosti. Pomaga pri ustvarjanju posnetka za prepoznavanje vrzeli v pokritosti. Skratka, za vsako zahtevo se lahko imenuje tudi metrika, ki določa število testnih primerov Run, Passed, Failed ali Blocked itd.

Zakaj je potrebna sledljivost zahteve?

Matrica sledljivosti zahtev pomaga pri povezovanju zahtev, Testni primeri , in napake natančno. Celotna aplikacija je preizkušena s sledljivostjo zahtev ( Preskušanje od konca do konca aplikacije).

s čim odpreti swf datoteke

Sledljivost zahtev zagotavlja dobro 'kakovost' aplikacije, saj so vse funkcije preizkušene. Nadzor kakovosti je mogoče doseči, ko se programska oprema preizkusi za nepredvidene scenarije z minimalnimi napakami in vse funkcionalne in nefunkcionalne zahteve so izpolnjene.

Matrica sledljivosti zahtev pripomočki za testiranje programske aplikacije v predpisanem časovnem obdobju, obseg projekta je natančno določen in njegovo izvajanje je doseženo v skladu z zahtevami in potrebami kupcev, stroški projekta pa so dobro nadzorovani.

Puščanje zaradi pomanjkljivosti je preprečeno, saj je celotna aplikacija preizkušena glede na njene zahteve.

Vrste matrike sledljivosti

Sledljivost naprej

V poglavju „Sledljivost naprej“ Zahteve za testne primere. Zagotavlja, da projekt napreduje v želeni smeri in da se vse zahteve temeljito preizkusijo.

Sledljivost nazaj

Testni primeri so preslikani z zahtevami v „Sledljivost nazaj“. Njegov glavni namen je zagotoviti, da je trenutni izdelek, ki se razvija, na pravi poti. Pomaga tudi ugotoviti, da se ne dodajo dodatne nedoločene funkcionalnosti in s tem vpliva na obseg projekta.

Dvosmerna sledljivost

(Naprej + nazaj): Matrika dobre sledljivosti vsebuje reference od testnih primerov do zahtev in obratno (zahteve za testne primere). To se imenuje „dvosmerna“ sledljivost. Zagotavlja, da je mogoče vse testne primere izslediti zahtevam, in vsaka določena zahteva ima natančne in veljavne testne primere zanje.

Primeri RTM

# 1) Poslovne zahteve

BR1 : Na voljo mora biti možnost pisanja e-pošte.

Preskusni scenarij (tehnična specifikacija) za BR1

TS1 : Na voljo je možnost sestavljanja pošte.

Testni primeri:

Testni primer 1 (TS1.TC1) : Možnost Sestavi pošto je omogočena in deluje uspešno.

Testni primer 2 (TS1.TC2) : Možnost sestavljanja pošte je onemogočena.

# 2) Napake

Po izvedbi testnih primerov, če se odkrijejo kakršne koli napake, ki jih je mogoče našteti in preslikati s poslovnimi zahtevami, testnimi scenariji in testnimi primeri.

Na primer, Če TS1.TC1 ne uspe, tj. Možnost »Sestavi pošto«, čeprav omogočena, ne deluje pravilno, se lahko zabeleži napaka. Recimo, da je samodejno ustvarjena ali ročno dodeljena številka ID napake D01, potem jo je mogoče preslikati s številkami BR1, TS1 in TS1.TC1.

Tako so lahko vse zahteve predstavljene v obliki tabele.

Preizkusite pokritost in sledljivost zahtev

Kaj je testna pokritost?

Test Coverage navaja, katere zahteve kupcev je treba preveriti, ko se začne testna faza. Test Coverage je izraz, ki določa, ali so testni primeri napisani in izvedeni, da se zagotovi popolno preizkušanje programske aplikacije na tak način, da se poročajo o minimalnih ali NIL napakah.

Kako doseči testno pokritost?

Največjo pokritost s preskusom je mogoče doseči z vzpostavitvijo dobre „sledljivosti zahtev“.

• Preslikava vseh notranjih napak na zasnovane testne primere
• Preslikava vseh napak, ki jih je prijavila stranka (CRD), v posamezne testne primere za prihodnji paket regresijskih testov

Vrste specifikacij zahtev

# 1) Poslovne zahteve

Dejanske zahteve strank so navedene v dokumentu, imenovanem Dokument o poslovnih zahtevah (BRS) . Ta BRS je podrobno izpeljan seznam zahtev na visoki ravni po kratki interakciji s stranko.

Običajno ga pripravijo „Poslovni analitiki“ ali projekt „Arhitekt“ (odvisno od organizacije ali strukture projekta). Dokument „Specifikacije zahtev za programsko opremo“ (SRS) izhaja iz BRS.

# 2) Dokument s specifikacijami zahtev za programsko opremo (SRS)

To je podroben dokument, ki vsebuje vse natančne podrobnosti o vseh funkcionalnih in nefunkcionalnih zahtevah. Ta SRS je osnova za načrtovanje in razvoj programskih aplikacij.

# 3) Dokumenti projektne dokumentacije (PRD)

PRD je referenčni dokument za vse člane ekipe v projektu, ki jim natančno pove, kaj naj izdelek naredi. Razdelimo ga lahko na oddelke, kot so Namen izdelka, Lastnosti izdelka, Merila za izdajo ter Predračun in časovni načrt projekta.

# 4) Uporabite dokument o primeru

To je dokument, ki pomaga pri oblikovanju in izvedbi programske opreme v skladu s poslovnimi potrebami. Načrtuje interakcije med igralcem in dogodkom z vlogo, ki jo je treba izvesti za dosego cilja. To je podroben podroben opis, kako je treba nalogo izvesti.

Na primer,

Igralec: Stranka

Vloga: Prenesite igro

Prenos igre je uspešen.

Primeri uporabe so lahko tudi del dokumenta SRS v skladu z delovnim procesom organizacije.

# 5) Dokument o preverjanju napak

Dokumentirano vsebuje vse podrobnosti v zvezi z napakami. Skupina lahko hrani dokument „Preverjanje napak“ za odpravljanje in ponovno testiranje napak. Preizkuševalci se lahko sklicujejo na dokument »Preverjanje napak«, ko želijo preveriti, ali so napake odpravljene ali ne, znova preizkusite napake v različnih OS, napravah, drugačni konfiguraciji sistema itd.

Dokument „Preverjanje napak“ je priročen in pomemben, kadar obstaja posebna faza odpravljanja in preverjanja napak.

# 6) Zgodbe uporabnikov

Zgodba uporabnika se v razvoju 'Agile' uporablja predvsem za opis programske funkcije z vidika končnega uporabnika. Zgodbe uporabnikov opredeljujejo vrste uporabnikov in na kakšen način ter zakaj želijo določeno funkcijo. Zahteva je poenostavljena z ustvarjanjem uporabniških zgodb.

Trenutno se vsa programska industrija premika k uporabi uporabniških zgodb in agilnega razvoja ter ustreznih programskih orodij za beleženje zahtev.

Izzivi za zbiranje zahtev

# 1) Zbrane zahteve morajo biti podrobne, nedvoumne, natančne in natančno določene. Ampak obstaja NE ustrezen ukrep za izračun teh podrobnosti, nedvoumnost, natančnost in natančno določene specifikacije, ki so potrebne za zbiranje zahtev.

#two) Razlaga „poslovnega analitika“ ali „lastnika izdelka“, ki zagotavlja informacije o zahtevah, je ključnega pomena. Podobno mora skupina, ki prejme informacije, ustrezno pojasniti, da bi razumela pričakovanja zainteresiranih strani.

Razumevanje mora biti sinhronizirano tako s poslovnimi potrebami kot z dejanskimi prizadevanji za izvajanje aplikacije.

# 3) Informacije je treba izpeljati tudi s stališča končnega uporabnika.

# 4) Stališča interesnih skupin v različnih obdobjih nasprotujejo ali nasprotujejo zahtevam.

# 5) Stališče končnega uporabnika se ne upošteva iz več razlogov in nadaljnje zainteresirane strani menijo, da 'popolnoma' razumejo, kaj je za izdelek potrebno, kar na splošno ni tako.

# 6) Razviti viri pomanjkanja znanj za uporabo.

# 7) Pogoste spremembe obsega aplikacije ali prednostne spremembe modulov.

# 8) Neodgovorjene, implicitne ali nedokumentirane zahteve.

# 9) Neskladne ali nejasne zahteve, ki jih določijo stranke.

# 10) Zaključek vseh zgoraj navedenih dejavnikov je, da je „uspeh“ ali „neuspeh“ projekta v veliki meri odvisen od zahteve.

Kako lahko pomaga sledljivost zahtev

# 1) Kje se izvaja zahteva?

Na primer,

Zahteva: V poštni aplikaciji implementirajte funkcijo »Sestavi pošto«.

Izvedba: Kjer je na glavni strani treba postaviti in dostopati do gumba »Sestavi pošto«.

# 2) Ali je potrebna zahteva?

Na primer,

Zahteva: Funkcijo »Sestavi pošto« uporabite v poštni aplikaciji samo za določene uporabnike.

Izvedba: Glede na pravice uporabniškega dostopa, če je e-poštni predal »Samo za branje«, v tem primeru gumb »Sestavi pošto« ne bo potreben.

# 3) Kako si razlagam zahtevo?

Na primer,

Zahteva: Funkcija »Sestavi pošto« v poštni aplikaciji s pisavami in prilogami.

Izvedba: Ko kliknete »Sestavi pošto«, katere vse funkcije naj bodo na voljo?

• Text Body za pisanje e-poštnih sporočil in urejanje z različnimi vrstami pisav, podčrtavanje pa tudi krepko, ležeče
• Vrste prilog (slike, dokumenti, druga e-poštna sporočila itd.)
• Velikost priponk (največja dovoljena velikost)

Tako se zahteve razčlenijo na podzahteve.

# 4) Katere odločitve o oblikovanju vplivajo na izvajanje zahteve?

Na primer,

Zahteva: Vsi elementi »Prejeto«, »Poslana pošta«, »Osnutki«, »Neželena pošta«, »Smetnjak« itd. Bi morali biti jasno vidni.

Izvedba: Elementi, ki bodo vidni, naj bodo prikazani v obliki 'Tree' ali 'Tab'.

# 5) Ali so dodeljene vse zahteve?

Na primer,

Zahteva: Na voljo je možnost pošiljanja smeti.

Izvedba: Če je bila zagotovljena možnost pošte »Smetnjak«, mora biti možnost (zahteva) »Izbriši« e-pošto na začetku implementirana in mora delovati natančno. Če možnost »Izbriši« e-pošto deluje pravilno, bodo v »Smetnjak« zbrana samo izbrisana e-poštna sporočila in izvajanje možnosti (zahteva) »Smetnjak« bo smiselno (koristno).

Prednosti RTM in testne pokritosti

# 1) Zgradba, razvita in preizkušena, ima zahtevano funkcionalnost, ki ustreza potrebam in pričakovanjem „kupcev“ / „uporabnikov“. Stranka mora dobiti tisto, kar želi. Presenetiti kupca z aplikacijo, ki ne naredi tega, kar se pričakuje, za nikogar ni zadovoljiva izkušnja.

#two) Končni izdelek (programska aplikacija), razvit in dostavljen kupcu, mora zajemati le tiste funkcije, ki so potrebne in pričakovane. Dodatne funkcije, ki so na voljo v programski aplikaciji, se lahko na začetku zdijo privlačne, dokler ni treba porabiti časa, denarja in truda za njen razvoj.

združi kodo razvrščanja v c ++ z rekurzijo

Dodatna funkcija lahko postane tudi vir napak, ki lahko stranki po namestitvi povzročijo težave.

# 3) Začetna naloga razvijalca se jasno opredeli, ko najprej dela na izvajanju zahtev, ki so prednostne glede na zahteve kupca. Če so zahteve stranke za visoko prioriteto jasno določene, potem je mogoče te komponente kode razviti in implementirati s prvo prioriteto.

Tako je zagotovljeno, da je verjetnost, da bo končni izdelek odposlan kupcu, v skladu z najvišjimi zahtevami in v skladu z roki.

# 4) Preizkuševalci najprej preverijo najpomembnejšo funkcionalnost, ki jo izvajajo razvijalci. Ker se najprej opravi preverjanje (testiranje) prednostne programske komponente, pomaga ugotoviti, kdaj in ali so prve različice sistema pripravljene na izdajo.

# 5) Natančni testni načrti, testni primeri so napisani in izvedeni, s čimer se preveri, ali so vse zahteve za uporabo pravilno izvedene. Preslikava testnih primerov z zahtevami pomaga zagotoviti, da se ne zamudijo večje napake. Nadalje pomaga pri uvajanju kakovostnega izdelka v skladu s pričakovanji kupcev.

# 6) V primeru, da odjemalec prejme zahtevo za spremembo, se spremenijo vse komponente aplikacije, na katere vpliva zahteva za spremembo, in ničesar ne spregledajo. To še poveča pri ocenjevanju vpliva vpliva zahteve za spremembo na programsko aplikacijo.

# 7) Na videz preprosta zahteva za spremembo lahko vključuje spremembe, ki jih je treba izvesti na več delih aplikacije. Bolje je, da ugotovite, koliko truda bo potrebno, preden se strinjate s spremembo.

Izzivi v testni pokritosti

# 1) Dober komunikacijski kanal

Če obstajajo spremembe, ki jih predlaga Zainteresirane strani , enako je treba sporočiti razvojnim in preskusnim skupinam v zgodnejših fazah razvoja. Brez tega pravočasno Razvoj, preizkušanje uporabe in odkrivanje / odpravljanje napak ni mogoče zagotoviti.

# 2) Pomembno je dati prednost preskusnim scenarijem

Težka naloga je ugotoviti, kateri prednostni, zapleteni in pomembni testni scenariji so. Poskušam preizkusiti vse Testni scenariji je skoraj nedosegljiva naloga. Cilj testiranja scenarijev mora biti s poslovnega vidika in vidika končnega uporabnika zelo jasen.

# 3) Izvajanje procesa

Postopek testiranja mora biti jasno opredeljen, upoštevajoč dejavnike, kot so tehnična infrastruktura in izvedbe, spretnosti ekipe, pretekle izkušnje, uporabljene organizacijske strukture in procesi, ocene projektov, povezane s stroški, časom in sredstvi ter lokacijo ekipe glede na časovne pasove.

Enotna izvedba postopka ob upoštevanju omenjenih dejavnikov zagotavlja, da je vsak posameznik, ki se ukvarja s projektom, na isti strani. To pomaga pri nemotenem toku vseh procesov, povezanih z razvojem aplikacij.

# 4) Razpoložljivost virov

Viri so dve vrsti, preizkuševalci za določene domene in orodja za preskušanje, ki jih uporabljajo preizkuševalci. Če preizkuševalci dobro poznajo domeno, lahko pišejo in izvajajo učinkovite testne scenarije in skripte. Za izvajanje teh scenarijev in skriptov bi morali biti preizkuševalci dobro opremljeni z ustreznimi „orodji za testiranje“.

Edino usposobljeni preizkuševalec in ustrezna orodja za testiranje lahko zagotovijo dobro izvedbo in pravočasno dostavo aplikacije stranki.

# 5) Učinkovito izvajanje strategije testiranja

' Testna strategija “je sama po sebi velika in ločena tema razprave. Ampak tukaj za „Test Coverage“ učinkovito izvajanje testne strategije zagotavlja, da „ Kakovost “ vloge je dobro in je vzdrževati v določenem časovnem obdobju povsod.

Učinkovita „testna strategija“ igra glavno vlogo pri vnaprejšnjem načrtovanju vseh vrst kritičnih izzivov, kar dodatno pomaga pri razvoju boljše aplikacije.

Kako ustvariti matriko sledljivosti zahtev

Da bi bili z nami, moramo natančno vedeti, kaj je tisto, kar je treba izslediti ali izslediti.

Preizkuševalci začnejo pisati svoje testne scenarije / cilje in sčasoma testne primere na podlagi nekaterih vhodnih dokumentov - Dokument o poslovnih zahtevah, Dokument o funkcionalnih specifikacijah in tehnični projektni dokument (neobvezno).

Recimo, da je naš dokument o poslovnih zahtevah (BRD): ( Prenesite ta vzorec BRD v formatu excel )

(Za povečavo kliknite katero koli sliko)

Spodaj je naš dokument o funkcionalnih specifikacijah (FSD), ki temelji na razlagi dokumenta o poslovnih zahtevah (BRD) in njegovem prilagajanju računalniškim aplikacijam. V idealnem primeru bi bilo treba v BRD obravnavati vse vidike FSD. Toda zaradi poenostavitve sem uporabil samo točki 1 in 2.

Vzorec FSD od zgoraj BRD: ( Prenesite ta vzorec FSD v formatu excel )

Opomba : Skupine za zagotavljanje kakovosti BRD in FSD ne dokumentirajo. Smo zgolj potrošniki dokumentov skupaj z drugimi projektnimi skupinami.

Na podlagi zgornjih dveh vhodnih dokumentov smo kot skupina za preverjanje kakovosti pripravili spodnji seznam scenarijev na visoki ravni, ki jih lahko preizkusimo.

Vzorčni scenariji preizkusov zgoraj BRD in FSD: ( Prenesite to datoteko z vzorčnimi testnimi scenariji )

Ko prispemo sem, bi bil zdaj pravi čas, da začnemo ustvarjati matriko sledljivosti zahtev.

Osebno imam raje zelo preprost excel list s stolpci za vsak dokument, ki mu želimo slediti. Ker poslovne zahteve in funkcionalne zahteve niso oštevilčene enolično, bomo za sledenje uporabili številke odsekov v dokumentu.

(Lahko se odločite za sledenje na podlagi številk vrstic ali številk z označenimi točkami itd., Odvisno od tega, kaj je za vaš primer najbolj smiselno.)

Evo, kako bi za naš primer izgledala preprosta matrika sledljivosti:

Zgornji dokument vzpostavlja sled med BRD do FSD in sčasoma do testnih scenarijev. Z ustvarjanjem takšnega dokumenta lahko zagotovimo, da je preskusna skupina upoštevala vse vidike začetnih zahtev pri ustvarjanju svojih testnih zbirk.

Lahko pustiš tako. Da pa bi bil bolj berljiv, raje vključim imena odsekov. To bo izboljšalo razumevanje, če ta dokument delite s stranko ali katero koli drugo skupino.

Rezultat je naslednji:

Še enkrat, izbira za uporabo prejšnje ali novejše oblike je vaša.

To je predhodna različica vašega TM, vendar na splošno ne služi svojemu namenu, ko se ustavite tukaj. Če ga ekstrapolirate do napak, lahko izkoristite največ koristi.

Poglejmo, kako.

Za vsak preizkusni scenarij, ki ste ga pripravili, boste imeli vsaj 1 ali več testnih primerov. Torej, ko pridete tja, vključite še en stolpec in napišite ID-jev testnih primerov, kot je prikazano spodaj:

Na tej stopnji lahko matrico sledljivosti uporabimo za iskanje vrzeli. Na primer, v zgornji matriki sledljivosti vidite, da za oddelek 1.2 FSD ni napisanih testnih primerov.

kako napisati testne primere za spletno aplikacijo

Praviloma so morebitna prazna mesta v matriki sledljivosti potencialna področja za preiskavo. Takšna vrzel lahko pomeni eno od dveh stvari:

• Testna skupina je nekako zamudila razmislek o funkciji 'Obstoječi uporabnik'.
• Funkcionalnost »Obstoječi uporabnik« je bila preložena na poznejšo uporabo ali odstranjena iz zahtev glede funkcionalnosti aplikacije. V tem primeru TM pokaže neskladnost v FSD ali BRD - kar pomeni, da je treba opraviti posodobitev dokumentov FSD in / ali BRD.

Če gre za scenarij 1, bodo navedeni kraji, kjer mora testna skupina še nekaj delati, da zagotovi 100-odstotno pokritost.

V scenarijih 2 TM ne prikazuje samo vrzeli, temveč kaže na napačno dokumentacijo, ki jo je treba takoj popraviti.

Zdaj razširimo TM, da vključimo stanje izvrševanja testnega primera in napake.

Spodnja različica matrike sledljivosti je običajno pripravljena med ali po izvedbi testa:

Prenesite predlogo matrike sledljivosti zahtev:

=> Predloga matrike sledljivosti v obliki zapisa Excel

Pomembne točke, ki jih je treba upoštevati

Spodaj so pomembna opozorila o tej različici matrike sledljivosti:

# 1) Prikaže se tudi stanje izvedbe. Med izvajanjem poda konsolidiran posnetek napredovanja dela.

# 2) Napake: Ko se ta stolpec uporablja za ugotavljanje sledljivosti nazaj, lahko ugotovimo, da je funkcionalnost »Novi uporabnik« najbolj pomanjkljiva. Namesto da bi poročal, da so takšni in drugačni testni primeri neuspešni, TM zagotavlja preglednost nazaj k poslovni zahtevi, ki ima največ napak, s čimer prikazuje kakovost v smislu, kaj stranka želi.

# 3) Kot nadaljnji korak lahko ID napake barvno označite tako, da predstavlja njihova stanja. Na primer, ID napake v rdeči lahko pomeni, da je še vedno odprt, v zeleni pa lahko pomeni, da je zaprt. Ko je to storjeno, TM deluje, ko je poročilo o zdravstvenem pregledu, ki prikazuje stanje napak, ki ustrezajo določeni funkciji BRD ali FSD, odprto ali zaprto.

# 4) Če obstaja tehnični projektni dokument ali primeri uporabe ali kateri koli drugi predmeti, ki bi jim radi sledili, lahko zgoraj ustvarjeni dokument vedno razširite tako, da ustreza vašim potrebam, tako da dodate dodatne stolpce.

Če povzamem, RTM pomaga pri:

• Zagotavljanje 100% pokritosti s testom
• Prikaz neskladnosti zahtev / dokumentov
• Prikaz splošnega stanja okvare / izvedbe s poudarkom na poslovnih zahtevah.
• Če bi se določena poslovna in / ali funkcionalna zahteva spremenila, TM pomaga oceniti ali analizirati vpliv na delo skupine za preverjanje kakovosti v smislu ponovnega obiska / predelave testnih primerov.

Poleg tega

• Matrica sledljivosti ni posebno orodje za ročno preskušanje, temveč se lahko uporablja tudi za projekte avtomatizacije. Za projekt avtomatizacije lahko ID testnega primera označuje ime skripta Automation Test.
• Prav tako ni orodje, ki bi ga lahko uporabljale samo kontrole kakovosti. Razvojna skupina lahko isto uporabi za preslikavo zahtev BRD / FSD v bloke / enote / pogoje kode, ustvarjene za zagotovitev, da so razvite vse zahteve.
• Orodja za upravljanje testov, kot so HP ALM prihajajo z vgrajeno funkcijo sledljivosti.

Pomembno je omeniti tonačin, kako vzdržujete in posodabljate svojo matriko sledljivosti, določa učinkovitost njene uporabe. Če se orodje ne posodablja pogosto ali se napačno posodablja, je breme, namesto da bi bilo v pomoč in ustvarja vtis, da orodje samo po sebi ni vredno uporabe.

Zaključek

Matrica sledljivosti zahtev je sredstvo za zemljevid in sled vse zahteve stranke s testnimi primeri in odkritimi napakami. Je en dokument ki služi glavnemu namenu, da ne zamudimo nobenega testnega primera in s tem zajamemo in preizkusimo vse funkcionalnosti aplikacije.

Dobra „pokritost s preizkusi“, ki je načrtovana predčasno, preprečuje ponavljajoče se naloge v fazah testiranja in uhajanja okvar. Veliko število napak pomeni, da je bilo testiranje opravljeno dobro in s tem narašča 'Kakovost' aplikacije. Podobno zelo majhno število napak pomeni, da testiranje ni bilo opravljeno do oznake, kar negativno ovira 'kakovost' aplikacije.

Če je pokritost s testom opravljena temeljito, je lahko nizko število napak upravičeno in to število napak se lahko šteje kot podporna statistika in ne kot primarna. Kakovost aplikacije se imenuje „dobra“ ali „zadovoljiva“, ko je testna pokritost največja in število napak zmanjšano.

O avtorju: Članica ekipe STH Urmila P. je izkušena strokovnjakinja za kakovost visoka kvaliteta preizkus in spretnosti sledenja.

Ste v svojih projektih ustvarili matriko sledljivosti zahtev? Kako podoben ali drugačen je od tega, kar smo ustvarili v tem članku? S svojimi komentarji delite svoje izkušnje, komentarje, misli in povratne informacije o tem članku.

Priporočeno branje

• Vzorčna predloga načrta preizkusa programske opreme z obliko in vsebino
• Kako napisati učinkovito poročilo o preizkusu (prenos vzorčnega poročila)
• Vzorčna predloga testnega primera s primeri testnega primera (prenos)
• Vzorčna predloga za poročilo o preizkusu sprejemljivosti s primeri
• Kako napisati testni dokument strategije (z vzorčno predlogo preizkusne strategije)
• Kako preizkusiti specifikacijo zahtev za programsko opremo (SRS)?
• Top 20+ najboljših orodij za upravljanje zahtev (popoln seznam)
• Kontrolni seznami za testiranje programske opreme QA (vključeni so vzorčni kontrolni seznami)