В предыдущей заметке был затронут вопрос тестирования документации, точнее был дан краткий ответ на вопрос “Зачем тестировать документацию?”. Здесь же постараюсь ответить на следующий часто возникающий вопрос - “Кто должен тестировать документацию?”.

В первую очередь, конечно же данная задача ложиться на плечи непосредственно автора.

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

Итак, вернёмся к тестированию документации силами того, кто её разработал.

Как ни странно, этот шаг очень часто пропускается. И не только разработчики, у которых постоянно нет времени на “писанину”, и аналитики, которые тоже не горят желанием писать эксплуатационную документацию, но и сами технические писатели (в основном конечно начинающие) не вычитывают и не тестируют свои “произведения”. Причин может быть множество. Например, автор получил задание на разработку документации поздно и не успевает к очередному релизу, перегружен другими более важными задачами, не имеет достаточного опыта в этом ремесле, да просто его лень одолела опять же (“и так сойдёт” © - Вовка в тридевятом царстве). С большой долей вероятности, после этого в документации будет множество логических и грамматических ошибок.

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

Но и на этом ещё не конец.

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

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

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

Итак, мысль заметки следующая.

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

  1. обязательная тщательная вычитка (логика и грамматика) документа его автором;
  2. подключение “наблюдателя”, который свежим взглядом ознакомится с документом.

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