Привет, Хабр! С вами Ксения Бычкова и Ольга Султанова из отдела тестирования Рунити. В этой статье расскажем про пирамиду тестирования и как мы внедряли эту best practice в нашей компании.
Навигация по тексту:
Как пирамида тестирования влияет на процессы
Пирамида тестирования — это процесс визуализации покрытия, который помогает группировать тесты по типам их назначения. Почему именно процесс? Потому что это непрерывное действие, которое внедряется и поддерживается непосредственно всей командой: как разработчиками, так и тестировщиками.
Внедрение пирамиды тестирования даст полное покрытие и поможет избежать дублирования тестов. Что, в свою очередь, позволит понять, на каком уровне вы пишете тесты. Это важно особенно тогда, когда в проекте много E2E- или мануальных тестов. Обычно бывает так: разработчики торопятся, бизнес подгоняет. Но когда тестировщики стараются покрыть все автотестами, в какой-то момент их становится очень много — до нескольких десятков тысяч. Написание такого количества тестов отнимает много времени, а главное — требуется потом всё это поддерживать. Но мы все хотим прийти к варианту, когда E2E станет как можно меньше, а интеграционных и unit-тестов — больше. В этом нам и помогает внедрение пирамиды тестирования.
Какие тесты используются у нас в компании
У нас в компании Рунити почти в каждую задачу заложено время для написания тестов, которые гарантируют, что функциональность работает корректно согласно требованиям. Ниже приведены примеры, какие тесты мы используем на практике.
Unit-тесты — применяются для тестирования одной логической выделенной единицы, изолированной. Обычно это класс или функция. И чтобы не было интеграций, взаимодействий, то обычно используются заглушки (Stubs) и моки (Mocks) для написания таких тестов. Эти тесты пишутся в основном разработчиками, но иногда их могут писать и тестировщики.
Интеграционные тесты — это тесты, которые тестируют связку нескольких модульных компонентов. И система здесь воспринимается как черный ящик, где есть несколько модулей со связками. Чтобы была возможность протестировать эти связки, то также используются заглушки и моки для тестирования.
API-тесты — эти тесты выполняются путем отправки запроса к эндпоинту и сравнения ответа с ожидаемым результатом. Тестирование производится с помощью специальных инструментов Postman/Swagger. В рамках написания таких тестов необходим поднятый backend и доступ в базу данных.
E2E-тесты — это тесты, которые полностью имитируют поведение пользователя системы. Мы пишем скрипты для того, чтобы полноценно, как пользователь, проходить пути сценариев. Эти тесты чаще всего пишутся тестировщиками. Здесь необходимо, чтобы было полностью поднято приложение. Такие тесты самые хрупкие и долгие, так как они зависят от изменений, скорости работы приложения и других нюансов, а также требуют больше времени на их поддержку.
VR-тесты — чаще всего эти тесты проверяют пользовательский интерфейс, точнее его визуальную часть. Эти тесты легко внедрить, для этого делается снимок нужного нам экрана, который мы считаем эталонным. В тестах при каждом новом запуске, создаем новый снимок. Потом делается сравнение с эталонным вариантом.
Как мы пришли к пирамиде тестирования
Думаю, многие компании в определенный момент своего развития приходят к тому, что автоматические тесты нужны и полезны, и не стоит пренебрегать их написанием. Да, очевидно, бизнес хочет, чтобы все критически важные пути были покрыты именно E2E-тестами и мы не стали исключением. Покрывали стабильный и важный функционал, сокращали время регрессионных тестов. Но в какой-то момент, когда количество тестов слишком увеличилось, и их поддержка стала отнимать много времени, стало понятно, что нужно остановиться и понять, что мы можем сделать, чтобы писать меньше E2E-тестов.
Первое, что мы сделали — постарались избавиться от всех ненужных тестов: тех, что покрывают негативные сценарии проверки, валидации, права. Эти проверки однозначно можно проверять на более низких уровнях. Договорились с разработчиками и заменили E2E либо юнитами, либо API-тестами. Это позволило нам оптимизировать тесты и распределить проверки между нижними уровнями пирамиды. Естественно, мы хотели сохранить качество тестирования, поэтому все договоренности были зафиксированы с командами, и всё было отмечено в нашей TMS (подробнее про TMS мы ранее рассказывали в этой статье).
Однако такая единоразовая акция хоть и была полезна, но отняла много времени, как у тестировщиков, так у разработчиков. А постепенно мы снова вернулись к обычному написанию E2E-тестов, не зная, что покрывают разработчики.
Такое положение дел нас не устраивало и постепенно мы стали внедрять пирамиду — сначала нашли несколько команд, в которых разработчики поддерживали этот подход, и с их помощью организовали процесс пирамидинга в этих командах. А далее масштабировали всю компанию: проводили воркшопы, рассказывали о плюсах пирамиды, показывали на примерах. В итоге полностью перестроили процессы и внедрили пирамиду тестирования как непрерывный процесс. Теперь все тесты в обязательном порядке распределяются по уровням.
Процесс работы по пирамиде
Этап 1. Оценка проекта. Когда приходит проект, все тестировщики описывают сценарии тестирования и заносят в нашу TMC. У нас в компании используется Testrail, поэтому все тест-кейсы и сценарии тестирования описываются именно там.
Этап 2. Планирование проекта. Здесь уже происходит общение команды друг с другом — разработчики и тестировщики, а также может подключаться менеджер. На этом этапе вы уже заходите в систему управления тестированием, актуализируете ранее описанные кейсы и распределяете их по уровням покрытия.
Также у нас есть команды, которые состоят только из backend-разработчиков. Соответственно, в таких командах Е2Е тесты не пишутся — пирамида состоит только из API-тестов и юнит-тестов, и по сути становится трапецией.
Если кейсов немного, то работа по первым двум этапам может проводиться в тикете, в котором реализуется фича. В таком случае в тикет добавляется чек-лист с проверками и обсуждаются уровни их покрытия. Потом все кейсы всё равно заносятся в Testrail, чтобы визуализировать наше покрытие.
Этап 3. Написание автотестов разработчиками. Если разработка ведется по TDD, тогда тесты, которые мы обсуждали на планировании, пишутся сразу вместе с кодом. Либо разработчик пишет тесты после реализации функциональности. После ревью задача переходит на следующий этап — этап тестирования.
Этап 4. Тестировщик тестирует и пишет автотесты. В идеальном мире после тестирования тестировщик сразу же пишет на фичу автотесты. Но если ему не хватает времени или квалификации, то ставится отдельная задача и прикрепляется к тикету с фичей. В рамках этой задачи будут написаны тесты на уже реализованный функционал, как только появятся свободные ресурсы.
Этап 5. Финал. Помечаем эти сценарии в нашем ТМС как автоматизированные.
Реальный пример применения пирамиды тестирования
Давайте на примере конкретной задачи разберем, как работает наша пирамида тестирования. В работу берется фича «Разработать новую шторку смены тарифа для OpenStack». Производится вычитка документации, после которой тестировщик накидывает в тикет чек-лист с проверками. На общем созвоне с разработчиками эти проверки распределяются по уровням в этом же тикете.
Далее происходит разработка и тестирование, параллельно с которыми пишутся обозначенные тесты. Тестировщик расписывает проверки из чек-листа в более подробные тест-кейсы и добавляет в TMS. После выполнения всех пунктов из чек-листа тикет уходит в «Готово».
Для удобства регресса и дальнейшей поддержки тестов в TMS мы добавили поле «Automation Type», которое указывает на тип автоматизации.
Вывод
В результате внедрения пирамиды мы обрели большую уверенность в качестве выпускаемого продукта и снизили затраты времени на регресс за счет хорошо построенной автоматизации. Кроме того, убрали дублирование одних и тех же проверок на разных уровнях, сократили количество UI-тестов и уменьшили затраты на их поддержку.
Но не обошлось и без минусов. В первую очередь, это увеличение времени на реализацию из-за того, что теперь в нее включена и работа над тестами. А также приходится верить на слово разработчикам, так как для проверки того, достаточно ли хорошо написаны unit-тесты, нужно обладать компетенциями для понимания происходящего в коде.
Пирамида тестирования — это непрерывный процесс, который помогает структурировать процесс тестирования. Однако для достижения максимальной эффективности важно уметь адаптировать его под специфику проекта. Ведь классическая форма не всегда оптимальна, по факту это может быть и трапеция (как у нас в некоторых проектах без frontend-разработки), и песочные часы (когда по какой-то причине мало интеграционных тестов), и другие альтернативные формы.