Автор: Майкл Болтон (Michael Bolton)
Оригинал статьи
Перевод: Ольга Алифанова

Часть 1
Часть 2
Часть 3
Часть 4
Часть 5

В прошлый раз мы остановились на вопросе "Как сфокусировать работу тестировщика, который уже что-то знает о продукте, не переусердствовав в этом?"

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

Идея тут в использовании сценариев, направляющих тестировщика на пути исследования, экспериментирования и получения опыта на продукте. Все это должно давать ему идеи о реальном использовании и о том, как продукт можно использовать неправильно. Приятно верить, что тщательно проработанный дизайн, юнит-тесты, BDD и автоматические проверки предотвратят баги продукта – и они, безусловно, помогают в этом деле – но, перефразируя Гертруду Штайн, опыт учит опыт учит опыт. Простите за выражение, но если вы хотите найти проблемы, с которыми люди могут столкнуться при использовании продукта, то использование этого чертова продукта может, знаете ли, помочь!

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

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

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

(Некоторые называют пользовательские роли "персонами", как в примерах ниже. Будьте осторожны с путаницей в терминах – ниже вы увидите относительно поверхностное понимание "персоны". У Алана Купера оно отличается и приводится для дизайнерских целей – оно богаче и проработанней. В любом случае его книги стоит прочитать, особенно "Об интерфейсе (с Рейманом, Кронином, Носселом) и более старую "Психбольница в руках пациентов").

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

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

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

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

Учитывая все это, дизайн набора сценариев должен включать шаблоны деятельности или действий, которые может выполнять тестировщик в ходе тестирования:

• Вживаясь в роль персоны или особого пользователя, выполнять задачи, которые, при здравом размышлении, этот пользователь мог бы выполнять.
• Рассматривать новичков продукта и/или доменной области, в которой работает продукт (тестирование на предмет поиска проблем с легкостью обучения).
• Рассматривать людей, имеющих значительный опыт работы с продуктом (тестирование на предмет поиска проблем с легкостью использования).
• Намеренно делать предсказуемые ошибки, которые мог бы сделать пользователь в определенной роли (тестирование на предмет поиска проблем, вызванных правдоподобными ошибками).
• Использовать множество функций и фич продукта реалистичным, но все более изощренным способом, провоцирующим сложные взаимодействия между функциями.
• Работать с записями, объектами и другими элементами данных, покрывая весь их жизненный цикл: создание, проверку, уточнение, извлечение, просмотр, обновление, слияние, разделение, удаление, восстановление, и так далее.
• Разработать богатые, сложные наборы данных для экспериментирования на протяжении длительного этапа (дольше единичной сессии).
• Имитировать турбулентность или помехи, с которыми может столкнуться пользователь: прерывания, отвлечение, препятствия, ветвление и переходы назад, обрывание процессов на полдороге, системные обновления, закрытие крышки ноутбука, въезд в железнодорожный туннель…
• Работать с множеством копий программы, инструментами и/или несколькими тестировщиками, чтобы создать соревнование, раздор и конфликт в доступе к определенным данным или ресурсам.
• Подключать продукт к разной периферии, прогонять его на разном железе и разных платформах, соединять его с взаимодействующими приложениями, работать на разных языках (да, мы в Канаде так делаем).
• Воспроизводить поведения или последовательности действий из сравнимых или конкурирующих продуктов.
• Рассматривать не только людей, использующих продукт, но и людей, взаимодействующих с ними – их заказчиков, клиентов, службы поддержки сети, техническую поддержку или менеджеров.

Дабы внедрить эти идеи в ProChain (компании, разрабатывающей ПО для управления проектами), Джеймс и Джорди разработали сборник сценариев.

Первый пример – это одностраничный документ, описывающий общий протокол для настройки сессий сценария.

Протокол и настройка сценарного тестирования

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

Тестировщики:

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

Настройка:

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

Задачи:

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

• Выберите тест-чартер сценария и проведите около 90 минут, тестируя соответственно чартеру.
• Выполните описанные в чартере действия, но также варьируйте их, и варьируйте последовательность своих действий.
• Если вы видите нечто странное, могущее оказаться проблемой, исследуйте это, даже если оно лежит вне пределов сценарного теста. Вы можете вернуться к сценарию позднее.
• Свободно внедряйте микро-поведения в ваши тесты. Микро-поведения включают совершение ошибок, отступления назад, получение онлайн-помощи в середине операции, нажатие на неверные клавиши, редактирование и повторное редактирование полей, и, в целом, неточное выполнение действий – так, как это делают реальные люди.
• Выполняйте действия, вызывающие сообщения об ошибках, и действия, которые не должны их вызывать.
• Задавайте вопросы о продукте, и пусть они направляют ваше тестирование: что произойдет, если я сделаю это? Может ли продукт справиться с этим?
• Обдумайте возможность работы с несколькими тестировщиками над несколькими сценариями. Совместно прогоните несколько сценариев.
• Не забывайте периодически продвигаться во времени, используя дату симуляции или системное время.

Заметки об оракулах:

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

Отчетность:

• Делайте заметки о всех странностях. Если видите проблему, кратко попытайтесь ее воспроизвести.
• Делайте заметки о препятствиях для тестирования, с которыми вы столкнулись.
  • Записывайте идеи для тестов, которые приходят вам в голову в процессе, и передайте их тест-лиду.

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

Тестировщики должны быть знакомы с оракулами, благодаря которым мы распознаем проблемы, или должны быстро их изучить. Когда этот документ разрабатывался, он содержал список соответствий мнемоническому акрониму HICCUPP; теперь он называется FEW HICCUPPS. Для каждого чартера могли существовать отдельные шаблоны соответствия, артефакты, документы, инструменты и механизмы, которые можно было применять, чтобы помочь тестировщику заметить и описать проблемы.

Вот пример чартера для отдельной миссии тестирования:

Сценарный тест-чартер, UP1: "Проверка и обновление задач"

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

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

Задачи:

• Перейдите в панель "Задачи" и отфильтруйте задачи, назначенные на вас (как вариант, фильтруйте их другими способами – по проекту или по незавершенным задачам, и выберите способ сортировки).
• Выберите один из видов просмотра задач и откройте каждую задачу. Установите фильтр задач так, чтобы он, как минимум, показывал реальный старт, общую продолжительность и оставшееся время.
• Для некоторых задач просмотрите детали, чеклисты и приложения.
• Обновите каким-либо образом каждую задачу, включая:
  • Отсутствие обновлений.
  • "Пометить как обновленную"
  • Сокращение оставшегося времени.
  • Установка оставшегося времени на ноль, или "Отметить как завершенную".
  • Увеличение оставшегося времени.
  • Предоставление комментариев, обновление чеклиста.
  • Отмена каких-либо обновлений.
  • Измените фильтр, чтобы увидеть больше задач. Найдите задачи, которые ведут в ваши или исходят из ваших. Обновите какие-либо из них.

Заметки об оракулах:

• Просмотрите обновленные задачи до буферного обновления, чтобы убедиться, что они верно обновились.
• Просмотрите обновленные задачи после буферного обновления, чтобы убедиться, что они верны.
• Убедитесь, что обновленная задача сообщает, что она "начата", или, где применимо, убедитесь, что она стала ключевой задачей или перестала ей быть.
• Определите общее количество задач, видимое в проектном файле MS, и убедитесь, что все они видны в Enterprise.

Вариации:

• ПОЛЬЗОВАТЕЛЬСКИЕ ДАННЫЕ: максимально ограничьте права пользовательской учетной записи так, чтобы они еще позволяли вам выполнить задачу.
• ПЕРЕТЯГИВАНИЕ КАНАТА: авторизуйтесь другим пользователем и повторно обновите те же задачи, или отмените обновления; авторизуйтесь как тот же самый пользователь (как будто вы забыли, что у вас уже открыто такое окно), затем внесите изменения в обоих окнах.
• УПС: обновите неправильную задачу, а затем отмените обновление; обновите задачу, дождитесь буферного обновления, затем осознайте, что вы налажали, и попытайтесь исправить ошибку.
• ПРЕРЫВАНИЕ: попытайтесь обновиться во время буферного обновления.
  • ЖИЗНЕННЫЙ ЦИКЛ: обновите новую задачу, обновите ее еще несколько раз, увеличивая дату симуляции, затем пометьте ее как завершенную. Сделайте это для всего проекта. Отметьте все задачи как завершенные.

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

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

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

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

Вот еще пример из того же проекта:

Сценарный тест-чартер, UP2: "Проверка статуса и выполнение буферного обновления"

Тема: вы – менеджер проекта. Вам нужно обновить ваш проект, чтобы подготовить еженедельный отчет о статусе проекта.

Настройка:

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

Задачи:

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

Заметки об оракулах:

• Просмотрите обновленные задачи до буферного обновления, чтобы убедиться, что они правильно обновились.
• Просмотрите обновленные задачи после буферного обновления, чтобы убедиться, что они верны.
• Убедитесь, что обновленная задача сообщает, что она "начата", или, где применимо, убедитесь, что она стала ключевой задачей или перестала ей быть.
• Определите общее количество задач, видимое в проектном файле MS, и убедитесь, что все они видны в Enterprise.
• Убедитесь в рациональности цепочек влияния, обновлений цепочек влияния и истории статусов.

Вариации:

• ПОЛЬЗОВАТЕЛЬСКИЕ ДАННЫЕ: суперадмин "случайно" меняет ваши пользовательские права во время теста, и вы больше не можете вносить изменения в ваш собственный проект.
• ПЕРЕТЯГИВАНИЕ КАНАТА: второй пользователь авторизуется и проверяет проект, который вы анализируете, блокируя его для изменений.
• УПС: обновите заметки и комментарии в неправильном проекте и попытайтесь удалить их и применить их к нужному проекту.
  • ПРЕРЫВАНИЯ: периодически нажимайте на иконку принтера.

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

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

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

Больше информации по разработке сценариев можно найти в приложениях к Rapid Software Testing в разделе "PCE Scenario Testing".

Вернемся к нашей тренинг-сессии. Фрида вновь вжилась в роль менеджера, зацикленного на тест-кейсах. "Если мы не дадим им тест-кейсы, то на что мы будем смотреть, когда они закончат работу? Как мы сможем точно убедиться, что было покрыто тестировщиком?"

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

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

Фрида, все еще в роли, ответила – "Хммм… Хотелось бы узнать больше об отчетности". Об этом поговорим в следующий раз!

Обсудить в форуме