Когда требования к проекту меняются «на лету» и у вас нет под рукой средств контроля реализации каждого отдельного требования к функции или модулю, перед вами встает вопрос: как провести анализ покрытия? Одним из инструментов, которые наша команда контроля качества использует в таких проектах, является матрица прослеживаемости.
На данный момент мы используем матрицы уже более 2,5 лет. За это время мы смогли оценить преимущества этого инструмента, а также адаптировать его под наш проект.
Что такое матрица прослеживаемости?
По определению, матрица прослеживаемости — это двумерная таблица, содержащая соответствие между функциональными требованиями продукта и подготовленными тест-кейсами.На пересечении соответствующей строки и столбца ставится отметка, указывающая, что данное требование покрывается данным тест-кейсом.
Таким образом, таблица дает наглядное отображение двух параметров:
- наличие в системе требований, которые еще не были покрыты (если требование не имеет ни одного пересечения с тест-кейсами (достаточное условие);
- Есть ли в системе избыточное тестирование – если требования имеют несколько пересечений (необходимое условие).
В нашем проекте мы используем матрицы трассируемости не только для оценки покрытия, но и для определения взаимосвязи между задачами разработки, требованиями и артефактами тестирования.
Таким образом, матрица имеет вид таблицы, каждая строка которой содержит:
- номер и описание задачи разработки из трекера задач;
- логический блок, к которому относится задача (необязательно);
- атомарные требования или критерии приемки;
- приоритет;
- номер и описание соответствующего тестового артефакта.
Поскольку мы используем трекер задач Jira, Zephyr от Jira для тестовой документации и систему управления требованиями Confluence, все сущности синхронизируются, и эта отслеживаемость позволяет нам:
- визуализировать текущее состояние реализации;
- разбить требования на более атомарные и структурировать их;
- отслеживать, есть ли требования, разработка которых еще не запланирована (пропуск реализации);
- отслеживать, выполняется ли требование на данный момент;
- отслеживать, покрывается ли требование тестовым примером (пропуская тестирование);
- четко отображать приоритетность требований.
Варианты связей в матрице прослеживаемости
Связь между требованием и тестовым примером может быть:- 1 к 1 (атомарное требование, которое покрывается одним тестовым примером, этот тестовый пример охватывает только это требование);
- от 1 до n (требование, которое покрывается несколькими тестовыми примерами, эти тестовые сценарии охватывают только это требование);
- от n до n (требование, которое покрывается несколькими тестовыми примерами, эти тестовые сценарии охватывают это и другие требования).
- Когда одно требование в матрице прослеживаемости покрывается несколькими тестами, это может указывать на избыточность тестирования.
В этом случае необходимо проанализировать, насколько атомарно требование.
- если, выполняя все тест-кейсы, мы обеспечиваем полное покрытие, а сами тест-кейсы не дублируют друг друга, это не будет избыточным тестированием.
Особенности оценки покрытия с использованием матриц прослеживаемости
Если для оценки покрытия использовать метрику «отношение количества требований к количеству тестовых артефактов», то связи в матрице должны быть «1 к 1», а требования должны быть максимально декомпозированы.Пример.
У нас есть неатомарное требование: «Пользователь должен иметь возможность изменять и форматировать письмо в текстовом редакторе».
Одного тестового примера явно будет недостаточно, но если в матрице связан только один артефакт, будет визуальное впечатление, что требование покрыто.
Поэтому лучше:
- разделите это требование в матрице на отдельные атомарные функции текстового редактора;
- написать критерий приемки для каждой функции;
- создать тестовый артефакт для каждого критерия;
- Если несколько атомарных требований можно охватить одним контрольным списком, вы сможете избежать ненужной фрагментации, сэкономив ресурсы.
При этом тест-кейсы и чек-листы для каждого неатомарного требования составляются одновременно, то есть каждое требование в матрице либо полностью покрыто артефактами, либо не покрыто вообще.
При составлении матриц целесообразно придерживаться рекомендации, что декомпозиция каждого требования в отдельной матрице должна быть примерно равной, то есть одна таблица не должна содержать требований, часть из которых требует 5 тест-кейсов, а часть — один тест. случай.
Оценка покрытия в этом случае рассчитывается отдельно для каждой матрицы.
Поскольку наша проектная документация может иметь разный вид для каждой фичи и даже описание одной фичи может содержать UML, диаграммы, варианты использования и диаграммы переходов, а проект содержит более 40 объемных функционалов, мы решили разработать отдельную матрицу для каждой функции.
модуль или функцию, чтобы не потерять ни одно из преимуществ этого инструмента.
Оценка покрытия также рассчитывается отдельно для каждого модуля или функции.
При таком подходе мы можем использовать описанную выше метрику: «количество требований на количество тестовых артефактов».
Даже если у нас есть соединения от 1 до n, от n до n, у нас есть несколько компонентов, каждый из которых можно использовать в нескольких модулях.
Требования и критерии приемки описаны в каждой матрице, а тестовый артефакт используется отдельно.
Наши матрицы также хранятся в системе управления требованиями Confluence — каждая матрица располагается в структуре как дочерняя страница той фичи, для которой она разрабатывалась.
Также все матрицы собраны на одной странице для удобства при оценке покрытия всей заявки.
Создание и ведение матрицы
Создание матрицы входит в наш рабочий процесс для работы над задачами аналитики.
Когда мы получаем информацию о новой функции, аналитик нашей команды создает задачу в трекере задач и работает над ней вместе с владельцем продукта заказчика.
В процессе сбора и структурирования требований вся команда анализирует и задает дополнительные вопросы.
Когда требования сформулированы, документированы и подтверждены заказчиком, руководитель группы разработки создает задачи на разработку этой функции, и группа тестирования может приступить к созданию матрицы трассировки.
И здесь можно выделить следующие этапы составления Матрицы прослеживаемости:
- Вначале требования декомпозируются и подлежат расстановке приоритетов командой контроля качества и/или владельцем продукта.
Результатом этого этапа является структурированный и расставленный по приоритетам список всех требований к данному функционалу.
- Вторым этапом будет общение с командой разработки и назначение задач из трекера задач разработки в матрицу согласно актуальным требованиям.
В результате мы можем отслеживать прослеживаемость требований и задач разработки.
- Третий этап — разработка тест-кейсов и чек-листов.
Этот этап проводится либо перед тестированием, либо во время тестирования конкретной задачи.
Если функционал новый и интерфейс будет меняться, то могут быть случаи, когда лучше описать шаги непосредственно перед тестированием задачи.
Если функционал реализации аналогичен одной из уже существующих фич, то можно приступать к описанию тест-кейсов с шагами сразу после рассмотрения и декомпозиции требований.
- 4 этап – наполнение матрицы тест-кейсами.
По результатам всего процесса мы получаем задачи на разработку, тест-кейсы для тестирования и матрицу трассируемости, объединяющую их и требования.
Задача разработки требований закрыта.
- 5 этап – поддержание матрицы в актуальном состоянии.
Изменения должны вноситься всякий раз, когда изменяются требования.
Также следует учитывать интеграционные связи между двумя матрицами, описывающими разные функции или модули, и при внесении изменений в одну обязательно проверять, есть ли необходимость редактирования второй.
Трудности в работе с матрицей прослеживаемости
- Обновлять
Матрица будет полезна только в том случае, если ее всегда поддерживать в актуальном состоянии.
На нашем проекте с часто меняющимися требованиями обновление занимало много времени, но если матрица не обновляется, она становится не только бесполезной, но и создает путаницу.
Как они решили : Мы частично решили проблему с частым изменением требований и перенесли этап создания матрицы на тот момент, когда требования уже были рассмотрены командой и подтверждены заказчиком.
Команда решила, что аналитик будет обновлять требования не только на самой странице описания функции, но будет находить и обновлять их в матрице, выделяя другим цветом.
Это помогло всей команде не потерять изменения, а команде QA в частности — увидеть, какие тест-кейсы требуют обновления.
- Временные ресурсы
Проект может иметь срочный релиз и одновременно работать с новыми требованиями, и все ресурсы QA направлены на тестирование, а не на работу с требованиями.
Таким образом, увеличивается задолженность за испытательную документацию.
Как они решили : Если все QA-специалисты заняты тестированием приоритетных задач, мы откладываем создание матрицы для конкретной фичи.
Максимально переносится на момент тестирования первой задачи по этой фиче, и в этом случае матрица заполняется тест-кейсами по мере тестирования задач, в которых реализована фича.
QA-специалист включает в оценку время не только на написание самих тест-кейсов, но и время на разработку матрицы.
- Ээффективность.
Если проект небольшой и все требования представлены в виде структурированного технического задания, а тест-кейсы создаются сразу для каждого требования, то матрица трассируемости в нашей форме будет лишь дублировать информацию и будет пустой тратой ресурсов.
Поэтому для оценки охвата необходимо использовать стандартную матрицу, описанную в определении.
Удобства
- Матрица позволяет контролировать выполнение требований, следить за тем, чтобы все требования были разработаны и протестированы и ничего не было упущено.
- Матрица помогает команде контроля качества отслеживать, есть ли задолженность по тестовой документации и какие конкретные требования еще не покрыты тест-кейсами.
- Этот инструмент используется аналитиками и командой контроля качества для отслеживания изменившихся требований.
- На проекте матрицы прослеживаемости стали использовать не только мы, но и продакт-владелец на стороне заказчика.
Поэтому они убедились, что все требования присутствуют и они верны, и отслеживали то, что уже реализовано, с помощью матрицы.
Матрицы позволили нам в некоторой степени сделать процесс разработки и тестирования более прозрачным.
-
Что Нового В Электронных Таблицах
19 Oct, 24 -
Powershell: Машина Против Человека
19 Oct, 24 -
Вершина Нашего Развития
19 Oct, 24
