Home

Автор: Майкл Болтон (Michael Bolton)

Оригинал статьи

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

Давайте вначале разберемся, что подразумевается под словом "план". Мы с Джеймсом Бахом говорим о планировании (и учим планировать в курсе Rapid Software Testing), понимая план как сумму или пересечение стратегии и логистики. Стратегия – это набор идей, направляющих ваш тест-дизайн. Логистика – это набор идей, направляющих распределение ваших ресурсов. Объедините их, и получится план. Тут очень важно отметить, что план – это не физический предмет - это набор идей. Следовательно, важно различать план и документацию по планированию – то есть документы, содержащие какую-то касающуюся плана информацию.

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

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

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

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

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

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

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

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

Аудитория документации может включать:

• Меня.
• Мою тест-команду.
• Моего менеджера.
• Кого-либо, кто может дать мне совет по моей стратегии.
• Его (ее) руководитель, и так далее вплоть до гендиректора.
• Клиенты моих заказчиков.
• Другие тест-команды (к примеру, внешняя команда тестирования или команда заказчика).
• Программисты.
• Аудиторы/юристы.
• Прочие люди/агентства.

Документация тест-планирования может иметь форму:

• Наброска на салфетке или бланке гостиницы, чтобы облегчить разговоры о тест-плане.
• Нескольких строк в карманном блокноте.
• Нескольких страниц в настольном блокноте.
• Электронного письма с предположениями о тест-плане, отправленное тестировщику.
• Диаграммы на доске.
• Ментальной карты.
• Иерархического текстового списка.
• Гантт-диаграммы.
• Детального набора тест-идей или кейсов в инструменте управления тестами и требованиями.
• Длинного, но поверхностного Word-документа, поддерживаемого таблицами данных в Excel.
• Формального, доведенного до совершенства и отформатированного документа для представления заказчику или представителям государства.
• Чего угодно еще, что описывает или моделирует ваши намерения, хотя бы частично.

В приложениях к курсу Rapid Software Testing есть отличные примеры документации тест-плана – от набросков и общих описаний до детальных документов. См. страницы 47-166. Пример общей процедуры также можно найти здесь. Обратите внимание на комментарий на странице, ссылающейся на него:

"Я создал эту процедуру для Microsoft, чтобы они могли наилучшим образом убедиться, что приложения, заявляющие о совместимости с Windows 2000, действительно совместимы с ней. Документация процедуры занимает шесть страниц. Насколько мне известно, это первая опубликованная процедура исследовательского тестирования. Она используется вместе с другой, неисследовательской процедурой (занимающей 400 страниц) для проведения сертификационных тестов. Интересно отметить, что мои шесть страниц – это примерно треть всех задач по тестированию".

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

• Планирование – это деятельность, у которой есть альтернативные издержки. Чем больше времени мы тратим на планирование, тем меньше его остается на взаимодействие с продуктом. Я не выступаю за ликвидацию планирования – но на него нужно тратить минимально возможное время, которого достаточно, чтобы эффективно направлять реализацию плана.
• Письменные планы – перевод мыслей в другой формат – занимают больше времени, чем планирование (размышление над идеями).
• Запись идей, наброски, краткие содержания – это продуктивная форма деятельности, обучения и запоминания. Поэтому эта деятельность имеет определенную ценность.
• Запись идей возрастает в важности, если люди разделены пространством, временем, доступными им знаниями в ситуации, когда знание несет ценность. Документы полезны для передачи специфичной или детализированной информации. В этом контексте, опять же, запись идей несет определенную ценность.
• Запись идей может помочь научить людей чему-то, или дать им иллюзию, что они это изучили. Это может даже предотвратить самостоятельное изучение вопроса. Эта проблема не нова – см. "Федр" Платона, и диалог между королем Египта и богом Тотом).
• Разговор (или задавание вопросов) может быть полезнее в ситуации, когда что-то еще не известно, но подлежит изучению.
• Аспекты этих двух подходов могут дополнять друг друга.
• Полезная эвристика, которой я научился от Кема Кейнера – это вопрос, должен ли  ваш тест-план быть продуктом, предназначенным для того, чтобы кто-то получил то, что хочет, или же инструментом, предназначенным для того, чтобы помочь нам достичь наших целей. Это размытые категории, однако размышлять над ними с целью расставить приоритеты может быть полезным.
• Новая информация подталкивает нас к перемене планов. Наиважнейшая часть нашей задачи как тестировщиков – это поиск новой информации. Мы должны с осторожностью выкладываться в планирование, потому что к обеду мы будем знать больше, нежели мы знаем с утра – и это верно для любого временного цикла.
• Контекст влияет на принятые нами решения, и как решения, так и контекст со временем меняются.