Привіт друзі! Минулого тижня підключився послухати DOU QA Voice Chat про тест дизайн – завжди цікаво, чим живуть інші тестери. І тут, серед інших питань, мені стало цікаво, чи створюють спікери traceability матриці? Чи може хоч хтось зі слухачів це робить?
Бо особисто я – ні 🤷♂️. І від того іноді почуваюсь лицеміром, бо це питання дуже часто питається на співбесідах, про матрицю розказують на QA курсах.
Як же так? В моєму розумінні, щоб створити таку матрицю та підтримувати її в актуальному стані, треба змусити аналітиків чи продакт овнерів записувати вимоги атомарно чи хоча б надавати кожній окремій вимозі унікальний ідентифікатор, який ми зможемо пізніше зв’язати з тест кейсом і побудувати власне матрицю. Я не зустрічав ще таких аналітиків, яким би така додаткова робота сподобалась. Тут хоча б просто з аналізом, описом вимог, нескінченними мітингами та купою уточнюючих запитань встигнути.
Та й тестери, якщо працюють добре – роблять це без матриці, об’єктивно розуміючи, які вимоги покриті, а які ні. Про що я як раз і кажу на курсах – traceability, це впершу чергу можливість адекватно зв’язати різні документи до купи, щоб розуміти, де знайти вимоги, що покриває тест чи (що більш актуально) на основі чого ми вирішили, що очікуваний результатат в дефекті має бути саме такий.
Що ж тоді залишається? Є концепція, про яку всі знають, але ніхто не користується? Може настав час визнати її застарілою та поховати десь між перфокартами та дисковими телефонами?
Поділіться своїми думками!