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

Позиция понятна. Мало кого из тех, кто занимается разработкой (или тестированием разработок) интересует документация. Разработчики не любят её писать и читать. “Лучше в коде посмотрю”. Вообще людям с русским менталитетом инструкции “тяжело заходят” (“Убери ты эту бумажку. У меня два высших образования. Что я сам не разберусь чтоль?”). Что уж тут говорить про гремучую смесь - “русского разработчика”.

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

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

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

“Новенький” разработчик: А что вот это такое?

“Старенький” разработчик: В документации же всё написано…

“Новенький” разработчик: Что-то не нашёл такого.

“Старенький” разработчик: Да вот же здесь, помню было. Сейчас погоди, давай вместе посмотрим… Так… Хм… Действительно нет… А тут что-то совсем перепутано, кстати. Эх, вот этим мне сейчас совсем некогда заниматься, задач и так полно… Ладно, давай по коду смотреть…

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

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

Вывод простой.

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