1. “Після цього клікати – не обов’язково” (і забули протестити клік)Ніхто не любить повзати по кожній кнопці. Але от кнопка в стилі “Submit” без жодної дії і вже гаряче.❌ Погано:Протестували валідацію форми, але не перевірили, що кнопка взагалі щось робить після неї.✅ Добре:Завжди перевіряй поведінку після дій, навіть якщо “начебто вже все валідне”.2. “Все працює, бо я так кажу” (і нуль тест-кейсів)Тестувати “на око” – це класика. Але нагадаємо: “Looks good to me” – не тест-кейс.❌ Погано:Прийомка без документації, без кейсів, без чеклістів.✅ Добре:Базові кейси в Notion/Google Doc/QA Touch – це вже ок.Все, що можна автоматизуй або хоча б стандартизуй.3. “Тестував на Dev, на Staging ще не бачив”Сценарій: на деві все супер, на проді зламалась оплата. Бо в staging інші налаштування, а ти туди не заходив.❌ Погано:Перевірка тільки на одному середовищі.✅ Добре:Завжди уточнюй, на яких енвайронментах треба перевірити.Проганяй критичні кейси скрізь, де вони можуть відрізнятись.4. “Щось не працює, але я не зберіг скрін”Скриншот, відео, логи, дані – усе це важить більше, ніж “ну воно просто не працює“.❌ Погано:Репорт: “Помилка при логіні” без опису, даних та відтворення.✅ Добре:Додавай все: що робив, у якому браузері, які кроки, які очікування.Скрін – це добре, але ще краще відео з Loom.5. “Я думав, що це фіча” (і не спитав ні в кого)Нічого страшного, що користувач не може вийти з кабінету. Це ж фіча. Мабуть.❌ Погано:Здогадки замість уточнень.✅ Добре:Питай: у продактів, у тімлідів, у дизайнерів.Краще уточнити, ніж закрити баг, який закриє вам карму.QA – не про те, щоб знайти баг. А про те, щоб не пропустити критичне лайно в прод. Іноді дрібна неуважність створює більше проблем, ніж баг в коді.Тому тестуй ретельно, думай системно і бережи скріншоти ❤️#codica_adviceTikTok | Instagram | Telegram