Тестирование в общем сборочном конвейере: решение организационных проблем

Крупные компании, которые разрабатывают более одного продукта, анализируя свой процесс тестирования, часто сталкиваются c "зоопарком" инструментов и технологий, методик и практик. В этой статье я рассмотрю организационную часть, связанную с проектированием и интеграцией тестов в общий процесс разработки. Вы узнаете: основные процессные проблемы в тестировании и возможные подходы к их решению, место тестирования в продуктовом сборочном конвейере, общие характеристики основных видов тестов.

Статья может быть полезна тест-архитекторам, руководителям команд и отделов QC и QA, CI-инженерам, а также всем, кто сталкивался с проблемами внедрения процесса тестирования в разработку ПО.

План

1. Организационные проблемы в тестировании
2. Этап тестирования в общем сборочном конвейере
3. Общие технические характеристики тестов

Организационные проблемы в тестировании

Если вам нужно организовать общий процесс тестирования в крупной компании, разрабатывающей несколько продуктов, вы можете столкнуться с некоторыми проблемами:

1. В компании отсутствует единый центр компетенций в тестировании, используется разнообразный инструментарий, нет общего описания процессов тестирования, а также хранилища знаний по лучшим практикам в тестировании.
2. Нет единых технологий и методик тестирования, которых придерживаются все инженеры. Как правило, все продуктовые отделы и отделы QA используют собственные решения и технологии для тестирования, свои форматы описания ручных и авто-тестов: у одной команды описание хранится в коде тестов на GitLab, в docstrings, у другой — в трекерах (TFS, YouTrack, Jira etc), TestRail или ReportPortal, а у кого-то тест-планы записаны на вики или в Excel-табличке.
3. "Зоопарк" тестовых фреймворков под все языки программирования или свои собственные разработки.
4. Различные виды отчётности по тестам: кому-то хватает вывода в консоль CI-системы GitLab CI, кто-то хранит результаты тестранов в в build log на TeamCity или в отчёте Allure, где-то результаты отрисованы через pytest-plugin или реализован свой вывод, а кто-то пушит результаты в трекеры (TFS, YouTrack, Jira etc), Artifactory, сервисы TestRail, ReportPortal или вообще шлёт письмом.
5. Различные способы доставки тестируемых компонентов и инсталляторов на тестовые стенды: кто-то устанавливает их вручную, кто-то через специальные метараннеры в TeamCity или job-ы в GitLab CI, кто-то использует saltstack или bash-скрипты.
6. Различные типы тестов: где-то один большой мега-тест, интегрированный в собственный тестовый фреймворк (и этот тест делает всё-всё-всё), где-то выделяют smoke и все прочие тесты, иногда разделяют функциональные и нагрузочные тесты, кто-то использует модульные юнит-тесты в сборках, кто-то нет, а кто-то пытается встроить все виды тестов прямо в сборку компоненты или инсталлятора продукта.

Чтобы решить проблему зоопарка тестовых технологий, необходимо собрать в единый комплекс, обобщить и структурировать имеющиеся знания и наработки в области тестирования в различных QA-отделах компании. Для этого нужно привлекать инженеров тестировщиков к выработке общих решений и подходов, совместно развивать общие технологии, инструменты и методики тестирования, распространять лучшие практики тестирования. Вы можете начать с того, что создадите в корпоративной базе знаний (у нас это Confluence) раздел, посвященный тестированию и общим процессам тестирования.

Для понимания масштаба проблем поможет первичный аудит состояния процесса тестирования в компании. Каждому руководителю QA-отдела  можно задать определённый набор вопросов и собрать их ответы в сводную таблицу. Вопросы могут быть такими:

1. Что тестируют: какой компонент или инсталлятор продукта тестируется?
2. Виды тестирования: какие виды тестов используются для тестирования (ручные, BVT, smoke, функциональные и прочие)?
3. Где хранят тесты: в каком виде и где хранятся тесты (текстовое описание на вики или может в excel, код в GitLab или в системе TestRail)?
4. Фреймворки: в каких программах или фреймворках создаются тест-кейсы (блокнот, py.test, Robot Framework, Selenium или что-то своё)?
5. Отчётность о результатах: в каком виде и где хранятся результаты тест-ранов (логи в CI-системах, текстовые отчёты или системы отчётности TestRail и ReportPortal)?
6. Способ деплоя: каким образом тестировщики подготавливают приложение (инсталлятор или компоненту) к тестированию, как деплоят на тестовый стенд, вручную или автоматически, при помощи каких систем и какие используя технологии?
7. Текущий процесс тестирования: короткое описание процесса тестирования продукта.

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

1. Как сейчас устроен ваш процесс тестирования (ваш "тестовый конвейер")? Можете описать общими словами:
   1.1) Что вы тестируете? Принцип взятия артефакта сборки (инсталлятора или компоненты) или сервиса в тестирование. Когда вы начинаете тестировать?
   1.2) Что, как и откуда берётся для тестирования? Как это деплоится на тестовые стенды? 
   1.3) Как организована структура ваших тестов: ручных и автоматических? Какие типы тестов вы используете (bvt, smoke, functional, integration etc)?
   1.4) Критерии тестирования. Что на входе тестов, что на выходе тестов?
   1.5) Как вы принимаете решение об окончании тестирования? Какие критерии тестирования приводят к "бану" тестируемого артефакта или сервиса?
   1.6) Есть ли у вас механизмы "продвижения" сборок: из "мусорных" репозиториев в релизные? Есть ли механизмы простановок "меток качества" для сборок, успешно прошедших тесты?
   1.7) В каких случаях вы или команда разработки игнорируете результаты тестирования и разрешаете использовать "плохие" артефакты в релизе?
   1.8) Как вы ведёте отчётность по результатам тестирования? Кому предоставляете эти отчёты?
   1.9) Есть ли этап анализа результатов тестирования? Если да, то как и какие принимаются решения по итогам анализа?
2. Какие есть проблемы в организации текущего процесса тестирования? 
3. Каким вы видите идеальный процесс тестирования в вашем продукте? 
4. Какие сервисы и инструменты для тестирования вы используете? 
5. Какие есть проблемы с использованием ваших обычных сервисов и инструментов? 
6. Чего вам не хватает сейчас из инструментов, технологий или сервисов для тестирования?
7. Какие инструменты или сервисы вы бы хотели установить, развернуть, попробовать в эксплуатации, если бы была такая возможность?

Собрав информацию от различных QA-команд, вы увидите, где есть пересечения и используются общие технологии, процессы и требуется одинаковый набор инструментов, а где есть различия. Общие технологии и инструменты можно использовать как ядро будущей единой системы тестирования. После этого можно спланировать работы для постепенной интеграции QA-команд в общий процесс тестирования. Параллельно с этим в компании следует наращивать централизованные компетенции в области тестирования.

Этап тестирования в общем сборочном конвейере

В предыдущей статье "Моделирование производственных процессов в ИТ-компании" я рассмотрел общие этапы разработки ПО и модели производственных процессов. В том числе, в статье было введено понятие технологической карты производственного процесса. На технологической карте дают описание общих этапов и шагов, присутствующих в продуктовом сборочном конвейере. Как правило, процессы разработки ПО у всех примерно одинаковые, в том числе и этап тестирования.

На этапе тестирования приложений рекомендуется следующая последовательность шагов (здесь и далее под приложением будем понимать тестируемые компоненты или инсталлятор некоторого продукта, обладающие определённой функциональностью):

1. Во время сборки приложения следует запускать только юнит-тесты (Unit-Testing). В этих небольших модульных тестах должны тестироваться методы и классы основных функций приложения. Возможна частичная замена или дополнение юнит-тестов статическим анализом и ревью кода (например, Upsource, SonarQube etc).
2. После сборки и деплоя приложения на тестовом стенде можно выполнить его ручное тестирование (Manual Testing) по чек-листу для проверки основной функциональности. Этот вид тестирования может выполняться отдельно и независимо от процесса автотестирования.
3. После сборки и деплоя приложения на тестовом стенде можно запустить так называемые BVT-тесты (Build Verification Testing). В этих автоматических тестах проверяется корректность самой сборки: наличие всех необходимых файлов и конфигураций для работы приложения.
4. Если BVT-тестирование завершилось успешно, далее можно запустить так называемые "дымовые" тесты (Smoke Testing) для проверки базовой функциональности приложения. Как правило, это достаточно быстрые функциональные тесты, не требующие серьёзных временных затрат и железных ресурсов. В качестве smoke-тестов должны использоваться проверки только тех функций, без корректной работоспособности которых дальнейшая эксплуатация и тестирование приложения становятся бессмысленными.
5. В случае успешного завершения smoke-тестов далее можно параллельно и независимо друг от друга запустить все остальные виды тестов:

• функциональные тесты, подробно тестирующие каждую бизнес-функциональность приложения (Functional Testing), к ним также можно отнести наборы приёмочных тестов (Acceptance Testing), согласованные с заказчиками приложения, и предварительные исследовательские тесты (Exploratory Testing);
• нагрузочные тесты, определяющие способность приложения работать при повышенной нагрузке или постепенном росте до пиковых нагрузок (Stress testing, Load Testing);
• интеграционные тесты, проверяющие совместную работоспособность отдельных компонентов приложения и их соответствие требуемой бизнес-логике (Integrity Testing);
• тесты доставки обновлений, которые проверяют всю цепочку поставки продукта или его компонентов до серверов обновлений (Delivery Testing).

Рис. 1. Место тестов в общем сборочном конвейере

Рекомендуемая схема интеграции тестов в общий процесс разработки изображена на рис. 1. По окончании каждого вида тестов должен быть сформирован отчёт с результатами и выводами. Отчёт может быть предоставлен в виде:

• обычных консольных логов, которые также можно отправить в единую систему сбора логов, например, в Graylog, или хранить в CI-системах GitLab CI или TeamCity как обычные билд-логи;
• автоматической выгрузки результатов тестирования в систему отчётности TestRail или ReportPortal;
• интегрированного отчёта от фреймворка py.tests на отдельной вкладке в CI-системе TeamCity;
• отчёта Allure Report, который возможно настроить для многих фреймворков;
• выгрузки в базу данных для дальнейшего анализа, например, в InfluxDB + Grafana;
• для ручных тестов допускаются письменные отчёты, например, сохранённые в Excel-файле, в трекерах (TFS, YouTrack, Jira etc), в Confluence или экспортированные в систему отчётности TestRail.

Про тестовые инструменты, фреймворки и системы отчётности, вы можете почитать на сайте software-testing.ru, а общие определения тестирования можно найти на сайте www.protesting.ru. Смотрите также:

• Методология тестирования ISTQB.
• PlantUML — инструмент для быстрого проектирования, рисования схем и диаграмм.
• Использование TeamCity в качестве системы управления запуском функциональных авто-тестов.
• TeamCity triggers & dependencies: построение процессов разработки и тестирования.
• TeamCity TestRuns on Rails: распараллеливаем тест-раны и агрегируем статистику.

Общие технические характеристики тестов

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

Unit-Testing

Под "модульными тестами" (или юнит-тестами, unit tests, см. рис. 2) будем понимать автотесты, которые запускаются во время сборки и тестируют только методы и классы с основными функциями приложения. Возможна частичная замена или дополнение юнит-тестов статическим анализом и ревью кода, например, с помощью инструментов Upsource и SonarQube.

Рис. 2. Место юнит-тестов в общем сборочном конвейере

Характеристики тестов:

1. Требования к тестированию: юнит-тесты запускаются во время сборки тестируемого приложения (до публикации артефакта сборки, компоненты или инсталлятора продукта, в хранилище Artifactory).
2. Что на входе: код приложения.
3. Что на выходе: список прошедших и зафейлившихся (PASSED/FAILED) юнит-тестов. Code Coverage.
4. Тестовые отчёты: в процессе сборки продукта и юнит-тестирования подготавливается отчёт в виде простого списка PASSED/FAILED. Отчёты могут быть сохранены в консольных логах CI-систем (TeamCity, GitLab CI) или интегрированы в них (через py.test integration, Allure Report etc).
5. Что происходит после тестирования: если юнит-тесты не проходят, то вся сборка фейлится, артефакт не выкладывается в хранилище Artifactory.

Manual Testing

Под "ручным тестированием" (см. рис. 3) будем понимать процессы установки и настройки объекта тестирования, выполняемые вручную, а также пошаговые, неавтоматизированные тестовые проверки. Как правило, они записаны в виде инструкций для человека — так называемый чек-лист (check list).

Рис. 3. Место ручных тестов в общем сборочном конвейере

Характеристики тестов:

• Требования к тестированию: приложение успешно собрано, в том числе прошли все юнит-тесты, и задеплоено на тестовый стенд.
• Что на входе: план тестирования с описанием тестовых сценариев, которые необходимо пройти вручную, и само тестируемое приложение.
• Что на выходе: список прошедших и зафейлившихся (PASSED/FAILED) тестов.
• Тестовые отчёты: отчёт по результатам ручного тестирования и выводы могут быть предоставлены в письменном виде (Excel, Word, почта etc), сохранены в трекеры (TFS, YouTrack, Jira etc), сохранены в TestRail или ReportPortal.
• Что происходит после тестирования: можно добавить "метку качества" в свойства артефакта, которое будет показывать общий статус тестирования. Например, qa.manual=TRUE|FALSE.

Build Verification Testing

Под "build verification тестами" (BVT, см. рис. 4) будем понимать автотесты, которые проверяют корректность самой сборки: присутствуют все файлы и компоненты, необходимые для работы приложения, в наличии все файлы документации, имеется локализация под требуемые языки, присутствуют необходимые файлы с преднастроенными конфигурациями, например, для инициализации баз данных и самого приложения.

Рис. 4. Место BVT-тестов в общем сборочном конвейере

Характеристики тестов:

• Требования к тестированию: приложение успешно собрано, в том числе прошли все юнит-тесты, и задеплоено на тестовый стенд.
• Что на входе: код автотестов, тестируемое приложение.
• Что на выходе: список прошедших и зафейлившихся (PASSED/FAILED) тестов.
• Тестовые отчёты: отчёт по результатам BVT тестирования и выводы могут быть сохранены в консольных логах CI-систем (TeamCity, GitLab CI etc), экспортированы в трекеры (TFS, YouTrack, Jira etc), интегрированы в отчёты CI-систем (если у них есть интеграция с py.test, Allure Report etc), экспортированы в TestRail или ReportPortal.
• Что происходит после тестирования: можно добавить "метку качества" в свойства артефакта, которое будет показывать общий статус тестирования. Например, qa.bvt=TRUE|FALSE.

Smoke Testing

Под "smoke тестами" (см. рис. 5) будем понимать автотесты, которые способны достаточно быстро проверить основную, базовую функциональность приложения. Как правило, такие автотесты ограничены в количестве и по времени прохождения, а также в них используются проверки только тех функций, без корректной работоспособности которых дальнейшая эксплуатация и тестирование приложения становятся бессмысленными.

Рис. 5. Место smoke-тестов в общем сборочном конвейере

Характеристики тестов:

• Требования к тестированию: приложение успешно собрано, в том числе прошли все юнит-тесты, и задеплоено на тестовый стенд. Успешно завершились автоматические BVT тесты.
• Что на входе: код автотестов, тестируемое приложение.
• Что на выходе: список прошедших и зафейлившихся (PASSED/FAILED) тестов.
• Тестовые отчёты: отчёт по результатам smoke-тестирования и выводы могут быть сохранены в консольных логах CI-систем (TeamCity, GitLab CI etc), экспортированы в трекеры (TFS, YouTrack, Jira etc), интегрированы в отчёты CI-систем (если у них есть интеграция с py.test, Allure Report etc), экспортированы в TestRail или ReportPortal.
• Что происходит после тестирования: можно добавить "метку качества" в свойства артефакта, которое будет показывать общий статус тестирования. Например, qa.smoke=TRUE|FALSE.

Functional Testing

Под "функциональными тестами" (см. рис. 6) будем понимать автотесты, которые полностью проверяют бизнес-логику работы приложения.

Рис. 6. Место функциональных тестов в общем сборочном конвейере

Характеристики тестов:

• Требования к тестированию: приложение успешно собрано, в том числе прошли все юнит-тесты, и задеплоено на тестовый стенд. Успешно завершились автоматические BVT и smoke тесты.
• Что на входе: код автотестов, тестируемое приложение.
• Что на выходе: список прошедших и зафейлившихся (PASSED/FAILED) тестов.
• Тестовые отчёты: отчёт по результатам функционального тестирования и выводы могут быть сохранены в консольных логах CI-систем (TeamCity, GitLab CI etc), экспортированы в трекеры (TFS, YouTrack, Jira etc), интегрированы в отчёты CI-систем (если у них есть интеграция с py.test, Allure Report etc), экспортированы в TestRail или ReportPortal.
• Что происходит после тестирования: можно добавить "метку качества" в свойства артефакта, которое будет показывать общий статус тестирования. Например, qa.functional=TRUE|FALSE.

Load Testing

Под "нагрузочными тестами" (см. рис. 7) будем понимать автотесты, которые позволяют проверить и оценить работу приложения под нагрузкой и определить момент, когда произойдёт отказ в обслуживании (DoS), а также выяснить, как ведёт себя приложение при работе с постоянной или пиковой нагрузкой.

Рис. 7. Место нагрузочных тестов в общем сборочном конвейере

Характеристики тестов:

• Требования к тестированию: приложение успешно собрано, в том числе прошли все юнит-тесты, и задеплоено на тестовый стенд. Успешно завершились автоматические BVT и smoke тесты.
• Что на входе: код автотестов, тестируемое приложение, инструмент для проведения нагрузки: ab (Apache Bench), Apache JMeter, Яндекс.Танк etc. По методологии ISTQB (п. 4.2.4) подготавливают "профили нагрузки": определяют критичные для конкретного теста метрики и варианты изменения нагрузки в течение теста.
• Что на выходе: значения различных метрик (ISTQB, стр. 36). Далее по методологии ISTQB (стр. 52) анализируются показатели: количество и статус симулированных виртуальных пользователей, время одной транзакции (запрос-ответ), количество транзакций в секунду, количество фейлов транзакций, пропускная способность сети, количество и статус HTTP запросов и ответов. Список метрик может быть расширен в зависимости от требований к работе приложения.
• Тестовые отчёты: отчёт по результатам нагрузочного тестирования и выводы могут быть сохранены в консольных логах CI-систем (TeamCity, GitLab CI), сохранены в виде текстовых Word или Excel отчётов, интегрированы в отчёты CI-систем (например, html-отчёт от Apache JMeter легко интегрировать с TeamCity — у тестрана его можно отобразить на отдельной вкладке), также можно выгрузить результаты во внешнюю базу данных (например, отчёт Яндекс.Танка можно автоматически сохранять в InfluxDB и отображать в Grafana).
• Что происходит после тестирования: можно добавить "метку качества" в свойства артефакта, которое будет показывать общий статус тестирования. Например, qa.loadtest=TRUE|FALSE.

Integrity Testing

Под "интеграционными тестами" (см. рис. 8) будем понимать автотесты, которые проверяют совместную работоспособность отдельных компонентов приложения и их соответствие требуемой бизнес-логике. Обычно такие тесты запускаются после интеграционной (полной) сборки приложения, включающей в себя все её составные компоненты.

Рис. 8. Место интеграционных тестов в общем сборочном конвейере

Характеристики тестов:

• Требования к тестированию: приложение успешно собрано, в том числе прошли все юнит-тесты, и задеплоено на тестовый стенд. Успешно завершились автоматические BVT и smoke тесты.
• Что на входе: "Отдельные компоненты системы, работу которых нужно проверить во взаимосвязи. Или компонента, работу которой нужно проверить после интеграции в саму систему", — цитата взята с сайта www.protesting.ru. Также на входе должен быть код самих автотестов.
• Что на выходе: список прошедших и зафейлившихся (PASSED/FAILED) тестов.
• Тестовые отчёты: отчёт по результатам интеграционного тестирования и выводы могут быть сохранены в консольных логах CI-систем (TeamCity, GitLab CI etc), экспортированы в трекеры (TFS, YouTrack, Jira etc), интегрированы в отчёты CI-систем (если у них есть интеграция с py.test, Allure Report etc), экспортированы в TestRail или ReportPortal.
• Что происходит после тестирования: можно добавить "метку качества" в свойства артефакта, которое будет показывать общий статус тестирования. Например, qa.integrity=TRUE|FALSE.

Delivery Testing

Под "тестами доставки обновлений" (см. рис. 9) будем понимать автотесты, которые проверяют работоспособность всей цепочки: сборка компонентов, инсталляторов или выпущенных лицензий и сертификатов — их публикация на корпоративных серверах обновлений — получение опубликованных артефактов на инфраструктуре заказчика — проверка лицензий или сертификатов — обновление компонентов и инсталляторов на стороне заказчика.

Рис. 9. Место ручных тестов в общем сборочном конвейере

Характеристики тестов:

• Требования к тестированию: приложение успешно собрано, в том числе прошли все юнит-тесты, и задеплоено на внешний по отношению к инфраструктуре разработки тестовый стенд, так как будет имитироваться ситуация выполнения обновлений и проверки лицензий на стороне заказчика. Успешно завершились автоматические BVT и smoke тесты.
• Что на входе: код автотестов, тестируемое приложение.
• Что на выходе: список прошедших и зафейлившихся (PASSED/FAILED) тестов.
• Тестовые отчёты: отчёт по результатам тестирования доставки обновлений и выводы могут быть сохранены в консольных логах CI-систем (TeamCity, GitLab CI etc), экспортированы в трекеры (TFS, YouTrack, Jira etc), интегрированы в отчёты CI-систем (если у них есть интеграция с py.test, Allure Report etc), экспортированы в TestRail или ReportPortal.
• Что происходит после тестирования: можно добавить "метку качества" в свойства артефакта, которое будет показывать общий статус тестирования. Например, qa.delivery=TRUE|FALSE.

В заключение

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

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