Причины разные: недостаточная компетентность основного пула программистов, необходимость тратить дополнительное время на внедрение тестов (а время, как известно, деньги). Даже те, кто покрывает тестами свои разработки, могут делать это неэффективно, поверхностно.

Более того, пользовательские интерфейсы не всегда оптимальны и эргономичны (с другой стороны, это головная боль архитекторов и дизайнеров). Когда приложение не является многофункциональным, тестирование проводят в ручном режиме. Это кажется удобным, быстрым, позволяет сразу выявить слабые места в коде по ходу разработки.

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

Хорошо то, что в последние годы растет количество организаций, понимающих важность тестирования. GUI-интерфейсы снабжаются соответствующими тестами, давая возможность получать мгновенные отчеты о сбоях в работе приложений.
Тем не менее, и здесь не все так гладко: работу тестов нужно совершенствовать, делая их максимально шустрыми, надежными.

Уважаемый программист и автор многочисленных трудов Майк Кон известен, в том числе, и предложенной в свое время пирамидой тестов. Он посчитал, что тесты бывают разных уровней и масштабов, что отражается на их изолированности от другого кода программы и скорости работы.

Рассмотрим кратко ее элементы.

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

Более трудоёмки и масштабны, но и по количеству их должно быть меньше. Тестирование проводится на уровне модулей приложения. Тут отсутствуют разного рода заглушки. Если для работы модуля требуется получение данных из базы, то осуществляется соединение. Нас не интересуют отдельные функции модуля, его внутренняя составляющая. Тестируется взаимодействие между крупными блоками.

Зачастую мы работаем с уровнем API - программным интерфейсом модулей. Передавая разный набор параметров, мы будем получать, например, от HTTP-сервера отличающиеся ответы. Важно проверить, все ли происходит так, как мы того ожидаем.
На этом уровне отсутствует пользовательский интерфейс.

Вершина пирамиды. Включает в себя графическую оболочку. Такие тесты трудоемки, требуют много времени на проведение, но их количество минимально.

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

Для осуществления подобного тестирования зачастую применяется Selenium.

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

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

Несмотря на условность пирамиды, предложенной М. Коном, из нее выводится два ключевых посыла:
– тестирование разноуровневое, что требует особого подхода к его проведению;
– больше всего тестов проводится на нижних уровнях пирамиды.

Качество тестов сильно влияет на их эффективность и результативность. Рассмотрим основные варианты, способные поднять процедуру тестирования пользовательских интерфейсов на новый уровень.

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

Если реализовать доступ через API, то вся процедура существенно сократится: нужно лишь передать запрос на сервер с требуемыми параметрами и получить список рекламных ссылок.

Если нам необходимо протестировать страницу редактирования профиля пользователя на сайте, то придется осуществить ряд телодвижений: зайти на сайт, найти поля логина и пароля, нажать кнопку войти, попасть на страницу редактирования профиля.

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

Все современные сайты используют куки-файлы для взаимодействия с пользователями. Вид страницы может существенно разниться в зависимости от того, залогинен ли пользователь, посещал ли он уже эту страницу, есть ли какие-то товары в корзине, какой тип устройства используется для просмотра сервиса.

UI-тесты не должны упускать данное обстоятельство. Их задача – имитировать поведение приложения при наличии определенных cookie-файлов. Грамотный инженер по автоматизации обязан использовать разные варианты куки, чтобы тестировать сервис и его работоспособность в меняющихся условиях.

Работая с базой данных напрямую, мы существенно сокращаем количество запросов-ответов при взаимодействии с приложением.

Предположим, тест проверяет корректность авторизации на сайте. Для этого необходимо ввести определенные данные пользователя, дождаться ответа от сайта, отобразить страницу пользователя при правильном наборе переданных параметров.

По факту, мы работаем с базой данных через посредника: сайт, проводя лишние операции. При помощи прямого обращения к базе данных можно задать начальное состояние той или иной страницы для теста. Это ускорит тестирование и позволит проверить функционирование сайта при разных входных параметрах.

Переключение функций (feature flags, feature toggles, feature switches) – актуальная задача, стоящая особо остро перед крупными компаниями. Их сервисы охватывают огромные аудитории, что приводит к разному их градуированию. Для примера, любая социальная сеть не является единожды созданной в конечном варианте. Постоянно добавляются новые фишки, статусы пользователей, возможности. При помощи A/B тестирования они оцениваются по параметрам: востребованности, удобству, эргономичности, скорости работы и т.д. Чтобы проводить такое тестирование, требуется постоянное переключение статусов пользователей. Более того, зачастую новые опции предлагаются ограниченному контингенту.

Создавать каждый раз страницу входа на сайт для разной аудитории неоправданно, так как мы не всегда заранее знаем, какой статус проверяется. Решение проблемы – флаги, передаваемые через куки, например. Активируя ту или иную «кнопку», мы проверяем отличающиеся окружения. Тесты смогут пройтись по всем вариантам окружения, оценивая их валидность.