Добро пожаловать в серию статей «Лидерство в тестировании» от гуру тестирования программного обеспечения и консультанта Пола Джеррарда. Эта серия предназначена для того, чтобы помочь тестировщикам с многолетним опытом работы, особенно в Agile командах, преуспеть в своей роли руководителя тестирования и менеджера.
В предыдущей статье мы рассмотрели инструменты, которые вы будете регулярно использовать как менеджер по тестированию. В этой статье мы более подробно остановимся на инструментах для выполнения тестов и на том, что вы получаете и чего не получаете при их использовании.
Выполнение тестов и автоматизация
Тема автоматизации тестирования (обычно с помощью графического интерфейса пользователя) занимает важное место в числе ключевых приоритетов большинства тестировщиков и менеджеров по тестированию. На первый взгляд эти инструменты кажутся многообещающими, но многие организации, желающие автоматизировать часть или все свои функциональные тесты, сталкиваются с проблемами.
В этой статье мы не будем вдаваться в технические подробности, но затронем некоторые вопросы, актуальные для менеджеров по тестированию и проектам, которым необходимо создать бизнес-обоснование для автоматизации. Мы рассмотрим:
Что вы получаете и чего не получаете от инструментов для выполнения тестов
Автоматизация тестирования с графическим интерфейсом пользователя (GUI)
Важно реалистично оценивать, что может и чего не может автоматизация, поэтому следующие несколько разделов могут показаться несколько пессимистичными.
Что вы получаете и чего не получаете от инструментов для выполнения тестов
Независимо от того, тестируете ли вы настольные приложения Windows, веб-сайты или мобильные устройства, принципы автоматизации тестирования, преимущества и подводные камни одинаковы. Что вы получаете от инструментов, так это:
Неутомимый, предположительно безошибочный робот, который будет выполнять любые тесты, написанные по вашему желанию, по запросу и так часто, как вы пожелаете.
Точное сравнение результатов тестирования с заранее подготовленными ожидаемыми результатами на любом уровне детализации, который вы хотите запрограммировать в инструменте.
Чего вы не получите, так это:
Гибкость и плавное реагирование на аномалии, сбои или сомнительное поведение.
Взгляд и мышление человека-тестировщика, способного принимать решения о том, как исследовать, задавать вопросы, экспериментировать и подвергать сомнению поведение тестируемой системы.
Бесплатные тесты. Вам все равно придется разрабатывать тесты, подготавливать тестовые данные и, например, ожидаемые результаты.
Хотя инструменты для выполнения тестов предлагают широкий спектр функциональных возможностей, им часто не хватает расширенных возможностей хранения данных. Для получения более комплексного решения вам может потребоваться изучить лучшее доступное программное обеспечение для управления базами данных.
Давайте рассмотрим значение этих преимуществ и проблем. Если вы достаточно компетентный программист, то для правильного использования этого инструмента несложно реализовать процедурные тесты, выполняемые людьми, в виде автоматизированных процедур на языке сценариев вашего инструмента.
Пока среда и данные, используемые вашим тестовым приложением, согласованы, вы можете ожидать, что ваши тесты будут надежно выполняться снова и снова. Это очевидное преимущество автоматизированного выполнения тестов.
Но автоматизированные тесты не могут точно имитировать то, что делают (хорошие) тестировщики при тестировании.
Тест, выполненный с помощью инструмента, не эквивалентен такому же тесту, выполненному человеком.
Тест, если он написан по сценарию, может подсказать тестировщику, что делать. Но тестировщики могут выйти за рамки простого сравнения ожидаемого результата с отображаемым на экране.
Тестировщики должны ориентироваться в среде проведения теста и быть бдительными в отношении аномального поведения – реакции на команды; скорости реакции; внешнего вида экрана; поведения объектов, на которые влияет изменение состояния приложения.
Человек-тестировщик, заметив аномалию, может приостановиться, повторить свои действия или глубже изучить приложение или данные, прежде чем прийти к выводу, что приложение работает правильно (или нет), и решить, продолжать ли тест по сценарию, корректировать данные и сценарий теста или продолжать по назначению.
Люди гибки, в то время как инструменты будут выполнять только то, на что вы их запрограммируете. В транзакции на экране инструмент вводит данные, нажимает кнопку и проверяет наличие сообщения или отображаемого результата – и это все. С помощью тестировщиков-людей вы получаете гораздо больше, чем мы считаем само собой разумеющимся.
В принципе, можно запрограммировать инструмент для выполнения всех проверок, которые человек выполняет инстинктивно, но вам придется написать много кода и потратить время на отладку своих тестов. Даже в этом случае вы не сможете понять способность человека решать, что делать дальше – приостановить, продолжить, изменить тест в середине или исследовать аномалию более глубоко.
Нигде негибкость инструментов не проявляется так ярко, как при реагировании на потерю синхронизации скрипта с тестируемой системой. Возможно, ожидаемый результат не совпадает, или система выходит из строя, или поведение пользовательского интерфейса (например, измененный порядок полей или новое поле) отличается от того, что ожидает скрипт. Что делает инструмент? Он пытается продолжить работу, и возникает поток сбоев в работе скрипта или сбоев в работе системы.
Да, вы можете и должны иметь в своем скрипте незапланированные обработчики событий для отслеживания сбоев тестирования. Сбои в синхронизации, несоответствия между состоянием системы и тестовыми данными, изменения в порядке следования полей, появление новых или удаление полей — все это тестировщик может распознать и исправить, не останавливая тестирование. Инструменты не могут этого сделать без значительных усилий с вашей стороны по программированию.
Использование людей для проведения тестов по сценарию также имеет свои недостатки. Тестировщики могут зациклиться на выполнении сценария и забыть о своих наблюдательных навыках. Они могут не замечать явных аномалий, потому что сосредоточены на следовании сценарию. Этот неоптимальный подход - именно то, что мы получаем от автоматизации выполнения тестов.
Слепое следование тестовым сценариям - плохая идея для тестировщиков-людей, но это лучшее, что мы можем сделать с помощью автоматизации тестирования.
В этом сравнении тестировщиков, использующих скрипты, и инструментов, выполняющих тесты, мы не рассматривали, что делают исследовательские тестировщики. Исследовательский подход дает тестировщикам свободу исследовать и тестировать, где и как они хотят.
Очевидно, что инструменты не могут имитировать эту деятельность. Что еще более важно, инструменты не могут определять масштаб, приоритеты и моделировать функциональность системы и риски, а также разрабатывать тесты соответствующим образом.
Анализ тестов и проектирование требуются независимо от того, выполняется ли тест человеком или инструментом.
Существуют дополнительные ограничения на возможности инструментов для выполнения тестов:
Инструменты для выполнения тестов выполняют именно то, на что вы их запрограммировали, – не больше и не меньше
Инструменты обычно не выполняют сборку и настройку среды и приложений, загрузку тестовых данных
Инструменты не занимаются разработкой тестовых примеров или сценариев, подготовкой тестовых данных и ожидаемых результатов
Инструменты не могут принимать продуманные решения при возникновении непредвиденных событий.
Чтобы оптимизировать процессы выполнения тестов, их интеграция с надежным программным обеспечением для управления тестированием может обеспечить оптимизацию рабочих процессов и улучшенную отчетность.
Автоматизация тестирования с графическим интерфейсом пользователя (GUI)
Прошло около двадцати пяти лет с тех пор, как средства автоматизации тестирования с графическим интерфейсом пользователя (GUI) появились на рынке, но число неудачных внедрений средств тестирования с графическим интерфейсом пользователя по-прежнему велико. В основном это происходит потому, что ожидания в отношении автоматизации слишком высоки, и инструменты, используемые без дисциплины, никогда не будут соответствовать им.
Средства автоматизации тестирования с графическим интерфейсом имеют репутацию простых в использовании продуктов, но ими сложно управлять, когда тестируемые приложения (и, следовательно, тестовые сценарии) нуждаются в изменении. Эти инструменты очень чувствительны к изменениям в пользовательском интерфейсе. Изменения в расположении, порядке, размере, а также добавление или удаление экранных объектов — все это может повлиять на сценарии. Дополнительные технические изменения, такие как переименование экранных объектов или изменение "невидимых" встроенных библиотек графического интерфейса, также вызывают проблемы.
Автоматизация тестирования графического интерфейса работает лучше всего, когда соблюдается дисциплина в отношении:
Процесса разработки, а также изменения и релизы тщательно контролируются. Например, результаты изменений анализируются и доводятся до сведения тестировщиков.
Подхода к разработке тестовых сценариев. Опытные инженеры по автоматизации тестирования применяют систематические соглашения об именах, структуры каталогов, модульные, повторно используемые компоненты, методы защищенного программирования и так далее.
Разработка сценариев для автоматизации тестирования — это задача, требующая не только базовых навыков программирования, но и, прежде всего, опыта в автоматизации и используемых инструментах. Там, где тесты автоматизированы в больших масштабах, также необходимы навыки проектирования.
Независимо от того, как поставщики описывают инструменты – “без скриптов”, “пригодные для использования непрограммистами” или “пользователи тоже могут автоматизировать”, - вам все равно нужен менталитет программиста, навыки проектирования и системный подход.
Автоматизация тестирования API и сервисов
При наличии компонентов или функциональных возможностей, развернутых в виде сервисов, вызываемых тонкими или мобильными клиентами, тестирование будет проводиться с использованием API или с помощью вызовов служб. Этот режим тестирования выполняется либо с использованием пользовательского кода, написанного разработчиками, либо с использованием специальных инструментов тестирования API или сервисов. В любом случае, обычный подход заключается в том, чтобы так или иначе автоматизировать тестирование.
Поскольку API "ближе" к тестируемому коду, тесты могут быть гораздо более сфокусированы на тестируемой функциональности. Безусловно, сложности навигации по пользовательскому интерфейсу и тестирование через сам пользовательский интерфейс можно обойти. По этой причине общее правило таково:
Если тестируемую функциональность (на уровне кода или компонента) можно протестировать с помощью вызова функции, API или сервиса, то автоматизация будет проще – и такой подход рекомендуется.
Тестирование через API имеет определенные преимущества.
Несмотря на то, что вам придется использовать или писать код, применять сами тесты будет намного проще (не нужно беспокоиться о пользовательском интерфейсе).
Как только вызов API будет автоматизирован, вам останется только составить таблицу с набором тест-кейсов, которые вы хотите применить. Количество сценариев, которые вы можете автоматизировать, не ограничено.
Тесты на основе API обычно выполняются намного быстрее, что делает этот стиль тестирования подходящим для систем непрерывной доставки, где конвейер развертывания полностью автоматизирован и требуется быстрое реагирование.
"Пирамида автоматизации тестирования" (поиск в Google покажет сотни графических примеров) была принята почти повсеместно, чтобы представить рекомендацию о том, что усилия по автоматизации тестирования должны быть в большей степени сосредоточены на тестировании разработчиками или API, а не на графическом интерфейсе.
Используйте тесты пользовательского интерфейса там, где необходимо отрабатывать рабочий процесс пользователя, но в небольших объемах, поскольку тесты дороги и могут выполняться медленно.
Используйте вызовы API или служб там, где тестируемая функциональность может быть изолирована и где важна скорость и простота автоматизации.
Регрессионное тестирование
Классическое применение автоматизированных инструментов заключается в выполнении регрессионных тестов. Эти тесты выполняются один раз, и считается, что они точно отражают ожидаемое поведение. При изменении тестируемого кода приложения, связанных с ним повторно используемых библиотек или тестовой среды эти тесты обеспечивают некоторую уверенность в том, что изменения не повлияли отрицательно на требуемую функциональность.
Вы можете представить себе автоматизированные тесты как форму, в которую вписывается тестируемая система. Конечно, тесты должны "пройти" все проверки, которые были выполнены ранее. Повторно запуская их, вы пытаетесь продемонстрировать функциональную эквивалентность новой версии программного обеспечения по сравнению с предыдущей. Существует несколько простых принципов, которым вам необходимо следовать:
Во-первых, необходимо выбрать тесты и проверки, которые позволят вам быть уверенным в отсутствии нежелательных изменений в поведении. Эти тесты действуют как “растяжка” для выявления различий в поведении.
При исправлении ошибок или внесении других изменений в программное обеспечение могут быть случаи, когда поведение изменяется (корректно), то есть тесты выявляют изменения как ошибку и считаются неудачными. Либо вы должны изменить свои тесты заранее, либо позволить им завершиться неудачей и исправить их впоследствии. Иногда быстрее полностью отказаться от неудачных тестов и создать новые тесты с нуля, чтобы заменить их. В любом случае, эти измененные тесты затем должны быть выполнены до завершения и успешно пройдены.
Если тестируемая система нестабильна, содержит много ошибок или претерпевает значительные изменения в период между выпусками, возможно, экономически невыгодно поддерживать набор автоматизированных тестов. Хотя функциональность системы не меняется, возможно, что пользовательский интерфейс все еще развивается – нестабильный пользовательский интерфейс также усложняет автоматизацию. Затраты на расследование сбоев в тестировании и техническое обслуживание тестов могут перевесить их полезность. Возможно, было бы разумно протестировать менее стабильные части системы вручную, пока они не стабилизируются.
Тестирование через пользовательский интерфейс иногда может быть громоздким, дорогостоящим и медленным. Прежде чем приступить к автоматизации тестирования с использованием графического интерфейса пользователя или даже к автоматизации отдельного сценария, разумно подумать, будет ли тестирование ключевых функциональных возможностей проще, быстрее и экономичнее с использованием API.
Классическое применение автоматизированных инструментов — это выполнение регрессионных тестов. Чтобы убедиться, что вы используете для этого самые эффективные инструменты, ознакомьтесь с нашим списком лучших средств тестирования программного обеспечения.
Фреймворки автоматизации тестирования
Тестовые платформы являются неотъемлемой частью любого успешного процесса автоматизированного тестирования. Рассматривайте их как набор рекомендаций для создания тест-кейсов. Их использование может повысить скорость и эффективность работы вашей команды по тестированию, повысить точность тестирования, снизить риски и затраты на обслуживание тестов. Сейчас мы рассмотрим два из них.
При обсуждении фреймворков автоматизации тестирования важно учитывать роль средств автоматизации контроля качества в формировании эффективной стратегии тестирования.
Фреймворки модульного тестирования
Фреймворки модульного тестирования существуют уже несколько лет и широко используются программистами для тестирования своего кода. Тесты для разработчиков, как правило, довольно локализованы – в конце концов, они обычно тестируют один компонент с имитацией интерфейсов к другим компонентам или базам данных. Таким образом, несмотря на то что модульные тесты требуют выполнения этапов «настройки» (Setup) и «разрушения» (Tear Down) до и после выполнения тестов, эти задачи, как правило, ограничиваются выполнением тестов одного компонента. Для каждого компонента будут существовать отдельные наборы тестов.
Модульные тесты, создаваемые разработчиками, обычно храняться в системе контроля версий и управляются параллельно с компонентным кодом. Как правило, средства непрерывной интеграции берут исходный код и все модульные тесты и запускают их после каждого коммита нового кода и/или тестов. Все разработчики видят результаты этих тестов, поэтому сбой тестирования в CI становится очень заметным. Исправление ошибок в тестах и коде является приоритетной задачей для команд, использующих CI таким образом, чтобы последняя версия системы постоянно проходила все тесты CI.
Фреймворки автоматизации интеграционных и системных тестов
В последние годы средства тестирования с графическим интерфейсом были интегрированы со средствами CI с использованием виртуализированных тестовых устройств, сред и выполнения через интерфейсы командной строки. Многие организации смогли полностью интегрировать выполнение модульных тестов, тестов на уровне API и тестов с графическим интерфейсом с помощью сервисов CI.
Однако многие команды тестирования по-прежнему используют свои собственные среды тестирования отдельно от служб разработки или CI. Эти команды, как правило, создают свои собственные платформы автоматизации тестирования, потому что инструменты CI слишком ориентированы на разработчиков или проприетарные инструменты не подходят.
Тесты с графическим интерфейсом, как правило, реализуют комплексные тесты или действия пользователей с использованием различных приложений, аппаратных устройств и сред. Для этих тестов необходимо легко настроить интегрированные тестовые среды и подготовить тестовые данные на разных платформах, а для этого требуются привилегированные, сложные процедуры и различные технические среды. Подавляющее большинство команд, использующих автоматизацию тестирования с графическим интерфейсом, создают свои собственные уникальные, но эффективные фреймворки автоматизации.
Платформы автоматизации с графическим интерфейсом различаются по сложности - от инструментов, подобных модульному тестированию, до сложных и всесторонних средств, необходимых для управления средами, сборки приложений, загрузки огромных объемов тестовых данных, обмена сообщениями и синхронизации между платформами и средами, а также обмена сообщениями и уведомлениями для членов команды.
Некоторые фирменные инструменты поставляются с утилитами для управления, выполнения и составления отчетов по наборам автоматизированных тестов. Они имеют различный функционал, поэтому многие организации создают свои собственные платформы автоматизации тестирования, чтобы расширить их функциональность. В последние годы сфера применения фреймворков автоматизации расширилась, и единого или простого определения больше не существует, поэтому сейчас мы рассмотрим, что могут сделать фреймворки автоматизации тестирования для разработчиков программного обеспечения.
Фреймворк автоматизации тестирования расширяет функциональность механизмов выполнения тестов.
Конфигурация набора тестов
Фреймворк объединяет автоматизированные тесты в значимые коллекции, или кластеры, тестов. Эти коллекции настраиваются таким образом, что тесты могут выполняться в виде иерархии последовательностей, групп или произвольных выборок. Эти инструменты могут включать функции для управления данными тестов с использованием подготовленных таблиц тестовых данных. Это самый простой фреймворк — популярные инструменты обычно предлагают некоторую конфигурацию набора тестов.
«Настройка» (Setup) и «разрушение» (Tear Down) тестов
Фреймворк обрабатывает все действия по настройке и разрушению для отдельного теста, коллекции или всего набора. Настройка может включать в себя создание тестовых сред с нуля, полных конфигураций и предварительную загрузку тестовых баз данных и других источников данных с нуля. При разрушении может потребоваться очистка тестовых данных, сброс настроек или удаление частичных или полных сред. Фреймворк может быть интегрирован со средствами конвейерной оркестровки и находиться под их контролем.
Обработка исключений
Сбой в любом тесте – будь то в тестируемой системе или потеря синхронизации – можно устранить последовательно, сообщив о событии и, как правило, позволив остальным тестам в этой коллекции продолжать выполняться. Фреймворк может быть запрограммирован таким образом, чтобы обрабатывать сбои в тестировании, потерю синхронизации, тайм-ауты выполнения и другие выбранные результаты тестирования – для каждого из них используются пользовательские процедуры.
Ведение журнала и обмен сообщениями
Фреймворк последовательно регистрирует выполнение тестов и их статус выполнения во всех наборах тестов. Фрейморк либо запускает создание отчетов от инструментов, которые выполняют тесты, либо предоставляет унифицированный журнал отчетов обо всех действиях по настройке, выполнению и завершению тестирования. Платформа может взаимодействовать с ботами ChatOps, чтобы информировать команду об исключениях и позволять членам команды приостанавливать, останавливать, повторять или перезапускать наборы тестов.
Абстракция тестирования с использованием языка, зависящего от предметной области
На рынке появились два различных типа фреймворков, которые абстрагируют код выполнения теста от моделей или удобочитаемого текста или текста нетехнического содержания:
Фреймворки на основе ключевых слов (Keyword-Driven) позволяют определять тесты с использованием ключевых слов. Вызовы функций исполняемого ядра фреймворка реализованы в виде англоязычных команд с заполнителями для параметров или данных. Пользовательские модули многократного использования могут быть определены и вызваны с помощью обычных текстовых команд таким же образом. Существуют фреймворки для всевозможных интерфейсов, включая графический интерфейс пользователя, службы, API, интерпретаторы командной строки и т. д. Скрипты могут реализовывать функциональность на различных операционных платформах и платформах устройств.
Фреймворки разработки, основанные на поведении (BDD), позволяют записывать юзер стори и сценарии (тесты), описывающие поведение объектов, с использованием языка, зависящего от предметной области (DSL). Наиболее популярным языком является так называемый Gherkin, который использует языковую структуру “given … when … then ….” для получения тестов. Given/when/then эффективно представляют предварительные условия, этапы и последующие условия тест-кейсов. Инструменты BDD преобразуют заданный текст given/when/then в "пошаговые вызовы" на языке программирования. Разработчик (или тестировщик) должен реализовать "fixtures" или код для выполнения вызовов в ядре фреймворка.
Фреймворки, основанные на моделях
В этом случае инструменты позволяют создать модель тестируемой системы. Это может быть автоматически получено из веб-страницы, где инструмент сканирует HTML-код, обнаруживает формы и поля и создает модель, на основе которой методы между перехода между формами могут быть либо сгенерированы автоматически, либо выбраны тестировщиком. Карты объектов для мобильных приложений или других интеллектуальных устройств также можно создавать вручную. Используя пути через карту объектов, вызовы функций исполняемого ядра фреймворка выполняются аналогично BDD и инструментам, управляемым ключевыми словами. В принципе, тесты можно создавать графически без использования кода. Инструменты в этой области являются относительно новыми и быстро совершенствуются. Ожидайте, что в будущем их использование станет более популярным.