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

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

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

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

  • Уровень тестирования

  • Сложность системы

  • Проектные и продуктовые риски

  • Модель жизненного цикла программного обеспечения

  • Инструменты тест-менеджмента

  • Зрелость процесса тестирования

  • Возможность проконсультироваться с другими участниками проекта

  • Квалификация тест-аналитика

    По результатам тест - анализа необходмо выяснить:

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

Тестовое покрытие

После определения причастных сторон, ознакомления с документацией и архитектурой продукта/системы, критериями приемки, мы должны определиться с объемом тестирования и видами тестирования.
Для начала проводится логическая декомпозиция системы и далее мы прикидываем, какие тест - сценариями можно использовать.
Например:

Функциональное позитивное (в т.ч.безопасности):

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

Выполняется тестировщиками ручным и автоматическим методами.

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

  • Тесты на проверку отдельной функциональности
  • UI - тесты
  • АPI - тесты
  • Интеграционные тесты
  1. Позитивные тесты безопасности:
  • возможность получения токенов, ключей, сертификатов в предусмотренных условиях с корректными запросами
  • E2E и UI-тесты под предусмотренными ролевой моделью ролями, работа с формами и сущностями (данными)

Функциональное негативное ( в т.ч.безопасности ):

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

Нефункциональное тестирование
( нагрузочное, стресс - тестирование, тестирование стабильности и надежности, тестирование выностивости, объемное тестирование, тестирование установки, тестирование удобства пользования, тестирование на отказ и восстановление, тестирование совместимости):

  • обычные нагрузочные тесты, стресс-тесты, тесты на отказоустойчивость и т.п.
  • обычные тесты на корректную работу (запуск) в различных предусмотренных конфигурациях
  • обычные тесты на корректный запуск приложения в различном environment и ОС
  • обычные тесты на установку приложения с соблюдением SLA
  • симуляция недоступности БД в процессе работы
  • симуляция потери данных в процессе работы (удаление файлов, сущностей в БД)
  • симуляция потери доступа к транспорту
  • симуляция недоступности портов и ресурсов
  • симуляция стопора в очереди в транспорте (недоступность Kafka/RabbitMQ, снижение пропускной способности)

Риски тестирования

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

Тест - дизайн – это этап процесса тестирования ПО, на котором проектируются и создаются тестовые случаи (тест кейсы), в соответствии с определёнными ранее критериями качества и целями тестирования.

План работы над тест - дизайном:

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

Роли, ответственные за тест - дизайн:

  • тест -аналитик определяет ЧТО тестировать

  • тест - дизайнер определяет КАК тестировать

    Попросту говоря, задача тест аналитиков и дизайнеров сводится к тому, чтобы используя различные стратегии и техники тест дизайна, создать набор тестовых случаев, обеспечивающий оптимальное тестовое покрытие тестируемого приложения. Однако, на большинстве проектов эти роли не выделяется, а доверяется обычным тестировщикам, что не всегда положительно сказывается на качестве тестов, тестировании и, как из этого следует, на качестве программного обеспечения (конечного продукта).

Анализ и декомпозирование требований

Аналих требований - часть процесса разработки программного обеспечения, включающая прочесс сборки требований к нему, их систематизацию, выявление взаимосвизи и документирование. В процессе сбора требований важно важно принимать во внимания возможные противоречия тебований различных заинтерисованных сторон. Полнота и качество анализа требований играют ключевую роль в успехе раазработки проекта.
Анализ требований включает в себя следующее:

  1. Сбор требований - общение с клиентами и пользователями, чтобы определить. каковы их требования; анализ предметной области.
  2. Анализ требований - определение, являются ли собранные требования полным. ясными и не противочащими друг другу.
  3. Документирование требований - требования могут быть задокументированы в разлитных формах, таких как простое описание, сценарии пользователя описание поведения системы, когда она взаимодействует с кем-то (или чем-то) из внешней среды.), пользовательские истории или спецификации процессов.

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

Требование — это не функция системы, а описание задачи или проблемы, которую хочет решить конкретный человек.

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

Процесс анализа требований к информационной системе включает следующие фазы:

  1. Разработка требований
  2. Выявление требований
  3. Анализ требований
  4. Спецификация требований
  5. Проверка требований
  6. Управление требованиями

Уровни требований к ПО:

1.Бизнес - требования
2.Требования пользователей
3.Функциональные требования

Бизнес -требования содержат высокоуровневые цели организации или заказчиков системы. Как правило, их высказывают те, кто финансируют проект, покупатели системы, менеджер реальных пользователей, отдел маркетинга.
Требования пользователей (user requirements) описывают цели и задачи, которые пользователям позволит решить система. К отличным способам представления этого вида требований относятся варианты использования, сценарии и таблицы «событие — отклик». Таким образом, в этом документе указано, что клиенты смогут делать с помощью системы.
Функциональные требования определяют функциональность ПО, которую разработчики должны построить, чтобы пользователи смогли выполнить свои задачи в рамках бизнес-требований.

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

Декомпозиция имее ряд преимуществ:

  1. Возможность быстро получить фидбек
  2. Быстрое тестирование и багфикс
  3. Определение важной и менее важной работы
  4. Лучшая прогнозируемость результатов спринта
  5. Больше доверия и веры в себя
  6. Смягчение рисков
  7. Лучшее распределение работы в рамках спринта