Quality Gate для автоматизации QA
Понятие Quality Gate (дословно ворота качества), предполагает автоматические проверки качества, которые устанавливают пороговые значения для продвижения продукта по конвейеру разработки CI/CD.
Использование принципа Quality Gates помогает решать проблемы в коде на ранних этапах, до того, как он обрастёт зависимостями. Так, в частности выявив ошибки в коде на начальных этапах разработки мы потратим меньше времени на тестирование исправленного варианта кода, что в конечном итоге позволит снизить общие расходы на разработку.
Quality Gate также можно назвать контрольными точками качества, и именно это понятие мы и будем дальше использовать.
Итак, контрольные точки качества — это промежуточные этапы цикла реализации проекта. И хотя, контрольные точки качества необходимы для создания высококачественного программного обеспечения, многие специалисты не совсем правильно понимают принципы работы данного механизма проверки кода. Давайте попробуем разобраться, что из себя представляют контрольные точки качества и чем они могут помочь QA при тестировании качества кода.
Прежде всего, контроль качества — это любая проверка, которая может остановить поставку продукта, если она не пройдена.
Виды контрольных точек
Начнем с самого простого — предупреждений или ошибок IDE. Современные средства разработки позволяют анализировать исходный код непосредственно в процессе написания. Так, IDE выявляет синтаксические ошибки, без которых код в принципе неработоспособен. По сути это тоже контроль качества.
Аналогично и при запуске кода в интерпретаторе мы можем получить различные сообщения об ошибках и предупреждения.
Если проверки на этапе IDE являются в некоторой степени очевидными контрольными точками, то следующие проверки уже будут несколько менее очевидными.
Начнем с «кода с душком» (code smell). Не слишком аккуратный стиль написания кода сразу не приведет к ошибкам. Поначалу код будет вполне рабочий. Но затем, по мере того, как мы будем пытаться вносить изменения в криво написанную программу, нам будет требоваться больше времени на о, чтобы разобраться в ней. В результате есть риск ого, что в какой-то момент мы допустим ошибку в коде, и в программе появится уязвимость.
Поэтому важно при разработке тестов качества уделять внимание «code smell» и аналогичным проверкам стилей написания кода. И именно здесь Quality Gate может помочь остановить сборку некачественно написанного кода.
Далее, еще одной контрольной точкой являются регулярные ревью кода. Всегда полезно, чтобы пара опытных глаз (или двое) изучали ваш код — по крайней мере, это гарантирует, что знания о коде будут распространены по всей команде, так что один разработчик не станет узким местом.
Сборка, это в некотором смысле еще один показатель качества — если сборка завершается неудачно, весь процесс останавливается.
И, конечно же, тесты. Модульные тесты, интеграционные тесты, промежуточные и ручные тесты.
Многие из этих проверок страдают от присущей им проблемы человеческого фактора — люди слишком умны. Разработчик, тестировщик, менеджер — у каждого свой взгляд на систему. Если они вообще думают о QA, у них разные подходы. Например, когда разработчик пишет потрясающее решение проблемы, написание модульных тестов — это рутинная работа; обычно они просто подтверждают, что потрясающее решение работает, тестируя счастливый путь. Они могут игнорировать желтые предупреждения из IDE, потому что, откровенно говоря, у них по горло забот с красными.
Тестировщики — основа контроля качества, но они допускают ошибки. Например, они могут отключить тест с ошибками, а затем забыть о нем, не осознавая, что тест стал постоянно красным.
Роботы против людей
А вот у автоматизации есть важное преимущество перед людьми: она немая. Что означает надежность и прозрачность. Автоматизация никогда полностью не заменит людей, и ручные тестировщики никуда не денутся. Но автоматизированные тесты обеспечивают проверки, которые не зависят от нашей лени, недостатка концентрации внимания или того, что наш мозг занят более насущными проблемами. Автоматизированные тесты с использованием Quality Gate являются одними из самых эффективных.
Совершенно логичным решением является интеграция проверок контроля качества в конвейер CI/CD. Так, размещая автоматизированные тесты в конвейерах сборки и развертывания, вы получаете автоматизированные контрольные точки качества, которые обеспечивают быструю и непрерывную обратную связь. Вы можете указать, завершается ли развертывание неудачно, если оно не проходит все контрольные точки качества или только одну из них, в зависимости от того, насколько строгими вы хотите быть с вашими конвейерами.
Благодаря автоматизированному характеру тестов, после успешного запуска конвейера вы будете уверены, что некоторые из ваших проблем были устранены без ручного отслеживания прогресса. Это более эффективно, чем ручные проверки качества, и экономит массу времени. Вы можете добавлять множество шлюзов во многие конвейеры, пока не автоматизируете почти 100% жизненного цикла тестирования.
Автоматизация в конечном итоге окупается, но требует работы. Не зацикливайтесь на автоматизации отдельных частей вашего рабочего процесса; отдача от ваших усилий возрастает, как только вы интегрируете эти части. Запуск вашего автоматизированного набора тестов при каждом запросе на извлечение — один из таких примеров.
На просторах Интернета можно найти массу публикаций в которых предлагается использовать различные готовые решения для реализации Quality Gate в конвейере. Однако, одна из основных проблем использования этих решений заключается в том, что многие из иностранных вендоров, например Atlassian, ушли из России и использовать их решения будет не так просто.
В качестве альтернативного варианта я предлагаю использовать собственные скрипты для разбора результатов тестов и проведения контроля качества. В качестве примера посмотрим работу с Pytest.
Quality Gate на Python
Прежде всего вам потребуется установить pytest с помощью команды
pip install pytest
Далее естественно потребуется написать свои тестовые примеры. Тестовый пример определяется как функция Python, которая начинается с test_ или заканчивается на _test. Например:
def test_subtraction():
assert 5 - 3 == 2Запустите тесты с помощью pytest. При этом будут выполнены все тестовые примеры, присутствующие в файле.
Далее необходимо сгенерировать отчет о тестировании. По умолчанию pytest генерирует краткий отчет о тестировании в терминале. Однако вы можете сгенерировать более подробный отчет в различных форматах, таких как HTML, JUnit XML или обычный текст. Чтобы сгенерировать отчет в формате XML, например, вы можете запустить команду pytest --xml=report.xml. В результате будет сгенерирован файл, содержащий подробный отчет о тестировании.
Pytest возвращает следующие метки состояния:
PASSED: Эта метка состояния указывает на то, что тест выполнен успешно и ожидаемый результат соответствует фактическому результату.
FAILED: Эта метка состояния указывает на то, что тест завершился неудачей, что означает, что ожидаемый результат не соответствует фактическому результату.
SKIPPED: Эта метка состояния указывает на то, что тест был пропущен либо намеренно, либо из-за какого-либо условия в коде.
XFAILED: Эта метка состояния указывает на то, что тест завершился неудачей, но сбой был ожидаемым. Это можно использовать для пометки тестов, которые, как известно, завершились неудачей из-за ошибки или неподдерживаемой функции.
XPASSED: Эта метка состояния указывает на то, что тест пройден, но результат прохождения был ожидаемым. Это можно использовать для пометки тестов, которые, как известно, прошли из-за ошибки или неподдерживаемой функции.
ERROR: Эта метка состояния указывает на то, что во время выполнения теста произошла ошибка, которая отличается от сбоя. Это могут быть исключения, тайм-ауты или любая другая непредвиденная проблема.
CAPTURE: Эта метка состояния указывает на то, что во время выполнения теста был произведен некоторый захват выходных данных. Это может быть использовано для указания на то, что тест выдал какие-либо выходные данные, такие как инструкции печати или сообщения журнала.
CREATED: Эта метка состояния указывает на то, что тестовый набор был создан, но еще не был выполнен.
UNKNOWN: Эта метка состояния указывает на то, что статус теста неизвестен. Это можно использовать для пометки тестов, которые не были выполнены, или если есть какие-либо проблемы со сбором или выполнением тестов.
Таким образом, мы можем парсить результаты тестов и в зависимости от необходимых пороговых значений для контрольных точек принимать решение о том, допускать ли код на следующий этап или нужна доработка.
Заключение
Наличие автоматизированных тестов в качестве контроля качества не означает, что вам нужно избавиться от всех ваших ручных тестов. Но вы можете автоматически запускать ручные тесты и полагаться на автоматические тесты, которые дадут добро, если все в порядке. Автоматизированные тесты не требуют проведения совещаний и прохождения контрольных списков вручную. Другими словами, это автоматизированные ворота качества.
Больше про автоматизацию тестирования и практические инструменты для тестировщиков, вы можете узнать в рамках онлайн-курсов от моих коллег из OTUS. Подробнее в каталоге.
