Привет, Хабр. Меня зовут Василь Хамидуллин, я работаю в ЦК тестирования решений на платформе SAP в компании РСХБ-Интех. Сегодня я поделюсь опытом тестирования бизнес процессов, внедряемых модулей SAP, в банке.

Что такое SAP и зачем его тестировать 

Немецкая корпорация SAP — один из лидеров на рынке поставки ПО для автоматизации бизнес процессов. Пользователи SAP — крупные компании с внушительным оборотом и числом сотрудников. 

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

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

Первое знакомство с системой SAP и смена деятельности

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

На данный момент я работаю в ЦК тестирования решений на платформе SAP в РСХБ-Интех. В мои обязанности входит тестирование бизнес-процессов внедряемых модулей SAP в банке. Опыт работы консультантом сильно помог переквалифицироваться в тестировщика SAP. Для успешной и эффективной работы мне необходимо было ознакомиться только с теоретической стороной тестирования, ведь навыками работы в системе я уже обладал.

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

Виды тестирования, используемые на проекте внедрения SAP

Для полноценного тестирования таких внедренных модулей, как MM, RE, PS, FI, PM и других, а также тестирования выстроенных бизнес-процессов, на нашем проекте применяются следующие виды тестирования:

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

Данный вид тестирования применяется нами при тестировании многих компонентов, среди которых:

• расширение стандартных отчетов;

• формирование статусных схем;

• контроль сроков выполнения;

• формирование и согласование различных заявок;

• проверка полномочий;

• формирование печатных форм;

• массовая рассылка сообщений.

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

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

С помощью данного вида на проекте среди прочих нами тестируется:

• поступление ИТ-активов;

• планирование затрат на персонал;

• формирование заявки на потребность, заявки на оплату, заявки на закупку, заявки на корректировку лимита;

• управление проектами, в частности, развитие региональной сети.

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

На данный момент на проекте по внедрению SAP присутствуют следующие информационные системы, с которыми настроена интеграция:

• Автоматизированная система управления персоналом;

• TransBase — ПО для управления автотранспортом;

• Gootax.pro — ПО для вызова такси;

• АБС ЦФТ — универсальная мультиплатформенная автоматизированная банковская система;

• CDI — ПО для управления клиентскими данными;

• АСУЗ — система управления зданием;

• uCMDB — база данных управления конфигурациями и элементами информационных технологий.

• IDM — система управления доступом;

• Web-alpha — система учета затрат на устройства самообслуживания;

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

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

Критичная функциональность, подлежащая smoke-тестированию, представлена следующими отдельными элементами бизнес-процесса:

• создание основных видов заявок, участвующих в бизнес процессе;

• создание основных видов контрактов, участвующих в бизнес процессе;

• осуществление основных видов проводок, таких как перемещение и списание;

• формирование критичных для бизнес-процесса отчетов;

• создание единиц оборудования;

• создание проекта развития региональной сети;

• создание критичных для бизнес-процесса карточек и договоров и др.

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

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

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

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

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

Стоит отметить, что каждый вид тестирования осуществляется на соответствующих контурах тестирования. КФТ, СФТ, ИФТ тестируется на контуре FTEST. Регрессионное тестирование проводится на контуре RTEST. Приемо-сдаточные испытания проводятся на отдельном контуре для приемочного тестирования.

Какие инструменты мы используем для тестирования SAP

TEST-IT

Для эффективного управления процессом тестирования на проекте используется система управления тестированием «TEST IT». К плюсам данной системы можно отнести:

• возможность легкого импорта тест-кейсов;

• возможность настройки интеграции с необходимым сервисом (в нашем случае Jira);

  

• наличие поддержки и регулярные обновления системы под нужды банка;

• возможность сбора и отображения статистики.

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

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

Внутри проекта во вкладке «тесты» отображается вся структура проекта. Здесь показаны созданные нами тест-кейсы.

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

Для организации эффективной работы проектной команды мы используем связку JIRA—Confluence.

Confluence

В качестве внутренней системы единой базы знаний на проекте мы используем «Confluence». Данная система удобна тем, что она позволяет каждому участнику процесса вносить свои данные, а также создавать новые ветки и подразделы. Здесь мы храним актуальную информацию о статусе проекта, подробный разрез прогресса тестирования, а также сопровождающую информацию, необходимую каждому тестировщику.

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

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

Jira

Для ведения списка задач и поручений мы используем Jira. Это система регистрации и исполнения обращений, ведения любого рода реестров и управления задачами. Здесь мы ведем учет рабочего времени в разрезе порученных задач. 

Также регистрируем дефекты систем и сопровождаем весь их жизненный цикл.

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

Проблемы и их решения

Одной из первых проблем, с которой мы столкнулись на проекте, было недостаточное владение профессиональными компетенциями членами команды в отношении тестируемых модулей SAP. Каждый тестировщик имел опыт работы в определенном модуле, следовательно, был специалистом в узком наборе бизнес процессов. В моем случае это был модуль HCM. 

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

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

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

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

Перспективы развития

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

Для начала планируется использовать встроенные инструменты SAP как для подготовки объемных тестовых данных, так и для проведения несложных механических тестов в системе. К таким инструментам относится Legacy System Migration Workbench, SAP Solution Manager TestSuite, SAP TAO, SAP eCATT.

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

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

Если есть вопросы/предложения, пишите в комментариях — обсудим. Спасибо за внимание!