Kādi ir iemesli, kāpēc testēšanas procesā mainās Severity un Priority statusi?

Defekta Severity un Priority statusa maiņa testēšanas procesā var notikt vairāku iemeslu dēļ:

1. Defekta ietekmes izpratnes maiņa: Sākotnēji ietekme varēja tikt novērtēta par zemu (piemēram, tika uzskatīts, ka tas ir UI problēma, bet patiesībā tas ietekmē kritisku biznesa loģiku) vai pārvērtēta.
2. Biznesa prasību vai prioritāšu maiņa: Ja defekts attiecas uz funkcionalitāti, kas kļuvusi svarīgāka vai mazāk svarīga biznesam, tā prioritāte var tikt koriģēta.
3. Aizvietošanas ceļa (workaround) atklāšana: Ja ir atrasts vienkāršs veids, kā apiet defektu bez būtiskiem zaudējumiem lietotājam, tā Priority var tikt samazināta. Severity parasti paliek nemainīga, jo apiet neizlabo pašu problēmu.
4. Citu defektu atkarība: Viena defekta labošana var pastiprināt vai mazināt cita ietekmi, kas var prasīt to statusu pārskatīšanu.
5. Lietotāju skaita maiņa: Ja defekts, kas sākotnēji šķita nenozīmīgs, tiek konstatēts pie daudz lietotāju, tā Priority var tikt palielināta.
6. Nepareiza sākotnējā novērtējuma kļūda: Testētājs varēja kļūdaini noteikt Severity vai Priority sakarā ar nepietiekamu konteksta, funkcionalitātes vai biznesa procesu izpratni.
7. Izstrādes/testēšanas posmu maiņa: Dažādos posmos (piemēram, vienību testēšana, integrācija, sistēmas, pieņemšana) tas pats defekts var tikt uztverts dažādi.
8. Komandas vai vadītāja lēmums: Galīgais lēmums par Severity un Priority bieži tiek pieņemts kolektīvi ar komandas vadītāja, projekta vadītāja vai Product Owner piedalīšanos, īpaši strīdīgos gadījumos.
9. Jaunu scenāriju atklāšana, kas attiecas uz defektu: Ja defekts parādās vairākos scenārijos nekā sākotnēji bija plānots, tā Severity vai Priority var tikt palielināta.

Statusa izmaiņas vienmēr jābalsta uz pamatotiem iemesliem un jādokumenti defektu uzraudzības sistēmā.