QA спільнота

Хто насправді винен у багах? комахи ж res.cloudinary.com/...​/yuqrua2hrcigb6tslt9g.jpg

QA is a journey, not a destination!

Тут не може бути єдиної відповіді, бувають різні кейси. З іншого боку, якщо таска не відповідає Acceptance Criteria, або текст юзер сторі по дібільному написан, QA має одразу говорити, а не тестити шо є і кидати в done.

Які інструменти в майбутньому допоможуть уникнути таких багів? Де недоліки методології, що пропустила таке? Де недоліки в процесах, що проблема виникла та не була відловлена?

багмени — міфологічні істоти що живуть в клавіатурі та псують код.

автору повідомлення бажаю рухатися далі в ІТ, спробуй як автоматизатор або розробником

Це 100% правда. Особливо відгукнулася фраза про те, що «компанія цінує швидкість релізів більше, ніж стабільність». Мені здається, це корінь 90% проблем і вигорання в QA.

Це вічне питання! Відповідальність завжди спільна, але роль QA — бути не «крайнім». Якщо баг прослизнув, це означає, що процес дав збій. Можливо, не вистачило часу, можливо, вимоги були нечіткі, а можливо, не було інструментів для виявлення.

«Перед публікацією — перечитуйте, що ви публікуєте» — це щоб повністю позбавитися помилок ))

Підхід «знайди крайнього» не є здоровим та продуктивним.

Во всем виноваты люди — человеки. Баги богов. Боги багов.

У нормальних командах з гарною інженерною культурою quality assurance — відповідальність всієї команди. І неважливо, чи є у такій команді dedicated QA, чи його немає

CTO кожного разу робить висновок «посилити тестування».

Задача RCA — визначити першоджерело проблеми. Якщо, наприклад, розробник провів рефакторинг, щоб перевикористати готове рішення, і пропустив повідомити тестувальників, то тестували лише те, що було змінено в задачі.

Задача CTO та менеджменту — організувати процес так, щоб зменшити кількість помилок Так він це і робить Коли баг вилітає в прод, CTO перш за все дивиться на нього.