Home

Автор: Саймон Найт (Simon Knight)
Оригинал статьи
Перевод: Ольга Алифанова

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

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

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

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

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

Мудрый совет: составляя тест-план, держите в уме пять вопросов:

• ЧТО будет (и не будет) протестировано? – масштаб вашего тестирования.
• КАК оно будет протестировано? – технические детали тестирования, подходы, инструменты, окружения, дата, автоматизация, и т. д.
• КТО будет это тестировать? – какие человеческие ресурсы вам нужны, чтобы справиться с тестированием.
• ПОЧЕМУ это надо тестировать? – ваше обоснование затрат времени и ресурсов на тестирование отдельных областей вместо каких-то других. Что за риски тут покрываются?
• КОГДА тестирование начнется и закончится? – каковы входные и выходные требования к тестированию? Сколько времени оно займет?

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

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

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

Тест-план как ментальная карта

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

Вот как бы я подошел к составлению ментальной карты тест-плана:

1. Начните с центрального раздела. Что нужно получить в результате? Какого результата все желают достичь? Это должно сконцентрировать ваши тест-усилия.
2. Создайте ветки для других ключевых компонентов плана.
   1. Объем тестирования – что вы затронете в ходе тестирования (в плане масштаба)? Что вы не будете затрагивать (останется за рамками)?
   2. Временная шкала – когда тестирование начнется и закончится?
   3. Тест-ресурсы – кто будет заниматься тестированием? Что им понадобится? Где они будут работать?
   4. Тест-подходы – как будет реализовано тестирование?
   5. Риски и допущения – какие препятствия могут вам встретиться? Как вы с ними справитесь?
   6. Потом раскрывайте эти ветки различными элементами и видами деятельности. Объем можно расширить требованиями, фичами или сторис на следующем уровне карты, а после этого копать глубже до отдельных кейсов, сценариев, исследовательских сессий или чего угодно другого в зависимости от вашего тест-стиля.
   7. Сделайте это для всех веток карты, пока ваш подход не станет достаточно детальным, чтобы выдержать пристальное внимание всех заинтересованных лиц.

Мудрый совет: не старайтесь достичь совершенства, какую бы форму ни принимал ваш тест-план. Будьте готовы к тому, что заказчики и команда будут задавать вопросы про план. Его можно обновлять и пересматривать, и это куда менее болезненно, если вы не успели убедить себя, что тест-планирование "завершено". Вы должны расценивать его как рабочий документ, объект постоянного пересмотра и обновления в зависимости от прогресса тестирования.

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

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

Вот еще ряд примеров ментальных карт в тестировании:

• Mindmapping a go-live decision
• Using mindmaps for agile testing
• Mindmaps in software testing

Тест-план в одну страничку

Схожий подход – использовать для тест-плана (или постараться) одностраничный документ.

В плане содержимого этот подход охватывает практически те же самые вопросы, что и ментальная карта: ведь что такое ментальная карта, как не стилизованный набор маркированных списков?

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

Охват вашего документа и последовательность шагов тоже практически идентична:

1. Определите список вопросов, на которые нужно ответить/которые нужно затронуть в вашем плане (помните о пяти вопросах). Используйте их как заголовки секций. Возможно, у вас получится что-то вроде этого (знакомо, не так ли?):
   1. Объем тестирования.
   2. Временные рамки.
   3. Тест-ресурсы.
   4. Тест-подходы.
   5. Риски и допущения.
   6. Изложите необходимую информацию в вашем документе. Идеально, если это маркированные списки, но предоставляйте дополнительную информацию (диаграммы, модели, таблицы), если это необходимо.

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

Мудрый совет: Используйте простой текстовый редактор, а не богатые форматированием инструменты вроде Word или Google Docs. Использование простого редактора и простой разметки сбережет место и сохранит вашу цель сокращения документа до одной страницы.

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

Тест-матрица

Еще одна итерация того же хода мыслей – это тест-матрица.

Я никогда не был поклонником этой модели, но они очень популярны в Lean и Agile-подходах – поэтому при необходимости я их использую.

Если у вас уже есть хорошо сформулированный набор секций тест-плана (например, неоднократно упомянутый выше), распределение их в матрицу – простое дело. Вот несколько примеров, чтобы вы поняли, о чем речь.

• Тест-план удобства использования
• Матрица тестирования
• Матрица автоматизации тестирования

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

• В комнате для совещаний, используя доску для создания секций и Post-It-наклейки для видов деятельности.
• Таблица с общим доступом для совместной работы онлайн, содержащая все нужные секции.

Или же можно пойти другим путем и использовать, например, Trello.

Упрощенное тест-планирование

Я большой фанат этой цитаты из Хельмута фон Мольтке:

"Никакой план не переживает первой встречи с противником".

Особенно мне нравится версия от Майкла Тайсона:

"Все думают, что у них есть план, пока не получат по лицу".

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

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

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

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

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

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

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