Робин Шонвальд

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

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

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

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

Для многих клиентов, которые приступают к тестированию, вопрос, во-первых, заключается в определении тестового сценария – test case, а во-вторых — в управлении его реализацией. Однако проверка и тестирование отличаются друг от друга.

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

Какие технологии нам помогают в этом? Во-первых, SAP Solution Manager. Но, конечно, все зависит от вашей организации и от тех решений, которые ей лучше всего подходят. Во-вторых, автоматизация тестирования. Существует масса инновационных решений и в этой области, некоторые из них мы рассмотрим позже. Если налажено автоматизированное тестирование, то нужно подумать и об управлении тестовыми данными. У некоторых клиентов есть автоматическая процедура оптимизации скрипта — она позволяет обеспечить полное соответствие тестируемых данных: так как если вы повторно запустите скрипт при тестировании работающей системы, то получите уже другой результат — в тестирование попадут другие данные.

Также существуют «продвинутые» методы тестирования возможных рисков — самых важных рисков: повторно тестировать приложение в полном объеме нельзя, поэтому нужно использовать рисковый подход по выявлению самых проблемных вещей или использовать, например, РСА – анализ последствий и влияние этих последствий на ситуацию. Также эффективен тест, который анализирует компоненты — примеры его применения я также приведу позже.

Рассмотрим 8 возможных вариантов экономии при тестировании.

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

Тех же респондентов спросили: «Сколько людей в вашей компании тестерами – с полной занятостью или с совмещением данных функций?». И более 50% сказали: «Мы не знаем». Получается, что издержки на тестирование, как правило, являются скрытыми: тестеры часто выполняют другие, смежные функции и бизнес-задачи, и никто точно не знает, каковы реальные затраты компании на тестирование.

Рекомендация
Выявите все центры издержек, связанных с тестированием.

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

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

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

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

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

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

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

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

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

В дальнейшем возникают другие затраты — эксплуатационные. Gartner заявляет, что 40% случаев впепланового простоя систем возникает из-за операционных ошибок, 20% от других причин, и 40% – из-за отказа приложений. Эти 40% отказа приложений — очень высокий процент — можно существенно уменьшить за счет правильного тестирования. Простой влечет за собой реальные затраты, а также риск утраты репутации и доверия к компании. Если клиент не может зайти к вам на сайт, не может снять деньги из банкомата или сделать что-то еще, он теряет к вам доверие.

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

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

Как-то мы приехали к клиенту, и один из наших опытных специалистов, рассмотрев тест-кейсы, понял, что в 50% случаев результаты были разные на одном и том же кейсе — то есть эффективности там не было никакой. Следовательно, можно было бы снизить количество этих тестов весьма значительно, не менее, чем на 15%. Тест-менеджер должен знать, сколько тест-кейсов должно быть выполнено, кто их будет выполнять — нужно уметь правильно распоряжаться ресурсами. Какие бизнес-процессы затрагиваются, какие данные нужно использовать для тестирования?

Рекомендация
Ситуация упрощается, если у нас есть интегрированное средство для тестирования или вся нужная релевантная информация, проанализировав которую, мы можем сказать: «Да, систему можно запускать». Возможно, есть сертификат ISTQB – это европейская организация, в которой можно получить сертификат тестера или тест-менеджера.

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

Как вы думаете, какой инструмент используется наиболее часто для управления тестированием? Microsoft Excel. Он широко распространен и используется, помимо прочих сфер, и в области управления проектами. Однако изначально он не для этого создавался. Поэтому многие люди могут совместно работать с таблицами Excel, но если у вас идет проект, превосходящий рамки обычного масштаба, Microsoft Excel вам не поможет. Лучше использовать другие инструменты. Например, SAP Solution Manager предлагает интегрированные средства для управления тестированием и возможность осуществлять тестирование в автоматическом режиме. Я рекомендую вам использовать SAP Solution Manager, это очень хороший выбор. Если у вас есть иные инструменты, например, Quality Center, то их можно с помощью адаптера интегрировать. Новая версия «SAP Solution Manager 7.1 интегрирована с IBM Rational Tools, поэтому вы можете выбирать — использовать ли SAP Solution Manager, или другие средства, для которых есть адаптеры. Однако Microsoft Excel – это, пожалуй, не то, что я вам рекомендовал бы использовать.

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

Это интегрированное решение, и я хочу вам показать скриншот ручного тестирования.

Эта процедура подразумевает использование подсказок: что именно нужно тестировать. Тестер может изучить пакет для тестирования, выбирать из него нужные компоненты, и получается у него на экране вот такая страница, такой интерфейс. Далее он начинает этот процесс, нажимая кнопку Start execution, система опознает, какую транзакцию необходимо проверить, и тестирует. Запустив эту процедуру, получаем описание теста в формате Word или PDF. В нем зафиксированы поля — статус, действие, комментарий, ограничение, тестовый пакет в качестве приложения, место обнаружения инцидентов - в общем, на одном экране доступного пользователю интерфейса есть все, что нужно для тестирования.

Где еще можно сэкономить деньги за счет этого подхода? За счет автоматизации процесса тестирования. Автоматизация тестирования сейчас популярна, однако – вещь сложная, очень много можно напутать. В немецком журнале «Computerwoche» была статья, автор которой делился своим опытом внедрения SAP. По его мнению, автоматизированные тесты от компании SAP экономят деньги. Он заявляет, что после четвертого сета тестирования показатель окупаемости инвестиций значительно возрастает. Таков опыт использования, однако есть еще и дополнительные средства, которые помогают вам провести тестирование лучше и эффективнее на дальнейших стадиях.

Где можно ошибиться в автоматизации тестирования? Ну, во-первых, когда вы выбираете кейс для тестирования — не все можно протестировать в автоматическом режиме. Система – живая вещь, она меняется все время, и когда она меняется, необходимо менять скрипты для автоматизированного тестирования. Всего 20-40 процентов автоматизированных тестов подходят для автоматизированной проверки, в реальных условиях обычно не больше 20%. А дальше нужно выявлять уже бизнес-процессы или транзакции с более высокой приоритетностью: такие, которыми пользуются многие пользователи по многу раз в день.

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

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

Затраты на обслуживание. Сейчас написать скрипт не так-то сложно, однако как снизить затраты на обслуживание этого скрипта? В HP Quality Centre есть такой подход – BPT (business process testing): вы создаете повторно используемые компоненты теста. Чем больше скрипт, тем больше шанс того, что нужно будет менять его, если вы меняете что-то в системе. А если у вас есть стандартные блоки, кусочки, которые можно повторно задействовать, вы гораздо быстрее можете потом создать скрипт, и это гораздо лучше, если вам нужно что-то изменять в скрипте.

Идея ВРТ была расширена с помощью SAP ТАО и нового решения — в версии 7.1 SAP Solution Manager включена функция «component based test automation» – CBTA, а также функционал TCE – «test composition environment», то есть среда для тестирования и создания повторно используемых компонентов.

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

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

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

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

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

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

Где еще можно сэкономить? Седьмая статья экономии – аутсорсинг тестирования. Это новый тренд, новая мода, которая в США набирает особую популярность, в Европе тоже, может быть, и в России начнет проявляться такая тенденция. Несколько лет тому назад 37% клиентов выполняли тестирование силами собственных сотрудников, сейчас — уже 31%, и мы видим, что лишь только 2% делают это с помощью внешних специалистов, отдают это на аутсорсинг.

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

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

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

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

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

Резюме

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

Вопросы и ответы

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

РОБИН ШОЕНВАЛЬД:
– Тестирование с помощью облачных технологий – вещь новая. У компании SAP, кстати, много продуктов, которые живут и работают в так называемом облаке. Тестирование же с помощью внешних экспертов, привлекаемых на крупные проекты, подразумевает обращение на так называемые фабрики тестирования — там есть эксперты, которые профессионально занимаются тестированием всего приложения. У компании SAP есть эксперты из global delivery, которые работают с решениями SAP тоже. Но для нашей компании это не основной фокус — есть другие компании, которые этим занимаются более прицельно.

– В ситуации, когда ключевому пользователю задают вопрос о приемлемом времени реакции приложения и он говорит: «Я не знаю», правильно ли будет, если IT все-таки заставит его ответить на этот вопрос, или есть какое-то другое решение?

РОБИН ШОЕНВАЛЬД:
– Хороший вопрос. Я как-то спрашивал одного моего клиента: «Вот когда система работает правильно?». Он говорит: «Не знаю, сказать не могу, но зато, когда она неправильно работает, я сразу вижу». То есть клиент не знает того, что мне от него нужно. Мы часто изучаем опыт использования предыдущих версий, где в самом начале определяем, что время доступа приложения должно быть 0,5-2 секунды, среднее время доступа – 1,2 секунды. Вот такие определения я даю клиенту в качестве примера, а они говорят: «Ну, такое время для нас приемлемо, а вот такое неприемлемо». Среднее время тоже имеет свой минимум и максимум, и ваш пользователь должен знать, каков этот показатель в реальности. Например, используются наглядные примеры, слайды, которые переключаются через определенное время — клиент смотрит и говорит, устраивает его такое время задержки или нет. В общем-то, очень сложно получить ответ на вопрос, что приемлемо, а что нет, нельзя заставить клиента сказать: «А ну-ка, напиши список со временем доступа, которое тебе надо». Никогда такой подход на практике не срабатывает, так что приходится прибегать к изощренным методам.

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

РОБИН ШОЕНВАЛЬД:
– Рекомендации зависят от сложности вашего конкретного решения — я знаю массу клиентов, которые используют три стандартных уровня иерархии – разработка, дальше тестирование, и затем уже использование в производстве. Есть также клиенты, у которых и 15 таких уровней есть — от разработки до ввода в эксплуатацию, использования. То есть все зависит от решения: от его сложности, количества пользователей, критичности этого решения для бизнеса. Если у вас 15 таких уровней, то, наверное, требуется определить критичные для бизнеса процессы, и масса средств для того, чтобы это все поддерживать «на плаву», так что нельзя дать универсальную рекомендацию для всех. Обычно трех-четырех уровней достаточно, но все это очень индивидуально.

– А какой ландшафт поддерживает Solution Manager в этом случае?

РОБИН ШОЕНВАЛЬД:
– Solution Manager – вещь очень гибкая: и двух уровневая иерархия в нем используется, и пятнадцати уровневая. Solution Manager универсален в этом плане. Он может с помощью управления транспортом, запросами, тестированием поддерживать самые сложные системы. Но нужно правильно выдерживать баланс между средствами, которые вы затрачиваете на то, чтобы использовать эти системы для тестирования, и уровнем вашей сложности. Нужен сбалансированный подход. Около 30-40% наших клиентов имеют трехуровневые системы, а другие – более сложные, у некоторых, правда, только двухуровневые, однако это очень редкие случаи. Так что нужно рассматривать — какая у вас архитектура, бизнес-процессы. Тогда можно будет дать конкретную рекомендацию, какой ландшафт лучше использовать для тестирования.

– Вы упоминали автоматические тесты. Можете назвать несколько эффективных инструментов, или просто информацию, что их кто-то использует?

РОБИН ШОЕНВАЛЬД:

Да, верный вопрос и верный комментарий. Есть простые инструменты «capture/replay» и CAD. «Capture/replay» разработан компанией SAP и поставляется вместе с Solution Manager без дополнительной платы за лицензию. Вы можете автоматизировать тестирование и с помощью CAD, но только для интерфейса SAP. Если это будет какая-то «серая» система, то и CAD там уже работать не будет. Поэтому мы используем QTP от Hewlett-Packard, эта аббревиатура расшифровывается «quick test professional». Это тоже инструмент для «capture/replay», и, как и CAD, он совместим с любыми пользовательскими интерфейсами. Нужно дополнительно приобретать лицензию QTP, но если вы корпоративный клиент, в нашей службе поддержки две лицензии вы получаете бесплатно вместе с версией SAP Solution Manager 7.1. Если вы хотите выйти на следующий уровень тестирования, то тут нужно упомянуть такой инструмент, как HP Quality Center, BPT (business process testing). С его помощью мы разрабатываем тест-компоненты и дополнительный продукт - SAP TAO, который создает повторно используемые компоненты для ВРТ без программирования. То есть вы запускаете тест-кейс, ТАО создает повторно используемый компонент с нужными параметрами и отправляет его в ВРТ. При использовании SAP Solution Manager в версии 7.1 мы предлагаем эти функции за счет использования следующего инструмента, интегрируемого туда – CBTA (component-based test automation). Это средство для автоматизированного тестирования, основанное на компонентах TCE (test composition environment), то есть среда тестирования. Этот инструмент входит в SAP Solution Manager 7.1, и интерфейс от Goji, и CRN поддерживается – все, что вы видели в системных требованиях управления, можно тестировать с помощью данного приложения. В версии SAP Solution Manager 7.1 есть еще Test Automation Framework - специальный фреймворк для автоматизации тестирования. Эта функция позволяет вам использовать практически все инструменты для автоматизации тестирования, имеющиеся сегодня на рынке. Конечно, требуется сертификация, но, в принципе, крупные вендоры, производители этих инструментов, имеют такие сертификаты, и они подходят для использования в этом фреймворке. Можно применять их вместе с SAP Solution Manager, можно управлять скриптами для тестирования, запускать их из других инструментов, получать статус, делать подробный анализ лог-файлов. Все это позволяет делать Test Automation Framework. Пожалуй, на сегодня это наиболее ключевые решения для автоматизированного тестирования.