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

Тестирование – один из самых сложных этапов во многих проектах. Поэтому мы обсудим, как минимизировать связанные с 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% отказа приложений — очень высокий процент — можно существенно уменьшить за счет правильного тестирования. Простой влечет за собой реальные затраты, а также риск утраты репутации и доверия к компании. Если клиент не может зайти к вам на сайт, не может снять деньги из банкомата или сделать что-то еще, он теряет к вам доверие.

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

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

Существует три различных уровня, на который выдается данный сертификат. В 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

Материалы для скачивания

Робин Шонвальд, Документация бизнес-процессов при внедрении SAP (EN)Day2_12h45_Robin.pdf