how create requirements traceability matrix
Què és la matriu de traçabilitat dels requisits (RTM) a les proves de programari: guia pas a pas per crear la matriu de traçabilitat amb exemples i plantilla de mostra
El tutorial d’avui tracta d’una eina important de control de qualitat, que és simplificada en excés (es passa per alt) o es fa èmfasi excessiu, és a dir, Matriu de traçabilitat (TM).
El més freqüent és que l'elaboració, revisió o compartició d'una matriu de traçabilitat no sigui un dels productes principals del procés de control de qualitat, de manera que no es concentra majoritàriament, cosa que provoca un subestimatge. Al contrari, alguns clients esperen que un TM reveli facetes destrossadores del seu producte (en proves) i es mostri decebut.
'Quan s'utilitza bé, una matriu de traçabilitat pot ser el vostre GPS per al vostre viatge de control de qualitat'.
Com és una pràctica general a STH , veurem els aspectes 'Què' i 'Com' d'una TM en aquest article.
Què aprendreu:
- Quina és la matriu de traçabilitat dels requisits?
- Cobertura de les proves i traçabilitat dels requisits
- Com es crea una matriu de traçabilitat dels requisits
Quina és la matriu de traçabilitat dels requisits?
A la matriu de traçabilitat de requisits o RTM, establim un procés de documentació dels enllaços entre els requisits d’usuari proposats pel client al sistema que s’està construint. En resum, és un document d’alt nivell per mapear i rastrejar els requisits de l’usuari amb casos de prova per garantir que s’aconsegueixi un nivell adequat de proves per a tots els requisits.
El procés per revisar tots els casos de prova que es defineixen per a qualsevol requisit s’anomena Traçabilitat. La traçabilitat ens permet determinar quins requisits van generar el major nombre de defectes durant el procés de prova.
El focus de qualsevol interacció de proves és i ha de ser la màxima cobertura de proves. Per cobertura, significa simplement que hem de provar tot el que cal provar. L'objectiu de qualsevol projecte de proves ha de ser un 100% de cobertura de proves.
La matriu de traçabilitat dels requisits estableix una manera d'assegurar-nos que fem controls sobre l'aspecte de la cobertura. Ajuda a crear una instantània per identificar els buits de cobertura. En resum, també es pot anomenar mètriques que determinen el nombre de casos de prova Executats, superats, fallits o bloquejats, etc. per a cada requisit.
Per què es requereix la traçabilitat dels requisits?
La matriu de traçabilitat dels requisits ajuda a enllaçar els requisits, Casos de prova , i defectes amb precisió. La totalitat de l'aplicació es prova tenint la traçabilitat del requisit ( Proves d'extrem a extrem d’una aplicació s’aconsegueix).
eclipsi ide per a c / c ++
La traçabilitat dels requisits garanteix una bona 'qualitat' de l'aplicació a mesura que es proven totes les funcions. Control de qualitat es pot aconseguir a mesura que el programari es prova per situacions imprevistes amb defectes mínims i que es compleixen tots els requisits funcionals i no funcionals.
La matriu de traçabilitat del requisit ajuda a provar aplicacions de programari en el temps estipulat, l’abast del projecte està ben determinat i s’aconsegueix la seva implementació segons les necessitats i necessitats del client i el cost del projecte està ben controlat.
S'eviten les fugues de defectes, ja que tota l'aplicació es prova per als seus requisits.
Tipus de matriu de traçabilitat
Traçabilitat cap endavant
A 'Traçabilitat avançada' Requisits als casos de prova. Assegura que el projecte progressa segons la direcció desitjada i que cada requisit es prova a fons.
Traçabilitat cap enrere
Els casos de prova s’assignen amb els requisits de la 'Traçabilitat cap enrere'. El seu objectiu principal és assegurar-se que el producte actual que es desenvolupa vagi pel bon camí. També ajuda a determinar que no s’afegeixen funcions addicionals no especificades i, per tant, es veu afectat l’abast del projecte.
Traçabilitat bidireccional
(Endavant + Endarrere): Una matriu de bona traçabilitat inclou referències des de casos de prova a requisits i viceversa (requisits per a casos de prova). Això es coneix com a traçabilitat 'bidireccional'. Assegura que tots els casos de prova es poden rastrejar segons els requisits i que tots els requisits especificats tenen casos de prova vàlids i precisos per a ells.
Exemples de RTM
# 1) Requisit empresarial
BR1 : Ha d’estar disponible l’opció d’escriure correus electrònics.
Escenari de prova (especificació tècnica) per a BR1
TS1 : Es proporciona l'opció Redacta el correu.
Casos de prova:
Cas de prova 1 (TS1.TC1) : L'opció Redactar correu està habilitada i funciona correctament.
Cas de prova 2 (TS1.TC2) : L'opció Redactar correu està desactivada.
# 2) Defectes
Després d’executar els casos de prova, si es detecten defectes, també es poden llistar i mapar amb els requisits empresarials, els escenaris de prova i els casos de prova.
Per exemple, Si TS1.TC1 falla, és a dir, l'opció Redacta el correu, encara que activada, no funciona correctament, es pot registrar un defecte. Suposem que el número de defecte generat automàticament o assignat manualment és D01, llavors es pot assignar amb números BR1, TS1 i TS1.TC1.
Així, tots els requisits es poden representar en format de taula.
| Requisit empresarial núm. | Escenari de prova núm. | Cas de prova núm. | # Defectes |
|---|---|---|---|
| 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 | NUL |
Cobertura de les proves i traçabilitat dels requisits
Què és la cobertura de les proves?
La cobertura de les proves indica quins requisits dels clients s’han de verificar quan comença la fase de proves. Cobertura de la prova és un terme que determina si els casos de prova s’escriuen i s’executen per assegurar-se que proveu completament l’aplicació de programari, de manera que s’informin de defectes mínims o NIL.
Com aconseguir la cobertura de les proves?
Es pot aconseguir la màxima cobertura de proves establint una bona 'traçabilitat dels requisits'.
- Assignar tots els defectes interns als casos de prova dissenyats
- Assignar tots els defectes reportats pel client (CRD) a casos de prova individuals per al futur conjunt de proves de regressió
Especificacions de tipus de requisits
# 1) Requisits empresarials
Els requisits reals dels clients es detallen en un document conegut com a Document de requisits empresarials (BRS) . Aquest BRS és una llista de requisits d’alt nivell derivada minuciosament, després d’una breu interacció amb el client.
Normalment els prepara «Business Analysts» o el projecte «Architect» (segons l'organització o l'estructura del projecte). El document 'Especificacions de requisits de programari' (SRS) es deriva de BRS.
# 2) Document d'especificació de requisits de programari (SRS)
És un document detallat que conté tots els detalls meticulosos de tots els requisits funcionals i no funcionals. Aquest SRS és la base per dissenyar i desenvolupar aplicacions de programari.
# 3) Documents de requisits del projecte (PRD)
El PRD és un document de referència per a tots els membres de l'equip en un projecte per dir-los exactament què ha de fer un producte. Es pot dividir en seccions com a Propòsit del producte, Funcions del producte, Criteris de llançament i Pressupost i calendari del projecte.
# 4) Document de casos d’ús
És el document que ajuda a dissenyar i implementar el programari segons les necessitats empresarials. Mapea les interaccions entre un actor i un esdeveniment amb un paper que cal realitzar per assolir un objectiu. És una descripció detallada pas a pas de com s’ha de realitzar una tasca.
Per exemple,
actor: Client
Rol: Descarrega el joc
La descàrrega del joc té èxit.
Els casos d’ús també poden ser una part inclosa al document SRS segons el procés de treball de l’organització.
# 5) Document de verificació de defectes
Està documentat que conté tots els detalls relacionats amb defectes. L'equip pot mantenir un document de 'Verificació de defectes' per solucionar i provar de nou els defectes. Els verificadors poden consultar el document de 'Verificació de defectes', quan volen verificar si els defectes estan corregits o no, tornar a provar defectes en diferents sistemes operatius, dispositius, configuracions del sistema diferents, etc.
El document 'Verificació de defectes' és útil i important quan hi ha una fase dedicada de correcció i verificació de defectes.
# 6) Històries d'usuaris
La història de l'usuari s'utilitza principalment en el desenvolupament 'Àgil' per descriure una funció de programari des de la perspectiva de l'usuari final. Les històries dels usuaris defineixen els tipus d’usuaris i de quina manera i per què volen una determinada característica. El requisit es simplifica mitjançant la creació d’històries d’usuaris.
Actualment, totes les indústries del programari s'estan avançant cap a l'ús de User Stories i Agile Development i les eines de programari corresponents per registrar els requisits.
Desafiaments per a la col·lecció de requisits
# 1) Els requisits recollits han de ser detallats, inequívocs, precisos i ben especificats. Però sí NO mesura adequada per al càlcul d’aquests detalls, inequivocitat, precisió i especificacions ben definides que són necessàries per a la recollida de requisits.
# 2) La interpretació de 'Business Analyst' o 'Product Owner' que proporcioni la informació sobre els requisits és fonamental. De la mateixa manera, l'equip que rep la informació ha d'aportar els aclariments adequats per entendre les expectatives dels grups d'interès.
La comprensió ha d'estar sincronitzada amb les necessitats empresarials i els esforços reals necessaris per a la implementació de l'aplicació.
# 3) La informació també s’ha de derivar des del punt de vista de l’usuari final.
# 4) Requisits contradictoris o contradictoris de l'estat de les parts interessades en diferents moments.
# 5) El punt de vista de l'usuari final no es considera a causa de múltiples motius i altres parts interessades pensen que entenen 'completament' el que es requereix per a un producte, cosa que en general no és així.
# 6) Els recursos no tenen habilitats per desenvolupar aplicacions.
# 7) Canvis freqüents d’aplicació ‘Abast’ o canvis de prioritat per als mòduls.
# 8) Requisits perduts, implícits o indocumentats.
# 9) Requisits inconsistents o vagues determinats pels clients.
# 10) La conclusió de tots els factors esmentats anteriorment és que l ''èxit' o el 'fracàs' d'un projecte depèn considerablement d'un requisit.
Com pot ajudar la traçabilitat dels requisits
# 1) On s’implementa un requisit?
Per exemple,
Requisit: Implementa la funcionalitat 'Redacta el correu' en una aplicació de correu.
Implementació: Des de la pàgina principal, s’hauria de col·locar i accedir al botó ‘Redacta el correu’.
# 2) És necessari un requisit?
preguntes per fer a un analista de negocis
Per exemple,
Requisit: Implementeu la funcionalitat 'Redacta el correu' en una aplicació de correu electrònic només per a determinats usuaris.
Implementació: Segons els drets d’accés de l’usuari si la safata d’entrada del correu electrònic és de “només lectura”, en aquest cas no serà necessari el botó “Redacta el correu”.
# 3) Com puc interpretar un requisit?
Per exemple,
Requisit: Funcionalitat de 'Compondre correu' en una aplicació de correu amb tipus de lletra i fitxers adjunts.
Implementació: Quan es fa clic a 'Redacta el correu', quines funcions s'han de proporcionar?
- Text Body per escriure correus electrònics i editar-los en diferents tipus de lletra i també en negreta, cursiva, per subratllar-los
- Tipus de fitxers adjunts (imatges, documents, altres correus electrònics, etc.)
- Mida dels fitxers adjunts (mida màxima permesa)
Així, els requisits es desglossen en subrequisits.
# 4) Quines decisions de disseny afecten la implementació d'un requisit?
Per exemple,
Requisit: Tots els elements 'Safata d'entrada', 'Correu enviat', 'Esborranys', 'Correu brossa', 'Paperera', etc. haurien de ser clarament visibles.
Implementació: Els elements que han de ser visibles s’han de mostrar en format ‘Arbre’ o en format ‘Tab’.
# 5) S’han assignat tots els requisits?
Per exemple,
Requisit: Es proporciona l'opció de correu 'Paperera'.
Implementació: Si s'ha proporcionat l'opció de correu 'Paperera', l'opció de correu electrònic 'Suprimeix' (requisit) s'ha d'implementar inicialment i hauria de funcionar amb precisió. Si l'opció de correu 'Suprimeix' funciona correctament, només es recolliran els correus electrònics suprimits a la 'Paperera' i la implementació de l'opció de correu 'Paperera' (requisit) tindrà sentit (serà útil).
Avantatges de RTM i cobertura de proves
# 1) La versió desenvolupada i provada té la funcionalitat necessària que compleix les necessitats i expectatives de 'Clients' / 'Usuaris'. El client ha d’aconseguir el que vol. Sorprendre el client amb una aplicació que no fa el que s’espera que faci no és una experiència satisfactòria per a ningú.
# 2) El producte final (aplicació de programari) desenvolupat i lliurat al client només ha d’incloure la funcionalitat necessària i esperada. Les funcions addicionals proporcionades a l'aplicació de programari poden semblar atractives inicialment fins que hi hagi un temps excessiu, diners i esforç per desenvolupar-la.
La característica addicional també es pot convertir en una font de defectes, que poden causar problemes al client després de la instal·lació.
# 3) La tasca inicial del desenvolupador es defineix clarament ja que treballen primer en la implementació dels requisits, que són d’alta prioritat, segons el requisit del client. Si s’especifiquen clarament els requisits d’alta prioritat del client, aquests components de codi es poden desenvolupar i implementar en primera prioritat.
D'aquesta manera, es garanteix que les possibilitats que el producte final s'enviï al client són segons els requisits més elevats i es compleixen els terminis previstos.
# 4) Els provadors verificen primer la funcionalitat més important implementada pels desenvolupadors. Com que la verificació (prova) del component de programari prioritari es fa primer, ajuda a determinar quan i si les primeres versions del sistema estan llestes per llançar-se.
# 5) Plans de prova exactes, s’escriuen i s’executen casos de prova que comproven que tots els requisits de l’aplicació s’implementen correctament. El mapatge de casos de prova amb els requisits ajuda a garantir que no es perdin defectes importants. A més, ajuda a implementar un producte de qualitat segons les expectatives dels clients.
# 6) En cas que hi hagi una 'Sol·licitud de canvi' del client, tots els components de l'aplicació afectats per la sol·licitud de canvi es modifiquen i no es passa per alt res. Això millora encara més en l'avaluació de l'impacte que té una sol·licitud de canvi en l'aplicació de programari.
# 7) Una sol·licitud de canvi aparentment senzilla pot implicar modificacions que cal fer a diverses parts de l'aplicació. És millor obtenir una conclusió sobre l’esforç que caldrà abans d’acceptar fer el canvi.
Reptes en la cobertura de les proves
# 1) Bon canal de comunicació
Si hi ha canvis suggerits per Els interessats , el mateix s’ha de comunicar als equips de desenvolupament i proves en les fases anteriors del desenvolupament. Sense això puntual No es pot assegurar el desenvolupament, la prova de l'aplicació i la captura / correcció de defectes.
# 2) Prioritzar els escenaris de prova és important
Identificar quins són els escenaris de prova d'alta prioritat, complexos i importants és una tasca difícil. Intentant provar tots els fitxers Escenaris de proves és gairebé una tasca inabastable. L'objectiu de provar els escenaris ha de ser molt clar des del punt de vista empresarial i de l'usuari final.
# 3) Implementació del procés
El procés de proves s’ha de definir clarament tenint en compte factors com infraestructures tècniques i implementacions, habilitats de l’equip, experiències passades, estructures organitzatives i processos seguits, estimacions del projecte relacionades amb el cost, el temps i els recursos i la ubicació de l’equip segons les zones horàries.
Una implementació uniforme del procés tenint en compte els factors esmentats garanteix que totes les persones interessades en el projecte es trobin a la mateixa pàgina. Això ajuda a un flux fluït de tots els processos relacionats amb el desenvolupament d'aplicacions.
# 4) Disponibilitat de recursos
Els recursos són de dos tipus, els provadors específics de domini especialitzat i les eines de prova utilitzades pels verificadors. Si els verificadors tenen un coneixement adequat del domini, poden escriure i implementar escenaris i scripts de prova eficaços. Per implementar aquests escenaris i scripts, els provadors haurien d’estar ben equipats amb les ‘Eines de prova’ adequades.
L’únic provador expert i les eines de prova adequades poden assegurar una bona implementació i lliurament puntual de l’aplicació al client.
# 5) Implementació efectiva de l'estratègia de proves
' Test Strategy ”en si mateix és un tema de debat gran i separat. Però aquí, per a 'Cobertura de proves', una implementació efectiva de l'estratègia de prova garanteix que ' Qualitat ” de l'aplicació és bé i ho és mantingut durant el període de temps a tot arreu.
Una 'estratègia de prova' eficaç té un paper important en la planificació anticipada de tot tipus de reptes crítics, cosa que contribueix encara més a desenvolupar una millor aplicació.
Com es crea una matriu de traçabilitat dels requisits
Per estar amb nosaltres, hem de saber exactament què és el que cal rastrejar o rastrejar.
Els verificadors comencen a escriure els seus escenaris / objectius de prova i, finalment, els casos de prova basats en alguns documents d’entrada: document de requisits empresarials, Document d'especificacions funcionals i document de Disseny Tècnic (opcional).
Suposem que el següent és el nostre document de requisits empresarials (BRD): ( Descarregueu aquest exemple de BRD en format excel )
(Feu clic a qualsevol imatge per ampliar-la)
A continuació es mostra el nostre document d’especificacions funcionals (FSD) basat en la interpretació del document de requisits empresarials (BRD) i l’adaptació d’aquest a les aplicacions informàtiques. L’ideal seria que tots els aspectes de la FSD s’abordin al BRD. Però per simplificar, només he utilitzat els punts 1 i 2.
Exemple de FSD de dalt BRD: ( Descarregueu aquesta mostra FSD en format excel )
Nota : Els equips de control de qualitat no documenten el BRD i el FSD. Som simples consumidors dels documents juntament amb els altres equips del projecte.
com executar un fitxer .swf
Basant-nos en els dos documents d’entrada anteriors, com a equip de control de qualitat, hem elaborat la següent llista d’escenaris d’alt nivell per provar-los.
Exemples d'escenaris de proves de BRD i FSD anteriors: ( Descarregueu aquest fitxer d'Escenaris de prova de mostra )
Un cop arribem aquí, ara seria un bon moment per començar a crear la matriu de traçabilitat dels requisits.
Personalment prefereixo un full Excel molt senzill amb columnes per a cada document que volem fer un seguiment. Com que els requisits empresarials i funcionals no estan numerats de manera única, farem un seguiment dels números de secció del document.
(Podeu triar fer un seguiment en funció de números de línia o de punts amb pics, etc. segons el que tingui més sentit per al vostre cas en particular.)
A continuació s’explica una simple matriu de traçabilitat per al nostre exemple:
El document anterior estableix una traça entre el BRD i el FSD i, finalment, als escenaris de prova. En crear un document com aquest, podem assegurar-nos que l’equip de proves hagi tingut en compte tots els aspectes dels requisits inicials per crear les seves proves.
Ho podeu deixar així. Tot i això, per fer-la més llegible, prefereixo incloure els noms de les seccions. Això millorarà la comprensió quan es comparteixi aquest document amb el client o qualsevol altre equip.
El resultat és el següent:
Una vegada més, l’opció d’utilitzar el format anterior o posterior és vostra.
Aquesta és la versió preliminar del vostre TM, però en general no serveix al seu propòsit quan us atureu aquí. Se’n poden obtenir els màxims beneficis quan s’extrapola fins a defectes.
A veure com.
Per a cada escenari de prova que hagueu plantejat, tindreu almenys un o més casos de prova. Per tant, incloeu una altra columna quan hi arribeu i escriviu els identificadors del cas de prova com es mostra a continuació:
En aquesta etapa, es pot utilitzar la matriu de traçabilitat per trobar buits. Per exemple, a la matriu de traçabilitat anterior, veieu que no hi ha casos de prova escrits per a la secció 1.2 de FSD.
Com a regla general, els espais buits de la matriu de traçabilitat són àrees potencials d'investigació. Per tant, un buit com aquest pot significar una de les dues coses:
- L’equip de proves d’alguna manera no ha tingut en compte la funcionalitat “Usuari existent”.
- La funcionalitat 'Usuari existent' s'ha ajornat posteriorment o s'ha eliminat dels requisits de funcionalitat de l'aplicació. En aquest cas, el TM mostra una incoherència en el FSD o el BRD, cosa que significa que s’hauria de fer una actualització dels documents FSD i / o BRD.
Si es tracta de l’escenari 1, indicarà els llocs on l’equip de proves ha de treballar una mica més per garantir una cobertura del 100%.
En els escenaris 2, TM no només mostra buits, sinó que apunta a documentació incorrecta que necessita una correcció immediata.
Ampliem ara el TM per incloure l'estat d'execució de casos i proves i defectes.
La versió següent de la matriu de traçabilitat es prepara generalment durant o després de l'execució de la prova:
Baixeu la plantilla de matriu de traçabilitat dels requisits:
=> Plantilla de matriu de traçabilitat en format Excel
Punts importants a tenir en compte
Els següents són els punts importants que cal tenir en compte sobre aquesta versió de la matriu de traçabilitat:
# 1) També es mostra l'estat d'execució. Durant l'execució, proporciona una instantània consolidada de com avança la feina.
# 2) Defectes: Quan s'utilitza aquesta columna per establir la traçabilitat cap enrere, podem dir que la funcionalitat 'Usuari nou' és la més defectuosa. En lloc d’informar que els casos de prova han fallat, TM proporciona transparència al requisit empresarial que té més defectes, mostrant així la qualitat en termes del que el client desitja.
# 3) Com a pas més, podeu codificar el color de l'identificador de defecte per representar els seus estats. Per exemple, Un identificador de defecte en vermell pot significar que encara està obert; en verd, pot estar tancat. Quan es fa això, el TM funciona com un informe de control de salut que mostra l'estat dels defectes corresponents a una determinada funcionalitat BRD o FSD que s'està obrint o tancant.
# 4) Si hi ha un document de disseny tècnic o casos d’ús o qualsevol altre artefacte que vulgueu fer un seguiment, sempre podeu ampliar el document creat anteriorment per adaptar-lo a les vostres necessitats afegint columnes addicionals.
En resum, RTM ajuda a:
- Garantir un 100% de cobertura de proves
- Es mostren les inconsistències del requisit / document
- Es mostra l'estat general de defecte / execució amb un focus en els requisits empresarials.
- Si es canviés un determinat requisit empresarial i / o funcional, un TM ajuda a estimar o analitzar l’impacte en el treball de l’equip de control de qualitat en termes de revisió / reelaboració dels casos de prova.
A més,
- Una matriu de traçabilitat no és una eina específica de proves manuals, sinó que també es pot utilitzar per a projectes d'automatització. Per a un projecte d'automatització, l'identificador de cas de prova pot indicar el nom de la seqüència de prova d'automatització.
- Tampoc no és una eina que pugui utilitzar només els QA. L'equip de desenvolupament pot utilitzar el mateix per assignar els requisits BRD / FSD a blocs / unitats / condicions de codi creades per assegurar-se que es desenvolupen tots els requisits.
- Eines de gestió de proves com HP ALM vénen amb la funció de traçabilitat integrada.
Un punt important a destacar és quela manera de mantenir i actualitzar la vostra matriu de traçabilitat determina l’eficàcia del seu ús. Si no s'actualitza sovint o s'actualitza incorrectament, l'eina suposa una càrrega en lloc de ser una ajuda i crea la impressió que l'eina per si mateixa no és digne d'utilitzar-la.
Conclusió
La matriu de traçabilitat dels requisits és el mitjà per fer-ho mapa i traça tots els requisits del client amb els casos de prova i els defectes descoberts. És un document únic que serveix per al propòsit principal que no es perdin casos de prova i, per tant, es cobreix i prova totes les funcionalitats de l'aplicació.
Una bona 'cobertura de les proves', que està prevista amb antelació, evita tasques repetitives en les fases de proves i defectes. Un alt recompte de defectes indica que les proves es fan bé i, per tant, la 'qualitat' de l'aplicació augmenta. De la mateixa manera, un recompte de defectes molt baix indica que la prova no es fa fins a la marca i això dificulta la 'qualitat' de l'aplicació de manera negativa.
Si la cobertura de la prova es realitza a fons, es pot justificar un baix recompte de defectes i es pot considerar que aquest recompte de defectes és estadístic de suport i no com a principal. La qualitat d'una aplicació es denomina 'Bona' o 'Satisfactòria' quan es maximitza la cobertura de la prova i es minimitza el recompte de defectes.
Sobre l'autor: El membre de l’equip de STH, Urmila P., és un professional amb experiència en control de qualitat alta qualitat habilitats de prova i seguiment de problemes.
Heu creat una matriu de traçabilitat de requisits en els vostres projectes? Què tan similar o diferent és del que hem creat en aquest article? Comparteix les teves experiències, comentaris, pensaments i comentaris sobre aquest article a través dels teus comentaris.
Lectura recomanada
- Exemple de plantilla de pla de prova de programari amb format i contingut
- Com escriure un informe de resum eficaç de la prova efectiva [Descàrrega d'informe de mostra]
- Exemple de plantilla de cas de prova amb exemples de casos de prova [Descarregar]
- Plantilla de mostra per a l'informe de prova d'acceptació amb exemples
- Com escriure un document d'estratègia de prova (amb una plantilla d'estratègia de prova de mostra)
- Com provar l'especificació de requisits de programari (SRS)?
- Top 20+ millors eines de gestió de requisits (llista completa)
- Les llistes de comprovació de proves de programari de qualitat (llistes de comprovació de mostra incloses)