Test Automation: подводные грабли

Автоматического тестирования программного обеспечения, к сожалению, не существует. И вряд ли оно когда-то появится. А вот автоматизировать процесс тестирования можно и нужно. Сегодня едва ли не все софтверное сообщество осознает важность и необходимость автоматизации тестирования, но далеко не все знают, как автоматизировать, что автоматизировать и, как ни странно, зачем автоматизировать. Подходы к разработке тестов совершенствуются, как и любые технологии. Автоматизация тестирования получила толчок к развитию еще в восьмидесятые годы ХХ века. Поначалу она заключалась в запуске через командную строку приложений с некоторыми параметрами и анализе результатов. Вскоре появилось тестирование через API, а позже – и с помощью GUI. Сейчас автоматизация является по-прежнему перспективным направлением, включая автоматизацию установки ПО, автоматизацию запуска тестов и интегрирование в непрерывный процесс разработки. На первый взгляд цели и задачи автоматизации тестирования очевидны: разработанные тесты ускоряют и упрощают тестирование, дефекты в программном обеспечении выявляются вовремя, программный продукт становится лучше – спутники не падают в океан. Но в этой области существует несколько важных моментов, которые часто недопонимаются, причем не только начинающими инженерами. Далее приводятся распространенные уязвимости из практики, которые существенно тормозят тестирование, отнимают ресурсы, тратят время и деньги. Возможно, кому-то они могут показаться банальными, однако очень часто очевидные моменты упускаются из вида.

Дефект как желаемый результат

Многие распространенные ошибки при написании тестов появляются из-за абстрагирования от конечной цели. А желаемый конечный результат – это найденный баг в приложении. Или, на худой конец, гарантия того, что бага нет. Вот, пожалуй, единственная цель Test Automation. Иногда разработка и сопровождение автоматизации так увлекает, что суть теряется из вида: тесты в первую очередь должны тестировать продукт. Быть совершенным продуктом для самой автоматизации все же цель вторичная. Отсюда и следующая проблема.

Автоматизация ради автоматизации.

Зачастую инженеры, особенно считающие себя исключительно программистами, практически все внимание уделяют качеству кода фреймворков для тестирования и построению архитектуры проекта. В результате может получиться качественный, но не очень полезный продукт автоматизации. Выглядит он, скорее всего, хорошо, а тесты работают. Но – вот незадача – продукт он не тестирует вовсе. Хорошо еще, если непосредственно тест кейсы разрабатывал опытный тестировщик. Сюда же можно отнести такое заблуждение, что любой программист может написать хорошую автоматизацию. К сожалению, без специальных знаний и практики, скорее всего – нет. А иногда привлекать программиста, разрабатывающего продукт, к его тестированию может быть еще и очень вредно.

Красим тесты зеленой краской

Менеджмент особенно желает видеть тесты «зелеными». Конечно, уважающий себя тест не должен «падать» по любому удобному случаю. Однако если тест генерирует ошибку и при этом сам не содержит дефект, он и должен оставаться в таком состоянии. Другими словами, если проблема не в самом тесте, то «подгонять» его к правильному результату неразумно. Не говоря уже о перекрашивании отчета в зеленый цвет с помощью Photoshop перед отправкой заказчику. В хорошо организованном проекте нет необходимости в любого рода маскировке отрицательного результата, будь то «workaround» или нежелание разбираться в корне проблемы.

Хардкод

Тема болезненная и не новая, но в автоматизации она приобретает особенное значение. На деле об этом нередко забывают или просто не считают проблемой. Но хорошая практика требует избегать жесткого использования в тестах любой информации, которая хоть как-то связана с каким-то определенным окружением. В идеале все данные, включая информацию о тестах и параметрах, должны выноситься за пределы служебного кода. Еще лучше, если в код вообще нет необходимости лишний раз заглядывать, т.е. нужные изменения можно произвести в файлах с данными. Иногда полезно использовать «data-driven» подход.

TestEverything()

Еще одна проблема заключается в часто встречающемся стремлении протестировать все и сразу. Это, пожалуй, один из самых неприятных аспектов. Тест генерирует сотни строк трудночитаемого лога с сотнями ошибок, что приводит к попыткам воспроизводить шаги вручную, тратя огромное количество времени и ресурсов. Простое правило поможет избежать таких проблем: один сценарий – один конкретный тест, который включает в себя простые и прозрачные шаги. Стремление протестировать заодно и соседнюю (или связанную) функциональность все равно не принесет желаемых результатов. Другими словами, один тест должен решать одну задачу, однако в пределах своей задачи должен быть универсальным. Качественная автоматизация укажет не только на функциональность, содержащую дефект, но и предоставит конкретные шаги для воспроизведения ошибки.

Сегментированность автоматизации

Бывает, что многообразие тестов, используемых фреймворков и приложений для автоматизации, приводит к неразберихе внутри проекта. Особенно, если продукт состоит из нескольких связанных продуктов (как «десктопных», так и веб-приложений). Важно не допустить зависимости между разными проектами по автоматизации. В таком случае требуется особо взвешенный подход к организации тестов. Хорошим выходом является использование API при подготовке данных для UI-тестирования.

Зависимость тестов

Довольно часто принимается за норму связанность тестов между собой, когда последующий тест использует результаты предыдущего. Таких ситуаций стоит опасаться. В идеальном случае каждый тест должен быть независимым и использовать лишь свои собственные данные. И, конечно, следует избегать любых ручных шагов для подготовки данных в приложении. Каждый тест должен быть самодостаточным и иметь возможность быть запущенным на «чистой» системе.

Зависимость функциональности

Стоит обратить внимание на ситуацию, когда тест использует какую-то функциональность приложения при тестировании другой функциональности. Например, тест проверяет наличие в таблице определенных данных, используя функцию поиска в самом приложении. В данном случае стоило бы взять данные из таблицы, не используя функциональность тестируемого приложения, а поиск проверить отдельным тестом. В таком случае, если в продукте Search-функциональность перестанет работать, получим один упавший тест с гордо выполненной функцией поиска дефекта. При этом все остальные тесты останутся работоспособными. Такой подход позволяет избежать применения «воркэраундов» и делает процесс тестирования более надежным.

Keep it simple, stupid!

Автоматизация не всегда хороша. Существует такая функциональность, которую автоматизировать не стоит. Если в вашем приложении, например, отображается какая-то графика, то наверняка будет лучше и проще взглянуть на нее глазами человека, чем изобретать робота. Скорее всего, автоматизировать стоит лишь то, что хорошо поддается автоматизации. В противном случае есть риск потратить время впустую, получив нестабильные, сложные, трудно поддерживаемые и не приносящие полезных результатов тесты. Не лишним будет вспомнить такие полезные концепции как KISS и YAGNI. Несмотря на широкое распространение автоматизации, не стоит относиться к ней как к панацее. Наличие автоматизированных тестов абсолютно не гарантирует успешное тестирование и качественную разработку продукта. Они лишь могут в определенной степени помочь вовремя выявить дефект. Или не выявить ☺. Кроме того, UI-тесты обычно требуют для своего выполнения даже больше времени, чем ручное тестирование, особенно в случае веб-приложений. Такая автоматизация экономит время лишь в случае распределенного запуска или запуска «на ночь». Наиболее успешным, наверное, является сочетание API- и UI-тестов. API-тесты дают существенное преимущество во времени выполнения и устойчивости к изменениям в продукте. Но одновременно требуют более продуманной разработки, т.к. они должны имитировать действия пользователей в реальном приложении. Современный уровень развития информационных технологий требует как никогда взвешенного подхода к тестированию вообще и к автоматизации в частности. Разработка и сопровождение фреймворков для тестирования – это всегда дорогое удовольствие. Сделать так, чтобы автоматизация не отнимала ресурсы, а, наоборот, приносила ощутимую пользу – задача весьма нетривиальная и не такая простая, как иногда кажется. Нужно не только поставить правильные задачи и цели, но и достигать их правильными методами.

Помогаете devby = помогаете ИТ-комьюнити.

Засапортить сейчас.