“Не баг, а фіча”: жарт чи реальність? У світі QA та AQA це словосполучення стало майже мемом. Скільки разів ми чули від розробників чи менеджерів пояснення, що “це не баг, а фіча”? Часто цей вислів викликає усмішку, але за ним може стояти глибший сенс. 👉 Коли це справді фіча? Іноді поведінка продукту, яка здається багом, насправді є продуманим функціоналом. Наприклад, специфічний UX-рішення, яке здається дивним, але має конкретну бізнес-логіку. Тому наш обов’язок як QA — розуміти продукт, його вимоги та цілі. 👉 А коли баг маскується під фічу? Трапляється, що команда через обмеження в часі чи ресурсах ухвалює рішення залишити проблему без виправлення. Тут важливо ставити запитання: • Чи ця “фіча” покращує досвід користувача? • Чи відповідає вона бізнес-логіці? • Чи впливає на інші частини продукту? Наш підхід як QA/AQA: 🚦 Завжди досконало вивчати вимоги. 🕵️‍♂️ Перевіряти, як поведінка продукту узгоджується з очікуваннями. 🤝 Вести відкритий діалог із командою. 📋 Якщо щось виглядає неоднозначно, документувати й нагадувати про ризики. “Не баг, а фіча” — це не просто жарт, це можливість розібратися, наскільки ми як QA можемо впливати на якість продукту. Бо наша мета — не просто знайти баги, а допомогти команді створити продукт, яким користувачі будуть задоволені. А у вас були випадки, коли “фіча” з часом таки ставала багом? Поділіться своїми історіями в коментарях! 👇 #QA #AQA #QualityAssurance #BugOrFeature #Тестування