Comments 17
Для какого уровня тест кейсов это подойдёт?
Непонятно как это тест кейсы смогут детально проработать, например, условия по настройкам окружения, в том числе протоколы авторизации и операционные системы. Иногда нужно более 200 кейсов для одного большого требования, которое включает в себя серверные настройки, домены, сертификаты.
Думаю что ИИ даже половину кейсов не составит с одного проста. Какой-нибудь частичный каркас матрицы покрытия, согласен что сэкономит несколько часов.
Мне больше помогает ии когда я вообще не знаю тему, но надо как-то протестировать. Так я знакомился с требованием на отказоустойчивость продукта.
По статье, есть ощущение того, что подобных статей уже много, конкретных примеров мало
Конкретно о тест-кейса в статье речи не шло. Требования действительно могут быть большие. Насколько подробно ИИ обработает это зависит от многих факторов. Влияет как конкретная модель, так и объем контекста, который в целом дан для ИИ. Допустим большой объем тестовых данных лучше сгенерирует клауд.
Конкретно мой проект как раз из таких сложных, где огромные требования и ТЗ. Для лучшего результата я разбиваю требования на части и уже с ними работаю с ИИ.
Например, фича включает какое-то количество доработок. Мы можем их раздробит по смыслу, страницам, ролевой модели. Все зависит от ситуации.
И начать постепенно вместе с ИИ тестировать. Сначала пишем чек-лист, потом уже выделяем блокеры и пишем с ИИ тесты. Тогда объем информации меньше и постепенно вместе с ИИ можно въехать в задачу.
Подходы могут быть разные, суть в том, что большие задачи лучше решать вместе с ИИ постепенно, дробя большой объем работы.
Честно я не придумала как дать больше конкретных примеров в статье. Потому что прошлая моя статья была как раз с примерами и в итоге утонула в ленте, так как многобукв не каждый может выдержать.
Суть статьи не дать конкретный подробный промт на каждую ситуацию с разбором, а показать в каких ситуациях можно использовать ИИ.
Спасибо за статью. А насколько усложняется дело когда допустим даем тз + несколько чеклистов + 10-20 тест кейсов. Как именно импортить в электронного друга всю историю с большим количеством разношерстных файлов удобно и быстро, и насколько он не теряет связность элементов при этом?
Хороший вопрос! На больших объёмах (ТЗ + чек-листы + пачка тестов) самое важное — структура, а не мощность модели.
Я обычно делаю так:
Даю документы частями — “Раздел 1: ТЗ”, потом “Раздел 2: чек-листы”, и т.д.
Ставлю жёсткое ограничение: “не придумывать, не дополнять, работать только с тем, что передано”.
Прошу сначала собрать карту связей — как элементы ТЗ соответствуют чек-листам/тестам.
Дальше иду шагами, а не одной командой.
При таком подходе модель не теряет связность: она работает как структурировщик, а не генератор. И ChatGPT/Claude обычно справляются с 10–20 документов нормально, если ввод аккуратно организован.
По п.1. То есть вы в эту цепочку глухого телефона — плохо описывающий задачу аналитик > плохо понимающий написанное тестировщик — добавили ещё одно звено, которое может свои галлюцинации привнести. Отличный план, надёжный как швейцарские часы!
Звучит как сценарий фильма ужасов, слава богу мой подход совсем о другом)
ИИ работает не вместо аналитика и не вместо тестировщика, а как инструмент для проверки того, что уже написано человеком.
Он не должен придумывать логику, а наоборот. В промте есть прямые ограничения: не придумывать, не заполнять пробелы, указывать, где информации недостаточно.
То есть это не новое звено в "глухом телефоне", а инструмент, который помогает увидеть ошибки в предыдущих двух звеньях.
Что должно помочь сделать ТЗ более полным и может подсветить моменты для обсуждения в команде. Ну по крайней мере на моей практике это работает именно так)
Да , с таким подходом вы далеко не уедете. Самая верный способ заставить ИИ плодить галлюцинации - дать ему повод симулировать роль. На простых задачах еще может и пройдет - но при работе со сложностями - сушите весла. Не в ту сторону идете...
Понимаю, о чём вы говорите, но в статье нет промтов вида “сыграй такую-то роль”.
Я просто дала названия сценариям, чтобы было понятнее, какую задачу они закрывают.
Суть не в ролях, а в том, какие рутинные задачи можно делегировать ИИ.
Все 5 методов в статье построены на другом принципе — ИИ работает только с фактическими данными, без домыслов:
1️⃣ Карманный аналитик — анализирует текст ТЗ и отмечает пробелы. Я отдельно прошу «не придумывать ничего сверх документа».
2️⃣ Личный секретарь — работает с расшифровкой созвона, то есть с реальным текстом.
3️⃣ Ревью тестов — сравнивает ТЗ и тест-кейсы, а не генерирует новые сценарии.
4️⃣ Матрица покрытия — превращает требования в таблицу. Это структурирование входных данных, не симуляция роли.
5️⃣ Импорт в TMS — форматирует существующие тесты в Excel-шаблон, без добавлений от себя.
То есть описанные методы, наоборот, снижают риск галлюцинаций, потому что модель работает в рамках чётких входных данных, а не “играет специалиста”.
Поэтому здесь критика немного мимо цели 🙂
Будучи тестировщиком, забабахал утилиту, которая в полуавтоматическом режиме проверяет требования и предлагает к ним тесты, с запросами к LLM. Гадость редкостная - галлюцинирует, игнорирует части промпта, на перепроверки и тюнинг к каждому требованию уходит непропорционально много времени. Если проект не самый тривиальный, проще и быстрее делать по-старинке руками, нейросети такую работу пока не тянут.
Да, ИИ действительно плохо справляется, когда от него ждут генерации логики “с нуля”.
Именно поэтому я использую другой подход: модель не придумывает тесты, а только структурирует факты, которые ей переданы (ТЗ, тесты, чек-листы, расшифровки созвонов).
В таких задачах галлюцинаций заметно меньше, и они реально экономят время, а не добавляют.
Для больших и объёмных требований у меня более подробный подход. Если интересно, я разбирала его тут (как раз на примере ТЗ и тестов).
Суть в том, что ИИ не просто "скармливают" требования, а объясняют, как именно их обрабатывать: что считать неполными требованиями, какие случаи нужно отдельно подсвечивать, где нельзя ничего додумывать.
То есть по сути мы пишем для ИИ не "сделай за меня", а что-то вроде кода с условиями:
в такой ситуации — делай А, в такой — Б, а если информации не хватает — честно скажи об этом.
А вам можно загружать техническое задание к коммерческому продукту в чужую нейросеть? Или у вас своя локально развернута?
У нас есть и корпоративная версия и локальная. Каждая для своих задач.
Допустим ChatGPT лучше пишет статьи, а Claude может махом работать с большим количеством данных.
Если покупается корпоративная версия (типа ChatGPT Enterprise / Claude Enterprise) или поднимается приватная/локальная модель в своём контуре (облако, VPC, on-prem) есть гарантии безопасности данных о проекте: договор с вендором, политика обработки данных, настройки безопасности и логирования и т.п.
И требования для ИИ уже будут внутренними данными, как для любого другого сервиса в инфраструктуре.
Спасибо за статью с примерами. Мне ещё пол года назад не очень понравилось работа с ИИ в качестве помощника а-ля ревьюера. Но получилось неплохо, применять техники тест дизайна с ее помощью. И она была просто идеальна в создании соковых ответов на основе данных о контракте из доки. Стоит отметить, что и качество ответов выросло за последнее время. Ждём следующую статью через полгода - год, интересно будет сравнить результаты работы ИИ в динамике.
Мне интересно какие промты используют от люди при юай автотестировании.
5 промтов, которые сэкономили мне часы рутинной работы тестировщика