Начните с одного действия пользователя
Бриф на разработку браузерного расширения задаёт конкретный сценарий для обсуждения с разработчиком. Начните с пользователя, его текущей работы и действия, которое хотите изменить. Затем опишите результат, который готовы принять, включая поведение при отказе доступа или сбое внешней системы.
Отделяйте требования от ещё не принятых решений. Версию браузера или детали интеграции можно оставить открытыми, если понятно, кто их уточнит. Преждевременная отметка «согласовано» затрудняет последующую проверку объёма работ.
Заполненный пример показывает один предлагаемый сценарий. Ниже есть пустой шаблон, который можно выделить и скопировать. Для первого вопроса о разработке достаточно короткого описания; заполнять весь шаблон необязательно.
Заполненный бриф: сообщение об ошибке на тестовом сайте
Это вымышленный запрос, составленный для этого материала. Он описывает предлагаемое расширение для команды тестирования, а не клиентский проект, реализованную функцию или предложение с установленной ценой и датой готовности. До начала работы описанное поведение нужно рассмотреть и согласовать.
Цель и задача пользователя
Тестировщики сообщают о дефектах при проверке тестового сайта. Пользователь должен открыть расширение, подготовить сообщение с путём нужной страницы, ввести заголовок и шаги воспроизведения, проверить содержимое и отправить его в систему учёта ошибок команды.
Мы хотим, чтобы принятое сообщение содержало контекст, по которому другой тестировщик сможет воспроизвести ошибку. Проверки ниже устанавливают требуемое поведение. Пользу в повседневной работе команда должна оценивать отдельно.
Что существует сейчас
Сейчас команда вручную копирует адрес страницы и пишет сообщение в системе учёта ошибок. Кода расширения нет. Есть тестовый сайт, тестовый проект в системе учёта и руководитель тестирования, который может предоставить учебные страницы и образцы сообщений.
Первый объём работ ограничен одним тестовым сайтом и одним проектом в системе учёта. Скриншоты, доступ к рабочему сайту и фоновый сбор данных в этот предлагаемый объём не входят. Дополнительные сценарии обсуждаются отдельно.
Браузеры и ограничения работы
Нужны Chrome и Microsoft Edge на устройствах команды с Windows. До подтверждения поддержки и проверки пакета руководитель тестирования должен записать фактические версии браузеров и ограничения управляемых устройств. Firefox в первый объём этого примера не входит.
Расширение должно действовать, когда тестировщик открывает его и выбирает подготовку сообщения. На странице вне согласованного тестового сайта оно должно объяснить ограничение и оставить систему учёта без изменений. Доступ браузера и точный способ реализации остаются вопросами технического рассмотрения.
Данные и доступ
Предлагаемое сообщение содержит origin и путь тестовой страницы, введённые пользователем заголовок и шаги воспроизведения, а также согласованные для проверки сведения о браузере. Параметры query string и содержимое страницы автоматически не собираются. Перед отправкой тестировщик проверяет и может отредактировать сообщение.
Руководитель тестирования предоставляет вымышленные данные для разработки и приёмки. До реализации разработчик и администратор системы учёта должны согласовать аутентификацию, необходимый доступ и хранение. Вопросы о получателях черновиков и их удалении ещё открыты. В первом обращении достаточно описать эти потребности; пароли, токены и реальные записи клиентов передавать не следует.
Интеграция и поведение при сбоях
Получателем является существующая система учёта ошибок команды; при проверках используется отдельный тестовый проект. Его администратор отвечает за доступ и должен предоставить документацию нужного интерфейса для рассмотрения.
После успешной отправки расширение должно показать идентификатор созданной записи и ссылку, которую тестировщик может открыть. После отклонённого запроса введённый текст должен оставаться доступным для исправления. Если ответ потерян и создание записи не установлено, интерфейс должен сообщить о неизвестном исходе и предложить проверить систему учёта до следующей попытки. Способ идентификации такой попытки остаётся открытым решением интеграции.
Проверки требуемого результата
Используйте согласованный пакет, версии браузеров, учебную страницу и тестовый проект. Рядом с каждым ожидаемым результатом сохраняйте фактический. До выполнения каждая проверка остаётся непроведённой.
| Ситуация проверки | Ожидаемый результат для согласования |
|---|---|
| Подготовить сообщение с разрешённой тестовой страницы | В предпросмотре есть согласованный путь и введённые поля. Вымышленный секрет из query string отсутствует. Изменение заголовка отражается в предпросмотре; до выбора «Отправить» система учёта не меняется. |
| Успешно отправить проверенное сообщение | В тестовом проекте одна запись с проверенными полями. Расширение показывает её идентификатор и рабочую ссылку. Проверяется сама запись в системе, а не только сообщение интерфейса. |
| Открыть расширение на другом сайте или отказать в необходимом доступе | Интерфейс объясняет ограничение и следующий шаг. Запись не создаётся, более широкий доступ не запрашивается без объяснения. |
| Система отклоняет запрос или её ответ потерян | Введённое сообщение остаётся доступным. Определённый отказ отличается от неизвестного исхода создания записи. Перед повтором неопределённой попытки предлагается проверить систему учёта. |
Приёмка, передача и роли при выпуске
Разработчик должен предоставить согласованный пакет, инструкции сборки и результаты проверок. Руководитель тестирования воспроизводит проверки и записывает принятые пункты и открытые ошибки. Администратор системы учёта подтверждает тестовый доступ и порядок рабочей интеграции.
После технической приёмки владелец продукта решает, выпускать ли расширение и каким способом. Маршрут распространения, аккаунт издателя, подготовка пакета и ответственность за отправку ещё требуют согласования. У отправки в магазин и решения магазина будут собственные статусы; эти проверки устанавливают только проверенное поведение. Последующее сопровождение требует отдельного объёма работ.
Открытые вопросы до согласования работ
- Какие точные версии браузеров и ограничения устройств должен учитывать первый пакет? Перечень предоставит руководитель тестирования.
- Какой интерфейс системы учёта и способ аутентификации доступны? Администратор предоставит документацию и план тестового доступа.
- Должны ли черновики сохраняться после закрытия расширения или перезапуска браузера? Владелец продукта определит поведение и правила удаления.
- Как сопоставить неопределённую отправку с записью в системе учёта? Разработчик и администратор предложат проверку до согласования повторных попыток.
- Какой способ распространения и какие материалы передачи нужны команде? Владелец продукта назначит ответственного за выпуск и подтвердит роли.
Этот запрос можно обсуждать, сохраняя открытые вопросы видимыми. Поддержка браузеров, выполнимость, сроки и коммерческие условия подтверждаются для конкретного проекта.
Скопируйте шаблон брифа
Выделите структуру ниже и скопируйте её в свой документ или сообщение. Заполните известное, остальное отметьте как открытые вопросы. Чувствительные сведения о доступе передавайте через отдельно согласованный закрытый процесс.
Бриф на разработку браузерного расширения
Цель и задача пользователя
- Кто будет пользоваться:
- Что пользователь делает сейчас:
- Одно действие, с которым должно помочь расширение:
- Ожидаемый результат:
Текущее состояние и первый объём работ
- Идея, спецификация, код или выпущенное расширение:
- Какие материалы доступны для рассмотрения:
- Что входит в первый объём:
- Что в него не входит:
Браузеры и ограничения
- Нужные браузеры, версии и устройства:
- Сайты и условия работы:
- Ограничения устройств, доступа или распространения:
- Какую поддержку браузеров ещё нужно подтвердить:
Данные и доступ
- Входные данные, источник и предлагаемый получатель:
- Что пользователь проверяет перед действием:
- Какой доступ нужно рассмотреть:
- Требования к хранению, доступу и удалению:
- Какие учебные данные доступны для проверок:
Интеграции
- Внешняя система и ответственный за неё:
- Доступные документация и тестовая среда:
- Ожидаемый результат успеха:
- Поведение при отказе доступа или недоступности системы:
- Как проверить неизвестный исход до повторной попытки:
Проверки приёмки (повторить для каждого важного действия)
- Условия и действие проверки:
- Ожидаемый наблюдаемый результат:
- Пакет и браузеры для проверки:
- Кто проверяет:
- Фактический результат и открытые пункты:
Передача и выпуск
- Нужные материалы и доступ:
- Ответственный за техническую приёмку:
- Предполагаемый способ распространения:
- Кто принимает решение о выпуске:
- Какую подготовку, отправку и поддержку нужно согласовать:
Открытые вопросы
- Вопрос:
- Кто отвечает за решение:
- Какое решение или подтверждение нужно:
Ограничения планирования
- Желаемая дата или зависимость, если есть:
- Коммерческие ограничения для обсуждения, если есть:
Перейдите от брифа к обсуждению
Отправьте задачу пользователя, текущее состояние и главный открытый вопрос через существующую форму запроса разработки. Для начала достаточно контакта и короткого описания. Заполненный бриф можно добавить позже, если он помогает объяснить объём работ.
Состав услуги и более подробные проверки браузеров описаны на странице разработки браузерных расширений. Extcorp рассматривает запросы индивидуально; нужные браузеры, работа, участие в выпуске, сроки и условия согласуются для проекта.