Свой велосипед

Был на Highload++, слушал доклады.

В нескольких докладах про изменение/развитие существующих систем заметил общий вполне понятный и разумный шаблон рассказа: встретили проблему - осмотрелись вокруг - решили делать что-то своё - разработали свой "велосипед".

* Здесь и далее буду называть "уникальные решения и разработки" велосипедами. Не потому, что в них есть что-то плохое (они, наоборот, как правило весьма достойны и хороши), а во-первых для краткости; во-вторых чтобы различать в тексте "решения", которые ментальное усилие выбора из нескольких вариантов, и "решения", которые программные системы и разработки; в-третьих сами докладчики их так называли.

Доклады были совсем не про механизм принятия решений, так что в них больше говорили про устройство велосипедов, а не о том, почему решили их строить. Вот несколько мельком озвученных причин (не дословно):

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

Некоторые вообще никаких причин не упоминали, а просто рассказывали про свой велосипед.

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

Как водится, причин может быть несколько. Первые пришедшие в голову:

• Синдром not invented here
• Люди недоразобрались с уже существующими велосипедами
• Люди действительно столкнулись со специфической проблемой требующей своего специфического велосипеда

На самом деле, полагаю, чаще всего присутствуют все три причины в каких-то пропорциях.

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

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

Нужно потратить время и силы (вообще говоря - без гарантии успеха).

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

Плюс срочность проблемы давит на людей, склоняя их использовать прежде всего знакомые инструменты: если надо срочно, то трудно разбираться с новым и неизвестным, особенно когда видны варианты, как допилить то, что уже имеется. В этом есть и рациональное зерно: силы/средства так и так придётся потратить. И можно их тратить на доработку чего-то знакомого, а можно на поиск и освоение чего-то неизвестного (а потом всё равно доработку знакомого, чтоб новое и старое работали вместе). Первое может быть объективно затратнее, но второе кажется более рискованным и неопределённым.

Есть старая шутка про написание научных статей: вывод это то место, где автор устал думать. Утрированно, но не лишено правды.

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

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

XPath в картинках

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

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

Качественный субъективизм

Один из серьёзных нюансов с качеством ПО с точки зрения разработки: уровень этого самого качества в изрядной степени субъективен.

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

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

И да, отмечу, фраза "каждый легко найдёт оправдания и объяснит, почему налажал не он" не должна вводить в заблуждение. Злобные мудаки встречаются всё же не очень часто (ну или я избалован работой в продуктовой компании). Никто не стремится саботировать. Просто каждый работает так, как видит возможным. Через голову не перепрыгнешь. Если есть из критериев качества только и прежде всего соответствие требованиям, то от них и будет каждый отталкиваться. В меру своего формализма, бодрости, семейных радостей и физического здоровья.

SUT с человеческим именем

Допустим я тестирую продукт, который работает [в том числе] с "человеческими данными".

Где-то для чего-то указываются и хранятся имена, емейлы, логины, телефоны и тому подобное. Есть формы, где можно данные редактировать, потом эти данные где-то показываются и используются. Есть и прочие вещи, слабо связанные с этими данными, например, возможность давать пользователю разные права: тут не обойтись без объекта "пользователь", но всякие атрибуты вроде имени/телефона обычно не важны. Другими словами, при тестировании можно указать любую белиберду, которую система согласна принять.

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

Но с некоторых пор я стал чаще использовать данные похожие на настоящие имена, фамилии и адреса. Ибо не фиг. И это таки немножко помогает в тестировании.

Уважение к старшим

С легаси кодом не просто.

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

Это такой код, который, с одной стороны, хочется радикально улучшить, а с другой - лучше к нему не прикасаться.

Так вот знаешь, что? Уважай его.

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

Он окончательно устарел и пришло-таки время всё исправить? ОК, не вопрос, давай исправлять. Но смотри внимательно: шрамы на старом коде - это следы древних багов. Будешь небрежен - и те же баги повторятся уже в новом коде.

Это легаси. Уважай его.

Сказка о неразобранных автотестах

Жил был проект, а в проекте делали продукт, а у продукта была веб-морда, и нужно было ту веб-морду тестировать, и были автотесты ("Selenium" - подумал Штирлиц) для всех и всяческих сценариев. Автотесты регулярно запускали на свежих билдах, они достаточно быстро выполнялись и радовали всех "зелёными" результатами. "Красные" результаты быстро исследовали, чинили проблему, и каждый следующий запуск был "зеленее" предыдущего. Скоро сказка сказывается, да не скоро дело делается.

У меня есть друг, у которого есть друг, знакомый которого рассказывал про человека… На одном из местных TechTalk'ов зашла речь про автотесты, и выяснилось, что "в реальном мире это не работает". Тут нужен дисклеймер. Сам я на том техтолке не был, это мне коллега рассказал, как люди болью делились. Мол, продукты хорошие, автотесты тоже в целом есть, и запустить их не проблема. Проблема - разобрать результаты работы автотестов. Что выполнилось, что упало, где баг, где косяк автотеста - вот это всё. Не хотят люди результаты разбирать - неинтересно им как-то, что ли… И что с такими неразобранными результатами делать? Как заставить, нет "заставить" слово нехорошее, как мотивировать человека разобрать-таки результаты автотестов?

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

С другой стороны, если сесть и вспомнить, то - ну да, всё так. Разбирать автотесты - это не вдохновляет. Как возникает эта задача, так сразу хочется чем-то другим заняться. На такой случай всегда найдётся Важное Дело, Которое Надо Сделать. То есть проблема не совсем выдуманная, и как-то же её решают те, кто живёт в нереальном мире.
Итак, возможные решения, только здесь и сейчас, спешить узнать.
Возможны противопоказания, проконсультируйтесь со своей командой.

Разработка и Продажи

Продажи (падают из-за кулис на сцену и смирно лежат).
Разработка (выходит, спотыкается об Продажи и падает): Вот черт! Никак об Продажи!
Продажи    (поднимаясь): Мерзопакость какая! Отдохнуть не дадут! (Идут, спотыкаются об Разработку и падают). Никак об Разработку спотыкнулися!
Разработка (поднимаясь): Ни минуты покоя! (Идет, спотыкается об Продажи и падает). Вот черт! Никак опять об Продажи!
Продажи    (поднимаясь): Вечно во всем помеха! (Идут, спотыкаются об Разработку и падают). Вот мерзопакость! Опять об Разработку!
Разработка (поднимаясь): Хулиганство! Сплошное хулиганство! (Идет, спотыкается об Продажи и падает). Вот черт! Опять об Продажи!
Продажи    (поднимаясь): Это издевательство сплошное! (Идут, спотыкаются об Разработку и падают). Опять об Разработку!
Разработка (поднимаясь): Вот черт! Истинно что черт! (Идет, спотыкается об Продажи и падает). Об Продажи!
Продажи    (поднимаясь): Мерзопакость! (Идут, спотыкаются об Разработку и падают). Об Разработку!
Разработка (поднимаясь):  Вот  черт! (Идет, спотыкается об Продажи и падает за кулисы). Об Продажи!
Продажи    (поднимаясь): Мерзопакость! (Уходит за кулисы).
За сценой слышен голос Продаж: "Об Разработку!"
Занавес

P.S. Основано на вымышленных событиях

Связанные многочисленными ниточками

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

Ниже — перевод статьи «Dependency Management in a Large Agile Environment», опубликованной компанией Salesforce.com. В статье рассказано, как компания решала проблемы взаимодействия команд разработки на крупном проекте. Многие подходы выглядят очень полезными.

Стоит потратить пять минут на чтение.

Краткий обзор
Департамент разработки Salesforce.com включает в себя более 30 Scrum-команд, совместно работающих над общим кодом в одной и той же ветке системы контроля версий. Статья описывает методы, используемые salesforce.com для масштабирования Scrum-подхода и для управления межкомандными взаимосвязями.

100500 конфигураций.

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

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

Сомневаюсь, что можно как-то окончательно решить эту проблему пока продукт развивается; можно только попытаться уменьшить опасность и критичность пропущенных проблем (и – снизить вероятность их пропуска, да).

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

4k+ знаков про ТО

Тестовое окружение – неизменный спутник тестирования. Неважно, какое ПО мы тестируем, без разницы, какую используем методологию: если мы выполняем тест, то, как минимум, нам нужен объект тестирования в подходящем состоянии. И как только этот объект появляется, появляется и оно, тестовое окружение.

Тестовое окружение (ТО) может готовиться заранее, а может «возникать» прямо в момент выполнения теста. Разным проектам нужны разные ТО, что естественно. ТО меняется вместе с развитием продукта, требованиями к нему, бюджетом и пониманием роли тестирования. Короче, как водится, идеального-вообще ТО не бывает, бывает – адекватное здесь-и-сейчас, решающее текущие задачи при данных обстоятельствах (ну и желательно с каким-то заделом на обозримое будущее).

Привет, Аноним в поисках вопросов

Внезапно мне пришёл комментарий:

Анонимный прокомментировал(а) ваше сообщение:
Добрый день, Павел.
Решил себя попробовать в тестировании, как мне казалась вещь очень интересная (знания брал из знаменитой для тестировщиков книги Савина), устроился в компанию, которая разрабатывает свой програмный продукт, проработав меньше месяца сбежал, т.к.было настолько скучно (тестирование - черный ящик, метод назывался "свободный поиск").
О чем спрашивать работодателя, когда принимают на работу? какие вопросы задавать по тестированию (чтобы потом не было так скучно)?

Комментарий к комментарию получился длинноват, так что публикую его отдельным постом.

Новая версия доступна. Обновить?

В жизни приложений, помимо "просто работы", есть масса интересных, пусть и относительно редких событий.
Приложение должно корректно устанавливаться – и нам нужно проверять это.
Приложение должно корректно удаляться (а вдруг!) – и нам нужно проверять это.
Приложение должно корректно обновляться до новой версии – и нам… подождите-подождите… нужно проверять это!
Об апгрейдах и пойдет речь.

Всего лишь пара изменений

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

Но не всегда тестировщик заранее знает, что что-то в поведении продукта изменится. Приходит он на работу, берет свежий билд приложения и видит, что добавились/пропали/переехали контролы в GUI. Или поменялась очередность шагов визарда. Или изменилась давно привычная логика работы. Да мало ли что. А чтоб такие изменения планировались, он и не слышал. Баг писать? Или так и должно быть теперь?

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

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

И вопрос - как эти изменения контролировать?

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

Баг для лога

В предыдущем посте речь шла о пользе чтения логов при исследовании и описании дефектов ПО. Сегодня я хочу зайти немного с другой стороны.

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

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

Лог для бага

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

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

Поскольку тестировщикам по роду деятельности приходится много сталкиваться с различными проблемами в работе приложения, то мы должны уметь грамотно работать с логами. Если смотреть «снаружи», то вся эта грамотность сводится к паре простых правил.

Калибан с зеркалом

Уточняя цитату про Калибана, перечёл предисловие к "Портрету Дориана Грея". Не удержался и перетолмачил это предисловие в иных терминах. Получился своеобразный манифест о тестировании :)

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

Итак. 

Границы и края

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

Так, приглядываясь к рискам, которые могут возникнуть в работе, проще всего сперва посмотреть на крайние значения. Кстати нередко вокруг таких крайних значений ломаются копья в различных спорах на тему тестирования (и вообще разработки ПО). Несколько примеров:

Все тесты должны быть описаны так, чтоб их мог выполнить человек с улицы

против

Мы тестируем, а не мараем бумажки 

40 и 90

Как и многие до меня, однажды я задумался о звучании чисел 40 и 90 в русском языке. Почему они - "сорок" и "девяносто", а не "четыредесять" и "девятьдесять"? В том же английском языке все честно: forty и ninety. И у нас вроде бы должно быть так же, если сравнивать с другими числами: "пятьдесят", "семьдесят". Что не так с этими двумя?

Наверняка я не знаю, конечно; разные есть версии на этот счет. Приведу те, что мне самому кажутся интересными и правдоподобными.

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

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

Впрочем, речь не о числах, интересно другое. Замеченная "странность мира" (нелогичные названия чисел) позволила по-новому взглянуть на числа и связь их названий с историей страны. То есть, заметив странное и покопав в этом направлении, я узнал что-то новое.

Странности мира - отличный источник знаний о мире. 

Дефекты продукта - отличный источник знаний о продукте. 

Между роботом и обезьяной

Есть две точки зрения на тестирование, с которыми в свое время сталкивался практически каждый тестировщик. Первая - что тестировать может любой, ума тут не надо: сел и прокликал. Вторая - что вообще не надо тестировать людьми, надо просто автоматизировать все тесты и жить счастливо. Эти подходы, пожалуй, несколько, гм, наивные (кто-то все равно должен эти тесты придумать и описать; кто-то должен приглядывать за автотестами и анализировать результаты их работы, и так далее), но я сейчас не об этом. На деле, мне кажется, это одна и та же точка зрения. В обоих случаях как минимум предполагается, что можно описать тесты таким образом, что их успешно выполнит любой - хоть студент, хоть скрипт. Или в других терминах - хоть обезьянка, хоть робот. Года полтора назад Макс cartmendum Дорофеев устраивал доклад-состязание "Обезьянки против Роботов"; если вдруг кто не видел - рекомендую к просмотру. В докладе отлично сформулирована разница между этими "крайностями": "Обезьянки умеют немножко смотреть по сторонам. Роботы не могут смотреть по сторонам. Они могут смотреть в точку, но быстро и долго". Это существенное различие, которое позволяет в разных ситуациях выигрывать то Обезьянкам, то Роботам. 

На самом же деле ни Обезьянки, ни Роботы сами по себе практически ничего не умеют. Они не могут придумывать тест-кейсы и программировать роботов. Они способны учитывать только формальный критерий, описанный в тест-кейсе или скрипте, они не обращают внимания на контекст. Ну, почти не обращают: Обезьянки все-таки немножко глядят по сторонам и иногда замечают странное не предусмотренное тест-кейсами. Они не умеют задавать вопросы и разговаривать (хотя бы с гуглом). Они не стремятся понимать, как работает приложение, и почему после нажатия на кнопку с неба падает (или не падает) банан. Они не отвечают за результат. Чаще всего они не могут сообщить дополнительные сведения, если что-то сломалось. Они знают только о приложении и не работают с остальными составляющими продукта. Они ничего не помнят. У них нет своих суждений, предположений и ожиданий; есть алгоритм и результаты - ожидаемый и реальный. 

Коротко говоря - они не умеют думать. Роботы - совсем, Обезьянки - почти. И в этом смысле тестировщик круче и Обезьянки, и Робота в равной степени. Ну разве что Робот быстрее кликает. Зато тестировщик способен понять, что тут кликать вообще незачем. 

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

Если перефразировать слова Макса, то можно сказать, что тестировщик смотрит по сторонам, и делает это быстро и долго. Нужно смотреть "быстро", чтобы замечать больше дефектов (и не только в продукте :)). Нужно смотреть "долго", то есть постоянно, на всех этапах разработки. Не случайно одна из главных бед тестировщика - "замыленый взгляд".

Удачи вам, верных Роботов, смышленых Обезьянок и ясного взгляда.

О тестировании документации

Documentation is like sex: when it is good, 

it is very, very good; and when it is bad, 

it is better than nothing.

Dick Brandon

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

Отбросим случай, когда документация не тестируется вообще никогда и никем. Это крайний и маловероятный вариант, к тому же обсуждать тут особо нечего. Как мы тестируем документацию, если уж до этого дошли руки? 

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