Комментарии по теме

«Игровой ролик: SAP для Retail»
Александр Дублин:
Суть ролика: если хотите спать в рабочее время, унижать подчиненных, то с решением от SAP вам это будет удобно. Сценарий ролика - продолжения истории: top-lap.livejournal.com/502664.html
«Ста­нда­рти­за­ция те­сти­ро­ва­ния и повышение на­де­жно­сти решений за счет инте­гра­ции SAP Solution Manager и SAP Quality Center by HP»
Кирилл Сатарин:
Хорошая статья, дает прекрасное понимание того, как работает взаимодействие между Solution Manager и HP SAP Quality Center. К сожалению авторы не указывают какую именно выгоду можно получить от...
«Ко­мпле­ксное решение для эле­ктро­нно­го до­ку­ме­нто­о­бо­ро­та на базе SAP ERP»
Иван Савчук:
Не хватает технической части. В остальном все очень подробно.

Мероприятия

Академия передовых практик внедрения и поддержки SAP (2014-2015) Дата проведения: 9 октября 2014 г. Все мероприятия

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

Предыдущая Следующая

Для скачивания материала, необходимо войти на сайт или зарегистрироваться.

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

Докладчик: Маркус-Александр Функе, 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, тест-планы, которые распределяются уже по ролям тестеров либо пользователей, отвечающих за те или иные бизнес-процессы. Что нужно тестировать, как структурировать тест-пакет? Это делается по профилю авторизации, который помогает нам правильно определять, что нужно тестировать.

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

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

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

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

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

Создав план тестирования, мы составили набор тест-кейсов, назначили их пользователям, и я теперь пытаюсь перейти на следующий шаг, потому что теперь нужно реализовать тест. Особенно, когда у вас бизнес распределенный, и вы хотите сэкономить, и не приглашать людей непосредственно, нужно им вместо этого отправить электронное сообщение — назначить пользователя на определенный тест-пакет, сгенерировать уведомление в виде e-mail. Как это выглядит?

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

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

Это просто выполнить — добавляете информацию, создаете заказ. Изначально создаются вручную документы. Можно взять из «Excel» эту информацию и заполнить эти поля. Не обязательно вручную заполнять все 55 полей, можно использовать импорты из «Excel». Это делается в режиме разделенного экрана, сохраняем, выходим. Тут есть несколько полей, которые обязательны для заполнения. Каждый тестер имеет статус, и тест-менеджер, и проектный менеджер получают отчетность, которая показывает, насколько хорошо реализуется тест, сколько тест-кейсов провалилось, сколько — нет. Где все хорошо, а где придется повторно тестировать, где обнаружились ошибки. Как тест-менеджер вы можете этим всем управлять и отслеживать, как осуществляется это тестирование. Я считаю, что можно обсуждать, полезный это инструмент или нет, но у вас есть возможность тестировать, по крайней мере, вручную. Вы прекращаете реализацию, выполнение, сохраняете тест-кейс, закрываете, и потом при обновлении информация обновляется.

Предположим, у вас есть проект, где 400–500–600 человек занимаются тестированием, и по ним постоянно скапливается отчетность. Эта отчетность — одна из функций Solution Manager, которая позволяет вам тестировать самые различные тест-пакеты, проводить мониторинг ошибок, анализировать, что завершилось благополучно, а где результат не достигнут. Эту функцию очень любят проектные менеджеры, потому что она дает возможность отслеживать прогресс тестирования.

Рассмотрим анализ последствий проводимых изменений — impact анализ в случае, если вы будете использовать тибомы из существующей системы для того, чтобы определить оптимальные тест-кейсы и осуществить регрессионный тест. Инструмент impact анализа используется также при ведении разработок. В таких тест-кейсах вы определяете масштаб, когда внедряете срочные изменения в вашу систему производства и проверяете, не возникнет ли от этих изменений побочных эффектов, ненужных последствий. Инструменты других вендоров, к сожалению, не могут показать этот анализ достаточно детально, но impact анализ часто показывает, что 70‑80 % транзакций при внедрении изменений придется перетестировать. Это очень мощный инструмент, который позволяет определить масштаб тестирования. При внедрении срочных изменений тестируется все на предмет того, не возникает ли сложных побочных эффектов.

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

В заключение хочу привести пример, как change impact анализ влияет на оптимизацию. Это BPCA для EHP. Пример такой. 73 тест-кейса показали 10–15 %, и, оценивая риски, вы можете минимизировать их влияние. Этот инструмент создает новый тест-план: изначально он создается вручную, но если вам необходимо внести enhancement-пакет, это происходит автоматически. Проверив TBOM, который вы собираетесь внедрить в производство, система устанавливает автоматически количество тестов, которые должны быть выполнены.

Предположим, что у вас 100 транзакций можно таким образом автоматизировать. Если вы 100 автоматизируете, то вы будете топ-компанией в мире. Такие компании, как «BMW», имеют очень высоко автоматизированную систему, и они 80–100 транзакций подобного рода автоматизируют, а это около 20 % транзакций из общего количества. Это имеет смысл, и на такое количество имеет смысл тратить силы. Если же это транзакции, которые осуществляются слишком редко, то их автоматизировать не очень нужно. Если вы автоматизируете 100 из 500 или даже 1000 транзакций, это будет очень хороший показатель. При автоматизации этого тестирования вы можете начать с 20–30 транзакций автоматизированных, и с мастер-данных. Вы для этого должны иметь очень хорошо описанные процессы.

Юнит-тест — это тест, который девелопером, консультантом выполняется, и 90 % компаний не используют инструменты по управлению тестированием, потому что они считают, что это лишние затраты. Вот предположим, вы составляете конфигурацию, где вы будете проделывать первый тест самостоятельно. String-тест для IT, для сквозных процессов этим занимаются специалисты из IT-отдела. Если речь заходит об интеграции, о тестах на интеграцию и приемку пользователя, то он проводится ключевыми пользователями. И тест на приемку пользователя требует существенных усилий, обновлений. К тестам на интеграцию привлекается бизнес, требуется 5–6 недель выделить для того, чтобы все протестировать.

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