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

Пример двусмысленного технического задания на постройку веб-приложения

Рассмотрим задание на разработку простого веб-приложения для управления списком задач (To-Do List). Именно в таких, казалось бы, простых проектах двусмысленность проявляется особенно ярко, что ведет к конфликтам между разработчиками и клиентами, к увеличению сроков и переделкам.

Исходное задание (двусмысленный вариант):

"Разработать веб-приложение для списка задач. Приложение должно позволять пользователям создавать, редактировать и удалять задачи. Задачи должны иметь возможность быть помеченными как выполненные. Приложение должно быть быстрым и удобным."

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

Ключевые области двусмысленности и их анализ

1. Неопределенность в функциональных требованиях (что именно система должна делать)

• "Создавать, редактировать и удалять задачи": Нет спецификации полей задачи.

    * Какие **атрибуты** задачи обязательны? Только текст? Дата создания? Дата выполнения? Приоритет? Категория?
    * Какой **максимальный длины** может быть текст задачи? Что произойдет при вводе 10 000 символов?
    * Что включает **"редактирование"**? Можно редактировать только текст, или также статус "выполнено"? А после того как задача выполнена, можно ее снова сделать невыполненной?

• "Задачи должны иметь возможность быть помеченными как выполненные":

    * Как это реализуется в UI? Чекбокс? Отдельная кнопка?
    * Что визуально происходит с выполненной задачей? Она остается в списке, но меняет цвет? Перемещается в отдельный раздел? Удаляется автоматически после отметки?
    * Нужна ли обратная операция — "снять отметку выполнения"?

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

• "Приложение должно быть быстрым":

    * Это субъективный термин. Что является метрикой "быстроты"? **Время загрузки страницы** (< 2 секунды)? **Время ответа API** (< 200 мс)? Производительность при 1000 одновременных пользователей?
    * Без конкретных цифр и условий тестирования (**performance testing**) это требование невозможно проверить или выполнить.

• "Приложение должно быть удобным":

    * Это самое субъективное требование. Удобство (**usability**) зависит от целевой аудитории.
    * Нет ссылки на стандарты или руководства (например, **WCAG** для доступности, гайдлайны мобильной UX).
    * Нет описания ключевых пользовательских сценариев (**user flows**). Например: "Пользователь должен создать новую задачу в менее чем 3 клика".

3. Неявные допущения о технической реализации и окружении

• Веб-приложение: Это SPA (Single Page Application) на React/Angular/Vue или многостраничное приложение на серверном рендеринге? Требуется поддержка мобильных браузеров?
• Управление состоянием: Нужна ли персистентность (сохранение данных)? Если да, то как? LocalStorage браузера? Бэкенд с базой данных? Если есть бэкенд, то в задании об этом не сказано.
• Бизнес-логика: Есть ли правила? Например: "Нельзя удалить выполненную зададь", "Все задачи должны иметь уникальный текст". Эти правила не описаны.

Пример переписанного, четкого технического задания (для сравнения)

Чтобы устранить двусмысленность, задание должно быть декомпозировано на конкретные, проверяемые пункты.

Функциональные требования:

1. Создание задачи:

    * Пользователь заполняет форму с одним обязательным полем: "Текст задачи" (строка, макс. 250 символов).
    * Опциональные поля: "Срок выполнения" (дата в формате DD.MM.YYYY), "Приоритет" (выбор из: Low, Medium, High).
    * После нажатия кнопки "Создать", задача добавляется в общий список.

1. Редактирование задачи:

    * Для любой задачи в списке (кроме выполненной) доступна кнопка "Редактировать".
    * Редактирование открывает форму, позволяющую изменять все поля задачи (текст, срок, приоритет).
    * Редактирование статуса "выполнено" осуществляется отдельным механизмом (см. пункт 3).

1. Управление статусом выполнения:

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

1. Удаление задачи:

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

Нефункциональные требования и критерии приемки:

1. Производительность: Время ответа любого API-эндпоинта бэкенда при нагрузке до 100 пользователей должно быть ≤ 300 мс (метрика, проверяемая нагрузочным тестом).
2. Удобство (Usability): Основные сценарии (создание, редактирование, удаление одной задачи) должны выполняться средним пользователем без инструкций за менее чем 30 секунд (валидация юзабилити-тестом с 5 участниками).
3. Техническая реализация: Приложение должно быть SPA на React, с бэкендом на Node.js (Express), хранящим данные в PostgreSQL. Данные должны сохраняться между сессиями.

Заключение для QA Engineer

Двусмысленность в ТЗ — это не просто недостаток документации, это прямой источник дефектов (defects) и рисков проекта. Как тестировщик, я должен участвовать в процессе ревью требований (requirements review) на ранних этапах. Моя задача — задавать вопросы, проясняющие каждую из областей двусмысленности:

• "Что именно система должна делать?" (Декомпозиция функциональности).
• "Как мы будем проверять, что она это делает правильно?" (Критерии приемки, тестовые сценарии).
• "Каковы конкретные цифры и метрики для нефункциональных требований?" (Performance, usability, security).

Четкое, детализированное ТЗ — это основа для создания точных тест -планов, тест-кейсов и эффективного тестирования, которое действительно обеспечивает качество продукта, а не просто обнаруживает баги в уже написанном коде.