Создавайте eval‑кейсы без Python из тикетов и таблиц

Почему хорошая обратная связь редко попадает в тесты

Команды поддержки обычно видят проблему первыми. Клиент отправляет тикет, прикладывает скриншот и простыми словами объясняет, что пошло не так. В таком отчёте часто уже есть точные детали для будущего теста: тип аккаунта, необычный ввод, состояние экрана и ожидаемый результат.

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

Инженеры делают то, что должны: исправляют описанный случай, выпускают патч и идут дальше. Если никто не превратил тикет в повторяемый тест, команда решает один инцидент и пропускает шаблон.

Вот почему та же ошибка появляется снова через месяц после рефакторинга, обновления интерфейса или смены обработки данных. Исходный отчёт клиента содержал достаточно сигнала, чтобы защитить продукт, но он так и не вошёл в набор тестов. Люди какое-то время помнят баг, затем память тает, и приложение снова впадает в ту же ошибку.

Баг с импортом таблицы — частый пример. Поддержка может знать, что провал случается только когда в одном столбце смешаны даты и текст, и только для аккаунтов с определённым шаблоном. К моменту, когда баг доходит до инженера, история может сократиться до «ошибка импорта CSV». Этого недостаточно, чтобы поймать следующую регрессию.

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

Как выглядит полезный eval-кейс

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

Начните с одного пользователя, который пытается сделать одну вещь. Не объединяйте три проблемы в один кейс. Если клиент спросил «Почему в сводке нет даты возврата?», у вас уже есть хороший исход.

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

Опишите ожидаемый результат простыми словами. Пишите, что должен увидеть человек, а не как система должна это сделать. «В сводке указана дата возврата и итоговая сумма» понятнее, чем «модель извлекает все релевантные сущности».

Правило прохождения тоже должно быть простым. Продакт-менеджер, руководитель поддержки или аналитик должны смочь проверить его за пару секунд. Если ответ включает оба требуемых факта — проход. Если чего-то не хватает — провал.

Большинство хороших кейсов включают четыре вещи:

• короткое имя
• реальный ввод, который вызвал проблему
• желаемый результат простыми словами
• точное правило, по которому определяется проход или провал

Возьмём кейс из клиентской жалобы. Ввод — оригинальное сообщение: «Я вернул заказ 3 марта и до сих пор не получил возврат $84.20». Ожидаемый результат говорит, что в ответе или сводке должна упоминаться дата возврата и сумма возврата. Правило: провал, если не упомянута ни одна из этих деталей.

Этого достаточно. Если кейсу нужна встреча для объяснений, он слишком туман.

Где доменные эксперты найдут материал для тестов

Начните с доказательств, которым команда уже доверяет. Хорошие тестовые материалы обычно лежат там же, где люди сообщают о багах, объясняют крайние случаи и подтверждают, как продукт должен вести себя.

Тикеты клиентов часто — лучший источник. Они дают точные слова пользователей, шаги, которые они проделали, и ожидаемый результат. Очищённое продуктовое резюме часто убирает детали, которые сделали проблему реальной.

Таблицы — ещё один сильный источник, особенно когда команды отслеживают импорты, правила цен, утверждения или грязные данные аккаунтов. Одна странная строка с пустым полем, датой в неправильном формате или несоответствием валюты может стать надёжным повторяемым тестом. Скучные строки редко учат чему-то полезному. Угловатые — да.

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

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

Как превратить сырые доказательства в один повторяемый тест

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

Затем сузьте доказательство до одного действия пользователя и одного ожидаемого результата. Если в оригинале написано «экспорт не сработал после изменения диапазона дат и редактирования двух фильтров», не сохраняйте все побочные детали. Оставьте точный шаг, который, похоже, запускает проблему, и опишите, чего пользователь ожидал.

Перед сохранением удалите приватные данные. Замените имена, емейлы, ID аккаунтов, цены и всё, что указывает на реального клиента. Если нужен скриншот — обрежьте или размойте чувствительные части. Тест должен сохранять поведение, а не личность того, кто сообщил о проблеме.

Простой кейс обычно отвечает на четыре вопроса: откуда взялось доказательство, что сделал пользователь, какой результат он ожидал и какие редактирования или правки вы сделали.

Записка об источнике важнее, чем многие думают. Через шесть недель кто-то спросит: «Зачем нам этот тест?» Если в кейсе есть «на основе тикета 1842 из обзора биллинга в марте» или «взято из таблицы проблем при онбординге», ответ уже очевиден.

Держите формулировку простой, чтобы руководитель поддержки или продакт-менеджер мог обновить её без помощи инженера. Так непрофессиональные разработчики сохраняют полезность кейсов со временем.

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

Используйте формат, который могут редактировать не разработчики

Если для нового теста требуется файл скрипта, репозиторий и code review, большинство экспертов остановятся после первой попытки. Лучше формат — лист, таблица или доска, где каждый кейс живёт в одной строке или карточке.

Формат должен выглядеть как обычная работа, а не как программирование. Короткий шаблон обычно достаточен:

• scenario
• input
• expected result
• check

Эти поля просты по замыслу. «Scenario» объясняет ситуацию простым языком. «Input» содержит тикет клиента, промпт, заполненную форму или скопированное сообщение. «Expected result» говорит, что должен сделать корректный ответ или действие. «Check» превращает это в правило прохождения, например «упоминает срок возврата» или «не утверждает, что заказ отправлен».

Держите правило простым: один кейс — один вопрос. Если строка пытается проверять тон, соответствие политике, крайние случаи и форматирование одновременно, никто не будет понимать, почему кейс провалился.

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

Скриншоты тоже заслуживают места в кейсе, а не чтобы они терялись в чате или на чужом ноутбуке. Скриншот оригинального тикета, помеченное состояние UI или вставленный ответ часто проясняют детали, которые текст упускает. Храните доказательства рядом со строкой или карточкой, чтобы кейс оставался понятным через месяцы.

Делайте формат немного скучным. Так он обычно дольше живёт. Если руководитель поддержки или продакт-менеджер может обновить кейс за две минуты во время обзора, команда будет продолжать им пользоваться.

Простой пример из тикета клиента

Тикет поддержки часто содержит всё необходимое для полезного eval-кейса. Представьте, что клиент сообщает о неверной сумме в счёте после применения скидки. Он прикладывает детали заказа и обводит итог на скриншоте — это число, которое показалось неправильным.

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

Простой вариант кейса может выглядеть так:

• Item price: $120
• Quantity: 2
• Discount: 25%
• Tax: 10%
• Expected invoice total: $198

Теперь правило ясно. Система должна сначала посчитать подитог, применить скидку, затем добавить налог. Если продукт показывает $264 или $216 — кейс провален. Если $198 — проходит.

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

Почему этот пример работает

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

Его также легко поддерживать. Если правила ценообразования меняются, команда обновляет одно ожидаемое число или примечание к формуле. Тикет становится повторяемым тестом, а скриншот даёт будущим рецензентам быстрый контекст, когда цифры снова будут выглядеть странно.

Как скриншоты делают кейсы понятнее

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

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

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

Держите короткую запись рядом с изображением. Достаточно сказать, какой ввод или настройка привели к экрану, какую часть экрана проверять и какое значение или состояние должно присутствовать.

Без такой заметки изображение превращается в тест на память. Люди смотрят на него позже и догадываются, что нужно было заметить. Эти догадки убивают доверие.

Изображения сами по себе тоже могут ввести в заблуждение — их легко неверно прочитать. Два экрана могут выглядеть почти одинаково, но фактический вывод неверен. Значение валюты может отличаться на одну цифру. Статус может быть «Pending» вместо «Paid». Скрытое поле может влиять на результат, хотя внешний вид нормальный.

Короткая письменная формулировка это исправляет. Например: «Для типа счёта B и налогосвободного клиента итог показывает $0 налога и баннер предупреждения не появляется». Скриншот показывает, куда смотреть. Предложение говорит, что должно быть правдой.

Ошибки, из‑за которых команды перестают использовать eval-кейсы

Команды перестают доверять набору, когда он кажется беспорядочным, расплывчатым или устаревшим. Проблема обычно не в идее, а в том, как кейсы пишут и поддерживают.

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

Ещё одна проблема — слабые ожидаемые результаты. Если в ответе написано «выглядит правильно» или «кажется нормальным», кейс ничего не направляет. Двое рецензентов прочитают это по‑разному. Хорошие eval-кейсы используют простые, конкретные проверки: поле должно соответствовать, метка должна появиться или сводка должна включать один факт и исключать другой.

Некоторые ошибки повторяются:

• Один кейс пытается проверить несколько сбоев одновременно.
• Ожидаемый результат сформулирован расплывчато вместо чёткого правила прохождения.
• Команда сохраняет тест, но теряет тикет, строку таблицы или скриншот, с которого он начинался.
• Старые кейсы остаются активными после изменений в продукте, и набор наказывает текущее поведение за несоответствие старым правилам.

Проблема с отсутствием источника хуже, чем кажется. Через месяцы кто-то спросит: «Зачем мы это тестируем?» Если оригинальный тикет или скриншот не сохранены, кейс превращается в фольклор. Люди спорят об намерении вместо проверки доказательств.

Устаревшие кейсы не лучше. Команда обновила рабочий процесс, изменила форму или переписала тексты, а набор eval-кейсов остался прежним. Тогда тесты падают по неправильной причине. После нескольких таких циклов люди перестают смотреть результаты, считая, что половина провалов — шум.

Если вы хотите, чтобы люди продолжали пользоваться eval-кейсами, держите каждый кейс узким, прописывайте точные ожидаемые результаты, сохраняйте источник и пересматривайте старые кейсы по расписанию. Небольшой набор, которому доверяют, лучше большого набора, который все игнорируют.

Быстрая проверка перед публикацией кейса

Команды часто застревают на одной простой проблеме: кейс требует встречи для объяснения. Если руководитель поддержки, продакт-менеджер или операционный сотрудник не может быстро прочитать кейс и уверенно оценить его, он не готов.

Хороший кейс прост. Он называет источник, показывает ввод, указывает правильный результат и объясняет, почему это важно. Новому человеку на проекте должно быть понятно примерно за минуту.

Сделайте короткую проверку перед добавлением кейса в общую таблицу или библиотеку:

• Неинженер может один раз прочитать кейс и понять, что тестируется.
• Правило прохождения достаточно конкретное, чтобы двое рецензентов дали одинаковую оценку.
• Кейс взят из реального тикета, строки таблицы или письменного бизнес‑правила.
• Команда сможет прогнать кейс снова после каждого релиза без поиска потерянного контекста.

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

Реальный источник тоже важен. Кейсы из тикетов ловят ту боль, которую уже почувствовали пользователи. Кейсы из политик ловят тихие ошибки, которые ведут к возвратам, задержкам или проблемам с соответствием. Если кейс не из того и не из другого, он обычно превращается в работу ради работы.

Скорость повторного запуска — последний фильтр. Если кейс зависит от того, что кто‑то помнит старый скриншот, приватный чат или скрытую вкладку таблицы, он умрёт после двух релизов. Поместите ввод, правило оценки и заметку об источнике в одном месте.

Готовый кейс легко читать, легко оценивать и легко воспроизвести. Именно это позволяет небольшому набору выжить в реальной продуктовой работе.

Следующие шаги для процесса, который команда сохранит

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

Назначьте явного владельца списка вне инженерии. Чаще всего это поддержка, можно и продакт. Этот человек не обязан писать код. Ему нужно держать описания кейсов понятными, просить недостающие доказательства и следить, чтобы старые кейсы не накапливались вечно.

Небольшой ритм ревью работает лучше тяжеловесного процесса. Поставьте короткую встречу в календарь каждые две–четыре недели. Держите её простой. Если встреча кажется скучной — это обычно хороший знак.

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

Этого достаточно, чтобы рабочий процесс оставался полезным. Большинство команд не проваливаются из‑за слабого формата. Они проваливаются, потому что у списка нет владельца, его никто не ревьюит и его не чистят. Простая таблица или общий лист — отлично, если люди действительно обновляют её.

Если список растёт быстро, разделите владельцев по областям продукта, но сохраните единый формат. Кейсы по биллингу, поиску и рабочим процессам поддержки должны выглядеть знакомо на одной странице. Это упрощает передачу ответственности и сокращает споры о том, что именно проверяет тест.

Некоторым командам нужна помощь в настройке, чтобы поддержка, продукт и инженерия могли совместно поддерживать набор. Oleg Sotnikov на oleg.is работает со стартапами и малыми компаниями по практическим AI‑дополненным процессам разработки, архитектуре продукта и поддержке Fractional CTO. Если ваша команда застряла между тикетами клиентов и повторяемыми тестами, такая практическая настройка может сэкономить много времени.