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