По итогам своего тренинга с TRAININGLABS 2008 написал статью:
http://boatmanshome.ru/cgi-bin/page.pl?21dev_004.page

Прошу полемизировать

Ну что ты так сразу! Мы читаем медленно...

Благодарю всех принявших участие за море отзывов и конструктивной критики

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

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

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

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

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

Очень похоже на нашу ситуацию. Причем стоит такой голове уйти, и начинается маленький бедлам. Или кому-то придти: трудно понять, в каком месте проект находится, и с чего начать, и куда двигаться

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

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

- не включить в шаблоны документов ничего лишнего,

может не включить в шаблон документов лишнего?

Текст предельно однозначен

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

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

Непротиворечит ли данное утверждение сделанному анализу текста, как однозначного?

Резюме.
Статья интересная. В целом понятная. Но очень хотелось бы примеров. Можно предложить автору такую тему?
Нужно разработать минимальный набор документов по тестированию.
Обычно в тестировании выделяют:
план тестирования (шаблонов его я видел предостаточно, тем не менее не очень понимаю как же есго составить)
список требований и тестовых случаев (типа матрицы трассировки)
тестовые случая в виде описания сценариев. тестовые случая описывают цель тестирования, исходные данные, ожидаемый результат
протокол проведения тестирования и описание обнаруженных дефектов

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

Предлагаю начать например с тестовых сценариев....

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

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

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


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

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

- как будет выполняться само тестирование
  Предполагается разработать набор тестовых сценариев, полностью или частично (если тут работает правило Паррето) покрывающих систему (а для начала отдельную законченную задачу)
  По тестовым сценариям написать скрипты для автоматического исполнения их на базе TestComplete.
 Подготовить тестовый стенд.
  Тесты прогонять по расписанию после внесения изменений в тестовую базу или тестовое приложение
  Анализировать результаты тестов
  В случае выявления дефектов - направлять новую функциональность на доработку

Вот как-то так...