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

Тест-анализ = процесс поиска и рассмотрения информации, необходимой для:

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

Обычно такая информация есть:

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

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

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

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

Об определении покрытия картинкой:

скачать схему в формате 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-приложении. Или даже TUI.
6. CLI (command-line interface) и возможные команды приложению посредством командной строки.
7. Варианты конфигурации приложения.

Теперь прикидываем какими видами тестирования с какими тест-сценариями можно покрыть всю разоблачённую феерию, составляя по-сути Карту Покрытия:

Группа	Уровень тестирования	Примеры тестов
Манипуляции над каждой бизнес-сущностью в Системе	UI, API	CRUD простой положительный: создали, прочитали и проверили, изменили, прочитали и проверили, удалили, попытались прочитать. Проверка комбинаций параметров при получении списка объектов сущностей, если такое действие предусмотрено. Проверка комбинаций параметров при создании объекта сущности Проверка комбинаций параметров при изменение объекта сущности Проверка комбинаций параметров на удаление объекта сущности (удаление по существующему id, по несуществующему, по невидимому и т.д.) Проверка дополнительных возможных действий с объектами сущностей — связывание, отвязывание и т.д. API-тесты (не забывая проверять соблюдение SLA) на обратную совместимость API, если вы её гарантируете Вышеупомянутые комбинации параметров могут включать в себя следующие негативные сценарии: попытка "скормить" данные не предусмотренного типа, не того который ожидается попытка "скормить" данные не в той структуре (не в том формате), которая ожидается попытка работать с несуществующими сущностями попытка работать с удалёнными сущностями попытка совершить переход сущности в состояние, не предусмотренное к достижению из текущего состояния попытка совершить переход сущности из текущего состояния в это же (проверяем что не совершается "лишних" действий, не появляются дубликаты данных, не происходит перезапись данных и т.п.)
Функции	UI, API	Тесты на основе уже определённых и описанных системными и бизнес-аналитиками критериев приёмки функций/свойств Системы; Позитивные проверки всего и вся: E2E-тесты по бизнес-процессам, use case, user story тесты на команды приложению в CLI (при наличии такого интерфейса) тесты на (обратную) совместимость экспорта-импорта чего-либо, когда, например экспорт был выполнен в предыдущей версии, а импорт пытаемся сделать в новой версии
Интеграции	API, UI	интеграционные тесты, если в скоуп тестирования входит несколько Систем (сервисов). Инициация интеграционных взаимодействий может быть и через UI и через API. тесты на (обратную) совместимость экспорта-импорта чего-либо, когда, например экспорт был выполнен в предыдущей версии, а импорт пытаемся сделать в новой версии
Пользовательский интерфейс, дизайн	UI	состояние и содержимое UI-элементов на странице логика отображения и поведения UI-элементов маски на полях, допустимая длина вводимых данных
Тестирование безопасности — ролевая модель	API, UI	Тесты под предусмотренными ролевой моделью ролями, работа с формами и сущностями (данными) невозможность работы с формами и сущностями (данными) от лица роли, доступа к ним для которой запрещена согласно ролевой модели
Тестирование безопасности — всё остальное	API, UI	используются ли в межсервисном взаимодействии нужные протоколы, сертификаты, шифрование невозможность получения токенов, ключей, сертификатов с некорректными условиями/запросами возможность получения токенов, ключей, сертификатов в предусмотренных условиях с корректными запросами тестирование на проникновение корректно ли замаскированы данные в БД ...
Нефункциональное: нагрузочное тестирование стресс-тестирование тестирование стабильности или надёжности тестирование выносливости объёмное тестирование тестирование удобства пользования тестирование на отказ и восстановление		Тесты на основе уже определённых и описанных системными и бизнес-аналитиками критериев приёмки обычные нагрузочные тесты, стресс-тесты, тесты на отказоустойчивость и т.п. обычные тесты на корректный запуск приложения в различном environment и ОС симуляция недоступности БД в процессе работы симуляция потери данных в процессе работы (удаление файлов, сущностей в БД) симуляция потери доступа к транспорту симуляция недоступности необходимых для работы портов и ресурсов симуляция стопора в очереди в транспорте (недоступность Kafka/RabbitMQ, снижение пропускной способности)
Нефункциональное: инсталляционное		Развёртывание системы "с нуля" Обновление системы Откат обновления Деинсталляция системы
Нефункциональное: конфигурационное		тесты на корректную работу (запуск) в конфигурациях, задаваемых при установке тесты на корректную работу при изменении настроек, применяемых "на лету"
Нефункциональное: тестирование совместимости, кросс-браузерность, кросс-платформенность	UI, API	(все вышеперечисленные) тесты в различных браузерах (если приложение кросс-браузерно) (все вышеперечисленные) тесты в различном окружении (если приложение кросс-платформенно)

В итоге получаем своего рода наброски (drafts) тест-кейсов, которые дальше уже далее потребуется детализировать по шагам.
Уже становится ПРИМЕРНО виден объём возможного тестирования, можно ПРИМЕРНО прикинуть сколько времени займёт как тест-дизайн по этим черновикам (детализация тест-кейсов), так и время прохождения всех этих тестов.
Заодно можно прикинуть какие из этих тест-кейсов целесообразно пустить потом в автоматизацию.

Матрица трассируемости требований (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) = процесс проектирования и создания тест-кейсов в соответствии с определёнными ранее критериями качества, целями тестирования, критериями приёмки.

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

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

Исчерпывающий формат тест-кейса

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

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

В общем случае нам требуется протестировать некую функцию системы. Часто, данные для функции и сам путь исполнения функции подразумевают некоторую вариативность. Нижеперечисленные техники как раз помогают определиться с тем, как именно подступиться к тестированию вариативности всего этого добра.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Пример:

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

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

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

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

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

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

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