ИСиП · внедрение и сопровождение · одна работа на две пары

Выпустить аптечный интерфейс и сохранить заказы

Вы принимаете новую версию аптечного сервиса. В нём работают покупатель, сотрудник выдачи и специалист поддержки. Нужно проверить интерфейс, согласовать версии клиентов и API, принять решение о выпуске и доказать, что заказы сохранились после изменений.

Продолжительность: 180 минут учебной работы, две пары по 90 минут. Перерыв между парами в расчёт не входит. Формат: команда 2–3 человека или индивидуально. Все этапы связаны одним протоколом, повторно начинать работу на второй паре не нужно.

Открыть стенд

Подготовка

  1. Полностью распакуйте архив в отдельную папку. Откройте index.html двойным щелчком в актуальном Chrome, Edge или Firefox. Не открывайте страницу внутри просмотрщика ZIP. Интернет, сервер, Node.js и регистрация не нужны.
  2. Оставьте одну вкладку стенда. В «Протоколе» укажите обозначение команды и группы. Настоящие имена покупателей, телефоны и медицинские сведения не вводите. Код покупателя: DEMO-001, DEMO-002 и т. п.
  3. Распределите работу: тестировщик проводит эксперименты, специалист внедрения меняет конфигурацию и следит за данными, поддержка ведёт протокол и разбирает инциденты. После первой пары смените роли. Один человек выполняет эти роли по очереди.
  4. Откройте «Выпуск». Тестовый и рабочий контуры имеют независимые корзины, заказы и остатки. Рабочий контур тоже является учебной моделью. Сборка интерфейса, версия API и версия клиента обозначают разные вещи.
Если сверху появилось предупреждение о сохранении, данные живут только до закрытия вкладки. Чаще скачивайте отчёт и журнал. Даже при штатном сохранении скачайте их перед перерывом. Снимок JSON служит для восстановления рабочего контура, журнал JSON для доказательств.

Что есть в поставке

index.html запускает тренажёр; practice.html содержит задание; styles.css, data.js и app.js обеспечивают работу. report-template.md позволяет вести протокол вне браузера. Изменение исходного кода для основной работы не требуется.

Учебная ситуация

В рабочем контуре установлена сборка 1.4.0 с API v1 и тремя клиентами v1. Для приёмки выдана сборка 1.5.0-rc с API v2: витрина уже использует клиент v2, выдача и поддержка пока остаются на v1. Позже доступна сборка 1.5.1 для повторного тестирования. Сам по себе новый номер версии не доказывает, что система готова к выпуску.

Архитектурная часть связана с темой «Согласовать клиент и API без потери данных». Здесь совместимость проверяется на реальных действиях модели: создание заказа, отображение его суммы, подготовка к выдаче и ответ поддержки.

Требования для приёмки

Ожидаемые результаты определяйте по этим требованиям, а не по тому, что сейчас показывает интерфейс.

КодУсловие
R1Поиск по названию работает без учёта регистра и пробелов по краям. Категория, поиск и фильтр наличия действуют вместе. Пустой результат объяснён пользователю.
R2Сортировка цены упорядочивает числовые цены. Цена в каталоге, карточке и корзине совпадает.
R3Количество является целым числом от 1 до 99. Оформление разрешено только в пределах остатка выбранной точки. Остаток другой точки не должен разрешать лишний заказ.
R4Промокод DEMO10 уменьшает сумму товаров на 10%, начиная с 1 000,00 ₽ включительно. Скидка округляется до копейки один раз от суммы всей корзины. Доставка и другие платежи отсутствуют.
R5После успешного оформления появляется один заказ, его сумма равна итогу корзины, остаток выбранной точки уменьшается на заказанное количество.
R6API v1 поддерживает клиента v1. API v2 поддерживает клиента v2, а клиента v1 через включённый адаптер. Несовместимость видна как SCHEMA_MISMATCH, а сохранённые заказы остаются в модели.
R7Клиент v1 читает order_id, status и total_rub. Клиент v2 читает id, state и total_kopecks. После преобразования контракта идентификатор, смысл статуса и денежная сумма должны сохраняться.
R8Заказ проходит статусы «Забронирован» → «Готов к выдаче» → «Выдан». Поддержка видит актуальное состояние, сумму и ключ запроса.
R9Повтор незавершённого запроса с прежним ключом не создаёт второй заказ. Перед повтором после отсутствия ответа проверяют состояние и журнал. Изменение корзины или точки начинает новую попытку.
R10Выпуск и возврат конфигурации сохраняют рабочие заказы и остатки. Восстановление снимка возвращает данные на момент его создания. Новые заказы после снимка требуют отдельного решения.

Исходные данные для граничных проверок

На чистых данных «Аква-Демо» стоит 250,00 ₽ и имеет остаток 8 в «Центре», «Пакет Демо» стоит 10,00 ₽ и имеет остаток 20, «Термометр Макет» стоит 1 250,00 ₽ с остатками 1 в «Центре» и 5 в «Парке». «Салфетки Демо» стоят 199,99 ₽. Количество в корзине редактируется. Для чистого повторения используйте «Сбросить данные тестового контура»; выбранные версии и протокол сохраняются.

Первая пара · приёмка и решение о выпуске

0–15 минут. Подготовить план

Прочитайте требования, распределите роли и выберите проверки. Для каждой записи укажите требование, условия, шаги, ожидаемый результат, фактический результат и статус. Сборка, API, клиенты и контур сохраняются в протоколе автоматически. Используйте обозначения TC-01, TC-02 и далее; повторный тест помечайте, например, TC-02-R.

Если используете ИИ, попросите предложить проверки по требованиям R1–R10. Проверьте его ожидания ручным расчётом и выполнением в стенде. В протоколе отметьте, что предложил ИИ и что вы исправили. Ответ ИИ не считается результатом теста.

До запуска проверки запишите ожидание. Варианты статуса: «Пройден», «Не пройден», «Заблокирован», «Не выполнен». Не подменяйте два последних успешным результатом.

15–35 минут. Зафиксировать исходное состояние

  1. Переключитесь на рабочий контур. Пройдите путь «Каталог → карточка → корзина → оформление». Создайте один небольшой заказ с кодом DEMO-001. Запишите его идентификатор, состав, сумму и остаток товара.
  2. Проверьте этот заказ в «Моих заказах», «Выдаче» и «Поддержке». На выдаче подготовьте его, затем проверьте обновление статуса в поддержке. Сохраните результаты.
  3. Сделайте снимок рабочего контура и скачайте его JSON. Этот заказ будет контрольной записью, по которой вы проверите сохранность данных при выпуске.

35–60 минут. Проверить кандидата 1.5.0-rc

Работайте в тестовом контуре. Обязательные группы экспериментов:

  1. Поиск одним и тем же фрагментом названия в разном регистре и с пробелами по краям. Отдельно проверьте отсутствие результатов и сочетание категории с наличием.
  2. Сортировка цены, переход в карточку и совпадение цены с корзиной.
  3. Промокод на суммах 990,00 ₽, 1 000,00 ₽ и 1 010,00 ₽. Для 990,00 ₽ можно собрать 3 «Аква-Демо» и 2 «Бинта Учебных». Для 1 000,00 ₽ подходят 4 «Аква-Демо», для 1 010,00 ₽ добавьте «Пакет Демо». Запишите ручной расчёт и сравните с интерфейсом. Корзину между сценариями очищайте.
  4. Один «Термометр Макет» в «Центре», затем отдельный эксперимент с двумя штуками при исходном остатке 1. До второго эксперимента сбросьте тестовые данные. Сравните также поведение в «Парке». Не делайте вывод об остатке только по суммарному количеству в сети.

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

60–80 минут. Проверить совместимость трёх рабочих мест

  1. В тестовом контуре сохраните минимум один заказ в совместимой конфигурации. Запишите его номер и сумму до изменения настроек.
  2. Последовательно проверьте четыре случая: API v1 + клиент v1; API v1 + клиент v2; API v2 + клиент v1 без адаптера; API v2 + клиент v1 с адаптером. Для изоляции сначала меняйте клиента одного рабочего места, остальные оставляйте в рабочем состоянии.
  3. Отдельно проверьте смешанную конфигурацию: API v2, витрина v2, выдача v1, поддержка v1, адаптер включён. Проследите один заказ через все три места. Сравните идентификатор, статус и сумму, затем раскройте «Ответ API».
  4. Запишите, какие изменения относятся к интерфейсу, какие к контракту, а какие к данным. Укажите, какое наблюдение доказывает сохранность заказа, даже если одно место не смогло его прочитать.

80–90 минут. Принять промежуточное решение

Оформите дефекты и решение: допустить кандидата, вернуть на исправление или допустить при явно названных ограничениях. Решение должно ссылаться на проверки. Сохраните его в «Итоговом решении» и скачайте отчёт и журнал. На второй паре продолжайте с теми же данными.

Вторая пара · исправление, выпуск и поддержка

90–115 минут. Повторный тест и регрессия

  1. В тестовом контуре выберите сборку 1.5.1. Настройте совместимую конфигурацию, которую считаете подходящей для трёх рабочих мест. Данные автоматически не сбрасываются. Для граничных сценариев восстановите тестовые исходные данные отдельной кнопкой.
  2. Повторите найденные несоответствия с теми же данными и ожиданиями. В карточке нового результата укажите ссылку на исходный тест. При необходимости добавьте запись дефекта с результатом повторной проверки.
  3. Проведите короткую регрессию: поиск → карточка → корзина → промокод → оформление → выдача → поддержка. Добавьте проверку дробной цены и округления скидки. Различайте повторный тест конкретного исправления и проверку соседних функций.

115–135 минут. Выпустить и проверить рабочие данные

  1. Проверьте наличие контрольного рабочего заказа и актуальность снимка. Если пересоздаёте снимок, сохраните старый файл отдельно. Зафиксируйте состав, номер, сумму и статус заказа.
  2. В «Выпуске» запишите основание решения и остаточные риски, подтвердите проверку трёх мест и выполните выпуск. Переносятся только конфигурация, API, клиенты и адаптер. Тестовые заказы не переносятся.
  3. Переключитесь на рабочий контур. Выполните smoke-проверку трёх рабочих мест, сравните контрольную запись и остатки. Создайте новый рабочий заказ с кодом DEMO-002. Зафиксируйте его отдельно как запись после снимка.

135–160 минут. Разобрать три инцидента

Инциденты выполняйте в тестовом контуре. Перед каждым очистите корзину и задайте новую попытку. Сбой задаётся на экране «Выпуск» и действует один раз.

  1. INC-1, нет ответа до записи. Соберите корзину, включите соответствующий сценарий, оформите заказ. Проверьте список и журнал, затем обоснованно повторите. Посчитайте созданные заказы.
  2. INC-2, нет ответа после записи. Повторите с новым заказом. Сначала сравните список и ключ запроса с журналом, затем вернитесь к оформлению без изменения корзины и повторите запрос. Проверьте число заказов и повторное списание остатка. Опишите различие двух внешне похожих ситуаций.
  3. INC-3, остаток изменился. Соберите корзину, затем в панели установите остаток выбранного товара в выбранной точке равным нулю. Попробуйте оформить. Запишите результат и безопасное действие покупателя.

В поддержке оформите хотя бы одну заявку по INC-2: симптом, проверенные факты, решение и короткий ответ покупателю. Не обещайте возврат денег или сроки доставки: в модели нет оплаты и доставки.

160–175 минут. Сравнить возврат версии и восстановление данных

  1. Скачайте рабочий отчёт и журнал. Посчитайте рабочие заказы и запишите их идентификаторы.
  2. Верните предыдущую конфигурацию. Снова откройте рабочий контур и проверьте контрольный и новый заказы на трёх местах. Сравните количество, суммы, статусы и остатки.
  3. Только после фиксации результатов восстановите данные из снимка. Прочитайте предупреждение. Сравните список с состоянием до восстановления и со временем снимка. Если заказ после снимка отсутствует, опишите способ дальнейшей сверки по сохранённым доказательствам. Автоматического слияния снимка и новых заказов в стенде нет.
  4. Сформулируйте разницу между откатом конфигурации и восстановлением снимка. Посчитайте фактическую потерю заказов в модели и интервал времени между снимком и последней утраченной записью. Это измерение вашей сессии, а не норматив RPO или обещание реальной системе.

175–180 минут. Завершить протокол

В итоговом решении укажите конфигурацию, рекомендуемую для выпуска, доказательства, открытые риски и непроверенные области. Скачайте итоговые файлы. Каждый участник должен суметь объяснить один дефект, один случай несовместимости и разницу двух способов возврата.

Результат для сдачи

  1. pharmacy-report.md: сведения о команде, не менее 14 результатов проверок, включая граничные условия, совместимость и повторные тесты; карточки обнаруженных дефектов; одна заявка поддержки; обоснованное решение о выпуске. Повторённые результаты не заменяют непроверенные обязательные группы.
  2. pharmacy-session.json: журнал событий и сохранённые доказательства. Он помогает проверить версии, порядок действий и идентификаторы. Это не файл восстановления.
  3. pharmacy-prod-backup.json: снимок рабочего контура до выпуска. Храните его отдельно от журналов, чтобы не перепутать назначение файлов.
  4. Файлы можно сдать папкой или в Git-репозитории с понятным коммитом результата. Не включайте настройки браузера и посторонние данные.
  5. Если ведёте протокол отдельно, заполните report-template.md и приложите те же данные. Скриншоты можно использовать как дополнение, но они не заменяют шаги и расчёты.

Критерии проверки · 100 баллов

План, условия и воспроизводимость результатов20
Функциональные и граничные проверки, качество карточек дефектов25
Три рабочих места, контракт, адаптер и сохранность суммы20
Повторный тест, регрессия, выпуск и возврат20
Диагностика инцидента, доказательства и итоговое решение15

Оценивается качество доказательств. Обнаруженный дефект не является ошибкой студента. Вывод «всё работает» без выполненных проверок не подтверждает приёмку. Подмена факта ожиданием и выдуманные результаты недопустимы.

Границы модели и технические замечания

Вернуться к стенду