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

QA — это не «кто-то пощёлкал перед сдачей»

Распространённое представление владельцев бизнеса таково: качество — это когда один человек в последнюю неделю проекта открывает экраны и нажимает кнопки. Это очень небольшая — и наименее эффективная — его часть. Настоящее обеспечение качества — это система, работающая с первого дня: требования, сформулированные достаточно точно, чтобы их можно было проверить; код, покрытый автоматическими тестами, которые запускаются при каждом изменении; промежуточная (staging) среда, повторяющая рабочую; и путь развёртывания, который не пропустит изменение в рабочую среду, пока оно не пройдёт эти барьеры.

Практическая разница проста: в первом случае дефект проявляется через несколько минут после того, как его написали; во втором его находит ваш клиент месяц спустя, когда вы уже построили другие функции поверх той же ошибки.

Уровни тестирования, важные для вас как для руководителя

От вас не ждут знания технических деталей, но ждут понимания того, за что вы платите. Вот уровни, которые должно называть любое серьёзное техническое предложение:

  • Модульные тесты: проверяют мельчайшие фрагменты логики изолированно. Они самые быстрые и дешёвые, и именно они не дают небольшому изменению сломать итог счёта, скидку или расчёт налога.
  • Интеграционные тесты: проверяют, что части системы правильно взаимодействуют друг с другом и с внешними системами — платёжным шлюзом, доставкой, платформами выставления счетов, мессенджерами. Большинство реальных сбоев живёт именно здесь, а не внутри самого кода.
  • Сквозные тесты: имитируют полный путь пользователя от начала до конца — от открытия страницы до подтверждения заказа и получения уведомления.
  • Тесты производительности и нагрузки: отвечают на вопрос, на который не отвечает ни один другой тест: что произойдёт, если в одну и ту же минуту придёт тысяча пользователей, а не десять? Именно этот уровень команды пропускают, а потом система падает в день вашей крупнейшей кампании.
  • Тесты безопасности: поиск распространённых уязвимостей до того, как их найдёт кто-то другой. Практический ориентир — список критических рисков веб-приложений OWASP Top 10; его упоминание в плане тестирования — явный признак зрелости.
  • Приёмочное тестирование пользователями: вы и ваша команда прогоняете систему по своим реальным бизнес-сценариям, а не по идеальному сценарию, подготовленному разработчиком. Этот этап — ваша ответственность, и никакой приёмки не должно быть до него.

Почему дефект тем дороже, чем позже вы его находите

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

Автоматическое и ручное тестирование: когда что применять

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

Следите за тестовыми данными

Один вопрос многие команды пропускают без внимания: копирование рабочей базы данных в промежуточную среду, чтобы разработчики могли на ней тестировать. Это означает, что имена, телефоны и адреса ваших клиентов теперь находятся в среде с более широким доступом и более слабой защитой. Закон Саудовской Аравии о защите персональных данных, за соблюдением которого следит Саудовское управление по данным и искусственному интеллекту (SDAIA), регулирует обработку персональных данных независимо от того, как вы называете среду, в которой они хранятся. Решение простое и известное: синтетически сгенерированные данные или реальные данные, чувствительные поля которых замаскированы перед копированием.

Что потребовать от подрядчика до подписания

  • Письменный план тестирования в составе объёма работ, а не устное обещание, что «система будет протестирована».
  • Тесты, автоматически запускающиеся при каждом изменении через конвейер непрерывной интеграции, с блокировкой развёртывания при падении теста.
  • Промежуточную среду, отделённую от той, с которой работают клиенты, с чётким указанием, откуда берутся её данные.
  • Регулярный отчёт о покрытии, который читается и как процент, и как направление: растёт ли покрытие по мере роста системы или падает?
  • Гарантийный период после запуска, в котором определено, что считается дефектом, исправляемым бесплатно, а что — новым запросом на разработку.

Признаки того, что качеством в вашем проекте пренебрегают

Чтобы их заметить, не нужно техническое образование: каждое исправление ломает что-то другое, каждому развёртыванию предшествует заметное напряжение в команде, никто не решается трогать старый модуль, «потому что он работает и мы не знаем, на что это повлияет», а о сбоях сообщают ваши клиенты, а не ваш мониторинг. Это не отдельные проблемы — это симптомы отсутствия тестовой сетки, которая позволила бы команде вносить изменения уверенно.

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

Источники