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

Тест-анализ = процесс поиска и рассмотрения информации, необходимой для тестирования. Обычно это люди со знаниями о системе и процессах, а также документация (требования, спецификации, описания архитектуры и интеграции и т.п).
Эта информация нужна для составления тест-кейсов.

Исполняющему роль тест-аналитика необходимо:

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

Тестовое покрытие = покрытие тестами требований к продукту/системе, выраженное в численном либо процентном соотношении. Тестовое покрытие является одной из основных метрик качества продукта.
Иногда под тестовым покрытием имеют в виду покрытие критериев приёмки, покрытие кода, покрытие именно автотестами.
Тестовое покрытие говорит о добротности тестирования, о степени доверия к продукту, который мы делаем, о том где у нас есть "белые пятна" и выше риск проявления ошибки.

Процесс определения покрытия кратко картинкой:

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

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

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

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

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

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

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

#	Block of feature	Issue for development	Acceptance criteria	Priority	Test-case
1	Create	Creating	User should be able to create new document	High	Test #1: Create document
2			User should not be able to create new document, if he has role = "Reviewer"	High	Test #14: Reviewer should not be able to create new doc
3	Print	Document printing	User should be able to print a document	High	Test #2: Print a document
4			.doc, .pdf, .docx, .rtf formats of a document should be able to be printed	High	Test #4: Check-list for doc formats
N	...	...	...	Low / Medium / High	link to TC

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

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

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

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

Если вы используете таск-трекер Jira (и её плагины Zephyr Scale (Zephyr Squad) - Test Management for Jira) для тестовой документации и систему управления требованиями Сonfluence, то JIRA-таски и Confluence-страницы можно привязывать к тест-кейсам, в JIRA-тасках создавать связи с тестовыми прогонами, и такая трассируемость позволяет:

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

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

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

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

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

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

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

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

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

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

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

Формат тест-кейса

1. Название (subject)
2. (опционально) Описание (description) -- что проверяем, некие важные подробности
3. (опционально) Трассировка (tracing) -- ссылки на таск и страницу с требованиями к проверяемой тест-кейсом функциональности, юзкейс, юзерстори ссылки на бегрепорты по тест-кейсу
4. Предусловия (preconditions), например:
   • Окружение: развёрнуто то-то и сё-то, ссылка на скрипты деплоя и инструкции при наличии, перечисление важных атрибутов конфигурации
   • Объект тестирования: тестируемая Система развёрнута так-то и там-то, ссылка на репозиторий, ссылка на регистр с контейнерами при наличии, ссылка на скрипты деплоя и инструкции при наличии, перечисление важных атрибутов конфигурации
   • Данные: в БД такой-то имеются такие-то данные
5. "Тело" тест-кейса, обычно в виде таблицы такого вида:

   № п/п	Действие	Ожидаемый результат	Результат
   1	Делаем вот это	Видим вот это, это и это	<успех / неудача, комментарий с подробностями фактического результата при неудаче>
   N	...	...	...

Определение классов эквивалентности (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)

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