🧐 Усі ми чули про risk-based стратегію тестування, але не завжди зрозуміло, що має в ній робити "пересічний тестувальник". На це питання нам допомагає відповісти ISTQB Advanced Test Analyst. Ця сертифікація не концентрується на високих матеріях керування ризиками, як Test Manager, але дає чіткі настанови для звичайних проєктних буднів.🫵 Отже, для початку ризики треба ідентифікувати. Якщо ви не Лід, то працюємо саме з product risks, тобто потенційними проблемами в роботі продукту або технологічній складовій. Ідентифікуються ризики, в першу чергу, на етапі планування та аналізу фітчів (у випадку Scrum це буде частіше за все на sprint planning та refinement наших user stories). Участь в ідентифікації бере вся команда — на загальному мітингу або кожен окремо. Є навіть описані підходи, як саме це організувати:• Expert interviews• Independent assessments• Retrospectives• Risk workshops• Brainstorming• Checklists❗️Зверніть увагу, що в оновленому АТА4.0 ці техніки не розписуються детально, але беруть участь в питаннях іспиту.Основне питання від колег зазвичай звучить так: "А що саме може бути ризиком? Як я маю його побачити?" Ділимося, сьогодні з вами одним з підходів — на основі Risks Categories від Рекса Блека. Ваша задача — дивлячись на кожну фітчу, прикинути що може потенційно призвести до різних категорій фейльорів. За посиланнямвище ви знайдете ці категорії та фейльори.До речі, ідеально, якщо ви заводите ідентифіковані ризики окремими тікетами "Risk" в багтрекері та лінкуєте їх до фічів/сторей — тоді вони будуть в поточній роботі, а не мертвим вантажем десь у файлику чи на вікі.