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