🤓 Мода на Defect Prevention «повертається»Якщо глянути на ринок, ми вже купу років рухаємось в напрямку підвищення значення упередження чи хоча б ранньої ідентифікації дефектів. Принаймні порівняно із їх знаходженням на етапі автоматизованого чи мануального тестування.На це можна впливати різними способами:🔸 за допомогою shift-left практик (аналіз вимог, code review , unit testing і тд)🔸 тісною комунікацією в команді🔸 аналітикою Коли ви бачите, що:✅ в командах поступово росте попит на SDETів, ✅вводяться автоматизовані практики оцінки коду вбудовані в процес CI/CD/DevOps [quality gates management], ✅ інженерні підходи з Extreame Programming щодо організації архітектури та коду набувають більшого значення для масштабування систем, ✅ практики аналізу lessons learned вписуються в регулярну роботу команд над спрінтами [retrospectives]✅ роль тестувальника поступово зменшується як виконавця [як варіант, із залученням ШІ] і збільшується як ролі яка допомагає тімі налагоджувати якість ➡️ це все про різні ступені Defect PreventionТак от, якщо виходить, що ринок і не відхилявся від руху в defect prevention, то от по скілам, які качати — воно було досить розмазано і згадувалось тільки в загальних фразах в книжках та статтях. З 2025го ж року — алілуя — в ISTQB ці практики нарешті зібрали в цілісний напрямок і озвучили, що вже з Middle+ рівня тестувальник в команді може: ✔️ робити health check свого проєкту в розрізі defect prevention, ✔️ допомогти ввести всій команді конкретні практики (розглядається, які саме),✔️ поміряти в метриках корисні речі на кшталт phase contaiment, defect leackege, і на основі показників динаміки дефектів порахувати cost-effectiveness різних практик (розглядається, як саме це зробити).🍒Почитати про цю смакоту самостійно можна в силабусі ISTQB Advanced Test Analyst v4.0 (Section5).🦄 А розібратись детально з прикладами і копнути глибше — велкам на наш курс підготовки до сертифікації, що стартує вже в березні.