• Сценарий автоматизации
• Создание списка фич и списка требований к автоматизации
• Оцениваем масштаб проекта
• Подбираем платформу
• Определяем языки и фреймворки
• Считаем стоимость
• Поиск и сравнение существующих инструментов
• Смотрим таблицу
• Пишем РоС
• Что еще учесть

На сегодняшний день доступно около 20 фреймворков и инструментов автоматизации, самые распространенные — Selenium, WebDriverIO, Cypress, Nightwatch, Playwright и Robot Framework. В этой статье будет описан простой пошаговый процесс, как подобрать нужные инструменты для проекта.

Сценарий

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

Приложение существует в веб-версии и в мобильной, под Android и iOS, обе нативные. Веб-приложение совместимо со всеми браузерами, включая Internet Explorer, Safari, Chrome, Opera, Edge. Есть iframe на каждой странице. Все ссылки открываются в новых вкладках. Есть API для сбора и хранения в базе больших объемов данных. Интерфейс немного отличается в версиях; например для Твиттера есть свои цвета и всплывающие сообщения при создании багов, для Инстаграма свои, и т.п.

Автоматизация: в команде хотят сделать автоматизацию тестов — традиционно, чтобы ускорить релиз и уменьшить количество багов, увеличить покрытие, качественно выловить новые и существующие баги, и встроить тесты в пайплайн CI/CD. Команда также хочет расширить количество браузеров и девайсов, которые можно тестировать одновременно, но не нанимать много тестировщиков, и не покупать много реальных девайсов.

Вот каким путем пошла наша команда.

Шаг первый. Создание списка фич и списка требований к автоматизации

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

Кросс-браузерное тестирование: совместимость со всеми браузерами

Автоматизация для мобильных версий: нативные приложения для Android и iOS

Поддержка табов и iframe: iframe-ы на каждой странице; открытие ссылок в новых вкладках

Автоматизация API: применяется API для сбора данных

Применение Data-Driven Testing: собирается и хранится достточно крупный массив данных; интерфейс приложений, насколько возможно, приспособлен к платформе

Автоматизация что касается баз данных: собираются и сохраняются в базу большие массивы данных

Визуальное регрессионное тестирование: маркируем разными цветами и текстовыми комментариями при создании багов

Юнит-тестирование функций: создаем баги для популярных приложений, получаем баг-баунти

Так, список требований у нас есть. Теперь оцениваем масштаб проекта.

Второй шаг. Оцениваем масштаб проекта

Теперь смотрим, какие требования из списка выше касаются автоматизации. Создаем стратегию автоматизации, как известно, она сильно помогает оценить масштаб и цели проекта, и прояснить результаты. Уже понятно, что нужно автоматизировать шесть функций веб-приложения, что касается самых распространенных браузеров Chrome и Firefox, и API.

Проект с баг-баунти, описанный выше, имеет как бы “много движущихся частей” — достаточно сложных и трудоемких; например веб- и мобильная автоматизация в браузерах и девайсах, автоматизация API и баз данных, а может быть, и data-driven testing (если получится). Функции приложения: аутентификация, отправка багов, пользовательская панель со статусом багов, обработка выплаты баг-баунти; и еще акцент на безопасности и производительности. 

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

Стратегию мы подготовили следующую:

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

Итак с масштабом, похоже, разобрались. Теперь думаем о платформе, на которой будем билдить проект. Пишем список инструментов и фреймворков.

Третий шаг. Подбираем платформу

Именно так, определяем сналача платформу, потому что от этого зависит, какие инструменты будем применять. Для автоматизации в данном проекте могут подойти такие вещи как: Appium, TestComplete, Espresso, XCUITest, Robotium; нужны будут также UI-тесты на десктопных браузерах. Еще подберем “тулзы” для автоматизации API, базы данных, и веб.

Четвертый шаг. Определяем языки и фреймворки.

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

Тут надо сделать поправку, что в автоматизации нужны люди, которые:

• Хорошо разбираются в том что называется Data Science и автоматизации баз данных
• Умеют правильно подбирать тесты для автоматизации
• Знают как определить нужный уровень автоматизации, не пытаются автоматизировать все подряд
• Знают как работать с API и автоматизировать API и базы данных
• И хорошо умеют писать сценарии автоматизации интерфейса (это обязательно).

Если в команде есть люди, которые хорошо разбираются в Gherkin, и есть возможность ручным тестировщикам и владельцам продукта применить Gherkin для написания автотестов, это обязательно надо делать!

Если команда у вас “обычная”, то есть в ней используют только JavaScript, то и “тулзы” должны соответствовать. 

Далее, насколько позволяет уровень команды, можно рассмотреть применение так называемых low-code-tools.

Пятый шаг. Считаем стоимость.

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

Далее надо подумать: платить за проприетарные фреймворки, или работать в бесплатном опенсорсном, полагаясь, как мы любим, на доброе комьюнити. Есть подводные камни:

Опенсорсные вещи: хоть они и бесплатные, они “висят” на комьюнити, стало быть своевременная и полная помощь — не факт, что гарантируется. С другой стороны, эти “тулзы” быстро развиваются. А есть возможность и самому вкладываться в их развитие (если уж рассчитываешь на помощь других). Но есть и много случаев, когда отличный опенсорс со временем “потух”, потому что было некому им всерьез заниматься. 

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

Шестой шаг. Поиск и сравнение существующих инструментов

Вспоминаем, какие инструменты применялись автоматизаторами (и смежными специалистами) в нашей компании раньше. И что, например, применяли наши разработчики в юнит-тестировании? Должным ли образом налажен наш CI-пайплайн, в котором фиксируется “ход” автотестов?

“Тулзы” и фреймворки отличаются смотря по масштабу тестирования;, так что могут быть разные инструменты для тестов API, интерфейса, баз данных и прочего.

Вспомнили, с чем работали раньше, прикинули какова была эффективность, релевантность их сейчас, не устарели ли.

• Есть ли проблемные места?
• Все ли хорошо шло, можно ли было сделать что-то лучше?

Седьмой шаг. Делаем таблицу

Разумеется, команда должна уже владеть этими фреймворками, т.к. обычно времени на овладение нет.

Конкретно наша команда остановилась на Selenium WebDriver, WebDriverIO и Codecept. Такие фреймворки подошли к нашим требованиям.

Восьмой шаг. Пишем РоС

Когда решили вопрос с фреймворками, настало время писать РоС = Proof of concept, “проверка концепции”, “доказательство осуществимости на практике”). Это как бы окончательное уточнение в проекте, которое проясняет вопросы:

1. Как фреймворк будет работать в проекте.
2. Простой ли он в работе.
3. Полностью ли отвечает нашим требованиям в проекте.
4. Подходит ли к приоритетным тест-кейсам; гибкий ли, для разных сценариев и версий приложения.

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

Что еще учесть

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