Ответ
Тестирование пользовательской документации проверяет материалы для конечного пользователя (руководства, справка). Тестирование проектной документации проверяет внутренние технические документы (ТЗ, спецификации).
| Критерий | Пользовательская документация | Проектная документация |
|---|---|---|
| Аудитория | Конечные пользователи. | Разработчики, тестировщики, менеджеры. |
| Цель тестирования | Проверить ясность, полноту, точность и удобство использования. | Проверить непротиворечивость, полноту, выполнимость и соответствие стандартам. |
| Фокус | Соответствует ли описание реальному поведению системы для пользователя? | Корректны ли и достаточны ли требования для реализации системы? |
Пример проверки пользовательской документации:
В руководстве написано: "Для сохранения отчета нажмите кнопку 'Экспорт PDF'." Проверка: Существует ли такая кнопка в интерфейсе и выполняет ли она указанное действие?
Пример проверки проектной документации:
В ТЗ указано: "Система должна поддерживать до 1000 одновременных подключений." Проверка: Является ли требование измеримым? Не противоречит ли оно другим требованиям по производительности?
Ответ 18+ 🔞
А, слушай, вот это тема, про которую все обычно забывают, а потом начинается: "А где тут, блядь, кнопка? В инструкции же написано!" Так вот, есть же два вида этих бумажек, которые надо проверять, как банку с огурцами на бомбу.
Тестирование пользовательской документации — это когда ты берёшь бумажку, написанную для бабушки из бухгалтерии или для дяди Васи с завода, и проверяешь, не обманули ли её. Руководства, справки — всё это. Тестирование проектной документации — это уже для своих, для внутренней кухни. Ты берёшь эти техзадания, спецификации и смотришь, не несут ли там авторы хуйню полную, которую невозможно реализовать.
| Критерий | Пользовательская документация | Проектная документация |
|---|---|---|
| Аудитория | Те, кто будет тыкать в интерфейс пальцем, иногда криво. | Те, кто этот интерфейс будет делать, тестировать и за него отвечать. |
| Цель тестирования | Убедиться, что написано понятно, ничего не утаили и не наврали. | Убедиться, что требования не противоречат друг другу, их вообще можно сделать, и они написаны не на коленке. |
| Фокус | А работает ли эта ваша система так, как вы тут моей бабушке пообещали? | А не долбанулись ли авторы, когда это писали? Можно ли по этому тексту вообще что-то построить? |
Вот смотри, пример для пользовательской бумажки:
Написано в мануале: "Для сохранения отчета нажмите кнопку 'Экспорт PDF'." Что делаем: Идём в интерфейс, ищем глазами эту кнопку. Нету? Ну всё, пиздец, автор документации — пидарас шерстяной. Есть? Жмём. Вылетает ошибка? Автор документации — пидарас шерстяной. Всё работает? Ну, бывает и такое, ебушки-воробушки.
А теперь пример для внутренней, проектной хрени:
В Техническом Задании гордо указано: "Система должна поддерживать до 1000 одновременных подключений." Что делаем: Первый вопрос — а как это, блядь, проверить-то? "Поддерживать" — это что, они просто могут подключиться и висеть, или что-то делать? Это требование — говно, потому что неизмеримое. Второе — смотрим другие пункты. А там: "Сервер — старенький ноутбук Василия Петровича". Ну, ёпта, ядрёна вошь! Противоречие на лицо. Вот на этом этапе и надо орать, а не когда всё уже написано и не работает.