Home

Автор: Лукас Розуонек (Łukasz Rosłonek).

Оригинал статьи: http://testdetective.com/top-5-traps-of-test-automation/

Перевод: Ольга Алифанова

"Делаешь что-то неоднократно – автоматизируй это" – довольно частая присказка. Тестирование ПО, при котором зачастую приходится многократно выполнять одинаковые действия – отличное поле деятельности для автоматизации. В современном мире разработки ПО, учитывая использование микросервисов и методологию непрерывной разработки, мы стремимся к быстрому, частому внедрению новой функциональности. Важность автоматизации в связи с этим растет, но связанные с ней проблемы все еще не решены. Вот мой список пяти самых распространенных ошибок, которые совершаются при автоматизации приемочных тестов.

Стабильность

Ложно-отрицательные срабатывания? Тест-план, испещренный красными пометками? Кто ж с этим не сталкивался! Стабильность автотестов – наиболее очевидное требование к ним, но соответствовать ему очень сложно. Даже крупные компании вроде LinkedIn или Spotify признают, что пытаются бороться с нестабильностью. Этому вопросу должно уделяться особое внимание при проектировании автотестов, потому что нестабильность – это основной источник отказов и неэффективности тестов. Создание тестов – это только начало, заложите в спринт время на их поддержку и пересмотр.

Интерфейсные тесты

Web-приложения составляют большинство современного ПО. Логично, что функциональное тестирование предпочитают автоматизировать на уровне интерфейса. Несмотря на свою полезность, браузерные тесты тоже страдают от ряда проблем (медленно выполняются, нестабильны). Так как мы живем в эпоху микросервисов, стоит подумать о делении тестов на уровни, тестировать функциональность приложения напрямую через интеграцию веб-сервисов (или на уровне бэкэнда), и сводить UI-тесты к минимальному набору для дымового тестирования.

Заглушки

Заглушки очень популярны и зачастую без них просто не обойтись, если тестируется система с большим количеством зависимостей. Однако следите за количеством ваших заглушек – они могут устареть или лгать, и ваша разработка начнет опираться на ложные предположения. Часто говорят "не имитируй то, чем ты не владеешь" – то есть что заглушки можно ставить только на те части архитектуры, которые вы внедряете самостоятельно. Все так, если вы тестируете интеграцию вашей системы с внешней, но что, если вы хотите сымитировать стабильные зависимости и тестировать только собственную разработку? Тогда вы ставите заглушки на все, кроме того, что разрабатываете сами. Стратегия использования заглушек может различаться в зависимости от цели тестирования.

Плотная привязка к фрейморку

Очень хитрая ошибка. Разработчики склонны выбирать фреймворки и инструменты, следуя последним тенденциям отрасли. Это верно и для тест-фреймворков: среди них есть прямо-таки отлично подходящие для прогона тестов, и это не говоря про REST-клиент, билд-инструменты, и др. Выбирая технологию, держите в уме необходимость максимальной независимости от инструментов – важен сценарий, а не фреймворк.

Не усложняйте

В зависимости от структуры вашей команды приемочные тесты внедряются или разработчиками, или тестировщиками. Разработчики, как правило, лучше пишут код, а тестировщики более функционально подходят к вопросу (это не правило, высеченное в камне, если что). Автоматизированный тест – сам по себе не продукт, а инструмент, поэтому функциональность важнее сложности. Код ваших тестов почти дорос до размеров кода тестируемой системы? Попробуйте разбить тесты на категории согласно их домену или типу. Добавление новых тестов требует времязатратного анализа структуры кода? Зачастую более подробный (но и более читабельный) код куда лучше для тестов, чем сложные структуры.

Заключение

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

Обсудить в форуме