Когда стоит переходить к автоматизации тестирования на проекте?

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

Это заблуждение, т.к. для повышения качества ПО нужна совокупность мер, лишь часть которых будет - автоматизировать всё, что не приколочено. Явными плюсами автоматизации можно назвать ускорение выпуска релизов, обеспечение повышение покрытия автотестами ПО при тестировании.


Автотесты

Ручное тестирование

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

Предпосылки для использования автотестов в команде:


  1. Ваше приложение имеет большое количество функций, требующих проверки на регрессе;

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

  3. Частые релизы. Если ваш проект увеличивается, релизы ускоряются, но штат сотрудников QA остается прежним, то стоит приступать к автоматизации, многие рутинные операции получится быстрее проверять.

  4. Усложнение технологий, в котором проверить «вручную» сложно. Перелопачивать действительно большой объем данных, с которым мы можем столкнуться разве что в BigData, не имеет смысла. Например, сложно вручную проверить все связи между микросервисами или в IoT (Internet of Things).


Стратегия, которая поможет на первых шагах автоматизации:


  1. Исследуйте. Потратьте время на поиски повторяющихся кейсов, которые выполняются регулярно. Это позволит снизить нагрузку на специалистов QA в целом;

  2. Ищите связи. Если ли вы проводите тестирование в разных браузерах (UI тесты) с одним бизнес-кейсом – автоматизируйте данные операции;

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

  4. Руководствуйтесь логикой. Автотест должен быть независим от других тест-кейсов – тест должен быть объективно маленьким, легко читаться и проверять одно условие.

  5. Подходите творчески. Автотест должен иметь стабильный ожидаемый результат (не всегда рекомендуется использовать генерацию случайных величин, чтобы избежать нестабильных (flaky) тестов, который то работает, то нет, и каждый раз необходимо тратить время и искать причину).

  6. Следите за порядком. Автотесты не должны дублировать проверки между собой. Например, на уровне unit-тестов можно проверить вариации данных, на API уровне выполнить проверку между сервисами, используя т.н. заглушки - самописные приложения (stub), UI тестами проверить клиентские сценарии (переход по страницам, ввод данных, нажатие кнопок). Таким образом, будет разбивка между проверками для бизнес-функций на каждом уровне тестирования для достижения оптимального времени прогона автотестов.


Автор: Андрей Терёшин