Что на самом деле покупают, оплачивая тестирование

Коротко. Заказчик просит «нормально протестировать», подрядчик закладывает в смету тридцать процентов на тестирование, и обе стороны имеют в виду разное. Тесты покупают не качество — качество определяется требованиями. Тесты покупают возможность менять систему быстро и не бояться.

Что стоит за словом «тестирование»

Уровень	Что проверяет	Кто пишет	Когда окупается
Модульные	Отдельные куски логики	Разработчик	Сразу, если система живёт дольше года
Интеграционные	Стыки между частями и с базой	Разработчик	Когда частей больше двух
Сквозные	Сценарий целиком, как у пользователя	Инженер по качеству	На ключевых сценариях, не на всех
Нагрузочные	Поведение под нагрузкой	Отдельная роль	Перед запуском и перед сезоном
Приёмочные	Соответствие тому, о чём договорились	Заказчик	Всегда

Последняя строка — единственная, за которую отвечает заказчик, и именно её чаще всего не делают.

Маршрут

Ступень	Что читаем	Что забираем	Срок
1. Основы	«Основы тестирования и верификации»	Словарь и уровни проверки	2 недели
2. Качество кода	Книги по чистому коду из подборки	Почему тестируемый код и понятный код — одно и то же	3 недели
3. Надёжность систем	«Безопасные и надёжные системы: лучшие практики проектирования»	Проверка не только функций, но и отказов	3 недели
4. Конвейер	Материалы по непрерывной интеграции	Как проверки встраиваются в выпуск	2 недели
5. Безопасность	«Стратегия обеспечения безопасности приложений»	Проверки, которые ищут не ошибки, а уязвимости	3 недели

Что это значит в деньгах

Ситуация	Без автопроверок	С автопроверками
Правка в системе возрастом два года	Ручная проверка соседних функций, срок непредсказуем	Двадцать минут конвейера
Смена подрядчика	Новая команда боится трогать код	Есть чем проверить, что ничего не сломано
Ошибка в продуктиве	Обнаруживает клиент	Обнаруживается до выпуска в большинстве случаев
Сезонная нагрузка	Узнаёте о пределе в час пик	Знаете предел заранее и планируете мощности

Шесть выводов — своими словами

Стопроцентное покрытие не цель. Покрытие измеряет, сколько строк выполнилось, а не сколько ошибок поймано; после определённого уровня оно растит стоимость без пользы.
Нестабильные тесты хуже отсутствующих. Проверки, падающие через раз, приучают команду перезапускать не глядя — и настоящая поломка проходит.
Сквозные тесты дороги в поддержке. Их держат на нескольких критичных сценариях, а не на каждом экране.
Тесты — это документация поведения. Для новой команды они часто понятнее, чем спецификация трёхлетней давности.
Приёмка — обязанность заказчика. Никакая автоматизация подрядчика не проверит, что сделано именно то, что нужно бизнесу.
Нагрузочное тестирование делают до запуска, а не после жалоб. Стоит день, экономит недели репутации.

Что записать в договор

Перечень сценариев приёмки — конкретных, а не «система работает корректно».
Требование, чтобы автоматические проверки передавались вместе с кодом.
Нагрузочный сценарий с числом одновременных пользователей.
Порядок действий при обнаружении ошибки после сдачи и срок исправления.

Частые вопросы

Сколько закладывать на тестирование

Ориентир — от пятой до трети объёма разработки в зависимости от цены ошибки. Ноль означает, что проверять будут пользователи.

Нужен ли отдельный инженер по качеству

На небольших системах — нет, достаточно дисциплины разработчиков. Отдельная роль появляется там, где есть сложные сквозные сценарии и регулярные релизы.

Как проверить, что тесты не фикция

Попросить показать отчёт конвейера за последний месяц: сколько прогонов, сколько падений, сколько времени занимает. Красивое покрытие при нулевой истории прогонов ничего не значит.

Связанное

Книги названы как источники. KZSalesHub не распространяет файлы изданий.

Тесты — не про поиск всех ошибок, а про уверенность вносить изменения. Команда, которая боится трогать код, платит за это скоростью каждый месяц.

Дальше по теме

Автоматизация рутины без разработчиков Данные как актив: маршрут от SQL до решений Как нанимать инженеров, если вы не инженер

Материал оказался полезным?