Riskiperusteinen testaus: lähestymistapa, matriisi, prosessi ja esimerkit

⚡ Älykäs yhteenveto

Riskiperusteisessa testauksessa jokainen ominaisuus luokitellaan sen epäonnistumisen todennäköisyyden ja epäonnistumisen aiheuttamien vahinkojen perusteella, ja sitten käytettävissä oleva testaustyö käytetään ensin korkeimman pistemäärän saaneisiin kohteisiin prioriteettijärjestyksessä.

  • 🔘 Ydinkaava: Riskiluokitus on yhtä kuin todennäköisyys kerrottuna vakavuudella, mikä muuntaa subjektiivisen huolen vertailukelpoiseksi luvuksi.
  • ☑️ Riskirekisteri: Yksi laskentataulukko sisältää jokaisen tunnistetun riskin, sen omistajan, altistuksen, testaustavoitteen ja vaiheen, jossa sitä käsitellään.
  • Testin prioriteettinumero: Todennäköisyys, seuraukset ja testin tehokkuus kerrotaan pistemääräksi välillä 1–125, joka asettaa suoritusjärjestyksen.
  • 🧪 Viisivaiheinen prosessi: Riskien tunnistaminen, riskianalyysi, riskiin reagointi, testausalueping ja testausprosessin määrittely suoritetaan peräkkäin.
  • 🛠️ Jokainen testitaso: Lähestymistapa soveltuu komponentti-, integraatio-, järjestelmä- ja hyväksymistestaukseen, ei pelkästään järjestelmätestaukseen.
  • 📊 Jäännösriski: Testaustulosten pohjalta tehdään tietoon perustuva julkaisupäätös mittaamalla sitä, mitä testaamatta jää suorituksen jälkeen.

Riskiperusteisen testauksen matriisikarttaping todennäköisyys vakavuuden funktiona testaustyön priorisoimiseksi

Riskipohjainen testaus

Risk Based Testing (RBT) on ohjelmistotestaustyyppi, joka perustuu riskin todennäköisyyteen. Se sisältää riskin arvioinnin ohjelmiston monimutkaisuuden, liiketoiminnan kriittisyyden, käyttötiheyden ja todennäköisimmin ongelman sisältävien alueiden perusteella. vikaRiskiperusteisessa testauksessa priorisoidaan ohjelmistosovelluksen ominaisuuksien ja toimintojen testausta, jotka ovat vaikuttavimpia ja joissa on todennäköisemmin virheitä.

Riski on epävarman tapahtuman esiintyminen, jolla on positiivinen tai negatiivinen vaikutus projektin mitattavissa oleviin onnistumiskriteereihin. Se voi olla menneisyydessä sattunut tapahtuma, nykyinen tapahtuma tai jokin, joka voi tapahtua tulevaisuudessa. Näillä epävarmoilla tapahtumilla voi olla vaikutusta projektin kustannuksiin, liiketoimintaan, teknisiin tavoitteisiin ja laatuun.

Riskit voivat olla positiivisia tai negatiivisia.

  • Positiiviset riskit kutsutaan mahdollisuuksiksi ja avuksi liiketoiminnan kestävyydessä. Esimerkkejä ovat investoinnit uuteen projektiin, liiketoimintaprosessien muuttaminen ja kehittäminenping Uudet tuotteet.
  • Negatiiviset riskit kutsutaan uhkiksi, ja projektin onnistumisen varmistamiseksi on toteutettava suosituksia niiden minimoimiseksi tai poistamiseksi.

Koska tekniikka kohdistaa työmäärää uuden testitason lisäämisen sijaan, se sijoittuu muiden päälle. ohjelmistotestauksen tyypit sen sijaan, että korvaisi jonkun niistä.

Milloin riskiperusteinen testaus tulisi ottaa käyttöön

Riskiperusteinen testaus voidaan toteuttaa

  • Projektit, joilla on aika-, resurssi- tai budjettirajoitteita.
  • Projektit, joissa riskipohjaista analyysiä voidaan käyttää haavoittuvuuksien havaitsemiseen SQL-injektiohyökkäykset.
  • Tietoturvatestaus pilvipalveluympäristöissä.
  • Uudet projektit, joihin liittyy korkeat riskitekijät, kuten kokemuksen puute käytetyistä teknologioista tai liiketoimintaosaamisen puute.
  • Inkrementaaliset ja iteratiiviset toimitusmallit.

Riskienhallintaprosessi

Ymmärrämme nyt riskienhallintaprosessiin liittyvät vaiheet.

Riskien tunnistaminen

Riskien tunnistaminen voidaan tehdä riskityöpajojen, tarkistuslistojen, aivoriihien, haastattelujen, Delphi-tekniikan, syy-seuraus-kaavioiden, aiemmista projekteista opittujen kokemusten, perussyyanalyysin sekä toimiala- ja aiheasiantuntijoihin yhteydenoton avulla.

Riskirekisteri on laskentataulukko, joka sisältää luettelon tunnistetuista riskeistä, mahdollisista vastatoimista ja perimmäisistä syistä. Sitä käytetään seurantaan ja track riskit (sekä uhat että mahdollisuudet) koko projektin elinkaaren ajan. Riskienhallintastrategioita voidaan käyttää sekä positiivisten että negatiivisten riskien hallintaan.

Riskienjakorakenteella on tärkeä rooli riskisuunnittelussa. Se auttaa tunnistamaan riskialttiit alueet ja tukee tehokasta arviointia ja riskien seurantaa projektin aikana. Se auttaa varaamaan riittävästi aikaa ja resursseja riskienhallintatoimille ja luokittelemaan monia lähteitä, joista projektin riskit voivat syntyä.

Alla oleva esimerkki havainnollistaa, miten riskienhallintajärjestelmä ryhmittelee riskit luokkiin siten, ettei yhtäkään riskin lähdettä jää huomiotta.

Riskien jakautumisen esimerkki Rakenneryhmäping projektiriskit kategorisoituna riskisuunnittelua varten

Riskianalyysi (sisältää kvantitatiivisen ja laadullisen analyysin)

Kun mahdollisten riskien luettelo on tunnistettu, seuraava vaihe on niiden analysointi ja riskien suodattaminen merkityksen mukaan. Yksi laadullisista riskianalyysitekniikoista on riskimatriisi (käsitellään myöhemmässä osiossa). Tätä tekniikkaa käytetään riskin todennäköisyyden ja vaikutuksen määrittämiseen.

Riskienhallinnan suunnittelu

Analyysin perusteella voimme päättää, vaativatko riskit reagointia. Esimerkiksi jotkut riskit vaativat reagoinnin projektisuunnitelmassa, jotkut projektin seurannassa ja jotkut eivät vaadi reagointia ollenkaan.

Riskin omistaja on vastuussa vaihtoehtojen tunnistamisesta, joilla vähennetään kohdistettujen riskien todennäköisyyttä ja vaikutusta.

Riskien minimointi on riskinhallintamenetelmä, jota käytetään mahdollisten uhkien haitallisten vaikutusten lieventämiseen. Tämä voidaan tehdä poistamalla riskit tai vähentämällä ne hyväksyttävälle tasolle. Alla oleva kaavio sijoittaa riskinhallintasuunnittelun laajempaan riskienhallintasykliin.

Riskienhallinnan suunnitteluvaihe, joka on sijoitettu riskienhallintaprosessiin

Riskivalmius

Varautumissuunnitelmaa voidaan kuvata epävarman tapahtuman mahdollisuutena, jonka vaikutus on tuntematon tai arvaamaton. Varautumissuunnitelma tunnetaan myös toimintasuunnitelmana tai varasuunnitelmana pahimman mahdollisen skenaarion varalle. Toisin sanoen se määrittää, mitä toimenpiteitä voidaan tehdä, kun arvaamaton tapahtuma toteutuu.

Riskien seuranta ja valvonta

Riskienhallinta- ja seurantaprosessia käytetään seuraaviin tarkoituksiin: tractunnistettujen riskien seuraaminen, jäännösriskien seuranta, uusien riskien tunnistaminen, riskirekisterin päivittäminen, muutosten syiden analysointi, riskinhallintasuunnitelman toteuttaminen ja riskien laukaisevien tekijöiden seuranta. Tämän jälkeen arvioidaan niiden tehokkuutta riskin vähentämisessä.

Tämä voidaan saavuttaa riskien uudelleenarvioinneilla, riskiauditoinneilla, varianssi- ja trendianalyysillä, teknisen suorituskyvyn mittauksella, tilapäivityskokouksilla ja takautuvasti pidettävillä kokouksilla.

Alla oleva taulukko antaa tietoa riskien seurannan ja valvonnan syötteistä, työkaluista ja tuotoksista.

Panokset riskien seurantaan ja valvontaan Riskienseurannan ja -hallinnan työkalut ja tekniikat Riskien seurannan ja valvonnan tulokset
Riskienhallintasuunnitelma Projektin riskienhallintatarkastukset Ratkaisusuunnitelmat
Riskivastaussuunnitelma Säännölliset projektin riskiarvioinnit Korjaava toimenpide
Projektin viestintäsuunnitelma Ansaitun arvon analyysi Hankkeen muutospyynnöt
Lisäriskien tunnistaminen ja analysointi Teknisen suorituskyvyn mittaus Riskienhallinnan suunnitelman ja riskien tunnistamisen tarkistuslistan päivitykset
Laajuuden muutokset Lisäriskien hallintasuunnitelma Riskitietokanta

Meidän on muistettava, että riski kasvaa teknologian muutosten, projektin koon, projektin keston (pidempi projektin aikataulu), rahoittavien tahojen määrän, projektiarvioiden, työmäärän ja sopivien taitojen puutteen myötä.

Riskiperusteinen testausmenetelmä

Yllä oleva hallintaprosessi ruokkii alla olevaa testausmenetelmää. Jokainen numeroitu vaihe tuottaa syötteen, jonka seuraava vaihe käyttää.

  1. Analysoi vaatimukset.
    • Dokumentit (SRS, FRS, käyttötapaukset) tarkastetaan. Tarkastuksen tarkoituksena on löytää ja poistaa virheitä ja epäselvyyksiä.
    • Vaatimusten hyväksyminen on yksi riskien vähentämistekniikoista, joilla vältetään myöhäisten muutosten tekeminen projektiin. Kaikki vaatimukseen tehtävät muutokset dokumentin perustason määrittämisen jälkeen edellyttävät muutoshallintaprosessia ja sitä seuraavia hyväksyntöjä.
  2. Arvioi riskit laskemalla kunkin vaatimuksen todennäköisyyden ja vaikutuksen projektiin ottaen huomioon määritellyt kriteerit, kuten kustannukset, aikataulu, resurssit, laajuus, tekninen suorituskyky, turvallisuus, luotettavuus ja monimutkaisuus.
    • Tunnista epäonnistumisen todennäköisyys ja korkean riskin alueet. Tämä voidaan tehdä riskinarviointimatriisin avulla.
    • Käytä riskirekisteriä tunnistettujen riskien listaamiseen. Päivitä, seuraa ja tracarvioi riskit säännöllisesti säännöllisin väliajoin.
    • Riskiprofilointi on tehtävä tässä vaiheessa riskikapasiteetin ja riskinsietokyvyn ymmärtämiseksi.
  3. Priorisoi vaatimukset luokituksen perusteella.
    • Riskiperusteinen testausprosessi on määritelty.
    • Erittäin kriittisiä ja keskisuuria riskejä voidaan harkita lieventämissuunnitelmien, toteutuksen ja edistymisen seurannan yhteydessä. Matalat riskit voidaan pitää seurantalistalla.
    • Riskitietojen laadun arviointi tehdään tietojen laadun analysoimiseksi.
  4. Suunnittele ja määrittele testit luokituksen mukaisesti.
    • Käytä sopivaa testaustapaa ja testisuunnittelutekniikoita siten, että korkeimman riskin kohteet testataan ensin. Korkean riskin kohteita voi testata resurssi, jolla on hyvä toimialaosaaminen ja -kokemus.
    • Testien suunnittelussa voidaan käyttää erilaisia ​​tekniikoita, kuten esim. päätöstaulukko tekniikkaa korkean riskin testausaineisiin ja vain ekvivalenssiositus vähäriskisille testituotteille.
    • Testata tapauksia on myös suunniteltu kattamaan useita toimintoja ja kokonaisvaltaisia ​​liiketoimintaskenaarioita.
    • Valmistele testidata, testiolosuhteet ja testialusta.
  5. Revkatso testidokumentaatiota — testaussuunnitelmat, testausstrategia, testitapaukset, testiraportit ja kaikki muut testaustiimin luomat asiakirjat.
    • Vertaisarviointi on tärkeä askel vikojen tunnistamisessa ja riskien vähentämisessä.
  6. Suorita testiajoja ja laatutarkastuksia tuloksille.
    • Testitapaukset suoritetaan riskikohteen prioriteetin mukaan.
    • Ylläpitää tracriskikohteiden, niitä käsittelevien testien, näiden testien tulosten ja testauksen aikana löydettyjen vikojen välinen yhteensopivuus. Kaikki oikein toteutetut testausstrategiat vähentävät laaturiskejä.
    • Riskiperusteista testausta voidaan käyttää kaikilla testaustasoilla — komponentti, integraatio, järjestelmä ja hyväksymistestaus.
    • Järjestelmätasolla meidän on keskityttävä siihen, mikä sovelluksessa on tärkeintä. Tämä voidaan määrittää tarkastelemalla toimintojen näkyvyyttä, käyttötiheyttä ja mahdollisia epäonnistumisen kustannuksia.
    • Poistumiskriteerien arviointi: kaikki korkean riskin alueet testattu täysin, ja jäljellä on vain pieniä jäännösriskejä.
  7. Raportoi riskiperusteisten testien tulokset ja analysoi mittareita.
    • Arvioi uudelleen olemassa olevat riskitapahtumat ja uudet riskitapahtumat avainindikaattoreiden perusteella.
    • Päivitä riskirekisteri.
    • Varautumissuunnitelmat toimivat vara- tai hätäsuunnitelmana suurille riskeille.
    • Vika-analyysiä ja vikojen ehkäisyä käytetään vikojen poistamiseen.
    • Uudelleentestaus ja Regressiotestaus validoi vikakorjaukset ennalta lasketun riskianalyysin perusteella, ja korkean riskin alueet tulisi käsitellä intensiivisimmin.
    • Riskiperusteinen automaatiotestaus, jos mahdollista.
    • Jäännösriskin laskenta.
  8. Seuraa ja hallitse riskejä.
    • Poistumiskriteerit tai valmistumiskriteerit voidaan määritellä erikseen eri riskitasoille. Kaikkiin keskeisiin riskeihin on puututtu asianmukaisilla toimenpiteillä tai varautumissuunnitelmilla, ja riskille altistuminen on projektille sovitulla hyväksyttävällä tasolla tai sen alapuolella.
    • Riskiprofiilien uudelleenarviointi ja asiakaspalaute.

Riskiperusteisen testauksen lähestymistapa järjestelmätestiin

  1. Teknisen järjestelmän testi — Tätä kutsutaan ympäristötestiksi ja integrointitestiksi. Ympäristötesti sisältää testauksen kehitys-, testaus- ja tuotantoympäristöissä.
  2. Toiminnallisen järjestelmän testi — Kaikkien toimintojen, ominaisuuksien, ohjelmien ja moduulien testaus. Tämän testin tarkoituksena on arvioida, täyttääkö järjestelmä sille asetetut vaatimukset.
  3. Ei-toiminnallinen järjestelmätesti — Ei-toiminnallisten vaatimusten testaus: suorituskyky, kuormituskokeet, stressitestit, konfigurointitestit, tietoturvatestit, varmuuskopiointi ja elpyminen menettelytavat ja dokumentaatio (järjestelmä-, käyttö- ja asennusdokumentaatio).

Alla oleva kaavio antaa selkeän yleiskuvan edellä mainitusta prosessista.

Riskiperusteisen testauksen lähestymistapa järjestelmätestaukseen jaettuna teknisiin, toiminnallisiin ja ei-toiminnallisiin järjestelmätesteihin

Järjestelmätestaus sisältää sekä toiminnallisia testejä että ei-toiminnallisia testejä.

Toiminnallinen testaus varmistaa, että tuote tai sovellus täyttää asiakkaan ja liiketoiminnan vaatimukset. Toisaalta, ei-toiminnallinen testaus tarkistetaan, täyttääkö tuote asiakkaan odotukset laadun, luotettavuuden, käytettävyyden, suorituskyvyn ja yhteensopivuuden suhteen.

Riskiperusteisen testauksen tekeminen: Täydellinen prosessi

Tässä osiossa käsitellään riskiperusteista testausprosessia, joka toimii viidessä vaiheessa.

  1. Riskien tunnistaminen
  2. Riskianalyysi
  3. Riskivastaus
  4. Testi Scoping
  5. Testiprosessin määritelmä

Viisi vaihetta kytkevät toisiinsa alla esitetyllä tavalla.

Riskiperusteisen testausprosessin viisi vaihetta riskien tunnistamisesta testausprosessin määrittelyyn

  1. Tässä prosessissa riskit tunnistetaan ja luokitellaan, laaditaan riskiluetteloluonnos ja tehdään riskilajittelu merkittävien riskien tunnistamiseksi.
  2. Riskeihin reagointiin kuuluu testaustavoitteiden muotoileminen riskien perusteella ja sopivien tekniikoiden valitseminen siten, että testaustoiminta tai testaustekniikka täyttää nämä testaustavoitteet.
  3. Dokumentoidut riippuvuudet, vaatimukset, kustannukset ja ohjelmistotestaukseen tarvittava aika otetaan huomioon testien tehokkuuspisteiden laskennassa.
  4. Testaa scoping on arviointitoiminta, joka vaatii kaikkien sidosryhmien ja teknisen henkilöstön osallistumista. On tärkeää noudattaa sovittua riskien laajuutta. Näihin riskeihin on puututtava testaamalla, ja kaikkien jäsenten on hyväksyttävä heille osoitetut vastuut ja näille toimille osoitettu budjetti.
  5. Kun testauksen laajuus on määritetty, kunkin testausvaiheen testaustavoitteet, oletukset ja riippuvuudet on koottava standardimuotoon.

Alla oleva esimerkki kuvaa jokaisen vaatimuksen siihen liittyvän riskin ja sitä vastaavan testaustavoitteen.

Toiminnalliset vaatimukset F1–F3 ja ei-toiminnalliset vaatimukset N1 ja N2 on kartoitettu niihin liittyviin riskeihin ja testaustavoitteisiin

Tarkastellaan toiminnallisia vaatimuksia F1, F2 ja F3 sekä ei-toiminnallisia vaatimuksia N1 ja N2.

F1 — Toiminnallinen vaatimus, R1 — F1:een liittyvä riski

  • Testitavoite 1 — Osoita testin avulla, että järjestelmän odotetut ominaisuudet ja toiminnot toimivat oikein ja että riski R1 voidaan käsitellä toiminnallisella testauksella.
  • Testi — Selainsivujen testaus tehdään tärkeiden käyttäjätehtävien suorittamiseksi ja sen varmistamiseksi, että R1 (F1:een liittyvä riski) voidaan ratkaista useissa eri tilanteissa.

F2 — Toiminnallinen vaatimus, R2 — F2:een liittyvä riski

  • Testitavoite 2 — Osoita testin avulla, että järjestelmän odotetut ominaisuudet ja toiminnot toimivat oikein ja että riski R2 voidaan käsitellä toiminnallisella testauksella.
  • Testi — Selainsivujen testausta tehdään tärkeiden käyttäjätehtävien suorittamiseksi ja sen varmistamiseksi, että R2:a voidaan käsitellä useissa eri tilanteissa.

F3 — Toiminnallinen vaatimus, R3 — F3:een liittyvä riski

  • Testitavoite 3 — Osoita testin avulla, että järjestelmän odotetut ominaisuudet ja toiminnot toimivat oikein ja että riski R3 voidaan käsitellä toiminnallisella testauksella.
  • Testi — Selainsivujen testausta tehdään tärkeiden käyttäjätehtävien suorittamiseksi ja sen varmistamiseksi, että R3:a voidaan käsitellä useissa eri tilanteissa.

N1 — Ei-toiminnallinen vaatimus, NR1 — N1:een liittyvä riski

  • Testitavoite N1 — Osoita testillä, että järjestelmän toiminnalliset ominaisuudet toimivat oikein ja että riski NR1 voidaan ratkaista ei-toiminnallisella testauksella.
  • Testi — Käytettävyystestaus on tekniikka, jota käytetään arvioimaan käyttöliittymien helppokäyttöisyyttä ja varmistamaan, että NR1-ongelma voidaan ratkaista käytettävyystestauksella.

N2 — Ei-toiminnallinen vaatimus, NR2 — N2:een liittyvä riski

  • Testitavoite N2 — Osoita testillä, että järjestelmän toiminnalliset ominaisuudet toimivat oikein ja että riski NR2 voidaan ratkaista ei-toiminnallisella testauksella.
  • Testi — Turvallisuustestaus on tekniikka, jota käytetään tarkistamaan, onko sovellus turvallinen tai altis hyökkäyksille, onko tietovuotoja, ja varmistamaan, että NR2 voidaan ratkaista tietoturvatestauksella.

Erityiset testitavoitteet: Luetellut riskit ja testaustavoitteet ovat testityyppikohtaisia, kuten alla on yhteenvetona esitetty.

Testityypille kohdennetut erityiset testaustavoitteet, jotka käsittelevät kutakin yksittäistä riskiä

Riskiperusteisen testausprosessin suunnittelumenettely

  • Laadi riskirekisteri. Siihen kirjataan yleisestä riskiluettelosta, olemassa olevasta tarkistuslistasta ja aivoriihikeskusteluista johdetut riskit.
  • Sisällytä järjestelmän toiminnallisiin ja ei-toiminnallisiin vaatimuksiin (käytettävyys, tietoturva, suorituskyky) liittyvät riskit.
  • Jokaiselle riskille annetaan yksilöllinen tunniste.

Rekisterin sarakkeet 1 ja 2 sisältävät tunnisteen ja riskin kuvauksen. Loput sarakkeet on kuvattu alla.

Eversti nro Sarakkeen otsikko Tuotetiedot
3 Todennäköisyys Järjestelmän todennäköisyys tälle vikaantumistyypille
4 Seuraukset Tämän vikaantumistavan vaikutus
5 Valotus Todennäköisyyden ja seurausten tulo (sarakkeet 3 ja 4)
6 Testaa tehokkuutta Kuinka luottavaisia ​​testaajat ovat, että he pystyvät käsittelemään tämän riskin?
7 Testin prioriteettinumero Todennäköisyyden, seurausten ja testin tehokkuuden tulo (sarakkeet 3, 4 ja 6)
8 Testitavoitteet Mitä testaustavoitetta käytetään tämän riskin ratkaisemiseksi
9 Testitekniikat Mitä menetelmää tai tekniikkaa käytetään tämän riskin torjumiseksi?
10 riippuvuudet Mitä testaajat olettavat ja mihin he luottavat
11 ponnistus Kuinka paljon vaivaa tämä testaus vaatii
12 Aikataulu Kuinka kauan tämän kokeen tekemiseen kuluu aikaa
13 Testausvaihe A — Yksikkötestit, Testausvaihe B — Integraatiotesti, Testausvaihe C — Järjestelmätesti Tämän toiminnon suorittavan henkilön tai ryhmän nimi

Kunkin riskin todennäköisyys (1 pieni, 5 suuri) ja seuraukset (1 pieni, 5 suuri) arvioidaan, koska kaksi rekisteriä osoittavattracalla olevat ts näyttävät.

Riskirekisterin todennäköisyys- ja seuraussarakkeet pisteytetty asteikolla 1 matala - 5 korkea

Riskialtistussarake lasketaan todennäköisyyden ja seurausten tulona

  • Testialtistus lasketaan.
  • Testaaja analysoi jokaisen riskin ja arvioi, onko riski testattavissa vai ei.
  • Testattaville riskeille määritellään testaustavoitteet.
  • Testaaja määrittelee testaustoiminnan, joka tulisi suorittaa suunnitellusti testitavoitteen saavuttamiseksi (staattiset katselmoinnit, tarkastukset, järjestelmätestit, integraatiotestit, hyväksymistestit, HTML-validointi, lokalisointitestaus ja niin edelleen).
  • Nämä testaustoiminnot voidaan luokitella vaiheisiin (komponenttitestaus tai yksikkötestaus, integraatiotestaus, järjestelmätestaus, hyväksymistestaus).
  • Joskus riskiin voidaan puuttua useammassa kuin yhdessä testausvaiheessa.
  • Tunnista riippuvuudet ja oletukset (taitojen, työkalujen, testiympäristöjen ja resurssien saatavuus).
  • Testin tehokkuus lasketaan. Testin tehokkuus liittyy testaajan luottamustasoon siihen, että riskiin puututaan testauksen avulla. Testin tehokkuuspistemäärä on luku yhdestä viiteen (5 = korkea luotettavuus, 1 = matala luotettavuus).
  • Arvioi näiden testien valmisteluun ja suorittamiseen tarvittava työmäärä, aika ja kustannukset.

Kaksi seuraavaa entistätracts näyttävät jäljellä olevat rekisterisarakkeet ja testin tehokkuuspistemäärän paikoillaan.

Riskirekisterin sarakkeet testaustavoitteille, testaustekniikoille, riippuvuuksille, työmäärälle ja aikataululle

Testin tehokkuuspisteet asteikolla 1 matala luotettavuusaste - 5 korkea luotettavuusasteikko kirjattu kullekin riskille

  • Testin prioriteettinumero lasketaan. Se on todennäköisyyden, seurausten ja testin tehokkuuspisteiden tulo.
  • 125 (enintään) – erittäin vakava riski, joka voitaisiin havaita testeillä.
  • 1 (vähintään) – erittäin pieni riski, jota ei havaita testeissä.
  • Testin tärkeysjärjestysnumeron perusteella testin tärkeys voidaan luokitella korkeaksi (punainen), keskitasoiseksi (keltainen) ja matalaksi (vihreä). Korkeimman riskin kohteet testataan ensin.
  • Jaa testaustehtävät testausvaiheille. Nimeä ryhmä, joka suorittaa testauksen kullekin tavoitteelle eri testausvaiheissa (yksikkötestaus, integraatiotestaus, järjestelmätestaus, hyväksymistestaus).

Jako testivaiheiden välillä on esitetty alla.

Testien prioriteettinumero ja testaustehtävien allokointi yksikkö-, integraatio-, järjestelmä- ja hyväksymistestauksen vaiheissa

Testausalueesta päätetään, mikä kuuluu testauksen piiriin ja mikä ei.ping vaihe.

  • Jokaiselle vaiheelle määritellään testaustavoitteet, testattava komponentti, vastuut, ympäristö, aloituskriteerit, lopetuskriteerit, työkalut, tekniikat ja tuotokset.

Yleiset testaustavoitteet — näitä yleisiä tavoitteita voidaan soveltaa useisiin hankkeisiin ja sovelluksiin.

  • Komponentti täyttää vaatimukset ja on valmis käytettäväksi suuremmissa osajärjestelmissä.
  • Tiettyihin testityyppeihin liittyvät riskit huomioidaan ja testitavoitteet saavutetaan.
  • Integroidut komponentit on koottu oikein ja komponenttien välinen rajapintojen yhteensopivuus on varmistettu.
  • Järjestelmä täyttää määritellyt toiminnalliset ja ei-toiminnalliset vaatimukset.
  • Tuotekomponentit täyttävät loppukäyttäjän tarpeet aiotussa käyttöympäristössä.
  • Riskienhallintastrategiaa käytetään riskien tunnistamiseen, analysointiin ja lieventämiseen.
  • Järjestelmä täyttää alan sääntelyvaatimukset.
  • Järjestelmä kohtaa haittojatractuaaliset velvoitteet.
  • Institutionalisointi ja muiden erityistavoitteiden, kuten kustannus-, aikataulu- ja laatutavoitteiden, saavuttaminen.
  • Järjestelmät, prosessit ja ihmiset vastaavat liiketoiminnan vaatimuksiin.

Yleiset testaustavoitteet, joita voidaan soveltaa useisiin projekteihin ja kaikkiin neljään testausvaiheeseen

Yleiset testaustavoitteet voidaan määritellä eri testausvaiheille.

  • Komponenttien testaus
  • Integraation testaus
  • Järjestelmän testaus
  • Hyväksyntätestaus

Tarkastellaan järjestelmän testausvaihetta.

  1. G4 ja G5 osoittavat, että järjestelmä täyttää toiminnalliset vaatimukset (F1, F2, F3) ja ei-toiminnalliset vaatimukset (N1, N2).
  2. Osoita testien avulla, että järjestelmän odotetut ominaisuudet ja toiminnot toimivat oikein ja että F1:een, F2:een ja F3:een liittyvät riskit voidaan käsitellä toiminnallisella testauksella.
  3. Osoita testien avulla, että järjestelmän toiminnalliset ominaisuudet toimivat oikein ja että N1:een ja N2:een liittyvät riskit voidaan käsitellä ei-toiminnallisella testauksella.
  4. Testin tärkeysjärjestysnumeron perusteella testin tärkeys voidaan luokitella korkeaksi (punainen), keskitasoiseksi (keltainen) ja matalaksi (vihreä).

Priorisointi- ja riskinarviointimatriisi

Riskienarviointimatriisi on todennäköisyys-vaikutusmatriisi. Se antaa projektitiimille nopean kuvan riskeistä ja prioriteetista, jolla kutakin riskiä on käsiteltävä.

Risk rating = Probability x Severity

Todennäköisyys on mitta sille, kuinka todennäköistä epävarma tapahtuma on. Se perustuu altistumiseen ajan, etäisyyden ja toistumisen suhteen. Se ilmaistaan ​​prosentteina.

Tämä voidaan luokitella seuraavasti: Usein (A), Todennäköisesti (B), Satunnaisesti (C), Epätodennäköisesti (D), Epätodennäköisesti (E) ja Eliminoituvasti (F).

  • tiheä — Odotetaan tapahtuvan useita kertoja useimmissa olosuhteissa (91–100 %).
  • todennäköinen — Todennäköisesti esiintyy useita kertoja useimmissa olosuhteissa (61–90 %).
  • Satunnainen — Saattaa esiintyä joskus (41–60 %).
  • Kaukosäädin — Epätodennäköistä, vaikkakin se voi joskus tapahtua (11–40 %).
  • epätodennäköinen — Voi esiintyä harvinaisissa ja poikkeuksellisissa olosuhteissa (0–10 %).
  • eliminoitu — Mahdotonta tapahtua (0 %).

Vakavuusasteella tarkoitetaan epävarman tapahtuman aiheuttaman vahingon tai menetyksen vaikutusta. Se pisteytetään asteikolla 1–4, ja se voidaan luokitella seuraavasti: Katastrofaalinen = 1, Kriittinen = 2, Merkittävä = 3 ja Merkityksetön = 4.

  • katastrofaalinen — Ankarat seuraukset, jotka tekevät projektista täysin tuottamattoman ja voivat jopa johtaa projektin lopettamiseen. Tämän on oltava riskienhallinnan kärkiprioriteetti.
  • kriittinen — Suuret seuraukset, jotka voivat johtaa suuriin tappioihin. Hanke on vakavasti uhattuna.
  • marginaalinen — Lyhytaikaiset vahingot, jotka ovat vielä korjattavissa ennallistamistoimilla.
  • merkityksetön — Vähäisiä tai minimaalisia vahinkoja tai menetyksiä. Tätä voidaan seurata ja hallita rutiinitoimenpiteillä.

Prioriteetti luokitellaan neljään luokkaan, jotka on kartoitettu riskin vakavuuden ja todennäköisyyden mukaan, kuten alla olevassa kuvassa on esitetty.

  • vakava
  • Korkea
  • Keskikova
  • Matala

Riskienarviointimatriisikarttaping todennäköisyys vakavuuden mukaan jaettuna vakavaan, korkeaan, keskitasoiseen ja matalaan prioriteettiluokkiin

Vakava: Tähän luokkaan kuuluvat riskit on merkitty keltaisella. Toiminta on lopetettava ja riskin eristämiseksi on ryhdyttävä välittömästi toimiin. Tehokkaat suojatoimet on tunnistettava ja toteutettava. Lisäksi toimintaa ei saa jatkaa, ellei riskiä ole vähennetty matalalle tai keskitasolle.

Korkea: Tähän luokkaan kuuluvat riskit on merkitty punaisella ja ne vaativat välittömiä toimia tai riskienhallintastrategian. Riskin eristämiseksi, poistamiseksi tai korvaamiseksi ja tehokkaiden riskienhallintatoimenpiteiden toteuttamiseksi on ryhdyttävä välittömästi toimiin. Jos näitä ongelmia ei voida ratkaista välittömästi, niiden ratkaisemiseksi on määriteltävä tiukat aikataulut.

Medium: Tähän luokkaan kuuluvat riskit on merkitty keltaisella. Riskien minimoimiseksi on ryhdyttävä kohtuullisiin ja käytännöllisiin toimiin.

Matala: Tähän luokkaan kuuluvat riskit on merkitty vihreällä, ja ne voidaan yleensä hyväksyä, koska ne eivät aiheuta merkittävää ongelmaa. Säännöllinen tarkastelu on silti välttämätöntä sen varmistamiseksi, että kontrollit pysyvät tehokkaina.

Yleinen tarkistuslista riskiperusteiseen testaukseen

Matriisi määrittää, miten riski luokitellaan. Alla oleva tarkistuslista päättää, mitkä ehdokkaat ensisijaisesti otetaan matriisiin.

  • Tärkeitä toimintoja projektissa.
  • Käyttäjälle näkyvä toiminnallisuus projektissa.
  • Toiminto, jolla on suurin vaikutus turvallisuuteen.
  • Toiminnot, joilla on suurin taloudellinen vaikutus käyttäjiin.
  • Erittäin monimutkaiset lähdekoodin alueet ja virhealtis koodi.
  • Ominaisuudet tai toiminnot, joita voidaan testata kehityssyklin varhaisessa vaiheessa.
  • Ominaisuudet tai toiminnot, jotka lisättiin tuotesuunnitteluun viime hetkellä.
  • Samankaltaisten tai asiaankuuluvien aiempien projektien kriittiset tekijät, jotka aiheuttivat ongelmia.
  • Samankaltaisten tai toisiinsa liittyvien projektien päätekijät tai ongelmat, joilla oli valtava vaikutus käyttö- ja ylläpitokustannuksiin.
  • Huonot vaatimukset, jotka johtavat huonoihin suunnitteluihin ja testeihin, joilla voi olla vaikutusta projektin tavoitteisiin ja tuotoksiin.
  • Pahimmassa tapauksessa tuote voi olla niin viallinen, ettei sitä voida enää työstää uudelleen ja se on romutettava kokonaan, mikä vahingoittaisi vakavasti yrityksen mainetta. Tunnista, millaiset ongelmat ovat ratkaisevia tuotteen tavoitteiden kannalta.
  • Tilanteet tai ongelmat, jotka aiheuttaisivat jatkuvia valituksia asiakaspalveluun.
  • Kokonaisvaltaiset testit, jotka voivat helposti keskittyä järjestelmän useisiin toimintoihin.
  • Optimaalinen testijoukko, joka voi maksimoida riskin kattavuuden.
  • Millä testeillä on paras riskien kattavuus suhteessa vaadittuun aikaan?

Riskiperusteinen testaustulosten raportointi ja mittarit

  1. Testiraportin laatiminen. Testaustilan raportoinnissa on kyse testitulosten tehokkaasta viestimisestä projektin sidosryhmille, selkeän ymmärryksen antamisesta ja testitulosten vertailun osoittamisesta testaustavoitteisiin nähden.
    • Suunniteltujen ja toteutettujen testitapausten lukumäärä.
    • Läpäytettyjen tai hylättyjen testitapausten määrä.
    • Tunnistettujen vikojen lukumäärä sekä niiden tila ja vakavuus.
    • Kriittisten vikojen määrä on vielä avoinna.
    • Ympäristön seisokit, jos sellaisia ​​on.
    • Näyttämöhuiput, jos sellaisia ​​on.
    • Testin yhteenvetoraportti ja testin kattavuus raportoida.
  2. Mittarien valmistelu. Metriikka on kahden tai useamman mittarin yhdistelmä, jota käytetään ohjelmistoprosessien, -projektien ja -tuotteiden vertailuun.
    • Ponnistelujen ja aikataulujen vaihtelu.
    • Testitapausten valmistelun tuottavuus.
    • Testisuunnittelun kattavuus.
    • Testitapausten suorituksen tuottavuus.
    • Riskien tunnistamisen tehokkuus %.
    • Riskienhallinnan tehokkuus %.
    • Testin tehokkuus %.
    • Testien suorituksen kattavuus.
    • Testien suorituksen tuottavuus.
    • Vika-/vuotoprosentti.
    • Vianhavaitsemisen tehokkuus ja vikatiheys.
    • Vaatimuksen vakausindeksi.
    • Laadun hinta.

Näitä toimenpiteitä verrataan sitten riskeihin:

  • Analysoi ei-toiminnallisten luokkien (suorituskyky, luotettavuus ja käytettävyys) riskejä vikatilan ja testien onnistumis- tai hylkäystulosten lukumäärän perusteella suhteessa riskeihin.
  • Analysoi toiminnallisissa luokissa olevia riskejä testausmittareiden, vikatilan ja testin läpäisy- tai hylkäystilan avulla suhteessa riskeihin.
  • Tunnista keskeiset etu- ja jälki-indikaattorit ja luo varhaisvaroitusindikaattoreita.
  • Seuraa ja raportoi etu- ja jälkijunariski-indikaattoreista (keskeiset riski-indikaattorit) analysoimalla datamalleja, trendejä ja keskinäisiä riippuvuuksia.

Luontainen riski vs. jäännösriskin arviointi

Riskien tunnistamisen ja analysoinnin tulisi sisältää myös luontaiset riskit, jäännösriskit, toissijaiset riskit ja toistuvat riskit.

  • Luontainen riski: Riskit, jotka tunnistettiin tai olivat jo järjestelmässä ennen kontrollien ja vastatoimien toteuttamista. Luontaisia ​​riskejä kutsutaan myös bruttoriskeiksi.
  • Jäännösriski: Riskit, jotka jäävät jäljelle kontrollien ja vastatoimien toteuttamisen jälkeen. Jäännösriskejä kutsutaan nettoriskeiksi.
  • Toissijainen riski: Riskienhallintasuunnitelman toteuttamisesta aiheutuva uusi riski.
  • Toistuva riski: Todennäköisyys sille, että alkuperäiset riskit toistuvat.

Riskiin perustuva testitulosten mittaus auttaa organisaatiota tunnistamaan jäännöslaaturiskin tason testin suorituksen aikana ja tekemään tietoon perustuvia julkaisupäätöksiä.

Riskien profilointi ja asiakaspalaute

Riskiprofilointi on prosessi, jolla löydetään asiakkaalle optimaalinen sijoitusriskin taso ottaen huomioon vaadittu riski, riskinottokyky ja riskinsietokyky.

  1. Vaadittu riski on riskitaso, jonka asiakkaan on otettava tyydyttävän tuoton saamiseksi.
  2. Riskinottokyky on se taloudellisen riskin taso, jonka asiakas on varaa ottaa.
  3. Riskitoleranssi on riskin taso, jonka asiakas on mieluummin valmis ottamaan.

Asiakaspalaute: kerätä asiakaspalautetta ja -arvosteluja parantaakseen liiketoimintaa, tuotteita, palvelua ja kokemusta.

Riskipohjaisen testauksen edut

Riskiperusteisen testauksen edut on esitetty alla.

  • Parempi tuottavuus ja kustannusten aleneminen.
  • Parempi markkinamahdollisuus (markkinoille saamisaika) ja oikea-aikainen toimitus.
  • Parannettu palvelun suorituskyky.
  • Parannettu laatu, koska kaikki sovelluksen kriittiset toiminnot testataan.
  • Selkeät tiedot testien kattavuudesta. Tällä lähestymistavalla tiimi tietää, mitä on testattu ja mitä ei.
  • Riskinarviointiin perustuva testausponnistuksen allokointi on tehokkain ja tehokkain tapa minimoida jäännösriski päästön yhteydessä.
  • Riskianalyysiin perustuva testitulosten mittaus mahdollistaa organisaatiolle jäännöslaaturiskin tunnistamisen testin suorituksen aikana ja tietoon perustuvien julkaisupäätösten tekemisen.
  • Optimoitu testaus selkeästi määritellyillä riskinarviointimenetelmillä.
  • Parempi asiakastyytyväisyys asiakkaiden osallistamisen sekä hyvän raportoinnin ja edistymisen ansiosta trackuningas.
  • Mahdollisten ongelma-alueiden varhainen havaitseminen, jotta voidaan ryhtyä tehokkaisiin ennaltaehkäiseviin toimenpiteisiin.
  • Jatkuva riskien seuranta ja arviointi koko projektin elinkaaren ajan auttaa tunnistamaan ja ratkaisemaan riskejä sekä puuttumaan ongelmiin, jotka voisivat vaarantaa projektin kokonaistavoitteiden saavuttamisen.

UKK

Tuoteriski on vika, joka voi saavuttaa käyttäjän, kuten rikkinäinen maksureitti. Projektiriski uhkaa itse toimitusta – puuttuva taito, myöhästynyt ympäristö, epävakaa vaatimus. Testaus käsittelee tuoteriskejä suoraan ja projektiriskejä vain epäsuorasti.

Arvioinnista tulee kertaluonteisen dokumentin sijaan lyhyt ja toistuva aktiviteetti. Jokaisessa sprintissä tiimi pisteyttää uudelleen tarinat, joita se aikoo rakentaa, joten riskirekisteri trackäsittelee tilausjonon kuukausia aiemmin kirjoitetun julkaisusuunnitelman sijaan.

Pisteet ovat arvioita, joten riskiä, ​​jota kukaan ei ole ajatellut, ei käsitellä lainkaan. Alhaisen luokituksen alueet voivat myös rapistua hiljalleen useiden julkaisujen aikana. Säännölliset tutkimusistunnot rekisterin ulkopuolella ovat tavanomainen suoja molempia sokeita pisteitä vastaan.

Pelkästään testaajien tekemä pisteytys ajautuu teknisen riskin suuntaan. Hyödyllisessä sessiossa on mukana liiketoiminta-analyytikko tai tuoteomistaja vaikuttavuuden arvioimiseksi, kehittäjä monimutkaisuuden ja muutoshistorian arvioimiseksi sekä testaaja todennäköisyyden arvioimiseksi, ja heille tarjotaan tukea erimielisyyksien ratkaisemiseksi.

Koneoppimismallit luokittelevat moduulit käyttämällä historiallisia vikatietoja, koodin vaihtuvuutta, monimutkaisuusmittareita ja muutosten tiheyttä versionhallinnasta ja ongelmista trackuningas. Tulosteena on lähtöluokitus, jota ihminen edelleen tarkistaa, koska liiketoimintavaikutukset eivät näy repositoriossa.

GitHub Copilot voi laatia rekisteririvit, altistumiskaavat ja ehdokastestaustavoitteita vaatimuskuvauksesta ja luoda testitapauksia korkeimman pistemäärän saaneille kohteille. Todennäköisyys- ja vakavuusarviot itsessään ovat ihmisen päätettävissä.

Säännellyillä aloilla käytetään samaa pisteytysmallia, mutta niihin lisätään todisteketju: jokainen riski, sen perustelut, sitä koskevat testit ja hyväksyntä säilytetään tarkastusta varten. Riskin alempi prioriteetti on sallittu vain, jos perustelut on dokumentoitu.

Pisteytä uudelleen aina, kun jokin pisteytykseen vaikuttanut asia muuttuu: uusi vaatimus, merkittävä uudelleenjärjestely, tuotantohäiriö tai vikaryppää matalaksi arvioidulla alueella. Käytännössä tiimit tarkastelevat tilannetta jokaisen sprintin rajalla ja uudelleen ennen julkaisupäätöstä.

Tiivistä tämä viesti seuraavasti: