Трассируемость и покрытие требований

Трассируемость требований (requirements traceability) - возможность проследить требование от его источника через проектирование, реализацию и тесты до результатов тестирования и обратно. Готел и Финкельштейн в 1994 году определили её как возможность описать и проследить жизнь требования в прямом и обратном направлении. Словарный стандарт ISO/IEC/IEEE 24765 определяет трассируемость в общем виде как степень, в которой можно установить связь между двумя или более продуктами процесса разработки.

В тестировании трассируемость - это связи между базисом тестирования (требованиями, юзер стори, рисками) и тестовыми артефактами (тест-кейсами, результатами тестов, дефектами). Силлабус ISTQB Foundation Level (версия 4.0.1, раздел 1.4.4) считает установление и поддержание такой трассируемости на всём протяжении процесса тестирования условием эффективного мониторинга и контроля тестирования. На трассируемости основаны два показателя, которые вычисляет система управления тестированием: покрытие требований и набор тестов, которые затрагивает изменение.

Какую задачу решает трассируемость

Набор требований и набор тест-кейсов могут существовать рядом без всякой связи между собой. Каждый из них может быть полным сам по себе, и всё равно на следующие вопросы ответа нет:

• у каких требований нет ни одного теста;
• какие требования проверены в этом релизе и с каким результатом;
• какие тест-кейсы нужно выполнить снова, когда меняется требование;
• зачем существует тест-кейс и нужен ли он ещё;
• какие требования затронуты открытыми дефектами релиза.

Силлабус ISTQB называет применения трассируемости в тестировании: оценка покрытия, определение влияния изменений, поддержка аудитов и ИТ-управления (IT governance), а также более понятные отчёты о ходе и завершении тестирования - в них можно показать состояние элементов базиса тестирования: требований, которые прошли свои тесты, не прошли их или ждут выполнения тестов.

Направления трассируемости

У трассируемости два направления.

• Прямая трассируемость (forward traceability) идёт от требования к рабочим продуктам, которые из него выведены: проекту, коду, тест-кейсам, результатам тестов. Она отвечает на вопрос «реализовано и проверено ли это требование?».
• Обратная трассируемость (backward traceability) идёт от рабочего продукта назад к требованию, из которого он происходит. Она отвечает на вопрос «зачем существует этот тест-кейс, этот фрагмент кода?».

Если по связям можно пройти в обоих направлениях, трассируемость называют двусторонней (bidirectional). В системе управления тестированием связь требования с тест-кейсом обычно одна запись, и её читают в обе стороны.

Готел и Финкельштейн разделили трассируемость и по этапам. Трассируемость до спецификации требований (pre-requirements specification traceability) связывает требование с его происхождением: людьми, документами и решениями, из которых оно взялось. Трассируемость после спецификации требований (post-requirements specification traceability) связывает требование с тем, что из него следует: проектом, реализацией, тестами. Их исследование с участием более 100 практиков показало, что большинство проблем, которые приписывают плохой трассируемости, связаны с первым видом. Управление тестированием имеет дело в основном со вторым.

Цепочка связей

В тестировании трассируемость образует цепочку от требования к дефекту:

Requirement PAY-7 "An expired card is rejected"
 |
 +-- Test condition: payment with an expired saved card
       |
       +-- Test case TC-13 "Pay with an expired card"
             |
             +-- Result in run "Release 2.4.0, Safari": failed
             |     |
             |     +-- Defect BUG-310
             |
             +-- Result in run "Retest, 2.4.1, Safari": passed

Каждую связь в цепочке создаёт своя активность. Связь требования с условием тестирования появляется при анализе тестирования, связь условия с тест-кейсом - при проектировании тестов, связь тест-кейса с результатом - при выполнении, связь результата с дефектом - при регистрации дефекта. Цепочка полна, только если каждая активность записывает свою связь.

Важна детализация связей. Связь целой спецификации с набором тестов ничего не говорит о покрытии. Связи полезны, когда соединяют отдельные элементы с идентификаторами: пронумерованное требование, юзер стори, критерий приёмки - с отдельными тест-кейсами.

Матрица трассируемости

Матрица трассируемости (traceability matrix) - таблица, которая показывает связи между двумя видами элементов, например требованиями и тест-кейсами. Строки - элементы одного вида, столбцы - другого, отметка на пересечении означает связь. Пример ниже охватывает пять требований и шесть тест-кейсов:

Из матрицы прямо читаются два вида пробелов:

• строка без отметок - требование без тестов: PAY-8 не покрыто;
• столбец без отметок - тест-кейс без требования: TC-16 не связан ни с одним из перечисленных требований. Он может проверять требование, которого нет в списке, а может быть устаревшим тестом.

Система управления тестированием хранит связи, а не матрицу. Матрица - одно из представлений, вычисленных из связей, вместе со списками непокрытых требований, тест-кейсов без требований и состоянием каждого требования в определённом прогоне.

Связи «многие ко многим»

Связи требований с тест-кейсами - «многие ко многим». Требование обычно проверяют несколько тест-кейсов: у PAY-7 есть TC-13 для самого отклонения и TC-14 для сообщения, которое видит пользователь. Тест-кейс может проверять несколько требований: TC-12 оплачивает сохранённой картой и заодно проверяет, что чек приходит по электронной почте, поэтому он связан с PAY-6 и PAY-9.

От этого зависит, как состояние требования в прогоне выводится из результатов его тест-кейсов. Распространённое правило:

• требование не пройдено, если не пройден хотя бы один связанный с ним тест-кейс;
• требование пройдено, если все связанные с ним тест-кейсы выполнены и пройдены;
• иначе требование проверено не полностью: часть его тест-кейсов заблокирована, пропущена или ещё не выполнялась.

По этому правилу непройденный TC-12 сразу помечает два требования как непройденные. Поэтому отчёт по требованиям и отчёт по тест-кейсам дают для одного прогона разные числа, и оба верны.

Покрытие требований

Покрытие требований (requirements coverage) - доля требований, покрытых тестами. В общем виде глоссарий ISTQB определяет покрытие (coverage) как степень, в которой набор тестов задействует заданные элементы покрытия, выраженную в процентах. Для покрытия требований элементы покрытия - это требования.

Значение зависит от того, что считать «покрытым», и распространены три варианта:

Для матрицы выше и прогона, в котором TC-11, TC-12, TC-13 и TC-15 пройдены, а TC-14 не пройден:

• покрытие по связям: у 4 из 5 требований есть тест-кейс (у PAY-8 нет), 80 процентов;
• покрытие по выполнению: у тех же 4 требований есть выполненный тест-кейс, 80 процентов;
• покрытие по прохождению: у PAY-5, PAY-6 и PAY-9 все тест-кейсы пройдены, у PAY-7 есть непройденный, итого 3 из 5, 60 процентов.

Отчёт указывает, какой вариант он использует.

Ограничения покрытия требований

Покрытие требований считает связи, а не глубину проверки. Требование с одним поверхностным тест-кейсом и требование с двадцатью тест-кейсами, которые проверяют все границы, одинаково считаются покрытыми. Покрытие 100 процентов означает, что нет требований без тестов. Оно не означает, что требования проверены достаточно.

Все требования считаются с одинаковым весом. На практике покрытие часто показывают отдельно для требований разного приоритета или риска: «все требования высокого риска покрыты и пройдены» говорит больше, чем «покрыто 92 процента требований».

Показатель полон настолько, насколько полон список требований. Поведения, которое никто не записал как требование, в нём нет, каким бы важным оно ни было. Техники, которые позволяют получить тест-кейсы, проверяющие требование в глубину, описаны в серии о тест-дизайне, начиная со статьи Классы эквивалентности и граничные значения.

Анализ влияния

Анализ влияния (impact analysis), в формулировке глоссария ISTQB, - определение всех рабочих продуктов, которые затрагивает изменение, включая оценку ресурсов, нужных для его выполнения. В тестировании он отвечает на вопрос: какие тесты нужно обновить и выполнить снова после этого изменения?

При наличии трассируемости анализ влияния идёт по связям:

Change: requirement PAY-7 now also rejects cards that expire this month
 |
 +-- Linked test cases: TC-13, TC-14       -> review and update
 +-- Their open defects: none
 +-- Related requirements: PAY-6           -> its test case TC-12 goes to regression

Без связей затронутые тесты ищут поиском по текстам тест-кейсов, и тесты, которые описывают поведение другими словами, теряются.

Силлабус ISTQB связывает анализ влияния с регрессионным тестированием: анализ влияния помогает определить объём регрессионного тестирования после изменения. Связи требований с тестами дают один источник сведений о влиянии. Другой источник - код: инструменты, которые записывают, какие тесты выполняют какие части кода, могут выбрать тесты, затронутые изменением кода. Два источника дополняют друг друга: первый отражает изменения замысла, второй - изменения реализации. Повторное и регрессионное тестирование в прогонах описано в статье Тестовый прогон.

Поддержание трассируемости

Связи теряют ценность, если их не поддерживать. Обычные причины известны заранее:

• неустойчивые идентификаторы: требование, перенумерованное после реорганизации спецификации, разрывает все свои связи;
• изменённые требования: связь с требованием, текст которого поменялся, по-прежнему существует, хотя тест-кейс мог перестать ему соответствовать;
• поздно созданные связи: связи, добавленные перед аудитом, по памяти, а не при проектировании тестов.

Практики, которые с этим справляются, следуют из причин. У требований и тест-кейсов неизменяемые идентификаторы. Связь создаёт тот, кто проектирует тест-кейс, в момент проектирования. Когда требование меняется, его связи помечаются для проверки, пока кто-то не подтвердит, что тест-кейсы ему по-прежнему соответствуют. Записывается версия требования, для которой написан тест-кейс.

Требования часто хранятся не в том инструменте, что тест-кейсы: в системе управления требованиями, таск-трекере, документе. Для обмена требованиями между инструментами разных производителей консорциум Object Management Group (OMG) публикует формат Requirements Interchange Format (ReqIF) на основе XML; его текущая версия 1.2 вышла в июле 2016 года. У каждого требования в файле ReqIF есть идентификатор, который не меняется от обмена к обмену, поэтому связи можно сохранить при повторном импорте требований.

Покрытие требований и покрытие кода

Покрытие требований и покрытие кода оба называются покрытием, но измеряют разное.

Каждая мера находит пробелы, которые другая найти не может. Покрытие кода не найдёт требование, которое так и не реализовали: покрывать нечего. Покрытие требований не найдёт код, который не выполняет ни один тест. Их используют вместе: покрытие требований - для вопроса «проверено ли всё, что требуется?», покрытие кода - для вопроса «выполняется ли тестами всё, что написано?». Уровни тестирования и их типичные меры описаны в статье Уровни автоматизации и пирамида тестов.

Термины

Источники

• ISTQB Certified Tester Foundation Level Syllabus v4.0.1, ISTQB, 2024(откроется в новой вкладке) (на английском)
• Глоссарий ISTQB(откроется в новой вкладке) (на английском)
• An analysis of the requirements traceability problem, O. Gotel, A. Finkelstein, 1994(откроется в новой вкладке) (на английском)
• ISO/IEC/IEEE 24765:2017, Systems and software engineering, Vocabulary(откроется в новой вкладке) (на английском)
• Requirements Interchange Format (ReqIF), version 1.2, OMG(откроется в новой вкладке) (на английском)