Какво бихте направили, ако трябваше да пуснете версия, но постоянно се откриват нови проблеми, чието отстраняване води до нова фаза на регресия?

Оценете критичността на новите проблеми. Определете кои от тях са основни пречки за издаването и кои могат да бъдат коригирани в следващия спринт или пач. Организирайте съвместна среща на екипа за разработка, тестове и управление на продукта, за да вземете решение за следващите стъпки. Варианти:

• Отложете издаването, докато не бъдат решени критичните проблеми.
• Издайте версия с известни некритични проблеми, като ги документирате.
• Издайте коригираща версия (patch) веднага след издаването с корекциите на критичните проблеми.

Паралелно с вземането на решение:

• Фокусирайте усилията върху тестването на критичните части на функционалността.
• Ефективно комуникирайте статуса и откритите проблеми. Използвайте общи табла за задачи (Jira, Azure DevOps и др.).
• Анализирайте причините за постоянното появяване на нови проблеми:
  • Недостатъчно покритие на тестовете (ръчни или автоматизирани).
  • Проблеми в процеса на разработка (преглед на код, култура на писане на код).
  • Спешност при разработката и тестването.
  • Недостатъчна спецификация на изискванията.

При необходимост, засилете регресионното тестване, приоритизирайки го. Може да са необходими допълнителни ресурси или преразпределение на задачите в екипа за тестване. Автоматизирайте най-често срещаните и критични сценарии за регресия, ако е възможно в кратки срокове. След издаването, проведете ретроспектива за идентифициране и отстраняване на причините за проблемите.