Täydellisessä maailmassa ohjelmistokehitys voisi sujua kitkattomasti, ja testaus- ja varmistusvaiheet olisivat nopeita, vikoja ei juuri löytyisi.
Mutta koska tämä on vain mielikuvitusta, todellisen maailman testaajien on kohdattava poikkeavuuksia ja toimintahäiriöitä jokaisessa ohjelmistosovelluksessa.
Ohjelmiston laatu määräytyy sen mukaan, kuinka puhdas tai virheetön ohjelmisto on?
Siksi on olennaista, että testaajat tarkastelevat monimutkaisia monikerroksisia sovelluksia ja tunnistavat, dokumentoivat, jäljittävät ja korjaavat lukuisat virheet tai viat.
Sisällysluettelo
- Mitä tarkoittaa vika?
- Luokittelu
- Tyypit
- Vikamittarit
- Vikojen luokitus
- 1. Vian vakavuus
- Miksi se on tärkeää?
- Vikatyypit vian vakavuuden mukaan
- Ole varovainen ennen kuin määrität vakavuustason
- 2. Vian prioriteetti
- Vikatyypit vikojen prioriteetin perusteella
- Ohjeita ennen prioriteetin ja vakavuuden valitsemista
- Ero vian vakavuuden ja prioriteetin välillä
- Vakavuuden ja prioriteetin yhdistäminen
- 3. Vian todennäköisyys
- Vian todennäköisyyden tyypit
- Vian elinkaari
- Vikavaltiot
- Vian elinkaariohjeet
- Vian syyanalyysi
- Prosessi (5W1H-menetelmä)
- Vaiheittainen syyanalyysi
- 1. Muodosta perussyyanalyysiryhmä
- 2. Määrittele
- 3. Tunnistaminen
- 4. Perussyyn korjaavan toiminnan toteuttaminen (RCCA)
- 5. Perussyyn ennaltaehkäisevän toiminnan toteuttaminen (RCPA)
- Perussyyanalyysin edut
- Virhe vs vika vs epäonnistuminen
- Ehdot
- Johdatus virheeseen, vikaan ja epäonnistumiseen
- Virhe
- Virhetyypit
- Virheiden syyt
- Virhe vs vika vs epäonnistuminen
- Viimeiset sanat
- Vikaraportti
- Määritä ohjelmistotestauksen vika
- Määritä vikaraportti
- Malli vikailmoitukselle
- Vianhallintaprosessi
- Vianhallintaprosessin tarve
- Tehokas vikailmoitus
- Vikamittarit
- Vika FAQ
- Suositellut artikkelit
Mitä tarkoittaa vika?
Vika on tila, joka ilmenee ohjelmistotuotteessa, kun se ei täytä ohjelmiston vaatimuksia tai odotuksia.
Se voi olla virhe ohjelman koodauksessa tai logiikassa, joka aiheuttaa sen toimintahäiriön.
Ne määritellään sääntöjenvastaisuuksiksi tai poikkeamiksi odotetuista tuloksista, jotka johtuvat kehittäjän virheistä kehitysvaiheessa.
Viat tai virheet tai viat ovat puutteita tai epätäydellisyyksiä, jotka estävät ohjelmistosovellusta suorittamasta sitä, mitä sen odotetaan tekevän.
Viat johtavat ohjelmistosovelluksen epäonnistumiseen.
Muutamia menetelmiä, joita on käytetty estämään ohjelmoijien käyttöönotosta virheitä kehityksen aikana, ovat:
- Vertaisarviointi
- Koodianalyysi
- Ohjelmointitekniikat käyttöön
- Ohjelmistokehitysmenetelmät
Luokittelu
Alla annetut vikaluokitukset ovat vain suuntaa antavia. Vikojen luokitteluperusteet riippuvat organisaatiosta ja niiden käyttämästä vianseurantatyökalusta.
Tiimin jäsenillä tulee olla ennakkosopimus vikaluokittelusta, jota käytetään välttämään tulevat ristiriidat.
Viat voidaan luokitella seuraavien perusteella:
Vakavuus
Vian vakavuus riippuu vian monimutkaisuudesta, joka korjataan kehitysnäkökulmasta.
Vakavuuden tila antoi testaajalle käsityksen ohjelmiston poikkeamasta spesifikaatioista.
Se voi olla:
- Kriittiset – Nämä viat kuvastavat ohjelmistosovelluksen keskeisiä toiminnallisuuden poikkeamia ilman korjaamista, joita laadunvarmistustastaja ei voi vahvistaa.
- Suuret – Nämä viat havaitaan, kun sovelluksen tärkeä moduuli ei toimi, mutta muu järjestelmä toimii hyvin. Laadunvarmistustiimin on korjattava nämä ongelmat, mutta se voi myös vahvistaa muun sovelluksen riippumatta siitä, onko suuri vika korjattu vai ei.
- Keskitaso – Nämä viat liittyvät yksittäisen näytön tai yksittäisen toiminnon ongelmiin, mutta ne eivät vaikuta järjestelmän toimintaan kokonaisuutena. Viat eivät estä mitään toimintoja.
- Matala – Nämä viat eivät vaikuta ohjelmistosovelluksen toimivuuteen ollenkaan. Se voi liittyä käyttöliittymän epäjohdonmukaisuuteen, kosmeettisiin virheisiin tai ehdotuksiin käyttäjän käyttökokemuksen parantamiseksi.
Todennäköisyys
Vian todennäköisyys voidaan määritellä vian todennäköisyydeksi järjestelmän tietyssä ominaisuudessa.
Vian löytämisen todennäköisyys riippuu kyseisen ominaisuuden käytöstä. Jos attribuuttia käytetään harvoin, löydetyllä vialla on suuri mahdollisuus. Silti, jos attribuuttia käytetään laajalti, vian todennäköisyys saattaa olla pieni, riippuen vian havaitsemisen harvinaisuudesta.
Se voi olla:
- Korkea – Jos kaikki tai useimmat ominaisuuden käyttäjät löytävät vian helposti, vian todennäköisyys on suuri.
- Keskitaso – Jos vian havaitsee vähintään 50 % ominaisuuden käyttäjistä, vian esiintymistodennäköisyys on keskitasoinen.
- Matala – Jos vain harvat ominaisuuden käyttäjät kohtaavat vian, vian todennäköisyys on pieni.
Prioriteetti
Tietyn korjaamisen tärkeys tai kiireellisyys määrittää vian prioriteetin.
Vian prioriteetti asetetaan a ohjelmiston testaaja ja viimeistelee projektipäällikkö.
Se voidaan luokitella seuraavasti:
- Kiireellinen – Tämän luokan vian välitöntä ratkaisua tarvitaan, koska nämä viat voivat vaikuttaa vakavasti sovellukseen ja aiheuttaa kalliita korjauksia, jos niitä ei käsitellä.
- Korkea – Näiden vikojen välitön ratkaiseminen on välttämätöntä, koska nämä viat vaikuttavat sovellusmoduuleihin, jotka ovat hyödyttömiä, kunnes viat on korjattu.
- Keskitaso – Nämä eivät ole niin olennaisia vikoja, ja ne voidaan ajoittaa korjattavaksi myöhemmissä julkaisuissa.
- Matala – Kun yllä mainitut kriittiset viat on korjattu, testaaja voi korjata ne tai olla korjaamatta niitä.
Vaihe ruiskutettu
Vikojen luokittelussa voidaan käyttää myös ohjelmistokehityksen elinkaaren vaihetta, jossa vika ilmeni tai lisättiin.
Vian injektoitu vaihe löydetään asianmukaisen perussyyanalyysin jälkeen.
Vika voidaan ruiskuttaa missä tahansa seuraavista vaiheista:
- Vaatimukset Kehittäminen
- Yksityiskohtainen suunnittelu
- Korkean tason suunnittelu
- Koodaus
- Käyttöönotto
Vaihe havaittu
Kun ruiskutettu vaihe tulee, vaihe havaitaan. Vaihetta, jossa tietty vika tunnistettiin, kutsutaan havaitsemisvaiheeksi.
Siinä on seuraavat vaiheet Ohjelmistojen testaus :
Aiheeseen liittyvä moduuli
Vian luokituksena voidaan käyttää moduulia, jossa tietty vika havaittiin.
Asiaan liittyvä moduuliluokitus antaa tietoa eniten bugeja sisältävästä moduulista.
Asiaan liittyvä laatu
Nämä ovat satoja ohjelmiston laatumittoja, kuten saavutettavuus, yhteensopivuus, samanaikaisuus ja monet muut.
Päätös siitä, kumpi ulottuvuus on tärkeämpi ja se tulisi vahvistaa ensin, on subjektiivinen. Se riippuu yksinomaan testaajan useiden arvojen ulottuvuudesta kyseisessä tilanteessa.
Vaatimukset ja tekninen vika
Asiakasvaje tai tuottaja (testaaja tai kehittäjä) aukko voi aiheuttaa vaatimuksiin liittyviä puutteita, joissa kehittäjä tai testaaja ei ymmärrä asiakkaan vaatimuksia.
Vaatimusasiakirjat tulee laatia yksiselitteisin, ristiriitaisin, selkein, ei-redundantsin ja täsmällisin vaatimuksin näiden vikojen vähentämiseksi.
Suunnitteluvirheitä
Yhteensopimattomien tai väärin suunniteltujen komponenttien ja moduulien välinen vuorovaikutus johtaa järjestelmän virheisiin.
Algoritmit, logiikka- tai dataelementit, moduulirajapintojen kuvaukset, algoritmit ja ulkoisen ohjelmiston tai laitteiston käyttöliittymäkuvaukset tulee suunnitella oikein suunnitteluvirheiden välttämiseksi.
Koodausvirheitä
Suunnitelmien tai koodien väärä toteutus kehitys- tai koodausstandardien puuttumisesta voi aiheuttaa koodausvirheitä.
Nämä viat liittyvät läheisesti luokkien suunnitteluvirheisiin, ensisijaisesti jos pseudoluokkia käytetään yksityiskohtaisessa suunnittelussa.
Joskus voi olla haastavaa luokitella vika koodaus- tai suunnitteluvirheeksi.
Testaus viat
Väärä testaus tai viat testausartefakteissa johtavat testausvirheisiin.
Näitä voi olla kolmea tyyppiä:
- Testityökaluvika – Testaajien käyttämät testityökalut voivat myös tuoda vikoja ohjelmistoon. A manuaalinen testi käytetään automaattisten työkalujen aiheuttamien vikojen etsimiseen.
- Testisuunnitteluvirhe – Vikoja testausartefakteissa, kuten testisuunnitelmissa, testiskenaarioissa, testidatan määritelmissä ja testitapauksissa, kutsutaan testisuunnitteluvirheiksi.
- Testiympäristövika – Kun testiympäristöä, eli laitteistoa, ohjelmistoa, testaushenkilöitä ja simulaattoria ei ole asetettu, syntyy testiympäristövirheitä.
Tila
Vika voidaan luokitella sen vian elinkaaren tilan tai tilan perusteella, jossa vika tällä hetkellä on.
Nämä tilat voivat olla:
- Avata
- Suljettu
- Lykätty
- Peruutettu
Word tuote
Työtuotteen tai kehitysvaiheen asiakirjojen tai lopputuotteiden perusteella vika voidaan luokitella seuraavasti:
- Lähdekoodi – Sovelluksen lähdekoodista löytynyt vika.
- SSD – Vika, joka löytyi ohjelmiston System Study -asiakirjasta.
- User Documentation – Vika, joka löytyy ohjelmiston käyttöoppaista tai käyttöohjeista.
- ADS – Ohjelmiston arkkitehtonisesta suunnitteluasiakirjasta löytynyt vika.
- Testisuunnitelma tai testitapaus – ohjelmiston testisuunnitelmassa tai testitapauksissa havaittu vika.
- FSD – Ohjelmiston Functional Specification -asiakirjasta löytynyt vika.
- DDS – Ohjelmiston yksityiskohtaisesta suunnitteluasiakirjasta löytynyt vika.
Tyypit
Muutamia ohjelmistokehityksen perusvikojen tyyppejä ovat:
Loogiset viat
Koodin toteutuksen aikana ohjelmoija ei ehkä ymmärrä ongelmaa selvästi tai ajattelee väärin. Tällaisissa tapauksissa tapahtuu loogisia virheitä.
Loogiset viat liittyvät ohjelmiston ytimeen ja voivat ilmetä, jos ohjelmoija ei toteuta kulmatapauksia asianmukaisesti.
Suorituskykyvirheet
Kun järjestelmä tai ohjelmistosovellus ei tuota haluttuja ja odotettuja tuloksia eikä pysty täyttämään käyttäjän vaatimuksia, ilmenee suorituskykyvirheitä.
Näihin virheisiin kuuluu myös järjestelmän vaste järjestelmän kuormituksen vaihteluun.
Monisäikeiset viat
Useiden tehtävien suorittamista samanaikaisesti kutsutaan multithreadingiksi, ja se johtaa erittäin monimutkaiseen virheenkorjaukseen.
Deadlock- ja Starvation-ongelmat monisäikeisessä käytössä voivat johtaa järjestelmän epäonnistumiseen.
Aritmeettiset viat
Liiallinen työmäärä tai vähemmän tietoa voi saada ohjelmoijan tekemään virheitä aritmeettisissa lausekkeissa ja niiden ratkaisuissa, joita kutsutaan aritmeettisiksi virheiksi.
Koodiruuhkat voivat estää ohjelmoijan lukemasta kirjoitettua koodia oikein ja voivat myös aiheuttaa aritmeettisia virheitä.
Syntaksivirheet
Joskus kehittäjät tekevät koodia kirjoittaessaan virheitä, jotka liittyvät koodin tyyliin tai syntaksiin.
Nämä virheet voivat olla niin pieniä kuin symbolin jättäminen pois.
Esimerkki syntaksivirheistä voi olla puolipisteen pois jättäminen (;) kirjoitettaessa koodia C++- tai Java-kielellä.
Käyttöliittymän vikoja
Viat voivat vaikuttaa käyttäjän ja ohjelmiston väliseen vuorovaikutukseen. Näitä kutsutaan käyttöliittymävirheiksi.
Monimutkaiset, epäselvät tai alustapohjaiset rajapinnat voivat aiheuttaa käyttöliittymävirheitä ohjelmistossa.
Vikamittarit
Tarkka arvio testattavan projektin laadusta, kustannuksista ja tehokkuudesta on olennaista.
Vikamittarit auttavat meitä arvioimaan ohjelmistosovelluksen aiemmin mainitut näkökohdat.
Vikatiheysmittarit
Ohjelmiston sisällä olevien vikojen paksuutta tai pitoisuutta kutsutaan vikatiheyden mittareiksi.
Vikatiheysmittarit voidaan määritellä prosenttiosuutena havaittujen vikojen määrästä vaatimusta tai testitapausta kohti.
Kaava:
|_+_|Missä koko on vaadittujen testitapausten lukumäärä.
Esimerkki:
Oletetaan, että ohjelmistossa on 1000 testitapausta, joista 600 on hyväksytty ja 400 epäonnistunut. Vian tiheys tässä tapauksessa on
|_+_|Siten vikojen tiheys on 40 %. Näin ollen 40 % testitapauksista epäonnistui suorituksen aikana tai vain 40 % testisuunnittelusta saattoi havaita vikoja.
Kokonaisvikamittarit
Suhteellinen arvio kokonaisvirheistä v/s moduulikokoon ja ohjelmiston monimutkaisuuteen voi selittää testaustoimien tehokkuuden.
Kukaan ei voi uskoa kehittäjää, joka sanoo, että ohjelmistossa on nolla vikaa.
Vikojen jakautuminen tärkeysjärjestyksen ja vakavuuden mukaan
Olemme jo ymmärtäneet, että viat luokitellaan niiden prioriteetin ja vakavuuden perusteella.
Jos kaikki havaitut viat ovat vakavia tai ensisijaisia vikoja, tämä tarkoittaa, että testiryhmä ei ole testannut järjestelmää kunnolla.
Vikojen kokonaismäärä antaa hyvän käsityksen testaustoimista, ja prioriteetti ja vakavuus voivat auttaa testaamisessa ja rakennuslaadussa.
Painotettu virhetiheys
Keskimääräinen vian vakavuus testitapausta kohti voidaan määritellä painotetuksi vikojen tiheydeksi.
Kaava:
|_+_|Jos koko on testitapausten tai vaatimusten lukumäärä.
Vakavuuden perusteella painot 5,3 ja 1 määrätään.
Vian etsimisen kustannukset
Olipa kyseessä kehitys tai testaus, kustannuksilla on olennainen tekijä kaikissa projekteissa.
Jos asiakas maksaa valtavia summia, hän odottaa, että toimitettu ohjelmisto on virheetön ja tehokas.
Kaava:
|_+_|Kokonaissumma voidaan laskea käyttämällä täydellisiä resursseja, laskutushintoja ja testauksen kestoa.
Vikojen poiston tehokkuus
Testaustiimin osaamista poistaa tehokkaasti ja tunnistaa vikojen enimmäismäärä ennen ohjelmiston lähettämistä seuraavassa vaiheessa kutsutaan vianpoistotehomittariksi.
Kaava:
|_+_|Esimerkki:
Harkitse ohjelmistoa, jossa on 200 virhettä alkuvaiheessa. Ohjelmiston korjauksen, uudelleentestauksen ja regressiotestauksen suorittamisen jälkeen User Acceptance Team testaa ja löytää 40 muuta vikaa, jotka olisi voitu tunnistaa ja korjata aikaisemmissa testausvaiheissa. Nämä 40 vikaa vuotivat seuraaviin vaiheisiin, eikä niitä poistettu järjestelmästä. Täten,
|_+_|Siten ohjelmistotestaustiimi pystyi tunnistamaan ja korjaamaan vain 83,33 % kaikista vioista ja vuoti loput 16,67 % seuraavissa vaiheissa.
Vikavuodon mittarit
Toisin kuin vian poistaminen, vikavuotometriikka näyttää niiden vikojen prosenttiosuuden, jotka ovat vuotaneet nykyisestä testausvaiheesta seuraavaan tai seuraavaan vaiheeseen.
Vikavuotomittareiden tulee olla minimaalisia joukkueen arvon parantamiseksi.
Kaava:
|_+_|Esimerkki:
Harkitse ohjelmistoa, jossa on 200 virhettä alkuvaiheessa. Ohjelmiston korjauksen, uudelleentestauksen ja regressiotestauksen suorittamisen jälkeen User Acceptance Team testaa ja löytää 40 muuta vikaa, jotka olisi voitu tunnistaa ja korjata aikaisemmissa testausvaiheissa. Nämä 40 vikaa vuotivat seuraaviin vaiheisiin, eikä niitä poistettu järjestelmästä. Täten,
|_+_|Siksi 16,67 % vioista vuoti seuraavaan vaiheeseen.
Vika Ikä
Vikojen elinkaari alkaa uuden vian tunnistamisesta ja päättyy, kun ne korjataan tai säilytetään seuraavaa julkaisua varten ja dokumentoidaan.
Vian ikä on aika, joka kuluu vian tunnistamisen ja korjaamisen välillä.
|_+_|Vika voi esiintyä tunneissa tai päivissä – mitä pienempi vika on, sitä parempi on testaustiimin reagointikyky.
Vikojen luokitus
Kaikki viat eivät ole samanlaisia tai vaativat testaajien välitöntä huomiota.
Tästä syystä on välttämätöntä luokitella viat.
Viat määritellään vakavuus- tai tärkeysasteen mukaan, jotta kehitystiimi ymmärtää, kumpi on ratkaistava ensin.
1. Vian vakavuus
Vian vakavuus tai vian vakavuus , joka tarkoittaa maallikollisesti, voidaan selittää vian vaikutukseksi ohjelmiston kehitykseen tai toteutukseen.
ISTQB:n mukaan vian vakavuus voidaan määritellä vian vaikutuksen asteena järjestelmän komponentin tai koko järjestelmän kehitykseen tai toimintaan.
Laadunvarmistustiimin vastuulla on määrittää kunkin havaitun vian vakavuusaste.
Tehokkailla vikojen vakavuustoimenpiteillä laadunvarmistustiimi voi ratkaista kriittiset viat ja muut järjestelmän vakavuusasteet hallitakseen loppukäyttäjän mahdollisia liiketoimintavaikutuksia.
Esimerkki:
Lisää koriin -kohdan kirjoitusvirhe on ei-kriittinen virhe, mutta se, että Lisää ostoskoriin -toiminnon toimivuus verkkokauppasivustolla ei toimi, on kriittinen virhe.
Miksi se on tärkeää?
Ongelman vakavuusasteiden määrittämisen merkitys on:
- Testausryhmät voivat määrittää testausprosessin tehokkuuden.
- Ohjelmiston eri osien virheellinen toiminta voidaan helposti tarkistaa.
- Virheiden seurantaa lisätään vian vakavuuden avulla, mikä parantaa ohjelmiston laatua.
- Laadunvarmistustiimi voi ensin määrittää ja testata vakavammat viat.
- Virheiden seuranta- ja hallintajärjestelmät voivat tulla systemaattisemmiksi ja organisoidummiksi käyttämällä vian tai vian vakavuutta.
- Vikoja voidaan kohdentaa tehokkaammin kehittäjän taitojen ja kokemustason sekä vakavuuden ja tason mukaan.
Vikatyypit vian vakavuuden mukaan
Vian vakavuuden perusteella ohjelmistossa on neljä vakavuustasoa:
(i) Kriittinen
S1 edustaa tätä vakavuusastetta tai korkeimman prioriteetin vakavuutta, joka ohjelmistosta löytyy.
Nämä vikatyypit estävät ohjelmiston suorittamisen kokonaan ja aiheuttavat joskus järjestelmän täydellisen sammumisen.
On äärimmäisen tärkeää poistaa nämä viat, koska niillä ei ole kiertotapaa ja ne häiritsevät ohjelmiston jatkotestausta.
varten esimerkki , jopa oikean tunnuksen ja salasanan syöttämisen jälkeen käyttäjä ei voi kirjautua sisään ja käyttää sovellusta on kriittinen vika.
(ii) Majuri
Merkittävä vika ilmenee, kun järjestelmälle annetaan joukko syötteitä, mutta se ei pysty tarjoamaan haluttuja tuloksia. S2 edustaa sitä.
Nämä viat voivat aiheuttaa järjestelmän kaatumisen, mutta silti jättää joitakin toimintoja toimiviksi, jolloin jää pieni tila niiden kiertämiselle lisätestausta varten.
varten esimerkki , se, että verkkokauppasivustolla ei voi lisätä useampaa kuin yhtä tuotetta ostoskoriin, on merkittävä puute, mutta ei kriittinen, koska käyttäjä voi silti ostaa yhden tuotteen.
(iii) Pieni
Kun komponentti ei tuota odotettuja tuloksia tai täytä vaatimuksiaan, mutta sillä on mitätön vaikutus koko järjestelmään, kutsutaan vähäiseksi tai kohtalaiseksi viaksi.
S3:n edustamat pienet viat vaikuttavat vain pieneen osaan sovelluksesta, mikä saa ohjelmiston käyttäytymään luonnottomalla tavalla, mutta vaikuttaa koko järjestelmään.
varten esimerkki , myös tuotteiden tilauksen jälkeen tuote näkyy tilatuissa tuotteissa ja sitä voidaan seurata, mutta näyttöön tulee viesti Tuote ei tilattu -kehoteikkunasta. Tämä on pieni vika, koska kehote on vain väärä.
(iv) Triviaali
Vikavirheet ovat vähäisiä vikoja, jotka vaikuttavat vain ohjelmiston ulkoasuun, mutta eivät vaikuta järjestelmän tai ohjelmiston toimivuuteen tai toimintahäiriöön.
Tämä vakavuustason S4-vika ei välttämättä vaikuta toimivuuteen, mutta on silti pätevä vika ja se on korjattava.
varten esimerkki , Sivuston käyttöehdot-sivun kohdistus- tai kirjoitusvirhe on vähäpätöinen virhe.
Ole varovainen ennen kuin määrität vakavuustason
Koska vikojen vakavuus on olennainen osa ohjelmistotestausta, niitä määriteltäessä tulee noudattaa suurta varovaisuutta.
Jokainen vakavuusaste on määriteltävä selvästi, koska tämä voi johtaa eroihin kehitys- ja laadunvarmistustiimin välillä.
2. Vian prioriteetti
Vian ratkaisemisen tärkeys tai kiireellisyys määräytyy vian tai vian prioriteetin mukaan.
The projektipäällikkö määrittää kunkin vian prioriteetin käyttäjän liiketoimintatarpeiden ja vian vakavuuden perusteella.
Vian prioriteetti on subjektiivinen, koska se määräytyy vertailun jälkeen muihin vioihin.
Projektipäällikön lisäksi tuotteen omistajat, yritysanalyytikot ja liiketoiminnan sidosryhmät määrittelevät vikojen korkeamman tai alemman prioriteetin.
Vikatyypit vikojen prioriteetin perusteella
Vikojen luokittelussa on neljä prioriteettitasoa:
(i) Välitön
Järjestelmään ja liiketoiminnan vaatimuksiin vaikuttavat viat on korjattava välittömästi.
P1:n edustamat viat estävät järjestelmää suorittamasta ydintoimintojaan tai tekevät järjestelmästä epävakaa, mikä rajoittaa lisätestausta.
Kaikilla kriittisillä vakavuusvirheillä on välitön prioriteetti, elleivät yritykset/sidosryhmät priorisoi järjestystä uudelleen.
varten esimerkki , Väärin kirjoitettu yrityksen nimi ei välttämättä ole suuri tai kriittinen vakavuusvirhe, mutta se on välitön prioriteetti, koska se vaikuttaa sen liiketoimintaan.
(ii) Korkea
Nämä P2 tai korkean prioriteetin viat ovat seuraavaksi ratkaistavaksi, kun välittömät prioriteetit on korjattu.
Viat, jotka eivät täytä 'poistumiskriteereitään' tai saavat komponentin poikkeamaan ennalta määritellyistä suorituskykymittareista. Nämä toimenpiteet voivat olla riippuvaisia koodauksesta tai ympäristötekijöistä.
Vika ei vaikuta suoraan yritykseen tai asiakkaaseen, mutta se on kuitenkin kiireellisesti korjattava.
varten esimerkki , tuotteiden lisäämättä jättäminen ostoskoriin kuuluu korkean prioriteetin luokkaan.
(iii) Keskikokoinen
Virheet, jotka eivät kuulu korkeaan ja välittömään luokkaan, kuuluvat keskitason prioriteettiin.
Nämä viat on korjattava heti, kun edellä mainitut on korjattu, koska ne voivat sisältää toimivuuteen liittyviä puutteita.
P3:n edustamat viat voivat joskus sisältää triviaaleja tai kosmeettisia virheitä, kuten virheellisiä virheilmoituksia vian aikana.
Nämä viat voidaan myös korjata seuraavissa julkaisuissa.
varten esimerkki , jopa onnistuneen sisäänkirjautumisen jälkeen tulee virheilmoitus kirjautumistunnuksesta/salasanasta, jolloin kyseessä on keskitason virhe.
(iv) Matala
Nämä ovat enimmäkseen vähän vakavia vikoja, jotka eivät vaadi välitöntä huomiota ja jotka voidaan ratkaista, kun muut kriittiset ja olennaiset viat on korjattu.
P4:n edustamat viat voivat olla kirjoitusvirheitä, kosmeettisia virheitä tai ehdotuksia, jotka liittyvät parannuksiin käyttökokemuksen parantamiseksi.
Koska ne eivät vaadi välitöntä huomiota, ne voidaan ratkaista tulevaisuudessa.
varten esimerkki , Yhteystiedot-välilehti ei sijaitse kotisivulla ja on piilotettu navigointipalkin toisen valikon sisällä.
Ohjeita ennen prioriteetin ja vakavuuden valitsemista
Jotta kehitys- ja testaustiimien välinen asiointi ja viestintä sujuvat sujuvasti, tietyt ohjeet on päätettävä ennen vakavuus- ja prioriteettitason valitsemista.
Jotkut näistä ohjeista ovat:
- On tärkeää ymmärtää vakavuuden prioriteetin käsite.
- Ennen kuin päätät vian vaikutuksen, ymmärrä vian prioriteetti käyttäjälle.
- Listaa kaikki vian esiintymiseen ja toimintaan liittyvät sekvenssit.
- Eristä ensin vika ja määritä sitten sen iskun syvyys.
- Määritä kunkin vian korjaamiseen tarvittava aika monimutkaisuuden ja todentamisajan perusteella.
- Määritä syötteen luokka, jota vika tukee.
- Määritä vakavuusaste vian tyypin perusteella, sillä se määrittää myös sen prioriteetin.
Ero vian vakavuuden ja prioriteetin välillä
| Vian vakavuus | Vian prioriteetti |
|---|---|
| Se on vian vaikutuksen aste järjestelmään. | Se on järjestys, jossa kehittäjä korjaa vian. |
| Laadunvarmistustajat määrittävät vakavuuden. | Tuotepäälliköt ja muut liiketoiminnan sidosryhmät asettavat tärkeysjärjestyksen. |
| Vakavuus, kun se kerran on päätetty, ei muutu ajan myötä. | Vian prioriteetti voi muuttua vertailun perusteella muihin vioihin. |
| Sitä on neljää tyyppiä: CriticalMajorMinorTrivial | Sitä on neljää tyyppiä: ImmediateHighMediumLow |
| Se osoitti vian vakavuuden. | Se ilmaisee vian liiketoiminnallisen merkityksen ja kuinka pian se on korjattava. |
| Vakavuus perustuu toiminnallisuuteen, johon vika vaikuttaa. | Prioriteetti perustuu liiketoiminnan arvoon, johon vika vaikuttaa. |
| SIT:n aikana viat korjataan ensin vakavuuden ja sitten prioriteetin perusteella. | UAT:n aikana viat korjataan prioriteetin perusteella. |
Vakavuuden ja prioriteetin yhdistäminen
Koska prioriteetti ja vakavuus ovat kaksi tärkeintä vikojen luokittelua, monet organisaatiot yhdistävät vakavuus- ja prioriteettitason eri tasojen määrittelemiseksi.
1. Korkea prioriteetti, suuri vakavuus
Kriittiset tai suuret liiketoimintavaatimusten puutteet kuuluvat tähän luokkaan, ja ne on korjattava välittömästi, koska lisätestausta ei voida suorittaa ennen kuin ne on korjattu.
varten esimerkki , kun olet maksanut ostoskorissasi olevat tuotteet verkkokauppasivustolla, tuotetta ei edelleenkään ole tilattu, mutta maksu tililtäsi on vähennetty.
2. Korkea prioriteetti, alhainen vakavuus
Viat, jotka eivät vaikuta toiminnalliseen vaatimukseen, mutta vaikuttavat liiketoiminnan vaatimukseen tai käyttökokemukseen, kuuluvat tähän kategoriaan.
varten esimerkki , verkkosivuston kirjasimet ja kohdistus eivät ole käyttäjäystävällisiä, silloin harvemmat asiakkaat napsauttavat verkkosivustoa, mikä vaikuttaa liiketoimintaan.
3. Korkea vakavuus, matala prioriteetti
Nämä viat ovat toiminnallisten vaatimusten kannalta erittäin vakavia, mutta ne eivät vaikuta liiketoiminnan vaatimuksiin.
varten esimerkki , sovellusta voi käyttää vain tietyn selaimen uudemmista versioista, joissa on suuri vakavuus mutta alhainen prioriteetti.
4. Matala vakavuus, matala prioriteetti
Kirjoitusvirheet, fontit, kohdistusvirheet sovelluksen myöhemmillä sivuilla, joita käyttäjät eivät usein pääse käsiksi, kuuluvat tähän luokkaan.
varten esimerkki , kirjoitusvirheet käyttöehtosivulla tai tietosuojakäytäntösivuilla ovat heikkolaatuisia ja alhaisen prioriteetin vikoja.
3. Vian todennäköisyys
Vian todennäköisyys on todennäköisyys sille, että käyttäjä näkee vian.
Vian todennäköisyyttä voidaan kutsua myös vian näkyvyydeksi, vian näkyvyydeksi tai vian todennäköisyydeksi, ja se ilmaistaan prosentteina (%).
Vian todennäköisyys määritetään tietyn ominaisuuden tai komponentin, mutta ei koko järjestelmän osalta.
Näin ollen matalan todennäköisyyden vika saattaa esiintyä laajalti käytetyssä ominaisuudessa, kun taas suuren todennäköisyyden vikaa käytetään harvoin.
Vian todennäköisyyden tyypit
(i) Korkea
Suuren todennäköisyyden viat ovat sellaisia, jotka käyttäjät voivat helposti kohdata.
Nämä viat ovat läsnä lähes kaikissa käyttäjän pääsyn ominaisuuksissa.
(ii) Keskikokoinen
Jos tiettyä ominaisuutta testattaessa yli 50 % sen käyttäjistä havaitsee vian, vika luokitellaan keskitodennäköisyydeksi.
(iii) Matala
Pienen todennäköisyyden vikoja kohtaavat vain harvat käyttäjät, eikä niitä tarvitse korjata heti.
Vian elinkaari
Vian elinkaari tai vian elinkaari on määritellyt joukon tiloja, jotka vika käy läpi koko elinkaarensa aikana ja jotka havaitaan ratkaistuksi/hylätyksi/lykätyksi.
Virheen elinkaari voidaan ymmärtää bugin kasvusyklinä, joka on määritelty helpottamaan eri tiimien välistä koordinointia ja viestintää.
Virhekierto vaihtelee organisaation, työkalujen (JIRA, QC jne.) ja projektin tyypin mukaan.
Vikavaltiot
Ohjelmistotestauksessa vian tai vian elinkaaressa on erilaisia tiloja. Ne ovat seuraavat:
Uusi: Kun testausryhmä havaitsee virheen tai virheen kehitetyssä sovelluksessa, ohjelmiston bugisykli käynnistyy ja bugin sanotaan olevan uudessa tilassa.
Määrätty: Kun vika on löydetty, testijohto tai projektipäällikkö hyväksyy vian ja antaa sen kehitystiimille muuttamalla vian tilaksi Assigned.
Avata: Kun kehitystiimi pitää vian käsittelyssä, sille määritetään avoin tila. Kehittäjät saattavat alkaa korjata virhettä, jos se ei kuulu seuraaviin vian elinkaaren luokkiin:
- Vika odotetaan korjattavan myöhemmissä versioissa.
- Vika on pieni eikä vaadi välitöntä huomiota.
- Asiakas saattaa muuttaa asiakkaan vaatimuksia.
- Virhe ei liity ohjelmiston nykyiseen koontiversioon.
- Tiimin johtajan tai projektipäällikön tulee varmistaa, että tiimin jäsenet tietävät vastuunsa virheestä ja sen tilasta.
- Vian tila tulee määrittää ja säilyttää.
- Varmista, että koko vian elinkaari on hyvin dokumentoitu ja jokainen tiimisi jäsen ymmärtää sen.
- Ennen vian tilan muuttamista on ilmoitettava uskottava ja yksityiskohtainen syy.
- Ongelmaan liittyvät järjestelmät,
- Ongelman aika,
- Ongelman vaikutus ja
- Ongelmaan osallistuva henkilö.
- Samojen asioiden käsittelyn vähentäminen yhä uudelleen ja uudelleen.
- Toistuvien ongelmien ehkäisy.
- Vähentää ongelmien korjaamisen kustannuksia.
- Tarjoaa asiakkaille ja sidosryhmille mitättömiä vikoja ohjelmistoja
- Kehittäjän looginen virhe aiheuttaa virheen.
- Suunnitteluvirhe arkkitehdin tekemä.
- Inhimilliset tavat, kuten letargia, viivyttely tai muut, aiheuttavat virheen.
- Virheet voivat johtua asiakkaiden antamista virheellisistä tai riittämättömistä tiedoista.
- Liiketoimintaanalyytikon virheellinen tulkinta vaatimuksista aiheuttaa virheen.
- Vaatimusten virheviestintä analyytikon ja kehittäjän välillä johtaa virheisiin.
- Löytö – viasta
- Luokittelu – viasta
- Vian korjaaminen/ratkaisu – kehittäjät
- Varmentaminen – testaajien toimesta
- Sulkeminen – viasta
- Vikaraportti
Korjattu: Vian korjaamisen jälkeen kehitystiimi siirtää vian testaustiimille uudelleen testattavaksi antamalla sille Fixed-tilan.
Odottaa uudelleentestausta: Kun testausryhmä vastaanottaa korjatun tilan vian vian elinkaaren edellisestä vaiheesta, bugille määritetään Odottaa uudelleentestauksen tila.
Testaa uudelleen: Kun sovelluksen uusintatestaus on alkanut tarkistaa, onko vika korjattu vai ei, vialle annetaan Retest-tila. Kun vian uudelleentestaus on valmis, testausryhmä voi määrittää sille jommankumman virhesyklin kahdesta tilasta:
Avaa uudelleen: Jos vikaa ei korjata uudelleentestauksen jälkeenkään, testaus antaa bugille Reopen-tilan ja lähettää sen takaisin kehitystiimille.
Vahvistettu: Jos vika on korjattu kokonaan, vialle annetaan Vahvistettu-tila, mikä tarkoittaa, että vika on korjattu ja laadunvarmistusviranomainen varmentanut.
Suljettu: Kun kehittäjä on korjannut vian ja testaaja on vahvistanut, vian tilaksi muutetaan Suljettu. Vian elinkaari myös päättyy tämän tilan valmistuttua.
Vian elinkaariohjeet
On olemassa erityisiä ohjeita, jotka on otettava huomioon ennen vian elinkaaren tilojen määrittelemistä. He ovat:
Vian syyanalyysi
Nyt kun olemme nähneet viat ja vikojen elinkaariluokituksen, katsotaanpa vikojen perussyyanalyysiä (RCA) ymmärtääksemme sen perimmäiset syyt.
Jos tämä analyysi tehdään systemaattisesti, niin nykyinen ohjelmisto hyödyttää paitsi koko organisaatiota.
Perussyyanalyysi auttaa löytämään vikoja varhaisessa vaiheessa, mikä vähentää niiden korjaamisen kokonaiskustannuksia pitkällä aikavälillä. Se voidaan tehdä suunnitteluvirheille, testausvirheille sekä tuotevirheille.
Muista kuitenkin, että juurisyyanalyysin tarkoituksena ei ole hoitaa tai ratkaista vikoja, vaan ainoastaan löytää tai diagnosoida ne.
Kun harkitsemme jääkaapin mekaanikon tapaustutkimusta, voimme ymmärtää perussyyanalyysiä paremmin. Hyvä mekaanikko löytää ensin jääkaapin ongelmien perimmäisen syyn ja sitten käyttää asianmukaisia menetelmiä sen korjaamiseksi.
Perussyyanalyysiä voidaan pitää käänteissuunnittelumekanismina, jossa tapahtumaketju kulkee taaksepäin viimeisestä mahdollisesta toiminnasta alkaen.
Prosessi (5W1H-menetelmä)
Alla olevien neljän kysymyksen avulla voidaan suorittaa juurisyyanalyysi:
Mitä?
Ensimmäinen ja olennainen vaihe perussyyanalyysiprosessissa on määrittää, MIKÄ ongelma on.
On mahdotonta määrittää ongelman perimmäistä syytä, jos emme tiedä tarkalleen ongelmaa.
varten esimerkki , verkkosivustosi käyttäjät ovat valittaneet, etteivät he voi kirjautua sisään oikealla tunnuksella ja salasanalla.
Kun?
Seuraava vaihe on määrittää, milloin tietty ongelma on ilmennyt.
Esimerkiksi Käyttäjät eivät voineet kirjautua sisään kello 4.00–5.00.
Missä?
Tämä vaihe määrittää, missä ongelma esiintyi, eli millä verkkosivuston sivulla tai ohjelmiston sijainnilla.
varten esimerkki , käyttäjät eivät voineet kirjautua sisään kirjautumissivulle, joten ongelma ilmeni kirjautumissivulla.
WHO?
Tämä kysymys koskee henkilöä, joka oli mukana ongelman ratkaisemisessa.
varten esimerkki , palvelimen ylläpitäjä vastasi palvelimen ylläpidosta, mikä johti kirjautumisongelmiin käyttäjien kanssa.
Miksi?
Tämä vaihe käsittelee ongelman syyn tunnistamista ja sen taustalla olevan perimmäisen syyn yksityiskohtaista analyysiä.
varten esimerkki , palvelimet olivat pois käytöstä huollon vuoksi, mikä häiritsi käyttäjien kirjautumista.
Miten?
Tämä on viimeinen vaihe juurisyyanalyysiprosessissa. Se auttaa meitä varmistamaan, että ongelma ei toistu tulevaisuudessa.
varten esimerkki , varmistamalla, että sähköposti tai tekstiviesti lähetetään kaikille rekisteröityneille käyttäjille aina kun järjestelmä on kunnossa, auttaa meitä estämään sen esiintymisen tulevaisuudessa.
Vaiheittainen syyanalyysi
On välttämätöntä ottaa käyttöön rakenteellinen ja organisoitu lähestymistapa perussyyanalyysiin.
Noudatettavat vaiheet ovat:
1. Muodosta perussyyanalyysiryhmä
Jokaisen tiimin tehtävänä on olla RCA-päällikkö, joka kerää ongelmiin liittyvät tiedot ja käynnistää RCA-prosessin.
Jokaisen tiimin henkilöstön eli vaatimusten, testauksen, laadun, suunnittelun, tuen ja ylläpidon sekä dokumentoinnin tulee olla RCA-tiimissä.
Jokainen joukkue on vastuussa vian jäljittämisestä ja sen selvittämisestä, mikä meni vikaan omassa vaiheessaan tapausraportin, ongelman todisteiden jne. avulla.
2. Määrittele
Kun tapahtumaraportti, ongelman todisteet ja muut asiakirjat on kerätty, RCA-tiimi tutkii ongelmaa ja yrittää määrittää:
Tapahtumasarja, joka johtaa käyttäjän ongelmaan,
3. Tunnistaminen
Ongelman määrittämisen jälkeen RCA-tiimi voi käyttää Fishbone- tai 5 Why Analysis -työkalua selvittääkseen perimmäisen syyn.
RCA-päällikkö auttaa sitten määrittämään säännöt aivoriihitapahtuman sujuvaa toimintaa varten.
4. Perussyyn korjaavan toiminnan toteuttaminen (RCCA)
Toimituspäällikön avulla määritetään toimituspäivämäärä ja korjausta vaativat versiot, jonka jälkeen aloitetaan korjaustoimet.
Esimerkiksi kun tukitiimi tarjoaa käyttäjille korjauksen heidän ongelmaansa, se on väliaikainen. RCCA-toteutus tarjoaa pysyvän korjauksen, jotta vika ei toistu tulevaisuudessa.
5. Perussyyn ennaltaehkäisevän toiminnan toteuttaminen (RCPA)
RCPA käsittelee tällaisten vastaavien ongelmien estämistä tulevaisuudessa päivitetyllä ohjekirjalla, päivitetyllä tiimin arvioinnin tarkistuslistalla, parannetulla taitosarjalla jne.
Perussyyanalyysin edut
RCA auttaa
Virhe vs vika vs epäonnistuminen
Yleensä testausaloittelijat ovat hämmentyneitä siitä, mitä termiä tulisi käyttää järjestelmän/sovelluksen poikkeavuudesta tai odottamattomasta lähdöstä.
He kutsuvat näitä poikkeavuuksia virheiksi, bugeiksi, vikoiksi tai epäonnistumisiksi ja käyttävät näitä termejä vaihtokelpoisesti ymmärtämättä selvästi, mitä ne tarkoittavat.
Katsotaan kuinka virheet, viat ja viat eroavat toisistaan.
Ehdot
Ensin keskustellaan muutamista erilaisista termeistä, joita aloittelijatestaajat käyttävät.
Virhe: Virhe voi olla virhe, väärinkäsitys tai kehittäjän tekemä väärinkäsitys. Kehittäjät voivat olla ohjelmoijia, ohjelmistoinsinöörit , analyytikot ja testaajat. Virhe aiheuttaa muutoksia ohjelman toimivuuteen. Saattaa esimerkiksi käydä niin, että ohjelmaa kirjoitettaessa muuttujan nimeä käytetään väärin. Tämä voi johtaa silmukointiin tai muihin syntaktisiin virheisiin.
Vika: Se on kohta, jossa sovellus tai ohjelmisto poikkeaa asiakkaan vaatimuksista. Se voi olla mikä tahansa ongelma, joka liittyy järjestelmän ulkoiseen tai sisäiseen käyttäytymiseen ja ominaisuuksiin.
Virhe: Testaajan löytämää virhettä kutsutaan virheeksi. Virhe, jos sitä ei käsitellä oikein, saattaa joutua asiakkaalle ja saa ohjelman toimimaan huonosti ja tuottaa odottamattomia tuloksia. Se voi myös johtaa sovelluksen kaatumisiin.
Väärä: Kun kehitettyä ohjelmistoa ei ole toteutettu vaatimusten mukaisesti, sen sanotaan olevan väärä.
Extra: Se on ohjelmiston ei-toivottu tai määrittelemätön osa, jota ei ole määritelty käyttäjän vaatimuksessa. Käyttäjä saattaa vaatia tätä attribuuttia tai ei, ja siksi sitä pidetään puutteena.
Vika: Virheet voivat johtaa virheisiin. Se on ohjelman virheellinen vaihe, prosessi tai määritelmä, joka saa sen toimimaan väärin. Vika on poikkeama, joka saa ohjelman toimimaan odottamattomalla, odottamattomalla tai tahattomalla tavalla.
Puuttuu: Ylimääräisen vastakohtana puuttuminen on vian luokittelu, kun ohjelmisto ei täytä käyttäjän vaatimuksia. Se tapahtuu, kun yhtä tai useampaa käyttäjän tarpeesta johtuvaa määritystä ei ole toteutettu.
Epäonnistuminen: Kun mikä tahansa vika saavuttaa loppuasiakkaan, sitä kutsutaan viaksi. Se määritellään ohjelmistojärjestelmän tai -komponentin kyvyttömyyteen toimia niin kuin sen on tarkoitus, eli määriteltyjen vaatimusten puitteissa.
Johdatus virheeseen, vikaan ja epäonnistumiseen
Joku voi ymmärtää virheen, vian ja vian seuraavan esimerkin avulla:
Läsnäoloohjelmistoa luodessaan kehittäjä unohtaa lisätä puolen päivän toiminnallisuuden. Tämä on virhe tai virhe. Se johtaa virheeseen tai virheeseen ohjelmistossa, koska tämä toiminto on välttämätön. Nyt jos tämä sovellus kehitetään ja toimitetaan asiakkaalle, niin ohjelmisto merkitään poissaolevaksi, jos joku organisaatiossa vie puoli päivää. Siten järjestelmä ei tee sitä, mitä sen piti tehdä, ja tämä aiheuttaa vian.
Virhe
Erehtyminen on inhimillistä.
Virhe on inhimillinen virhe, joka johtuu kehittäjän virheestä, väärinkäsityksestä tai väärinkäsityksestä.
Yksittäinen virhe voi aiheuttaa sarjan vikoja ohjelmistossa.
Se voi johtua:
Virhetyypit
Virheiden syyt
Joitakin mahdollisia syitä siihen, miksi ohjelmistotuotteessa esiintyy virheitä, ovat:
Virhe vs vika vs epäonnistuminen
| Virhe | Vika | Epäonnistuminen |
| Se on virhe. | Virhe aiheuttaa vian. | Vika johtaa epäonnistumiseen. |
| Ihmisen toiminta tuottaa odottamattomia tuloksia. | Tuotteessa tai ohjelmistossa on tietty puute, jonka vuoksi se ei täytä vaadittuja määrityksiä. | Komponentti tai järjestelmä ei suorita vaadittuja toimintoja ennalta määritettyjen ehtojen mukaisesti. |
| Kaikki virheet eivät johda virheisiin. Esimerkiksi yksinkertaista kielioppivirhettä ei pidetä puutteena. | Kaikki viat eivät johda epäonnistumiseen. Esimerkiksi tietty toiminto saattaa vaatia tiettyjä ennakkoehtoja, mutta ne eivät ole välttämättömiä eivätkä siten aiheuta vikaa. | Kaikki epäonnistumiset eivät ole kriittisiä. Esimerkiksi asiakkaan on ehkä parannettava järjestelmän versiota ohjelmistoa käyttäessään, koska asiakkaan versio on vanhentunut. |
Viimeiset sanat
Yhden poikkeaman ilmaantuminen tai esiintyminen johtaa muihin ongelmiin, ja siten se kaikki liittyy toisiinsa.
Virheet johtuvat inhimillisistä virheistä, jotka johtavat poikkeamiseen vaatimuksista ja aiheuttavat puutteita.
Vika voi olla kriittinen tai ei, joten se ei välttämättä tarkoita virhettä koodissa.
Se voi olla myös vaatimuksissa määritelty toteuttamaton toiminto.
Tarkista siis huolellisesti, ennen kuin teet sen johtopäätöksen, että koodi on virheellinen.
Vikaraportti
Vikaraportti tai virheraportti on dokumentti, joka tunnistaa ja kuvaa testaajan havaitseman vian. Vikaraporttia voidaan käyttää samantyyppisten vikojen tunnistamiseen tulevaisuudessa niiden välttämiseksi.
Määritä ohjelmistotestauksen vika
Virhe tai vika on seuraus tai seuraus koodausvirheestä, joka ei täytä todellisia vaatimuksia.
Kun testaajat suorittavat testitapausten testaamista, sovelluskohdan vaihtelu tai poikkeama loppukäyttäjän vaatimuksista, joka aiheuttaa virheellisiä tai odottamattomia tuloksia, on vika.
Ongelmia, bugeja, ongelmia tai tapauksia kutsutaan yleisesti ohjelmistotestausvirheiden nimiksi.
Määritä vikaraportti
Vikaraportiksi kutsutaan dokumentaatiota, joka määrittää vian esiintymisen, tilan ja luonteen läpinäkyvästi, jotta kehittäjät voivat helposti kopioida ja korjata sen.
Asiakirja sisältää tietoja viasta, kuten sen kuvauksen, sen löytäneen testaajan nimen, virheen havaitsemispäivämäärän, sen korjaaneen kehittäjän ja paljon muuta.
Malli vikailmoitukselle
Vikaraporttien malli voi vaihdella työkalusta toiseen. Yleinen vikaraporttimalli on kuitenkin seuraava:
| ID | Automaattinen tai manuaalinen yksilöllinen tunniste vian tunnistamiseksi |
| Projekti | Projektin nimi |
| Tuote | Tuotteen nimi |
| Julkaisuversio | Tuotteen julkaisuversio |
| Moduuli | Moduuli, jossa vika havaittiin. |
| Havaittu versioversio | Tuotteen versio, jossa vika havaittiin. |
| Yhteenveto | Selkeä ja ytimekäs yhteenveto löydetystä viasta. |
| Kuvaus | Yksinkertainen ja kattava kuvaus viasta. Älä käytä mitään toistuvasti tai käytä monimutkaisia sanoja. |
| Toistamisen vaiheet | Vaiheittainen kuvaus vikojen toistoon useilla vaiheilla. |
| Todelliset tulokset | Todelliset tulokset saatiin vaiheiden noudattamisen jälkeen. |
| odotetut tulokset | Nämä tulokset odotettiin saatavan vaiheiden noudattamisen jälkeen. |
| Liitteet | Lisätietoja, kuten kuvakaappauksia ja lokeja. |
| Huomautukset | Lisäkommentteja viasta. |
| Vian todennäköisyys | Vian todennäköisyys. |
| Vian vakavuus | Vian vakavuus. |
| Ilmoittanut | Viasta ilmoittaneen henkilön nimi. |
| Määritetty | Sen henkilön nimi, jolle vika on annettu analysoitavaksi tai korjattavaksi. |
| Tila | Vian tila |
| Kiinteä versio | Rakenna versio tuotteesta vian korjaamisen jälkeen. |
Vianhallintaprosessi
Järjestelmällistä prosessia virheiden tunnistamiseksi ja korjaamiseksi kutsutaan vianhallintaprosessiksi.
Vianhallintasyklissä on seuraavat kuusi vaihetta:
1. Löytö
Tässä vaiheessa testaajat selvittävät mahdollisimman monta vikaa ennen kuin loppukäyttäjä havaitsee ne.
Kun kehittäjät ovat tunnustaneet ja hyväksyneet puutteen, sitä voidaan kutsua löydetyksi.
2. Luokittelu
Luokittelu tarkoittaa erilaisten vikojen jakamista niiden tärkeysjärjestyksen mukaan, jotta kehittäjät voivat korjata ne vastaavasti.
Luokkia on neljä:
3. Resoluutio
Ohjelmistotestauksessa vikojen korjaaminen tai vianselvitys on yleensä nelivaiheinen prosessi, joka auttaa korjaamaan ja jäljittämään vikoja helposti.
Alkaen virheiden osoittamisesta kehittäjille, jota seuraa viankorjausaikataulu, jonka jälkeen viat korjataan, prosessi päättyy, kun ratkaisuraportti lähetetään testipäällikölle.
4. Vahvistus
Testausryhmä tarkistaa, ovatko kehitysryhmän korjaamat viat korjattu vai eivät.
5. Sulkeminen
Onnistuneen korjaamisen ja vian tarkistamisen jälkeen vian tilaksi muutetaan suljettu. Jos näin ei tapahdu, testaajat tarkistavat vian uudelleen.
6. Raportointi
Johtokunnan tulee ymmärtää vianhallintaprosessi ja sillä on oltava oikeus tietää vikatila.
Testauspäällikkö laatii vikaraportin ja lähettää sen palautetta varten johtoryhmälle. Johtoryhmä tarkistaa vianhallintaprosessin ja lähettää tarvittaessa palautetta tai tukea.
Vioista ilmoittaminen parantaa viestintää ja vikojen seurantaa.
Vianhallintaprosessin tarve
Konkreettisen vianhallintaprosessin vaatimus voidaan ymmärtää paremmin seuraavan esimerkin avulla:
Oletetaan, että Task Manager -sovellusta testataan.
Testauksen aikana testausryhmä löysi joitakin bugeja, esimerkiksi 80, ja niistä ilmoitettiin testipäällikölle.
Testipäällikkö ilmoittaa vioista kehitystiimille, jotka vastaavat viikon kuluttua 70 vian korjauksella.
Testauspäällikkö lähettää nämä tiedot testaustiimille.
Testausryhmä vastasi viikkoa myöhemmin ja ilmoitti, että 70 vikaa oli korjattu, mutta 20 uutta ilmeni.
Nyt tämä koko prosessi voi olla hieman monimutkainen vain sanallisen viestinnän vuoksi. Vikojen jäljittäminen ja korjaaminen tulee olemaan vaikeaa.
Siksi tarvitaan vianhallintaprosessi.
Tehokas vikailmoitus
Vikailmoitukset on luotava tehokkaasti.
Tämä auttaa säästämään aikaa ja turhaa vaivaa yritettäessä ymmärtää ja toistaa vika.
Seuraavia toimenpiteitä voidaan noudattaa hyödyllisten vikaraporttien varmistamiseksi:
1. Pelaa:
Kun vika on paljastettu, toista se vielä kerran varmuuden vuoksi. Jos replikointi ei ole mahdollista, muista tarkat testiolosuhteet, jotka johtivat virheeseen, ja yritä uudelleen. Jos vika ei kuitenkaan vieläkään toistu, lähetä yksityiskohtaiset vikaraportit ja kaikki koetulokset lisätutkimuksia varten.
2. Ole täsmällinen:
Jokaisen vikaraportin toimenpiteen tulee olla erityinen.
Esimerkiksi sen sijaan, että sanoisi Kirjaudu sisään, siellä pitäisi olla (1) Siirry kotisivulle, (2) Napsauta kirjautumispainiketta, (3) Anna käyttäjätunnus ja salasana ja (4) napsauta Kirjaudu.
Jos esimerkiksi polkuja on useita, mainitse tarkka polku, jota seurattiin ja johda virheeseen.
Vältä käyttämästä epämääräisiä pronomineja, kuten se, ja määritä, mitä se tarkoittaa.
3. Tavoite:
Sen sijaan, että käyttäisit subjektiivisia lausuntoja, kuten surkea sovellus, vältä tunteita ja sano objektiivisesti Kyllä tai Ei tai Hyväksytty tai Hylätty.
4. Tarkista:
Kirjoittamisen jälkeen lähetä se vasta tarkastettuasi ja poistanut kirjoitusvirheet.
5. Yksityiskohtiin suuntautunut:
Anna tiedot yksityiskohtaisesti. Kehittäjät eivät saa joutua tiedon puutteesta.
Vikamittarit
Vikamittareita käytetään mittaamaan testin suorittamisen laatua. On kaksi parametria:
Vian hylkäyssuhde (DRR) = (hylättyjen vikojen määrä / havaittujen vikojen kokonaismäärä) * 100
Vian vuotosuhde (DLR) = (puuttuneiden vikojen määrä / ohjelmiston vikojen kokonaismäärä) * 100
Jos DRR- ja DLR-arvot ovat pieniä, testin suorittamisen laatu on parempi. Testinhallinta määrittää näiden arvojen hyväksytyt alueet.
Näitä suhteita voidaan pienentää
Tiimin jäsenten testaustaitojen parantaminen.
Käytä enemmän aikaa testin suorittamiseen ja tulosten tarkistamiseen.
Oletetaan esimerkiksi, että Task Manager -projektissa on 80 vikaa, mutta testausryhmä pystyi tunnistamaan vain 60. Näistä kehitystiimi hylkäsi 10 vikaa. Siten 20 vikaa puuttui.
Joten DRR-suhde on:
(10/60) * 100 = 16,66 %
Ja DLR-suhde tulee olemaan:
(20/80) * 100 = 25 %
Vika FAQ
Mikä on vikaesimerkki?
Esimerkki ohjelmistovirheestä voi olla käyttöliittymän kielioppivirhe tai ohjelman koodausvirheet.
Mikä toinen sana on vialle?
Ohjelmistotestauksessa vikaa voidaan kutsua bugiksi, virheeksi, viaksi ja moneksi muuksi.
Mikä on viankorjaus?
Vian sanotaan korjatuksi, kun sen tila on merkitty suljetuksi. Vian tila vaihtuu suljetuksi, kun se joko varmistetaan riittävästi tai se säilytetään korjausta varten myöhemmissä julkaisuissa.
Mikä on vian elinkaari?
Vian elinkaari eli vian elinkaari on matka vian tunnistamisesta korjaamiseen. Vika muuttuu elinkaarensa aikana tunnistetusta määritetystä aktiiviseksi testattavaksi, varmennettavaksi ja suljettavaksi. Vika voi myös mennä hylättyyn tai lykättyyn tilaan tai uudelleen avattuun tilaan. Nämä tilat vaihtelevat organisaatioittain testaukseen käytetyn työkalun mukaan.
Miten hallitset vikoja?
Vikoja voidaan vähentää seuraavilla tavoilla:
1. Vikaanalyysin tehokas suorittaminen
2. Ohjelmistovaatimusten perusteellinen analysointi
3. Virheenvalvontaohjelmiston käyttö
4. Aggressiivinen regressiotestaus
5. Toistuva koodin uudelleenmuodostus.