1. “Тест працює тільки в мене на машині”❌ Погано:driver.find_element(css: '.button') – Але кнопка існує лише локальноЛокальний Chrome 120, локальна локаль, локальні баги. А на CI падає, як вежа Дженги в день дедлайну.

✅ Добре:— перевіряй автотести в середовищі, наближеному до бойового— запускай у Docker або на CI/CD— уникай прив’язки до локальних шляхів, специфічних таймінгів і dev-only config’ів2. “wait(1)” вирішить усе❌ Погано:time.sleep(3)Іноді здається, що більше сну – більше стабільності. Насправді – це антистрес, а не тестування.

✅ Добре:— використовуй explicit wait з умовами— мінімізуй sleep, бо в CI це 90% проблем3. “Крутий фреймворк, але без звітів”

Тести запустились, щось там пролетіло, щось впало – а що саме? Невідомо.

✅ Добре:— генеруй читабельні репорти (Allure, TestNG, HTML-звіти)— скриншоти на фейлах – маст хев4. “У нас є PageObject, але там 500 рядків”

Page Object Pattern – супер. Але коли вся логіка тесту, бізнес-логіка, верстка і душа QA живе в одному класі – то це вже Spaghetti Object.

✅ Добре:— тримай Page Object чистим— логіку – в окремі helper-и або step definition-и— тест має бути «що перевіряємо», а не «як усе клікати»5. “Автотести є – але їх ніхто не запускає”

Тести написані, додані в репо… але з 2022 року не запускались. Або запускаються лише вручну “на реліз“.

✅ Добре:— інтегруй з CI/CD: GitHub Actions, GitLab CI, Jenkins— запускай хоча б smoke тести на pull request📌 Висновок

Автоматизація – це не про “писати тести“, а про робочу систему, яка регулярно щось перевіряє без вашої участі. Не будь тим, хто пише автотести тільки для галочки (і лише в README).#codica_adviceTikTok | Instagram | Telegram