Двухрелизная модель развития решения

Докладчик: Маркус-Александр Функе, SAP

Давайте подумаем о роли тестирования в ежедневной жизни IT. В чем заключается самая большая сложность при тестировании IT-решений? Многие считают, что это тест-кейс: его необходимо описать настолько детально, чтобы максимально приблизить к реальной бизнес-задаче. Также сложности может вызывать создание тестовой модели, помогающей при обновлении системы протестировать ее жизнеспособность на уровне существующих тестов и сценариев. Какие же инструменты используются для поддержки тестирования? И есть ли способ оптимизировать издержки на этот процесс без потери качества конечного продукта? В Solution Manager есть функциональность, которая позволяет управлять тестированием, в том числе ручным. Мы также работаем и с решениями других вендоров, в том числе — с HP Quality Center, это один из наших стратегических партнерских продуктов.

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

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

Концептуальная картина управления тестированием в SAP такова: мы создаем новое решение, создаем Blueprint, и Blueprint в идеале должен быть задокументирован в SAP Solution Manager. При тестировании, вне зависимости от того, какие типы тестов вы будете использовать, вам придется заниматься планированием тестов. Это процесс, где вы составляете планы тестов, гранулярность определяете, предлагаете путь реализации теста. Реализуется тест с помощью тест-кейсов. И с точки зрения передовых практик SAP, мы не определяем тип теста, который вы можете использовать, например, «end-to-end» тест, string-тест. Что касается исполнения теста, то, прежде всего, нужно подготовить тест, а потом сделать его реализацию. И, конечно же, после тестирования дальше начинается реализация изменений.

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

У многих клиентов используются ECAD, которые существуют уже достаточно давно, но имеют свои ограничения. Только GUI-транзакции могут автоматизированные, а в ECAD имеются проблемы с «end-to-end» тестами. Для этого Solution Manager предлагает функции, которые называются «тест automation frameworks», ключевые компоненты — CBTA, компонентный инструмент, который позволяет вам автоматизировать сквозные процессы, «end-to-end» процессы.

Второй, вторичный набор инструментов называется так, как назвал мой коллега здесь за столом, — HP Quality Center. Он являлся и по‑прежнему является одним из самых лучших инструментов управления тестированием. Особенно HP Quality Center используется большим количеством компаний для того, чтобы тестировать приложения не из саповской среды. Такова рыночная реальность. Многие клиенты используют HP Quality Center как отдельное решение. Но как часть вашего проекта, Blueprint, как часть ILM, вы используете и HP Quality Center. Но я бы рекомендовал вам сделать так, чтобы процессы были введены в SAP Solution Manager, а потом адаптированы для HP Quality Center, чтобы вы воспользовались лучшими функциями и того, и другого.

HP Quality Center использует SAP TAO, это специальный framework, автоматизированный для тестирования, и позволяет проводить автоматизированные тесты, SAP TAO, и я считаю, что существуют, конечно же, различные способы проведения тестов, но в целом они практически одинаковы. Второй вариант — когда мы интегрируем, например, инструмент иного производителя. И тот, и другой подход примерно одинаковые с точки зрения интеграции. Solution Manager предлагает определенные функции, которые называются «анализ последствий изменений». Например, если вы внедряете какой‑либо update-пакет либо новое функциональное требование, и необходимо узнать, какие транзакции должны выполняться — для того, чтобы определить вот именно последствия и масштаб последствий, не проходя через весь цикл сквозного тестирования, можно использовать change impact analyser.

Технология, которая за этим стоит — TBOM, техническая спецификация материалов, которая определяет различные транзакции для выполнения. Это функция BPCA, которая осуществляет анализ последствий. То есть вам не нужно использовать для этого инструмент сторонних производителей, потому что SAP Solution Manager использует такие же функции, и если вы правильно подготовите документацию и наладите процессы тестирования, правильно их интегрируете, вы сможете это использовать как коробочное решение, без изменений.

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

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

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

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

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