Что умеет SaveTest: ссылки и вложения в тест-кейсах — меньше потерь контекста, больше пользы в прогоне
Когда тестировщик открывает кейс, ему почти всегда нужно что-то рядом со сценарием, например, требование из трекера, макет, API-документация, связанный баг-репорт, эталонный скриншот, лог или пример входного файла. Сам по себе тест-кейс может быть написан корректно, но без этого контекста проверка быстро превращается в поиск по чатам, вкладкам браузера и старым комментариям.
Для одного сценария это выглядит как мелочь. Но если команда готовит регресс, принимает новую функциональность или подключает к проекту нового специалиста, такие мелочи начинают съедать рабочее время. Тестировщик тратит силы не на проверку, а на восстановление картины. Где актуальное требование, какой макет использовать, какой файл загрузить, по какому примеру сверять результат?
В SaveTest эту задачу закрывают две простые функции:
Ссылки — быстрые переходы к внешним ресурсам, связанным с конкретным тест-кейсом.
Вложения — файлы, которые помогают выполнить проверку, воспроизвести сценарий или разобраться в результате.
Их задача сделать ее самодостаточной. Исполнитель открывает сценарий и сразу видит не только шаги, но и весь рабочий контекст, который нужен для нормального прогона.
Что дают ссылки и вложения команде
Ссылки полезны, когда к кейсу нужно привязать внешний источник:
Вложения нужны там, где важен сам файл или артефакт:
На практике это снижает время на ориентацию перед прогоном и уменьшает риск, что проверка пойдет по устаревшему или неполному контексту. Особенно это заметно на ручных регрессах, приемке изменений и в командах, где один специалист пишет кейс, а другой потом его выполняет.
Классический проект в SaveTest: как добавить ссылки и вложения
В классическом проекте SaveTest ссылки и вложения добавляются прямо в карточке тест-кейса через интерфейс платформы. Логика привычная: открыть кейс, перейти в редактирование, добавить нужные материалы и сохранить изменения.
1. Добавляем ссылки в тест-кейс
Откройте нужный тест-кейс в реестре и перейдите в режим редактирования. В секции ссылок нажмите «Добавить ссылку».
Далее заполните поля:
После этого сохраните изменения. Если к кейсу нужно добавить несколько ссылок, повторите действие через кнопку «Добавить ссылку». Ненужные или устаревшие ссылки удаляются в той же секции через действие удаления в строке.
Здесь важно не экономить на названии. Ссылка 1 или документ мало помогают исполнителю. Хорошее название сразу объясняет, зачем этот ресурс нужен в прогоне.
Когда тестировщик открывает кейс, ему почти всегда нужно что-то рядом со сценарием, например, требование из трекера, макет, API-документация, связанный баг-репорт, эталонный скриншот, лог или пример входного файла. Сам по себе тест-кейс может быть написан корректно, но без этого контекста проверка быстро превращается в поиск по чатам, вкладкам браузера и старым комментариям.
Для одного сценария это выглядит как мелочь. Но если команда готовит регресс, принимает новую функциональность или подключает к проекту нового специалиста, такие мелочи начинают съедать рабочее время. Тестировщик тратит силы не на проверку, а на восстановление картины. Где актуальное требование, какой макет использовать, какой файл загрузить, по какому примеру сверять результат?
В SaveTest эту задачу закрывают две простые функции:
Ссылки — быстрые переходы к внешним ресурсам, связанным с конкретным тест-кейсом.
Вложения — файлы, которые помогают выполнить проверку, воспроизвести сценарий или разобраться в результате.
Их задача сделать ее самодостаточной. Исполнитель открывает сценарий и сразу видит не только шаги, но и весь рабочий контекст, который нужен для нормального прогона.
Что дают ссылки и вложения команде
Ссылки полезны, когда к кейсу нужно привязать внешний источник:
- задачу или требование в трекере;
- дизайн-макет;
- API-спецификацию;
- связанную документацию;
- баг-репорт;
- описание бизнес-правила.
Вложения нужны там, где важен сам файл или артефакт:
- эталонные скриншоты и видео;
- примеры входных файлов;
- логи и дампы для воспроизведения;
- тестовые JSON, XML, CSV;
- дополнительные инструкции для редких сценариев.
На практике это снижает время на ориентацию перед прогоном и уменьшает риск, что проверка пойдет по устаревшему или неполному контексту. Особенно это заметно на ручных регрессах, приемке изменений и в командах, где один специалист пишет кейс, а другой потом его выполняет.
Классический проект в SaveTest: как добавить ссылки и вложения
В классическом проекте SaveTest ссылки и вложения добавляются прямо в карточке тест-кейса через интерфейс платформы. Логика привычная: открыть кейс, перейти в редактирование, добавить нужные материалы и сохранить изменения.
1. Добавляем ссылки в тест-кейс
Откройте нужный тест-кейс в реестре и перейдите в режим редактирования. В секции ссылок нажмите «Добавить ссылку».
Далее заполните поля:
- Название — понятное имя ссылки, например Требование PAY-184, Макет экрана оплаты, Swagger Orders API;
- URL — полный адрес ресурса.
После этого сохраните изменения. Если к кейсу нужно добавить несколько ссылок, повторите действие через кнопку «Добавить ссылку». Ненужные или устаревшие ссылки удаляются в той же секции через действие удаления в строке.
Здесь важно не экономить на названии. Ссылка 1 или документ мало помогают исполнителю. Хорошее название сразу объясняет, зачем этот ресурс нужен в прогоне.
2. Добавляем вложения в тест-кейс
В режиме редактирования откройте секцию вложений и нажмите «Загрузить файл». Выберите файл в системном окне и сохраните кейс. После загрузки файлы доступны прямо в карточке тест-кейса: их можно просмотреть, скачать или удалить, если они больше не нужны.
Отдельный плюс — встроенный предпросмотрщик вложений. Он позволяет открыть файл прямо в интерфейсе SaveTest без скачивания на локальную машину. Например, для текстовых вложений можно сразу посмотреть содержимое, скопировать нужный фрагмент и продолжить проверку без лишних переключений.
Простой пример: в кейсе на проверку ошибки оплаты можно хранить эталонный скриншот сообщения и текстовый лог запроса. Исполнитель не ищет эти материалы отдельно — они лежат рядом со сценарием.
Git-проект: как добавить ссылки и вложения через визуальный редактор VS Code
Если в классическом проекте ссылки и вложения добавляются через веб-интерфейс SaveTest, то в Git-проекте команда работает с теми же сущностями, но в другой технической модели. Данные сохраняются в YAML и попадают в репозиторий вместе с тест-кейсами. Для команд, которые ведут тестовую базу как код, это принципиально. Ссылки, вложения и сами сценарии можно ревьюить через привычный Git-процесс, смотреть историю изменений и обновлять связанные материалы в одном коммите.
В плагине SaveTest для VS Code обе функции поддерживаются и в структуре тест-кейса, и в визуальном сценарии редактирования.
Подготовка
- Откройте test-suite.yaml из каталога tests/test-case/.
- Нажмите иконку визуального редактора в правом верхнем углу файла или выполните команду SaveTest: Открыть визуальный редактор
- После этого выберите нужный тест-кейс в дереве.
1. Добавляем ссылки
Через визуальный редактор процесс выглядит так:
- Перейдите к блоку ссылок тест-кейса.
- Добавьте новую ссылку.
- Укажите имя и URL.
- Сохраните изменения.
В YAML ссылки хранятся в массиве links:
links:
- name: "Требование PAY-184"
value: "https://tracker.example.com/PAY-184"
- name: "Макет экрана оплаты"
value: "https://www.figma.com/file/xxxx/payment-screen"
Такой формат удобен тем, что связь кейса с требованиями, макетами или документацией становится частью репозитория. Ее видно на ревью, можно отследить в истории изменений и обновить вместе со сценарием.
2. Добавляем вложения
Через визуальный редактор:
- Откройте блок вложений в карточке кейса.
- Добавьте файл или несколько файлов.
- Проверьте, что вложения появились в кейсе.
- Сохраните изменения.
Прикрепленные файлы автоматически попадают в папку: tests/attach/ Вручную копировать их туда не нужно. Расширение само положит файл в каталог и пропишет путь в тест-кейсе. В YAML вложения отображаются в массиве attachments:
attachments:
- name: "payment-error-example.png"
type: "image/png"
path: "tests/attach/payment-error-example.png"
- name: "request-log.txt"
type: "text/plain"
path: "tests/attach/request-log.txt"
Если YAML редактируется вручную, можно использовать команду редактора SaveTest: Вставить вложение
Она добавляет шаблон для блока attachments, чтобы не собирать структуру руками.
Как это выглядит на реальном сценарии
Представим тест-кейс на проверку ошибки при неуспешной оплате. Шаги могут быть описаны корректно: открыть корзину, выбрать способ оплаты, отправить запрос, проверить сообщение об ошибке. Но для качественного выполнения проверки тестировщику обычно нужен дополнительный набор материалов.
Например, к такому кейсу можно добавить ссылки:
links:
- name: "Требование PAY-184"
value: "https://tracker.example.com/PAY-184"
- name: "Макет ошибки оплаты"
value: "https://www.figma.com/file/xxxx/payment-error"
- name: "Документация платежного API"
value: "https://api.example.com/docs/payments"
И вложения:
attachments:
- name: "bank-decline-response.json"
type: "application/json"
path: "tests/attach/bank-decline-response.json"
- name: "payment-error-reference.png"
type: "image/png"
path: "tests/attach/payment-error-reference.png"
В результате исполнитель получает полный рабочий набор: сценарий, требование, макет, API-контекст, пример ответа и эталонный результат. Это особенно полезно, когда кейс выполняет не автор, а другой участник команды, который не участвовал в обсуждении задачи.
Best practices: как не превратить кейсы в свалку артефактов
Ссылки и вложения помогают только тогда, когда команда использует их аккуратно. Если прикреплять к кейсам все подряд, тестовая база быстро зарастет устаревшими скриншотами, битыми URL, тяжелыми файлами и артефактами без понятного назначения. Рабочие правила простые:
Типичные ошибки
Чаще всего проблемы возникают не из-за инструмента, а из-за отсутствия договоренностей внутри команды:
С чего начать в команде
Не обязательно сразу приводить всю тестовую базу к идеальному состоянию. Лучше начать с критичных и часто выполняемых сценариев. Для каждого критичного кейса добавьте минимум одну ссылку на источник требований. Для кейсов с визуальными проверками — актуальный эталонный скриншот. Для сценариев с загрузкой файлов — пример входного файла. Для сложных интеграционных проверок — ссылку на API-документацию или пример запроса.
Через один-два спринта эффект обычно становится заметен: меньше уточнений в чатах, быстрее стартуют ручные прогоны, новым участникам проще входить в контекст, а тест-кейсы становятся не просто формальным описанием проверки, а полноценными рабочими артефактами.
Представим тест-кейс на проверку ошибки при неуспешной оплате. Шаги могут быть описаны корректно: открыть корзину, выбрать способ оплаты, отправить запрос, проверить сообщение об ошибке. Но для качественного выполнения проверки тестировщику обычно нужен дополнительный набор материалов.
Например, к такому кейсу можно добавить ссылки:
links:
- name: "Требование PAY-184"
value: "https://tracker.example.com/PAY-184"
- name: "Макет ошибки оплаты"
value: "https://www.figma.com/file/xxxx/payment-error"
- name: "Документация платежного API"
value: "https://api.example.com/docs/payments"
И вложения:
attachments:
- name: "bank-decline-response.json"
type: "application/json"
path: "tests/attach/bank-decline-response.json"
- name: "payment-error-reference.png"
type: "image/png"
path: "tests/attach/payment-error-reference.png"
В результате исполнитель получает полный рабочий набор: сценарий, требование, макет, API-контекст, пример ответа и эталонный результат. Это особенно полезно, когда кейс выполняет не автор, а другой участник команды, который не участвовал в обсуждении задачи.
Best practices: как не превратить кейсы в свалку артефактов
Ссылки и вложения помогают только тогда, когда команда использует их аккуратно. Если прикреплять к кейсам все подряд, тестовая база быстро зарастет устаревшими скриншотами, битыми URL, тяжелыми файлами и артефактами без понятного назначения. Рабочие правила простые:
- Оставляйте в кейсе только те ссылки, которые действительно нужны исполнителю на прогоне или ревью. Если ресурс не помогает выполнить проверку или понять ее смысл, лучше не добавлять его в карточку.
- Используйте говорящие названия: не link, file, document, а Требование PAY-184, Эталонный скриншот ошибки, Пример CSV для импорта.
- Для вложений придерживайтесь единого нейминга. Хорошее имя файла должно быть понятно без открытия: payment-error-reference.png или import-invalid-csv-example.csv работают лучше, чем image-final-2.png.
- Не храните устаревшие скриншоты после изменения интерфейса. Если UI поменялся, обновляйте не только шаги, но и связанные вложения.
- Не дублируйте один и тот же тяжелый файл в десятках кейсов. В таких ситуациях лучше использовать единый актуальный источник или аккуратную ссылку на общий артефакт.
- При изменении требований обновляйте ссылки и вложения в том же изменении, где правите тест-кейс. Для Git-проектов это особенно удобно: сценарий, ссылки и артефакты можно провести через один коммит и одно ревью.
Типичные ошибки
Чаще всего проблемы возникают не из-за инструмента, а из-за отсутствия договоренностей внутри команды:
- Добавили URL, но не проверили доступность. У автора ссылка открывается, а у исполнителя нет прав.
- Загрузили вложение без контекста. Файл есть, но непонятно, к какому шагу или условию он относится.
- Оставили старый скриншот после изменения интерфейса. Формально вложение есть, но фактически оно вводит тестировщика в заблуждение.
- Перегрузили кейс файлами, которые не помогают выполнению проверки. Чем больше лишнего шума в карточке, тем сложнее найти действительно нужный артефакт.
- Такие ошибки хорошо ловятся на ревью тест-кейсов. Проверять стоит не только шаги, предусловия и ожидаемый результат, но и связанные материалы.
С чего начать в команде
Не обязательно сразу приводить всю тестовую базу к идеальному состоянию. Лучше начать с критичных и часто выполняемых сценариев. Для каждого критичного кейса добавьте минимум одну ссылку на источник требований. Для кейсов с визуальными проверками — актуальный эталонный скриншот. Для сценариев с загрузкой файлов — пример входного файла. Для сложных интеграционных проверок — ссылку на API-документацию или пример запроса.
Через один-два спринта эффект обычно становится заметен: меньше уточнений в чатах, быстрее стартуют ручные прогоны, новым участникам проще входить в контекст, а тест-кейсы становятся не просто формальным описанием проверки, а полноценными рабочими артефактами.