Как писать план тестирования

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

Вот здесь и кроется все самое прекрасное и такое милое, что может случиться в рабочей обыденности любого тестировщика: у вас в голове проскакивает мысль, что вышла новая версия браузера, в среде мобильных гаджетов появилось еще одно расширение и вообще, за красивым дизайном и милыми анимациями могут скрываться жесткие баги, за которые будет стыдно именно ВАМ! Чтобы хоть как-то прийти в себя и перестать паниковать, вы открываете в своем компьютере папку с документацией по плану тестирования сайта…

Но, не стоит забывать о стратегии тестирования. О ней сейчас и поговорим.

Зачем применять стратегию тестирования

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

Что же должно быть описано в подобной стратегии

• Какие типы проверок намечены;
• Будет ли выполнятся тестирование UI, производительности системных компонентов, работа конфигураций и прочее;
• Собирается ли команда QA реализовывать прочие статические типы тестов, к примеру, рецензирование установленных требований;
• Будете ли вы проводить исследовательское тестирование, и в каком % соотношении.

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

К примеру, дизайн тестов, подготовка требуемой тестовой веб-среды и многое другое.

Вы спросите, зачем это делать? Чтобы не забыть ни о чем при разработке тест-плана.

Что пойдет в основу будущих тестов? Из какой величины вы намерены выводить величины для проверки установленных тестов?

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

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

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

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

Понятие тест плана

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

Рекомендации по составлению тест-планов

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

• TestPlanTemplate RUP;
• TestPlanTemplate IEEE 829.

Изучив данные документы внимательно, сразу становится понятно, что их содержание описывает одни и те же детали, но в разных формах.

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

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

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

Затем, чтобы документ приобрел более завершенный вид, в него стоит внести такие пункты:

• Актуальное окружение проверяемой системы;
• Используемое для тестов оборудование и виртуальные системы;
• Потенциальные риски и пути их решения.

Типы планов тестирования

Как правило, на практике можно столкнуться с такими видами:

• Мастер тест-план;
• Тест-план (детализированный тест-план).

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

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

Рецензирование и утверждение плана работ

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

Как пример, подобная проектная группа может включать в себя:

• Главного сотрудника отдела QA;
• Тест менеджера (главного менеджера по качеству);
• Начальника отдела разработки;
• Менеджера всего проекта.

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

Тест план объемом в одну страницу – 100% попадание!

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

Думается, второй вариант ему понравиться больше!

Тест план

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

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

Не стоит перегружать документ второстепенными деталями, на которые всем будет, мягко говоря, все равно.

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

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

Если по соображениям, продиктованным исключительно бизнесом, вы обязаны что-то добавить в план – выполните это!

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

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

К примеру, ссылку можно сделать на следующие объекты и компоненты:

• Используемые инструменты для тестов;
• Специальные тест чартеры;
• Список потенциальных рисков;
• Использованные прототипы и проводимые исследования;
• Документы по веб-инфраструктуре;
• Дизайн документ по всему проекту.

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

Пару идей для оригинальной презентации вашего тест плана

Если вы не располагаете большим объемом свободного места, включайте креатив!

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

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

Взгляните на такие варианты:

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

Тест план типа дашборда

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

Trello

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

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