Управлять тестами стало легче: перспектива модели пользовательского опыта

Содержание

• Введение
• Тестирование и модель пользовательского опыта
• Определение тестовых сценариев
  • Понимание навигационной карты
  • Определение значимых транзакций
  • Оценка усилий по тестированию
  • Определение тестовых данных
  • Планирование модульности
  • Определение правильности транзакций
• Каталог тестовых идей
• Детализация тестовых сценариев с использованием архива эксплуатационных прецедентов
• Чередование экранов
• Заключение
• Примечания

Введение

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

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

Что такое тестовый сценарий? RUP определяет это следующим образом:

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

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

Есть два главных элемента, которые в случае их своевременного и правильного определения, облегчат тестирование:

• Тестовые сценарии
• Тестовые данные

После определения этих элементов все остальные усилия по управлению тестами становятся на свои места. Эта статья описывает, как происходит управление тестами согласно модели пользовательского опыта (UX - User Experience).1)

Тестирование и модель пользовательского опыта

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

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

Определение тестовых сценариев

Давайте рассмотрим, как процесс моделирования UX начинает обнаруживать тестовые мотиваторы.

В типичном проекте сначала моделируется экран, который будет видеть конечный пользователь. Это делается с использованием стереотипов классов <<экран>> и/или <<форма ввода>>. Экраны соединяются вместе в цепочку диаграммы смены экранов, которая представляет собой использование приложения каким-либо образом. Текстовым дополнением этого представления является архив эксплуатационных прецедентов. Многочисленные эксплуатационные прецеденты описывают то, как пользователь взаимодействует с приложением. Все главные пути, которыми пользователь может использовать приложения, представляет навигационная карта.

Мы пройдем через пример покупки билета в кино (Purchase Movie Ticket) на основе модели UX, которая состоит из навигационной карты (рисунок 1), архива эксплуатационных примеров покупки билета в кино (рисунок 2) и череды экранов (рисунок 3).

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

• Понимание навигационной карты.
• Определение значимых транзакций.
• Оценка усилий по тестированию.
• Определение тестовых данных.
• План модульности.
• Определение правильности транзакций.

Понимание навигационной карты

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

Рисунок 1: навигационная карта для архива эксплуатационных прецедентов

Определение значимых транзакций

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

Таблиц

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

О незавершенных операциях мы поговорим в разделе "Детализация тестовых сценариев". Незавершенные транзакции в архиве эксплуатационных прецедентов соответствуют альтернативному потоку.

Оценка усилий по тестированию

Таблица 1 также объясняет усилия, необходимые для выполнения тестовых сценариев. Усилия привязываются к технологии, которая необходима для достижения конечного результата. Если для автоматизации усилия используется средство для записи и воспроизведения, то вместе взятое минимальное время на реализацию тестовых сценариев составляет удвоенное время процесса записи. Это будет важным фактором при принятии решения о необходимых ресурсах и планировании тестов. Например, если пользователю необходимо y минут для достижения страницы результатов выбора фильма и завершения транзакции покупки, то для получения суммарного времени (z), необходимого на запись и воспроизведение одной такой транзакции, можно умножить y на 2. Суммарные необходимые усилия будут равны z, умноженному на количество тестовых сценариев. Это конечное число можно использовать для итерационного планирования.

Определение тестовых данных

Столбец 5 в таблице 1 показывает наборы данных, необходимые для выполнения тестовых сценариев. Тестовые данные для первого тестового сценария (Основной поток 1) можно легко вывести, взглянув на регистрационную форму и форму выбора фильма. Для нахождения тестовых данных для второго тестового сценария (Подчиненный поток 1) необходимо проверить действия, которые ведут к отображению следующего экрана, который перечисляет фильмы, которые можно выбрать.

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

Планирование модульности

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

С применением модульности сопровождение сценариев тестирования становится удобнее. Путем разбиения транзакций на последовательности экранов (как в столбце 4 таблицы 1) можно достигнуть модульности в том случае, если, например, один экран соответствует одному сценарию тестирования.

Таким образом, при изменении основного экрана регистрации (MainFrm), из столбца сценария тестирования (столбец 6 таблицы 1) можно увидеть, что затрагиваются два тестовых сценария. Все, что необходимо сделать, - это изменить всего один сценарий: сценарий регистрации.

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

Определение правильности транзакций

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

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

Коротко говоря, навигационная карта позволяет управляющему по тестам следующее: (1) разрабатывать высокоуровневый черновик тестовых сценариев для всего приложения; (2) определять количество создаваемых тестовых данных. Этот черновик можно детализировать в степени, достаточной для указания проверяемых транзакций и ожидаемых выходных значений.

Каталог тестовых идей

Здесь стоит упомянуть "тестовые идеи" и каталог тестовых идей (артефакт RUP). Не покрытые до настоящего времени тестом транзакции являются тестовыми идеями. Тестовые сценарии, которые они представляют, по-прежнему нуждаются в уточнении и детализации. RUP определяет тестовую идею следующим образом:

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

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

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

Примером каталога тестовых идей служит таблица 2. Соответствующая информация по проектам собирается в строках "Создать (записи о билетах в кино)" и "Выбрать (рецензии на фильм)". Также могут существовать подобные тестовые идеи из другого проекта, как в строке "Создать (другие)".

Таблица 2: каталог тестовых идей

Детализация тестовых сценариев с использованием архива эксплуатационных прецедентов

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

Для определения реальных этапов тестовых сценариев мы сошлемся на архив эксплуатационных прецедентов, который является этапами эксплуатационных прецедентов с дополнительной информацией об опыте пользователя. Архив эксплуатационных прецедентов показан на рисунке 2.

Рисунок 2: архив эксплуатационных прецедентов

Чтобы архив эксплуатационных прецедентов был полезен для детализации тестовых сценариев, необходимы некоторые дополнительные сведения:

• Расскажите, как пользователи будут использовать систему. Архив должен предоставлять пошаговый процесс опыта работы пользователя с этим приложением. Этот процесс в конце концов определит тестовые процедуры, так что архив эксплуатационных прецедентов должен предоставлять достаточно подробные сведения. Поскольку наш пример с Web-узлом продажи билетов в кино имеет два подчиненных потока, то необходимо выполнить как минимум два тестовых сценария.
• Опишите, какие типы объектов могут быть видимыми и их важность для пользователя. Это важная информация для специалистов по тестированию. Вместо того, чтобы полагаться на свой опыт и обучение для определения точек проверки, они находят эти весьма чувствительные точки в архиве эксплуатационных прецедентов. Специалистам по тестированию необходимо создавать методы проверки тестовых сценариев. В данном случае это проверка использования правильной цветовой схемы для отображения цен.
• По возможности включайте различные тестовые сценарии. Различные подчиненные потоки определяют количество производимых тестовых сценариев. Альтернативные потоки также увеличивают количество тестовых сценариев. Одним из недостатков навигационных карт является то, что они не показывают готовые альтернативные потоки, так что легко упустить некоторые тестовые сценарии. Наш пример имеет два альтернативных потока. Обычно опытные специалисты по тестированию находят дополнительные альтернативные потоки при детализации тестовых сценариев или во время реального выполнения тестов, когда обнаруживаются новые варианты.
• Включайте наборы тестовых данных для всех определенных тестовых сценариев. Каждый из этих наборов тестовых данных, определенных ранее, будет кандидатом на различные тестовые сценарии и для дальнейшей разработки. Временами наборы тестовых данных также необходимо уточнять. Например, если пользователи имеют различные профили (как в первом приведенном ранее правиле), то тестовые данные должны отражать это для правильного тестирования механизма профилей. В таких случаях определите наилучший тестовый сценарий, а затем создайте дополнительные тестовые сценарии, которые будут отражать различные наборы тестовых данных. В представленном на рисунке 2 архиве эксплуатационных прецедентов для основного потока могут существовать различные тестовые сценарии. Например, специалист может решить протестировать основной поток с использованием нескольких профилей, или выбрать комбинацию экранных вводов, и т.д. Для соответствия каждому набору тестовых данных (каждому выбранному профилю) создается один тестовый сценарий. Альтернативный метод заключается в выполнении тестового сценария с использованием другого набора данных, но в данном случае важно явно отслеживать различные наборы тестовых данных. Я рекомендую использовать старый метод, поскольку существует прямая зависимость между набором данных и его тестовым сценарием.
• Предоставьте данные, помогающие проанализировать рабочую нагрузку. При обычном тестировании производительности важно определить, где в приложении будет высокий уровень обмена данными. Иногда моделирования всего обмена данными может быть невозможным, так что мы используем правило 80/20 для исключения какой-то части менее важного обмена данными. Другими словами, следует моделировать лишь 80% или более всего объема передаваемых данных, а моделирование оставшихся 20% можно не производить. В нашем примере первый подчиненный поток создает 95% потока данных. Этот объем и необходимо моделировать при тестировании производительности. Оставшиеся 5% претендуют на то, чтобы ими пренебрегли. Либо, в том случае, если уже был создан функциональный сценарий, его можно здесь повторно использовать в качестве замены. Если информация об объеме потока данных отсутствует, например, из-за недавнего создания системы, то возможно моделирование рабочей нагрузки с использованием широчайшего спектра нагрузок. По возможности изучите всех пользователей приложения и определите деловую активность, связанную с работой приложения. Эти действия используются для создания чернового варианта рабочей нагрузки.

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

Чередование экранов

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

Рисунок 3: чередование экранов при покупке билетов в кино

Заключение

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

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

Примечания

1. Хорошей справочной книгой по модели UX является "Создание Web-приложений с помощью UML", 2-я редакция, автор Джим Конэллен (Jim Conallen) (издательство Addison-Wesley, 1999 г.).