->
Примечание редактора. Добро пожаловать в серию статей «Лидерство в тестировании» от гуру и консультанта по тестированию программного обеспечения Пола Джеррарда. Эта серия предназначена для того, чтобы помочь тестировщикам с опытом работы в несколько лет, особенно тем, кто работает в agile-командах, преуспеть в роли руководителя тестирования и управления.
В предыдущей статье мы рассмотрели инструменты, которые вам понадобятся для эффективного тестирования и совместной работы. В этой статье мы обсуждаем заключительный этап тестирования и способы подтверждения того, что ваши системы будут работать в соответствии с планом.
Мы подошли к последней паре статей из серии «Лидерство в тестах». До сих пор мы рассмотрели, как планировать тестовый проект и управлять им от начала до конца, а также многие из задействованных инструментов и процессов.
В этой статье я хочу обсудить обеспечение корпоративных бизнес-процессов (EBPA) — что это такое и как к нему подойти.
Нам предстоит многое рассказать, так что давайте приступим.
Что такое обеспечение корпоративных бизнес-процессов?
Каждая организация, внедряющая новые системы, сталкивалась с проблемами при их первом использовании. Системы, которые даже немного не соответствуют существующей инфраструктуре и бизнес-процессам, могут привести к хаосу и сложности в ремонте.
Итеративные, гибкие и более совместные методы помогают, но проблемы интеграции в масштабе предприятия могут быть решены только на заключительном этапе тестирования.
Мы называем этот заключительный этап обеспечением корпоративных бизнес-процессов (EBPA) . Успех зависит от одного или нескольких этапов тестирования, которые продемонстрируют, что системы, бизнес-процессы и данные интегрированы и предоставляют обещанные услуги.
На эту тему мало научных статей, хотя на последних этапах каждого крупномасштабного проекта эта деятельность доминирует. Чтобы проинформировать нашу стратегию EBPA, мы сначала более подробно рассмотрим типы системной интеграции и тестирования, с которыми вы будете иметь дело.
Понимание системной интеграции и тестирования
Вертикальная интеграция
С технической точки зрения интеграция представляет собой связь между различными уровнями технической архитектуры. Интеграционное тестирование для разработчиков в основном состоит из проверок того, что данные, принятые через пользовательский интерфейс в транзакции обновления, успешно сохраняются в базе данных.
С другой стороны, хранящиеся данные проверяются, чтобы их можно было точно представить в пользовательском интерфейсе по запросу. Связи и пути через техническую архитектуру можно рассматривать как вертикальные пути или вертикальные интеграционные тесты.
Горизонтальная интеграция
Конечные пользователи не видят технической архитектуры и всей ее сложности. Они рассматривают систему как набор функций, используемых разными пользователями в ходе того, что можно назвать путешествием пользователя.
Эти пути отслеживают пути в бизнес-процессах пользователей и получают доступ к различным системам и функциям на каждом этапе пути с помощью пользовательского интерфейса.
Agile-команды работают над историями меньшего масштаба и не видят большой эпопеи. Разработчики обычно не могут отслеживать и тестировать более длительные пути пользователя, потому что у них нет сред или данных. Таким образом, организации обычно полагаются на крупномасштабные тесты и группы тестировщиков для их проверки.
Пути пользователя естественным образом охватывают бизнес-процесс и системные функции в сочетании. Таким образом, горизонтальные тесты осуществляют интеграцию между системами и бизнес-процессом.
Вертикальное интеграционное тестирование использует более техническую перспективу; горизонтальное тестирование принимает точку зрения пользователя или бизнес-процесса.
Теперь давайте воспользуемся этими концепциями для построения модели, которая поможет нам понять и спланировать EBPA. Мы будем ссылаться на подходы горизонтальной и вертикальной интеграции в модели.
Модель для интеграции и тестирования
Интеграция — это часто неправильно понимаемое понятие. Процесс интеграции фактически начинается почти сразу после начала написания кода. Можно сказать, что интеграция начинается, когда у нас есть две строки кода — вторая строка кода должна быть интегрирована с первой. Интеграция заканчивается, когда все функциональное тестирование завершается принятием пользователем.
Давайте сосредоточимся на примере использования готовых коммерческих модулей (COTS) и модулей планирования ресурсов предприятия (ERP).
Компания-разработчик программного обеспечения, создающая модули COTS или ERP, провела модульное и функциональное тестирование. Когда эти компоненты прибывают, обычно можно предположить, что они работают и технически интегрированы. Но всегда есть риск непредвиденного взаимодействия интегрированных компонентов от разных поставщиков.
Кроме того, если компоненты настроены, их поведение изменится, и опять же это, вероятно, вызовет тонкие (и не очень) побочные эффекты в другом месте. По-прежнему существует потребность в вертикальной интеграции для проверки обмена данными и элементами управления в стеке технологий, а также в горизонтальной интеграции компонентов и бизнес-процессов.
Мы представляем четыре интеграционных действия в четырехквадрантной модели с двумя осями. По оси X у нас находится масштаб тестируемой системы — либо отдельный компонент или подсистема в отдельности, либо интегрированные системы в контексте бизнес-процесса.
Правая сторона модели окрашена в синий цвет и представляет собой EBPA. Тестирование нашей системы в контексте других систем (SIT) и бизнес-процессов (BIT) — это то, что мы называем гарантией бизнес-процессов предприятия.
Давайте посмотрим на четыре квадранта по очереди.
Тестирование модуля, функции или компонента
Модуль должен быть функционально протестирован независимо от того, является ли он созданным пользователем или компонентом COTS. Пользовательский опыт всегда важен и должен интегрироваться с каким-то шагом или действием в бизнес-процессе.
Интеграционное тестирование подсистемы
Интеграция постепенная. По мере того, как низкоуровневые компоненты и функции становятся доступными, они интегрируются во все более крупную систему и тестируются до тех пор, пока не будет готова полная согласованная система. Мы называем это интеграционным тестированием подсистемы.
Системное интеграционное тестирование (SIT)
Ни одна система не существует изолированно, поэтому, когда наша система завершена, нам нужно интегрировать эту систему с другими системами. Мы устанавливаем нашу систему в среду с ее интерфейсными системами и тестируем эти системы, работающие как «система систем» через эти интерфейсы. Нашей целью на этом этапе является устранение технических рисков интеграции, и мы называем это системным интеграционным тестированием.
Тестирование бизнес-интеграции (BIT)
Существует заключительный этап интеграции, целью которого является обеспечение интеграции готовых систем с бизнес-процессами и (часто выполняемыми вручную) процедурами пользователей этих систем. Включая внешние интерфейсы системы (если они еще не протестированы), мы проверяем, что системы и бизнес-процессы, работающие совместно, обеспечивают согласованное и эффективное взаимодействие пользователей, а также правильное и последовательное управление данными и их передачу. Обычно мы называем это бизнес-интеграционным тестированием.
В оставшейся части этой статьи мы сосредоточимся на горизонтальной стороне модели EBPA.
Горизонтальное тестирование: подход к тестированию E2E
Горизонтальная интеграция больше всего зависит от того, что часто называют сквозным (E2E) тестированием.
E2E-тестирование — это метод разработки тестов, который вызывает серию связанных транзакций, обычно охватывающих несколько систем, включая нашу тестируемую систему (системы). Эти тесты, как правило, отслеживают пути пользователей через их бизнес-процессы.
Учитывая модель бизнес-процесса, пути прослеживаются через процесс для создания полезной серии транзакций, которые имитируют то, как пользователи будут использовать систему в производственной среде.
Эти модели могут быть знакомыми диаграммами, такими как блок-схемы или диаграммы плавательных дорожек, или они могут быть более техническими представлениями, такими как последовательности UML или диаграммы сотрудничества. (UML — это унифицированный язык моделирования, используемый многими ИТ-организациями).
E2E-тесты устраняют определенные риски, которые не могут быть легко устранены путем более раннего тестирования подсистем или сред, которые сильно зависят от заглушенных интерфейсов и чисто синтетических данных.
Принятие
Понятие «соответствие» подходит для интеграции компонент-компонент, интеграции системы-системы и интеграции системы-бизнес-процессов.
Принятие обычно основывается на результатах горизонтальных тестов E2E, поскольку заинтересованные стороны бизнеса могут быть уверены, что эти тесты показывают, насколько новая система подходит и поддерживает их способы работы. Горизонтальные E2E-тесты дают им уверенность в том, что предоставленный сервис будет работать.
Процесс приемки систем обычно зависит от успешного горизонтального E2E-тестирования, по крайней мере частично. Это связано с тем, что только тесты E2E тестируют систему в реалистичной среде и имитируют реалистичную деятельность пользователя.
Во многих организациях только на заключительных этапах тестирования можно продемонстрировать работу систем, и это дает заинтересованным сторонам уверенность в том, что система будет работать должным образом.
Если вас попросят спланировать приемочный тест, мы ожидаем, что метод тестирования E2E сыграет большую роль в вашем планировании.
Интеграционные риски и E2E-тестирование
Как уже говорилось, интеграционные риски связаны с системной интеграцией или системной интеграцией бизнес-процессов.
Некоторые организации предпочитают разделять тесты, направленные на устранение этих двух типов рисков, на тестирование системной интеграции (SIT) и тестирование бизнес-интеграции (BIT). Но часто риски и тесты объединяются в один этап тестирования с пометкой E2E, приемка или бизнес-тестирование.
Как бы ни структурировано тестирование, в нем широко используется описанный выше подход к тестированию E2E. В вашей среде риски, с которыми вы сталкиваетесь, могут быть вариациями этих тем, и вам может потребоваться соответствующим образом скорректировать цель тестирования и подход к тестированию.
Представленный здесь список рисков следует рассматривать только как отправную точку и как напоминание о том, на что следует обратить внимание при проведении тестирования. Вероятно, существуют риски, характерные для вашей организации, отрасли или технологии, которые вам необходимо добавить в этот начальный список.
В приведенной ниже таблице «системы» относятся к набору интегрированных систем, включающих новую систему или разрабатываемые системы, другие унаследованные или инфраструктурные системы, а также внешние системы, например банки или партнерские организации.
| Риск | Цель теста | Тестовый подход |
| Системы не интегрированы (передача данных). | Продемонстрируйте, что системы интегрированы и правильно выполняют передачу данных. | Тест системной интеграции (SIT) |
| Системы не интегрированы (передача управления). | Продемонстрировать, что системы интегрированы (передача управления с требуемыми параметрами осуществляется правильно). | СИДЕТЬ |
| Интерфейсы выходят из строя при использовании в течение длительного периода времени. | Продемонстрируйте, что интерфейсы могут непрерывно использоваться в течение длительного периода времени. | SIT (эти проверки также могут выполняться как часть проверки надежности и/или отказоустойчивости) |
| Системы не интегрированы (данные не согласовываются между интерфейсами). | Продемонстрируйте, что системы интегрированы (данные, передаваемые через интерфейс, используются последовательно, например, валюта, язык, метрики, время, точность, допуски). | СИДЕТЬ |
| Системы не синхронизированы (передача данных не запускается, запускается в неподходящее время или несколько раз). | Продемонстрируйте, что передача данных запускается правильно. | СИДЕТЬ |
| Объекты или сущности, существующие в нескольких системах, не согласуются между системами. | Продемонстрируйте, что состояния бизнес-объектов точно представлены в системах, содержащих данные об объектах. | Тест бизнес-интеграции (BIT) |
| Системы не интегрированы с бизнес-процессом (цепочкой поставок). | Продемонстрируйте, что системы интегрируются с бизнес-процессами и поддерживают процесс цепочки поставок. | НЕМНОГО |
| Внутренние бизнес-процессы не поддерживают веб-интерфейс или мобильный интерфейс. | Продемонстрируйте, что процессы цепочки поставок работоспособны и поддерживают бизнес-цель. | НЕМНОГО |
| Интегрированные системы, используемые одними и теми же сотрудниками, имеют несогласованные пользовательские интерфейсы или поведение для аналогичных или связанных задач. | Продемонстрируйте, что пользователи демонстрируют одинаковое поведение в разных системах при выполнении схожих или связанных задач. | BIT (Эти проверки также могут выполняться во время проверки UX) |
Примечания к таблице рисков
Некоторые из приведенных выше рисков нуждаются в небольшом пояснении.
Проблемы с передачей данных
Часто данные передаются между системами по сетям. Если эти передачи выполняются как пакетные процессы и завершаются сбоем или сбоем как передача в реальном времени, инициируемая пользователем, бизнес-процессом или другим системным событием, то данные будут отсутствовать в целевой системе.
Неправильная передача управления
Передача управления — это когда действие пользователя или системный процесс переводит пользователя или процесс на другую функцию системы.
Обычно существует выбор целевой функции и, в зависимости от действий пользователя или содержания данных транзакции, осуществляется выбор другого маршрута через приложение.
С точки зрения пользователя, они перемещаются в неправильное место в приложении, или системный процесс ожидает выполнения неправильного процесса и теряет синхронизацию.
Данные не согласуются
Система может распространять данные, относящиеся, например, к деньгам или местонахождению активов, или к некоторой физической величине, которая должна «суммироваться» во всех системах.
Например, если 100 единиц запаса куплены и перемещены, проданы, использованы в производственных процессах, признаны неисправными и возвращены или утилизированы, количество единиц, хранящихся в каждой подсистеме, должно совпадать с первоначальным количеством 100 единиц.
Разновидностью этой проблемы являются, например, единицы, используемые в системах хранения данных. Должны учитываться размеры партий или совокупность подсчитанных единиц, или системы должны соответствовать метрическим и имперским единицам измерения и т. д.
Системы не синхронизированы
В связи с описанной выше проблемой передачи данных системные процессы, выполняющие передачу, планируются для выполнения в правильной последовательности, запускаются надлежащим образом авторизованными процессами или людьми и запускаются своевременно и соответствующим событием или сочетанием событий.
Некоторые пакетные процессы должны выполняться ежечасно, ежедневно, еженедельно, в конце месяца, квартала или года и т. д., и их необходимо проверять. Большая часть функционального поведения зависит от относительного времени транзакций или возраста данных в разных системах, и это также необходимо проверять.
Объекты не примиряются
Эти риски связаны не с подсчетом предметов, денег или физических измерений, а со статусом объектов, хранящихся в распределенных системах. Например, статус сотрудника в кадровой документации должен быть согласован во всех системах, в которых хранятся копии этого объекта данных. Процессы, которые распределяют изменения состояния по системам, содержащим копии одного и того же объекта, должны быть запущены, а их действия проверены.
Системы, не интегрированные с бизнесом
Поведение систем должно синхронизироваться с намерениями пользователей. Типичные проблемы возникают, когда система предоставляет неполную, устаревшую или неправильную информацию. Основная причина этого заключается в том, что передача данных или синхронизация работают неправильно, но эти проблемы проявляются через пользовательский интерфейс.
Внутренние процессы не поддерживают внешний интерфейс
Проблема такого рода проявляется в несоответствии между системами регистрации и системами взаимодействия. Внутренние пакетные процессы, которые выполняются недостаточно часто или вообще не делают данные доступными для внешних систем взаимодействия. Точно так же транзакции пользователей через системы взаимодействия не отражаются в системах записи.
Несовместимые пользовательские интерфейсы
Если бизнес или услуга предлагается через мобильные, веб-интерфейсы и киоски, пользовательский интерфейс ведет себя по-разному или непоследовательно. Все они могут быть проверены независимо друг от друга, но их поведение отличается. Например, применяются разные правила проверки ввода, захватываются/отображаются разные поля данных или различается последовательность ввода.
Последние мысли
Мы представили модель интеграции и тестирования, которая уделяет особое внимание интеграции в масштабах предприятия и бизнес-процессу. Подход E2E — единственный, который требует полной системной интеграции и основывает тесты на полных циклах взаимодействия пользователей. Таким образом, заинтересованные стороны могут увидеть свидетельства того, что системы работают правильно в реальном контексте.
Многие организации полагаются на то, что пользователи применяют форму E2E-тестирования в своих приемочных тестах и запускают эти тесты вручную. Исходя из опыта, я выступаю за более систематический подход, основанный на оценке рисков, который упрощает автоматизацию большей части трудоемкого выполнения тестов.
По мере того, как организации внедряют гибкие и более динамичные подходы к разработке с непрерывной доставкой, возлагая на гибкие команды больше ответственности за тестирование своих подсистем, легко пренебречь более поздней интеграцией и приемочным тестированием в масштабах предприятия.
Подход EBPA, особенно если он автоматизирован, расширяет режим непрерывной интеграции с подсистемы на обеспечение бизнес-процессов предприятия.
Пакеты COTS и ERP позволяют внедрять мощные, но сложные системы с меньшими затратами на разработку, но риски интеграции так же очевидны, как и при разработке программного обеспечения на заказ.
В более крупных средах гибкие и непрерывные подходы к доставке становятся все более популярными, поэтому по мере увеличения сложности и масштаба увеличивается частота доставки и связанный с этим риск.
Решение очевидно: организации должны серьезно относиться к EBPA. Им необходимо понимать риски интеграции и то, как структурировать тестирование для их устранения. Тестировщики должны перейти к современному подходу, основанному на моделях, и абстрагировать свои бизнес-процессы, свои системы и тесты, а также систематически внедрять автоматизацию тестирования.
