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

🚨 СТОП! КРИТИЧЕСКОЕ ПРЕДУПРЕЖДЕНИЕ ПЕРЕД НАЧАЛОМ РАБОТЫ¶

ЗАПРЕЩЕНО использовать упрощённые параметры инструментов!

Когда в инструкции явно указан параметр (например, format=all), нужно использовать ТОЧНО этот параметр. Нельзя сначала вызывать с упрощённым параметром (format=short_info) для "быстрой оценки", а потом с полным.

Пример ЗАПРЕЩЁННОГО действия:

# ❌ НЕПРАВИЛЬНО - сначала short_info, потом all
get_data_from_knowledge_base(format="short_info")  # для "быстрой оценки"
get_data_from_knowledge_base(format="all")          # потом полное чтение

Пример ПРАВИЛЬНОГО действия:

# ✅ ПРАВИЛЬНО - сразу полное чтение
get_data_from_knowledge_base(format="all")

Это правило применяется ко ВСЕМ инструментам и параметрам, явно указанным в инструкциях.

🚨 СТОП! ЗАПРЕТ СОЗДАНИЯ ТЕСТОВЫХ ДАННЫХ (КРИТИЧНО)¶

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

К вспомогательным тестовым данным относятся:¶

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

Что Исследователь МОЖЕТ создавать:¶

✅ Документы, явно указанные в исходном сценарии как шаги (например: «Когда: Я создаю заявку на закупку», «И Я добавляю товар в таблицу "Товары"»)
✅ Любые новые элементы, создание которых прямо описано в шагах сценария

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

НЕ создавать недостающие данные через UI/BSL/любым способом
НЕ пытаться «обойти» сценарий (например, использовать российского партнёра вместо партнёра ЕАЭС)
Зафиксировать факт отсутствия в файле research/РезультатИсследования_<NN>_<КраткоеНазвание>.MD в разделе «⛔ Блокеры / Отсутствующие тестовые данные»:
какие именно данные отсутствуют,
в каком справочнике / документе их ожидали,
с какими ключевыми реквизитами они должны быть
Завершить исследование с пометкой о блокере и перейти к следующему сценарию

❌ Антипаттерны (ЗАПРЕЩЕНО):¶

❌ «Создам партнёра ЕАЭС сам, чтобы быстрее получить результат»
❌ «Использую российского партнёра — для НДС разница небольшая»
❌ «Подготовлю данные во время исследования — это же логично»
❌ «Создам данные через BSL, это быстрее, чем через UI»

Почему это критически важно:¶

🚫 Невоспроизводимость в CI: Если исследователь создаст данные в своей базе, в CI их не будет — сценарий упадёт при запуске тестов
🚫 Смешение ролей: Подготовка данных — это отдельная задача, не входящая в обязанности исследователя
🚫 Загрязнение базы: Неконтролируемые тестовые данные усложняют поддержку и удаление
🚫 Нарушение протокола: Управляющий Агент не сможет корректно оценить наличие тестовых данных (Шаг 2.3б), если они созданы неявно в ходе исследования

Подробные правила см. в разделе «🆕 Отсутствие необходимых тестовых данных в базе» ниже.

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

Сначала прочитай целевой файл и пойми его логику.
СРАЗУ прочитай базу знаний Vanessa Automation: get_data_from_knowledge_base, format=all (НЕ используй format=short_info перед этим!)
Также прочитай файл 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
- save_table_document_to_file
Сначала получи все команды командного интерфейса (панель разделов и панель функций для каждого элемента панели разделов) с помощью инструмента manage_command_interface, action=get_all (важный момент, это надо сделать до начала записи действий пользователя).
Затем посмотри какие тестовые данные есть в базе данных клиента тестирования (важный момент, это надо сделать до начала записи действий пользователя).

⚠️ ВАЖНО: Получение командного интерфейса и анализ тестовых данных в базе выполняется отдельным субагентом АнализДанныхИИнтерфейса ДО запуска Исследователя. Результат сохраняется в файл data/АнализДанных_<NN>_<ИмяСценария>.MD.

Исследователь ОБЯЗАН в начале работы: 1. Прочитать файл data/АнализДанных_<NN>_<ИмяСценария>.MD 2. Использовать подготовленные там данные о командном интерфейсе и тестовых данных 3. НЕ ВЫЗЫВАТЬ самостоятельно manage_command_interface, action=get_all — эта работа уже выполнена 4. НЕ ИСКАТЬ самостоятельно данные в базе через get_table_data — рекомендации уже в файле

Допускается точечный поиск конкретных элементов через get_table_data, если в файле АнализДанных их нет. - Ты должен собрать подробную информацию о каждой форме, которую ты открывал и с которой взаимодействовал: - Какие поля формы шапки заполнялись (имя поля, заголовок поля, тип поля). - Какие поля таблиц формы шапки заполнялись (имя таблицы, имя поля, заголовок поля, тип поля). - Какие кнопки нажимались (имя кнопки и заголовок кнопки). - Ты должен собрать подробную информацию о том какие команды ты использовал из командного интерфейса и для чего. - Ты должен выполнить "вручную" обязательно все пункты из задачи. - Перед началом выполнения действий "вручную" нужно ОБЯЗАТЕЛЬНО включить запись действий пользователя с помощью инструмента user_actions_recording - После окончания "ручных" действий нужно остановить запись действий пользователя и получить от инструмента user_actions_recording шаги сценария. - Текст сценария надо очистить от мусорных действий, если они в нём есть. - Ты должен вернуть полученную информацию о формах и шаги сценария в файл "РезультатИсследования.MD" - Нужно статраться использовать инструмент execute_form_actions, чтобы за один вызов выполнить несколько действий, т.к. он позволяет выполнить несколько действий с формой за один вызов инструмента и это существенно ускоряет исследование. - Лучше в инструменте execute_form_actions за один вызов выполнять максимальное число возможных действий, до 10 за один вызов.

⚠️ Важные правила выполнения¶

🚨 КРИТИЧЕСКОЕ ПРАВИЛО - АНАЛИЗ СКРИНШОТОВ ПРИ ЛЮБЫХ ПРОБЛЕМАХ¶

Если текстовый ответ инструмента не показывает ожидаемый результат или вы не можете найти нужный элемент формы:

СРАЗУ сделайте скриншот через get_window_screenshot_os
ПРОЧИТАЙТЕ скриншот через read_file
Проанализируйте визуальную информацию - что реально отображается на экране
ТОЛЬКО ПОСЛЕ анализа скриншота принимайте решение о дальнейших действиях

Почему это важно: - Текстовые ответы инструментов (get_form_analysis, manage_form_elements) могут не показывать все элементы формы - Элементы могут быть невидимы, заблокированы или находиться в другом месте - Визуальный анализ скриншота позволяет увидеть реальное состояние приложения - Без скриншота вы работаете вслепую и можете принимать неверные решения

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

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

Алгоритм при любой проблеме:

1. get_window_screenshot_os - сделать скриншот
2. read_file - прочитать скриншот
3. analyze - проанализировать что на экране
4. decide - принять решение на основе визуальной информации

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

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

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

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

1. НЕМЕДЛЕННО вызвать get_window_screenshot_os
2. НЕМЕДЛЕННО вызвать read_file для скриншота
3. Проанализировать скриншот:
   - Какое окно сейчас активно?
   - Какие элементы видны на самом деле?
   - Есть ли сообщения об ошибках на форме?
   - Правильное ли имя элемента я использовал?
4. Только после анализа скриншота принимать решение об исправлении действия

Пример правильной последовательности:

❌ НЕПРАВИЛЬНО:
   manage_form_elements (ошибка) → попробовать другое действие → attempt_completion

✅ ПРАВИЛЬНО:
   manage_form_elements (ошибка) → get_window_screenshot_os → 
   read_file → анализ → исправить действие → повторить

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

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

🖼️ Обязательное создание скриншотов (КРИТИЧНО ВАЖНО)¶

Внимание! Не полагайтесь только на текстовые ответы инструментов. Визуальный анализ скриншотов критически важен для понимания реального состояния клиентского приложения 1С.

Когда ОБЯЗАТЕЛЬНО нужно делать скриншоты:¶

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

Пример правильного использования:¶

Шаг 1: Нажать кнопку "Провести и закрыть"
Шаг 2: Сделать скриншот инструментом get_window_screenshot_os
Шаг 3: Прочитать скриншот инструментом read_file
Шаг 4: Убедиться, что форма закрыта (на скриншоте видно другое окно)

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

📁 Расположение скриншотов в проекте¶

Все скриншоты должны сохраняться в каталоге проекта в подкаталоге png!

Структура каталогов проекта:

<корень_проекта>/                # Например: <ПутьКПроекту> (см. ПараметрыКонфигурации.MD)
├── png/                        # ✅ ВСЕ скриншоты сохраняются ЗДЕСЬ
│   ├── scenario_1_step_1.png
│   ├── scenario_1_step_2.png
│   ├── scenario_2_step_1.png
│   └── ...
├── features/                   # Feature файлы
├── research/                   # Результаты исследований
├── InstructionsResearch.md
├── InstructionsWriteScenario.md
├── ТестПлан.MD
└── ...

Правила именования скриншотов: - Используйте префикс scenario_<номер>_<описание>.png - Пример: scenario_1_zayavka_sozdanie.png, scenario_3_otchet_otkloneniya.png - Или используйте описательное имя: zayavka_000002_form.png, zayavka_000002_tovary.png

Перед созданием первого скриншота: 1. Убедитесь, что каталог png/ существует в корне проекта 2. Если каталог не существует — создайте его командой:

mkdir -p png

Пример вызова инструмента:

инструмент: get_window_screenshot_os
параметр: file_name=png/scenario_1_step_1.png
параметр: window_title="Заявка на закупку (создание)*"

❌ ЗАПРЕЩЕНО: - Сохранять скриншоты во временных каталогах ОС (/tmp, C:\Users\...\Temp) - Сохранять скриншоты в домашнем каталоге пользователя - Сохранять скриншоты в любом месте вне каталога проекта - Использовать абсолютные пути вне проекта

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

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

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

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

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

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

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

Пример ситуации: - Сценарий 1: Запись включена → Выполнен → Запись остановлена - Сценарий 2: Возникла ошибка → Запись остановлена - Сценарий 3-5: Требуется снова включить запись перед началом!

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

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

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

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

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

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

10. Перед началом работы надо закрыть все открытые окна в клиенте тестирования.¶

- это нужно сделать, т.к. от работы предыдущих агентов могли остаться открытые окна.¶

🔧 Проверка доступности функционала через константы¶

⚠️ Важное замечание о недоступных документах¶

Если при попытке создать документ или открыть форму вы получаете ошибку "Неверно задана навигационная ссылка" или документ не найден в хозяйственных операциях:

Возможная причина: Функционал отключен на уровне констант конфигурации 1С.
Как проверить:
Откройте файл const.MD в корневой папке проекта
Найдите константу с названием интересующего документа/функции
Проверьте значение: Да (включено) или Нет (отключено)

Примеры констант:

- **Использовать заявки на закупку**: Нет
- **Использовать заказы поставщикам**: Да
- **Использовать запросы коммерческих предложений поставщиков**: Нет

Что делать если функционал отключен:
ОБЯЗАТЕЛЬНО включить функционал через форму настроек перед продолжением исследования

Важно: Перед началом исследования рекомендуется заранее проверить файл const.MD на предмет включенного/отключенного функционала, чтобы понимать какие документы и возможности доступны в данной демо-базе.

🚨 КРИТИЧЕСКОЕ ТРЕБОВАНИЕ - ПРОВЕРКА КОНСТАНТ ПЕРЕД НАЧАЛОМ ИССЛЕДОВАНИЯ¶

Перед началом выполнения любого сценария исследования:

ОБЯЗАТЕЛЬНО прочитай файл const.MD полностью
Найди все константы, относящиеся к объектам исследования (документы, справочники, отчеты)
Если функционал отключен (значение "Нет"):
НЕ продолжай исследование на аналогах
НЕ записывай в результаты что "функционал недоступен"
СРАЗУ включи функционал через форму настроек
Только после включения продолжай исследование
Запрещено:
❌ Использовать документы-аналоги вместо требуемых (например, "Заказ поставщику" вместо "Заявка на закупку")
❌ Пропускать сценарии с формулировкой "функционал отключен"
❌ Завершать исследование до включения требуемого функционала

Порядок включения функционала:

1. Прочитать const.MD
2. Найти отключенные константы по теме исследования
3. Открыть форму настроек
4. Включить нужные опции через manage_form_elements или execute_form_actions
5. Сохранить настройки
6. Проверить что функционал стал доступен (открыть форму документа)
7. ТОЛЬКО ПОСЛЕ этого продолжить исследование

🆕 Отсутствие необходимых тестовых данных в базе¶

❗ Критически важное правило¶

Если сценарий требует определённых данных (заявка, документ, контрагент, номенклатура и т.п.), но их нет в базе — исследователь НЕ ДОЛЖЕН создавать их самостоятельно. Вместо этого он обязан зафиксировать факт отсутствия данных в РезультатИсследования.MD (в разделе «Блокеры / Отсутствующие тестовые данные»), чтобы эта информация была передана для подготовки тестовой базы.

🚫 АБСОЛЮТНЫЙ ЗАПРЕТ¶

Это НЕ рекомендация, а АБСОЛЮТНЫЙ ЗАПРЕТ. Исследователь НЕ ИМЕЕТ ПРАВА создавать вспомогательные тестовые данные, даже если: - Сценарий невозможно выполнить без этих данных - Создание данных кажется «логичным» или «быстрым решением» - Создание занимает всего несколько кликов в UI - Удалось найти инструкцию в Memory.MD или АнализДанных о том, как это сделать

Почему это важно¶

❗ Тестовая база в CI не совпадает с базой исследователя. Если исследователь создаст данные в своей базе во время исследования, то при запуске теста в CI этих данных уже не будет — сценарий упадёт.
❗ Вспомогательные тестовые данные (контрагенты, номенклатура, заявки, документы и т.п.) должны заранее присутствовать в тестовой базе. Их подготовка — это отдельная задача, не входящая в обязанности исследователя сценария.
❗ Создание данных в исследовательской базе делает результат исследования невоспроизводимым в тестовой среде CI.
❗ Создание данных исследователем нарушает Шаг 2.3б протокола Управляющего Агента — Управляющий Агент проверяет наличие данных перед запуском Писателя, и неявно созданные данные невозможно отследить.
❗ Создание данных запутывает Код-Ревьюера — он не может отличить данные, которые были в базе, от данных, которые создал исследователь.

Допустимое исключение (ЕДИНСТВЕННОЕ)¶

Создание нового элемента в рамках сценария допустимо ТОЛЬКО если сам сценарий явно требует создания нового документа/записи как шага сценария (например: «создать заявку», «ввести новое поступление», «оформить новый документ»). Такие шаги являются частью сценария, а не подготовкой вспомогательных данных, и описываются в шагах сценария.

Что делать исследователю при отсутствии данных (пошаговый алгоритм)¶

Прекратить попытки выполнить сценарий — не пытаться найти обходной путь
Проверить наличие требуемых данных через get_table_data (точечный поиск)
Подтвердить отсутствие данных — если их действительно нет
Записать в РезультатИсследования_<NN>_<КраткоеНазвание>.MD в раздел «⛔ Блокеры / Отсутствующие тестовые данные»:
какие именно данные отсутствуют (с конкретными именами/идентификаторами)
в каком справочнике / документе / регистре их ожидали
с какими ключевыми реквизитами они должны быть (по сценарию)
какие значения полей должны быть заполнены (если известны)
Предложить рекомендации по подготовке данных (если есть экспертные знания)
Завершить исследование с пометкой ⛔ «Заблокировано: отсутствуют тестовые данные»
Не создавать данные самостоятельно и не пытаться «обойти» сценарий
Перейти к следующему сценарию

Шаблон записи в `РезультатИсследования.MD`:¶

## ⛔ Блокеры / Отсутствующие тестовые данные

### Что отсутствует

| Тип объекта | Наименование | Ключевые реквизиты | Примечание |
|---|---|---|---|
| Справочник.СтраныМира | БЕЛАРУСЬ | Код = 112, Наименование = БЕЛАРУСЬ | Критично для сценария |
| Справочник.Партнеры | Поставщик ЕАЭС | Поставщик = Истина, Страна = БЕЛАРУСЬ | — |
| Справочник.Контрагенты | Контрагент ЕАЭС | Партнер = <Поставщик ЕАЭС>, СтранаРегистрации = БЕЛАРУСЬ, ВидКонтрагента = ЮрЛицоНерезидент | — |
| Справочник.СоглашенияСПоставщиками | Закупка ЕАЭС | ХозяйственнаяОперация = ЗакупкаВСтранахЕАЭС | — |

### Рекомендации по подготовке

1. Создать страну БЕЛАРУСЬ через UI-классификатор ОКСМ (BSL НЕ работает)
2. Создать партнёра `Поставщик ЕАЭС` с признаком `Поставщик = Истина`
3. Создать контрагента с `СтранаРегистрации = БЕЛАРУСЬ`
4. Создать соглашение с `ХозяйственнаяОперация = ЗакупкаВСтранахЕАЭС`

### Статус

⛔ **Заблокировано:** сценарий не может быть выполнен через UI до подготовки указанных данных.

Конкретные примеры антипаттернов¶

❌ «В базе нет нужного контрагента — создам его через форму создания», а сценарий не требует создания нового контрагента.
❌ «Нет подходящей заявки — заведу её, чтобы прогнать сценарий», а сценарий не требует создания новой заявки.
❌ «Добавлю номенклатуру вручную, чтобы пройти шаг сценария», а сценарий не требует создания новой номенклатуры.
❌ «Создам документ-основание, чтобы проверить ввод на основании», а сценарий не требует создавать документ-основание.
❌ «В базе нет стран ЕАЭС — добавлю Беларусь через ОКСМ, чтобы протестировать метод ПараметрыНалогообложенияНДС».
❌ «В базе нет партнёра-импортёра — создам через BSL, чтобы не блокировать сценарий».
❌ «Использую существующего партнёра Поставщик1 (Россия), хотя сценарий требует ЕАЭС — для НДС разница не критична».
❌ «Создам соглашение с хоз. операцией «ЗакупкаПоИмпорту», хотя в АнализДанных указано «ЗакупкаВСтранахЕАЭС» — это почти одно и то же».

Правильный подход:¶

✅ Обнаружил отсутствие → записал в РезультатИсследования.MD в раздел «Блокеры / Отсутствующие тестовые данные».
✅ Указал, какие именно данные нужны и в каком виде (справочник/документ, ключевые реквизиты).
✅ Предложил рекомендации по подготовке (если есть экспертные знания).
✅ Завершил исследование с пометкой ⛔ «Заблокировано».
✅ Продолжил работу над другими сценариями.

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

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

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

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

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

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