how create requirements traceability matrix
Ce este cerința Matricei de trasabilitate (RTM) în testarea software-ului: Ghid pas cu pas pentru crearea Matricei de trasabilitate cu exemple și șablon de eșantion
Tutorialul de astăzi este despre un instrument important de control al calității, care este fie simplificat în exces (citit cu vederea), fie suprasolicitat - adică Matricea de trasabilitate (TM).
Cel mai adesea, realizarea, revizuirea sau partajarea unei matrici de trasabilitate nu este unul dintre principalele rezultate ale procesului de asigurare a calității - deci nu este concentrat în mod major, provocând astfel sublinierea. Dimpotrivă, unii clienți se așteaptă ca un TM să dezvăluie fațete distrugătoare ale pământului despre produsul lor (sub test) și sunt dezamăgiți.
„Când este utilizat corect, o matrice de trasabilitate poate fi GPS-ul dvs. pentru călătoria dvs. de QA”.
Așa cum este o practică generală la STH , vom vedea aspectele „Ce” și „Cum” ale unui TM în acest articol.
Ce veți învăța:
- Care este matricea de trasabilitate a cerințelor?
- Acoperirea testului și trasabilitatea cerințelor
- Cum să creați o matrice de trasabilitate a cerințelor
Care este matricea de trasabilitate a cerințelor?
În Matricea de trasabilitate a cerințelor sau RTM, am creat un proces de documentare a legăturilor dintre cerințele utilizatorilor propuse de client către sistemul în curs de construire. Pe scurt, este un document de nivel înalt pentru cartografierea și urmărirea cerințelor utilizatorilor cu cazuri de testare pentru a se asigura că pentru fiecare cerință se atinge un nivel adecvat de testare.
Procesul de revizuire a tuturor cazurilor de testare definite pentru orice cerință se numește Trasabilitate. Trasabilitatea ne permite să stabilim care cerințe au generat cel mai mare număr de defecte în timpul procesului de testare.
Accentul oricărui angajament de testare este și ar trebui să fie acoperirea maximă a testelor. Prin acoperire, înseamnă pur și simplu că trebuie să testăm tot ceea ce trebuie testat. Scopul oricărui proiect de testare ar trebui să fie acoperirea 100% a testelor.
Cerințe Matricea de trasabilitate stabilește o modalitate de a ne asigura că efectuăm verificări asupra aspectului acoperirii. Ajută la crearea unui instantaneu pentru identificarea lacunelor de acoperire. Pe scurt, poate fi denumită și metrică care determină numărul de cazuri de testare Executate, trecute, nereușite sau blocate etc. pentru fiecare cerință.
De ce este necesară trasabilitatea cerințelor?
Matricea de trasabilitate a cerințelor ajută la conectarea cerințelor, Cazuri de testare , și defectele cu precizie. Întreaga aplicație este testată având trasabilitatea cerințelor ( Testarea End to End a unei aplicații se realizează).
întrebări de interviu jira pentru scrum master
Trasabilitatea cerințelor asigură o „calitate” bună a aplicației, deoarece toate caracteristicile sunt testate. Control de calitate poate fi realizat pe măsură ce software-ul este testat pentru situații neprevăzute cu defecte minime și toate cerințele funcționale și nefuncționale fiind îndeplinite.
Matricea de trasabilitate a cerințelor ajută la testarea aplicațiilor software în perioada de timp prevăzută, scopul proiectului este bine determinat și implementarea acestuia se realizează conform cerințelor și nevoilor clienților, iar costul proiectului este bine controlat.
Scurgerile de defecte sunt prevenite întrucât întreaga aplicație este testată pentru cerințele sale.
Tipuri de matrice de trasabilitate
Trasabilitate înainte
În „Urmărirea trasabilității” Cerințe pentru cazurile de testare. Se asigură că proiectul progresează conform direcției dorite și că fiecare cerință este testată cu atenție.
Trasabilitatea înapoi
Cazurile de testare sunt mapate cu cerințele din „Trasabilitate inversă”. Scopul său principal este de a se asigura că produsul actual în curs de dezvoltare este pe drumul cel bun. De asemenea, ajută la determinarea faptului că nu se adaugă funcționalități suplimentare nespecificate și, astfel, domeniul de aplicare al proiectului este afectat.
Trasabilitate bidirecțională
(Înainte + Înapoi): O matrice de bună trasabilitate are referințe de la cazuri de testare la cerințe și invers (cerințe la cazuri de testare). Aceasta este denumită trasabilitate „bidirecțională”. Se asigură că toate cazurile de testare pot fi trasate la cerințe și fiecare cerință specificată are cazuri de testare corecte și valide pentru acestea.
Exemple de RTM
# 1) Cerința de afaceri
BR1 : Opțiunea de scriere a e-mailurilor ar trebui să fie disponibilă.
Scenariu de testare (specificații tehnice) pentru BR1
TS1 : Opțiunea Compunere e-mail este furnizată.
Cazuri de testare:
Testul 1 (TS1.TC1) : Opțiunea Compunere e-mail este activată și funcționează cu succes.
Testul 2 (TS1.TC2) : Opțiunea Compunere e-mail este dezactivată.
# 2) Defecte
După executarea cazurilor de testare, dacă se constată defecte, acestea pot fi listate și mapate cu cerințele de afaceri, scenarii de testare și cazuri de testare.
De exemplu, Dacă TS1.TC1 eșuează, adică opțiunea Compunere e-mail, deși activată nu funcționează corect, atunci poate fi înregistrat un defect. Să presupunem că ID-ul defectului generat automat sau numărul atribuit manual este D01, atunci acesta poate fi mapat cu numerele BR1, TS1 și TS1.TC1.
Astfel, toate cerințele pot fi reprezentate într-un format de tabel.
| Cerința de afaceri nr. | # Scenariu de testare | Caz de testare nr. | Defecte # |
|---|---|---|---|
| BR1 | TS1 | TS1.TC1 TS1.TC2 | D01 |
| BR2 | TS2 | TS2.TC1 TS2, TC2 TS2.TC3 | D02 D03 |
| BR3 | TS3 | TS1.TC1 TS2.TC1 TS3.TC1 TS3.TC2 | ZERO |
Acoperirea testului și trasabilitatea cerințelor
Ce este acoperirea testelor?
Acoperirea testului indică cerințele clienților care trebuie verificate la începerea fazei de testare. Acoperirea testului este un termen care determină dacă cazurile de testare sunt scrise și executate pentru a asigura testarea completă a aplicației software, astfel încât să fie raportate defecte minime sau NIL.
Cum se realizează acoperirea testului?
Acoperirea maximă a testului poate fi atinsă prin stabilirea unei bune „trasabilități a cerințelor”.
- Maparea tuturor defectelor interne la cazurile de testare proiectate
- Maparea tuturor defectelor raportate de clienți (CRD) la cazuri individuale de testare pentru viitoarea suită de teste de regresie
Tipuri de specificații ale cerințelor
# 1) Cerințe de afaceri
Cerințele reale ale clienților sunt enumerate într-un document cunoscut sub numele de Document de cerințe comerciale (BRS) . Acest BRS este o listă de cerințe de nivel înalt derivată minutios, după o scurtă interacțiune cu clientul.
De obicei, este pregătit de „Business Analists” sau de proiectul „Architect” (în funcție de organizație sau structura proiectului). Documentul „Specificațiile cerințelor software” (SRS) este derivat din BRS.
# 2) Documentul de specificații pentru cerințele software (SRS)
Este un document detaliat care conține toate detaliile minuțioase ale tuturor cerințelor funcționale și nefuncționale. Acest SRS este linia de bază pentru proiectarea și dezvoltarea aplicațiilor software.
# 3) Documente privind cerințele de proiect (PRD)
PRD este un document de referință pentru toți membrii echipei dintr-un proiect pentru a le spune exact ce ar trebui să facă un produs. Poate fi împărțit în secțiuni precum Scopul produsului, Caracteristicile produsului, Criteriile de lansare și Bugetarea și programul proiectului.
# 4) Utilizați documentul cazului
Este documentul care ajută la proiectarea și implementarea software-ului conform nevoilor afacerii. Acesta mapează interacțiunile dintre un actor și un eveniment cu un rol care trebuie îndeplinit pentru a atinge un obiectiv. Este o descriere detaliată pas cu pas a modului în care trebuie efectuată o sarcină.
De exemplu,
Actor: Client
Rol: Descarcare joc
Descărcarea jocului este reușită.
Cazurile de utilizare pot fi, de asemenea, o parte inclusă în documentul SRS conform procesului de lucru al organizației.
# 5) Document de verificare a defectelor
Este documentat conținând toate detaliile legate de defecte. Echipa poate menține un document „Verificarea defectelor” pentru remedierea și reevaluarea defectelor. Testatorii pot consulta documentul „Verificarea defectelor”, atunci când doresc să verifice dacă defectele sunt sau nu remediate, pot retesta defectele pe sisteme de operare diferite, dispozitiv, configurație de sistem diferită etc.
Documentul „Verificarea defectelor” este la îndemână și important atunci când există o fază dedicată de remediere și verificare a defectelor.
# 6) Povești de utilizatori
Povestea utilizatorului este utilizată în principal în dezvoltarea „Agile” pentru a descrie o caracteristică software dintr-o perspectivă a utilizatorului final. Poveștile utilizatorilor definesc tipurile de utilizatori și în ce mod și de ce doresc o anumită caracteristică. Cerința este simplificată prin crearea de povești de utilizator.
În prezent, toate industriile software se îndreaptă spre utilizarea User Stories și Agile Development și a instrumentelor software corespunzătoare pentru înregistrarea cerințelor.
Provocări pentru colectarea cerințelor
# 1) Cerințele colectate trebuie să fie detaliate, fără ambiguități, exacte și bine specificate. Dar acolo este NU FACE măsură adecvată pentru calcularea acestor detalii, lipsă de ambiguitate, acuratețe și specificații bine definite care sunt necesare pentru colectarea cerințelor.
sisteme de punct de vânzare pentru ipad
#Două) Interpretarea „Business Analyst” sau „Product Owner”, care furnizează informațiile despre cerințe, este critică. În mod similar, echipa care primește informațiile trebuie să aducă clarificări adecvate pentru a înțelege așteptările părților interesate.
Înțelegerea trebuie să fie sincronizată atât cu nevoile de afaceri, cât și cu eforturile efective necesare pentru implementarea aplicației.
# 3) Informațiile ar trebui, de asemenea, derivate din punctul de vedere al utilizatorului final.
# 4) Cerințele conflictuale sau contradictorii ale statului părților interesate în momente diferite.
# 5) Punctul de vedere al utilizatorului final nu este luat în considerare din mai multe motive și alte părți interesate cred că înțeleg „complet” ceea ce este necesar pentru un produs, ceea ce, în general, nu este cazul.
# 6) Resurse lipsă de abilități pentru aplicații dezvoltate.
# 7) Modificări frecvente ale „domeniului de aplicare” sau modificări de prioritate pentru module.
# 8) Cerințe ratate, implicite sau nedocumentate.
# 9) Cerințe incoerente sau vagi determinate de clienți.
# 10) Concluzia tuturor factorilor menționați mai sus este că „Succesul” sau „Eșecul” unui proiect depinde considerabil de o cerință.
Cum poate ajuta trasabilitatea cerințelor
# 1) Unde este implementată o cerință?
De exemplu,
Cerinţă: Implementați funcționalitatea „Compuneți e-mail” într-o aplicație de e-mail.
Implementare: Unde pe pagina principală ar trebui să fie plasat și accesat butonul „Compuneți e-mail”.
# 2) Este necesară o cerință?
De exemplu,
Cerinţă: Implementați funcționalitatea „Compuneți e-mail” într-o aplicație de e-mail numai pentru anumiți utilizatori.
Implementare: Conform drepturilor de acces ale utilizatorilor, dacă căsuța de e-mail este „Numai citire”, în acest caz nu va fi necesar butonul „Compuneți e-mail”.
# 3) Cum interpretez o cerință?
De exemplu,
Cerinţă: Funcționalitatea „Compuneți e-mail” într-o aplicație de e-mail cu fonturi și atașamente.
Implementare: Când se face clic pe „Compune e-mail”, ce funcții ar trebui furnizate?
- Text Corp pentru a scrie e-mailuri și a edita în diferite tipuri de fonturi și, de asemenea, cu caractere aldine, cursive, subliniați-le
- Tipuri de atașamente (imagini, documente, alte e-mailuri etc.)
- Dimensiunea atașamentelor (dimensiunea maximă permisă)
Astfel, Cerințele sunt defalcate la sub-cerințe.
# 4) Ce decizii de proiectare afectează implementarea unei cerințe?
De exemplu,
Cerinţă: Toate elementele „Mesaje primite”, „Mesaje trimise”, „Schițe”, „Spam”, „Coș de gunoi” etc. ar trebui să fie clar vizibile.
Implementare: Elementele care urmează să fie vizibile trebuie afișate în formatul „Tree” sau în formatul „Tab”.
# 5) Sunt alocate toate cerințele?
De exemplu,
Cerinţă: Este furnizată opțiunea de e-mail „Coș de gunoi”.
Implementare: Dacă a fost furnizată opțiunea de e-mail „Coș de gunoi”, atunci opțiunea de e-mail „Ștergere” (cerință) trebuie implementată inițial și ar trebui să funcționeze cu precizie. Dacă opțiunea de e-mail „Ștergeți” funcționează corect, atunci numai e-mailurile șterse vor fi colectate în „Coșul de gunoi” și implementarea opțiunii de e-mail „Coș de gunoi” (cerință) va avea sens (va fi utilă).
Avantajele RTM și acoperirea testelor
# 1) Construcția dezvoltată și testată are funcționalitatea necesară, care răspunde nevoilor și așteptărilor „Clienților” / „Utilizatorilor”. Clientul trebuie să obțină ceea ce dorește. A surprinde clientul cu o aplicație care nu face ceea ce se așteaptă să facă nu este o experiență satisfăcătoare pentru nimeni.
#Două) Produsul final (aplicație software) dezvoltat și livrat clientului trebuie să cuprindă doar funcționalitatea necesară și așteptată. Funcțiile suplimentare furnizate în aplicația software pot părea atractive inițial până când există o cheltuială de timp, bani și eforturi pentru ao dezvolta.
Funcția suplimentară poate deveni, de asemenea, o sursă de Defecte, care pot provoca probleme unui client după instalare.
# 3) Sarcina inițială a dezvoltatorului este definită în mod clar, deoarece lucrează mai întâi la implementarea cerințelor, care sunt de mare prioritate, conform cerințelor clientului. Dacă cerințele de înaltă prioritate ale clientului sunt specificate în mod clar, atunci aceste componente de cod pot fi dezvoltate și implementate pe prima prioritate.
Astfel, se asigură că șansele ca produsul final să fie livrat clientului este în conformitate cu cele mai bune cerințe și este în termen.
# 4) Testerii verifică mai întâi cea mai importantă funcționalitate implementată de dezvoltatori. Deoarece verificarea (testarea) componentei software prioritare se face mai întâi, ajută la determinarea când și dacă primele versiuni ale sistemului sunt gata să fie lansate.
# 5) Planuri de testare precise, cazurile de testare sunt scrise și executate, care verifică dacă toate cerințele aplicației sunt implementate corect. Testarea cartografierii cazurilor cu cerințele ajută la asigurarea faptului că nu se ratează defecte majore. În plus, ajută la implementarea unui produs de calitate conform așteptărilor clienților.
# 6) În cazul în care există „Cerere de modificare” de la client, toate componentele aplicației care sunt afectate de cererea de modificare sunt modificate și nimic nu este trecut cu vederea. Acest lucru îmbunătățește și mai mult în evaluarea impactului pe care o solicitare de modificare îl are asupra aplicației software.
# 7) O cerere de modificare aparent simplă ar putea implica modificări care trebuie făcute mai multor părți ale aplicației. Este mai bine să trageți o concluzie cu privire la cât de mult efort va fi necesar înainte de a fi de acord să faceți schimbarea.
Provocări în acoperirea testelor
# 1) Canal de comunicare bun
Dacă există modificări sugerate de Părțile interesate , același lucru trebuie comunicat echipelor de dezvoltare și testare în fazele anterioare ale dezvoltării. Fără asta la timp Dezvoltarea, testarea aplicației și captarea / remedierea defectelor nu pot fi asigurate.
# 2) Prioritizarea scenariilor de testare este importantă
Identificarea care sunt scenariile de testare prioritare, complexe și importante este o sarcină dificilă. Încercând să testez toate Testează scenarii este aproape o sarcină de nerealizat. Scopul testării scenariilor trebuie să fie foarte clar din punct de vedere al afacerii și al utilizatorului final.
# 3) Implementarea procesului
Procesul de testare trebuie să fie clar definit având în vedere factori precum infrastructura și implementările tehnice, abilitățile echipei, experiențele anterioare, structurile organizaționale și procesele urmate, estimările proiectului legate de cost, timp și resurse și locația echipei conform fusurilor orare.
O implementare uniformă a procesului, având în vedere factorii menționați, asigură că fiecare persoană interesată de proiect se află pe aceeași pagină. Acest lucru ajută la un flux lin al tuturor proceselor legate de dezvoltarea aplicațiilor.
# 4) Disponibilitatea resurselor
Resursele sunt de două tipuri, testeri specifici domeniului calificat și instrumentele de testare utilizate de testatori. Dacă testerii au cunoștințe adecvate despre domeniu, pot scrie și implementa scenarii și scripturi de testare eficiente. Pentru a implementa aceste scenarii și scripturi, testerii ar trebui să fie bine echipați cu „Instrumente de testare” adecvate.
Implementarea bună și livrarea la timp a aplicației către client pot fi asigurate de singurul tester calificat și instrumentele de testare adecvate.
# 5) Implementarea eficientă a strategiei de testare
' Strategia de testare ”în sine este un subiect mare și separat de discuție. Dar aici pentru „Test Coverage”, o implementare eficientă a strategiei de testare asigură că „ Calitate' a cererii este bun si e menținut peste perioada de timp de pretutindeni.
O „strategie de testare” eficientă joacă un rol major în planificarea în avans a tuturor tipurilor de provocări critice, ceea ce ajută în continuare la dezvoltarea unei aplicații mai bune.
Cum să creați o matrice de trasabilitate a cerințelor
Pentru a fi alături trebuie să știm exact ce este ceea ce trebuie urmărit sau urmărit.
Testatorii încep să-și scrie scenariile / obiectivele de testare și, eventual, cazurile de testare pe baza unor documente de intrare - Document de cerințe comerciale, Document cu specificații funcționale și documentul de proiectare tehnică (opțional).
Să presupunem că următorul este documentul nostru privind cerințele de afaceri (BRD): ( Descărcați acest exemplu BRD în format excel )
(Faceți clic pe orice imagine pentru a mări)
Mai jos este documentul nostru de specificații funcționale (FSD) bazat pe interpretarea documentului de cerințe de afaceri (BRD) și adaptarea acestuia la aplicații informatice. În mod ideal, toate aspectele FSD trebuie abordate în BRD. Dar, de dragul simplității, am folosit doar punctele 1 și 2.
Exemplu de FSD din partea de sus a BRD: ( Descărcați acest eșantion FSD în format excel )
Notă : BRD și FSD nu sunt documentate de echipele de asigurare a calității. Suntem simpli consumatori ai documentelor împreună cu celelalte echipe de proiect.
Pe baza celor două documente de intrare de mai sus, în calitate de echipă QA, am venit cu lista de mai jos a scenariilor la nivel înalt pe care să le testăm.
Exemple de scenarii de test din BRD și FSD de mai sus: ( Descărcați acest fișier Scenarii de probă )
Odată ajunși aici, acum ar fi un moment bun pentru a începe crearea Matricei de trasabilitate a cerințelor.
Personal prefer o foaie excel foarte simplă cu coloane pentru fiecare document pe care dorim să îl urmărim. Deoarece cerințele comerciale și cerințele funcționale nu sunt numerotate în mod unic, vom folosi numerele secțiunilor din document pentru a urmări.
(Puteți alege să urmăriți pe baza numerelor de linie sau a punctelor marcate etc., în funcție de ceea ce are cel mai mult sens pentru cazul dvs., în special.)
Iată cum ar arăta o matrice simplă de trasabilitate pentru exemplul nostru:
Documentul de mai sus stabilește o urmă între BRD și FSD și, eventual, scenariile de testare. Prin crearea unui document ca acesta, ne putem asigura că fiecare aspect al cerințelor inițiale a fost luat în considerare de echipa de testare pentru crearea suitelor de testare.
O poți lăsa așa. Cu toate acestea, pentru a o face mai ușor de citit, prefer să includ și numele secțiunilor. Acest lucru va îmbunătăți înțelegerea atunci când acest document este distribuit clientului sau oricărei alte echipe.
Rezultatul este cel de mai jos:
Din nou, alegerea de a utiliza formatul anterior sau ulterior este a ta.
Aceasta este versiunea preliminară a TM-ului dvs., dar, în general, nu își îndeplinește scopul atunci când vă opriți aici. Beneficiile maxime pot fi obținute din aceasta atunci când o extrapolați până la defecte.
Să vedem cum.
Pentru fiecare scenariu de testare cu care ați venit, veți avea cel puțin 1 sau mai multe cazuri de testare. Deci, includeți o altă coloană când ajungeți acolo și scrieți ID-urile cazului de testare, așa cum se arată mai jos:
În acest stadiu, Matricea de trasabilitate poate fi utilizată pentru a găsi lacune. De exemplu, în Matricea de trasabilitate de mai sus, vedeți că nu există cazuri de test scrise pentru secțiunea 1.2 a FSD.
Ca regulă generală, orice spații goale din Matricea de trasabilitate sunt zone potențiale de investigare. Deci, un astfel de decalaj poate însemna unul dintre cele două lucruri:
- Echipa de testare a ratat cumva luând în considerare funcționalitatea „Utilizator existent”.
- Funcționalitatea „Utilizator existent” a fost amânată ulterior sau eliminată din cerințele de funcționalitate ale aplicației. În acest caz, TM arată o inconsecvență în FSD sau BRD - ceea ce înseamnă că ar trebui făcută o actualizare a documentelor FSD și / sau BRD.
Dacă este scenariul 1, acesta va indica locurile în care echipa de testare trebuie să mai lucreze pentru a asigura o acoperire de 100%.
În scenariile 2, TM nu doar arată lacune, ci indică o documentație incorectă care necesită o corectare imediată.
Să extindem acum TM pentru a include starea de execuție a cazului de testare și defecte.
Versiunea de mai jos a Matricei de trasabilitate este, în general, pregătită în timpul sau după executarea testului:
Descărcați șablonul Matricei de trasabilitate a cerințelor:
=> Șablon de matrice de trasabilitate în format Excel
Puncte importante de remarcat
Următoarele sunt punctele importante de remarcat despre această versiune a Matricei de trasabilitate:
# 1) Se afișează și starea de execuție. În timpul execuției, oferă un instantaneu consolidat al progresului muncii.
# 2) Defecte: Când această coloană este utilizată pentru a stabili Trasabilitatea înapoi, putem spune că funcționalitatea „Utilizator nou” este cea mai defectuoasă. În loc să raporteze că astfel de cazuri de testare au eșuat, TM oferă transparență înapoi la cerința de afaceri care are cele mai multe defecte, prezentând astfel calitatea în ceea ce privește ceea ce dorește clientul.
# 3) Ca un pas suplimentar, puteți codifica codul ID-ului defectului pentru a le reprezenta stările. De exemplu, ID-ul defectului în roșu poate însemna că este încă deschis, într-un verde poate însemna că este închis. Când se face acest lucru, TM funcționează ca un raport de verificare a stării de sănătate care afișează starea defectelor corespunzătoare unei anumite funcționalități BRD sau FSD fiind deschisă sau închisă.
# 4) Dacă există un document de proiectare tehnică sau cazuri de utilizare sau orice alte artefacte pe care doriți să le urmăriți, puteți întotdeauna extinde documentul creat mai sus pentru a se potrivi nevoilor dvs. adăugând coloane suplimentare.
Pentru a rezuma, RTM ajută la:
- Asigurarea acoperirii 100% a testelor
- Se afișează neconcordanțe de cerință / document
- Afișarea stării generale a defectului / execuției, cu accent pe cerințele de afaceri.
- Dacă s-ar schimba o anumită cerință de afaceri și / sau funcțională, un TM ajută la estimarea sau analiza impactului asupra activității echipei de asigurare a calității în ceea ce privește revizuirea / relucrarea cazurilor de testare.
În plus,
- O matrice de trasabilitate nu este un instrument specific de testare manuală, poate fi utilizată și pentru proiecte de automatizare. Pentru un proiect de automatizare, ID-ul cazului de test poate indica numele scriptului de testare a automatizării.
- De asemenea, nu este un instrument care poate fi utilizat doar de către QA-uri. Echipa de dezvoltare poate folosi același lucru pentru a mapa cerințele BRD / FSD la blocuri / unități / condiții de cod create pentru a se asigura că toate cerințele sunt dezvoltate.
- Instrumente de gestionare a testelor precum HP ALM vin cu caracteristica de trasabilitate încorporată.
Un punct important de remarcat este cămodul în care vă mențineți și actualizați Matricea de trasabilitate determină eficacitatea utilizării sale. Dacă nu este actualizat des sau actualizat incorect, instrumentul este o povară în loc să fie un ajutor și creează impresia că instrumentul în sine nu este demn de utilizat.
Concluzie
Cerința de trasabilitate Matricea este mijlocul de a harta și urmărirea toate cerințele clientului cu cazurile de testare și defectele descoperite. Este un document unic care servește scopului principal că nu sunt ratate cazuri de testare și astfel fiecare funcționalitate a aplicației este acoperită și testată.
O bună „acoperire a testului”, care este planificată din timp, previne sarcinile repetitive în fazele de testare și defectele. Un număr mare de defecte indică faptul că testarea se face bine și, astfel, „Calitatea” aplicației crește. În mod similar, un număr foarte scăzut de defecte indică faptul că testarea nu se face până la marcă și acest lucru împiedică „calitatea” aplicației într-un mod negativ.
declarați o matrice de șiruri în java
Dacă acoperirea testului este realizată temeinic, atunci un număr scăzut de defecte poate fi justificat, iar acest număr de defecte poate fi considerat ca statistică de susținere și nu unul primar. Calitatea unei aplicații este denumită „Bună” sau „Satisfăcătoare” atunci când acoperirea testului este maximizată și numărul de defecte este minimizat.
Despre autor: Membru al echipei STH, Urmila P. este un profesionist QA cu experiență calitate superioară abilități de testare și urmărire a problemelor.
Ați creat o matrice de trasabilitate a cerințelor în proiectele dvs.? Cât de asemănător sau diferit este de ceea ce am creat în acest articol? Vă rugăm să împărtășiți experiențele, comentariile, gândurile și feedback-ul dvs. despre acest articol prin comentariile dvs.
Lectură recomandată
- Exemplu de șablon de plan de testare software cu format și conținut
- Cum se scrie un raport sumar eficient al testului (Descărcare exemplu de raport)
- Exemplu de șablon de caz de testare cu exemple de cazuri de testare (Descărcare)
- Exemplu de șablon pentru raportul testului de acceptare cu exemple
- Cum se scrie un document de strategie de testare (cu un șablon de strategie de testare)
- Cum se testează specificațiile cerințelor software (SRS)?
- Top 20+ Cele mai bune instrumente de gestionare a cerințelor (lista completă)
- Listele de verificare pentru testarea software-ului QA (Exemple de liste de verificare incluse)