Практика автоматизации
- Smoke-тесты
- Тесты, которые пишутся всегда, и которые пишутся в начале каждого этапа
- “Большие тесты” — с большим массивом данных
- Тесты с множественными конфигурациями
- Тесты производительности
- Что еще учесть
«Автоматизация тестирования нужна, чтобы решить следующие проблемы: утомительная (и дорогая) ручная работа тестировщиков, огромные наборы данных, ускорение процессов в CI/CD-пайплайне. Автоматизация сейчас в тренде, но можно и не поддаваться тренду, а сперва разобраться — что дает автоматизация, и какие есть инструменты. Например, начать с подбора фреймворка.
“Полное всеобъемлющее тестирование невозможно” — гласит один из фундаментальных законов тестирования. Хотя автоматизация заметно расширяет покрытие, бывают ситуации, когда она обходится компании дороже чем ручное тестирование, с точки зрения времени, денег и затраченных усилий.
Перед тем как начать автоматизацию, не помешало бы ознакомиться с такой вещью как DDT-подход к тестированию (Data Driven Testing), который тоже в тренде (почитать о DDT можно здесь). Надо правильно расставить приоритеты — надо уточнить уровень автоматизации. Автотесты, в основном, сейчас применяются в таких сферах как: Юнит-тесты, API-тесты, UI-тесты.
Независимо от уровня автоматизации, ваша цель — автоматизировать то, что приносит больше всего добавочной стоимости для компании, а остальное оставить ручному тестированию. Надо оценить объем данных — если они большие, надо автоматизировать. Если автоматизация проводится “наощупь” или просто потому что “в тренде”, может получиться что затраты огромные, а результат не соответствует ожиданиям.
Далее пять вещей, которые нужно оценить до того как приступать к автоматизации.
1. Автоматизируй Smoke-тесты.
Такие тесты позволяют удостовериться, что приложение в целом работоспособно, и их желательно делать при каждом изменении функциональности, и после каждого билда. Smoke-тесты должны интегрироваться в CI/CD-процессы — это позволяет выловить критические ошибки. Smoke-тестами проверяют основные части приложения/сайта, они должны оставаться работоспособными в любых условиях; гарантируется, что билд достаточно стабилен, значит можно продвигаться дальше в пайплайне.
Автоматизация Smoke-тестирования помогает:
- Оперативно найти критические баги, и сделать это очень рано в пайплайне. Главная страница/экран не открывается; у клиент не получается залогиниться или сделать себе аккаунт; платежные системы не подключаются и т.п.
- Быстрее идет устранение новых или “регрессионных” дефектов. Smoke-тесты сами по себе “дают широкое покрытие, но малую глубину” этого покрытия. Получается много тестовых кейсов без необходимости “глубокого погружения” тестировщиков в проект. Убедились, что самые важные части работоспособны — и идем дальше, к менее важным компонентам.
- Автоматизация Smoke-тестов позволяет экономить время за счет уменьшения большого количества ручной работы. Включение автотестов в CI/CD позволяет проводить smoke-тестирование еще на этапе сборки билда.
2. Автоматизируй тесты, которые пишутся всегда, и которые пишутся в начале каждого этапа
Тогда получаются стабильные тест-сьюты. К примеру, тестирование создания аккаунта должно делаться до того как юзер может логиниться и видеть свое клиентское окно, проводить платежи и т.п.
Создание автоматического “регрессионного” тестового набора (сьюта) позволяет:
- Делать тесты, оперативно находящие баги, возникающие из правок в коде. Правки могут быть новыми функциями, или “фиксами” прошлых багов.
- Тестовый набор, как уже было сказано, получается с повышенной стабильностью и надежностью. Регрессионное тестирование обычно касается существующей функциональности, то есть функции уже тестированы неоднократно. Это повышает стабильность сьютов, экономится время ручных тестировщиков, когда не знаешь, реально “падают” тесты или они нестабильные.
- Экономится время: можно сосредоточиться на ручном тестировании (особенно граничных значений).
3. Автоматизируй “большие тесты” — с большим массивом данных
“Большие тесты” — это может быть ввод больших массивов данных, тестирование форм, или тесты предполагающие многократный ручной ввод самых разных данных. Их-то и надо автоматизировать. Если речь идет о формах, автоматизация позволяет быстро протестировать комбинации данных в форме, например ситуации когда пропущены поля, данные неполные, и т.п. Тут полезно DDT-тестирование, позволяющее модифицировать только данные, а не весь скрипт. Это то что называется “реюзабельный” и эффективный подход.
4. Автоматизируй тесты с множественными конфигурациями
Если в проекте множество ОС и целый “парк браузеров”, будет сложная конфигурация.
Ручная конфигурация всего этого “парка” — утомительная вещь, и для экономии времени такое тестирование стараются автоматизировать. Тесты запускают в разных окружениях, меняя лишь переменную среды достаточно удобным образом.
Желательно также почитать что-то о параллельном тестировании, которое также экономит время. Можно применять специальные “тулзы” типа CircleCI — прописывают ОС/браузер/окружение, в которых будут выполняться параллельные тесты.
5. Автоматизируй тесты производительности
Такие тесты проводятся для устранения отказов приложения, улучшения пресловутого User Experience, и, разумеется, контроля производительности приложения. Проверяется, как приложение ведет себя под серьезной нагрузкой; находят ее проблемные точки; контролируют то что называется “плавность” приложения, время реакции на действия, стабильность, степень задействования аппаратных ресурсов девайса, и способность безболезненно реагировать на резкий рост нагрузки.
Автоматизация тестирования производительности — это когда генерируются тысячи условных “пользователей”, и проверяют, как реагирует приложение.
Что еще учесть
Разумеется, этот список из пяти пунктов — лишь самое базовое в автоматизации. Надо “мыслить стратегически и оставаться сосредоточенным”.
Есть смысл подробно обсудить с другими членами QA-команды их текущие практики, найти узкие места (а они обязательно есть), и посмотреть свежим глазом, что в проекте можно решить автоматизацией, и что решить реально. “Автоматизировать все” по существующему тренду — как уже было сказано, во первых не получится, во вторых бывает вредно.
Перед созданием автотестов надо определить, до какого уровня дойдет автоматизация, а не решать этот вопрос на ходу.
“Автоматизируются тесты, которые автоматизировать выгодно” — когда получается самый высокий ROI (показатель эффективности инвестиций). То есть самые “механические”, потребляющие время, критически важные для бизнеса, и влияющие на производительность.»
