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

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

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

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

1. Ваше приложение имеет большое количество функций, требующих проверки на регрессе;
2. Масштаб проекта и долгоидущие планы на его развитие, хотя бы больше года. В этом случае также пора задуматься об уменьшении ручного труда с переходом в автоматизацию.
3. Частые релизы. Если ваш проект увеличивается, релизы ускоряются, но штат сотрудников QA остается прежним, то стоит приступать к автоматизации, многие рутинные операции получится быстрее проверять.
4. Усложнение технологий, в котором проверить «вручную» сложно. Перелопачивать действительно большой объем данных, с которым мы можем столкнуться разве что в BigData, не имеет смысла. Например, сложно вручную проверить все связи между микросервисами или в IoT (Internet of Things).

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

1. Исследуйте. Потратьте время на поиски повторяющихся кейсов, которые выполняются регулярно. Это позволит снизить нагрузку на специалистов QA в целом;
2. Ищите связи. Если ли вы проводите тестирование в разных браузерах (UI тесты) с одним бизнес-кейсом – автоматизируйте данные операции;
3. Работайте в команде. При изменениях вашего ПО (рефакторинге, добавлении новой функциональности или изменении текущей) будьте готовы поддерживать ваши кейсы в актуальном состоянии. И прислушивайтесь на планировании, что делают ваши коллеги разработчики, чтобы тесты не падали.
4. Руководствуйтесь логикой. Автотест должен быть независим от других тест-кейсов – тест должен быть объективно маленьким, легко читаться и проверять одно условие.
5. Подходите творчески. Автотест должен иметь стабильный ожидаемый результат (не всегда рекомендуется использовать генерацию случайных величин, чтобы избежать нестабильных (flaky) тестов, который то работает, то нет, и каждый раз необходимо тратить время и искать причину).
6. Следите за порядком. Автотесты не должны дублировать проверки между собой. Например, на уровне unit-тестов можно проверить вариации данных, на API уровне выполнить проверку между сервисами, используя т.н. заглушки - самописные приложения (stub), UI тестами проверить клиентские сценарии (переход по страницам, ввод данных, нажатие кнопок). Таким образом, будет разбивка между проверками для бизнес-функций на каждом уровне тестирования для достижения оптимального времени прогона автотестов.

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