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

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

Модульные тесты важны, и они часто дают немедленные результаты. В то время как сквозные автоматические тесты требуют времени на разработку и обслуживание, что может привести к разочарованию и сопротивлению вкладывать время в автоматизацию тестирования.

Дизайн важен, но его также необходимо проверить, работает ли задуманный дизайн на всех платформах и устройствах, а пользовательский опыт на высоте. Обычно это делается путем сквозного тестирования, которое включает тестирование функциональности и макета веб-приложения во всех окнах просмотра и на всех платформах, таких как macOS, Windows, iOS и Android.

Сквозное тестирование обычно выполняется командами QE, в основном разработчиками программного обеспечения в этих командах. Они создают среду автоматизации тестирования для выполнения функциональных тестов и тестов компоновки во всех браузерах и платформах либо с использованием сторонней сетки Selenium (Sauce Labs), либо с внутренней сеткой Selenium, созданной их командами. Это не означает, что выполняется только автоматизация и нет ручного тестирования.

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

Вызов: культура качества

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

Хотя группам обеспечения качества важно адаптироваться к модели непрерывной доставки (DevOps), также важно повысить осведомленность о качестве в организации.

Просто найти ошибки недостаточно, это должно быть нечто большее. Команды QA должны думать и работать над

  • как уменьшить количество дефектов, отправленных в производство, за счет непрерывной интеграции тестирования с использованием модели DevOps
  • как донести до команд информацию о том, что такое Качество и почему оно должно быть приоритетом
  • защита пользовательского опыта путем сбора и предоставления данных заинтересованным сторонам, которые могут влиять и принимать меры

Задача: ручное тестирование

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

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

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

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

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

Задача: автоматизация тестирования

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

Недостаток опыта. Для понимания и работы с средами тестирования JavaScript требуется опыт работы с интерфейсом. Навыков кодирования может быть недостаточно. Вам понадобятся члены команды с сочетанием навыков кодирования, а также понимающие и разрабатывающие масштабируемую структуру автоматизации. Без правильного баланса опыта или практических знаний о тестовых средах вам будет сложно выйти за пределы фазы Proof Of Concept.

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

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

Тестовая среда. Как я упоминал ранее, сквозные тесты обеспечат тестовое покрытие для веб-приложений на всех поддерживаемых платформах и устройствах. Если ваше веб-приложение поддерживает все браузеры на macOS, Windows, iOS и Android, создание инфраструктуры автоматизации тестирования для их поддержки является большой проблемой.

  • Существует множество доступных тестовых фреймворков. Большинство фреймворков не дают вам всего, что нужно для вашего проекта. Вы должны исследовать или создавать собственные методы, чтобы ваши автоматические тесты работали во всех мобильных и настольных браузерах.
  • Эти автоматические тесты требуют затрат на обслуживание, если вам необходимо поддерживать все эти платформы и устройства. Таким образом, важно иметь правильный талант и стратегию тестирования.
  • Для запуска тестов вам потребуется широкий спектр устройств и настольных операционных систем. В зависимости от ваших потребностей вы должны запланировать запуск тестов в Sauce Labs, Browserstack, например, в сторонних сервисах, или создать свои собственные. Если у вас нет сторонней тестовой среды или локальной сетки Selenium, это расстроит ваших разработчиков, поскольку им придется настраивать среду локально, поддерживать ее и запускать разработанные тесты. Это отнимает много времени.

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

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

Статьи по Теме

Создание команды автоматизации с диверсифицированным набором навыков

Функциональное и визуальное регрессионное тестирование

Первоначально опубликовано на https://engineering-quality.com 24 августа 2019 г.