Состав сметы: тестирование ПО
Вторая вещь, которую полезно проговорить заранее, — что тестирование не заканчивается однократной проверкой. Каждая правка разработчиков возвращает часть сценариев на повторный прогон, а перед релизом проходит регресс по всей ключевой функциональности. Количество прогонов и порядок повторных проверок после исправлений влияют на смету сильнее, чем число самих тест-кейсов, и это стоит показать в документе явно, а не выяснять после первой же волны исправлений.
Позиции и единицы измерения
- Изучение продукта и подготовка тест-планачас
- Разработка тест-кейсов и чек-листовтест-кейс
- Функциональное тестирование сценариясценарий
- Проверка вёрстки и отображения интерфейсаэкран
- Тестирование на устройстве из согласованной матрицыконфигурация устройства
- Проверка интеграций и обмена даннымиинтеграция
- Оформление и описание найденных дефектовдефект
- Повторная проверка после исправленийпрогон
- Регрессионное тестирование перед релизомпрогон
- Нагрузочное тестирование по согласованному профилюэтап
- Автоматизация проверок ключевых сценариевчас
- Отчёт о результатах тестирования за периодотчёт
Срок привязывайте к готовности сборки, а не к календарю: проверка начинается, когда версия развёрнута на тестовом стенде и доступна инженеру. Укажите длительность первичного прогона в рабочих днях и отдельно — срок регресса перед релизом. Оговорите, что задержка исправлений со стороны разработки сдвигает повторные проверки, а простой инженера в ожидании стабильной сборки согласовывается заранее.
Для разовой проверки удобна оплата по этапам: подготовка документации, первичный прогон, регресс. Для постоянного сопровождения релизов — ежемесячный пакет часов с переносом или сгоранием остатка по согласованию. Опишите отдельно, как оплачиваются повторные прогоны сверх включённого числа и срочные проверки вне рабочего графика.
Гарантируйте выполнение проверок в объёме согласованного тест-плана и корректное оформление найденных дефектов. Прямо укажите, что тестирование не гарантирует полного отсутствия ошибок в продукте: проверяются сценарии из плана и конфигурации из матрицы. Дефекты, найденные в функциональности вне согласованного объёма или на устройствах вне матрицы, к гарантийным случаям не относятся.
Блоки, смета с расчётом и условия уже готовы — останется вписать свои цены. Клиент открывает ссылку в браузере, а вы видите, кто её открыл и докуда дочитал.