Что значит Release Candidate?

Что такое Release Candidate (RC)?

Release Candidate (RC) — это предрелизная версия программного продукта, которая считается потенциально готовой к финальному выпуску (General Availability, GA). Это ключевой этап в цикле разработки ПО, следующий после бета-тестирования. Основная философия RC заключается в том, что все запланированные функциональные возможности (features) реализованы, критические баги (critical bugs) исправлены, и продукт не должен содержать дефектов, препятствующих его выпуску. По сути, это кандидат на то, чтобы стать финальным релизом.

Цели и задачи стадии Release Candidate

Стадия RC решает несколько критически важных задач в процессе обеспечения качества (Quality Assurance):

• Фокус на стабилизации: В отличие от альфа- или бета-версий, где главное — проверка функциональности и сбор обратной связи, цель RC — найти и устранить оставшиеся, преимущественно критические и блокирующие, дефекты. Разработка новых функций на этой стадии обычно замораживается.
• Финальная всесторонняя проверка: Это последняя возможность для QA-инженеров и бета-тестеров выполнить:

    *   **Регрессионное тестирование (Regression Testing)** — чтобы убедиться, что исправления багов не сломали работавшие ранее части системы.
    *   **Тестирование на соответствие требованиям (Requirements Validation)** — окончательная сверка со спецификациями.
    *   **Тестирование в максимально приближенной к production среде** — включая проверку установки, обновления, конфигурации и работы под нагрузкой.

• Сбор финальной обратной связи от ограниченной аудитории: Часто RC распространяется среди широкого круга бета-тестеров, ключевых клиентов или партнеров для выявления проблем, которые могли ускользнуть от внутренней команды QA.
• Подготовка инфраструктуры: Пока идет тестирование RC, команды поддержки, документации и DevOps готовят финальные релизные пакеты, документацию и развертывание.

Роль QA Engineer на стадии Release Candidate

Для инженера по обеспечению качества эта фаза является одной из самых ответственных и интенсивных. Его деятельность включает:

1. Приоритизацию тестирования: Фокус смещается на критические пути (critical paths) использования продукта, основные сценарии (smoke- и sanity-тесты) и области, где были внесены последние исправления.
2. Жесткий контроль за дефектами: Каждый найденный баг тщательно анализируется:

   # Пример логики принятия решения об исправлении бага в RC
   def should_fix_bug_in_rc(bug_severity, bug_impact, workaround_exists):
       if bug_severity == "Critical" and bug_impact == "Data Loss":
           return True  # Исправляем обязательно
       elif bug_severity == "Major" and not workaround_exists:
           return True  # Высокий приоритет
       elif bug_severity == "Minor":
           return False # Скорее всего, отложим на следующий релиз
       # ... дополнительная логика оценки рисков ...
   

3. Регрессионное тестирование: Автоматизированные тестовые наборы (regression test suites) становятся главным инструментом для быстрой проверки стабильности.
4. Тестирование обновления (Upgrade Testing): Критически важная проверка — может ли текущая версия продукта у клиентов быть беспроблемно обновлена до новой RC (и будущего релиза).
5. Участие в Go/No-Go Meeting: QA-инженер предоставляет итоговый отчет о качестве, основанный на метриках (количество открытых критических багов, процент пройденных тестов и т.д.), который является ключевым входным данным для принятия решения о выпуске финальной версии.

Цикл Release Candidate

Часто бывает не одна, а несколько последовательных версий RC (RC1, RC2 и т.д.). Каждый новый билд включает исправления багов, найденных в предыдущем кандидате, и проходит новый раунд интенсивного тестирования. Цикл повторяется до тех пор, пока не будет достигнут критерий качества, позволяющий присвоить версии статус финального релиза.

Критерии перехода от RC к финальному релизу:

• Отсутствие открытых дефектов с severity Critical и Blocker.
• Все запланированные тесты пройдены.
• Получено одобрение от ключевых стейкхолдеров (продакты, поддержка, менеджмент).

Отличие от других стадий

• Alpha vs RC: Альфа — сырая версия для внутреннего тестирования, функционал может быть неполным.
• Beta vs RC: Бета-версия предназначена для публичного тестирования и обратной связи, в ней еще могут добавляться функции и есть известные баги. RC — это стабильная бета, замороженная для финальной полировки.
• RTM (Release to Manufacturing) / GA vs RC: RTM/GA — это и есть финальная, подписанная к выпуску версия. RC — последний шаг перед этим.

Вывод: Release Candidate — это этап контроля качества и снижения рисков, где QA-инженер играет центральную роль. Это "последний рубеж", на котором проверяется, действительно ли продукт готов к тому, чтобы его использовали клиенты. Успешное прохождение этой фазы напрямую влияет на стабильность и репутацию финального релиза.