Перевод статьи Nikolay Advolodkin «3 GUI test automation mistakes that will kill your project».
Случалось ли так, что вы загорались какой-то идеей на работе, реализация которой меняла все вокруг? Возможно, это была какая-то новая инициатива или усовершенствование неработающего процесса, которые навсегда изменили вашу организацию.
Был ли у вас когда-нибудь подобный опыт с проектом автоматизации тестирования, над которым вы работали? Возможно, автоматизация тестирования была настолько успешной, что все вокруг начали использовать ее в своих конвейерах, чтобы создавать более качественное программное обеспечение, быстрее выпускать продукты и приносить больше прибыли компании.
Подпишитесь на наш ТЕЛЕГРАМ КАНАЛ ПО АВТОМАТИЗАЦИИ ТЕСТИРОВАНИЯ
Для большинства из нас, я могу с уверенностью предположить, что так никогда не было.
Я провел годы, обучая автоматизации тестирования более 50 000 студентов в более чем 100 странах. А с 2018 года я работаю архитектором решений. Эта должность позволяет мне взаимодействовать с десятками клиентов и сотнями инженеров по автоматизации каждый год. И главное, я вижу снова и снова, что автоматизация тестирования – это безумно сложный процесс.
Автоматизацию сложно сделать правильно, и в то же время в ней можно очень легко наделать ошибок. Вот несколько цифр от компании Sauce Labs, которая проверяет количество пройденных тестов на основе 2 миллиардов тестов, выполненных по всему миру в своем облаке непрерывного тестирования. Выяснилось, что менее 20% из нас могут выполнить тест, который проходит в 90% случаев. Еще хуже то, что в даже самой большой группе процент успешно сдавших экзамен составлял от 50% до 75%.
Существуют сотни ошибок, которые могут сорвать проект автоматизации тестирования и привести к потере крупной суммы для вашей компаний. Приведу пример трех распространенных ошибок, которые постоянно встречаются у большинства инженеров, с которыми я работаю, и которые гарантированно приведут к провалу ваш проект.
1. Дефицит простоты
Правильная автоматизация тестирования следует двум основным правилам: «Будь проще» (Keep It Simple Stupid) и «Вам это не понадобится» (You Ain’t Gonna Need It). Эти фундаментальные принципы используются для принятия сотен решений в день. Например, “Буду ли я использовать паттерн “страница-объект” для автоматизации тестирования”? Будь проще!, – и это абсолютно точно.
Есть причина, по которой спустя 15 лет эти шаблоны остаются стандартом по умолчанию в автоматизации тестирования. Зачем нам изобретать велосипед, если он и так существует?
Тогда почему мы делаем все наоборот? Буквально на прошлой неделе я столкнулся на «объект страницы», у которого были только локаторы и имя, не имеющее никакого смысла. Все методы всех объектов страницы размещались в одном файле для возможности «повторного использования». Еще страшнее был сам «объект страницы», который состоит из 10 500 строк кода и в основном управляет параметрами строки запроса.
Еще одна распространенная проблема, с которой я сталкиваюсь ежедневно, – будет ли команда использовать разработку, основанную на поведении (BDD – Behavior-driven development), для автоматизации тестирования. Первый вопрос, который нужно задать: действительно ли это так просто и хотите ли вы изучить новый инструмент, синтаксис и правила.
Это звучит сложно и требует дополнительной работы, а значит не соответствует принципу Keep It Simple.
Во-вторых, является ли целью автоматизации BDD улучшение сотрудничества между разработчиками, QA инженерами и бизнес-аналитиками? Или же основная цель состоит в том, чтобы писать легко читаемые предложения при автоматизации тестирования? Если вы выбираете последний пункт, значит вам это определенно не нужно.
Когда вы заняты автоматизацией тестирования, вы должны думать об этих двух правилах при принятии каждого решения – от высокоуровневых, касающихся архитектуры, до низкоуровневых, которые определяют, следует ли вам вынести эту строку кода в отдельный метод.
Если вы этого не делаете, то каждая написанная вами строка кода – это движение в неправильном направлении. В какой-то момент ваш код станет настолько негодным и необслуживаемым, что вы просто перестанете выполнять свою работу по созданию более качественного программного обеспечения. Вместо этого вы сосредоточитесь на исправлении локаторов, синхронизации и поиске наиболее продвинутых вариантов использования XPath.
2. Наличие неатомарных тестов
Атомарный тест проверяет только одну функцию. В приведенном ниже примере используется пользовательский интерфейс для проверки того, что пользователь может успешно оформить заказ в интернет-магазине:
Этот тест содержит одно утверждение, поэтому он, скорее всего, атомарный. С другой стороны, тест ниже не является атомарным.
Можно сказать, что он проверяет загрузку страницы, наличие некоторых полей, возможность входа пользователя в систему и выхода из нее. Множественные утверждения также являются довольно очевидным признаком.
Интересно, что второй пример выше не так уж плох. В 90% случаев я каждый день встречаюсь с ситуациями гораздо хуже этой.
Чем дальше вы отходите от атомарного тестирования, тем меньше стабильности, эффективности и детерминизма вы получаете от фактической автоматизации GUI. (Детерминированная система – это система, в которой нет случайностей в развитии будущих состояний системы).
Каждое взаимодействие с веб-интерфейсом – это шанс, что что-то пойдет не так. Неверный локатор элемента, неправильная точка синхронизации или обновление страницы – вот лишь некоторые из веб-взаимодействий, которые могут привести к сбою. Следовательно, чем больше таких взаимодействий в тесте, тем менее стабильным он будет.
В результате эффективность автоматизированного тестирования снизится, поскольку вам придется тратить гораздо больше времени на отладку ложных срабатываний. Представьте себе автоматизированный тест, который выполняется за 20 минут вместо 20 секунд. Если первый тест завершится неудачей на 19-й минуте, вам придется подождать 19 минут, прежде чем вы сможете провести отладку сбоя. Если сбой сложнее, чем смена локатора, вы можете потратить час на то, чтобы выяснить, почему он произошел.
Это приводит нас к последнему пункту о том, что наименее атомарные тесты также являются наименее детерминированными. Они дают не самое лучшее представление о сбоях системы. Ваши тесты GUI не работают по разным случайным причинам, за исключением реальных ошибок. А вы тратите свое время на поиск сломанных локаторов элементов, сложных локаторов элементов и некорректных синхронизаций, вместо того, чтобы помогать компании быстро и эффективно создавать более качественное программное обеспечение.
Такая неэффективность проникает в проект автоматизации, как вирус. В итоге в проекте остается команда инженеров по автоматизации, которые в основном тратят свое время на исправление ошибок в коде.
3. Попытка перевести ручное тестирование на автоматизацию
Любой проект, который пытается преобразовать набор ручного тестирования в набор автоматизированного тестирования, гарантированно потерпит неудачу. Эта идея и сам процесс в корне ошибочны. Во-первых, автоматизация тестирования кода и ручное тестирование выполняются совершенно по-разному. Во-вторых, не все ручное тестирование должно быть автоматизировано, особенно на уровне графического интерфейса.
У ручного тестирования есть одна вещь, которой нет у автоматизации: интеллект. С его помощью уже в течение первых 30 минут можно обнаружить множество различных ошибок в приложении, потому что тестировщик интуитивно замечает несогласованное поведение программы.
С другой стороны, автоматизация никогда не находила и не может найти никаких ошибок, кроме валидации, которая выполняется в коде. Вся веб-страница может не отображаться, но если вы указали системе автоматизации пользовательского интерфейса, чтобы она проверила, что URL-адрес отображает правильную строку, то эта автоматизация продолжит выполняться.
Однако решение состоит не в том, чтобы добавлять все проверки в один тест (см. ошибку 2). Оно заключается в правильном применении макетирования и управления состояниями для приведения приложения в желаемую конфигурацию. После этого убедитесь, что ваше приложение с графическим интерфейсом работает должным образом.
В этом примере функция SetCartState() в строке 26 внедряет JavaScript в веб-приложение, чтобы вы могли установить желаемое состояние приложения, создать пользователя и добавить товары в корзину. В конечном счете, это позволяет вам убедиться, что пользователь может правильно выполнить процесс оформления заказа через графический интерфейс.
Попытка сделать что-то большее через веб-интерфейс приведет к отказу от атомарного тестирования и ко всем проблемам, упомянутым в ошибке 2. Таким образом, автоматизация тестирования – это принципиально иной процесс в сравнении с выполнением тестовых примеров вручную.
Не переборщите с автоматизацией
Не пытайтесь автоматизировать все ручные тесты, особенно на уровне графического интерфейса. Это связано в основном с тем, что существуют гораздо более эффективные места для автоматизации тестирования, чем веб-интерфейс – например, уровни модулей и интеграции.
Сложно выработать общее правило, поскольку многие приложения сильно различаются между собой. Но в большинстве случаев вы можете определить, соответствует ли уровень автоматизации GUI необходимому, если:
- Все тесты GUI выполняются менее чем за 30 секунд на ваших локальных ресурсах.
- Все тесты GUI имеют надежность 99,5%.
- Весь набор может быть выполнен менее чем за 10 минут.
Если любое из этих требований не выполняется, то, вероятно, у вас слишком много автоматизации графического интерфейса. Пришло время сделать паузу и убедиться, что вы добавляете автоматизацию тестирования на правильном системном уровне.
Правильное решение этой проблемы заключается в том, чтобы позволить инженеру по автоматизации определить соответствующие тесты для выполнения на уровнях пользовательского интерфейса и API. Кроме того, инженер может работать с разработчиками, чтобы стимулировать их проводить больше юнит-тестов.
В какой-то момент автоматизацию GUI приходиться останавливать, потому что в ней больше нет смысла. И это нормально. Теперь вы можете работать над добавлением автоматизации на более эффективных уровнях вашей системы.
Попытка преобразовать ручной набор в автоматизированный – это принципиально ошибочный процесс, который гарантированно приведет к пустой трате ресурсов вашего работодателя. За всю свою карьеру я ни разу не видел, чтобы это сработало, и я каждый день помогаю компаниям бороться с этим.
Берегите себя от неудач
Автоматизировать тестирование графического пользовательского интерфейса – безумно сложный процесс, о чем свидетельствуют массовые печальные показатели выполнения тестов. Рассмотренные нами ошибки нередко стоят за этими неудачами. Совершите хотя бы одну из них, и ваш проект автоматизации тестирования гарантированно провалится. Совершите все три, и уже никто не сможет распутать этот клубок.