Будешь ли закладывать тестирование в оценку проекта

Конечно, буду. И не просто закладывать, а считать тестирование одним из центральных и неотъемлемых столпов оценки проекта, бюджета и сроков. Рассматривать его как «опциональную» или «дополнительную» активность, которую можно сократить для экономии, — это прямой путь к рискам, перерасходам и провалу продукта.

Сама постановка вопроса указывает на очень распространённую дилемму в управлении проектами. Мой ответ основан на 10+ годах опыта и выглядит как стратегический подход с конкретными тактическими шагами.

Почему тестирование — обязательная статья в оценке

Тестирование — это не этап, а сквозной процесс, который не начинается и не заканчивается в какой-то конкретной фазе. Поэтому его оценка должна быть комплексной. Вот ключевые причины:

• Корректность базовой оценки: Если не заложить effort на тестирование, то оценка трудозатрат на разработку будет технически неполной и заведомо ложной. Это как оценить стоимость машины без колёс.
• Управление стоимостью качества (Cost of Quality, CoQ): В проекте всегда есть три вида затрат на качество:

    1.  **Профилактические (Prevention Costs):** Планирование, обучение, code reviews.
    2.  **Оценочные (Appraisal Costs):** Собственно тестирование (ручное, автоматизированное, нагрузочное).
    3.  **Затраты на устранение дефектов (Failure Costs):** Подразделяются на внутренние (поиск и исправление багов до релиза) и **внешние (после релиза)**. Последние — самые дорогие и включают техподдержку, хотфиксы, потерю репутации и клиентов.
    **Не закладывая «оценочные» затраты (тестирование), мы сознательно повышаем риск колоссальных «внешних» затрат на отказ.**

• Основополагающий принцип тройственной ограниченности (Triple Constraint): Любое изменение в требованиях (Scope) влияет на Time и Cost. Тестирование — это значительная часть Scope (объёма работ). Убрать его — значит нарушить баланс и создать иллюзию быстрого и дешёвого проекта, что вскроется на поздних стадиях.

Как именно я закладываю тестирование в оценку: практический подход

Я не использую абстрактный процент «на всякий случай». Оценка структурируется и обосновывается.

1. Декомпозиция и оценка по видам тестирования

Вместе с техническим лидом и QA-лидом я разбиваю тестовую активность на компоненты и оцениваю каждый:

Оценка тестовых активностей для модуля "Онлайн-оплата":
1.  Анализ требований и проектирование тестов (Test Design):
    - Создание чек-листов: 2 чел./дня
    - Написание тест-кейсов: 3 чел./дня
2.  Функциональное тестирование (Manual Execution):
    - Первичный прогон (Full Pass): 5 чел./дней
    - Регрессионные прогоны (3 итерации): 3 чел./дня каждая
3.  Автоматизация тестов (Automated Testing):
    - Разработка автоматизированных скриптов для 20 ключевых сценариев: 10 чел./дней
    - Поддержка и обновление скриптов: 2 чел./дня/спринт
4.  Нефункциональное тестирование (Non-Functional):
    - Нагрузочное тестирование (подготовка, прогон, анализ): 8 чел./дней
    - Тестирование безопасности (Security Scan/Pentest): внешний контракт, $XXXX
5.  Сопроводительные активности (Management & Support):
    - Настройка тестового окружения: 3 чел./дня
    - Отчётность и анализ дефектов: 1 чел./день/неделю
    - Участие в планировании: 0.5 чел./дня/спринт

Такой подход делает оценку прозрачной и доказуемой для заказчика.

2. Связь с моделью разработки и методологией

• В классической Waterfall тестирование выделяется в отдельную фазу, и его оценка должна быть детализирована в плане качества (Quality Management Plan).
• В гибких методологиях (Agile/Scrum) оценка тестирования встроена в оценку каждой пользовательской истории (User Story). Мы используем Definition of Done (DoD), где проверенные тест-кейсы — обязательный пункт.

  // Пример Definition of Done для User Story в бэклоге
  const definitionOfDone = {
      codeIsWritten: true,
      codeIsReviewed: true,
      unitTestsPassed: true,
      integrationTestsPassed: true,
      // Тестирование — обязательная часть "готовности":
      acceptanceTestsPassed: true, // Подтверждено QA-инженером
      uiAutomationUpdated: false, // Не готово, т.к. это не выполнено
      deployedToStaging: true,
      productOwnerApproved: true
  };
  

    Здесь видно, что без `acceptanceTestsPassed: true` история не считается завершённой, а значит, её нельзя оценить без трудозатрат на тестирование.

3. Работа с рисками и презентация оценки стейкхолдерам

Я всегда обсуждаю тестирование в рамках управления рисками:

• «Если нам сократить тестирование на 30%, мы экономим N человеко-дней, но повышаем риск P1/P2-дефектов в продакшене на 40%».
• Я предлагаю варианты: можно снизить полноту покрытия, но добавить автоматизацию в следующем релизе; можно отказаться от нагрузочного тестирования MVP, но заложить его в следующую фазу. Главное — решение должно быть осознанным и документированным.

Заключение: Позиция IT Project Manager

Буду ли закладывать тестирование в оценку? Не просто буду, а настаиваю на этом как на профессиональном стандарте.

Моя задача как PM — предоставить стейкхолдерам реалистичную и целостную картину. Оценка без тестирования — это неоправданный оптимизм, который ведёт к срыву сроков, конфликтам и, в конечном итоге, к более высоким затратам. Я закладываю тестирование как явную, структурированную, доказуемую статью расходов, обосновываю её необходимость и вместе с командой ищу оптимальный баланс между скоростью, стоимостью и качеством. Пропустить этот шаг — значит подвести и команду, и заказчика, и конечных пользователей.