traceability matrix что такое
Пример матрицы трассировки требований
Матрица трассировки — метод визуализации связей между элементами системы в форме таблицы.
Матрица трассировки создается путем связывания бизнес-требований с вариантами использования и сценариями тестирования, которые будут использоваться для их проверки. В процессе трассировки, отношения между бизнес-требованиями и вариантами использования + сценариями тестирования могут иметь следующий вид: один-к-одному, один-ко-многим или многие-к-одному. Трассировка требует уникальных идентификаторов для каждого требования и вариантов использования/сценариев тестирования. Трассировка обеспечивает полноту тестирования и подготавливает основу для планирования тестов. Матрица трассировки может быть самостоятельным документом или может быть включена как часть документации по требованиям или часть плана тестирования.
Примеры картинок с трассировочными матрицами
Пример 1 
Пример 2 
Пример 3 
Пример 4 
Инструкции:
В соответствии с лучшими практиками, бизнес-требования следует декомпозировать до мельчайших пакетов и нумеровать в соответствии со следующими правилами нумерации: BR001, BR002 и т.д. Для каждого бизнес-требования будет одно или несколько функциональных требований, которые должны соответствовать соглашению по нумерации для соответствующего бизнес-требования: FR001.01, FR001.02, FR001.03, FR002 и т.д. Функциональные требования должны быть декомпозированы до мельчайших пакетов.
Для каждого функционального требования будет существовать одна или несколько связанных технических спецификаций, которые должны соответствовать соглашению по нумерации для связанных функциональных требований: TS001.01.01, TS001.01.02, TS001.01.03 и т.д. Технические спецификации должны быть декомпозированы до мельчайших пакетов.
Для простоты, технические спецификации могут храниться в отдельной таблице.
ID Матрицы — уникальная последовательность для идентификации комбинации требований и связанных с ними вариантов использования.
# Бизнес-требования — номер бизнес-требования (в соответствии с документацией по требованиям), который идентифицирует критерии успеха, на основе которых будут выполняться тесты.
# Функциональные требования — идентификационный номер функционального требования (в соответствии с документацией по требованиям), которое исполняет указанное бизнес-требование.
# Вариант использования — идентификационный номер варианта использования, который будет использоваться для проверки соответствия бизнес-требований с функциональными требованиями. Этот параметр должен соответствовать ID в документе по требованиям. Поле является необязательным для заполнения.
# Сценарий тестирования — идентификационный номер тестового скрипта, который будет использоваться для проверки связанных бизнес или функциональных требований.
Вы можете создать таблицу со следующими столбцами и строками:
Матрица прослеживаемости требований
Введение в матрицу прослеживаемости требований
Определение матрицы прослеживаемости требований
Матрица отслеживаемости требований, обычно называемая RTM, представляет собой документ или таблицу, в которую включены требования клиентов к проекту в работе. Это простой тип матрицы со структурой строк и столбцов, который четко определяет, какие требования выполняются, а какие изменяются между процессами. Таким образом, в целом RTM мы отслеживаем контрольные примеры, касающиеся требований клиента, и просматриваем дефекты в требованиях во время процесса.
Почему требуется матрица прослеживаемости требований?
У RTM есть ряд преимуществ, прежде всего, как мы уже говорили выше, это используется для отслеживания требований клиентов, а также мы можем найти недостатки в требованиях, если таковые имеются. Кроме того, RTM обеспечивает качество проекта, поскольку этим устраняются различные дефекты, а также, если между тестами есть какие-либо изменения в требованиях, мы можем легко изменить это и сэкономить время и энергию. Эти вещи очень помогают завершить проект вовремя и быстрее.
Типы матрицы прослеживаемости требований
Давайте посмотрим на другую матрицу прослеживаемости.
Прямая трассировка
Обратное отслеживание
Это еще один тип матрицы, который гарантирует менеджеру, что масштаб проекта не расширен, или что строго соблюдаются требования, без добавления дополнительных случаев или функций, которые могут не являться частью проекта.
Двунаправленная секционная трассируемость
Этот тип прослеживаемости помогает менеджеру сопоставить требования к тестовым примерам для прямой и обратной прослеживаемости в одном документе. Таким образом, этот тип гарантирует, что все требования проверены должным образом.
Примеры матрицы прослеживаемости требований
Бизнес-требование №
Описание
Контрольные примеры
Контрольный пример 1: опция TS1.TC1 (BR1) выполнена успешно.
Контрольный пример 2: опция TS1.TC2 (BR1) отключена.
дефекты
Таким образом, при выполнении, если какой-либо дефект обнаружен, например, мониторинг в реальном времени, не работает должным образом, и данные не обновляются через каждую секунду, таким образом, генерируется идентификатор дефекта для решения этой конкретной проблемы.
Скажем, X01, поэтому этот идентификатор отображается в матрице, чтобы показать дефект.
Матрица покрытия и отслеживания требований
Тестовое покрытие определяется как процесс, в котором мы проверяем, каковы требования клиента и какие требования должны быть проверены, когда начинается процесс тестирования. Обычно это делается для того, чтобы исключить вероятность дефекта в проекте.
Для достижения полного охвата тестированием необходимо установить «прослеживаемость требований». В котором все дефекты отображаются.
Типы спецификаций требований
1. Спецификация требований к программному обеспечению
2. Бизнес-требования
3. Использование прецедентного документа
4. Документ с требованиями проекта
5. Документы для проверки дефектов
Преимущества
Как создать матрицу прослеживаемости требований?
RTM, как обсуждалось выше, является документом строки и столбца, который содержит тестовое покрытие о различных требованиях и дефектах, обнаруженных в этом. По сути, для создания RTM необходимо иметь доступ к Microsoft Excel, поскольку он содержит все необходимые инструменты, необходимые для создания матрицы.
Кроме того, знание Excel весьма полезно, потому что для создания матрицы используются разные инструменты, а также существуют различные формулы, поэтому, если человек знает об этом, он легко создает матрицу и выполняет то же самое. Вот пример RTM:
Важные моменты для запоминания
Вывод
Рекомендуемые статьи
Traceability matrix что такое
Тест-анализ = процесс поиска и рассмотрения информации, необходимой для тестирования. Обычно это люди со знаниями о системе и процессах, а также документация (требования, спецификации, описания архитектуры и интеграции и т.п).
Эта информация нужна для составления тест-кейсов.
Тестовое покрытие = покрытие тестами требований к продукту/системе, выраженное в численном либо процентном соотношении. Тестовое покрытие является одной из основных метрик качества продукта.
Иногда под тестовым покрытием имеют в виду покрытие критериев приёмки, покрытие кода, покрытие именно автотестами.
Тестовое покрытие говорит о добротности тестирования, о степени доверия к продукту, который мы делаем, о том где у нас есть «белые пятна» и выше риск проявления ошибки.
Процесс определения покрытия кратко картинкой:
Итак, вы прошли этап определения причастных сторон, ознакомились с документацией по Проекту, получили описание архитектуры Продукта/Системы, требования к ней, критерии приёмки.
Теперь надо определиться с объёмом тестирования и видами тестирования.
Матрица трассируемости требований (Requirement Traceability Matrix) = двумерная таблица, содержащая соответствие требований (user/business requirements, software requirements) и подготовленных тест-кейсов (test cases).
Основное её предназначение в отображении степени покрытия требований тест-кейсами.
В соответствии с лучшими практиками, Бизнес-Требования следует максимально декомпозировать и нумеровать в соответствии со следующим правилом: BR001, BR002 и т.д.
Для каждого Бизнес-Требования будет одно или несколько Функциональных Требований, которые должны соответствовать соглашению по нумерации для соответствующего бизнес-требования: FR001.01, FR001.02, FR001.03, FR002 и т.д. Функциональные требования также должны быть максимально декомпозированы.
Пример рабочего процесса, в котором присутствует создание Матрицы Трассировки:
Формат тест-кейса
Определение классов эквивалентности (Equivalence Partitioning)
и Анализ Граничных Значений (Boundary Value Analysis)
Попарное тестирование (Pairwise Testing)
Метод, основывающийся на тестировании комбинаций, с учётом того, чтобы каждое значение всех параметров хотя бы единожды сочеталось в проверках с другими значениями остальных параметров. Метод сильно уменьшает объём тестирования, но увеличивает вероятность пропуска дефекта.
Пример «оптимизации» оптимизации количества тестов этим методом:
Причина / Следствие (Cause/Effect)
Тестирование смены состояний (State Transition Testing)
Таблица решений (Decision Table Testing)
Способ компактного представления модели со сложной логикой. Устанавливает связь между условиями (входными параметрами) и результатом (действиями Системы). Определить/записать все условия. Просчитать возможное количество комбинаций условий. Заполнить комбинации. Записать действия. Убрать лишние комбинации.
Например:
Тестирование путей (Path Testing)
Однако, его же можно использовать для покрытия тестами логики тестируемой системы, если у нас имеются BPMN-диаграммы и UML activity-диаграммы, описывающие процессы, проходящие в ней.
Количество сценариев будет зависеть от количества логических узлов ветвлений. Если условия ветвлений зависят от значений каких-то данных, то скорее всего, для каждого тест-сценария необходимо, опираясь на диаграмму, определить набор входных данных.
Очень упрощённо:
Предугадывание ошибки (Error Guessing)
Это когда тест-аналитик/тестировщик использует свои знания системы и способность к интерпретации спецификации на предмет того, чтобы «предугадать» при каких входных условиях система может выдать ошибку. Например, спецификация говорит: «пользователь должен ввести код». Тест-аналитик, будет думать: «Что, если я не введу код?», «Что, если я введу неправильный код? «, и так далее. Это и есть предугадывание ошибки.
Исчерпывающее тестирование (Exhaustive Testing)
Матрица трассабилити
Когда требования на проекте меняются “на лету” и у вас нет под рукой средства контроля за реализацией каждого отдельного требования по фиче или модулю, перед вами встает вопрос: как проводить анализ покрытия? Одним из таких инструментов, который использует наша команда QA на подобных проектах — матрица трассируемости (traceability matrix).
На данный момент мы используем матрицы более 2,5 лет. За это время мы смогли оценить преимущества этого инструмента, а также адаптировать его под наш проект.
Что же такое матрица трассируемости?
По определению матрица трассируемости — двумерная таблица, содержащая соответствие функциональных требований продукта (functional requirements) и подготовленных тестовых сценариев (test cases).
На пересечении соответствующих строки и столбца ставится отметка, обозначающая, что данное требование покрывается данным тест-кейсом.
Таким образом, таблица дает визуальное отображение двух параметров:
На нашем проекте мы используем матрицы трассируемости не только для оценки покрытия, но и для определения связи между задачами на разработку, требованиями и тестовыми артефактами.
Поэтому матрица имеет вид таблицы, каждая строка которой содержит:
Так как мы используем таск трекер Jira, Zephyr by Jira для тестовой документации и систему управления требованиями Сonfluence, все сущности синхронизируются и такая трассируемость позволяет нам:
Варианты связей в матрице трассируемости
Привязка требования и тест-кейса может быть:
Специфика оценки покрытия с помощью матриц трассируемости
Если для оценки покрытия мы используем метрику “отношение количества требований к количеству тестовых артефактов”, то связи в матрице должны быть “1 к 1”, а требования максимально декомпозированы.
Пример. Имеем неатомарное требование: “Пользователь должен иметь возможность изменять и форматировать письмо в текстовом редакторе”. Одного тест-кейса явно будет недостаточно, но если в матрице будет прилинкован только один артефакт, визуально будет представление, что требование покрыто.
В таком случае, тест-кейсы и чек-листы для каждого неатомарного требования составляются единовременно, то есть каждое требование в матрице или полностью покрыто артефактами или не покрыто совсем.
При составлении матриц желательно придерживаться рекомендации, что декомпозиция каждого требования в отдельно взятой матрице должна быть примерно равной, то есть в одной таблице не должны содержаться требования, часть из которых требует 5 тест-кейсов, а часть — один тест-кейс.
Оценка покрытия в таком случае рассчитывается отдельно для каждой матрицы.
Так как наша проектная документация может иметь различный вид для каждой фичи и даже описание одной фичи может содержать UML, схемы, диаграммы юз-кейсов и переходов, а проект содержит более 40 объемных функциональностей, мы решили разрабатывать отдельную матрицу для каждого модуля или фичи, чтобы не терять ни один из плюсов данного инструмента.
Оценка покрытия также рассчитывается отдельно для каждого модуля или фичи.
При таком подходе мы можем использовать метрику, описанную выше: “количество требований к количеству тестовых артефактов”. Даже если у нас есть связи 1 к n, n к n, у нас есть несколько компонентов, каждый из которых может быть использован в нескольких модулях. Требования и приемочные критерии описываются в каждой матрице, а тестовый артефакт используется один.
Наши матрицы хранятся также в системе управления требованиями Confluence — каждая матрица расположена с структуре в качестве дочерней страницы фичи, для которой была разработана. Также все матрицы собраны на одной странице для удобства при оценке покрытия всего приложения.
Создание и ведение матрицы
Создание матрицы включено в наш воркфлоу работы над задачами по аналитике.
Когда мы получаем информацию о новой фиче, аналитик нашей команды создает задачу в таск трекере и совместно с product-owner со стороны заказчика работает в рамках этой задачи. В процессе сбора и структурирования требований вся команда проводит ревью и задает дополнительные вопросы. Когда требования сформулированы, задокументированы и подтверждены заказчиком, тим-лид разработки создает таски на разработку данной фичи, а команда тестирования может приступать к созданию матрицы трассировки.
И здесь можно выделить следующие этапы составления Traceability Matrix:
Сложности в работе с матрицей трассируемости
Если все QA-специалисты заняты тестированием приоритетных задач, мы переносим создание матрицы по конкретной фиче. Максимально он переносится на момент тестирования первой задачи по этой фиче и в таком случае матрица заполняется тест-кейсами по мере тестирования задач, в которых реализована фича.
Если проект небольшой и все требования оформлены в виде структурированного ТЗ, а тест-кейсы создаются на каждое требование сразу, матрица трассируемости в нашем виде будет только дублировать информацию и будет лишней тратой ресурсов.
Поэтому нужно использовать стандартную матрицу, описанную в определении, для оценки покрытия.
Обзор частых вопросов по тестированию ПО на собеседованиях и ответы на них
Главная цель данной статьи – помочь преодолеть страх, который возникает у тестировщиков ПО (как начинающих, так и опытных) к предстоящему интервью в связи с незнанием грядущего.
Второстепенная цель – собрать воедино основные вопросы, которые, вероятней всего, будут заданы на собеседовании. Как у начинающего тестировщика, у меня уже скопился определенный опыт подготовки к собеседованиям на данную должность, и я могу заметить, что даже специализированные QA форумы не справляются с этой целью, а может и не ставят ее перед собой вообще.
Перечень вопросов разумеется не окончательный и не претендует на образцовость, а выступает лишь своеобразным ориентиром при подготовке специалистов с тестирования ПО.
Собственно вопросы:
Обеспечение качества (QA) — это совокупность мероприятий, охватывающих все технологические этапы разработки, выпуска и эксплуатации ПО и предпринимаемых на разных стадиях жизненного цикла ПО, для обеспечения требуемого уровня качества выпускаемого продукта.
Обеспечение качества определено в стандарте ISO 9000:2005 «Системы менеджмента качества. Основные положения и словарь» как «часть менеджмента качества, направленная на создание уверенности в том, что требования к качеству будут выполнены».
Менеджмент качества в этом же стандарте представлен как «скоординированная деятельность по руководству и управлению организацией применительно к качеству», а в примечании сказано, что он «обычно включает разработку политики и целей в области качества, планирование качества, управление качеством, обеспечение качества и улучшение качества».
Тестирование ПО — это процесс, содержащий в себе все активности жизненного цикла, как динамические, так и статические, касающиеся планирования, подготовки и оценки программного продукта и связанных с этим результатов работ с целью определить, что они соответствуют описанным требованиям, и показать, что они подходят для заявленных целей и для определения дефектов.
Из этого определения становится понятно, что тестирование ПО включает в себя два различных процесса:
Валидация (validation): доказанное объективными результатами исследования подтверждение того, что требования для конкретного определенного использования приложения были выполнены. [ISO 9000]
Верификация (verification): доказанное объективными результатами исследования подтверждение того, что определенные требования были выполнены. [ISO 9000]
Цель тестирования (test objective, test target) — это причина или цель разработки и выполнения теста.
Следует также понимать что такое big-bang тестирование, тестирование «сверху вниз», восходящие и инкрементное тестирование;
Критерии входа (entry criteria) — это набор общих и специфичных условий для продолжения процесса с определенной задачей, например, фаза тестирования. Цель критериев входа — предотвращение начала задачи, которое может потребовать больше (бесполезных) усилий, чем на устранение не пройденных критериев входа.
Проще говоря для Вас, как будущего тестировщика, критерии входа следует понимать как основные условия, которые должны быть выполнены до того, как Вы и Ваша команда могут начать тестирование.
Критерии выхода (exit criteria) — это набор общих и специфичных условий, согласованных заранее с заинтересованными сторонами, для того, чтобы процесс мог официально считаться завершенным. Цель критериев выхода — предотвращение возможности, когда задание считается завершенным, однако еще существуют отдельные незавершенные части задания. Критерии выхода используются для отчетности, а также планирования того, когда остановить тестирование.
Проще говоря, как критерии входа определяют начало тестирования, так и критерии выхода определяют его окончание и ПО готово к следующему этапу жизненного цикла (внедрение и т.д.).
Реальный вопрос, на который мы ищем ответ: строим ли мы продукт правильно?
Процесс верификации (verification) выполняется, чтобы убедиться, что каждый этап жизненного цикла разработки ПО (разработка, тестирование и т.д.) строится на основе предопределенных требований (requirements) и спецификаций (specifications) и без каких-либо отклонений от них. (см. № 7)
Реальный вопрос, на который мы ищем ответ: строим ли мы правильный продукт?
Процесс, позволяющий тестировщику оценить ПО после стадии разработки до передачи его заказчику. В этом процессе мы должны убедиться, что ПО разработано на основе потребностей пользователей.
Помните, валидация охватывает динамическую сторону тестирования, где определенное ПО тестируется и оценивается вопреки заданной SRS документации.
Отладка (debugging) — это процесс поиска, анализа, и устранения причин отказов и ошибок в ПО.
Эмуляция — это воспроизведение работы программы или системы (а не какой-то её мизерной части) с сохранением ключевых её свойств и принципов работы. Эмуляция выполняет программный код в привычной для этого кода среде, состоящей из тех же компонентов, что и эмулируемый объект.
Симуляция — это воспроизведение работы программы-оригинала сугубо виртуально, на движке специальной программы (средство разработки курсов, к примеру). Симуляция лишь имитирует выполнение кода, а не копирует его, всё виртуально на 100%, всё «понарошку».
Эмулятор ПО — это полнофункциональный аналог оригинального ПО, либо его версия, в которой может быть предусмотрен ряд ограничений по функционалу, возможностям и поведению ПО.
Симулятор ПО — это модель оригинального ПО, в которой реализуется логика работы этого ПО (частично или полностью), имитируется поведение ПО, копируется его интерфейс.
Симулятор по полноте функций/учитываемых параметров уже, чем эмулятор. Эмулируется объект, а симулируются его свойства, функции или поведение.
Спецификация (specifications) — это текстовый файл с описанием того, что нужно протестировать в тестовых данных. В ней указывается какие результаты должна получить программа. Тестовый код находит реальные, вычисленные на живом коде результаты. А тестовый движок производит сверку спецификации и вычисленных результатов.
Спецификацию получаем от заказчика проанализировав, исследовав его требования и переведя их на качественно новый, более детализированный уровень, на котором ими и будет пользоваться команда разработчика.
Кодирование (coding) — это процесс написания программного кода, скриптов, с целью реализации определённого алгоритма на определённом языке программирования.
Некоторые путают такие понятия, как программирование и непосредственно кодирование. Кодирование является лишь частью программирования, наряду с анализом, проектированием, компиляцией, тестированием и отладкой, сопровождением (В узких кругах кодирование также может называться «кодинг». Однако, если верить Вики, в литературе этот термин используется редко.).
Требование (requirement) — совокупность утверждений относительно атрибутов, свойств или качеств программной системы, подлежащей реализации. Создаются в процессе разработки требований к программному обеспечению, в результате анализа требований.
Требования могут выражаться в виде текстовых утверждений и графических моделей.
В классическом техническом подходе совокупность требований используется на стадии проектирования программного обеспечения (ПО). Требования также используются в процессе тестирования ПО, так как тесты основываются на определённых требованиях.
Этапу разработки требований, возможно, предшествовало технико-экономическое обоснование, или концептуальная фаза анализа проекта. Фаза разработки требований может быть разбита на выявление требований (сбор, понимание, рассмотрение и выяснение потребностей заинтересованных лиц), анализ (проверка целостности и законченности), спецификация (документирование требований) и проверка правильности.
Критичность (severity) — это важность воздействия конкретного дефекта на разработку или функционирование компонента или системы.
Приоритет (priority) — это степень важности, присваиваемая багу. Другими словами определяется, насколько срочно это ошибка должна быть исправлена.
Сборка (build) — подготовленный для использования информационный продукт. Чаще всего это исполняемый файл (двоичный файл, содержащий исполняемый код программы).
Драйвер (driver) — это компонент ПО или средство тестирования, которое заменяет компонент, обеспечивающий управление и/или вызов компонента или системы.
Обвязка (harness) — это тестовое окружение, включающее в себя заглушки и драйверы, необходимые для проведения теста.
Для измерения покрытия требований, необходимо проанализировать требования к продукту и разбить их на пункты. Опционально каждый пункт связывается с тест кейсами, проверяющими его. Совокупность этих связей — и является матрицей трассировки (traceability matrix). Проследив связи, можно понять какие именно требования проверяет тестовый случай.
Тесты не связанные с требованиями не имеют смысла. Требования, не связанные с тестами — это «белые пятна», т.е. выполнив все созданные тест кейсы, нельзя дать ответ реализовано данное требование в продукте или нет.
End-to-end тестирование — это тип тестирования где тестировщик использует ПО (сценарии, которые исследуют весь поток выполнения) в условиях которыми вероятней всего обладает пользователь.
Функциональное тестирование (functional testing) — это тестирование, основанное на анализе спецификации функциональности компонента или системы.
Функциональные тесты базируются на функциях и особенностях, а также взаимодействии с другими системами, и могут быть представлены на всех уровнях тестирования: компонентном или модульном (Component/Unit testing), интеграционном (Integration testing), системном (System testing) иприемочном (Acceptance testing). Функциональные виды тестирования рассматривают внешнее поведение системы.
Белый ящик — это тестирование кода на предмет логики работы программы и корректности её работы с точки зрения компилятора того языка, на котором она писалась.
Техника тестирования по принципу Белого ящика, также называемая техникой тестирования, управляемой логикой программы, позволяет проверить внутреннюю структуру программы. Исходя из этой стратегии тестировщик получает тестовые данные путем анализа логики работы программы.
Тестирование чёрного ящика или поведенческое тестирование — это стратегия (метод) тестирования функционального поведения ПО с точки зрения внешнего мира, при котором не используется знание о внутреннем устройстве тестируемого объекта. Под стратегией понимаются систематические методы отбора и создания тестов для тестового набора. Стратегия поведенческого теста исходит из технических требований и их спецификаций
Спасибо за внимание и удачи в ваших начинаниях!
P.S. Пожалуйста, обратите внимание, что это всего лишь перечень вопросов составленный на основе моего опыта (он не будет уникальным для всех интервью), а запоминание ответов как истинных может помешать вам работать в индустрии. Целью является помочь вам понять основные вопросы, с которыми вы предположено столкнетесь во время собеседования.
Призываю к активному и обоснованному холивару!