# ПРОЦЕССЫ Ресурсы Цикл разработки ПО Waterfall RUP Agile Kanban Управление Теория ограничений АНАЛИЗ Ресурсы ПО для Аналитика Кто аналитики? Бизнес-процесс Требования Уровни и типы Источники Стейкхолдеры Нотации Vision (Концепция) Сервисы АРХИТЕКТУРА Ресурсы ПО для Архитектора Кто архитекторы? Архитектурные слои язык Archimate GAP-анализ SOA Типы интеграции Solution Design (Проектное решение) DDD Микросервисы и service mesh ESB HTTP/REST RPC DevOps CI/CD/CDP VM и Docker Контракты API Оценка задачи git Frontend Apache Регулярка Linux ТЕСТИРОВАНИЕ Ресурсы QA и QC Цикл тестирования Уровни тестирования Виды тестирования Баг-репорт Шаблоны Тестирование требований Тест-анализ Тест план Тест дизайн Метрики качества Автотесты Selenium XPATH Генератор данных Безопасность Нагрузочное ДАННЫЕ Ресурсы MDM Big data Об информации SQL intro MongoDB intro БИБЛИОТЕКА Курсы Системная инженерия Сознание, интеллект Политэкономия Сумма технологии Экстраполяция в будущее Красивые диаграммы Арт
Эта страница:
Ресурсы Тест-анализ Тестовое покрытие Трассировка требований и тест-кейсов Риски качества Риски тестирования
Другие страницы:
ТЕСТИРОВАНИЕ Тестирование требований Тест-анализ Тест план Тест дизайн Метрики качества Android Автоматизация Selenium WebDriver XPATH Генератор случайных данных Различные расчёты Безопасность Нагрузочное
Другие разделы:
# АНАЛИЗ АРХИТЕКТУРА ДАННЫЕ DevOps БИБЛИОТЕКА ПРОЦЕССЫ ТЕСТИРОВАНИЕ
Тест-анализ
last update: 06-10-2020, 06:42
Ресурсы
Тест-анализ

Тест-анализ = процесс поиска/рассмотрения того, что можно использовать для получения информации, необходимой для тестирования. Т.е. информации, необходимой для составления тест-кейсов - или test basis. И чаще всего test basis представляет собой набор документов, состоящий из требований, спецификаций, описания архитектуры, интеграционных интерфейсов и т.п.

В общем и целом, необходимо выявить:

  1. Суть проекта/доработки: для каких целей создан Продукт/Система, кто и каким образом использует
  2. Суть реализации: как работает Продукт/Система
  3. Скоуп (область) тестирования, в т.ч. исходя из объёма Продукта, архитектуры Системы
  4. Ограничения
  5. Риски тестирования

Тестовое покрытие
Определяем тестовое покрытие (скоуп/объём тестирования)

покрытие тестами
вариантов использования системы требований рисков качества поддерживаемых конфигураций

Трассировка требований и тест-кейсов

Матрица трассируемости требований (Requirement Traceability Matrix) = двумерная таблица, содержащая соответствие требований (user/business requirements, software requirements) и подготовленных тест-кейсов (test cases).
Основное её предназначение в отображении степени покрытия требований тест-кейсами.

  • ID Бизнес-Требования (BR, Business Requirement) или Бизнес Варианта Использования (Business Use Case);
  • суть Бизнес-Требования;
  • (опционально) приоритет Бизнес-Требования;
  • (опционально) приёмочный критерий Требования (acceptance criteria);
  • (опционально) ID Функционального требования (FR, functional requirement) из Спецификации к Требованиям ПО (SRS) или ID Варианта Использования (UC, Use Case);
  • (опционально) описание Функционального требования или Варианта Использования;
  • ID тестового артефакта (Тест-кейса);
  • (опционально) ожидаемый результат Тест-кейса (expected result);
  • (опционально) номер Задачи на разработку из таск-трекера + её описание;
  • (опционально) логический блок / модуль, к которому принадлежит Задача/Требование;

Примеры Матриц Трассировки:

(скачать в формате XLSX)

В соответствии с лучшими практиками, Бизнес-Требования следует максимально декомпозировать и нумеровать в соответствии со следующим правилом: BR001, BR002 и т.д.
Для каждого Бизнес-Требования будет одно или несколько Функциональных Требований, которые должны соответствовать соглашению по нумерации для соответствующего бизнес-требования: FR001.01, FR001.02, FR001.03, FR002 и т.д. Функциональные требования также должны быть максимально декомпозированы.

Пример рабочего процесса, в котором присутствует создание Матрицы Трассировки:

скачать схему в формате diagrams.net (бывший draw.io)

Если вы используете таск трекер Jira, Zephyr by Jira для тестовой документации и систему управления требованиями Сonfluence, то все сущности синхронизируются и такая трассируемость позволяет:

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

Соотношение привязки Требования и Тест-кейса может быть:

  • 1 к 1 (атомарное требование, которое покрывается одним тест-кейсом, данный тест-кейс покрывает только это требование);
  • 1 к n (требование, которое покрывается несколькими тест-кейсами, данные тест-кейсы покрывают только это требование);
    когда одно требование в матрице трассируемости покрывается несколькими тестами, это может говорить об избыточности тестирования. В таком случае надо проанализировать, насколько требование атомарно.
  • n к n (требование, которое покрывается несколькими тест-кейсами, данные тест-кейсы покрывают это и другие требования).

Программные комплексы для управления требованиями:
Риски качества

Риск качества (Quality risk) - потенциальный вид ошибки, способ поведения системы, при котором она, вероятно, не соответствует обоснованным ожиданиям качества системы, имеющимся у пользователя или заказчика. Это потенциальный, а не обязательный результат.

Общие категории рисков качества
Функциональность Проблемы, в результате которых не работают конкретные функции
Нагрузка, производительность, объём Проблемы обработки ожидаемых пиковых нагрузок при параллельной работе нескольких пользователей
Надёжность, стабильность работы Проблемы, при которых система слишком часто зависает или долго не восстанавливается
Перегрузки, обработка ошибок и восстановление Проблемы, возникающие ввиду превышения допустимых пиковых нагрузок или из-за обработки недопустимых условий (например, побочный эффект от сознательного внесения ошибок)
Обработка времени и дат Ошибки в математических действиях с датами и временем, в их форматировании, в планируемых событиях и других операциях, зависящих от времени
Качество данных Ошибки в обработке, извлечении и хранении данных
Производительность проблемы с временем завершения задач при ожидаемой нагрузке
Локализация проблемы, связанные с локализацией продукта, в том числе в обработке страницы символов, языковой поддержке, в использовании грамматики, словаря, а также в сообщениях об ошибках и файлах помощи
Безопасность проблемы в защите системы и охраняемых данных от мошеннического и злонамеренного использования
Установка/перенос ошибки, которые препятствуют поставке системы
Документирование ошибки в руководствах по установке и работе с системой для пользователей и системных администраторов
Из этого также следует вывод о том, насколько важно изучить требования заказчика, придерживаться их и здравого смысла (заказчик не всегда прав, иногда полезно намекнуть ему о потенциальных рисках в результате реализации какого-либо из его легкомысленных требований).

Риски тестирования

Основные риски тестирования:

  1. Проектные - связанные с коммуникациями участников команды, инфраструктурой:
    - изменение скоупа тестирования после проверки основных тест-кейсов
    ...
  2. Продуктовые - связанные только с тестируемым функционалом и тестовыми средам:
    - отсутствие тестовых зон с заданной конфигурацей (медленные БД, (не)обезличенные БД, отсутствие каких-то тестовых данных)
    - недопустимое время на ожидание подготовки тестовых зон со стороны Администраторов
    ...