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

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

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

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

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

Примеры часто встречающихся дефектов документации:

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

Тестирование документации цель:

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

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

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

Брайан Хэнкс в своём материале на тему требований ‘Requirements in the Real World’ подчеркивает, что:

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

Когда же тестирование документации наиболее актуально:

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

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

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

Какая документация подвержена тестированию:

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

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

Тестирование документации и требований относится к разряду нефункционального тестирования. Существуют специальные техники для тестирования документации и требований:

1. review требований

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

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

 3) тест-кейсы — требование должно быть проверяемым, значит должны существовать способы проверки корректности реализованного требования. Чем тщательнее продуман чек-лист, тем вероятнее определение проверяемости требований. Прежде, чем записывать возможные тест-кейсы, убедитесь в том, что вы понимаете требование. Для хорошего понимания конкретного требование поможет анализ других требований, которые вполне возможно будут каким либо образом связаны. Но если требование так и не удалось понять — скорее всего в нем есть неточность или ошибка. Когда же все требования будут хорошо сформулированы и протестированы, можно продолжать использование этой техники, совмещая разработку тест-кейсов с дополнительным тестированием.

 4) исследование поведения системы: тестировщик моделирует процесс работы  системой, созданной по тестируемым требованиям и ищет неоднозначные варианты поведения системы (чем-то мне напоминает исследовательское тестирование).  

 5) графическое представление: для того, чтобы увидеть все требования полностью, очень удобно будет использовать рисунки, схемы, мокапы. На рисунках довольно просто заметить неточности, нестыковку элементов. После доработки всех неточностей, получится хорошее дополнение к текстовым требованиям.