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