Что такое тест аналитика

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

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

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

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

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

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

Матрица трассируемости требований (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);
(опционально) номер Задачи на разработку из таск-трекера + её описание;
(опционально) логический блок / модуль, к которому принадлежит Задача/Требование;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Пример:

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

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

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

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

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

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

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

Что такое тест аналитика