Home

Автор: Аарон Ходдер (Aaron Hodder)

Оригинал статьи: https://www.testingcircus.com/documents/TestingTrapeze-2015-June.pdf#page=14

Перевод: Ольга Алифанова

Ветки

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

Вот как выглядит модель тестового покрытия после чтения спецификации и разговора с разработчиком:

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

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

Выделенные зоны

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

Оценка

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

1. План тестового покрытия разделен на зоны – то есть области покрытия, которые, в идеале, можно протестировать за 90 непрерывных минут.
2. Я допускаю, что тестировщик может завершить три сессии в день.

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

Вот так выглядит план тестового покрытия с выделенными зонами:

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

Я ни в коем случае не хочу заявить, что этот метод точнее (если это вообще возможно оценивать), чем любой другой, но он дает прозрачность, необходимую команде. По моему опыту,  использовании плана тестового покрытия я могу показать его кому-нибудь и услышать «покрытие этой области займет всего 90 минут? Да ты гонишь!». Моя оценка и модель, которую я использовал для этой оценки, существуют совместно.

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

Прогресс

В процессе тестирования мы можем сообщать о своем прогрессе, раскрашивая соответствующие зоны. Мне нравится раскрашивать их так:

• Зеленый – «считается завершенным»
• Красный – «баг, нуждается в фиксе, нужно пересмотреть эту область еще раз»
• Желтый – «произошла проблема, и приемлемое тестирование этой области блокировано»

Пример плана тестового покрытия с закодированным разными цветами прогрессом:

С одного взгляда можно увидеть, что мы примерно наполовину завершили работу, но есть область, которая нуждается в повторном тестировании, и часть зон заблокированы. Мы можем спросить у тестировщика, что происходит: «Что за проблема случилась тут?», «Как разблокировать тебе работу?». План также сообщает нам, что наша временная оценка под угрозой. Вместо того, чтобы в конце проекта обнаружить, что тестирование занимает больше времени, чем планировалось, мы можем на лету видеть угрозы изначальному расписанию.

Результат

Результат – это отчет о тест-сессии и другие артефакты, которые не являются неотъемлемой частью модели (скриншоты, логи, другая документация).

Отчет о тест-сессии

Обычно отчет о тест-сессии содержит следующую информацию:

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

Отчет о тест-сессии фиксирует реально прошедшее тестирование. Генерацию тест-сессий поддерживает множество инструментов – например, Rapid Reporter – но я предпочитаю Notepad.

Каждой завершенной зоне должен соответствовать как минимум один отчет о тест-сессии.

Зона, содержащая тест-сессию:

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

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

Заключение

План тестового покрытия – это название специфичного вида визуальной тестовой модели, которая, с моей точки зрения, опровергает заявление, что исследовательское тестирование не имеет структуры, и что «тест-кейсы» необходимы для формализованного, подотчетного тестирования.

Зачем же я потратил столько сил, чтобы люди перестали называть все тестовые модели, созданные в майнд-карточном софте, майнд-картами? Это же просто семантика?

На самом деле мы не всегда знаем, что люди имеют в виду. С тех пор, как я впервые заговорил о визуальных моделях тестирования (четыре года назад), я видел множество тестировщиков, с энтузиазмом поддерживающих эту концепцию. Однако недавно я заметил, что суть по дороге потерялась. Я видел тестировщиков, пишущих в XMind пошаговые тест-кейсы и заявляющих, что они занимаются lean-тестированием, так как используют «майнд-карты».

У слов, которые мы используем, есть значения, и это значение быстро испаряется из слова «майнд-карта». Вскоре мы будем бороться за различия льва и собаки в костюме льва, как в начальных примерах. Давайте продолжать классифицировать и называть различные вариации тестовых моделей, своими именами!

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