Non-functional testing проверяет свойства, от которых зависит качество использования системы: скорость, устойчивость, безопасность, доступность, совместимость и другие характеристики. Заказ может успешно создаваться в идеальных условиях, но при реальной нагрузке ждать минуту, теряться после сбоя или становиться доступным чужому пользователю. Формально работающая функция ещё не гарантирует приемлемый продукт.
Для QA здесь важно перевести абстрактное «надёжно и удобно» в проверяемые условия. Хорошее нефункциональное требование связывает действие пользователя, окружение, нагрузку и измеримый результат.
Какие вопросы решает такое тестирование
Вместо одного универсального теста команда выбирает несколько направлений по риску продукта. Performance testing исследует время выполнения и поведение под нагрузкой. Reliability и recovery testing — устойчивость и восстановление. Accessibility testing — возможность пользоваться продуктом разными способами. Security testing проверяет защитные механизмы и нежелательные действия.
Границы терминов могут различаться между командами. Авторизация, например, имеет конкретную функциональную логику, но одновременно относится к security-проверкам. Полезнее договориться о требованиях и покрытии, чем спорить, в какой единственной колонке должен находиться тест.
Как сформулировать проверяемое требование
Фраза «экспорт должен быть быстрым» не даёт основания поставить Passed. Уточни объём данных, число одновременных экспортов, момент начала измерения, состояние кэша и допустимые ошибки. Затем согласуй порог с продуктом и инженерами.
Пример учебного требования: при пяти одновременных экспортах по 100 000 строк каждый файл формируется не дольше 60 секунд, содержит все ожидаемые строки и не замедляет открытие карточек выше согласованного порога. Это не отраслевой норматив: конкретные числа должны отражать ценность и ограничения вашего продукта.
Начинать с последствий, а не с инструмента
Для сервиса покупки билетов важны пики спроса, отсутствие двойного списания, защита персональных данных и восстановление бронирования. Для офлайн-редактора — сохранность черновика, синхронизация и работа при недостатке памяти. Набор проверок будет разным даже при похожем интерфейсе.
Составь цепочку «актив или сценарий → отказ → последствия → проверка». Например, выгрузка большого отчёта может занять весь пул соединений и остановить операции остальных клиентов. Тогда тест должен наблюдать не только экспорт, но и соседний пользовательский маршрут.
Окружение и данные определяют смысл результата
Нужны известная сборка, конфигурация, ресурсы, версии зависимостей и описание отличий от production. Если в тестовой базе тысяча строк, вывод о поиске на десяти миллионах записей не подтверждён. Если внешний сервис заменён мгновенным mock, нельзя заявлять проверку полного времени интеграции.
Данные должны отражать распределение и связи: короткие и длинные записи, крупные аккаунты, разный возраст объектов. Используй подготовленные синтетические или допустимо обезличенные наборы. После прогона сохраняй версию набора и способ его подготовки, чтобы следующий результат можно было сравнить.
Что измерять помимо времени
Одновременно наблюдай результат операции, ошибки, потребление ресурсов, очереди и состояние данных. Низкая latency при массовом отказе запросов не означает хорошую производительность. Быстро завершившийся экспорт без половины строк тоже не проходит тест.
Для доступности интерфейса измеримым исходом может быть выполнение маршрута с экранным диктором без недостижимых действий. Для восстановления — отсутствие потери подтверждённых записей в пределах согласованной модели и восстановление обслуживания за заданное время. Любая цифра нуждается в точном определении событий начала и окончания.
Практический пример: экспорт заказов
Подготовь аккаунт со 100 000 тестовых заказов, заранее сохрани ожидаемое число строк и контрольные суммы для выбранных полей. Зафиксируй базовую скорость открытия карточки без экспорта, затем запусти пять экспортов одновременно и продолжай открывать карточки независимым потоком.
- →Для каждого экспорта запиши время запроса, принятия задания, готовности и скачивания файла.
- →Сверь количество строк, уникальность ID, суммы и отсутствие заказов другого аккаунта.
- →Наблюдай очереди, занятые соединения, память и ошибки соседнего маршрута.
- →После завершения проверь, что задания не зависли и временные файлы очищаются по принятой политике.
Если файлы готовы за 45 секунд, но карточки стали открываться за 12 секунд вместо согласованных двух, требование не выполнено. Отчёт должен показывать оба результата, а не среднее время успешных экспортов.
Проверять деградацию и восстановление
Добавь управляемый отказ в согласованном тестовом окружении: например, временную недоступность хранилища готовых файлов. Проверь понятное состояние задания, ограниченные повторы и возможность продолжить работу после восстановления.
Отдельно оцени повторную отправку: создаётся ли новое задание, возобновляется ли старое, как пользователь видит результат. Неконтролируемые retries могут усилить исходный сбой. Завершай эксперимент проверкой целостности данных и возврата системы в рабочее состояние, а не только восстановлением HTTP 200.
Как распределить ручные проверки и автоматизацию
Повторяемые измерения и сравнение с порогами удобно автоматизировать. В pipeline можно включить проверку небольшого представительного сценария, а более тяжёлые исследования проводить в выделенном окружении по риску изменений. Время и нагрузка должны соответствовать цели, а не случайному расписанию.
Ручная работа остаётся важной для исследования, оценки понятности ошибок и сценариев доступности. Результат инструмента требует интерпретации: сигнал о контрасте, уязвимой зависимости или задержке становится полезным после проверки применимости и влияния на конкретный продукт.
Какие ошибки встречаются чаще всего
Частая ошибка — назначать требования после получения графиков. Ещё одна — сравнивать разные окружения как одинаковые или скрывать время прогрева внутри общей статистики. Проверка только идеального ответа пропускает деградацию, очереди и повреждение состояния.
Не пытайся подтвердить «всю безопасность» одним сканированием или «полную доступность» одним автоматическим аудитом. Область проверки должна быть явно ограничена. Непроверенный риск стоит записать отдельно: это информация для решения, а не недостаток отчёта.
Что должен вынести QA из этой темы
Нефункциональное качество начинается с пользовательского риска и заканчивается наблюдаемым доказательством. Определи сценарий, условия и критерии заранее, проверяй результат вместе с характеристиками системы и объясняй границы вывода. Тогда тестирование помогает решить, готов ли продукт к реальным условиям, и показывает, какое улучшение даст наибольший эффект.