Millised on põhjused, miks muutuvad testimise protsessis Severity ja Priority staatused?

Defekti Severity ja Priority staatuse muutmine testimise protsessis võib toimuda mitmel põhjusel:

1. Defekti mõju mõistmise muutus: Alguses võis mõju olla alahinnatud (näiteks arvati, et probleem on UI, kuid tegelikult mõjutab see kriitilist äriloogikat) või ülehinnatud.
2. Ärireeglite või prioriteetide muutus: Kui defekt puudutab funktsiooni, mis on muutunud ettevõtte jaoks olulisemaks või vähem oluliseks, võib selle prioriteet muutuda.
3. Tööriista (workaround) leidmine: Kui leiti lihtne viis defektist möödumiseks ilma kasutajale olulist kahju tekitamata, võib selle Priority väheneda. Severity jääb tavaliselt samaks, kuna möödalaskmine ei lahenda probleemi ise.
4. Teiste defektide sõltuvus: Ühe defekti parandamine võib halvendada või leevendada teise mõju, mis võib nõuda nende staatuste ülevaatamist.
5. Kasutajate arvu muutus: Kui väike defekt avastatakse suurel hulgal kasutajate seas, võib selle Priority tõusta.
6. Ebakorrektne algne hinnang: Testija võis valesti määrata Severity või Priority, kuna ei olnud piisavalt konteksti, funktsionaalsust või äriprotsesse mõistetud.
7. Arendus- või testimise etappide muutus: Erinevatel etappidel (näiteks üksuse testimine, integratsioon, süsteem, vastuvõtt) võib sama defekti mõju tajuda erinevalt.
8. Meeskonna või juhtkonna otsus: Lõplik otsus Severity ja Priority kohta tehakse sageli meeskonna arutelu käigus, osalevad tiimijuht, projekti juht või Product Owner, eriti vaidlusalustel juhtudel.
9. Uute kasutusjuhtumite avastamine, mis puudutavad defekti: Kui defekt ilmneb rohkemates stsenaariumides kui algselt eeldati, võib selle Severity või Priority tõusta.

Status muutused peavad alati olema põhjendatud ja dokumenteeritud defektide jälgimissüsteemis.