Kokios yra priežastys, kodėl keičiasi Severity ir Priority būsenos testavimo procese?

Defekto Severity ir Priority statuso pakeitimas testavimo proceso metu gali įvykti dėl kelių priežasčių:

1. Defekto poveikio supratimo pokytis: Iš pradžių poveikis galėjo būti nepakankamai įvertintas (pavyzdžiui, buvo laikoma, kad problema yra UI, o iš tikrųjų ji veikia kritinę verslo logiką) arba pervertintas.
2. Verslo reikalavimų ar prioritetų pokytis: Jei defektas susijęs su funkcija, kuri tapo svarbesnė arba mažiau svarbi verslui, jo prioritetas gali būti koreguojamas.
3. Atsarginio kelio (workaround) radimas: Jei rastas paprastas būdas apeiti defektą be reikšmingų nuostolių vartotojui, jo Priority gali būti sumažintas. Severity dažniausiai lieka ta pati, nes apeitis neišsprendžia pačios problemos.
4. Kiti defektai priklausomybė: Vieno defekto pataisa gali pabloginti arba sumažinti kito poveikį, todėl gali prireikti peržiūrėti jų statusus.
5. Naudotojų skaičiaus pokytis: Jei defektas, kuris atrodė mažos reikšmės, yra nustatytas daugeliui naudotojų, jo Priority gali būti padidintas.
6. Netikslus pradinis įvertinimas: Testuotojas galėjo klaidingai nustatyti Severity arba Priority dėl nepakankamo konteksto, funkcionalumo ar verslo procesų supratimo.
7. Kūrimo/testavimo etapų pokytis: Skirtinguose etapuose (pavyzdžiui, vienetinis testavimas, integracija, sisteminis, priėmimas) tas pats defektas gali būti suvokiamas skirtingai.
8. Komandos ar vadovo sprendimas: Galutinį sprendimą dėl Severity ir Priority dažnai priima komandos diskusija, dalyvaujant vadovui, projekto vadovui ar Product Owner, ypač ginčytinuose atvejose.
9. Nauji naudojimo scenarijai, susiję su defektu: Jei defektas pasireiškia daugiau scenarijų nei iš pradžių buvo numatyta, jo Severity arba Priority gali būti padidintas.

Statuso pakeitimai visada turi būti pagrįsti ir dokumentuoti defektų stebėjimo sistemoje.