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

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

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

конспект полезных знаний по тестированию документации
конспект полезных знаний по тестированию документации

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

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

 

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

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

 

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

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

 

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

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

 

конспект полезных знаний по тестированию документации
конспект полезных знаний по тестированию документации

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

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

 

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

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

 

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

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

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

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

 

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

 

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

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

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

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

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

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