Россия
Приведены основные этапы управления требованиями к тестам, представлены пара-метры оценки рисков требований к тестам, критерии ранжирования тестов и пара-метры для создания матрицы отслеживания требований
тестирование, матрица требований, ранжирование требований
Планирование тестирования предполагает как определение требований к тестам, так и выработку подхода к управлению ими. Управление требованиями к тестам включает в себя хранение требований, отслеживание связей, оценку рисков требований к тестам, выстраивание последовательности требований к тестам и определение методов верификации тестов. Отслеживание связей предполагает отображение тестовых процедур на требования к тестам и дефектов на тестовые процедуры.
Группа тестирования должна описать способ управления требованиями к тестам в плане тестирования. Требования могут хранится в текстовом документе, электронной таблице или в базе данных инструмента управления требованиями. Ключевые соображения при выборе способа хранения требований к тестированию — простота и гибкость сортировки требований и подготовки отчетов, простота и скорость доступа к требованиям, эффективность сопровождения требований. Еще одно соображение: сколько сотрудников могут одновременно иметь доступ к информации о требованиях. Также важна способность механизма хранения требований приспосабливаться к различным данным, относящимся к управлению требованиями к тестам, и сохранять целостность и безопасность информации о требованиях.
Во многих компаниях для хранения требований используют текстовые программы или электронные таблицы. Хранение требований в документе текстового вида имеет множество недостатков. Например, существует ограниченное количество способов сортировки требований и отбора их по фильтру. Сложно хранить историю изменений, показывающую, когда, кем и какие изменения были сделаны. Часто сотрудники из-за тяжести задачи сопровождения требований с помощью подобных инструментов отказываются от ее выполнения.
На рынке представлены коммерческие инструменты управления требованиями, которые могут выполнять все упомянутые выше работы. Эти инструменты особенно полезны для отслеживания связей. Отслеживание связей между системными требованиями или сценариями использования системы и различными продуктами, появляющимися в процессе разработки системы, может быстро усложниться. Это отображение трудно поддерживать вручную, и, кроме того, изменения требований и различных продуктов проекта также усложняют отображение и работу с ним.
Применение специальных автоматизированных инструментов полезно, в частности, при решении утомительных и трудоемких задач. К таким задачам относится управление требованиями к тестам. Группа тестирования должна проверить, есть ли в компании стандартный инструмент для поддержки управления требованиями. Затем нужно выяснить, будет ли этот инструмент применяться в проекте и можно ли его установить в среде системной разработки исключительно для управления требованиями к тестам. Если в компании нет стандартного инструмента или его использование не запланировано в проекте, возможно, группе тестирования придется показать, что его отсутствие порождает проблемы в управлении, или выступить с инициативой проведения оценки и подбора такого инструмента.
Применение инструмента управления требованиями дает целый ряд преимуществ. Например, все требования, относящиеся к проекту, могут храниться в базе данных инструмента. Инструмент использует главный репозиторий базы данных для хранения всех связанных с ним данных. Требования могут быть договорными, системными и требованиями к тестам. Добавление требований к тестам в базу данных инструмента управления требованиями позволяет легко управлять покрытием тестами и отображением требований к тестам на бизнес-требования или системные требования.
После определения требований к тестам группа тестирования должна измерить риски, присущие различным требованиям, оценив требования по следующим характеристикам:
- Степень влияния. Оценивается значение требования. Предположим, что определенное требование к тестам не вошло в рамки тестирования, в результате чего соответствующая этому требованию функциональность не работает после установки системы. Какое влияние может оказать эта проблема на функционирование системы и способность пользователя работать с системой? Является ли эта проблема потенциальной помехой в деятельности компании?
- Вероятность. Оценивается вероятность возникновения проблем в случае, если определенное требование к тестам не войдет в рамки тестирования. Анализируется частота, с которой конечный пользователь будет сталкиваться с соответствующей функциональностью системы. Оценивается опыт работы пользователя с данной функциональностью.
- Сложность. Определяются функции, являющиеся наиболее сложными. Ресурсы тестирования должны быть направлены на проверку этой функциональности.
- Источники проблем. Оценивается возможность возникновения проблем, и определяются требования к тестам, которые с наибольшей вероятностью могут породить эти проблемы.
Группа тестирования должна расставить требования к тестам в порядке приоритетов. Также необходимо провести анализ функций системы, критичных для приложения, и функций повышенного риска, и использовать это в качестве входной информации для определения порядка, в котором будут выстроены группы требований. Лучший способ — сгруппировать требования по степени критичности функциональности, начиная с наиболее критичных и заканчивая наименее критичными. При определении, какая функция более критична, а какая — менее, стоит учесть информацию от конечных пользователей. Еще одно преимущество классификации требований, таким образом, состоит в том, что упрощается распределение задач между тестировщиками.
Ниже приводятся критерии, позволяющие определить порядок группировки требований к тестам:
- Степень риска. На основании оценки рисков требования к тестам группируются таким образом, чтобы уменьшить влияние функций повышенного риска на работу системы и возникновение потенциальных помех деятельности компании. Примерами функций повышенного риска являются функции, которые препятствуют вводу данных или выполнению бизнес-правил, что может повлечь повреждение данных или нарушение правил.
- Функциональные характеристики. Некоторые из требований к тестам будут ранжированы довольно высоко в списке приоритетов, поскольку их часто применяют либо конечные пользователи практически не имеют информации в этой области. Функции, относящиеся к техническим ресурсам и к внутренним пользователям, а также редко используемые функции ранжируются как низкоприоритетные.
- Требования пользователей. Некоторые из требований к тестам жизненно важны для пользователей. Если подход к тестированию не повысит внимание к этим требованиям, могут быть нарушены договорные обязательства или компания понесет финансовые потери. Важно оценить влияние возможных проблем на требования конечного пользователя.
- Доступные ресурсы. Тестирование имеет ограничения по персоналу и аппаратному' обеспечению, к тому же могут существовать конфликтующие требования к проекту. Необходимо управлять болезненным процессом достижения компромиссов. Дополнительный фактор при ранжировании требований к тестам — доступность ресурсов.
Проявление дефекта (exposure). Проявление дефекта определяется как риск (вероятность), умноженный на стоимость неисправности. Например, дефект, имеющий высокую вероятность с большой стоимостью повреждения, характеризуется большим проявлением дефекта.
Системные требования или сценарии использования системы обычно сопровождаются с помощью инструмента управления требованиями. После определения тестовых процедур во время планирования тестирования или проектирования тестов они заносятся в базу данных инструмента управления требованиями и привязываются к соответствующим системным требованиям или сценариям использования системы. Позднее, когда ведется отслеживание тестов, результаты их применения фиксируются и привязываются к соответствующим тестовым процедурам.
Матрица отслеживания требований представляет собой продукт, получаемый автоматически при помощи инструмента управления требованиями. Она позволяет проследить системные требования и сценарии использования системы, а также покрытие требований тестовыми процедурами. Матрица может принимать одну из нескольких форм, основанных на различных видах отображений. Матрица отслеживания требований определяет каждое требование, которое проверяется группой тестирования, а также метод его верификации. Важно то, что матрица отображает тестовые процедуры на системные требования или сценарии использования системы и помогает убедиться в том, что системные требования или сценарии использования системы, проверяемые на фазе тестирования, успешно реализованы.
Необходимо, чтобы группа тестирования как можно раньше получила обратную информацию о матрице отслеживания требований от конечных пользователей или заказчиков системы. Это способствует достижению согласия по поводу методов верификации, обеспечивающих проверку или контроль каждого требования. Принятие этого решения особенно важно, поскольку методы верификации отличаются по сложности и затратам времени. Раннее получение информации по матрице от заказчика позволяет группе тестирования увеличить время реакции на возможные изменения.
Поскольку матрица отслеживания требований определяет выполняемые тестовые процедуры, одобрение матрицы заказчиком также означает его удовлетворение степенью покрытия тестами системных требований или сценариев использования системы. При проведении приемо-сдаточных испытаний заказчик проанализирует матрицу, чтобы проверить покрытие тестами системных требований или сценариев использования системы. В таблице 1 приводится пример матрицы отслеживания требований.
Матрица, представленная в таблице 1, содержит текст формулировки требования, уникальный идентификатор требования, порождаемый инструментом управления требованиями, метод верификации, степень риска или приоритет требования и тестовая процедура, связанная с требованием. Также указывается номер поставляемой версии системы (Dl, D2 или D3), в которой будет реализовано требование.
Поскольку матрица отслеживания требований определяет выполняемые тестовые процедуры, одобрение матрицы заказчиком также означает его удовлетворение степенью покрытия тестами системных требований или сценариев использования системы. При проведении приемо-сдаточных испытаний заказчик проанализирует матрицу, чтобы проверить покрытие тестами системных требований или сценариев использования системы.
Подводя итоги, стоит отметит следующие тезисы:
1) Планирование работ по тестированию должно учитывать ресурсы и работы, которые необходимо выполнить, чтобы своевременно настроить тестовую среду. Группа тестирования должна определить требования к аппаратному, программному и сетевому обеспечению и к местоположению с целью создания и поддержания тестовой среды. Нужно спланировать работы по приобретению, установке и настройке различных компонентов тестовой среды.
2) Группа тестирования должна исчерпывающе документировать планы программы тестирования, а тестировщики обязаны подробно изучить содержание этих планов. Создание плана тестирования — итеративный процесс, требующий обратной связи с различными участниками проекта и их согласия с определенными в нем подходами, стратегиями тестирования и сроками выполнения работ.
3) Группа тестирования должна получить одобрение плана тестирования у конечного пользователя или заказчика. Заказчик должен утвердить стратегию тестирования и тестовые процедуры, которые подробно описаны в плане тестирования и определяют, какие тесты будут выполняться. Кроме того, предполагается, что заказчик согласен с тем, что план тестирования и связанные с ним тестовые скрипты правильно проверяют удовлетворительное покрытие тестами системных требований или сценариев использования системы.
Таблица 1
|
Текст |
Метод верификации |
Приоритет |
D1 |
D2 |
D3 |
Тестовая процедура |
|
Система должна выполнять установку программного обеспечения и обновление версий |
Тестирование |
Нет |
- |
D2 |
- |
SM2012 |
|
Система должна выполнять балансировку загрузки серверов WFTS |
Тестирование |
Нет |
- |
D2 |
- |
SM2013 |
|
Система должна восстанавливать работу программы и данные в случае сбоя |
Тестирование |
Высокий приоритет |
- |
D2 |
- |
SM2014 |
|
Система должна управлять дисковой и файловой структурой и размещением файлов, чтобы определять размер доступного и используемого дискового пространства |
Тестирование |
Нет |
- |
D2 |
- |
SM2015 |
|
Система должна уметь конфигурировать электронную почту и управлять функциями службы маршрутизации |
Тестирование |
Нет |
D1 |
- |
- |
SM2016 |
|
Система должна осуществлять мониторинг конфигурации критических системных компонентов и рабочих станций, включая проверку устаревших версий |
Тестирование |
Нет |
D1 |
- |
- |
SM2017 |
|
Система должна удовлетворять сертификационным критериям, определенным Федеральным резервным банком |
Сертификация |
|
- |
- |
D3 |
СТ001 - СТ100
|
1. Александрова Е.Г., Добрынина Н. Н. Методология ATML в автоматизированном тестировании // Сборник научных трудов Ангарского государственного технического университета. – 2024. – С. 3-6.
2. Александрова Е.Г., Добрынина Н. Н. Профессиональные навыки в области тестирования // Сборник научных трудов Ангарского государственного технического университета. – 2024. – С. 7-10.
3. Куликов С.С. Тестирование программного обеспечения. Базовый курс / Куликов С.С. — 3-е изд. — Минск: Четыре четверти, 2020. — 312 с.
4. Quality Assurance Institute. QA Quest. N. www.qaiu- sa.com/journal.html
5. Джефф Р., Элфрид Д., Джон П., Тестирование программного обеспечения // “Лори”, 2014 – 541 с.
