Сейчас компетентность в сфере TestOps является таким же базовым требованием к QA-инженерам, как и написание автоматизированных тестов. Причина — в активном развитии CI/CD в проектах и необходимости QA-инженерам работать с пайплайнами (читать как "последовательность этапов в CI/CD") и даже внедрять свои. Так почему же CI/CD — отличный инструмент контроля качества? Давайте разбираться.

Итак, зачем CI/CD тестировщикам?

Автоматический запуск тестов
Контроль качества с помощью Quality Gates
Построение релизного процесса

Автоматический запуск тестов

Кажется, что локальный запуск автотестов — это что-то из далекого прошлого. Тесты запускаются автоматически при помощи CI/CD, это его основная функция.

Допустим, у нас есть девопс и мы делегировали настройку пайплайнов с тестами. Но так мы игнорируем прекрасную возможность реализовать вторую функцию CI/CD — контроль качества с помощью «ворот качества».

Контроль качества с помощью Quality Gates

Что же такое «ворота качества», иначе говоря, проверки качества кода? Давайте посмотрим на нашу «крепость» — код продукта. Каждый день команда разработки пишет код для новых фич, которые могут сломать нашу крепость. Задача QA — тестировать каждую фичу и уменьшать вероятность попадания бага в код продукта. QA мало спит и нервничает, ведь процесс не автоматизирован и нет «сторожа», который контролирует все метрики, даже в самые опасные моменты, например в пятницу вечером, когда разработчик хотел бы пораньше убежать в выходные и доделать все задачи, не перенося их на новую неделю. В этот момент происходит злосчастный merge, который принесет много проблем позже.

Путь нового кода через "ворота качества"

Внедрение проверок качества решает эту проблему.

Каждая из проверок будет отвечать за прохождение важной метрики. Если метрика не соблюдается, «ворота» должны закрыться и не пустить фичу дальше. Пока не пройдут все проверки, фича не будет залита в код продукта, а значит потенциальные баги будут предотвращены.

Из каких проверок качества может состоять CI/CD?

Чтобы максимально автоматизировать процесс, нам нужно составить список проверок для успешного прохождения пайплайна. Можно следовать последовательности проверок качества “fail first” (упади как можно раньше). Первыми идут проверки на работоспособность приложения, а именно: сборка, code style и статический анализ.

Со сборкой все понятно: не собралось приложение — значит, фича не допущена. Code style важно вынести в CI/CD, чтобы унифицировать требования и не тратить время на code style ошибки во время code review.

Статический анализ — важнейший инструмент для анализа качества кода. Он укажет на многие критические ошибки, которые обязательно приведут к багам.

Далее указываем проверки второго уровня: юнит-тесты с анализом покрытия и контролем достижения нужного уровня, а также интеграционные и системные тесты со всеми возможными отчетами для наглядности.

Помимо этого могут быть различные нефункциональные тесты, такие как скриншот-тесты, тестирование производительности, удобства и безопасности.

Общие требования к пайплайну:

он должен гарантировать максимальное качество фич с учетом ваших требований;
длительность пайплайна не должна стопорить рабочий процесс. Обычно на пайплайн выделяется до 20 минут.

Примеры инструментов для внедрения в проверки качества

Code style linter

Стиль кода — это набор правил, которым должна удовлетворять каждая строчка кода в проекте, начиная от правил выравнивания и до правил типа «никогда не использовать глобальные переменные».

Казалось бы, как стиль может влиять на тестировщиков? Оказывается, связь прямая. Есть несколько плюсов, которые проверка стиля дает QA-команде (а, на самом деле, всем членам команды): - благодаря единому стилю в проекте разработчику легче работать с кодом, а значит есть чуть больше времени на реализацию новых фичей и исправление ошибок; - за счет ускорения ревью кода можно не проверять стиль вручную, так как это сделает CI/CD, а значит снова выигрывается немного времени на новые фичи или исправление ошибок.

Примеры руководств по стилю можно подсмотреть у крупных компаний. Например, вот стиль по JavaScript от Airbnb, а вот гайды от Google. Также вы можете написать собственный.

Инструменты для проверки стиля зависят от языка кода. Можно найти подходящий, например, на GitHub, а также узнать, какие инструменты используют в соседних командах. Примеры линтеров — ktlint для Kotlin, checkstyle для Java или eslint для JavaScript. Все они берут какой-то свод правил за основу и подсвечивают места, где код этим правилам не удовлетворяет.

Статический анализ кода

На рынке существует много разных статических анализаторов кода. Рассмотрим один из них под названием Qodana. Основное преимущество этого анализатора кода в том, что он содержит различные инспекции, доступные нам в средах разработки JetBrains, когда мы пишем код.

Многие наверняка использовали IDE-driven подход, когда IDE помогает вам писать код и указывает на различные ошибки: неоптимальное использование кода, необработанный NullPointerException, дубликаты и т. д.

К сожалению, мы не можем быть уверены, что разработчик исправил все найденные проблемы внутри IDE перед коммитом. Один из способов гарантировать отсутствие критичных проблем в коде — внедрить Qodana прямо в CI/CD-пайплайн. Если нельзя пофиксить все сразу, вы сможете выбрать критичные проблемы, добавить их в baseline и постепенно разбирать тех. долг, не замедляя разработку, но при этом контролируя появление новых проблем.

Тестовое покрытие

Покрытие кода — метрика, которая помогает понять, насколько хорошо код покрыт тестами, в большинстве случаев — юнит-тестами.

В проверке качества нужно задать какой-то минимальный процент покрытия, который необходимо поддерживать в проекте. Так код не сможет попасть на боевое окружение, если он не покрыт тестами на достаточном уровне. Минимальный процент устанавливается эмпирическим способом, но стоит помнить, что и стопроцентное покрытие может не избавить код от ошибок полностью. Согласно этой статье от Atlassian, хороший показатель — 80%.

Для разных языков есть разные анализаторы покрытия, например Jacoco для Java, Istanbul для JavaScript, Coverage.py для Python. Всех их можно встроить в CI/CD и удобно следить за метриками.

Построение релизного процесса

Помимо автоматического запуска тестов и выполнения определенных метрик качества кода, CI/CD позволяет тестировщикам выстроить релизный процесс.

Иногда релизный процесс сложен и зависит от множества ручных действий. Часто это целиком ручной релиз: какой-то артефакт собирается одним из разработчиков, потом сборка передается тестировщикам и проверяется, затем передается человеку, который умеет доставлять ее на боевое окружение. Здесь есть много узких мест — представьте, если кто-то из этих людей уйдет в отпуск или заболеет.

Эффективный релизный процесс для каждой команды выглядит по-разному, но чаще всего он включает следующие шаги:

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

Настроить такой процесс позволяет любая CI/CD-система. Он должен быть удобен для всей команды, в том числе и для команды тестирования.

Основные правила релизного процесса:

Артефакты должны быть готовы для скачивания и тестирования, а в идеале — быть собраны в одном месте.
Максимальное количество проверок и тестов должно проходить автоматически, без участия человека.
Все сложные манипуляции со сборками должны быть переложены на автоматизацию, если это возможно.
Все сборки, которые отправляются на боевое окружение, должны быть зафиксированы и доступны в течении некоторого времени после релиза. Это поможет в расследовании ошибок в продакшене, воспроизведении багов и просто отслеживании истории.

В конце хочу напомнить, что, пока качественные метрики не контролируются автоматически и ни на что не влияют, они бесполезны и мы не можем отвечать за качество продукта.

Реализуйте пайплайны, автоматизируйте процессы, используйте статический анализ кода!

Ваша команда Qodana

Спасибо Ирине Хромовой за классные иллюстрации и помощь в написании статьи.

Зачем CI/CD тестировщикам?