ИИ написал автотесты. Кто проверил сами проверки?
Попросили ИИ написать автотесты. Получили код, запустили — всё зелёное ✅ Проверок стало больше. Можно спокойнее выпускать релиз? Есть один вопрос: что именно сейчас подтвердили эти тесты? Представим оформление заказа. Тест отправляет запрос и проверяет успешный ответ системы. Всё проходит. А скидка рассчитана неправильно. Тест не сломан. Он честно проверил то, что ему поручили. Просто правильность суммы в его задачу не входила. Самое интересное начинается, когда добавляем проверку суммы. ИИ видит формулу в коде приложения и воспроизводит её в тесте. Результаты совпадают. Но если в исходной формуле ошибка, тест может повторить её. Получается, программа согласна сама с собой — а соответствует ли расчёт условиям скидки, мы так и не выяснили. Это возможно и с тестами, написанными человеком. ИИ ускоряет создание проверок, поэтому особенно важно понимать, на чём они основаны. Я бы предложил задать три вопроса. 1. Откуда взялся правильный ответ? Из согласованного бизнес-правила и независимо рассчитанного примера? Или мы просто записали текущий результат работы системы как ожидаемый? Для скидки это конкретная сумма, которую можно объяснить условиями акции. 2. А при ошибке тест упадёт? Если в тестовой версии намеренно изменить расчёт скидки, заметит ли проверка разницу? Такую проверку полезно провести на выбранном критичном сценарии. Она даёт больше понимания, чем ещё один успешный запуск. 3. Можно ли доверять следующему запуску? Сегодня зелёный, завтра красный, после перезапуска снова зелёный — знакомо? Стоит разобраться, не зависит ли тест от чужих данных, порядка запуска или случайных задержек. Иначе команда постепенно привыкает игнорировать падения — вместе с ними можно пропустить настоящую ошибку. С чего начать на практике? Выбрать несколько важных сценариев: расчёт стоимости, оплату, возврат. Посмотреть, что именно проверяется, откуда взяты ожидаемые результаты и какие ошибки останутся незамеченными. При этом не нужно помещать всё в один огромный тест. Расчёт можно проверить отдельно, обмен между системами — интеграционными проверками, а ключевой путь клиента — сквозным сценарием. В Performance Lab при создании и аудите автоматизации мы помогаем разбирать именно такие вопросы: какие бизнес-сценарии покрыты, где проверок недостаточно и насколько надёжны их результаты. Зелёный отчёт полезен, когда понятно, что за ним стоит. Вы уже используете ИИ для создания автотестов? Как проверяете, что они действительно замечают ошибки? Поделитесь подходом в комментариях 👇 #АвтоматизацияТестирования #QA #ИИ #PerformanceLab
· вчера
К примеру со скидкой добавил бы граничные случаи из условий акции: сумма ровно на пороге, на копейку ниже и возврат части заказа. Ожидаемые суммы стоит согласовать отдельно от реализации — тогда тест проверяет договорённость с бизнесом, а не повторяет формулу из кода.
0
ответить
коммент скрыт — часть юзеров считает его токсичным или некорректным
коммент удалён
· вчера
Никита, спасибо за дополнение! Частичный возврат — показательный случай: прежде чем писать тест, нужно выяснить, что вообще должно произойти со скидкой. Несколько согласованных примеров с суммами здесь дадут ИИ гораздо более надёжную основу для проверок.
0
ответить
коммент скрыт — часть юзеров считает его токсичным или некорректным
ответ удалён