Привіт друзі! Нещодавно, читаючи якусь статтю про тестування зустрів термін Defect triage, який раніше не чув і не використовував. Тож вирішив розібратись, що воно таке, бо некомфортно розуміти, що в тестуванні є щось, що я не знаю 😆 І з вами поділитись.
Якщо коротко, то за крутою назвою ховається звичайний менеджмент дефектів, або сортування багів. Це періодичний процес аналізу багів в вашому бек лозі, оновлення пріоритетів, додавання деталей.
ISTQB глосарій про цей термін знає (https://glossary.istqb.org/en_US/search?term=defect%20triage), але використовує більш вживаний defect management.
З мого досвіду – не в багатьох проєктах я робив сортування дефектів, бо банально їх не було настільки багато, щоб ще й сортувати 😄
Але один одразу згадую. Коли я за нього взявся, в джирі вже був величезний технічний борг, баги висіли відкриті роками, але оскільки розробників було мало, то фіксились лише найкритичніші, залишаючи дріб’язок нащадкам. Налагодивши більш-менш процес тестування і покращивши якість продукту, одним сонячним ранком я вирішив вичистити ці авгієві конюшні – хоча б просто перечитати все. І коли почав читати, виявив, що більшість багів не просто не актуальні, а взагалі заводились на попередню версію продукту. Тому я почав їх закривати. І закрив десь сотню, як тут до мене в паніці прибіг продакт овнер і кричить
- що ти робиш? Я отримав нотифікації, що ти закриваєш баги!
- їм по шість років. Скоро в школу підуть. Відпусти і забудь
- ні, так не можна! Вони нам дуже дорогі, поверни все як було
Які висновки я зробив?
✅ не допускати такої ситуації – не збільшувати технічний борг
✅ defect management не робиться одноосібно. В усіх статтях написано, що це має бути committee – колегіальне рішення, тоді ніхто не змусить вас перевідкривати 100 багів шестирічної давнини 😆
А ви робите triage? Чи є в ньому потреба?