1. “Після цього клікати – не обов’язково” (і забули протестити клік)

Ніхто не любить повзати по кожній кнопці. Але от кнопка в стилі “Submit” без жодної дії і вже гаряче.❌ Погано:Протестували валідацію форми, але не перевірили, що кнопка взагалі щось робить після неї.

✅ Добре:Завжди перевіряй поведінку після дій, навіть якщо “начебто вже все валідне”.2. “Все працює, бо я так кажу” (і нуль тест-кейсів)

Тестувати “на око” – це класика. Але нагадаємо: “Looks good to me” – не тест-кейс.❌ Погано:Прийомка без документації, без кейсів, без чеклістів.

✅ Добре:Базові кейси в Notion/Google Doc/QA Touch – це вже ок. Все, що можна автоматизуй або хоча б стандартизуй.3. “Тестував на Dev, на Staging ще не бачив”

Сценарій: на деві все супер, на проді зламалась оплата. Бо в staging інші налаштування, а ти туди не заходив.❌ Погано:Перевірка тільки на одному середовищі.

✅ Добре:Завжди уточнюй, на яких енвайронментах треба перевірити. Проганяй критичні кейси скрізь, де вони можуть відрізнятись.4. “Щось не працює, але я не зберіг скрін”

Скриншот, відео, логи, дані – усе це важить більше, ніж “ну воно просто не працює“.❌ Погано:Репорт: “Помилка при логіні” без опису, даних та відтворення.

✅ Добре:Додавай все: що робив, у якому браузері, які кроки, які очікування. Скрін – це добре, але ще краще відео з Loom.5. “Я думав, що це фіча” (і не спитав ні в кого)

Нічого страшного, що користувач не може вийти з кабінету. Це ж фіча. Мабуть.❌ Погано:Здогадки замість уточнень.

✅ Добре:Питай: у продактів, у тімлідів, у дизайнерів. Краще уточнити, ніж закрити баг, який закриє вам карму. QA – не про те, щоб знайти баг. А про те, щоб не пропустити критичне лайно в прод. Іноді дрібна неуважність створює більше проблем, ніж баг в коді. Тому тестуй ретельно, думай системно і бережи скріншоти ❤️ #codica_adviceTikTok | Instagram | Telegram