Когда стоит переходить к автоматизации тестирования на проекте?
Почему все больше компаний используют для контроля качества выпускаемого ПО автоматизированное тестирование? Надеюсь, что никто не подумал, что автотесты позволят отказаться от ручного и будут серебряной пулей, решающей все проблемы в процессах.
Это заблуждение, т.к. для повышения качества ПО нужна совокупность мер, лишь часть которых будет — автоматизировать всё, что не приколочено. Явными плюсами автоматизации можно назвать ускорение выпуска релизов, обеспечение повышение покрытия автотестами ПО при тестировании.
|
|
Автотесты |
Ручное тестирование |
| Стоимость | Высокая, но на длительный срок экономически выгодна | Низкая в кратковременной перспективе |
| Скорость | Высокая скорость | Низкая скорость |
| Человеческий фактор | Отсутствует | Могут быть ошибки и пропуски |
| Чувствительность к изменениям в продукте | Очень высокая. Незначительные изменения ведут к переписыванию теста | Невысокая, особенно при изменениях в интерфейсе |
| Виды тестирования | Регрессионное, производительности и нагрузочное тестирование
|
Исследовательское, UX и специальное тестирование
|
| Пользовательский опыт | Отсутствие пользовательского фидбэк. Автотест — машина, которая не поделится с вами своим мнением о вашем ПО
|
Тестировщик выполняет кейсы пользователей, таким образом в процессе тестирования можем получить потенциальный пользовательский фидбэк
|
Предпосылки для использования автотестов в команде:
-
Ваше приложение имеет большое количество функций, требующих проверки на регрессе;
-
Масштаб проекта и долгоидущие планы на его развитие, хотя бы больше года. В этом случае также пора задуматься об уменьшении ручного труда с переходом в автоматизацию.
-
Частые релизы. Если ваш проект увеличивается, релизы ускоряются, но штат сотрудников QA остается прежним, то стоит приступать к автоматизации, многие рутинные операции получится быстрее проверять.
-
Усложнение технологий, в котором проверить «вручную» сложно. Перелопачивать действительно большой объем данных, с которым мы можем столкнуться разве что в BigData, не имеет смысла. Например, сложно вручную проверить все связи между микросервисами или в IoT (Internet of Things).
Стратегия, которая поможет на первых шагах автоматизации:
-
Исследуйте. Потратьте время на поиски повторяющихся кейсов, которые выполняются регулярно. Это позволит снизить нагрузку на специалистов QA в целом;
-
Ищите связи. Если ли вы проводите тестирование в разных браузерах (UI-тесты) с одним бизнес-кейсом — автоматизируйте данные операции;
-
Работайте в команде. При изменениях вашего ПО (рефакторинге, добавлении новой функциональности или изменении текущей) будьте готовы поддерживать ваши кейсы в актуальном состоянии. И прислушивайтесь на планировании, что делают ваши коллеги разработчики, чтобы тесты не падали.
-
Руководствуйтесь логикой. Автотест должен быть независим от других тест-кейсов — тест должен быть объективно маленьким, легко читаться и проверять одно условие.
-
Подходите творчески. Автотест должен иметь стабильный ожидаемый результат (не всегда рекомендуется использовать генерацию случайных величин, чтобы избежать нестабильных (flaky) тестов, который то работает, то нет, и каждый раз необходимо тратить время и искать причину).
-
Следите за порядком. Автотесты не должны дублировать проверки между собой. Например, на уровне unit-тестов можно проверить вариации данных, на API уровне выполнить проверку между сервисами, используя т.н. заглушки — самописные приложения (stub), UI-тестами проверить клиентские сценарии (переход по страницам, ввод данных, нажатие кнопок). Таким образом, будет разбивка между проверками для бизнес-функций на каждом уровне тестирования для достижения оптимального времени прогона автотестов.
