4 принципа автоматизированного тестирования для большей надежности автотестов

Введение

Я работаю в области тестирования качества почти шесть лет и считаю, что самая большая проблема в автоматизированном тестировании — уверенность в результатах. «Упавший» тест не дает достаточной уверенности в том, что мы обнаружили дефект. Это происходит потому, что существует множество возможных причин сбоев, например проблемы с окружением или инструментами, валидные изменения в программном обеспечении, которые произошли в результате дальнейшей разработки, или плохая архитектура тестов.

В рамках опроса, проведенного в конце 2021 года, примерно 59% респондентов заявили, что регулярно сталкиваются с ненадежными тестами. «Упавший» тест требует внимания человека, а это увеличивает время обратной связи. И получается, что автоматизированные тесты больше не автоматические. Но как мы можем улучшить эту ситуацию?

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

Принцип 1: Изоляция

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

В примере ниже тесты изолированы с помощью уникальных тестовых данных. Без изоляции на TEST 1 может повлиять TEST 2.

Principle 2: Managing application state

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

Кроме того, этот принцип помогает создавать маленькие, атомарные тесты, которые лучше читаются и быстрее выполняются.

В данном примере создается специальный продукт через API, и мы можем быть уверены, что продукт доступен. Продукт удаляется после выполнения TEST 3 для поддержания чистоты среды.

Принцип 3: API предпочтительнее, чем UI

Этот принцип тесно связан с предыдущим. Цель — использовать UI только на странице, где мы хотим что-то проверить. Прокси — это инструмент, который помогает узнать, что происходит под капотом, а затем cмоделировать это с помощью взаимодействия с API и/или с базой данных.

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

Принцип 4: Тестирование на основе функциональности

Интерфейс пользователя часто подвергается изменениям на этапе разработки. Я считаю, что эту проблему можно решить, тестируя только основную функциональность. Маловероятно, что кнопка «купить» исчезнет на странице, предназначенной для продажи чего-то.

Заключение

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

Если вы хотите применять эти принципы, учитывайте, что у приложения должен быть специальный дизайн, который делает возможными изоляцию и управление состоянием. Однако я уверен, что это упростит работу всех членов команды — от тестировщиков до разработчиков, и, что самое важное, повысит качество продукта.