Пару дней назад была статья об исследовательском тестировании, и я хотел бы продолжить тему описанием одного из инструментов, поддерживающих процесс такого тестирования.
Что, собственно, мы ожидаем от такого инструмента, если в исследовательском тестировании у нас нет ни сценария, ни плана, ни четких критериев оценки правильности поведения системы?
Требования к инструменту
На мой взгляд, такой инструмент должен:
- Быть интегрирован с системой баг-трекинга, чтобы можно было заводить дефекты по мере их обнаружения
- Автоматически документировать обнаруженный дефект. Это важно, когда тест идёт не по сценарию, а в произвольной последовательности, которую невозможно держать в голове
- Обеспечивать возможность повторения последовательности исследовательского теста
- Быть интегрирован с системой управления требованиями — чтобы по возможности привязывать обнаруженные дефекты к требованиям
- Быть интегрирован с системой управления тестами, чтобы:
- проводить все виды тестирования в единой среде
- создавать новые сценарии тестирования на основе исследовательских тестов
Собственно, оптимальным вариантом в этом смысле будет наличие поддержки исследовательского тестирования в интегрированном инструменте управления требованиями, тестами и дефектами. Об одном из таких инструментов — Microsoft Test Manager 2012 — я и хочу рассказать.
В 2012-й версии MTM появилась поддержка исследовательского тестирования. Способы применения этого функционала мне видятся следующие:
- Проведение исследовательского тестирования в дополнение к тестам по сценариям
- Проведение тестирования в условиях отсутствия сценариев тестирования
- Быстрое создание новых сценариев тестирования через сеансы исследовательского тестирования
Для демонстрации я буду использовать готовую, доступную для загрузки виртуальную машину. Там же есть более подробные инструкции и сценарии использования.
План тестирования
Запустим MTM, выберем проект и откроем план тестирования. В проекте может быть несколько планов тестирования, поэтому требования, сценарии тестирования, дефекты и т.д. хранятся в общем хранилище TFS, а план тестирования позволяет организовать работу с некоторыми из них.
Наш план тестирования может быть совсем пустым, но мы рассмотрим сценарий, когда у нас есть несколько требований и мы добавили их в план (кнопка «Add requirements» — активна, когда выбрана корневая папка или подпапка, Suite). Когда мы добавляем в план требование, для него создается папка, в которую автоматически добавляются все связанные с требованием сценарии тестирования. Здесь же мы можем добавить другие сценарии (кнопка «Add») или создать новые (кнопка «New»). Здесь и далее я использую термин «Требование», хотя его конкретная реализация в TFS может отличаться в зависимости от выбранного шаблона. Это будет «User Story» для Agile, «BacklogItem» для SCRUM, «Requirement» или ещё какой-нибудь тип из категории требований для разных шаблонов.
Сессия исследовательского тестирования
Перейдем к исследовательским тестам. Для этого переключимся на закладку «Test» и дальше откроем пункт «Do Exploratory Testing».
Здесь у нас две ключевые возможности — запустить сеанс исследовательского тестирования («Explore») и запустить сеанс исследовательского тестирования для выбранного требования из списка входящих в текущий план («Explore work item»).
Разница между этими двумя опциями довольно проста: если мы выбираем исследуемое требование, то созданные потом артефакты (результаты тестирования, дефекты, сценарии тестирования) будут автоматически привязаны к этому требованию.
Выберем вариант «Explore work item». Откроется окно оснастки тестирования. Этот инструмент позволит нам собирать информацию о ходе исследовательского тестирования. Когда будем готовы, нажмём кнопку «Start», наш инструмент активизируется.
Правая часть рабочего стола остаётся свободной для работы с тестируемым Web- или Desktop-приложением, а в нашей оснастке мы можем оставлять комментарии по ходу тестирования, добавлять скриншоты, управлять ходом записи действий. В процессе тестирования также могут записываться:
— видео происходящего на экране
— голосовые комментарии
— действия (actions), выполняемые в пользовательском интерфейсе
— отладочная информация Intellitrace
— другие данные, собираемые Diagnostics Adapters (см. ниже про их настройку)
Итак, у нас есть Web-приложение и мы тестируем его поведение.
Пользователь открыл сайт, выбрал товар, добавил его в корзину, ввёл промо-код, нажал чудо-кнопку Go и ничего не произошло. Мне кажется, что это дефект, поэтому я пишу в комментариях «Нет реакции на кнопку Go» и прикладываю скриншот («Add screenshot»).
На первый взгляд, малоинформативно. К сожалению, именно так тестировщики частенько документируют дефекты. Когда они начинают писать нормальное описание, их переименовывают в специалистов по качеству (QA Engineer).
Однако, посмотрим, что может сделать современный инструментарий.
Создание отчета об ошибке.
Кнопкой «Create Bug» создадим новый отчет об ошибке:
И вот тут-то мы понимаем, зачем в исследовательском тестировании нужен MTM:
Дефект уже практически сам задокументирован:
— автоматически записана последовательность действий (шаги 1-7)
— сформировано описание дефекта из введенных комментариев и скриншотов
— приложена собранная системная информация
— приложен лог Intellitrace
— приложена видеозапись происходившего на экране
Теперь специалисту по качеству нет нужды вспоминать, что же он делал для того, чтобы получить ошибку. Все ходы записаны. Разработчику будет очень легко воспроизвести последовательность шагов и очень трудно отклонить ошибку со словами «а у меня всё работает», глядя на видеозапись.
Создание сценария тестирования
Одна из практик тестирования гласит, что прежде, чем исправлять найденную ошибку, следует создать тест, проверяющий наличие этой ошибки.
Функция «Create test case» позволяет автоматически создать сценарий тестирования на основе информации о выполнявшихся действиях.
Действия, которые выполнялись в ходе сессии, добавляются в качестве шагов тестирования. Остаётся при необходимости подправить их описание и добавить информацию об ожидаемом результате в колонку «Expected Result».
В итоге мы можем не только проводить исследовательское тестирование и документировать ошибки, но и использовать этот инструмент для быстрого описания сценариев тестирования.
И если мы в момент старта сессии тестирования выбирали требование, то найденные ошибки и сценарий тестирования будут привязаны к требованию. Впрочем, такие связи всегда можно добавить вручную.
Сохранённые сессии исследовательского тестирования
Информация о сессиях исследовательского тестирования может сохраняться, даже если не было обнаружено дефектов.
Посмотреть их можно на закладке View Exploratory Test Sessions
Можно открыть детальное описание сессии и просмотреть собранные данные
Такие же данные (Test Result) собираются системой и при проведении других типов тестов.
Настройка собираемой информации
Кратко посмотрим настройку параметров собираемой информации в ходе тестирования.
В MTM мы можем создать и использовать несколько конфигураций тестирования, включая не только локальные профили, но и профили для сложных тестовых сред, включающих несколько машин, что позволяет, например, собирать протоколы происходившего и на серверах приложений, и на клиентском рабочем месте, и на других машинах, входящих в тестовую среду.
Для настройки переключаемся из режима «Testing Center» в «Lab Center» и открываем закладку «Test Settings»
Выберем одну из конфигураций и посмотрим её настройки для одной из ролей машин, входящих в тестовые среды:
Достуны несколько базовых адаптеров сбора данных:
- IntelliTrace — сбор исторического протокола исполнения приложений. Статьи на Хабре.
- EventLog — сбор событий из журнала событий Windows
- System Information — сбор данных о конфигурации операционной системы
- Test Impact — сбор данных об исполняемых в ходе теста строчек кода приложений. Используется для выявления тестов, на которые могли повлиять новые изменения в системе версионного контроля (хорошая тема для статьи, правда?)
- Video Recorder — запись происходящего на экране в видеофайл. Есть настройки битрейта и уровня качества. Можно также писать звук.
- Action Log — запись операций с пользовательским интерфейсом.
Последний пункт требует пояснений. Система действительно распознает, какие кнопки были нажаты, какие ссылки открыты, какие поля заполнены, и т.д. Причем, этот механизм используется в нескольких местах: в инструментах описания автоматических тестов пользовательского интерфейса (Coded UI Test), в системе частичной автоматизации ручных тестов, а также при проведении исследовательского тестирования.
Поддерживаются приложения Windows Forms 2.0, Win32, WPF, Silverlight, Web и HTML5 через IE8-10 и некоторые другие.
Есть и неподдерживаемые технологии — Flash/JAVA, SAP, Lotus Notes. Ряд технологий поддерживаются через дополнительные расширения.
Заключение
Исследовательское тестирование — один из видов тестирования. И он должен использоваться как дополнение к существующим процедурам юнит-тестирования, автоматическому, функциональному, эргономическому, нагрузочному тестированию, тестированию безопасности и т.д.
Используемый инструментарий должен обеспечивать единую среду исполнения тестов, хранения результатов и обеспечивать связность со всеми сущностями проекта — требованиями, дефектами и сценариями тестирования.
Автор: ayakovlev
