Написать пост

Как мы сократили регрессионное тестирование в 4 раза

Аватар Типичный программист

Рассказ о том, как от тест-кейсов в Excel-таблице на 100 строк перейти к 1200 тест-кейсам и при этом в 4 раза сократить время регрессионного тестирования.

Меня зовут Александр Наташкин, я уже более 7 лет работаю в сфере тестирования.

В конце 2016 года меня пригласили в компанию «Яндекс.Деньги» возглавить мобильное тестирование и обеспечить достойное качество выпускаемых мобильных продуктов.

В то время наша команда мобильной разработки состояла из 10 разработчиков и 5 тестировщиков, мы разрабатывали под три платформы (Windows Phone, iOS и Android).

Тест-кейсы хранились в Excel-табличке из 117 строк, и последний тест-кейс назывался «И протестировать все остальное». Регрессионное тестирование занимало практически неделю и часто имело больше одной итерации. Новые версии продукта выходили не чаще раза в 1–1,5 месяца.

Сейчас 2020 год, команда выросла более чем в 3 раза, количество тест-кейсов превышает 1200 штук на 2 платформы, регрессионный прогон занимает 1,5 дня, и мы на постоянной основе выпускаем релизы раз в 2 недели, а в случае необходимости можем релизиться каждую неделю.

Регрессионное тестирование мобильного приложения имеет особое значение в релизном цикле и часто отнимает много времени. Чем большей функциональностью обладает ваше приложение, тем дольше вам придется заниматься регрессионной частью тестирования. Одна из ключевых задач руководителя — сокращение времени на регрессионное тестирование без потери качества. Добиться сокращения времени можно разными способами, и в статье мы рассмотрим некоторые из них, которые помогли мне сократить время регрессионного тестирования практически в 4 раза.

Тест-кейсы

Тест-кейсы — это первое, что пришлось приводить в порядок. Для начала мы переехали из Excel-таблички в нормальную TMS, которая позволила организовать тестовую документацию, хранить историю тестовых прогонов и версий.

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

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

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

Но помните: во всем необходимо знать меру, иногда писать тест-кейсы на все подряд бывает избыточно и это не приносит пользы. Также надо определить необходимые критерии детализации кейсов — это что-то вроде code style conventions, только для тест-кейсов. Кейсы с одинаковыми стилистикой и уровнем детализации позволят всем одинаково их читать, ревьюить и использовать.

Зоны ответственности и компетенции

Когда все отвечают за всё, то ответственного не найти. Мы попробовали новый для нас подход: поделили тестировщиков на платформы. Например: все задачи для iOS берут на себя Маша и Саша, а все задачи для Android — Дима и Аня. Мы получили в каждой платформе своих специалистов, которые глубже разбираются в предметной области, особенностях работы приложения в рамках конкретной операционной системы и определенных вендоров, и несут ответственность за релизы своей платформы.

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

Итого: имеем более узконаправленных специалистов, знающих особенности приложения и платформы, а также специфику работы конкретных разработчиков. С изучением документации появилось время готовиться к предстоящему тестированию проектов/релизов и писать тест-кейсы. Это позволило сократить время тестирования, увеличить качество выпускаемых продуктов, иметь документацию и прочие артефакты.

Автоматизация тестирования

Конечно, куда же мы без автоматизации тестирования, у нас она тоже имеется.

Сначала это было так: Appium, Cucumber, BDD-тесты, 1 автоматизатор, который пишет и поддерживает наш фреймворк. Остальные тестировщики только составляли себе кейсы из готовых кусков. Тесты запускались на живых устройствах, подключенных к «билд-агенту», которые часто отваливались, у них вздувались батареи, но все это работало. Писали тесты обычно в оставшееся от основных задач время, но маленькими шажками покрытие росло на обеих платформах (iOS и Android).

К этому времени мы уже провели некоторый ресеч и выяснили, что тестировщик может проходить в среднем 50 кейсов в день. Наш регрессионный прогон в то время состоял из порядка 200-250 кейсов. Несложные расчеты говорят, что нам надо 4-5 человеко-дней на прохождение регресса и каждые 50 автоматизированных кейсов позволяют освобождать практически 1 день.

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

«Все круто, но переделывай»

Интересный случай произошел с выходом iOS10. Все «яблочные» автотесты (на тот момент их было уже порядка 70 штук) ломаются из-за новой версии Xcode и несовместимости Appium. Тогда Appium выпустил фикс только спустя несколько месяцев. Повторно попасть в такую ситуацию я не хотел. Было принято решение отказаться от Appium и перейти на нативные средства сначала для iOS, а в дальнейшем и для Android.

К нативным средствам относятся XCUITest для iOS и Espresso для Android. К этому времени тестировщики уже начали разбираться в особенностях платформы, специфике разработки и имели некоторый опыт работы со Swift. Автотесты Android пока оставили, как есть, ибо оставаться сразу без автотестов на двух платформах очень опрометчивый поступок.

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

Решением стало выделение двух тестировщиков в отдельную команду автоматизации. Один курировал платформу iOS, а второй Android. Основная их задача была подготовить окружение и весь необходимый инструментарий, а в оставшееся время увеличивать покрытие автотестами. Иногда им перепадали задачи ручного тестирования, но я старался минимизировать этот момент.

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

После того как основы были подготовлены начался этап обучения тестировщиков в командах. Задача — научиться писать автотесты, покрывать фичи своей команды автотестами вовремя.

Воркфлоу изменился на:

  • ознакомление с фичей,
  • подготовка тест-кейсов,
  • автоматизация,
  • приемка фичи,
  • автоматизация,
  • регрессионное тестирование.

В итоге

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

Сейчас на проекте автоматизировано примерно 42% iOS и 70% Android. Покрытие проекта автотестами и описанные выше активности позволяют нам проходить регрессионный прогон Android за один день, а регрессионный прогон iOS за 2 дня.

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

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

Следите за новыми постами
Следите за новыми постами по любимым темам
7К открытий7К показов