• What is Test Basis in Software Testing?
• RUP - Концепция: Трассируемость
• Матрица трассировки
• How to Create Requirements Traceability Matrix (RTM)
• Пример документа SRS для создания Матрицы Трассировки Требования (RTM)
• Тестовый случай (Test Case)
• What is Test Scenario?

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

Необходимо определить:

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

Итак, вы прошли этап определения причастных сторон, ознакомились с документацией по Проекту, получили описание архитектуры Продукта/Системы, требования к ней, критерии приёмки.
Теперь надо определиться с объёмом тестирования и видами тестирования.

Для начала проводим логическую декомпозицию Системы, определяя:

1. сущности (задействованные чаще всего, самые важные), связи сущностей, состояния сущностей и правила перехода между ними, действия с сущностями (CRUD, фильтрация, сортировка, поиск, экспорт, иморт, валидация, парсинг, копирование).
2. бизнес-процессы, use cases (user scenarios, system scenarios), проходящие в продукте.
3. интеграция (ETL, RPC, REST API, file, MQ,...)
4. ролевая модель -- какие роли с какими правами, на какие бизнес-процессы, use cases и на работу с какими сущностями она влияет
5. UI как те или иные виды экранных форм в web-, desktop-, mobile-приложении.
6. CLI (command-line interface)
7. поддерживаемые конфигурации

Теперь прикидываем какими тест-сценариями это можно покрыть:

Вид тестирования	Примеры тестов
Функциональное позитивное (в т.ч. безопасности)	Позитивные проверки всего и вся: E2E-тесты по бизнес-процессам и пользовательским сценариям тесты на проверку отдельной функциональности, тесты на корректную работу системы с сущностями (данными) UI-тесты состояние и содержимое UI-элементов на странице логика отображения и поведения UI-элементов маски на полях, допустимая длина вводимых данных (все вышеперечисленные) тесты в различных браузерах (если приложение кросс-браузерно) API-тесты (не забывая проверять соблюдение SLA) интеграционные тесты, если в скоуп входит несколько Систем (сервисов). Часто совмещаются с API-тестами. (все вышеперечисленные) тесты в различном окружении (если приложение кросс-платформенно) тесты на команды приложению в CLI (при наличии такого интерфейса) Позитивные тесты безопасности: возможность получения токенов, ключей, сертификатов в предусмотренных условиях с корректными запросами E2E и UI-тесты под предусмотренными ролевой моделью ролями, работа с формами и сущностями (данными)
Функциональное негативное (в т.ч. безопасности)	попытка "скормить" данные не предусмотренного типа, не того который ожидается попытка "скормить" данные не в той структуре (не в том формате), которая ожидается попытка работать с несуществующими сущностями попытка работать с удалёнными сущностями попытка совершить переход сущности в состояние, не предусмотренное к достижению из текущего состояния попытка совершить переход сущности из текущего состояния в это же (проверяем что не совершается "лишних" действий, не появляются дубликаты данных, не происходит перезапись данных и т.п.) негативные тесты на безопасности: невозможность получения токенов, ключей, сертификатов с некорректными условиями/запросами невозможность работы с формами и сущностями (данными) от лица роли, доступа к ним для которой запрещена согласно ролевой модели
Нефункциональное: нагрузочное тестирование стресс-тестирование тестирование стабильности или надёжности тестирование выносливости объёмное тестирование тестирование установки тестирование удобства пользования тестирование на отказ и восстановление тестирование конфигурации тестирование совместимости	обычные нагрузочные тесты, стресс-тесты, тесты на отказоустойчивость и т.п. обычные тесты на корректную работу (запуск) в различных предусмотренных конфигурациях обычные тесты на корректный запуск приложения в различном environment и ОС обычные тесты на установку приложения с соблюдением SLA симуляция недоступности БД в процессе работы симуляция потери данных в процессе работы (удаление файлов, сущностей в БД) симуляция потери доступа к транспорту симуляция недоступности портов и ресурсов симуляция стопора в очереди в транспорте (недоступность Kafka/RabbitMQ, снижение пропускной способности)

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

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

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

(скачать в формате 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. Продуктовые - связанные только с тестируемыми функциями и тестовыми средам:
   - отсутствие тестовых зон с заданной конфигурацей (медленные БД, (не)обезличенные БД, отсутствие каких-то тестовых данных)
   - недопустимое время на ожидание подготовки тестовых зон со стороны Администраторов / DevOps
   ...

Проектирование тестов (test design) = процесс проектирования и создания тест-кейсов (тестовых случаев/сценариев/дел, case - юр. "дело"), в соответствии с определёнными ранее критериями качества, целями тестирования, критериями приёмки.

Тестовый случай (Test Case) = артефакт, описывающий совокупность шагов, конкретных условий и параметров, необходимых для проверки реализации тестируемой функции или её части.
Этимология слова case восходит к юридиспруденции. Case - дело, случай.
В тестировании мы, по-сути, с помощью тест-кейсов, предоставляющих нам свидетельства и факты, поддерживаем аргументы, обосновывая ими заявления о том, что проверяемая Система/ПО/Продукт соответствуют требованиям.

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

Пример оформления: http://www.protesting.ru/documentation/test_case_example.zip

Определение классов эквивалентности (Equivalence Partitioning)
и Анализ Граничных Значений (Boundary Value Analysis)

• Если область определения параметра — диапазон, то имеет смысл выделение трёх классов эквивалентности: слева от диапазона (невалидные значения), сам диапазон (валидные значения) и справа от диапазона (снова невалидные). При выделении классов нужно использовать включающие границы с целью однозначности и точности: одно и то же значение не может относиться к двум классам одновременно.
  Анализ граничных значений может быть применен к полям, записям, файлам, или к любого рода сущностям имеющим ограничения.
• Если область определения это набор неупорядоченных данных, то всегда можно выделить как минимум два класса — валидные и невалидные значения.
  Полученное разбиение можно "дробить" дальше. Например, множество латинских букв можно разбить на два подмножества: латинница в верхнем и нижнем регистре соответственно.

Попарное тестирование (Pairwise Testing)

Метод, основывающийся на тестировании комбинаций, с учётом того, чтобы каждое значение всех параметров хотя бы единожды сочеталось в проверках с другими значениями остальных параметров. Метод сильно уменьшает объём тестирования, но увеличивает вероятность пропуска дефекта.
Пример "оптимизации" оптимизации количества тестов этим методом:

Подробнее: ПОПАРНОЕ ТЕСТИРОВАНИЕ (PAIRWISE TESTING) (2018).

Причина / Следствие (Cause/Effect)

Простая проверка базовых действий и их результата. Как правило, ввод комбинаций условий (причин) для получения ответа от системы (Следствие).
Например, вы проверяете возможность добавлять клиента, используя определенную экранную форму. Пользователю необходимо заполнить несколько полей -- "Имя", "Адрес", "Номер Телефона" -- а затем нажать кнопку "Добавить". Это Причина. После нажатия кнопки "Добавить" система добавляет клиента в БД и показывает его номер на экране -- это Следствие.
Примерный алгоритм:

1. Выискиваем и связываем причины и следствия в спецификации
2. Учитываем "невозможные" сочетания причин и следствий
3. Составляем "таблицу решений", где в каждом столбце указана комбинация входов и выходов, т.е. каждый столбец это готовый тестовый сценарий
4. Приоритизируем решения.

Тестирование состояния сущностей (State Transition Testing)

Когда в Системе есть сущности (объекты), которые могут принимать различные состояния, то неплохо бы проверить, что предусмотренные требованиями переходы возможны к осуществлению, а непредусмотренные -- невозможны.
Пример:

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

Подробнее: Тестирование на основе диаграмм состояний сущности (2015).

Таблица решений (Decision Table Testing)

Способ компактного представления модели со сложной логикой. Устанавливает связь между условиями (входными параметрами) и результатом (действиями Системы). Определить/записать все условия. Просчитать возможное количество комбинаций условий. Заполнить комбинации. Записать действия. Убрать лишние комбинации.
Например:

Чуть подробнее: Decision Table Testing: Learn with Example

Тестирование путей (Path Testing)

Часто под ним имеется в виду метод тестирования белого ящика Control Flow Testing, в котором тест-кейсами покрываются все потоки и логические пути ПО. Подробнее можно прочитать здесь:

• Path Testing & Basis Path Testing with EXAMPLES
• Control Flow Testing

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

Посмотреть/послушать о такого рода применении метода можно здесь Где логика?! История тестирования одного микросервиса (Денис Кудряшов, Leroy Merlin, 2020), где докладчик скомбинировал этот метод с вышеупомянутой таблицей решений (Decision Table Testing).

Предугадывание ошибки (Error Guessing)

Это когда тест-аналитик/тестировщик использует свои знания системы и способность к интерпретации спецификации на предмет того, чтобы "предугадать" при каких входных условиях система может выдать ошибку. Например, спецификация говорит: "пользователь должен ввести код". Тест-аналитик, будет думать: "Что, если я не введу код?", "Что, если я введу неправильный код? ", и так далее. Это и есть предугадывание ошибки.

Исчерпывающее тестирование (Exhaustive Testing)

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