Co byś zrobił, gdybyś musiał wydać wersję, ale ciągle pojawiają się nowe problemy, a ich naprawa prowadzi do nowej fazy regresji?

Ocenić krytyczność nowych problemów. Zidentyfikować, które z nich są blokadami dla wydania, a które można naprawić w następnym sprincie lub patchu. Przeprowadzić wspólne spotkanie zespołu deweloperskiego, testowego i zarządzania produktem, aby podjąć decyzję o dalszych działaniach. Opcje:

• Odłożyć wydanie do czasu naprawy krytycznych problemów.
• Wypuścić wersję z znanymi niekrytycznymi problemami, dokumentując je.
• Wypuścić wersję naprawczą (patch) zaraz po wydaniu z poprawkami krytycznych problemów.

Równocześnie z podjęciem decyzji:

• Skupić wysiłki na testowaniu krytycznych części funkcjonalności.
• Efektywnie komunikować status i znalezione problemy. Używać wspólnych tablic zadań (Jira, Azure DevOps itp.).
• Analizować przyczyny ciągłego pojawiania się nowych problemów:
  • Niewystarczające pokrycie testami (manualnymi lub automatycznymi).
  • Problemy z procesem rozwoju (przegląd kodu, kultura pisania kodu).
  • Pośpiech w rozwoju i testowaniu.
  • Niewystarczająca specyfikacja wymagań.

W razie potrzeby wzmocnić regresyjne testy, priorytetyzując je. Może być konieczne dodatkowe zasoby lub redystrybucja zadań w zespole testowym. Automatyzować najczęstsze i krytyczne scenariusze regresji, jeśli jest to możliwe w krótkim czasie. Po wydaniu przeprowadzić retrospektywę, aby zidentyfikować i wyeliminować przyczyny źródłowe problemów.