1 ДОКУМЕНТИРОВАННОСТЬ ПРОЦЕССА ТЕСТИРОВАНИЯ, ТЕСТОВАЯ ДОКУМЕНТАЦИЯ

1.1. Что такое тестовая документация

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

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

1.2.  Важность тестовой документации

Тестовая документация играет ключевую роль в процессе тестирования программного обеспечения.

Тестовая документация  – это не просто «бумажки» или «галочки». Это рабочий инструмент, который решает следующие задачи:

Обеспечение качества: Тестовая документация помогает структурировать и систематизировать процесс тестирования, что способствует выявлению ошибок и дефектов на ранних стадиях разработки. Это, в свою очередь, повышает общее качество продукта.

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

Упрощение передачи знаний: Тестовая документация служит источником информации для новых членов команды и других заинтересованных сторон. Она помогает быстро понять, как проводилось тестирование, какие были выявлены проблемы и как они были решены.

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

Обеспечение соответствия требованиям: Тестовая документация помогает убедиться, что все требования и спецификации были учтены и протестированы. Это особенно важно для соблюдения стандартов и регуляторных требований в некоторых отраслях.

Упрощение анализа результатов: Документация позволяет легко анализировать результаты тестирования, выявлять паттерны ошибок и определять области, требующие улучшений. Это способствует более эффективному управлению качеством.

Поддержка автоматизации тестирования: Хорошо структурированная тестовая документация может быть использована для создания автоматизированных тестов, что ускоряет процесс тестирования и снижает вероятность человеческих ошибок.

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

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

2 ИЕРАРХИЯ ТЕСТОВОЙ ДОКУМЕНТАЦИИ

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

2.1. Стратегия тестирования (Master Test Plan / Test Strategy)

Это документ самого высокого уровня, который определяет общие принципы и подходы к обеспечению качества. Он создается для всей компании, линейки продуктов или для типовых проектов и отвечает на вопрос «Как мы в принципе тестируем?».

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

Что определяет Стратегия:

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

·            Типы тестирования: Какие виды проверок являются обязательными для всех проектов (например, функциональное тестирование обязательно, нагрузочное  – только для highload-систем, безопасность  – для проектов с платежами).

·            Инструментарий: Утвержденный стек инструментов (например, баг-трекинговая система  – Jira, автотесты  – Selenium/Playwright, CI/CD  – Jenkins).

·            Подход к автоматизации: Общие цели по автоматизации (например, стремиться к 70% покрытию автотестами критического пути).

·            Управление рисками: Методологии работы с рисками на уровне организации.

Кто создает: Тест-менеджер, руководитель тестирования, архитектор ПО.

Изменяемость: Очень низкая. Изменения вносятся только при фундаментальных изменениях в компании.

2.2. Мастер-тест-план (Master Test Plan)

Это основной документ этапа тестирования для конкретного проекта. Он конкретизирует общую Стратегию применительно к данному продукту и служит основой для всех остальных тестовых документов. Мастер-тест-план  – это «конституция» тестирования для проекта, которая отвечает на вопрос «Что, где и когда мы тестируем в проекте "Х"?».

В отличие от стратегии, Мастер-тест-план учитывает уникальные особенности проекта: сроки, бюджет, специфику требований.

Содержание Мастер-тест-плана:

1. Введение и цели - краткое описание проекта и целей тестирования. Определение критических аспектов качества для успеха продукта.

2. Объект и объем тестирования (Scope)

o     что тестируется: Перечень функций, модулей и подсистем.

o     Что НЕ тестируется- четкое определение границ ответственности (например, «интеграция со сторонним API не тестируется, так как это зона ответственности вендора»). Это критически важно для управления ожиданиями заказчика.

3. Подходы и стратегия:

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

o     Определение типов тестов для проекта: функциональное, нагрузочное, безопасности, удобства использования и т.д.

4. Ресурсы и окружение:

o     Команда: роли и ответственность.

o     Тестовые стенды: фиксация тестовой конфигурации (состав и параметры аппаратуры, ПО, операционных систем).

o     Инструменты и лицензии.

5. График и этапы (Расписание тестовых циклов) Крупные вехи (milestones): даты начала и окончания основных фаз (дымовое тестирование, функциональное, регрессионное).

6. Критерии:

o     Критерии начала: Условия, при которых можно приступать к тестированию (например, успешное прохождение дымного теста разработчиками, готовность стенда).

o     Критерии окончания: Четкие метрики, сигнализирующие о том, что тестирование можно считать завершенным (например, все критические баги закрыты, покрытие требований  – 95%, пройдены все приоритетные тест-кейсы).

7. Метрики: Список тестовых метрик для сбора и анализа в ходе проекта: плотность дефектов, процент покрытия требований, скорость выполнения тестов.

           8. Риски: Анализ специфических для проекта рисков (например, сжатые сроки, нестабильность требований) и план действий по их минимизации.

Кто создает: Тест-менеджер или ведущий тестировщик (Test Lead).

Изменяемость: Средняя. Может корректироваться при изменении сроков, бюджета или требований к продукту.

2.3. Тест-план (Test Plan)

Это документ операционного уровня, который описывает, как будет проводиться тестирование для конкретной итерации: релиза, спринта или отдельного типа тестирования (например, тестирование безопасности или установки).

Тест-план отвечает на вопрос «Какую именно кнопку, в какой последовательности и кто будет проверять на этой неделе?». Тестовые сценарии удобно объединять в тест-планы по назначению:

·            тестирование релиза (очередной версии продукта);

·            тестирование развертывания / инсталляции;

·            тестирование удобства использования (UI/UX);

·            конфигурационное тестирование;

·            тестирование безопасности.

Содержание Тест-плана:

1.         Область применения (в контексте Master Plan):  Ссылка на Мастер-тест-план. Уточнение, что данный план является его частью.

o     Детальный объем: Список конкретных функций, фич или багов, которые будут проверяться в данном цикле.

2.         Типы тестов: Определение конкретных типов тестирования для данной итерации. Например, в этом спринте мы проводим только функциональное тестирование нового модуля оплаты и регресс старого функционала.

Классификация тестов может идти по двум категориям:

§   По виду подсистемы: тестирование инсталляции, тестирование документации, тестирование основной функциональности.

§   По способу выбора входных данных: функциональное тестирование, стрессовое, тестирование граничных значений, тестирование производительности, совместимости.

3.         Расписание (Scheduler): Подробный график на дни/часы: кто из команды, что и когда делает («Понедельник, 10:00  – смок-тест сборки; Вторник  – прогон чек-листов по модулю "Регистрация"»).

4.         Тестовые данные: Описание конкретных входных данных, которые будут использоваться.

5.         Результаты и отчетность: Формат предоставления результатов тестирования для данной итерации (отчет, список ошибок).

Кто создает: Тест-лид или назначенный тестировщик.

Изменяемость: Высокая. Это живой документ, который может меняться каждый спринт.

2.4. Визуализация требований

Визуализация требований помогает команде лучше понять функциональность приложения и его требования. К основным инструментам визуализации относятся:

·            Матрица трассировки требований (traceability matrix): Этот инструмент позволяет отслеживать, какие требования были протестированы и какие тесты к ним относятся. Это помогает убедиться, что все требования покрыты тестами и ничего не упущено.

Матрица соответствия требований (traceability matrix, трассируемость требования в тестах)  – это двумерная таблица, содержащая соответствие функциональных требований ПО и подготовленных тестовых сценариев.

В заголовках колонок таблицы расположены требования, а в заголовках строк  – тестовые сценарии.

На пересечении  – отметка, означающая, что требование текущей колонки покрыто тестовым сценарием текущей строки.

Матрица соответствия требований используется руководителями тестирования ПО для валидации покрытия продукта тестами и является неотъемлемой частью тест- плана.

Данный QA-термин  – абсолютный рекордсмен по количеству русскоязычных названий.

Их не меньше десяти:

·  Матрица отслеживания требований

·  Матрица прослеживаемости требований

·  Матрица сверки требований

·  Матрица слежения за требованиями

·  Матрица соответствия требований

·  и просто матрица требований

Также встречаются названия:

·  Матрица трассировки требований

·  Матрица трассируемости (и именно это название одобрено ISTQB)

·  и матрица трассабилити.

·  Также называют просто RTM-матрицей.

Отслеживание требований может быть как прямое («от требований к коду»), так и обратное («от кода к требованиям»).

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

RTM-матрица наполняется тестировщиками, отвечающими за функцию/модуль/часть приложения, и передается менеджеру или лиду. Лид проверяет репозитории, и если соответствующие тест-кейсы существуют, утверждает матрицу. В общем виде это простая стандартная worksheet-таблица, создаваемая по шаблону.

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

Нюансы

·  Матрица создается до утверждения требований и перед выполнением тест-кейсов

·  Матрицу пишут с учетом, что какой-то тест-кейс может быть отменен

·  Задача матрицы отслеживания  – чтобы каждое требование имело хотя бы один тест-кейс, не обязательно чтобы на одно требование было много тест-кейсов

Типы матрицы

Существует три типа матрицы сверки требований:

·  Прямая

·  Обратная

·  Двунаправленная

Прямое отслеживание

Помогает проверить, что каждое бизнес-требование корректно имплементировано и качественно протестировано, что разработка продукта идет правильно.

Обратное отслеживание

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

Двусторонняя Матрица

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

Преимущества и важность матрицы отслеживания требований

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

Именно здесь матрица отслеживания требований становится незаменимой, предлагая следующие преимущества:

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

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

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

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

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

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

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

·       Майндмап: Визуальная карта, которая помогает структурировать информацию о проекте и его требованиях. Она позволяет команде увидеть взаимосвязи между различными требованиями и функциональностью.

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

3. ДЕТАЛЬНАЯ ДОКУМЕНТАЦИЯ ТЕСТИРОВАНИЯ

3.1. Тест-сценарий (сценарий тестирования)

Тестовые сценарии работают на более высоком уровне тестирования. Они менее подробны, как бы более «человечны» и ориентированы на «путь пользователя» по приложению/сайту.

Тестовые сценарии  – высокоуровневые средства тестирования. Они ориентированы на «общий вид» приложения, его функциональности (или юзабельности).

Тестовые сценарии дают как бы «общий путь» описание того, ЧТО тестировать без деталей "как", и могут ссылаться на детальные тест-кейсы.

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

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

Создавая тестовый сценарий, QA-инженер как бы «ставит себя на место пользователя»; в сценарии он описывает ситуации, возникающие в приложении.

Сценарии могут быть как позитивными, так и негативными.

Тестовые сценарии используются на этапе планирования тестирования, когда нужно определить, какие функции или процессы тестировать

Как писать тестовый сценарий

·  Ознакомиться с требованиями в проекте, то есть со документами (спецификациями) системных требований (System Requirement Specifications, SRS), бизнес-требований (BRS), и функциональных требований (FRS). Изучить юз-кейсы приложения, мануалы и другие дополнительные материалы.

·  По каждому требованию уточнить технические аспекты.

·  Понять основные варианты взаимодействия пользователя с приложением.

·  Определить возможные сценарии некорректного использования (и в частности злонамеренного)

·  После ознакомления с требованиями подготовить список тест-кейсов проверки каждой функции приложения

·  После определения базовых тестовых сценариев подготовить матрицу трассировки требований, где будут сопоставлены требования с тестовыми сценариями.

·  Сценарии подаются на согласование руководителю проекта / тест-менеджеру / лиду и стейкхолдерам.

Несколько советов

·  Иметь под рукой список часто используемых функций и модулей

·  В сценариях проверять модули по одному, поддерживая порядок и не забывая о второстепенных модулях

·  Сценарии лучше делать «на уровне модуля»

·  Стараться не удалять готовые сценарии, чтобы потом не писать с нуля

·  Писать сценарии простым понятным языком (а ещё лучше Simple English)

·  Лаконичность  – каждый сценарий лучше уложить в одну-две строчки (не абзацев)

Почему нужен тестовый сценарий

·  Качественные тестовые сценарии дают полное тестовое покрытие

·  Сквозная проверка функциональности функций и всего приложения

·  Проверка важных транзакций/взаимодействий

·  Проверка приложения на всех уровнях всеми привлеченными сторонами

Когда тестовый сценарий не нужен

·  В Agile-методологиях типа Scrum тестовые сценарии могут редко применяться

·  Когда приложение нестабильное; чрезвычайно сложное; или не хватает времени

·  Когда сценарии будут в чем-то мешать, например, регрессионному тестированию

Характеристики хорошего сценария

·  В идеале, это «указания тестировщикам, что сделать, одной строчкой»

·  Упрощает и ускоряет тестирование, устраняет «дублирование действий»

·  Создается в результате обдумывания шагов тестирования, их обсуждения, и затем записывается

·  Это серия четких последовательных действий/процедур

·  Если не хватает времени на написание многих тест-кейсов, команда выбирает вариант «один большой тестовый сценарий»

·  Хороший тестовый сценарий легко модифицировать

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

·     Цель: Какова цель этого сценария? Что он должен проверить?

·     Предпосылки: Какие условия должны быть выполнены перед началом сценария?

·     Шаги: Какова последовательность действий, которые должны быть выполнены?

·     Ожидаемый результат: Каков ожидаемый результат каждого шага?

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

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

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

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

Тестовые сценарии удобно объединять в тест-планы по назначению:

· тестирование релиза, то есть очередной версии продукта;

· тестирование развертывания;

· тестирование удобства использования;

· конфигурационное тестирование;

· тестирование безопасности и т.п.

Шаги работы с тестовыми сценариями

Общие шаги, которым могут следовать тестировщики при проверке ПО компаний с помощью тестовых сценариев.

1.         Определение цели тестирования: QA-специалисты определяют, какую функциональность или аспект системы следует протестировать.

2.         Сбор требований: тестировщики изучают документацию, чтобы понять, что должно быть протестировано.

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

4.         Выполнение: QA-специалисты следуют шагам, описанным в тестовом сценарии. Они вводят необходимые данные и взаимодействуют с системой в соответствии с инструкциями.

5.         Запись результатов: после выполнения тестового сценария тестировщики фиксируют фактические результаты и сравнивают их с ожидаемыми. Если результат не соответствует ожиданиям, то тестировщики заводят дефект.

6.         Отчётность: тестировщики составляют отчёты о результатах тестирования, включая информацию о тестовых сценариях, которые были использованы, и о найденных дефектах. Это помогает разработчикам понять, какие аспекты требуют доработки.

7.         Регрессионное тестирование: после исправления ошибок тестировщики могут повторно запустить соответствующие тестовые сценарии для проверки исправлений.

8.         Поддержка: тестовые сценарии следует регулярно обновлять по мере изменения требований или функциональности ПО, чтобы они оставались актуальными и эффективными.

3.2 Тест-кейс 

Тест-кейс – это документ, который описывает конкретный случай тестирования, т.е. как именно проверить определенный аспект системы. Это пошаговый алгоритм действий тестировщика.

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

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

Цель -: проверить конкретную функциональность, условие или требование, убедиться, что приложение (сайт) работает, как ожидалось, как прописано в требованиях..

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

Иногда термин «test case» на русский язык переводят как «тестовый случай». Это вполне адекватный перевод, но из-за того, что «тест-кейс» короче произносить, наибольшее распространение получил именно этот вариант.

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

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

Высокоуровневый тест-кейс  – тест-кейс без конкретных входных данных и ожидаемых результатов.

Цель - проверить основные функциональности без излишней детализации. Часто используются для проверки целых бизнес-сценариев.

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

Пример высокоуровневого тест-кейса:

ID тест-кейса: TC-HL-LOGIN-01
Заголовок: Проверка входа в систему
Модуль: Авторизация
Приоритет: Высокий
Предусловия: Пользователь зарегистрирован в системе.
Шаги:

1. Перейти на страницу входа.

2. Ввести валидные учетные данные.

3. Нажать кнопку входа.

Ожидаемый результат: Пользователь успешно входит в систему и перенаправляется на главную страницу.

Высокоуровневые тест-кейсы подходят для:

·   Приемочного тестирования (UAT)

·   Смоук-тестов

·   Тестирования опытными тестировщиками

·  Быстрого покрытия основных сценариев

Низкоуровневый тест-кейс  – тест-кейс с конкретными входными данными и ожидаемыми результатами.

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

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

Пример низкоуровневого тест-кейса:

ID тест-кейса: TC-LL-LOGIN-01
Заголовок: Проверка входа в систему с валидным email и паролем
Модуль: Авторизация
Приоритет: Высокий
Предусловия:

·            Пользователь с email testuser@example.com и паролем Password123! зарегистрирован в системе.

·            Открыт браузер Chrome версии 115.

·            URL страницы входа: https://example.com/login.

Шаги:

1.         В поле "Email" ввести testuser@example.com.

2.         В поле "Пароль" ввести Password123!.

3.         Нажать кнопку с текстом "Войти".

Ожидаемый результат:

·            Происходит перенаправление на URL https://example.com/dashboard.

·            В верхнем правом углу отображается текст "Добро пожаловать, testuser@example.com".

Низкоуровневые тест-кейсы необходимы для:

-  Регрессионного тестирования

-  Тестирования новыми членами команды

-  Автоматизации тестирования

-  Сложных функциональных проверок

-  Юридически значимых систем

Практический совет: Использование комбинированного подхода:

1.         Высокоуровневые - для основных пользовательских сценариев

2.         Низкоуровневые - для критически важных и сложных функций

Это позволяет балансировать между скоростью написания тестов и точностью их выполнения.

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

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

Спецификация тест  – документ, состоящий из спецификации тест-дизайна, спецификации тест-кейса и/или спецификации тест-процедуры.

 Цель написания тест-кейсов

Тестирование можно проводить и без тест-кейсов (не нужно, но можно; да, эффективность такого подхода варьируется в очень широком диапазоне в зависимости от множества факторов).

Наличие же тест-кейсов позволяет:

  Структурировать и систематизировать подход к тестированию (без чего крупный проект почти гарантированно обречён на провал).

  Вычислять метрики тестового покрытия (test coverage 296 metrics) и принимать меры по его увеличению (тест-кейсы здесь являются главным источником информации, без которого существование подобных метрик теряет смысл).

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

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

  Хранить информацию для длительного использования и обмена опытом между сотрудниками и командами (или как минимум  – не пытаться удержать в голове сотни страниц текста).

  Проводить регрессионное тестирование и повторное тестирование (которые без тест-кейсов было бы вообще невозможно выполнить).

  Повышать качество требований (мы это уже рассматривали: написание чек-листов и тест-кейсов  – хорошая техника тестирования требований).

  Быстро вводить в курс дела нового сотрудника, недавно подключившегося к проекту.

 Жизненный цикл тест-кейса

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

  Создан  – типичное начальное состояние практически любого артефакта. Тест-кейс автоматически переходит в это состояние после создания.

  Запланирован  – в этом состоянии тест-кейс находится, когда он

или явно включён в план ближайшей итерации тестирования, или как минимум готов для выполнения.

  Не выполнен  – в некоторых системах управления тест-кейсами это состояние заменяет собой предыдущее («запланирован»). Нахождение тест-кейса в данном состоянии означает, что он готов к выполнению, но ещё не был выполнен.

  Выполняется  – если тест-кейс требует длительного времени на выполнение, он может быть переведён в это состояние для подчёркивания того факта, что работа идёт, и скоро можно ожидать её результатов. Если выполнение тест-кейса занимает мало времени, это состояние, как правило, пропускается, а тест-кейс сразу переводится в одно из трёх следующих состояний  – «провален», «пройден успешно» или «заблокирован».

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

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

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

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

  Закрыт  – очень редкий случай, т.к. тест-кейс, как правило, оставляют в состояниях «провален / пройден успешно / заблокирован / пропущен». В данное состояние в некоторых системах управления тест-кейс переводят, чтобы подчеркнуть тот факт, что на данной итерации тестирования все действия с ним завершены.

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

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

Атрибуты (поля) тест-кейса.

В общем смысле классический тест-кейс включает в себя:

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

·            Шаги выполнения: Подробное описание действий, которые необходимо выполнить для проведения теста.

·            Ожидаемые результаты: Результаты, которые должны быть получены в результате выполнения теста.

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

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

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

Расшифровка тестовых информационных полей:

Общий вид всей структуры тест-кейса представлен ниже:

Атрибуты:.

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

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

UR216_S12_DB_Neg).

  Приоритет   показывает важность тест-кейса. Он может быть выражен буквами (A, B, C, D, E), цифрами (1, 2, 3, 4, 5), словами («крайне высокий», «высокий», «средний», «низкий», «крайне низкий») или иным удобным способом. Количество градаций также не фиксировано, но чаще всего лежит в диапазоне от трёх до пяти.

Приоритет тест-кейса может коррелировать с:

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

  потенциальной важностью дефекта, на поиск которого направлен тест-кейс;

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

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

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

как прослеживаемость.

Частые вопросы, связанные с заполнением этого поля, таковы:

  Можно ли его оставить пустым? Да. Тест-кейс вполне мог разрабатываться вне прямой привязки к требованиям, и (пока?) значение этого поля определить сложно. Хоть такой вариант и не считается хорошим, он достаточно распространён.

  Можно ли в этом поле указывать несколько требований? Да, но чаще всего стараются выбрать одно самое главное или «более высокоуровневое» (например, вместо того чтобы перечислять R56.1, R56.2, R56.3 и т.д., можно просто написать R56). Чаще всего в инструментах управления тестами это поле представляет собой выпадающий список, где можно выбрать только одно значение, и этот вопрос становится неактуальным. К тому же многие тест-кейсы всё же направлены на проверку строго одного требования, и для них этот вопрос также неактуален.

  Модуль и подмодуль приложения   указывают на части приложения,

к которым относится тест-кейс, и позволяют лучше понять его цель.

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

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

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

Теперь  – самое сложное: как выбираются модули и подмодули. В реальности проще всего отталкиваться от архитектуры и дизайна приложения. Например, в уже знакомом нам приложении можно выделить такую иерархию модулей и подмодулей:

  Механизм запуска:

    механизм анализа параметров;

    механизм сборки приложения;

    механизм обработки ошибочных ситуаций.

  Механизм взаимодействия с файловой системой:

    механизм обхода дерева SOURCE_DIR;

    механизм обработки ошибочных ситуаций.

  Механизм преобразования файлов:

    механизм определения кодировок;

    механизм преобразования кодировок;

    механизм обработки ошибочных ситуаций.

  Механизм ведения журнала:

    механизм записи журнала;

    механизм отображения журнала в консоли;

    механизм обработки ошибочных ситуаций. 

Согласитесь, что такие длинные названия с постоянно повторяющимся словом «механизм» читать и запоминать сложно. Перепишем:

  Стартер:

    анализатор параметров;

    сборщик приложения;

    обработчик ошибок.

  Сканер:

    обходчик;

    обработчик ошибок.

  Преобразователь:

    детектор;

    конвертер;

    обработчик ошибок.

  Регистратор:

    дисковый регистратор;

    консольный регистратор;

    обработчик ошибок. 

Но что делать, если мы не знаем «внутренностей» приложения (или не очень разбираемся в программировании)? Модули и подмодули можно выделять на основе графического интерфейса пользователя (крупные области и элементы внутри них), на основе решаемых приложением

задач и подзадач и т.д. Главное, чтобы эта логика была одинаковым образом применена ко всему приложению. 

Внимание! Частая ошибка! Модуль и подмодуль приложения  – это НЕ действия, это именно структурные части, «куски» приложения. В заблуждение вас могут ввести такие названия, как, например, «печать, настройка принтера» (но здесь имеются в виду именно части приложения, отвечающие за печать и за настройку принтера (и названы

они отглагольными существительными), а не процесс печати или настройки принтера).

Сравните (на примере человека): «дыхательная система, лёгкие»  – это модуль и подмодуль, а «дыхание», «сопение», «чихание»  – нет; «голова, мозг»  – это модуль и подмодуль, а «кивание», «думание»  – нет.

Наличие полей «Модуль» и «Подмодуль» улучшает такое свойство тест-кейса, как прослеживаемость.

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

Сравните.

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

  Информативность.

  Хотя бы относительная уникальность (чтобы не путать разные тест-кейсы).

Внимание! Частая ошибка! Если инструмент управления тест-кейсами не требует писать заглавие, его   всё равно надо писать  . Тест-кейсы без заглавий превращаются в мешанину информации, использование которой сопряжено с колоссальными и совершенно бессмысленными затратами.

И ещё одна небольшая мысль, которая может помочь лучше формулировать заглавия. В дословном переводе с английского «test case» обозначает «тестовый случай (ситуация)». Так вот, заглавие как раз и описывает этот случай (ситуацию), т.е. что происходит в тест-кейсе, какую

ситуацию он проверяет.

  Исходные данные, необходимые для выполнения тест-кейса, предусловия  , позволяют описать всё то, что должно быть подготовлено до начала выполнения тест-кейса, например:

  Состояние базы данных.

  Состояние файловой системы и её объектов.

  Состояние серверов и сетевой инфраструктуры.

То, что описывается в этом поле, готовится БЕЗ использования тестируемого приложения, и таким образом, если здесь возникают проблемы, нельзя писать отчёт о дефекте в приложении.

Эта мысль очень и очень важна, потому поясним её простым жизненным примером. Представьте, что вы дегустируете конфеты. В поле «исходные данные» можно прописать «купить конфеты таких-то сортов в таком-то количестве». Если таких конфет нет в продаже, если закрыт магазин,

если не хватило денег и т. д.  – всё это НЕ проблемы вкуса конфет, и нельзя писать отчёт о дефекте конфет вида «конфеты невкусные потому, что закрыт магазин».

Внимание! Некоторые авторы не следуют этой логике и допускают в приготовлениях работу с тестируемым приложением. И здесь нет «правильного варианта»  – просто в одной традиции решено одним образом, в другой  – другим. Во многом это  – ещё и терминологическая проблема: «preparation», «initial data» и «setup» вполне логично выполнять без участия тестируемого приложения, в то время как «precondition» по смыслу ближе к описанию состояния тестируемого приложения. В реальной рабочей обстановке вам достаточно будет прочитать несколько тест-кейсов, уже созданных вашими коллегами,

чтобы понять, какой точки зрения на данный вопрос они придерживаются.

  Шаги тест-кейса   описывают последовательность действий, которые необходимо реализовать в процессе выполнения тест-кейса.

Общие рекомендации по написанию шагов таковы:

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

  даже если в тест-кейсе всего один шаг, нумеруйте его (иначе возрастает вероятность в будущем случайно «приклеить» описание этого шага к новому тексту);

  если вы пишете на русском языке, используйте безличную форму (например, «открыть», «ввести», «добавить» вместо «откройте», «введите», «добавьте»), в английском языке не надо использовать частицу «to» (т.е. «запустить приложение» будет «start application», не «to start application»);

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

  ссылайтесь на предыдущие шаги и их диапазоны для сокращения объёма текста (например, «повторить шаги 3–5 со значением...»);

  пишите шаги последовательно, без условных конструкций вида «если... то...».

Внимание! Частая ошибка! Категорически запрещено ссылаться на шаги из других тест-кейсов и другие тест-кейсы целиком: если те, другие тест-кейсы будут изменены или удалены, ваш тест-кейс начнёт ссылаться на неверные данные или в пустоту, а если в процессе выполнения те, другие тест-кейсы или шаги приведут к возникновению

ошибки, вы не сможете закончить выполнение вашего тест-кейса.

  Ожидаемые результаты   по каждому шагу тест-кейса описывают реакцию

приложения на действия, описанные в поле «шаги тест-кейса». Номер шага соответствует номеру результата.

По написанию ожидаемых результатов можно порекомендовать следующее:

  описывайте поведение системы так, чтобы исключить субъективное толкование (например, «приложение работает верно»  – плохо, «появляется окно с надписью...»  – хорошо);

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

лучше оставить в списке ожидаемых результатов пустую строку  – это облегчает восприятие);

  пишите кратко, но не в ущерб информативности;

  избегайте условных конструкций вида «если... то...».

Внимание! Частая ошибка! В ожидаемых результатах ВСЕГДА описывается КОРРЕКТНАЯ работа приложения. Нет и не может быть ожидаемого результата в виде «приложение вызывает ошибку в операционной системе и аварийно завершается с потерей всех пользовательских данных».

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

отсутствие такого сообщения, и/или повреждение, или потеря записываемых данных.

Для более глубокого понимания принципов оформления тест-кейсов рекомендуется прямо сейчас ознакомиться с главой «Типичные ошибки при разработке чек-листов, тест-кейсов и наборов тест-кейсов».

Свойства качественных тест-кейсов

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

Правильный технический язык, точность и единообразие формулировок. Это свойство в равной мере относится и к требованиям, и к тест-кейсам, и к отчётам о дефектах  – к любой документации.

Основные идеи:

  пишите лаконично, но понятно;

  используйте безличную форму глаголов (например, «открыть» вместо «откройте»);

  обязательно указывайте точные имена и технически верные названия элементов приложения;

  не объясняйте базовые принципы работы с компьютером (предполагается, что ваши коллеги знают, что такое, например, «пункт меню» и как с ним работать);

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

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

Баланс между специфичностью и общностью. Тест-кейс считается тем более специфичным, чем более детально в нём расписаны конкретные действия, конкретные значения и т. д., т. е. чем в нём больше конкретики. Соответственно, тест-кейс считается тем более общим, чем в нём меньше конкретики.

Рассмотрим поля «шаги» и «ожидаемые результаты» двух тест-кейсов (подумайте, какой тест-кейс вы бы посчитали хорошим, а какой  – плохим и почему):

Тест-кейс 1:

Тест-кейс 2:

Если вернуться к вопросу «какой тест-кейс вы бы посчитали хорошим, а какой  – плохим и почему», то ответ таков: оба тест-кейса плохие потому, что первый является слишком специфичным, а второй  – слишком общим. Можно сказать, что здесь до абсурда доведены идеи низкоуровневых и высокоуровневых тест-кейсов.

Почему плоха излишняя специфичность (тест-кейс 1):

  при повторных выполнениях тест-кейса всегда будут выполняться строго одни и те же действия со строго одними и теми же данными, что снижает вероятность обнаружения ошибки;

  возрастает время написания, доработки и даже просто прочтения тест-кейса;

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

Почему плоха излишняя общность (тест-кейс 2):

  тест-кейс сложен для выполнения начинающими тестировщиками или даже опытными специалистами, лишь недавно подключившимися к проекту;

  недобросовестные сотрудники склонны халатно относиться к таким тест-кейсам;

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

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

Вот пример такого срединного подхода:

Тест-кейс 3:

В этом тест-кейсе есть всё необходимое для понимания и выполнения, но при этом он стал короче и проще для выполнения, а отсутствие строго указанных значений приводит к тому, что

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

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

Баланс между простотой и сложностью. Здесь не существует академических определений, но принято считать, что простой тест-кейс оперирует одним объектом (или в нём явно виден

главный объект), а также содержит небольшое количество тривиальных действий; сложный тест-кейс оперирует несколькими равноправными объектами и содержит много нетривиальных

действий.

Преимущества простых тест-кейсов:

  их можно быстро прочесть, легко понять и выполнить;

  они понятны начинающим тестировщикам и новым людям на проекте;

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

  они упрощают начальную диагностику ошибки, т.к. сужают круг поиска.

Преимущества сложных тест-кейсов:

  при взаимодействии многих объектов повышается вероятность возникновения ошибки;

  пользователи, как правило, используют сложные сценарии, а потому сложные тесты более полноценно эмулируют работу пользователей;

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

Тест-кейс и тестовый сценарий  – табличное сравнение

3.3.  Чек-лист

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

Лист проверки может быть абсолютно разного уровня детализации. На сколько детальным будет чек-лист, зависит от требований к отчетности, уровня знания продукта сотрудниками и сложности продукта. Как правило, лист проверки содержит только действия (шаги), без ожидаемого результата.

Лист проверки менее формализован, чем тестовый сценарий. Его уместно использовать тогда, когда тестовые сценарии будут избыточны. Лист проверки обычно используется в гибких подходах в тестировании.

Он используется для:

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

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

Чек-лист чаще всего представляет собой обычный и привычный нам список, который может быть:

- Списком, в котором последовательность пунктов не имеет значения (например, список значений некоего поля).

-  Списком, в котором последовательность пунктов важна (например, шаги в краткой инструкции).

- Структурированным (многоуровневым) списком (вне зависимости от учёта последовательности пунктов), что позволяет отразить иерархию идей.

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

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

Поскольку в разных проектах встречаются однотипные задачи, хорошо продуманные и аккуратно оформленные чек-листы могут использоваться повторно, чем достигается экономия сил и времени.

Свойства чек-листов

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

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

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

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

Правильно создавать и оформлять чек-листы также помогает восприятие их не только как хранилища наборов идей, но как «требования для составления тест-кейсов». Эта мысль приводит к пересмотру и переосмыслению свойств качественных требований к чек-листам.

Поскольку среди всех прочих терминов этот легче и быстрее всего произносить, в зависимости от контекста под ним могут понимать и отдельный пункт чек-листа, и отдельный шаг в тест-кейсе, и сам тест-кейс, и набор тест-кейсов и продолжать можно долго. Главное здесь одно: если вы слышите или видите слово «тест», воспринимайте его в контексте.

3.4. Test Suite (Тестовый набор)

Уровень: Организационный

Что это: Группа тест-кейсов/скриптов, объединенных для совместного выполнения.

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

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

4. ТЕХНИКИ ТЕСТ-ДИЗАЙНА (МЕТОДИКИ РАЗРАБОТКИ ТЕСТОВ)

Тест-дизайн  – это этап, на котором мы решаем, какие именно тесты написать, чтобы найти максимальное количество ошибок при минимальных затратах.

Техники тест-дизайна помогают создавать эффективные тесты. К самым распространенным относятся:

·            Классы эквивалентности, эквивалентное разбиение

·            Граничные значения, анализ граничных значений

·            Таблица принятия решений.

·            Попарное тестирование.

4.1 Классы эквивалентности, эквивалентное разбиение:

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

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

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

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

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

Техника заключается в разбиении всего набора тестов на классы эквивалентности с последующим сокращением числа тестов. Целью данной техники является не только сокращение числа тестов, но и сохранение приемлемого тестового покрытия [12].

При использовании этой техники тестировщик должен помнить:

· слишком большое количество эквивалентных классов увеличивает вероятность, что множество тестов будет лишним (избыточным);

· слишком малое число эквивалентных классов увеличивает вероятность, что ошибки продукта будут пропущены.

Примерный алгоритм использования техники следующий:

1.         Разделить все возможные входные данные на классы эквивалентности. Это главный шаг техники. От него во многом зависит эффективность её применения.

2.         Выбрать одного представителя от каждого класса. На этом шаге из каждого эквивалентного набора тестов выбирают один тест.

3.         Выполнить тесты. На этом шаге выполняют тесты от каждого класса эквивалентности.

Если есть время, можно протестировать еще несколько представителей от каждого класса. Но нужно иметь в виду, что если правильно выполнен первый шаг, т. е. правильно определены классы эквивалентности, то дополнительные тесты, скорее всего, будут избыточными и дадут тот же результат.

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

Можно разбивать тесты на классы эквивалентности по разным принципам. От этого эффективность тестирования может выиграть. Например, если тестируют поле ввода, которое принимает максимум пять символов, то можно выбрать разные принципы разбиения на классы эквивалентности:

· по количеству символов;

· по типу символов (цифры, буквы, спецсимволы).

Пример. Рассмотрим функцию подсчета комиссии при отмене бронирования авиабилетов (рис. 3).

Рис. 3. Эквивалентное разбиение

Предположим, что размер комиссии зависит от времени до вы лета, когда совершена отмена:

· за 5 сут до вылета комиссия составляет 0 %;

· меньше 5 сут, но больше 24 ч – 50 %;

· меньше 24 ч, но до вылета – 75 %;

· после вылета – 100 %.

Определим классы эквивалентности (для каждого теста из этих классов мы ожидаем получить одинаковый результат):

· 1-й класс: время до вылета > 5 сут;

· 2-й класс: 24 ч < время до вылета < 5 сут;

· 3-й класс: 0 ч < время до вылета < 24 ч;

· 4-й класс: время до вылета < 0 ч (вылет уже состоялся).

Выберем представителя от каждого класса. Здесь можно выбрать любые значения из класса. Если предположить, что разделение на классы эквивалентности было правильным, то нет разницы, какое значение из диапазона будет выбрано:

· время до вылета = 10 сут (тест из 1-го класса);

· время до вылета = 3 сут (тест из 2-го класса);

· время до вылета = 12 ч (тест из 3-го класса);

· время после вылета = 30 мин (тест из 4-го класса).

Выполним тесты:

· отменим бронь за 10 сут до вылета и проверим, что комиссия составила 0 %;

· отменим бронь за 3 сут до вылета и проверим, что комиссия составила 50 %;

· отменим бронь за 12 ч до вылета и проверим, что комиссия составила 75 %;

· отменим бронь через 30 мин после вылета и проверим, что комиссия составила 100 %.

Таким образом осталось всего четыре теста. А сколько возможных тестов существует? Даже если ввести ограничение, что отмена бронирования может произойти в рамках 10 суток до вылета и 1 суток после вылета, то будет около 950 400 возможных тестов (если посчитать количество секунд в 11 сутках). Был рассмотрен очень простой пример. Редко бывает так, что функция зависит только от одной переменной. Обычно классов эквивалентности больше и выделить их сложнее [12].

Как и любая другая техника, анализ классов эквивалентности имеет достоинства и недостатки. К плюсам можно отнести заметное сокращение времени и улучшение структурированности тестирования, к минусам ‒ то, что при неправильном использовании техники есть риск потерять баги.

4. 2 Граничные значения, анализ граничных значений: Это дополнение к предыдущей технике. Статистика говорит, что ошибки чаще всего возникают на границах допустимых диапазонов. Поэтому мы тестируем не просто любое значение из класса, а именно границы.

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

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

Анализ граничных значений может применяться на всех уровнях тестирования. Он относительно легок в применении и эффективен при поиске дефектов. Для выделения границ крайне полезны подробные спецификации.

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

Это техника проверки ошибок на границах классов эквивалентности. Если техника анализа классов эквивалентности ориентирована на тестовое покрытие, то эта техника основана на рисках. Ее основная идея в том, что программа может сработать некорректно в области граничных значений.

Считается, что с граничными значениями связаны серьезные

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

Указанная техника на первый взгляд проста. Но её эффективное применение зависит от способности правильно выделить классы эквивалентности и затем выбрать тесты для проверки границ этих классов. Цель техники сформулировать несложно: найти ошибки, свя- занные с граничными значениями [12].

Примерный алгоритм использования техники анализа граничных значений состоит из четырёх основных шагов:

1.         Необходимо выделить классы эквивалентности. От правильности разбиения на классы эквивалентности зависит эффективность тестов граничных значений.

2.         Далее нужно определить граничные значения этих классов.

3.         Затем следует понять, к какому классу будет относиться каждая граница.

4.         Наконец, для каждой границы нужно провести тесты по про верке значения до границы, на границе и сразу после границы.

Можно сказать, что количество тестов для проверки граничных значений будет равно количеству границ, умноженному на 3. Причем в литературе по тестированию рекомендуется проверять значения вплотную к границе. Скажем, если есть диапазон целых значений, а граница находится в числе 10, то необходимо проводить тесты с числом 9 (вплотную до границы), 10 (на границе) и 11 (сразу после границы).

Пример. Вернемся к примеру с бронированием и проведем тестирование граничных значений (рис. 4).

Рис. 4. Анализ граничных значений

Выделим классы эквивалентности:

· время до вылета > 5 сут;

· 24 ч ≤ время до вылета ≤ 5 сут;

· 0 ч < время до вылета < 24 ч;

· время до вылета ≤ 0 ч (вылет уже состоялся).

Определим границы:

· 5 сут;

· 24 ч;

· 0 ч.

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

· 5 сут – ко 2-му классу;

· 24 ч – ко 2-му классу;

· 0 ч – к 4-му классу.

Протестируем значения на границах, до и после них:

· отменим бронь за 5 сут + 1 с до вылета (или просто постара- емся выполнить бронь как можно ближе к границе, но слева от нее) и проверим, что комиссия равна 0 %;

· отменим бронь ровно за 5 сут до вылета и проверим, что  комиссия равна 50 %;

· отменим бронь за 5 сут ‒ 1 с до вылета и проверим, что  комиссия равна 50 %;

· отменим бронь за 24 ч + 1 с до вылета и проверим, что комиссия равна 50 %;

· отменим бронь ровно за 24 ч до вылета и проверим, что  комиссия равна 50 %;

· отменим бронь за 24 ч ‒ 1 с до вылета и проверим, что комиссия равна 75 %;

· отменим бронь за 1 с до вылета и проверим, что комиссия равна 75 %;

· отменим бронь ровно во время вылета и проверим, что комиссия равна 100 %;

· отменим бронь спустя 1 с после вылета и проверим, что  комиссия равна 100 %.

Таким образом, имеется 9 тестов, по 3 теста на каждую границу. Если суммировать тесты, необходимые для проверки классов эквивалентности и граничных значений, получим: 4 + 9 = 13 тестов.

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

· техника анализа классов эквивалентности говорит о том, что мы должны выбрать минимум по одному значению из каждого класса;

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

Преимущество техники анализа граничных значений в том, что она добавляет в технику анализа классов эквивалентности ориентированность на конкретный тип ошибок. Техника анализа классов эквивалентности просто говорит нам о том, что нужно разбить все тесты на классы и провести тестирование всех классов. А техника граничных значений ориентирована на обнаружение конкретной проблемы – возникновения ошибок на границах классов эквивалентности.

Но, как и для техники анализа классов эквивалентности, эффективность техники анализа граничных значений зависит от правильности ее использования. Необходимо приложить усилия, чтобы правильно определить классы эквивалентности и их границы. Если отнестись к этому поверхностно, то есть риск пропустить ошибки [12].

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

Цель тестирования по этой методике  – повысить общее тестовое покрытие, не упуская все (возможные) комбинации.

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

4.4  Таблицы альтернатив и комбинированные техники

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

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

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

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

Создается достаточное количество тестовых сценариев ‒ такое, чтобы каждая комбинация условий была покрыта как минимум одним тестовым сценарием.

При использовании таблицы альтернатив критерий покрытия сводится к простому для запоминания правилу – не менее одного теста для каждого столбца в таблице.

Итак, какие же типы дефектов находят с помощью таблиц альтернатив? Их два. Первый, когда при определенной комбинации условий может произойти неверное событие. Иными словами, когда существует некое действие, которое система не должна выполнять при такой комбинации условий, но выполняет. Второй тип дефектов ‒ когда при определенной комбинации условий система может не выполнить корректное действие. Иными словами, когда существует некое действие, которое система должна выполнить при такой комбинации условий, но не выполняет.

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

Существует целый набор условий, определяющий процесс обработки:

· Принадлежит ли введенная кредитная карта указанному лицу, и верна ли остальная информация?

· Действует ли карта или истек срок действия?

· Находится ли лицо в пределах лимита по карте или вне его?

· Проходит ли транзакция из обычного места или подозрительного?

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

· Нужно ли подтвердить транзакцию?

· Нужно ли связаться с держателем карты (например, чтобы предупредить его о покупке из подозрительного места)?

· Нужно ли связаться с эмитентом (например, чтобы попросить его конфисковать карту с истекшим сроком)?

Как работает таблица. Условия перечислены в левой верхней части таблицы, а действия ‒ в левой нижней. Остальные столбцы содержат бизнес-правила. Каждое правило утверждает (вкратце): «В этой конкретной комбинации условий необходимо выполнить конкретную комбинацию действий».

Количество столбцов, т. е. количество бизнес-правил, равняется 2 в степени числа условий: 2⁴ = 16. Когда условие строго булево (истина или ложь) и мы имеем дело с полной таблицей альтернатив (а не свернутой), то это всегда верно.

Как заполняются условия. Первое условие изменяется медленнее всего. Половина колонок ‒ Истина, половина – Ложь. Второе сверху условие изменяется более быстро, но медленнее, чем все остальные условия. Правило заполнения: четверть ‒ Истина, четверть ‒ Ложь, четверть ‒ Истина, четверть ‒ Ложь. И наконец, четвертое условие – чередование Истина, Ложь, Истина, Ложь и т. д.

Такой шаблон заполнения позволяет гарантировать, что ничего не будет пропущено.

Получение тестовых сценариев в этом примере простое: каждый столбец соответствует тестовому сценарию. Когда дело дойдет до выполнения тестов, будут созданы условия, которые явля- ются входными данными для тестов. Условия «Истина/Ложь» будут заменены на реальные входные значения для номера кредитной карты, секретного кода, даты истечения срока действия и имени держателя карты во время проектирования тестов или, возможно, даже во время выполнения тестов. Будут проверены действия, которые являются ожидаемыми результатами для тестов.

В некоторых случаях возникает необходимость создать более одного теста для каждого столбца. Эта возможность будет рассмотрена более детально ниже: методики эквивалентного разбиения и анализа граничных значений будут применены для расширения таблицы альтернатив.

Сворачивание таблицы альтернатив. В приведенном случае некоторые тестовые сценарии не имеют особого смысла. Например, как счет может быть нереальным, но при этом активным? Как счет может быть нереальным, но при этом в рамках лимита? Такая ситуация – подсказка, что возможно в таблице альтернатив не нужны все столбцы.

В некоторых случаях можно свернуть таблицу альтернатив, объединив некоторые столбцы, добившись ее лаконичности (иногда ощутимой). В любой ситуации, когда значение одного или нескольких конкретных условий не может повлиять на действия для двух или более комбинаций условий, можно свернуть таблицу альтернатив. Это подразумевает объединение двух или более столбцов, в которых одно или более условие не имеет возможности повлиять на действия. Столбцы, которые можно объединить, обычно, но не всегда, находятся рядом. По крайней мере, можно начать с рассмотрения соседних столбцов [12].

Для объединения двух и более столбцов нужно рассмотреть два или более столбца, которые приводят к одинаковому набору действий. Необходимо помнить, что действия должны быть одинаковыми для всех действий в таблице, а не просто некоторых. В этих столбцах некоторые условия будут одинаковыми, а другие отличными. Те, которые различаются, очевидно, не влияют на результат. Поэтому можно заменить условия, которые различаются в этих столбцах, прочерком («‒»). Прочерк обычно означает: не важно, не имеет значения или этого не может произойти при заданных условиях.

Теперь нужно повторить этот процесс для всех следующих столбцов, которые содержат такие же комбинации действий для всех действий в таблице.

Еще один важный пункт: нужно быть предельно внимательным, когда имеются таблицы, где в каждый момент времени может применяться более чем одно правило. Такие таблицы имеют неразделимые правила. Они будут рассмотрены ниже.

Табл. 7 отражает ту же самую таблицу альтернатив, что и табл. 6, только свернутую для того, чтобы выявить ненужные столбцы. Наиболее заметно, что столбцы с 9 по 16 в исходной таблице альтер- натив были свернуты в один столбец.

Исходная нумерация столбцов сохранена для простоты сравнения. Нельзя свернуть столбцы 2 и 3, потому что это приведет к про- черку для условий «В пределах лимита» и «Расположение оk». Если проанализировать табл. 6 или табл. 7, то можно заметить, что одно из этих условий должно быть не Истина, чтобы связались с держателем карты. Сворачивание правила 4 в правило 3 говорит, что если карта превысила лимит, то с держателем свяжутся независимо от распол жения. Такая же логика применятся при сворачивании правила 8 в правило 7.

Формат таблицы при сворачивании не изменяется. Условия пе- речислены в левой верхней части таблицы, а действия ‒ в левой нижней. Остальные столбцы содержат бизнес-правила. Каждое правило утверждает: «В этой конкретной комбинации условий (отображенных в верхней части правила, некоторые из которых не учитываются), нужно выполнить конкретную комбинацию действий (отображенную в нижней части правила, каждое из которых полностью определено)».

 Количество столбцов ‒ не более двух, возведенное в степень числа условий. Это важно, поскольку иначе свертывание нельзя было бы провести. При сворачивании таблицы удобный шаблон заполнения столбца «Истина/Ложь», присутствующий в полной таблице, ичезает. Это еще одна причина быть очень внимательным при сворачивании таблицы, потому что нельзя полагаться на шаблон или математическую формулу для проверки работы.

Неразделимые правила в таблицах альтернатив.

Иногда более чем одно правило может быть применено к транзакции. В табл. 8 показан расчет комиссий по кредитной карте. Есть три условия, при этом 1, 2, 3 или все три условия могут выполниться в одном месяце. Как эта ситуация влияет на тестирование? Это немного осложняет тестиро- вание, но можно использовать методический подход и тестирование на основе рисков для того, чтобы избежать значительных затрат.

Сначала нужно проверить таблицу альтернатив как обычную таблицу по каждому правилу и удостовериться в том, что условия, которые не относятся к этому правилу, не тестируются. Это позволяет тестировать правила отдельно – как это приходится делать в ситуациях с разделимыми правилами. Далее нужно оценить тестирование комбинаций правил. Именно «оценить», но не «протестировать все возможные комбинации правил». Это поможет избежать не перебираемого числа комбинаций, что происходит, когда тестировщики начинают тестировать комбинации условий без оценки таких тестов.

Теперь в этом случае есть только 8 комбинаций – 3 условия; 2 варианта значений для каждого условия, 2 в третьей степени равняется 8. Однако если имеется 6 условий по 5 вариантов значений для каждого, то комбинаций будет 15 625.

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

Рассмотрим возможность разработки более чем одного тестового сценария для столбца таблицы альтернатив с помощью комбинирования эквивалентного разбиения и методики таблиц альтернатив. Вернемся к табл. 7, а конкретно к столбцу 9. Можно применить эквивалентное разбиение (ЭР) к вопросу «Как много интересующих – с точки зрения тестирования – случаев, когда счет не является действительным?». Как видно из рис. 5, это возможно в следующих потенциально интересных случаях:

· несоответствие номера карты и держателя;

· несоответствие номера карты и даты истечения срока;

· несоответствие номера карты и секретного кода;

· два из перечисленных несоответствия (три варианта);

· все три несоответствия.

Рис. 5. Эквивалентное разбиение и таблицы альтернатив

Таким образом, для столбца 9 (см. табл. 7) может быть семь тестов.

Можно ли применить анализ граничных значений? Да, можно применить его к таблицам альтернатив, чтобы найти новые и интересные тесты.

Например, «Как много интересующих тестовых значений относится к кредитному лимиту?».

Как видно из рис. 6, эквивалентное разбиение (ЭР) и анализ граничных значений (АГЗ) дают шесть случаев:

· счет начинается с нулевого баланса;

· баланс будет находиться в пределах нормы после транзакции;

· баланс будет точно на границе лимита после транзакции;

· баланс будет точно за границей лимита после транзакции;

· баланс был точно на границе лимита до транзакции (что точно приведет к его превышению, если транзакция завершится);

· баланс будет на максимальном значении овердрафта после транзакции (что может быть недопустимо).

Комбинируя указанные методики ЭР и АГЗ с таблицей альтернатив, видим, что тестов на проверку условия «Сверх лимита» будет больше, чем столбцов – на один. Иными словами, будет четыре теста на проверку «В пределах лимита» и три теста на проверку «Сверх лимита». Это верно до тех пор, пока не потребуется убедиться, что каждый класс эквивалентности «В пределах лимита» представлен в подтвержденной транзакции. В этом случае столбец 1 будет представлен не одним тестом, а тремя [12].

5.5. Диаграммы причинно-следственных связей

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

Процесс создания диаграммы причинно-следственных связей из таблицы альтернатив или наоборот достаточно прост. Для создания диаграммы из таблицы сначала нужно выписать все условия слева. Затем справа перечислить все действия. Теперь для каждого действия нужно определить, какие комбинации условий приводят к действию. Одно или несколько условий связываются с действием, используя булевы операторы, которые показаны на рис. 7. За- тем необходимо повторить этот процесс для всех действий в таблице альтернатив.

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

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

Если нужно построить таблицу альтернатив по диаграмме причинно-следственных связей, сначала нужно перечислить все условия в левой верхней части «чистой» таблицы. Затем перечислить все действия в левой нижней части таблицы, под условиями.

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

На рис. 7 показана диаграмма причинно-следственных связей, соответствующая приведенной таблице альтернатив (см. табл. 6 ‒ 7). Может возникнуть вопрос: «Какой именно, полной или свернутой?». Ответ ‒ обеим. Полная и свернутая таблицы логически эквивалентны, если только при сворачивании не было допущено ошибки.

На рис. 7 показана легенда, указывающая, как читать операции:

a.        Простая причинно-следственная связь: если А ‒ истина, то произойдет B, или, другими словами, А ведет к B.

b.       Отрицание: если А ‒ не истина, то произойдет B, или, другими словами, не А ведет к B.

c.        Операция ИЛИ: если А1 или А2 ‒ истина, то произойдет B, или, другими словами, А1 или А2 ведет к B.

d.       Операция И: если А1 и А2 одновременно истина, то произойдет B, или, другими словами, А1 и А2 ведут к B.

Рассмотрим связи между условиями и действиями. Сплошные линии с оператором И показывают, что все четыре условия должны быть удовлетворены, чтобы транзакция была подтверждена. Пунктирные линии с отрицанием и оператором ИЛИ показывают, что если счет недействительный или счет не активный, нужно связаться с эмитентом.

Штрихпунктирные линии имеют более сложную интерпретацию. Для начала скомбинированы условия «Внутри лимита» и

«Расположение оk» с помощью операторов отрицания и ИЛИ для того, чтобы создать промежуточное условие «Лимит или расположение неверны». Затем это условие комбинируется с условием «Действительный счет», чтобы сказать, что если лимит превышен или имеет место ситуация с подозрительным расположением, но счет действительный, то нужно связаться с держателем карты [12].

4.6  Тестирование на основе состояний и диаграммы переходов состояний 

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

В основе такой методики лежит диаграмма или таблица переходов состояний. Диаграмма или таблица связывает начальные состояния, события и условия с конечными состояниями и действиями. Диаграмма состояний по существу является графом специального вида, который представляет некоторый автомат. Иными словами, существует некий статус-кво, и система находится в текущем состоянии. Затем происходит некоторое событие, которое система должна обработать. На обработку этого события может влиять одно или более условий. Комбинация событий и условий вызывает сраба-ывание перехода: или из текущего состояния в новое, или из текущего снова в текущее состояние. В случае перехода система предпринимает одно или более действий.

Имея такую модель, можно генерировать тесты, которые проходят по состояниям и переходам. Входные данные вызывают события и создают условия, в то время как ожидаемыми результатами теста являются новые состояния и действия, предпринимаемые системой.

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

Еще один потенциально более жесткий критерий покрытия требует, чтобы каждая последовательность переходов длины N и меньше была покрыта как минимум одним тестом. N может быть равно 1, 2, 3, 4 и больше. Это называется «Покрытием переходов Чау» («Chow’s switch coverage»), по имени профессора Чау, разработавшего методику, или «Покрытием N-1 переходов» ‒ по достигнутому уровню покрытия. Если покрыть все переходы единичной длины, тогда «Покрытие N-1 переходов» означает «Покры- тие 0 переходов». Следует заметить, что это тоже нижний уровень покрытия, который рассматривался выше. Если покрыть все переходы длины 1 и 2, тогда «Покрытие N-1 переходов» означает «По- крытие 1-го перехода». Это, естественно, более высокий уровень покрытия по сравнению с нижним [2].

Но «Покрытие 1-го перехода» необязательно выше уровнем, чем покрытие каждой строки, потому что таблица переходов ведет к тестированию комбинаций событий/условий, чего не происходит в диаграмме переходов состояний. Так называемые «переходы» в

«Покрытии N-1 переходов» получаются из диаграммы переходов, а не таблицы.

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

Согласно глоссарию ISTQB, тестирование переходов состояний (state transition testing) – это разработка тестов методом черного ящика, в котором сценарии тестирования строятся на ос нове выполнения корректных и некорректных переходов состояний [2].

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

Рис. 8. Пример диаграммы переходов состояний

Слева на рис. 8 изображен небольшой элемент в виде кружка и стрелки ‒ «Начальное состояние». Такая нотация показывает, что с точки зрения клиента транзакция начинается с просмотра веб-сайта. Можно переходить по ссылкам и просматривать каталог товаров, оставаясь в состоянии просмотра. Стрелка в виде петли над состоянием просмотра отражает как раз такой процесс. Узлы в виде прямоугольников со скругленными углами представляют состояния. Стрелки отражают переходы.

В состояние «Выбор» можно войти путем добавления товара в корзину. «Добавить в корзину» ‒ событие. Затем система отображает «Диалог выбора», в котором спрашивает пользователя о количестве товаров, которое он хочет приобрести, а также о любой другой информации, которая необходима для добавления товара в корзину. Как только это сделано, пользователь может сообщить системе, что он хочет продолжить покупку. В этом случае система снова отображает домашнюю страницу, и пользователь возвращается в состояние просмотра. С точки зрения нотации следует заметить, что действия, выполняемые системой, записаны после символа наклонной черты на стрелке перехода.

Существует альтернатива: покупатель может выбрать оформление покупки. В этом случае он входит в состояние авторизации. Он вводит регистрационную информацию. К этой информации приме- нимо условие: верна ли регистрационная информация. Если неверна, то система отображает ошибку, и пользователь остается в состоянии авторизации. Если верна, то система отображает первую страницу в диалоге оплаты. Заметим, что «Верный» и «Неверный», отображенные в квадратных скобках, с точки зрения нотации обозначают условия.

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

Часто при разборе тестирования на основе состояний возникает вопрос: «Как различить состояние, событие и действие?» Основные отличия, следующие:

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

· событие происходит либо сразу, либо в ограниченный, конечный период времени. Это что-то, что наступает, происходит вне, – и вызывает переход;

· действие – это ответ системы во время перехода. Действие, как и событие, либо мгновенно, либо требует ограниченного, конечного времени.

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

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

 Тестирование на основе состояний использует формальную модель, поэтому имеется формальная процедура для получения тестов из модели. Приведенный ниже список показывает процедуру, которую можно использовать для получения тестов, позволяющих достигнуть покрытия состояний/переходов (т. е. «покрытие 0 пере- ходов»).

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

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

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

4.         Повторять шаги 2 и 3 до тех пор, пока не пройдены все состояния и все переходы. Иными словами, пока каждое состояние и переход не будут помечены карандашом или маркером.

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

Рассмотрим этот процесс на примере проанализированного ранее приложения электронной коммерции. На рис. 9 пунктирными линиями показаны покрытые состояния и переходы.

Рис. 9. Проверка покрытия 1

На рис. 9 нужно отметить две вещи: 1) правило, которое гласит, что тест должен начинаться в начальном состоянии и заканчиваться в конечном; 2) какие шаги включены в тест: («Про- смотр», «Пройти по ссылке», «Отобразить», «Добавить в корзину», «Диалог выбора», «Продолжить», «Отобразить», «Добавить в корзину», «Диалог выбора», «Посчитать», «Диалог авторизации», «Вход [Неверный]», «Ошибка», «Вход [Верный]», «Диалог оплаты», «Оплата [Неверно]», «Ошибка», «Оплата [Успешно]», «Подтверждение», «Продолжить покупку», «Отобразить», «Отмена», «Выход»).

Теперь проверим полноту покрытия, которое отслеживается на диаграмме переходов состояний. Как видно, покрыты все состояния и большинство переходов, но не все. Необходимо создать еще несколько тестов.

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

1)        («Просмотр», «Пройти по ссылке», «Отобразить», «Добавить в корзину», «Диалог выбора», «Продолжить», «Отобразить», «Добавить в корзину», «Диалог выбора», «Посчитать», «Диалог авторизации», «Вход [Неверный]», «Ошибка», «Вход [Верный]», «Диалог оплаты»,  «Оплата  [Неверно]»,  «Ошибка»,  «Оплата  [Успешно]»,

«Подтверждение», «Продолжить покупку», «Отобразить», «Отмена»,

«Выход»);

2)        («Просмотр», «Добавить в корзину», «Диалог выбора», «От- мена», «Выход»);

3)        («Просмотр», «Добавить в корзину», «Диалог выбора», «По- считать», «Диалог авторизации», «Отмена», «Выход»);

4)        («Просмотр», «Добавить в корзину», «Диалог выбора», «По- считать», «Диалог авторизации», «Вход [Верный]», «Диалог оплаты»,

«Отмена», «Выход»);

5)        («Просмотр», «Добавить в корзину», «Диалог выбора», «Продолжить», «Отобразить», «Добавить в корзину», «Диалог выбора», «По- считать», «Диалог авторизации», «Вход [Верный]», «Диалог оплаты»,

«Оплата [Успешно]», «Подтверждение», «Уйти на другой сайт»).

Рис. 10. Завершающая проверка покрытия

Рис. 10 отражает проверку покрытия состояний и переходов. Процесс нельзя считать завершенным до тех пор, пока каждое состояние и каждый переход не помечены, как сделано на этом рисунке.

Суперсостояния и подсостояния. В некоторых случаях полезно преобразовать отдельное состояние в суперсостояние, состоящее из двух или более подсостояний. На рис. 11 отражено, что состояние оплаты из примера расширено тремя подсостояниями.

Рис. 11. Суперсостояния и подсостояния

Правило базового покрытия здесь простое: покрыть все переходы в суперсостояние, все переходы из суперсостояния, все подсостояния и все переходы внутри суперсостояния.

Заметим, что для нашего примера это увеличит число тестов, поскольку теперь имеется три перехода «Отмена» из состояния

«Оплата» в состояние «Выход» вместо одного. Это также увеличит количество элементов в тестах, т. е. станет больше событий и действий, за счет того, что нужно убедиться, что протестированы как минимум три различных типа сущностей неверной оплаты [12].

4.7 Таблицы переходов состояний

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

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

Рис. 12. Диаграмма переходов состояний для приложения электронной коммерции

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

· текущее состояние;

· событие/условие;

· действие;

· новое состояние.

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

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

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

Здесь имеются 6 состояний:

·  просмотр;

·  выбор;

·  авторизация;

·  оплата;

·  подтверждение;

·  выход.

Также имеются 11 условий/событий:

·  пройти по ссылке;

·  добавить в корзину;

·  продолжить;

·  выписать;

·  вход [Неверный];

·  вход [Верный];

·  оплата [Успешно];

·  оплата [Неверно];

·  отмена;

·  продолжить покупку;

·  уйти на другой сайт.

Указанное выше количество условий и состояний означает, что полная таблица переходов состояний будет иметь 66 строк – по одной строке для каждой пары «состояние ‒ событие/условие» [2].

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

Следует заметить, что мы строим уже существующий набор тестов, созданный на основе диаграммы переходов состояний, для достижения покрытия состояний/переходов или «покрытия 0 переходов».

1.         Начнем с набора тестов (включая правила начального и конечного состояния), полученных из диаграммы переходов состояний, дающей покрытие состояний/переходов.

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

3.         Выберем тесты, покрывающие состояние, для которого в таблице существует одна или более «неопределенных» строк. Изменим тесты и попытаемся создать комбинацию событий/условий для «не- определенной» строки. Заметим, что действие в этом случае не определено.

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

5.         Повторяем шаги 3 и 4, пока все строки не будут покрыты. Такая процедура создает логические тестовые сценарии. Для наглядности рассмотрим пример.

Существующий                тест:      («Просмотр»,         «Добавить        в    корзину»,

«Диалог выбора», «Выписать», «Диалог авторизации», «Вход [Верный]», «Диалог оплаты», «Отмена», «Выход»).

Измененные тесты:

· («Просмотр», попытка: «Продолжить», неопределенное действие, «Добавить в корзину», «Диалог выбора», «Выписать», «Диалог авторизации», «Вход [Верный]», «Диалог оплаты», «Отмена», «Вы- ход»);

· («Просмотр», попытка: «Выписать», неопределенное действие, «Добавить в корзину», «Диалог выбора», «Выписать», «Диалог авторизации», «Вход [Верный]», «Диалог оплаты», «Отмена», «Выход»);

· можно создать еще шесть измененных тестов, но приводить их здесь не будем.

Не пытайтесь покрыть «неопределенные» комбинации событий/условий более чем для одного состояния в любом тесте, поскольку вы наверняка не знаете, останется ли система пригодной для тестирования после этого!

В лучшем случае «неопределенная» комбинация событий/условий останется проигнорированной или будет получен отказ с осмысленным сообщением об ошибке, а после этого процесс продолжится в нормальном режиме. 

Это пример получения тестов на основании таблицы, построенной для примера с приложением электронной коммерции. Как можно заметить, в самом начале был выбран тест из набора полученных ранее тестов: («Просмотр», «Добавить в корзину», «Диалог выбора»,

«Выписать», «Диалог авторизации», «Вход [Верный]», «Диалог оплата », «Отмена», «Выход»).

Затем мы начали создавать измененные тесты для покрытия только «неопределенных» событий/условий в состоянии «Просмотр». Кроме того, в этом примере не показано еще шесть измененных тестов. Как видно, создание таких тестов – механический процесс. Если вы аккуратны при отслеживании покрытых строк, например с использованием маркера, то почти невозможно пропустить тест.

Также можно заметить, что в каждый тест включена только одна «неопределенная» комбинация событий/условий. Почему? Это разновидность правила эквивалентного разбиения, согласно которому нельзя создавать «некорректные» тестовые сценарии, которые включают более одного «некорректного» тестового данного. В нашем случае каждая строка представляет собой «некорректные» тестовые данные. Если попытаться покрыть две строки одним тестом, то мы не можем быть уверены, что система останется пригодной для тестирования после первого «некорректного» тестового данного.

Мы пометили действие как «неопределенное». Какое поведение системы в этих условиях можно считать идеальным? Лучше, если «неопределенные» события/условия будут проигнорированы или – еще лучше – отклонены с осмысленным сообщением об ошибке. После этого система должна функционировать нормально. При отсутствии какого-либо решения бизнес-аналитика, проектировщиков системы или другого влиятельного специалиста, а также спецификации требований мы вправе принять позицию, когда любой иной исход считается дефектом, включая непонятные сообщения об ошибках наподобие «То, что только что произошло, ‒ не могло произойти» [12].

Покрытие переходов. Рассмотрим концепцию покрытия пер ходов на примере все того же приложения электронной коммерции. На рис. 14 изображена последовательность переходов, которая получена с помощью покрытия переходов. Диаграмма схожа с рис. 15 стой лишь разницей, что на ней имена состояния заменены на буквы, а имена переходов – на цифры. Теперь пара «состояние ‒ переход» может быть определена буквой и цифрой.

Рис. 14. Диаграмма состояний и переходов для приложения электронной коммерции с заменами имён состояний на буквы, а имён переходов – на цифры

Рис. 15. Диаграмма состояний и переходов для приложения электронной коммерции

Не будем перечислять все комбинации в таблице, представленной на рис. 16, поскольку исходя из диаграммы понятно, какое состояние следует после определенного перехода. Существует только одна стрелка с указанным номером, которая ведет из состояния с указанной буквой, и эта стрелка ведет точно в одно состояние [12].

Рис. 16. Таблица покрытия переходов

4.8 Попарное тестирование: это одна из техник тест-дизайна, основанная на комбинаторике и разделению входных параметров «по парам» (почему и называется pairwise testing).

Проводится комбинирование вариантов и подбор нужных, то есть оцениваются все возможные комбинации (сочетания) входных переменных, и из них выбираются только нужные (значимые). Техника основана на том, что 99,9…% дефектов возникают при взаимодействии не более двух факторов одновременно.

5. ОТЧЕТНАЯ ДОКУМЕНТАЦИЯ

5.1 Баг-репорт (Bug Report / Defect Report)

Баг-репорт  – это документ, фиксирующий найденные дефекты в программном обеспечении.

Краткая версия должна содержать:

·            Заголовок: Краткое и понятное описание проблемы. «Что? Где? При каких условиях?». Плохо: «Программа падает». Хорошо: «При попытке сохранить заказ с пустым полем "Email" приложение выдает исключение и падает на странице Checkout».

·            Серьёзность бага и приоритет исправления: Уровень влияния дефекта на продукт и приоритетность его устранения.

·            Шаги для воспроизведения: Подробное описание действий, которые необходимо выполнить, чтобы воспроизвести проблему.

·            Окружение: при каких условиях среды обнаружен баг: тип и версия операционной системы, браузера, разрешение экрана и другие параметры, важные для воспроизведения дефекта. Также указывается версия приложения.

·            Ожидаемый результат: то, что должно было произойти при правильной работе приложения.

·            Фактический результат: то, что произошло на самом деле.

·            Статус: на какой стадии решения находится баг: открыт, в работе, исправлен или завершён.

·            Вложения и дополнения: Вспомогательные материалы, которые объясняют механику возникновения бага: скриншоты, видеозапись экрана, ссылки и логи.

·            Автор: Тестировщик, составивший баг-репорт.

·            Исполнитель: Разработчик, устраняющий дефект.

Также отчет об ошибке может включать в себя следующие разделы:

• программа или модуль (указывается при наличии нескольких компонент ПО (например, серверная или клиентская части) или реализаций ПО под несколько платформ);

• версия программы или модуля;

• тип отчета (может включать в себя ошибку или запрос на до- бавление новой функциональности);

• важность отчета (варианты значения: критический, высокий, средний, низкий);

• описание;

• повторяемость;

• последовательность шагов для воспроизведения ошибки;

• предлагаемое исправление;

• автор отчета;

• ответственный за исправление;

• комментарии пользователей ПО;

• текущее состояние отчета (варианты значения: открытый, за- крытый);

• приоритет отчета (отмечается руководителем разработки ПО в отличие от важности, которую указывает автор отчета);

• срок выполнения работ (указывается руководителем разработ- ки ПО).

Составление подробных отчетов и сбор полной информации об ошибках является очень важным элементом тестирования.

Хорошо составленный баг-репорт помогает разработчикам быстро понять суть проблемы и принять меры для ее устранения.

Анализ воспроизводимости

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

• максимально подробно записать последовательность действий, приводящих к ошибке;

• выявить наиболее серьезные проблемы (повысить важность);

• найти кратчайший путь воспроизведения (облегчить отладку);

• найти альтернативные действия, приводящие к этому результа- ту;

• выявить связанные проблемы;

• проверить более ранние версии (поиск модификаций в коде);

• проверить на нескольких конфигурациях.

5.2 . Отчет по тестированию

Отчет по тестированию подводит итоги проведенного тестирования и включает в себя:

·            Информация о выполненных тестах: Список тестов, которые были проведены, и их результаты.

·            Полученные результаты: Описание результатов тестирования, включая выявленные дефекты и их статус.

·            Рекомендации по улучшению качества продукта: Предложения по устранению выявленных проблем и улучшению функциональности.

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

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

Как это все работает

Эффективная работа с тестовой документацией требует понимания ее роли и взаимосвязей между элементами на разных стадиях разработки.

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

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

Составляется тест-план. Он содержит конкретную информацию о том, что, как, кем и в какие сроки будет протестировано на конкретном этапе (это может быть релиз, спринт, тест-план для конкретного модуля продукта и т.д.). Является «живым» документом, который постоянно претерпевает изменения.

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

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

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

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

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

Как определить, какую документацию внедрить на проект

Определение тестовой документации для проекта  – это важный шаг, который зависит от нескольких факторов. Вот краткое руководство:

·            Тип проекта: Учитывайте, является ли проект веб-приложением, мобильным приложением или десктопным. Коммерческие проекты могут требовать более строгой документации.

·            Методология разработки: Выбор методологии (Agile, Waterfall, DevOps) влияет на подход к тестированию и документации. Agile, например, предполагает более гибкие документы.

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

·            Команда и ресурсы: Учитывайте опыт команды и доступные инструменты для управления тестированием, что может упростить создание документации.

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

Советы по составлению документации для тестирования

·            Четкая структура и форматирование: Используйте единообразный и логичный формат для всех документов. Разделите информацию на четкие разделы (введение, цели, объем, тест-кейсы, результаты и т.д.), чтобы облегчить навигацию и понимание. Используйте заголовки, подзаголовки и списки для улучшения читаемости.

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

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

·            Учет требований и стандартов: Включайте в документацию ссылки на требования и спецификации, с которыми связаны тесты. Это поможет обеспечить полное покрытие требований и упростит отслеживание соответствия между тестами и функциональностью.

·            Использование инструментов для совместной работы: Рассмотрите возможность использования специализированных инструментов для управления тестированием и совместной работы (например, TestRail, JIRA, Confluence и др.). Это упростит процесс совместного редактирования, обмена информацией и отслеживания изменений, а также повысит прозрачность и доступность документации для всей команды.

6. Системы хранения тестовой документации (TMS)

Хранить тест-кейсы в Word или Excel на общей папке  – это путь к хаосу (проблемы с версиями, одновременным редактированием, поиском). Для этого существуют Системы управления тестированием (TMS  – Test Management System).

Система управления тестированием (TMS)  – это специализированное программное обеспечение, предназначенное для планирования, организации и контроля процессов тестирования в разработке программного обеспечения.

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

 Это способствует улучшению качества программного обеспечения, повышению прозрачности процессов и обеспечению полного покрытия требований.

Самые популярные системы управления тестированием:

·            JIRA + Zephyr: JIRA  – это известная система управления проектами, а Zephyr  – это плагин, который интегрирует управление тестированием в JIRA, позволяя пользователям создавать тест-кейсы, планировать тестирование и отслеживать результаты прямо в интерфейсе JIRA.

·            TestRail: Это мощная и интуитивно понятная система для управления тестированием, которая предлагает удобный интерфейс для создания и управления тест-кейсами, выполнения тестов и генерации подробных отчетов о результатах тестирования.

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

·            Xray: Плагин для JIRA, который позволяет управлять тестами, связывать их с требованиями и отслеживать статус выполнения, обеспечивая полное покрытие тестами и удобную отчетность.

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

КОНТРОЛЬНЫЕ ВОПРОСЫ

Раздел 1: Общие понятия и важность тестовой документации

1.             Что такое тестовая документация и какую роль она играет в процессе разработки ПО?

2.             Назовите три основные причины, подчеркивающие важность тестовой документации.

3.             Как тестовая документация способствует обеспечению качества продукта?

4.             Каким образом документация помогает в стандартизации процессов тестирования?

5.             Как тестовая документация упрощает передачу знаний в команде?

6.             Как документация помогает отслеживать изменения в требованиях?

7.             Почему тестовая документация важна для обеспечения соответствия регуляторным требованиям?

8.             Как документация поддерживает автоматизацию тестирования?

Раздел 2: Виды тестовой документации
9. Перечислите основные виды тестовой документации.
10. Что такое мастер-тест-план и какие элементы он включает?
11. Какие основные вопросы должен раскрывать тест-план?
12. В чем разница между тест-планом как «продуктом» и как «инструментом»?
13. Что такое матрица трассировки требований (RTM) и для чего она используется?
14. Назовите хотя бы три альтернативных названия для матрицы трассировки требований.
15. Какие три типа матрицы трассировки требований существуют и чем они отличаются?
16. Каковы преимущества использования матрицы трассировки требований?
17. Какие инструменты визуализации требований, кроме матрицы, вы знаете?

Раздел 3: Тест-кейсы
18. Дайте определение тест-кейса.
19. Чем отличается высокоуровневый тест-кейс от низкоуровневого?
20. Для каких целей лучше подходят высокоуровневые тест-кейсы?
21. В каких ситуациях необходимы низкоуровневые тест-кейсы?
22. Перечислите основные атрибуты (поля) тест-кейса.
23. Какую информацию содержит поле «Предусловие»?
24. Каковы правила написания шагов тест-кейса?
25. Почему в ожидаемых результатах всегда описывается корректная работа приложения?
26. Каков жизненный цикл тест-кейса? Назовите ключевые состояния.
27. Какие свойства характеризуют качественный тест-кейс?
28. Почему тест-кейс с излишней специфичностью считается плохим?
29. Каковы преимущества простых тест-кейсов?
30. Каковы преимущества сложных тест-кейсов?

Раздел 4: Тест-сценарии и Чек-листы
31. Что такое тест-сценарий и чем он отличается от тест-кейса?
32. Какую информацию обычно включает тестовый сценарий?
33. Что такое чек-лист и в каких случаях его уместно использовать?
34. Какими свойствами должен обладать полезный чек-лист?
35. В чем основное отличие чек-листа от тест-кейса по уровню формализации?

Раздел 5: Техники тест-дизайна
36. Что такое техники тест-дизайна и для чего они применяются?
37. Дайте определение метода эквивалентного разбиения.
38. Какой алгоритм используется при применении техники эквивалентного разбиения?
39. Что такое анализ граничных значений и почему он эффективен?
40. Как связаны между собой методы эквивалентного разбиения и анализа граничных значений?
41. Опишите алгоритм использования техники анализа граничных значений.
42. Что такое таблица принятия решений и какова цель её использования?
43. Что такое таблица альтернатив и как она помогает в тестировании бизнес-логики?
44. Как можно свернуть таблицу альтернатив и зачем это делается?
45. Что такое неразделимые правила в таблицах альтернатив?
46. Как диаграммы причинно-следственных связей связаны с таблицами альтернатив?
47. Что такое тестирование на основе состояний?
48. Что такое диаграмма переходов состояний и какие элементы она включает?
49. Как различить состояние, событие и действие в диаграмме переходов состояний?
50. Что такое «покрытие переходов Чау» (Chow's switch coverage)?
51. Что такое таблица переходов состояний и чем она полезна?
52. Что такое попарное тестирование (pairwise testing) и на какой принцип оно опирается?

Раздел 6: Баг-репорты
53. Что такое баг-репорт и какую информацию он должен содержать в краткой версии?
54. Какие разделы могут быть включены в подробный отчет об ошибке?
55. Что такое «анализ воспроизводимости» и какие пункты он включает?
56. Почему важно указывать окружение в баг-репорте?

Раздел 7: Отчет по тестированию и процессы
57. Какую информацию включает отчет по тестированию?
58. Опишите, как различные элементы тестовой документации взаимодействуют в процессе разработки.
59. Какой документ является первым шагом в процессе тестирования?
60. Как определяется, какую тестовую документацию нужно внедрить на проект?
61. Назовите факторы, влияющие на выбор тестовой документации для проекта.
62. Каковы советы по составлению четкой и эффективной тестовой документации?

Раздел 8: Системы управления тестированием (TMS)
63. Что такое TMS и какую роль она играет?
64. Перечислите три популярные системы управления тестированием.

Обобщающие и сравнительные вопросы
65. Сравните чек-лист, тест-кейс и тестовый сценарий по уровню детализации и цели использования.
66. В чем разница между прямой и обратной трассировкой требований?
67. Почему баланс между специфичностью и общностью важен при написании тест-кейсов?
68. Каковы типичные ошибки при написании шагов и ожидаемых результатов в тест-кейсах?
69. Как тестовая документация помогает в управлении рисками при запуске продукта?
70. Как процесс тестирования и сопровождающая его документация способствуют непрерывному улучшению качества продукта?

 Задание: провести сравнение Чек-листа, тест-кейса и тестового сценария

Задания:

Раздел 1: Документированность процесса (Важность документации)

1.         Кризис в проекте. Проект находится в состоянии хаоса: тестировщики пропускают критические сценарии, новые члены команды тратят недели на вникание в процесс, а заказчик недоволен качеством. Тест-менеджер предлагает сэкономить время и полностью отказаться от тестовой документации в пользу «гибкого» исследовательского тестирования. Используя текст лекции, приведите три аргумента, почему это предложение только усугубит ситуацию, а не спасет проект.

Раздел 2: Иерархия тестовой документации (Стратегия, Планы, RTM)

2.         Банковский проект. Ваша компания выиграла тендер на разработку мобильного банка. Заказчик требует предоставить документ, описывающий глобальные принципы обеспечения качества: какие уровни и типы тестирования обязательны, какой инструментарий будет использоваться, и как вы будете управлять рисками. О каком документе из лекции идет речь, и почему в данной ситуации важен именно он, а не детальный план на спринт?

3.         Смена приоритетов. В середине спринта выясняется, что дату релиза сдвинули на две недели раньше. Какой документ (Мастер-тест-план или Тест-план на спринт) и какой именно его раздел потребует немедленной корректировки? Какие последствия это будет иметь для команды?

4.         Пропущенная функция. На приемочном тестировании заказчик обнаружил, что функция «Автоплатеж по расписанию», подробно описанная в требованиях, не была протестирована. Тестировщики уверяют, что проверяли все сценарии оплаты. Какой артефакт тестовой документации (инструмент визуализации требований) отсутствовал или был составлен некачественно, что привело к такому пропуску? Кратко опишите, как он должен был сработать.

5.         Новый модуль. Вам поручили составить тест-план для новой функции в интернет-магазине  – «Калькулятор рассрочки». Какие три раздела из структуры Тест-плана (описанной в лекции) вы сочтете самыми важными на начальном этапе и почему?

Раздел 3: Детальная документация (Тест-кейсы, Сценарии, Чек-листы)

6.         Новый сотрудник. В команду пришел стажер. Ему нужно поручить регрессионное тестирование модуля оплаты, но вы опасаетесь, что без детальных инструкций он пропустит важные нюансы. Какой тип тест-кейсов (высокоуровневый или низкоуровневый) вы дадите ему для выполнения и почему? Опишите ситуацию, в которой тому же стажеру было бы полезнее выдать высокоуровневый тест-кейс.

7.         Случайная находка. Тестировщик выполняет тест-кейс «Проверка добавления товара в корзину». Все шаги выполнены успешно, товар добавился, но в этот момент «сломался» интерфейс  – исчезла кнопка «Оформить заказ». В какое состояние перевести исходный тест-кейс («Пройден успешно» или «Провален»)? Каковы дальнейшие действия тестировщика согласно правилам, описанным в лекции?

8.         Плохой тест-кейс. Коллега написал шаг в тест-кейсе: «Ввести некорректные данные и проверить, что система работает верно». Используя раздел лекции о свойствах качественных тест-кейсов (баланс специфичности и общности, правильный язык), объясните, в чем здесь главные ошибки, и перепишите этот шаг (и ожидаемый результат) правильно для поля ввода номера телефона.

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

10.     Заблокирован. При тестировании вы поняли, что не можете выполнить тест-кейс «Оплата заказа», так как баг на предыдущем шаге (невозможно добавить товар в корзину) блокирует дальнейшие действия. В какой статус вы переведете тест-кейс «Оплата заказа» согласно жизненному циклу, описанному в лекции, и что нужно сделать с багом, который вы обнаружили на шаге добавления в корзину?

Раздел 4: Техники тест-дизайна

11.     Поле ввода возраста. В приложении есть поле «Возраст», которое принимает целые числа от 18 до 65 включительно. Используя техники эквивалентного разбиения и анализа граничных значений, составьте оптимальный набор чисел для проверки этого поля. Поясните, почему вы выбрали именно эти значения, а не все подряд.

12.     Логика кредитного скоринга. Банковское приложение выдает кредит, если выполняется одно из двух условий: (1) Возраст клиента больше 30 лет И ежемесячный доход выше 1000$, ИЛИ (2) У клиента есть положительная кредитная история. Какая техника тест-дизайна из лекции лучше всего подойдет для проверки этой бизнес-логики и почему? Сколько минимально тестов потребуется, чтобы покрыть все правила?

13.     Сложный выбор. Объясните на примере всё того же поля «Возраст» (от 18 до 65) разницу между целью эквивалентного разбиения (сделать тестовое покрытие меньше, но эффективным) и целью анализа граничных значений (снизить риски, связанные с конкретным типом ошибок). Почему эти техники рекомендуется использовать вместе?

14.     Лифт. Представьте, что вы тестируете логику работы лифта. Лифт может быть на этажах (состояния: 1, 2, 3...). События: «Вызвать с 1-го этажа», «Нажать кнопку 5 внутри». Используя терминологию из раздела про диаграммы переходов состояний, объясните, чем в данном примере является «Нажатие кнопки 5», чем  – само нахождение на «5-м этаже», а чем  – «Открытие дверей».

Раздел 5: Отчетная документация (Баг-репорты)

15.     Не воспроизводится. Разработчик отвечает на ваш баг-репорт: «У меня все работает. Закрываю». Вы точно знаете, что баг существует, но проявляется только в браузере Firefox на ОС Linux. Обратившись к структуре баг-репорта в лекции, какой важнейший раздел вы, скорее всего, заполнили недостаточно подробно? Что конкретно вы в нем допишете?

16.     Путаница. Вы нашли баг: на главной странице не грузится логотип компании. Это очень заметная, но не фатальная проблема. Серьезность (Severity) бага  – «Major» (высокая). Однако завтра у заказчика важная презентация, и для него эта проблема критична. Какой атрибут баг-репорта (серьезность или приоритет) должен изменить тест-лид или менеджер, и в какую сторону, чтобы разработчик взял баг в работу немедленно?

Раздел 6: Системы хранения и выбор документации

17.     Стартап. Вы пришли работать тестировщиком в стартап из трех человек. Продукт только создается, требования меняются каждый день. Коллеги предлагают сразу завести сложную TMS (вроде TestRail) и писать детальные тест-кейсы на всё. Используя разделы лекции о выборе документации и чек-листах, предложите более легковесный и гибкий подход для текущей стадии проекта. Свой выбор обоснуйте.

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

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

20.     Итоговый вердикт. Цикл тестирования завершен. Разработчики исправили все критические баги. Вам нужно подготовить документ для руководства и заказчика, который обобщит результаты: сколько тестов пройдено, сколько багов найдено, какова оценка качества продукта и можно ли его выпускать. Какой артефакт тестовой документации вы подготовите, и какие разделы (хотя бы два) из лекции обязательно в него включите?

Скачано с www.znanio.ru