• Новости
• Блоги
• Аналитика
• Новости компаний
• В СНГ и в мире
• Анонсы

Тестируем вместе

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

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

Лучшие практики

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

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

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

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

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

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

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

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

Должны использоваться детальные предусловия для минимизации времени на выполнение тест-кейсов.

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

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

Не ошибиться с выбором инструментария

Для создания тестовых моделей можно использовать одну из известных тест-трекинговых систем, например, Microsoft Test Manager (MTM), Zephyr for Jira или HP Quality Center (QC) (сравнение этих систем по наиболее важным параметрам см. в таблице).

Microsoft Test Manager

MTM упрощает тестирование собранного приложения. Система сохраняет планы и результаты тестирования на сервере Team Foundation Server. Если все функции MTM не нужны, то для планирования и запуска тестов можно использовать Team Web Access.

Функциональные возможности системы:

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

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

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

Тестирование приложений для магазина Windows. Можно собирать диагностические данные и скриншоты при выполнении тестов на устройстве или ПК с Windows 8 при помощи приложения MTM, запущенном на отдельном ПК.

Планирование тестов приложения из документа Microsoft Excel или Microsoft Word. Можно использовать Excel для массового редактирования планов тестирования и синхронизации с планами тестирования, внедренными в документы Word.

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

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

JIRA Zephyr

Тест-трекинговую систему Zephyr for Jira целесообразно использовать, если в компании уже используется система управления проектами Atlassian Jira. Jira – это продукт, который может быть лицензирован для работы на локальном сервере или доступен в качестве удаленного приложения. Особенности данной системы:

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

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

Поиск тестов столь же простой, как и поиск сущностей в Jira. Можно настраивать поиск определенной группы тест-кейсов и создавать тест-планы с сохраненным фильтром. Сохраняя фильтр, можно создавать инфографику стандартными средствами Jira с доступом для всей команды.

HP Quality Center

Система HP Quality Center содержит пять модулей, тесно интегрированных между собой и обеспечивающих непрерывность процесса тестирования:

Management – модуль регистрации релизов ПО, подлежащих тестированию. Сущность «Release» может иметь дочернюю сущность «Cycle», означающую цикл тестирования.

Requirements management – модуль описания требований. Как правило, каждому требованию соответствует одна сущность «Requirement». Допускается многократная вложенность требований, а также различные типы требований (в том числе создаваемые пользователями).

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

Test Lab – модуль, в котором отдельные тесты объединяются в последовательности, задаются условия запуска тестов в зависимости от успешности предыдущих, создается расписание запуска тестов, осуществляется запуск тестов вручную.

Defects management – система отслеживания ошибок, интегрированная со всеми другими модулями. Ошибку можно зарегистрировать как в требовании (модуль Requirements), тесте или шаге теста (Test Plan), так и в конкретном запуске теста (Test Lab).