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

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

Актуальные проблемы организации процесса тестирования

При организации правильного процесса тестирования внутри большой компании, обычно сталкиваются с такими проблемами:

• В фирме нет единого центра компетенции тестирования, приветствуется практика использования случайного инструментария, нет документированного описания актуальных процессов тестирования;
• Не практикуются шаблонные методики и техники тестирования, которым следовали бы все инженеры качества. Зачастую, все продуктовые отделы и отделы тестирования используют свои личные технологии и практики проверок: программисты могут хранить все на GitLab, а тестировщики в популярных трекерах – Jira, YouTrack and TFS;
• Разнообразие проверочных фреймворков под популярные языки программирования или свои персональные наработки;
• Случайные типы отчетности по тестам: кто-то рад выводу в консоли CI-системы GitLab CI, а кто-то ратует за сохранение всех test-runs в build log на TeamCity;
• Разнообразные способы проверочных компонентов и инсталляторов на тестовые стенды: можно все устанавливать вручную, а можно использовать универсальные метараннеры в TeamCity или в GitLab CI;
• Оригинальные виды тестов: на одном проекте используется один большой mega test, с последующей интеграцией в тестовый фреймворк, а на другом происходит выделение дымовых тестов в отдельную группу проверок (с возможным дроблением на нагрузочные и функциональные тесты).

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

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

Создание базы знаний QA внутри компании

Итак, чтобы понимать масштаб предстоящих работ, можно начать с первичного аудита методики тестирования внутри определенной компании. Например, если в фирме трудится 2-3 инженера контроля качества, у каждого из которых есть новички в обучении, им (QA-руководителям) можно составить перечень вопросов, ответы которых будут поступать в сводную таблицу.

Вопросами могут быть:

• Что проверяется: какие части ПО или инсталлятор в данный момент в стадии тестов?
• Типы используемого тестирования;
• Как сохраняются тесты?
• Использует ли команда фреймворки?
• Каким образом структурируется отчетность тестовых результатов?
• Виды развёртывания: как тестировщики готовят приложение к процессу проверки?
• Нынешний процесс тестирования: краткое описание вида тестирования ПО.

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

Какими должны быть этапы тестирования ПО в шаблонной форме?

На стадии тестирования программного обеспечения настоятельно рекомендуется придерживаться общей философии последовательности выполняемых действий.

Если более детально, всё сводится к таким шагам:

1. При сборке ПО, следует запускать исключительно модульные тесты. В подобных малых модульных проверках можно тестировать методы и классы базовых функций программного обеспечения. Допускается частичная смена модульных тестов на проверку кода или дополнение новыми проверками;
2. После того как выполнены развёртывание и сборка ПО внутри тестовой среды, можно начать выполнение ручного тестирования. Для этих целей используется заранее составленный чек-лист, внутри которого описана вся функциональность ПО. Данный процесс может выполняться отдельно от автоматизации;
3. Параллельно с ручными тестами можно запустить BVT-тесты. Эти автотесты помогут проверить текущую корректность сборки: присутствуют ли в структуре ПО все нужные файлы и конфигурации для работы ПО;
4. После завершения тестирования сборки, запускаются дымовые тесты для эффективной проверки корректности функционирования архитектуры программного обеспечения. Зачастую, это очень быстрый прогон тестов, которые не сопряжены с большими денежными и временными затратами;
5. Удачное завершение дымового тестирования дает «зеленый» сигнал для размеренного выполнения всех последующих типов проверок: начиная от функциональных тестов, и заканчивая тестами интеграции и проверками обновлений.
   

   Правильная интеграция процесса тестирования ПО

1 вид тестов – 1 вид отчета

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

На практике можно воспользоваться следующей структурой:

• Консольные логи;
• Выгрузка итогов тестирования в платформу отчетности (например, в ReportPortal and TestRail);
• Отчет в Allure Report, который в будущем можно выгрузить для интерфейса любого аналитического фреймворка;
• Выгрузка в корпоративную базу данных, например в Grafana / InfluxDB;
• Письменные отчеты в известном любому инженеру Excel-файле.

Классические характеристики корректно структурированных тестов

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

Все ниже описанное можно смело брать за шаблон требований к процессу тестирования ПО.

Модульные тесты

Модульные тесты – это автоматические тесты, которые стартуют во время начала сборки ПО и проверяют исключительно методы и классы, совместимые с параметрами продукта.

Особенности модульных тестов:

1. Выполняются во время сборки проверяемого продукта;
2. Анализируют программный код продукта;
3. По итогу выполнения проверок формируется список удачных и неудачных тестов;
4. Генерация тестовых отчетов с последующим сохранением в логах или интегрированных системах учета данных.

Ручные тесты

Под ручными проверками понимаются процессы инсталляции и оптимизации объекта тестирования, выполняемые вручную, а также пошаговые, тестовые проверки. Традиционно, они формируются в виде интуитивно понятных инструкций для пользователя – другими словами, в форме классического чек-листа.

Особенности ручных  тестов:

• Модульные тесты прошли успешно и тестовая среда удачно развернута на виртуальный тестовый стенд;
• Пошаговый план тестирования с детализированным описанием всех тестовых сценариев, которые необходимо выполнить тестировщику;
• Перечень успешных и заваленных тестов;
• Генерация тестовых отчетов: могут предоставляться как в ручном виде, так и в форме виртуальной интеграции на используемые трекеры.

Тестирование сборки

Это своего рода автотесты, цель которых – проверка корректности функционирования тестовой сборки: все ли файлы и компоненты содержаться в архитектуре ПО, есть ли локализация под актуальные языки, присутствуют ли файлы с предварительно настроенными параметрами и так далее.

Особенности тестов:

• Код автотестов;
• Перечень успешных и неудачных проверок;
• Возможность формирования отчетов тестирования в консольных логах, с интеграцией в отчеты CI-систем, экспорт в TestRail или ReportPortal.

Дымовое тестирование

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

Особенности тестов:

• Приложение уже прогнано на модульные есты, всё перешло на виртуальный тестовый стенд. Группа используемых тестов сборки успешно выполнена;
• Перечень успешных и неудачных проверок;
• Возможность формирования отчетов тестирования в консольных логах, с интеграцией в отчеты CI-систем, экспорт в TestRail или ReportPortal.

Функциональные тесты

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

Особенности тестов:

• Приложение уже прогнано на модульные тесты, все перешло на виртуальный тестовый стенд. Группа используемых тестов сборки успешно выполнена. Сформирован отчет по всем пунктам проведенного дымового тестирования;
• Перечень успешных и неудачных проверок;
• Возможность формирования отчетов тестирования в консольных логах, с интеграцией в отчеты CI-систем, экспорт в TestRail или ReportPortal.

Нагрузочные тесты

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

Особенности тестов:

• ПО уже прогнано на модульные тесты, всё перешло на виртуальный тестовый стенд. Группа используемых тестов сборки успешно выполнена. Сформирован отчет по всем пунктам проведенного дымового тестирования. Выполнена проверка по всем ранее утвержденным функциональным тестам;
• Перечень успешных и неудачных проверок;
• Возможность формирования отчетов тестирования в консольных логах, с интеграцией в отчеты CI-систем, экспорт в TestRail или ReportPortal.

Вместо вывода

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

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