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

Форматы

Отображать тест план можно разными способами:

• В виде традиционного документа с использованием Microsoft Excel или Microsoft Word.
• Используя методики визуализации с помощью майнд-карт, таблиц, диаграмм, коротких схем.
• Прибегнуть к помощи профессиональных инструментов – систем для управления процессами на проектах.

Преимущества схематических тест планов:
— Позволяют визуально представить запланированный процесс,
— Просты в использовании,
— Гибкие к внесению изменений,
— Содержат самую основную информацию, что позволяет в значительной степени сократить время на планирование.

Рекомендации по написанию

Что должен содержать хороший тест план:

• Что надо тестировать?

Описание объекта тестирования: системы, приложения, оборудования.

• Что будете тестировать?

Список функций и описание тестируемой системы и её компонент в отдельности.

• Как будете тестировать?

Стратегия тестирования, а именно: виды тестирования и их применение по отношению к объекту тестирования.

• Когда будете тестировать?

Последовательность проведения работ: подготовка (Test Preparation), тестирование (Testing), анализ результатов (Test Result Analisys) в разрезе запланированных фаз разработки.

• Критерии начала тестирования:

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

• Критерии окончания тестирования:

Результаты тестирования удовлетворяют критериям качества продукта: требования к количеству открытых багов выполнены, выдержка определенного периода без изменения исходного кода приложения Code Freeze (CF), выдержка определенного периода без открытия новых багов Zero Bug Bounce (ZBB) и т.д.

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

Далее, чтобы документ приобрел более менее серьезный вид, можно дополнить его следующими пунктами:

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

Структура

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

Структура тест-плана:

1-я страница:

— шапка (логотип и адрес компании),

— название,

— версия,

— год.

2-я страница:

— история документа, которая представляет собой таблицу изменений. Эта таблица содержит столбцы: дата, версия, описание, автор.

3-я страница:

— содержание.

4-я страница и далее:

— введение,

— виды тестирования,

— операционные системы, браузеры,

— функционал приложения,

— критерии начала тестирования,

— критерии выхода из тестирования,

— характеристики оборудования.

Предпоследняя страница:

— сколько человеко-часов планируется на различных этапах (дата начала и окончания). Например, на тест-дизайн, выполнение тестов, анализ тестирования, отчеты.

Последняя страница:

— выводы и рекомендации.

Также в тест план могут входить следующие данные:

— команда исполнителей,

— контактные данные,

— жизненный цикл бага,

— риски тестирования,

— ссылки на документы или стандарты,

— толковый словарь,

— расписание,

— обязанности,

— риски.

Рецензия и утверждение

Для увеличения ценности тест плана рекомендуется проводить его периодическое рецензирование со стороны участников проектной группы. Это можно сделать просто договорившись между собой или же реализовать в виде «процедуры утверждения». Примерный список участников проектной группы:

• Ведущий тестировщик,
• Тест менеджер (менеджер по качеству),
• Руководитель разработки,
• Менеджер проекта.

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

Шаблоны и примеры

Каждая методология или процесс диктуют свои форматы оформления планов тестирования.

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

Обычный документ

Шаблоны, которых можно придерживаться:

1. Test Plan Template RUP
2. Test Plan Template IEEE 829

Готовые примеры:

— Тестирование интернет-магазина 1

— Тестирование интернет-магазина 2

— Тестирование программы Блокнот

Майнд-карта (mind map)

Несколько примеров, как именно можно использовать майнд-карту

• 
• 
• 
• 
• 

Дашборд

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

Excel или другая таблица

В таблице можно запросто отобразить любые списки тестов или описание сценариев, с которыми мы намерены работать на данном проекте.

Доска для записей – Trello

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

Итог

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

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

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

Когда вы запускаете новый продукт, обеспечение качества (QA) очень важно. Независимо от того, отдаете ли вы аутсорсинг команде QA или выполняете внутренние проверки, вам необходимо создать план тестирования. Это гарантирует, что в процессе обеспечения качества ничего не будет упущено.

Если вы новичок в планировании тестирования, эта статья ответит на все ваши вопросы и предоставит основу для планирования.

Что такое контроль качества?

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

Источник

Что такое план тестирования?

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

Тесты делятся на несколько категорий:

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

Функциональное тестирование — функциональное тестирование фокусируется на функциях продукта и проверке их соответствия требованиям.

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

Тестирование производительности — тестирование производительности измеряет скорость работы продукта и выявляет любые узкие места в системе.

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

Зачем нужен план тестирования?

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

Как создать идеальный план тестирования?

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

Шаг 1. Анализ продукта

При создании плана тестирования QA вам необходимо разбить свой продукт на более мелкие компоненты. Это позволит вам определить лучший процесс тестирования в зависимости от типа создаваемого продукта:

Источник

• Выявите все функции вашего продукта

• Определите, сколько тестовых сценариев необходимо для каждой функции

• Составьте список, что должно быть проверено

Шаг 2. Проанализируйте целевую аудиторию

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

Шаг 3. Разработайте стратегию

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

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

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

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

Шаг 4. Определите цели

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

Источник

Шаг 5. Определяем критерии теста

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

Критерии приостановки — это условия, которые требуют временной остановки тестирования.

Критерии выхода — это условия, составляющие успешное испытание. Когда критерий выхода выполнен, тест может перейти к следующему этапу.

Шаг 6. Планируйте ресурсы

Теперь, когда у вас есть стратегия и план тестирования, пришло время определить, какие ресурсы необходимо использовать для выполнения работы. Это включает:

Люди — сколько человек необходимо для выполнения задач тестирования.

Время — сколько времени требуется для тестирования.

Инструменты — если в процессе тестирования будут использоваться какие-либо инструменты тестирования и управления задачами.

Бюджет — вам необходимо учитывать размер вашего бюджета на тестирование.

Шаг 7. Спланируйте тестовую среду

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

• Определите конкретное место, где будет проходить тестирование

• Определите типы устройств, необходимых для тестирования

• Назначьте людей на разные части плана тестирования

Шаг 8. График и оценка

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

Шаг 9. Определите результаты тестирования

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

Необходимые тестовые компоненты и документы

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

Идентификатор плана тестирования (ID) — идентификатор плана тестирования требуется, чтобы отличить один план обеспечения качества от другого.

Сводка теста (Test summary) — краткий обзор того, что было протестировано, и были ли обнаружены какие-либо проблемы.

Тестовые элементы — все характеристики и функции, которые были протестированы.

Расписание — включает, когда тесты должны начинаться и останавливаться, кто несет ответственность, где это будет происходить и т. д.

Список функций для тестирования — этот пункт представляет собой список функций, которые необходимо протестировать. Автоматизация Excel поможет вам организовать этот список.

Список функций, которые не будут тестироваться — этот пункт представляет собой список функций, которые не будут тестироваться.

Подход – как будет проходить тестирование.

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

Требования к приостановке и возобновлению — этот пункт представляет собой список условий, которые требуют приостановки и/или возобновления тестирования.

Результаты тестирования — это список всех результатов, которые потребуются после завершения тестирования.

Задачи тестирования — список всех задач, которые необходимы для выполнения QA-тестирования.

Потребности — список всех элементов, необходимых для успешного завершения тестирования QA.

Смета – плановая смета времени и стоимости.

График — список всех этапов и сроков, которые необходимо выполнить.

Инструменты и ресурсы — здесь будут подробно описаны любые инструменты, которые будут использоваться для тестирования.

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

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

Предположения и зависимости — включаtn предположение о том, что требуется для выполнения плана тестирования QA.

Метрики и KPI — включает все элементы, которые необходимо отслеживать.

В заключение

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

Согласно стандарту IEEE 829, тест план должен состоять из 19 пунктов:

• Идентификатор тест плана
• Ссылки
• Введение
• Объекты тестирования
• Проблемы и риски
• Функции, которые нужно протестировать
• Функции, которые НЕ нужно тестировать
• Подходы
• Критерии прохождения тестов для объектов тестирования
• Критерии остановки и требования для возобновления тестирования
• Результаты тестирования
• Оставшиеся задачи тестирования
• Требования среды
• Требования по части кадров и их обучения
• Распределение обязанностей
• Расписание
• Планирование рисков и непредвиденных обстоятельств
• Утверждение
• Глоссарий

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

Одна из важных частей документации — тест план.

В этой статье мы рассмотрим:

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

Прежде чем приступить к определениям и объяснениям, мы хотели бы объяснить еще один важный термин из сферы QA — артефакт тестирования. 

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

А теперь давайте перейдем непосредственно к тест плану.

Что такое тест план?

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

Структура тест плана

Тест план имеет четкую структуру, установленную IEEE 829 — отраслевым стандартом для документации тестирования программ и систем. Это значит, что вы можете подготовить шаблон и использовать его для любого проекта, заполняя конкретными данными.

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

1. Идентификатор тест плана 

В этом разделе мы указываем название и логотип компании, проводящей тестирование, название документа, его версию и год создания. Это титульная страница вашего тест плана.

2. Ссылки

Дальше идет история документа. Добавьте таблицу изменений со следующими столбцами:

• дата
• версия
• описание
• автор.

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

3. Введение

Здесь мы кратко обозначаем, что собираемся делать. Введение — это пояснительная записка для клиента. В паре предложений опишите, какие услуги предоставит команда QA и зачем. Например:

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

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

4. Объекты тестирования

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

5. Проблемы и риски

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

6. Функции, которые нужно протестировать

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

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

7. Функции, которые не нужно тестировать

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

8. Подходы

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

9. Критерии прохождения тестов

Каждый тест-кейс будет обозначен как «Pass» (пройден) или «Fail» (провален) в зависимости от двух критериев:

1. Наличие и серьезность багов
2. Уровень успешно выполненных требований.

И не забудьте определить критерии начала и окончания тестирования. 

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

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

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

Критерии окончания тестирования — это то, что вы считаете необходимым для завершения процесса тестирования. Тестировщики часто стараются сделать критерии окончания тестирования условием для поставки ПО, но это не реально. Это решение принимает собственник продукта (или другое ответственное лицо).

Пример критериев окончания тестирования:

«Все запланированные тесты проведены, все исправленные баги отмечены, сделаны уведомления обо всех новых обнаруженных багах. Все точки отказа (например, провал определенного набора тестов из-за неисправности железа) задокументированы».

10. Критерии остановки и требования для возобновления тестирования

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

11. Результаты тестирования

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

12. Оставшиеся задачи тестирования

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

13. Требования среды

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

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

14. Требования по части кадров и их обучения

Если мы получим задачу тестирования ПО для ядерных реакторов, вполне вероятно, что команда не будет полностью понимать специфику. Это, конечно, преувеличение. Но если команда должна протестировать проект из сферы, с которой они не знакомы, имеет смысл провести лекцию или краткий обучающий курс от экспертов. Это поможет тестировщикам понять особенности проекта и сделает их работу более эффективной.

15. Обязанности

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

16. Расписание

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

17. Планирование рисков и непредвиденных обстоятельств

Этот раздел перекликается с п. 5 «Проблемы и риски». Здесь, в дополнение к перечню рисков, мы предоставляем разъяснения о том, как справиться с этими рисками, и что делать в случае форс-мажорных обстоятельств.

18. Утверждение

Каждый тест план должен содержать информацию о том, кто его составлял (имя, должность), и о том, кто его должен одобрить и дать команде зеленый свет на его использование.

19. Глоссарий

В этом разделе вы можете пояснить основные термины, используемые при написании тест плана. Глоссарий помогает предотвратить неправильное толкование используемой терминологии.

Виды тест планов

Несмотря на стандартную структуру, существует несколько типов тестовых планов. Они отличаются особенностями описанных задач и объемом работ. QA-команды, как правило, используют следующую классификацию:

Тест планы по уровням — планы модульного, интеграционного, системного, приемочного тестирования

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

Мастер тест план — это комплексный план тестирования. Включает высокоуровневую информацию, которая не часто меняется в ходе тестирования и требования к которой не часто пересматриваются.

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

Вы можете создать тест план любого типа без использования каких-то особых инструментов. Вам может повстречаться выражение «Инструменты управления тест планами», но это неточная формулировка. Тест план — это документ, и единственный инструмент, который вам нужен для управления им, это текстовый редактор. Обычно речь идет об инструментах  управления тестированием, таких как TestRail, TestPad, Qmetry, KualItee и т. д. 

Тест план и стратегия тестирования — в чем разница?

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

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

Итоги

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

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

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