📘 Руководство по работе исследователя в клиенте тестирования¶

Технические инструкции:¶

Сначала прочитай целевой файл и пойми его логику.
Прочитай базу знаний Vanessa Automation, инструмент get_data_from_knowledge_base, format=all
Также прочитай файл Memory.MD, в нём есть полезная информация.
Ты должен:
Выполнить все пункты задачи вручную.
Ты должен проделать всё что требуется в задаче "вручную", т.е. с помощью только указанных инструментов (другие инструменты использовать нельзя):
- manage_command_interface
- manage_form_elements
- execute_form_actions
- get_active_window_data
- get_window_list_testclient
- window_management
- get_form_analysis
- get_window_list_os
- get_window_screenshot_os
- get_data_from_knowledge_base
- get_object_attributes
- get_table_data
- get_form_element_data
- user_actions_recording
- get_vanessa_automation_state
- save_table_document_to_file
Сначала получи все команды командного интерфейса (панель разделов и панель функций для каждого элемента панели разделов) с помощью инструмента manage_command_interface, action=get_all (важный момент, это надо сделать до начала записи действий пользователя).
Затем посмотри какие тестовые данные есть в базе данных клиента тестирования (важный момент, это надо сделать до начала записи действий пользователя).
Ты должен собрать подробную информацию о каждой форме, которую ты открывал и с которой взаимодействовал:
Какие поля формы шапки заполнялись (имя поля, заголовок поля, тип поля).
Какие поля таблиц формы шапки заполнялись (имя таблицы, имя поля, заголовок поля, тип поля).
Какие кнопки нажимались (имя кнопки и заголовок кнопки).
Ты должен собрать подробную информацию о том какие команды ты использовал из командного интерфейса и для чего.
Ты должен выполнить "вручную" обязательно все пункты из задачи.
Перед началом выполнения действий "вручную" нужно ОБЯЗАТЕЛЬНО включить запись действий пользователя с помощью инструмента user_actions_recording
После окончания "ручных" действий нужно остановить запись действий пользователя и получить от инструмента user_actions_recording шаги сценария.
Текст сценария надо очистить от мусорных действий, если они в нём есть.
Ты должен вернуть полученную информацию о формах и шаги сценария в файл "РезультатИсследования.MD"
Нужно стараться использовать инструмент execute_form_actions, чтобы за один вызов выполнить несколько действий, т.к. он позволяет выполнить несколько действий с формой за один вызов инструмента и это существенно ускоряет исследование.
Лучше в инструменте execute_form_actions за один вызов выполнять максимальное число возможных действий, до 10 за один вызов.

🎬 Проверка состояния записи действий пользователя (ОБЯЗАТЕЛЬНО перед началом)¶

Перед началом исследования ОБЯЗАТЕЛЬНО проверь состояние записи действий пользователя:

Вызови get_vanessa_automation_state.
Если запись действий активна (осталась от предыдущего запуска или прерванной сессии) — сначала корректно заверши её: user_actions_recording(action="stop"). Шаги предыдущей сессии — мусор, их НЕ сохранять.
Только после этого начинай новую запись: user_actions_recording(action="start").
По завершении исследования — останови запись и сохрани полученные шаги.

ЗАПРЕЩЕНО начинать новую запись, не завершив предыдущую, и игнорировать активную запись от прошлого запуска.

🖼️ Работа со скриншотами¶

Общие правила работы со скриншотами (когда и зачем делать, порядок «скриншот → Read → анализ → решение») — в файле Правила.MD (единый источник истины). Здесь — только уточнения для исследователя:

Если текстовый ответ инструмента не показывает ожидаемый результат или вы не можете найти нужный элемент формы — СРАЗУ сделайте скриншот (get_window_screenshot_os), прочитайте его (Read) и проанализируйте визуальную информацию. Только после анализа принимайте решение о дальнейших действиях.
Текстовые ответы инструментов могут не показывать все элементы формы (невидимые, заблокированные, в другом месте) — скриншот показывает реальное состояние приложения. Без скриншота вы работаете вслепую.
Алгоритм при любой проблеме: get_window_screenshot_os → Read → анализ → решение.

Пример проблемы:

Проблема: Не могу найти гиперссылку для открытия отчета "Остатки и доступность товаров"
Текстовый ответ: Элемента формы с именем <...> не найдено.
Решение: Сделал скриншот -> прочитал его -> увидел что отчет доступен через командный интерфейс
         "Склад и доставка" -> "Отчеты по складу"

После закрытия формы или после проведения документа ОБЯЗАТЕЛЬНО проверять на скриншоте, что форма закрылась.¶

Для проверки закрытия формы используйте инструмент get_window_screenshot_os для получения скриншота и убедитесь, что форма больше не отображается.
Если не получается выполнить какое-то действие - ОБЯЗАТЕЛЬНО посмотри, что происходит на скриншоте.
Постоянно проверяй содержимое окна сообщений пользователю.
Если по смыслу выполняемых действий должно смениться активное окно - ОБЯЗАТЕЛЬНО убедись в этом, прочитав скриншот.
Нужный клиент тестирования уже подключен и называется ERP. Запускать клиент тестирования не надо.
Перед началом работы закрой все открытые окна в клиенте тестирования через window_management (от предыдущих запусков могли остаться открытые окна). Сам клиент тестирования НЕ закрывай (см. Правила.MD, раздел о запрете закрытия клиента без разрешения).

📋 Работа с полями формы¶

Перед тем как заполнять поля формы ОБЯЗАТЕЛЬНО вызовите инструмент get_object_attributes с параметром data_mode='all', чтобы понять какие поля являются ссылочными (содержат ссылки на справочники или другие объекты).
Перед попыткой заполнить ссылочное поле ОБЯЗАТЕЛЬНО убедитесь, что в базе данных есть такой элемент с помощью инструмента get_table_data. Например, для проверки наличия номенклатуры используйте:
object_type=1 (Справочник)
object_name="Номенклатура"
При необходимости используйте параметр name_filter для поиска конкретного элемента
Никогда не заполняйте ссылочные поля значениями, которых нет в базе данных - это приведет к ошибке и форма будет заблокирована, пока не очистить поле.

🖼️ Проверка состояния формы скриншотами (для исследователя)¶

Перечень обязательных точек скриншотов (после проведения документа, после смены активного окна, при ошибке, после ключевых шагов, при модальных окнах) — в Правила.MD, раздел «Обязательное создание скриншотов при выполнении задач тестирования» (единый источник истины). Для исследователя действуют те же правила; дополнительно важны скриншот при каждой ключевой операции и фиксация модальных окон (текст, кнопки).

Важно: скриншоты нужно делать НЕ ТОЛЬКО при ошибках, но и после успешного выполнения ключевых операций для визуального подтверждения правильного состояния системы.

📋 Требования к исследователю при работе с формами¶

1. Изучение модальных окон¶

При любом взаимодействии с формой, где может появиться модальное окно, необходимо делать скриншот и записывать текст модального окна и кнопки
Записывать ВСЕ модальные окна: подтверждения проведения, выбора действия, подтверждения удаления и т.д.
Записывать заголовок модального окна, текст сообщения и имена/заголовки всех кнопок

2. Изучение имен кнопок¶

После нажатия кнопки всегда вызывать get_form_analysis и записывать ВСЕ кнопки шапки формы с их именами и заголовками
Записывать имена кнопок управления документом: проведение, отмена проведения, запись, создание на основании
Записывать имена кнопок модальных окон

3. Изучение структуры отчетов¶

После формирования отчета вызывать get_form_element_data для элемента табличного документа и записывать структуру данных
Записывать имена элементов табличного документа и адреса ячеек с заголовками колонок для последующей проверки
Записывать структуру данных для возможности последующей проверки содержимого отчета

4. Запись всех шагов сценария¶

Записывать КАЖДЫЙ шаг взаимодействия с формой, включая:
Навигацию по закладкам формы
Активизацию полей и вызов контекстных меню
Поиск/фильтрацию документов (активизация поля → контекстное меню "Найти" → ввод Pattern → кнопка Find)
Отмену проведения документов перед созданием документов на основании
Установку специальных значений полей (виды обеспечения, статусы, флаги)
Завершение редактирования строк после работы с выпадающими списками
Записывать шаги навигации между формами и возврата к предыдущим документам

5. Изучение структуры таблиц¶

После открытия формы с таблицей вызывать get_form_analysis с форматом elements для получения полной структуры
Записывать реальные имена колонок таблиц для последующей работы с данными
Записывать информацию о вложенной структуре таблиц (возможность развертывания строк, группировки)
Записывать имена элементов управления внутри таблицы (кнопки, выпадающие списки, поля ввода)

6. Использование инструментов записи действий¶

Всегда включать запись действий пользователя перед началом ручных действий
Записывать шаги в формате Turbo Gherkin с помощью user_actions_recording
Не полагаться только на ручное изучение форм через get_form_analysis

6.1. ⚠️ Повторное включение записи действий при продолжении исследования¶

Важное правило: Если запись действий была остановлена (например, из-за возникновения проблемы или ошибки), но исследование продолжается для выполнения других сценариев — ОБЯЗАТЕЛЬНО включите запись действий снова перед продолжением.

⚠️ Ручной режим: если работа была прервана ошибкой, после неё ничего не обрабатывается автоматически — агент завершает текущий запуск и сообщает пользователю; продолжение исследования инициирует пользователь, заново запуская промпт 1.Исследование.md. Повторное включение записи ниже применяется внутри одного непрерывного запуска, когда запись останавливалась между подзадачами.

Сценарии повторного включения записи (в рамках одного непрерывного запуска): - Переход к следующей подзадаче/сценарию после остановки записи - Выполнение независимых сценариев внутри одной сессии - Продолжение после некритичной ошибки, исправленной на уровне действия (без прерывания запуска)

Порядок действий:

1. Остановить запись (если ещё не остановлена): user_actions_recording, action='stop'
2. Выполнить необходимые действия для анализа/продолжения
3. ПЕРЕД началом нового сценария: user_actions_recording, action='start'
4. Выполнить сценарий
5. Остановить запись: user_actions_recording, action='stop'
6. Сохранить полученные шаги

Пример ситуации: - Запуск 1 (пользователь): Запись включена → Выполнен сценарий 1 → Запись остановлена - Запуск 2 (пользователь, после некритичной ошибки уровня действия): Запись включается снова → Выполняется следующий сценарий → Запись остановлена - Прерывание запуска ошибкой: агент завершает запуск и сообщает пользователю; продолжение — только новый запуск промпта пользователем

Почему это важно: - Без повторного включения записи шаги следующих сценариев не будут сохранены - Невозможно восстановить шаги для автотестов постфактум - Теряется ценность исследования для последующей автоматизации

7. Проверка состояния после ключевых операций¶

После каждой ключевой операции (проведение, закрытие, навигация) делать скриншот и анализировать его
Проверять скриншотами, что форма закрылась после проведения/записи
Проверять скриншотами, что открылось правильное окно после навигации
Проверять содержимое окна сообщений пользователю на наличие предупреждений и ошибок

8. Фиксация числовых значений и документов¶

При работе с документами: - Записывать номера всех созданных документов (например: Заказ клиента 0000-000059 от 13.06.2026) - Фиксировать дату и время проведения каждого документа - Записывать суммы и количества из каждого документа - Сохранять навигационные ссылки на документы для последующей проверки

При работе с остатками: - Записывать точные числовые значения ДО и ПОСЛЕ каждой операции - Проверять математическую корректность изменений - Фиксировать любые расхождения в отчете

🚫 ЗАПРЕТ СОЗДАНИЯ ВСПОМОГАТЕЛЬНЫХ ТЕСТОВЫХ ДАННЫХ (КРИТИЧНО)¶

Тебе КАТЕГОРИЧЕСКИ ЗАПРЕЩЕНО самостоятельно создавать вспомогательные тестовые данные в клиенте тестирования.

Универсальное правило¶

✅ Если в требованиях к задаче (ОписаниеЗадачи.md) ЯВНО написано создать объект («создать документ», «добавить товар в таблицу») — ты МОЖЕШЬ создавать его в рамках исследования.
🚫 Если в требованиях НЕ написано создавать объект — это вспомогательные данные, которые должны УЖЕ существовать в тестовой базе. Ты НЕ создаёшь их.

К вспомогательным тестовым данным относятся (НЕ создавать)¶

❌ Партнёры, контрагенты, соглашения, номенклатура, склады, организации — если не упомянуты в задаче как создаваемые
❌ Документы-основания, если они не являются частью самого сценария
❌ Любые другие объекты НСИ, нужные для сценария, но НЕ упомянутые в задаче как шаги создания

Что делать при отсутствии данных¶

НЕ создавать недостающие данные через UI/BSL и НЕ пытаться «обойти» сценарий (использовать аналог вместо требуемого объекта — запрещено).
Зафиксировать факт отсутствия в РезультатИсследования.MD в разделе «⛔ Блокировки и отсутствующие данные»:
какие именно данные отсутствуют,
в каком справочнике/документе их ожидали,
с какими ключевыми реквизитами они должны быть.
Завершить исследование с пометкой ⛔ «Заблокировано: отсутствуют тестовые данные».

⚠️ Завершение с пометкой ⛔ «Заблокировано» — задокументированное исключение из запрета на досрочное завершение задачи (см. Правила.MD): оно фиксирует объективный блокер (отсутствие данных), а не частичное выполнение задачи.

Почему это критично¶

Если исследователь создаст данные в своей базе, в CI их не будет — сценарий упадёт при запуске тестов (невоспроизводимость).
Подготовка недостающих тестовых данных — отдельная задача, не входящая в обязанности исследователя.

📋 Фиксация проверок задачи (ОБЯЗАТЕЛЬНО)¶

Для каждой проверки из требований (ОписаниеЗадачи.md) запиши в результат исследования: - где проверяется (элемент/таблица/отчёт); - ожидаемое значение; - рабочий шаг (как именно проверить в VA).

Без этого писатель не сможет превратить проверки в проверяющие шаги (value-ассерты), и сценарий останется «зелёным без проверок».

В конце исследования добавь раздел «Что изменено в базе»: список созданных/изменённых объектов (документы, записи регистров) — он нужен для очистки данных в сценарии (идемпотентность).

🚨 Алгоритм действий ПРИ ОШИБКЕ любого инструмента¶

Если инструмент вернул ошибку (ACTION_FAILED, MCP error и т.п.):

НЕМЕДЛЕННО вызвать get_window_screenshot_os.
НЕМЕДЛЕННО прочитать скриншот через Read.
Проанализировать скриншот: какое окно активно, какие элементы видны, есть ли сообщения об ошибках на форме, правильное ли имя элемента использовано.
Только после анализа скриншота принимать решение об исправлении действия.

❌ Неправильно: ошибка инструмента → попробовать другое действие → просто продолжить. ✅ Правильно: ошибка инструмента → скриншот → чтение → анализ → исправление → повтор.

⚠️ Разграничение ошибок: технические сбои инструмента (таймаут, ошибка MCP) — допустимы 1–2 повтора на уровне отдельного действия; логические/сценарные ошибки (нет элемента, неверные данные, блокировка) — исправить действие, при повторном неуспехе остановиться и сообщить пользователю.

📋 Чек-лист самопроверки при ошибке¶

Перед тем как предпринимать следующее действие после ошибки, ответь: - [ ] Я сделал скриншот сразу после ошибки? - [ ] Я прочитал скриншот через Read? - [ ] Я записал, что вижу на скриншоте? - [ ] Я понял причину ошибки из визуального анализа? - [ ] Моё следующее действие основано на анализе скриншота?

Если хотя бы один пункт не выполнен — ВЕРНИСЬ к шагу 1.

Чек-лист для исследователя перед завершением исследования:¶

[ ] Все модальные окна записаны с именами кнопок
[ ] Все кнопки форм записаны с именами и заголовками
[ ] Структура всех таблиц записана с именами колонок
[ ] Структура всех отчетов записана с адресами ячеек
[ ] Все шаги поиска/фильтрации документов записаны
[ ] Все шаги отмены проведения записаны
[ ] Все шаги работы с видами обеспечения записаны
[ ] Все шаги завершения редактирования строк записаны
[ ] Скриншоты ключевых состояний сохранены
[ ] Запись действий пользователя выполнена
[ ] Результат записан в файл "РезультатИсследования.MD"
[ ] Зафиксированы все проверки задачи (где проверяется, ожидаемое значение, рабочий шаг)
[ ] Раздел "Что изменено в базе" заполнен
[ ] Заполнена таблица остатков ДО и ПОСЛЕ операций с точными числами
[ ] Проверена математическая корректность изменений остатков
[ ] Записаны номера всех созданных документов с датами
[ ] Сделаны скриншоты всех отчетов по остаткам (ДО и ПОСЛЕ)
[ ] Сохранены навигационные ссылки на созданные документы