Добро пожаловать в серию статей «Лидерство в тестировании» от гуру тестирования программного обеспечения и консультанта Пола Джеррарда. Эта серия предназначена для того, чтобы помочь тестировщикам с многолетним опытом работы, особенно в Agile командах, преуспеть в своей роли руководителя тестирования и менеджера.  

В предыдущей статье мы рассмотрели инструменты для выполнения тестов. В этой статье мы более подробно остановимся на обеспечении бизнес-процессов предприятия. 

Мы подошли к двум последним статьям из серии "Лидерство в тестировании". До сих пор мы рассуждали о том, как планировать тестовый проект и управлять им от начала до конца, а также о многих связанных с этим инструментах и процессах.  

В этой статье я хочу обсудить обеспечение бизнес-процессов предприятия - что это такое и как к нему подступиться. Мы рассмотрим:

• Что такое обеспечение бизнес-процессов предприятия? 

• Понимание системной интеграции и тестирования 

• Горизонтальное тестирование: Подход к тестированию E2E 

• Риски интеграции и E2E-тестирование 

Тут есть о чем поговорить, так что давайте продолжим.  

Что такое обеспечение бизнес-процессов предприятия? 

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

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

Мы называем этот заключительный этап обеспечением бизнес-процессов предприятия (Enterprise Business Process Assurance — EBPA). Успех зависит от одного или нескольких этапов тестирования, которые продемонстрируют, что системы, бизнес-процессы и данные интегрированы и предоставляют обещанные услуги. 

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

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

Понимание системной интеграции и тестирования 

Вертикальная интеграция 

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

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

Горизонтальная интеграция 

Конечные пользователи не видят технической архитектуры и всей ее сложности. Они рассматривают систему как набор функций, реализуемых разными пользователями в процессе, который можно назвать пользовательским путешествием (end-to-end test).  

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

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

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

При тестировании вертикальной интеграции используется более технический подход; при горизонтальном тестировании используется подход пользователя или бизнес-процесса. 

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

Модель для интеграции и тестирования 

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

Давайте сосредоточимся на примере использования готовых коммерческих модулей (commercial‑off‑the‑shelf — COTS) и модулей планирования ресурсов предприятия (enterprise resource planning — ERP).

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

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

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

Правая часть модели выделена синим цветом и представляет собой EBPA. Тестирование нашей системы в контексте других систем (system in the context of other systems — SIT) и бизнес‑процессов (system in the context of business process — BIT) — это то, что мы называем обеспечением бизнес-процессов предприятия. 

Давайте рассмотрим четыре сектора по очереди. 

Тестирование модулей, функций или компонентов 

Модуль должен быть функционально протестирован, независимо от того, создан ли он на заказ или является компонентом COTS. Удобство для пользователя всегда важно и должно быть интегрировано с каким-либо этапом или действием бизнес-процесса. 

Интеграционное тестирование подсистем 

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

Тестирование системной интеграции (SIT)

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

Тестирование бизнес-интеграции (BIT) 

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

В оставшейся части этой статьи мы уделим большое внимание горизонтальной, EBPA-составляющей модели. 

Горизонтальное тестирование: Подход к тестированию E2E 

Горизонтальная интеграция в наибольшей степени зависит от того, что часто называют сквозным (end-to-end) тестированием. 

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

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

Эти модели могут быть привычными схемами, такими как блок-схемы или диаграммы плавательных дорожек (swim-lane diagrams), или более техническими представлениями, такими как диаграммы последовательности UML или совместной работы. (UML — это унифицированный язык моделирования, используемый многими ИТ-организациями). 

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

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

Приемка 

Понятие «соответствие» подходит для интеграции компонентов, системной интеграции между системами и интеграции системных бизнес‑процессов.

Приемка, как правило, основывается на результатах горизонтальных end‑to‑end тестов, поскольку заинтересованные стороны могут быть уверены, что эти тесты показывают, насколько новая система подходит и поддерживает их методы работы. Горизонтальные end‑to‑end тесты дают им уверенность в том, что предоставляемый сервис будет работать.

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

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

Если вас попросят спланировать приемочное тестирование, мы ожидаем, что методика тестирования end‑to‑end сыграет большую роль в вашем планировании. 

Риски интеграции и E2E-тестирование 

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

Некоторые организации предпочитают разделять тесты, направленные на устранение этих двух типов рисков, на тестирование системной интеграции (SIT) и тестирование бизнес‑интеграции (BIT). Но часто риски и тесты объединяются в единый этап тестирования, обозначаемый как end‑to‑end, приемочное или бизнес‑тестирование.

Как бы ни было структурировано тестирование, в нем широко используется подход к end‑to‑end тестированию, описанный выше. Риски, с которыми вы сталкиваетесь, могут быть различными, и вам, возможно, потребуется соответствующим образом скорректировать цель тестирования и подход к тестированию.

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

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

Примечания к таблице рисков 

Некоторые из вышеперечисленных рисков требуют более подробного объяснения.

Проблемы с передачей данных 

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

Ошибочная передача управления 

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

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

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

Данные не согласовываются 

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

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

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

Системы не синхронизированы 

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

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

Объекты не согласуются друг с другом 

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

Системы, не интегрированные с бизнес-системами 

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

Серверные процессы не поддерживают интерфейсную часть 

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

Несогласованные пользовательские интерфейсы 

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

Заключение 

Мы обсудили модель интеграции и тестирования, в которой особое внимание уделяется интеграции в масштабах предприятия и бизнес‑процессам. Подход end‑to‑end — единственный, который требует полной системной интеграции и основывает тестирование на полном взаимодействии пользователей. Таким образом, заинтересованные стороны могут видеть доказательства правильной работы систем в реалистичном контексте.

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

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

Подход EBPA, особенно в случае автоматизации, расширяет режим непрерывной интеграции от подсистемы до обеспечения бизнес‑процессов предприятия. 

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

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

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