Всем привет! Меня зовут Данилов Егор, я ведущий тестировщик в компании ЮMoney. Как известно, в основе работы тестировщика лежит рутина. Я хочу рассказать, как мы с ней боремся. Но сначала погрузимся в контекст.
Тестирование в ЮMoney
У нас есть 25 продуктовых команд, в них трудятся порядка 50 тестировщиков. А ещё есть более 150 микросервисов, число которых постоянно растёт. Каждый день появляется в среднем 50 новых задач и проходит более 50 релизов. Наш рекорд — 100 релизов за день. И мы на этом не останавливаемся — наша пропускная способность намного выше.
Чтобы поддерживать высокое качество наших продуктов при такой непрерывной разработке, мы постоянно расширяем экспертизу и стараемся автоматизировать всё, что можно автоматизировать. Все тестировщики в ЮMoney пишут автотесты, поэтому у нас более пяти тысяч E2E-тестов на всевозможные сценарии.
Две стадии тестирования
В жизненном цикле задачи есть две стадии тестирования: после разработки и на этапе релиза. Разберёмся подробнее.
1. Тестирование на этапе фичесборки
Этим занимаются тестировщики в любой компании. Основная цель тестирования на этом этапе — получить предварительную сборку, проверить новую функциональность и провести регрессионное тестирование, то есть убедиться, что уже существующая, работающая функциональность не пострадала от новых изменений.
2. Тестирование на этапе релиза
На этом этапе производится приёмочное тестирование. Мы проверяем, чтобы в процессе мержа фичесборки в мастер не было никаких артефактов. Этап приёмочного тестирования у нас полностью автоматизирован, о нём мы рассказывали в этой статье.
Регрессионное тестирование
Рассмотрим, как выглядит регрессионное тестирование фичесборки и какие действия предпринимает тестировщик.
Для запуска регрессионных тестов тестировщику необходимо:
найти схему для прогона;
задеплоить свою фичесборку;
проверить, что в процессе деплоя не было никаких проблем;
запустить прогон необходимых тестов;
разобрать результаты прогона;
откатить фичесборку и вернуть схему в эталонное состояние.
Все автоматические процессы (деплой сборок, запуск тестов и т.д.) у нас интегрированы в CI/CD. Тестировщику надо лишь зайти в нужные джобы Jenkins и запустить их с необходимым набором параметров. Или же воспользоваться нашими самописными сервисами. О них мы и поговорим.
Внутренние сервисы, которые помогают нашим тестировщикам
Нужно сказать пару слов про тестовые схемы — это набор виртуальных машин с запущенными на них приложениями. Как я уже говорил, у нас более 150 микросервисов. У каждой команды есть несколько тестовых схем с необходимым количеством приложений.
Чтобы тестировщику не приходилось вручную искать нужные хосты, подключаться по SSH и устанавливать нужные версии приложений через apt-get install, мы реализовали самописный сервис под кодовым названием Pinger.
Сервис имеет простой UI. Можно найти нужную схему по префиксу команды, посмотреть текущее состояние компонент на схеме и выполнить ряд действий над компонентом. Нажатие на компонент позволяет:
установить нужную версию;
запустить прогон автотестов на компонент;
сделать рестарт или пересоздание компоненты;
подключиться по SSH.
С помощью Pinger мы упростили жизнь тестировщикам и сократили время, которое тратится на рутинные действия. Теперь не нужно искать схемы и приложения, подключаться к ним по SSH, чтобы установить нужную версию, и следить по логам за ходом установки. За всё это отвечает один сервис.
Ещё одна задача тестировщика заключается в том, чтобы разобрать и обработать результаты прогона автотестов. С этим ему помогает сервис Reporter.
В сервисе можно:
Посмотреть детальную статистику по тестам, их Success Rate, количество успешных и неудачных запусков.
Заблокировать тесты.
Посмотреть детальный отчёт о прогоне (узнать, сколько тестов запускалось и сколько из них прошло успешно, найти все необходимые ссылки на джобы деплоя и запуска тестов, на Allure отчёт и в TMS для просмотра тест-кейса).
Перезапустить прогон автотестов — весь целиком или только упавшие тесты.
Предвосхищаю вопрос: зачем изобретать велосипед, когда есть, например, Allure TestOps? Да, но мы сделали наш сервис в те времена, когда мейнстримом был Allure Report. Да и реализовывать нужные фичи нам удобнее и быстрее в своих сервисах, не дожидаясь комьюнити.
Подведём итог
Перечисленные сервисы закрывают почти все потребности тестирования в запуске, аналитике и разборе автотестов. Тестировщику остаётся только вручную проверить новую функциональность — или ту, которая не автоматизирована. При этом у тестировщиков по-прежнему есть доступ ко всем джобам и виртуальным машинам для более детального анализа проблем.
В этой статье я рассказал лишь о малой части сервисов, которые используются у нас в компании. В следующей публикации поговорим о регрессионном тестировании и о том, как мы с ним справляемся.