Kuten nimestä voi päätellä, tätä matriisia käytetään seuraamaan ja tarkistamaan, täyttyvätkö nykyiset projektin vaatimukset. Asiakirjaa, jota käytetään kahden perustason asiakirjojen rinnakkaisliittämiseen, jotka vaativat useista moneen -suhteita kyseisen suhteen täydellisyyden tarkistamiseksi, kutsutaan nimellä vaatimusten jäljitettävyysmatriisi .

Sisällysluettelo

• Vaatimukset jäljitettävyysmatriisi (RTM)
• Vaatimustyypit Jäljitettävyysmatriisi
  • 1. Jäljitettävyys eteenpäin
  • 2. Taaksepäin tai käänteinen jäljitettävyys
  • 3. Kaksisuuntainen tai eteenpäin ja taaksepäin jäljitettävyys
• Vaatimusten jäljitettävyysmatriisiin sisältyvät parametrit
• Vaatimusten tärkeys Jäljitettävyysmatriisi
• Esimerkki vaatimusten jäljitettävyysmatriisista
• Testin kattavuus
• Vaatimusmääritystyypit
  • 1. Software Requirements Specification Document (SRS)
  • 2. Käytä tapausasiakirjaa
  • 3. Liiketoiminnan vaatimukset
  • 4. Käyttäjien tarinat
  • 5. Project Requirement Documents (PRD)
  • 6. Vian varmistusasiakirja
• Vaatimusten jäljitettävyysmatriisin hyödyllisyys esimerkin avulla
  • 1. Toteutus
  • 2. Onko vaatimus välttämätön?
  • 3. Vaatimuksen tulkitseminen
  • 4. Suunnittele päätökset vaatimuksen täytäntöönpanon jälkeen
  • 5. Kaikki vaatimukset kohdistettu
• Testin kattavuuden ja RTM:n edut
• Haasteet testata kattavuutta
  • Viestintä
  • Testiskenaarioiden priorisointi
  • Tehokas testistrategia
  • Prosessin toteutus
  • Resurssien saatavuus
• Viimeiset sanat
• Suositellut artikkelit

Vaatimukset Traceability Matrix (RTM)

Asiakirjaa, joka kaappaa kaikki asiakkaan ehdottamat vaatimukset ja jäljittää vaatimukset yhdeksi asiakirjaksi kartoittamalla ja seuraamalla testitapauksia käyttäjän vaatimusten kanssa, kutsutaan vaatimusten jäljitettävyysmatriisiksi.

Vaatimukset Jäljitettävyysmatriisiasiakirja toimitetaan ohjelmistokehityksen elinkaaren lopussa.

Asiakirjojen ensisijaisena tarkoituksena on varmistaa, että kaikki käyttäjävaatimukset tarkistetaan testitapausten avulla ja ettei ohjelmistotestauksen aikana ole jätetty tarkistamatta mitään toimintoja.

Testauksen 100 %:n kattavuuden tulee olla jokaisen testaustoimen painopiste, eli kaikki testattava tulee testata.

Vaatimustyypit Jäljitettävyysmatriisi

Vaatimus jäljitettävyys voidaan luokitella laajasti kolmeen pääkomponenttiin. He ovat:

1. Jäljitettävyys eteenpäin

Tämä matriisi varmistaa, että kaikkia vaatimuksia sovelletaan tuotteeseen ja että se testataan perusteellisesti.

Se myös tarkistaa tuotteen suunnan ja varmistaa, että se etenee oikean ohjelmiston/tuotteen haluttuun suuntaan.

Vaatimukset kartoitetaan testitapauksiin.

2. Taaksepäin tai käänteinen jäljitettävyys

Tämä matriisi varmistaa, että testaajat eivät laajenna projektin laajuutta lisäämällä koodia, testejä, suunnitteluelementtejä tai muuta tarpeetonta työtä, jota ei ole ennalta määritelty käyttäjävaatimuksissa.

Se myös varmistaa, että nykyinen tuote pysyy oikeilla jäljillä.

Testitapaukset on kartoitettu vaatimusten mukaan.

3. Kaksisuuntainen tai eteenpäin ja taaksepäin jäljitettävyys

Se varmistaa, että kaikki käyttäjien vaatimukset katetaan kaikissa testitapauksissa ja analysoi käyttäjien vaatimusten muutokset, jotka johtuvat tuotteen vioista ja päinvastoin.

Vaatimusten jäljitettävyysmatriisiin sisältyvät parametrit

Vaatimusten jäljitettävyysmatriisia kehittävä testaustiimi voi valita saatavilla olevia testinhallintatyökaluja sen lisäksi, että se ylläpitää erikseen Excel-taulukkoa.

RTM:n Excel-arkki sisältää kolme parametria:

• Vaatimustunnus
• Vaatimustyyppi ja kuvaus
• Testitapaukset tilalla

Edellä mainitun lisäksi vaatimusjäljitettävyysmatriisi voi sisältää myös:

• Vaatimus katetaan testitapausten lukumäärän mukaan.
• Käyttäjän hyväksyntätestin tila, jos käyttäjä on sen tehnyt.
• Suunnittelu ja suoritustila tietyille testitapauksille.
• Liittyvät vikoja ja nykytilaa mainitaan.

Ei olisi väärin sanoa, että RTM on yhden luukun palvelu kaikille testitoiminnoille.

Vaatimusten tärkeys Jäljitettävyysmatriisi

Käyttäjävaatimusten perusteellinen analyysi ja positiivisten ja negatiivisten testitapausten luominen tulee varmistaa ottamalla huomioon kaikki mahdolliset skenaariot tai testitapaukset.

Joten miten voidaan varmistaa, että mitään vaatimusta ei ole jätetty pois testauksen aikana?

Yksinkertaisin tapa on jäljittää vaatimukset ja niitä vastaavat testitapaukset ja testiskenaariot yksinkertaistetulla tavalla.

Jokaisen testaajan on varmistettava, että toimitettava tuote on virheetön ja täyttää kaikki käyttäjän vaatimukset.

Tämän tavoitteen saavuttamiseksi laadunvarmistustestaajien tulee ymmärtää vaatimukset perusteellisesti ja pystyä jakamaan vaatimukset eri skenaarioiksi ja sitten luomaan kyseisille skenaarioille testitapauksia.

Kun testitapaukset on tehty, ne on suoritettava yksitellen, ja myös onnistumis- ja epäonnistumisraportit tulee luoda.

Täällä vaatimukset jäljitettävyysmatriisi tulee näkyviin.

Matriisi on vain tyypillinen laskentataulukko, joka sisältää käyttäjän vaatimukset ja kaikki mahdolliset testiskenaariot, testitapaukset ja niiden nykyiset onnistumisen tai epäonnistumisen tilat.

RTM:n avulla testaustiimi ymmärtää ja jäljittää paremmin erilaisia ​​testaustoimintoja, joita ohjelmistolle tai tuotteelle on tehtävä.

Esimerkki vaatimusten jäljitettävyysmatriisista

Tarkastellaanpa esimerkkiä käyttäjävaatimusmäärityksestä, joka edellyttää a Aseta muistutus Task Manager -ohjelmistossa .

Siten, Liiketoiminnan vaatimus (BR1) tulee olemaan: Aseta muistutus -painikkeen pitäisi olla käytettävissä.

The testiskenaario (TS1) Vaatimus on: Aseta muistutus -painike.

Tässä skenaariossa on kaksi testitapausta:

Testitapaus 1 (TS1.TC1): Muistutusasetus on otettu käyttöön ja toimii onnistuneesti.Testitapaus 2 (TS1.TC2): Muistutusasetus on poistettu käytöstä onnistuneesti.

Kun yllä olevat testitapaukset on otettu käyttöön, ne voivat onnistua tai epäonnistua.

Epäonnistumisen sattuessa löydetyt viat voidaan myös listata ja kartoittaa liiketoimintavaatimuksen, testiskenaarion ja testitapausten rinnalle.

Oletetaan, että TS1.TC1 epäonnistuu, eli käyttäjä ei voi asettaa muistutusta päivittäisistä tehtävistä, vaikka vaihtoehto on käytössä. Vika voidaan tällöin kirjata Requirement Traceability Matrixiin.

Oletetaan, että vikatunnus on D1. Sitten tämä myös kartoitetaan BR1:n, TS1:n ja TS1.TC1:n kanssa.

Taulukkomuodossa RTM näyttää jokseenkin tältä:

Vastaavasti voidaan lisätä muita rivejä muille liiketoimintavaatimuksille, BR2, BR3 ja muille, sekä niiden testitapaukset, testiskenaariot ja kartoitetut viat.

Testin kattavuus

Testin kattavuus on termi, joka määrittää, mitkä käyttäjävaatimukset on testattava ja varmennettava, kun testaus alkaa.

Se tarkistaa, suoritetaanko testitapaukset oikein vai ei, jotta ohjelmistosovelluksen täydellisyys voidaan varmistaa minimaalisilla tai NIL-virheillä.

Testin 100 % kattavuus voidaan saavuttaa käyttämällä Requirement Traceability -toimintoa seuraavasti:

Sisäiset viat tulee kartoittaa suunniteltuihin testitapauksiin.

Asiakkaan ilmoittamat viat (CRD) tulee yhdistää yksittäisiin testitapauksiin.

Vaatimusmääritystyypit

1. Software Requirements Specification Document (SRS)

Se on yksityiskohtainen asiakirja, joka sisältää kaikki tiedot asiakkaan tai sidosryhmien toiminnallisista ja ei-toiminnallisista vaatimuksista.

SRS on ohjelmistosovellusten suunnittelun ja kehittämisen perusasiakirja.

2. Käytä tapausasiakirjaa

Käyttötapausdokumentti auttaa ohjelmiston suunnittelussa ja toteutuksessa liiketoiminnan tarpeiden mukaan.

Se näyttää yksityiskohtaisen työnkulun siitä, kuinka kukin tehtävä on suoritettava.

Järjestelmän ja käyttäjän väliset vuorovaikutukset kartoitetaan Käyttötapausasiakirjassa käyttämällä toimijoita ja tapahtumia, jotka vaaditaan vaaditun tavoitteen saavuttamiseksi.

3. Liiketoiminnan vaatimukset

Business Requirements Document (BRS) on korkean tason vaatimuslista, joka sisältää lyhyen asiakasvuorovaikutuksen jälkeen todelliset asiakkaiden vaatimukset.

Liikeanalyytikko tai projektiarkkitehti on yleensä se, joka muodostaa tämän asiakirjan. SRS on johdettu BRS:stä.

4. Käyttäjien tarinat

Ketterän kehitysmenetelmän tapauksessa käyttäjätarinalla kuvataan erilaisia ​​ohjelmiston ominaisuuksia loppukäyttäjien näkökulmasta.

Nämä tarinat yksinkertaistavat käyttäjien vaatimuksia määrittelemällä erityyppiset käyttäjät ja heidän vaatimukset mitä ominaisuudelle ja miksi.

Käyttäjän tarinat ja ketterä kehitys on ohjelmistoteollisuuden uusi suuntaus, ja ne siirtyvät kohti heitä ja vastaavia ohjelmistotyökaluja tarvitaan käyttäjien vaatimusten tallentamiseen.

5. Project Requirement Documents (PRD)

Koko projektitiimille luotu referenssidokumentti, joka kertoo jokaiselle jäsenelle tuotteiden toiminnasta, on PRD.

Siinä on neljä osiota:

• Tuotteen käyttötarkoitus
• Tuotteen ominaisuudet
• Vapautuskriteerit
• Budjetointi ja projektin aikataulu

6. Vian varmistusasiakirja

Testausryhmä ylläpitää dokumenttia, joka sisältää vikoja koskevat tiedot vikojen korjaamista ja uudelleentestausta varten.

Tämä Vianvarmistusasiakirja varmistaa, onko viat korjattu vai ei; ne testataan uudelleen eri käyttöjärjestelmissä tai laitteissa tai erilaisilla järjestelmäkokoonpanoilla.

Jos projektissa on luotettava viankorjaus- ja varmistusvaihe, Vianvarmistusasiakirja on välttämätön ja hyödyllinen.

Vaatimusten jäljitettävyysmatriisin hyödyllisyys esimerkin avulla

Kun otetaan huomioon edellinen asetettu ilmoitus tehtävänhallintaohjelmistossa, katsotaan kuinka vaatimuksen jäljitettävyysmatriisi voi auttaa.

1. Toteutus

Vaatimus: Ota käyttöön Aseta ilmoitus -painike tehtävänhallintasovelluksessa.

Toteutus: Kun käyttäjä on kirjautunut sisään, asetettu ilmoituskuvakkeen pitäisi olla näkyvissä ja käytettävissä kojelaudassa.

2. Onko vaatimus välttämätön?

Vaatimus: Käytä Aseta ilmoitus -painiketta vain tietyille käyttäjille.

Toteutus: Käyttäjä voi valita, ottaako tehtäviensä ilmoitukset käyttöön automaattisesti vai manuaalisesti vai ei ollenkaan.

3. Vaatimuksen tulkitseminen

Vaatimus: Aseta ilmoitus -painike sisältää päivämäärän ja kellonajan, jolloin ilmoitus asetetaan.

Toteutus: Kun käyttäjä napsauttaa Aseta ilmoitus -kuvaketta/painiketta, mikä on käytettävissä?

• Valitse tehtävä, jolle haluat asettaa muistutuksen.
• Päivämäärä ja aika voidaan asettaa käyttäjien tarpeiden mukaan.

4. Suunnittele päätökset vaatimuksen täytäntöönpanon jälkeen

Vaatimus: Tehtävät, poista, muokkaa, uudet, asetukset, aseta ilmoitus, tulee olla näkyvissä ja käytettävissä.

Toteutus: Kaikki kohteet, joiden on oltava näkyvissä, tulee järjestää kehyksen mukaan taulukkomuodossa.

5. Kaikki vaatimukset kohdistettu

Vaatimus: 'Mykistä ilmoitus' -vaihtoehto tulee tarjota.

Toteutus: Jos 'Aseta ilmoitus' -vaihtoehto on käytettävissä, 'Mykistä ilmoitus' pitäisi myös olla käytettävissä ja toimia tarkasti. Jos 'mykistä ilmoitus' -vaihtoehto toimii oikein, kaikki asetetut ilmoitukset voidaan helposti nollata tai mykistää, kun tehtävät on suoritettu tai käyttäjien vaatimusten mukaisesti.

Testin kattavuuden ja RTM:n edut

• Vaatimukset Traceability Matrix korostaa asiakirjan puuttuvat vaatimukset ja epäjohdonmukaisuudet. Käyttäjän pitäisi saada mitä hän pyysi ilman vähemmän tai lisätoimintoja.
• Yleiset viat, toteutus ja tila esitetään liiketoiminnan vaatimusten näkökulmasta.
• 100 % testin kattavuus on vahvistettu.
• Testitapausten uudelleenkäynnin ja uudelleenkäsittelyn vaikutus QA-tiimin työhön analysoidaan ja arvioidaan RTM:n avulla.
• Käyttäjien vaatimusten toteuttaminen prioriteettien mukaan on välttämätöntä. Ensisijaiset vaatimukset tulisi toteuttaa ensin, jotta lopputuote voidaan toimittaa ensisijaisen prioriteetin vaatimuksilla ja aikataulun mukaisesti.
• Testisuunnitelmat ja testitapaukset on kirjoitettu tarkasti sen varmistamiseksi, että kaikki sovelluksen vaatimukset täyttyvät.
• Asiakkaan muutospyynnön tapauksessa kaikkia siihen liittyviä toimintoja voidaan muokata vastaavasti ilman, että mitään jää huomiotta.

Testin kattavuuden haasteet

Viestintä

Sidosryhmien vaatimista muutoksista tulee ilmoittaa välittömästi kehitys- ja testaustiimeille kehitys- ja testaussyklin aikaisemmissa vaiheissa. Jos se viivästyy, se vaatii turhaa aikaa ja vaivaa, mikä viivästyttää projektia ja lisää kustannuksia.

Testiskenaarioiden priorisointi

Testiskenaariot tulee priorisoida käyttäjien vaatimusten mukaisesti ja toimittaa sellaisinaan viivästysten välttämiseksi. Kaikkia testiskenaarioita on mahdotonta toteuttaa, joten on päätettävä, mitä testiskenaarioita on testattava ja missä järjestyksessä.

Tehokas testistrategia

Tehokas testauskattavuuden toteutusstrategia on se, joka varmistaa sovelluksen hyvän laadun, jota ylläpidetään jonkin aikaa

Prosessin toteutus

Testausprosessia määriteltäessä tulee ottaa huomioon tekijät, kuten tiimitaidot, seuratut organisaatiorakenteet ja prosessit, aiemmat kokemukset, tekninen infrastruktuuri, toteutus, aika ja resurssit, kustannuksiin liittyvät projektiarviot ja tiimin sijainti aikavyöhykkeiden mukaan.

Näin tiimi voi varmistaa, että prosessi etenee sujuvasti ja jokainen projektissa oleva henkilö pysyy samalla sivulla.

Resurssien saatavuus

Ammattitaitoiset verkkoaluekohtaiset testaajat ja testaajien käyttämät testaustyökalut ovat kahdenlaisia ​​resursseja, joita tarvitaan houkuttelevien testiskenaarioiden ja komentosarjojen kirjoittamiseen ja toteuttamiseen.

Nämä resurssit voivat varmistaa oikea-aikaisen toimituksen ja sovelluksen riittävän toteutuksen käyttäjälle.

Viimeiset sanat

RTM tai Requirement Traceability Matrix on yksittäinen asiakirja, jonka ensisijaisena tarkoituksena on varmistaa, että mitään testitapauksia ja testiskenaarioita ei jätetä pois. Kaikki toiminnot on testattu ja katettu onnistuneesti. Tätä tarkoitusta varten asiakkaan vaatimukset kartoitetaan ja jäljitetään dokumenttiin.

Vikamäärä määrittää suoritettavan testauksen tyypin. Jos luku on korkea, se tarkoittaa hyödyllistä laatutestausta ja alhainen luku osoittaa riittämättömän laadun testauksen.

Kun se tehdään perusteellisesti ja suunnittelee etukäteen, Test Coverage johtaa vähemmän toistuviin tehtäviin ja virheisiin testausvaiheissa, mikä johtaa alhaiseen virheiden määrään.

Siten ohjelmisto tai tuote on hyödyllinen, jos vika on minimoitu ja testin kattavuus on maksimoitu.

Suositellut artikkelit

• Mikä on Unsecapp.exe ja onko se turvallista?
• 15 parasta UML-kaaviotyökalua ja ohjelmistoa
• [KORJAATTU] Windows ei voi käyttää määritettyä laitetta, polkua tai tiedostovirhettä
• 16 korjausta Windows Updatelle, joka ei toimi Windowsissa
• 4 korjausta AMD Radeon -asetukset eivät avaudu
• Zoom-kuvakaappaustyökalu: vinkkejä ja temppuja