Привет! В прошлый раз я рассказал, как устроено тестирование в ЮMoney и какие сервисы помогают нашим тестировщикам в повседневной жизни. Сегодня поговорим про регрессионные тесты.
Регрессионные тесты и минорные задачи
Как вы знаете, тестировщики не только проверяют новую функциональность в задачах — ещё они прогоняют регрессионные тесты. Это позволяет убедиться, что изменения никак не затронули уже работающую функциональность.
На одной из наших встреч с отделом разработки был поднят вопрос о том, что минорные задачи очень долго тестируются.
Задачи без новой функциональности, но с небольшими изменениями в старой называются минорными. Это, например, снижение уровня логирования приложения, поднятие таймаутов в конфигах и другие небольшие изменения.
Анализ статистики подтвердил, что таких задач достаточно много, а скорость их тестирования низкая.
Пример задачи
Как видим, разработчик сделал задачу за полчаса и передал в тестирование. Тестировщик приступил к тестированию только через сутки и выполнил задачу всего за полчаса. За это время он не проверял никакую новую функциональность, а лишь запустил прогон тестов, дождался результатов и перевел задачу в «Проверено».
Причины, почему тестировщик не может оперативно взять задачу, бывают разные. Возможно, приоритет был сфокусирован на других задачах, более важных, а может, тестировщик заболел или взял выходной.
Автоматизация: начало
Чтобы провести регрессионные тесты, тестировщику приходилось в ручном режиме заходить в сервис Pinger (о нём мы говорили в прошлой статье), искать схему, запускать сборку, ждать её успешного деплоя, запускать набор тестов и разбирать результаты.
Мы пришли к выводу, что можем автоматизировать этот процесс, то есть весь ручной запуск тестов, выполняемый тестировщиками. Но для этого нужен был какой-нибудь атрибут, на основе которого мы могли бы понимать, требуется ли автоматизация, и запускать её.
Нам на помощь пришли коллеги из бэкенд-разработки. Они предложили на основании главной задачи, в рамках которой ведётся разработка, автоматически создавать связанную задачу и уже на её основе запускать автоматизацию. Выглядит это следующим образом:
Разработчики сделали джобу в Jenkins, которая создавалась одновременно с тестовым билдом и при запуске проверяла несколько условий:
статус текущей, исходной задачи (чтобы понимать, можно ли запускать тесты или задача ещё в разработке);
заполненность поля Build в задаче (без него мы не сможем установить нужную сборку приложения);
приоритет задачи (чтобы понимать очередность её выполнения и прогона тестов).
В результате этих проверок в Jira создавалась связанная задача RE. На её основе можно прикручивать автоматизацию. За основу мы взяли уже имеющегося бота (Autorun), который используется для приёмочного тестирования (о нём мы рассказывали в этой статье), и научили его запускать не только приёмочные тесты, но и регрессионные.
Теперь Autorun может в автоматическом режиме выполнять следующие действия:
опрашивать Jira на наличие RE-задач в открытом статусе;
находить свободную схему через Pinger;
резервировать схему (об этом поговорим чуть позже);
запускать на схеме деплой и следить за его успешностью;
запускать прогон автотестов;
в конце — информировать тестировщиков в Telegram и давать в комментариях к RE-задаче данные о результатах (сколько тестов запущено, на какой схеме, сколько упало и т. д.).
Выглядит классно, но ничего непонятно? Вот упрощённая схема работы Autorun:
Резервирование тестовых схем
Для этого используется ещё один наш самописный сервис — Locker. Выглядит он следующим образом:
Суть его работы — добавить специальный атрибут в схеме. Сделать это можно через UI либо, в случае с ботом, через API, чтобы бот не мог взять эту схему для автоматизации. Так мы гарантируем, что на одной схеме будет пройден один регресс и никакая другая автоматизация его не за затронет.
Автоматизация Jira
Итак, мы научились создавать задачи, запускать в автоматическом режиме тесты и нотифицировать тестировщиков. Но основная проблема ещё не решена: тестировщику по-прежнему необходимо зайти в задачу, перейти в связанную RE-задачу и, в случае успешного прогона, перевести исходную задачу в «Проверено».
Мы обратились к команде, ответственной за интеграцию в Jira, и их усилиями реализовали автоматизацию. В основной задаче появилось дополнительное поле Manual Testing. Оно может принимать значение True/False — на основе этого признака и принимается решение, будет ли задача автоматически переведена в «Проверено» или останется в текущем статусе. То есть если в задаче не требуется ручное тестирование, то Autorun в связанной задаче прогоняет тесты. Если упавших тестов не было, Autorun переводит RE-задачу в статус Done, тогда Jira автоматически переводит основную задачу в статус «Проверено». Так мы получили полную автоматизацию процесса регрессионного тестирования.
Запуск автоматизации на все задачи
Результаты автоматизации не заставили себя ждать — вскоре мы увидели колоссальное сокращение времени, которое требуется на минорные задачи:
Как можно заметить, разработчик сделал минорную задачу за полчаса, после чего её подхватил autorun. Ещё через полчаса задача была автоматически переведена в «Проверено» и поехала дальше. По сравнению с такой же задачей, о которой я говорил выше, мы сэкономили сутки.
Так минорные задачи стали быстрее попадать на прод и не простаивать в тестировании. Разработчики рады, мы тоже довольны, но что-то всё же не давало нам покоя.
Через некоторое время мы поняли, что этот процесс можно включить для всех наших задач, а не только для минорных, ведь тестировщики прогоняют регрессионные тесты вне зависимости от задачи. Никаких особых доработок не понадобилось, и авторегресс был запущен на все задачи.
Результаты автоматизации
Итак, после внедрения авторегресса мы:
ускорили time-to-market задач;
снизили нагрузку на тестировщиков;
научились получать данные для анализа прогонов автотестов;
сократили влияние сторонних задач на прогон тестов.
Каждый день у нас в автоматическом режиме проходит в среднем 50-60 регрессов, общее количество тестов при этом превышает пять тысяч, средний Success Rate — 60%. Показатель не идеальный, есть проблемы со стабильностью автотестов и тестовых схем. Но мы не стоим на месте и продолжаем совершенствовать процесс автоматического регрессионного тестирования.
P. S. Не бойтесь автоматизации, экспериментируйте, создавайте что-то новое. Это всегда интересно и полезно — как для повышения качества и скорости работы, так и для собственного развития.