- Сценарий автоматизации
- Создание списка фич и списка требований к автоматизации
- Оцениваем масштаб проекта
- Подбираем платформу
- Определяем языки и фреймворки
- Считаем стоимость
- Поиск и сравнение существующих инструментов
- Смотрим таблицу
- Пишем РоС
- Что еще учесть
На сегодняшний день доступно около 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 (если получится). Функции приложения: аутентификация, отправка багов, пользовательская панель со статусом багов, обработка выплаты баг-баунти; и еще акцент на безопасности и производительности.
Как уже понятно, проект получится достаточно большим, поэтому пробуем “упростить” его, сосредотачиваясь на отдельных частях, и со временем внедрим автоматизацию в проекте, по мере необходимости применяя нужные инструменты (и фреймворки, о чем позже).
Стратегию мы подготовили следующую:
- Оценили масштаб проекта и подобрали функции, подходящие для автоматизации.
- Написали список сценариев автоматизации, без которых точно не обойтись.
- Определили таймлайн имплементации.
- Разобрались с ключевыми инструментами имплементации и поддержки.
Итак с масштабом, похоже, разобрались. Теперь думаем о платформе, на которой будем билдить проект. Пишем список инструментов и фреймворков.
Третий шаг. Подбираем платформу
Именно так, определяем сналача платформу, потому что от этого зависит, какие инструменты будем применять. Для автоматизации в данном проекте могут подойти такие вещи как: Appium, TestComplete, Espresso, XCUITest, Robotium; нужны будут также UI-тесты на десктопных браузерах. Еще подберем “тулзы” для автоматизации API, базы данных, и веб.
Четвертый шаг. Определяем языки и фреймворки.
Наши талантливые автоматизаторы знают все языки, инструменты и фреймворки. И могут писать тестовые скрипты на любом языке. У них есть любимые языки и фреймворки, и их они будут применять.
Тут надо сделать поправку, что в автоматизации нужны люди, которые:
- Хорошо разбираются в том что называется Data Science и автоматизации баз данных
- Умеют правильно подбирать тесты для автоматизации
- Знают как определить нужный уровень автоматизации, не пытаются автоматизировать все подряд
- Знают как работать с API и автоматизировать API и базы данных
- И хорошо умеют писать сценарии автоматизации интерфейса (это обязательно).
Если в команде есть люди, которые хорошо разбираются в Gherkin, и есть возможность ручным тестировщикам и владельцам продукта применить Gherkin для написания автотестов, это обязательно надо делать!
Если команда у вас “обычная”, то есть в ней используют только JavaScript, то и “тулзы” должны соответствовать.
Далее, насколько позволяет уровень команды, можно рассмотреть применение так называемых low-code-tools.
Пятый шаг. Считаем стоимость.
Теперь настало время оценить бюджет проекта. Коротко: все зависит от количества нанятых людей — сколько можно потратить на зарплаты, и на какое время нанимать людей; далее, сколько стоят инструменты и инфраструктура; и потом, сколько будет стоить поддержка.
Далее надо подумать: платить за проприетарные фреймворки, или работать в бесплатном опенсорсном, полагаясь, как мы любим, на доброе комьюнити. Есть подводные камни:
Опенсорсные вещи: хоть они и бесплатные, они “висят” на комьюнити, стало быть своевременная и полная помощь — не факт, что гарантируется. С другой стороны, эти “тулзы” быстро развиваются. А есть возможность и самому вкладываться в их развитие (если уж рассчитываешь на помощь других). Но есть и много случаев, когда отличный опенсорс со временем “потух”, потому что было некому им всерьез заниматься.
Коммерческие: всегда много хороших функций, всегда более-менее надежно, но цены иногда неприятно-шокирующие. С поддержкой комьюнити дела не всегда хорошо, а туториалы и тем более обучение специалистами — бывает за дополнительные деньги.
Шестой шаг. Поиск и сравнение существующих инструментов
Вспоминаем, какие инструменты применялись автоматизаторами (и смежными специалистами) в нашей компании раньше. И что, например, применяли наши разработчики в юнит-тестировании? Должным ли образом налажен наш CI-пайплайн, в котором фиксируется “ход” автотестов?
“Тулзы” и фреймворки отличаются смотря по масштабу тестирования;, так что могут быть разные инструменты для тестов API, интерфейса, баз данных и прочего.
Вспомнили, с чем работали раньше, прикинули какова была эффективность, релевантность их сейчас, не устарели ли.
- Есть ли проблемные места?
- Все ли хорошо шло, можно ли было сделать что-то лучше?
Седьмой шаг. Делаем таблицу
Инструмент/Фреймворк | JavaScript | iFrame | Мобильная автоматизация | Стоимость | Браузеры | Комьюнити и поддержка |
Selenium WebDriver | ✅ | ✅ | ✅ | ✅ Бесплатный | ✅ | ✅ |
WebDriverIO | ✅ | ✅ | ✅ Хорошая совместимость с Appium | ✅ Опенсорсный и бесплатный | ✅ | ✅ Очень хорошее комьюнити |
Cypress.io | ✅ | ⚠️ Есть проблемы с iFrames | ❌ | ⚠️ Бесплатный. Но платный дешборд | ⚠️ Семейство Chrome (а также Edge и Firefox) | ✅ Хорошее комьюнити |
Playwright | ✅ | ✅ | ⚠️ Эмулирует девайсы. Хорош для респонсивных веб-приложений в мобильных браузерах | ✅ | ⚠️ Не поддерживает старые версии Edge и 11-й Internet Explorer | ❌ Новый фреймворк, поэтому с комьюнити не очень хорошо |
Codecept | ✅ | ✅ | ✅ Хорошо работает с Appium | ✅ | ✅ | ⚠️ Не идеальное комьюнити |
Разумеется, команда должна уже владеть этими фреймворками, т.к. обычно времени на овладение нет.
Конкретно наша команда остановилась на Selenium WebDriver, WebDriverIO и Codecept. Такие фреймворки подошли к нашим требованиям.
Восьмой шаг. Пишем РоС
Когда решили вопрос с фреймворками, настало время писать РоС = Proof of concept, “проверка концепции”, “доказательство осуществимости на практике”). Это как бы окончательное уточнение в проекте, которое проясняет вопросы:
- Как фреймворк будет работать в проекте.
- Простой ли он в работе.
- Полностью ли отвечает нашим требованиям в проекте.
- Подходит ли к приоритетным тест-кейсам; гибкий ли, для разных сценариев и версий приложения.
РоС уточняет риски, существующие с фреймворком и инструментами. Возможно, от каких-то фреймворков (и вспомогательных вещей) придется, на основе этого РоС-списка, все-таки отказаться.
Что еще учесть
Надо иметь терпение, выбирая инструменты в крупный проект. Если подходить к делу стратегически, и без суматохи, потом экономится куча времени, денег, и не будет напряжения в команде.