Изложенный подход позволит вам шаг за шагом изучить тест-анализ и даст понимание того, как проводить его на разных уровнях.
Тест-анализ vs Тест-дизайн
Эти два термина часто путают и используют как взаимозаменяемые, поэтому начнем с обсуждения разницы между ними.
Тест-анализ:
- Тест-анализ — это процесс понимания и анализа поведения системы.
- Цель тест-анализа — определить, что должно быть протестировано, что входит в область тестирования (Scope), а что выходит за ее пределы.
- Также включает в себя определение приоритетов фич продукта на основе потребностей пользователей и бизнес-целей.
- Тест-анализ дает нам общее представление о системе и является основой для тест-дизайна.
Тест-дизайн:
- Тест-дизайн — это процесс создания тест-кейсов на основе тест-анализа.
- Цель тест-дизайна — определить, как будет верифицироваться определенная область тестирования.
Деятельность по тест-дизайну включает:
- Принятие решений о методах тест-дизайна;
- Создание тест-кейсов с четко определенными критериями прохождения/непрохождения и последовательностями выполнения;
- Описание тестовых данных, как входных данных для тест-кейсов, так и данных, которые должны существовать в системе для выполнения тест-кейса;
- Проектирование тестового окружения и определение необходимой инфраструктуры и инструментов.
Тест-анализ отвечает на вопрос, что тестировать, а тест-дизайн — как тестировать.
Уровни тест-анализа
Тест-анализ может проводиться на разных уровнях — на уровне продукта (системы) и на уровне фич (конкретной функциональности системы). Разница заключается в масштабе и фокусе анализа.
Уровень продукта:
- Цель — понять общие функциональные возможности системы, их приоритеты и зависимости.
- Это облегчает разработку тест-планов и стратегий тестирования, а также обеспечивает основу для планирования регрессионного тестирования.
Уровень фичи:
- Цель — понять требования к конкретной фиче, чтобы спланировать и разработать тесты, проверяющие ее корректность и завершенность.
- Здесь мы используем методы тест-дизайна и создаем результаты для конкретных фич, такие как тест-кейсы, тестовые данные и конфигурации тестового окружения.
Мы должны начать с анализа тестирования на уровне продукта, который станет основой для дальнейшего анализа конкретных фич.
Тест-анализ на уровне продукта
Существует три основных вида деятельности по тест-анализу на уровне продукта:
- Декомпозиция — разбиение системы на высокоуровневые модули.
- Приоритизация — определение важности фич системы на основе потребностей пользователей и бизнес-целей.
- Анализ зависимостей — выявление связей между фичами системы.
Этап 1: Декомпозиция
Первым действием является декомпозиция, которая означает разбиение системы на части. Кроме того что она помогает справиться со сложностью разработки ПО, она также приносит пользу следующим образом:
- Улучшает наше понимание поведения системы.
- Облегчает планирование тестирования, оценку и отслеживание хода работы.
- Дает возможность оценить тестовое покрытие.
- Предоставляет возможность выполнить анализ зависимостей.
Декомпозиция может быть выполнена на разных уровнях в зависимости от контекста и потребностей проекта. Существуют такие уровни декомпозиции, как эпики, сценарии использования (юзкейсы), веб-страницы/экраны, модули, объекты и т. д. Эти уровни декомпозиции не являются взаимоисключающими, они могут дополнять друг друга. Например, система может быть декомпозирована на несколько юзкейсов, и каждый юзкейс может включать в себя несколько веб-страниц.
Распространенным подходом является декомпозиция на уровне объектов. Объекты представляют собой сущности или концепции в системе, которые имеют определенные параметры (свойства) и действия (поведение).
Для тест-анализа на уровне Продукта мы будем анализировать объекты и их действия.
Рассмотрим этапы декомпозиции продукта на примере приложения Slack.
Шаг 1: Определите объекты
Вот некоторые объекты, которые мы можем определить:
Можно ли разбить все функциональные возможности системы на объекты? Нет, и, как было сказано выше, мы можем комбинировать различные уровни декомпозиции. Для описания других функциональных возможностей мы будем использовать эпики в дополнение к объектам.
Эпик представляет собой большую фичу или набор связанных фич.
Шаг 2: Определите действия для каждого объекта
Следующий шаг — определение действий, которые могут быть выполнены над объектом или самим объектом.
Шаг 3: Определите альтернативные методы выполнения действий
В системе могут быть разные способы выполнения одного и того же действия, которые необходимо отметить.
Этап 2: Расстановка приоритетов (приоритизация)
Не все фичи одинаково ценны и важны для пользователей. Наличие списка приоритетных фич позволяет нам:
- Начать тестирование более важных фич, чтобы в случае нехватки времени на тестирование всех фич оставить менее важные вне области тестирования;
- Найти более критичные баги раньше и иметь достаточно времени для их исправления и предотвращения задержек релиза;
- Создать различные тестовые наборы (например, набор смок-тестирования для критических фич и набор регрессионного тестирования для критических и основных фич).
Шаг 4: Определение приоритетов для каждого объекта/эпика
Более продвинутый подход заключается в том, чтобы расставить приоритеты для каждого действия объекта.
Этап 3: Анализ зависимостей
Большинство фич в системе часто связаны с другими фичами. Следующим важным шагом является анализ зависимостей, который включает в себя выявление связей между определенными объектами/элементами, понимание того, как они взаимодействуют друг с другом.
Анализ зависимостей помогает:
- Определить связанные фичи в системе и гарантировать, что во время тестирования будут покрыты все необходимые сценарии.
- Определить потенциальное влияние изменений/обновлений конкретной фичи на другие связанные функции.
- Оценить потенциальное влияние существующих дефектов на другие зависимые фичи и выполнить целенаправленное тестирование для снижения таких рисков.
Анализ зависимостей часто документируется в виде матрицы. Матрица состоит из строк и столбцов, где каждая строка и столбец представляют объект (или другой элемент, который использовался для декомпозиции). Ячейки в матрице указывают на зависимости между ними.
Итак, нам нужно просмотреть список объектов/эпиков и подумать, как они взаимодействуют друг с другом, ища любые зависимости, такие как:
- Функциональные зависимости — один объект зависит от вывода или поведения другого.
- Зависимости от данных — один объект требует определенных данных от другого.
Шаг 5: Определите зависимости между объектами/эпиками
Вот пример матрицы анализа зависимостей.
Это однонаправленная матрица, используется только половина матрицы, зеленые ячейки подчеркивают взаимосвязи между элементами. Дополнительные столбцы или примечания могут использоваться для документирования специфики каждой зависимости.
Более продвинутый подход — двунаправленная матрица, которая анализирует обе стороны отношений, показывая, какие элементы зависят от других и обратные зависимости.
Элементы вверху в столбцах зависят от элементов слева в строках, и, соответственно, элементы в строках влияют на элементы в столбцах. Например, мы видим, что объект Messages зависит от Users, Workspaces, Channels, а также влияет на History и Search.
Этот тип матрицы дает более полное представление, с более подробным анализом. Выбор между однонаправленными и двунаправленными матрицами зависит от уровня детализации, необходимого для проекта, и рекомендуется для критически важного ПО.
Что ж, мы проделали большую работу и теперь имеем прочный фундамент для понимания следующего уровня тест-анализа. Далее рассмотрим алгоритм тест-анализа на уровне продукта.
Все эти действия могут быть выполнены в следующей последовательности:
- Сбор информации на основе:
- Документации по продукту (требования, пользовательские истории, мануалы пользователя и т. д.).
- Самого продукта (исследовательское тестирование).
- Общения с аналитиками, разработчиками, стейкхолдерами и т. д.
- Визуализация информации
- Можно использовать различные таблицы, дорожные карты, диаграммы и т. д.
- Ревью
- Проанализируйте результаты работы с командой и стейкхолдерами, чтобы найти пропущенную или неверную информацию и внести соответствующие исправления.
- Поддерживайте все в актуальном состоянии
- По мере развития продукта продолжайте обновлять и поддерживать документацию, иначе она не будет стоить затраченных усилий, быстро устареет и станет бесполезной.
Тест-анализ на уровне фич
Мы изучили тест-анализ системы в целом и теперь готовы пойти дальше и рассмотреть анализ конкретных фич.
Существует три основных вида деятельности тест-анализа на уровне фич:
- Декомпозиция тестируемого объекта.
- Тест-дизайн — создание тест-кейсов с использованием соответствующих техник тест-дизайна.
- Анализ зависимостей — определение отношений между тестируемой фичей и другими фичами в системе.
Этап 1: Декомпозиция
Для тест-анализа на уровне продукта, то есть высокоуровневого анализа системы, достаточно определить действия объекта в процессе декомпозиции, но для тест-анализа на уровне фичи нам нужно пойти дальше и описать параметры тестируемого объекта.
Параметры — это свойства или характеристики объекта, они определяют конкретные условия, поведение или конфигурации, связанные с этим объектом. По сути, параметры — это значения, которые выступают в качестве входных данных, предоставляя информацию, необходимую для выполнения определенной операции.
Итак, имеем следующую последовательность декомпозиции:
На примере Slack рассмотрим функцию создания учетной записи.
Шаг 1: Определите объект и действие
- Объект: Пользователь
- Действие: Создать учетную запись
Шаг 2: Определение параметров действия
Для создания учетной записи пользователю необходимо отправить форму со следующими параметрами:
- Полное имя
- Пароль
У каждого параметра есть требования относительно того, какие значения он должен принимать:
- Полное имя:
— 1-50 символов
Необходимый
- Пароль:
— 6-30 символов —
Необходимый
- Email:
— Да, по умолчанию
Далее нам нужно создать тестовые данные для проверки отправки формы с различными значениями каждого параметра, чтобы убедиться, что допустимые значения принимаются, а недопустимые отклоняются.
Шаг 3: Определение тестовых данных для каждого параметра
Существует большое количество возможных значений, которые можно проверить, и обычно нет столько времени, чтобы проверить все возможные значения каждого параметра. Вместо этого мы можем изучить методы тест-дизайна, которые помогут определить минимально эффективный набор тестовых данных.
Этап 2: Тест-дизайн
Переходим к следующему этапу — созданию тест-кейсов с использованием соответствующих методов тестздизайна.
Для проверки тестовых данных чаще всего используются следующие методы:
Однако тестирование ввода — это не все проверки, которые мы должны проводить. Многие тесты включают в себя тестирование бизнес-логики, которая находится «под» пользовательским интерфейсом. Наиболее известными техниками, направленными в первую очередь на тестирование функциональности бизнес-логики, являются:
Техники тест-дизайна помогают сократить количество тестов при сохранении высокого уровня покрытия. Однако есть несколько важных моментов, которые следует помнить о методах тест-дизайна:
- Не существует одной идеальной техники для всех ситуаций. Важно понимать применимость каждой техники в каждом случае и выбирать наиболее подходящую технику.
- Усилия по разработке тестов должны быть приоритизированными и сбалансированными, чтобы соответствовать рискам и ценности для бизнеса.
Этап 3: Анализ зависимостей
На уровне фич нам также необходимо провести анализ зависимостей, поскольку обычно каждая новая фича взаимодействует с существующими. Поэтому нам нужно выяснить эти взаимодействия и возможные зависимости.
Мы должны взять список наших объектов/эпиков (созданный на этапе тест-анализа продукта), пройти их по одному и подумать, взаимодействует ли он с тестируемой фичей.
Проведем анализ зависимостей для фичи «Отправка сообщений» в Slack.
Шаг 1: Найти связанные объекты
- Каналы: мы можем отправить сообщение в канал
- Пользователи: мы можем отправить прямое сообщение одному пользователю и группе пользователей
Шаг 2: Определить состояния связанных объектов
- Каналы: Активен, Архивирован, Удален
- Пользователи: Приглашенные, Активные, Деактивированные
Шаг 3: Определить параметры связанных объектов
- Каналы: Публичный, Личный
- Пользователи: Обычный пользователь, Гостевой пользователь, Внешний пользователь
Теперь мы можем расширить тест-кейсы для фичи «Отправка сообщений» следующими верификациями:
- Отправить сообщение на канал:
— в разных состояниях (Активный, Архивный, Удаленный)
— с разным типом (Публичный, Личный)
- Отправить прямое сообщение одному пользователю:
— в разных состояниях (Приглашен, Активен, Деактивирован)
— с разным типом (Обычный пользователь, Гость, Внешний пользователь)
- Отправить прямое сообщение группе пользователей:
— в разных состояниях (Приглашен, Активен, Деактивирован)
— с разным типом (Обычный пользователь, Гость, Внешний пользователь)
Теперь вспомним шаги тест-анализа на уровне фичи.
Резюме
Итак, мы узнали, что тест-анализ может проводиться на разных уровнях:
- Уровень продукта — высокоуровневый анализ всего продукта, который является основой для дальнейшего тест-анализа на уровне фич.
- Уровень фич — детальный анализ конкретной фичи в продукте, где мы определяем область тестирования фичи и разрабатываем тест-кейсы.
Ниже приведена диаграмма, иллюстрирующая уровни тест-анализа и деятельности:
Структурированный и всесторонний тест-анализ дает следующие преимущества:
- Обеспечивает глубокое понимание продукта.
- Определяет объем тестирования.
- Обеспечивает концентрацию усилий по тестированию на критических фичах и потенциальных областях отказа.
- Помогает достичь максимального тестового покрытия при минимальной избыточности.
- Способствует предотвращению дефектов путем выявления проблем в требованиях.
- Помогает упорядочить информацию и снижает вероятность неправильного понимания.
Важно отметить, что тест-анализ приносит пользу не только QA-команде, но и всей команде проекта. Он способствует сотрудничеству между членами команды, а документация по тест-анализу служит источником для справок, проверок и передачи знаний внутри команды.
Хорошо организованный процесс тест-анализа обеспечивает достаточный уровень уверенности в эффективности тестирования и способствует поставке высококачественного ПО.
