Какие Quality Gates используются на вашем текущем проекте?

На проекте, где я работаю QA-инженером, мы внедрили несколько Quality Gates в CI/CD пайплайн для автоматического контроля качества.

Основные гейты включают:

1. Покрытие тестами (Test Coverage Gate):

   • Устанавливаем минимальный порог покрытия unit-тестами (например, 75% для новых модулей).
   • Используем инструменты вроде JaCoCo для Java или coverage.py для Python. Сборка падает, если порог не достигнут.
   • Пример конфигурации для Maven/JaCoCo:

     <configuration>
     <rules>
     <rule>
       <element>BUNDLE</element>
       <limits>
         <limit>
           <counter>LINE</counter>
           <value>COVEREDRATIO</value>
           <minimum>0.75</minimum>
         </limit>
       </limits>
     </rule>
     </rules>
     </configuration>

2. Статический анализ кода (Static Code Analysis Gate):

   • Интеграция с SonarQube или ESLint/TSLint. Сборка блокируется при обнаружении:
     • Критических уязвимостей или блокирующих (Blocker) issues.
     • Высокого уровня технического долга, превышающего установленный лимит.
     • Дублирования кода выше определенного процента.

3. Результаты автоматических тестов (Automated Test Results Gate):

   • Все unit-тесты должны проходить успешно.
   • Критические интеграционные и API-тесты (помеченные специальными тегами, например, @smoke или @critical) также обязаны проходить. Мы используем фреймворки вроде pytest или JUnit с интеграцией в Jenkins/GitLab CI.

4. Code Review Gate (Неавтоматизированный, но обязательный):

   • Ни один Pull Request (Merge Request) не может быть влит в основную ветку (main, master) без как минимум одного одобрения (approve) от другого разработчика или старшего QA.
   • Мы используем политики веток в GitHub или GitLab для принудительного соблюдения этого правила.

5. Гейты, специфичные для QA (QA-Specific Gates):

   • Статус тест-рана: Перед релизом в staging-среде должен быть выполнен и успешно пройден определенный набор регрессионных тестов (например, отмеченный тег @regression).
   • Отсутствие открытых критических/блокирующих багов: В тикете на релиз не должно быть открытых багов с приоритетами Critical или Blocker в нашем трекере (Jira, YouTrack).

Эти гейты позволяют нам отлавливать проблемы на ранних этапах и гарантировать, что в основную ветку и дальше на прод попадает только код, соответствующий нашим стандартам качества.