Ko darītu, ja jums būtu išleidžiama versija, bet nuolat atsiranda naujų problemų, ir jų sprendimas sukelia naują regresijos fazę?

Novērtēt jauno problēmu kritiskumu. Noteikt, kuri no tām ir galvenās problēmas izlaišanas laikā, un kuras var novērst nākamajā sprintā vai patchā. Organizēt kopēju izstrādes, testēšanas un produktu vadības komandas sanāksmi, lai pieņemtu lēmumu par turpmākajiem soļiem. Iespējas:

• Atlikt izlaišanu līdz kritisko problēmu novēršanai.
• Izlaist versiju ar zināmiem, nekritiskiem problēmām, dokumentējot tās.
• Nekavējoties pēc izlaišanas izlaist labojuma versiju (patch) ar kritisko problēmu risinājumiem.

Vienlaikus ar lēmuma pieņemšanu:

• Koncentrēties uz kritisko funkcionalitātes daļu testēšanu.
• Efektīvi sazināties par statusu un atrastajām problēmām. Izmantot kopīgas uzdevumu dēļus (Jira, Azure DevOps utt.).
• Analizēt iemeslus, kāpēc pastāvīgi rodas jaunas problēmas:
  • Testu pārklājums ir nepietiekams (rokas vai automatizēts).
  • Problēmas izstrādes procesā (koda pārskatīšana, kodēšanas kultūra).
  • Steiga izstrādē un testēšanā.
  • Nepietiekama prasību specifikācija.

Ja nepieciešams, pastiprināt regresijas testēšanu, prioritizējot to. Var būt nepieciešami papildu resursi vai uzdevumu pārredistribūcija komandas ietvaros. Automatizēt biežākos un kritiskākos regresijas scenārijus, ja tas ir iespējams īsā laikā. Pēc izlaišanas veikt retrospektīvu, lai identificētu un novērstu problēmu cēloņus.