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

Развивающийся продукт

Подобный опыт наша команда пережила с собственным продуктом. Изначально думали так: большой проект, вручную тестировать долго, нужна автоматизация. Но по факту команда QA не успевала переписывать автотесты под новый функционал — продукт менялся с каждым спринтом, то есть буквально раз в две недели.

У нас была ситуация, когда переписывали приложение с Xamarin на натив, а часть нативного кода перенесли на React Native. Команда потратила много часов, чтобы переписать все под новый интерфейс.

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

Автоматизация, которую мы используем

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

Тесты для API

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

Для клиентских запросов чаще всего используем Postman, а также различные самописные решения на основе проверенных библиотек и фреймворков. Это могут быть Python в связке с Requests или Ruby с REST Client.

Для эмуляции ответов сервера обычно применяем спуферы, например: Fiddler, Burp Suite, Charles Proxy. Настроили API-тесты, чтобы они автоматически запускались несколько раз в день и проверяли, насколько корректно работает прод.

Проверка критической функциональности

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

Нагрузочное тестирование

Ставим эксперимент и пробуем автоматизировать нагрузочные тесты. Пока что рано делать выводы, но в перспективе это должно помочь разработчикам определять падение производительности еще на этапе написания кода, а также помочь тестировщикам сократить время на регрессионное нагрузочное тестирование.

Длинные end-to-end сценарии в участках со стабильным функционалом

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

Юнит-тестирование

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

В остальных случаях чаще всего тестируем вручную. QA продумывают кейс, тестируют и мы сразу получаем результат.

Целесообразность

Как правило, автоматизация тестирования в стартапе работает так:

1) сначала придумали кейс;

2) потом написали тест;

3) затем его починили;

4) повторить шаг 1.

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

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

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

На самом деле, область автоматизации в тестировании еще только развивается, а современные инструменты ограничены:

  • автоматизировать можно не на всех языках;
  • часто приходится дописывать ядро тестового фреймворка вручную;
  • инструменты для анализа результатов оставляют желать лучшего.

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

Индустрия развивается, и уже лет через пять большая часть ручного поверхностного UI-тестирования перейдет в простые «human-readable» сценарии. Верим, надеемся, ждем.

Саммари

Вопрос применения автотестов в любом проекте — это единство грамотно выбранной стратегии тестирования, комплексного анализа и гибкого подхода. В Меркури мы работали над многими проектами, но универсального «правила» так и не нашли.

Зато определили для себя сценарии, когда автоматизация даже в быстроменяющемся продукте наиболее часто окупает себя:

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

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