E2e что это в бизнесе
Сквозное тестирование (end-to-end): особенности и инструменты
Что такое E2E тестирование? Разбираемся с определениями и подбираем инструментарий.
E2E тесты обычно выполняются после всех остальных типов тестирования
У этой записи один комментарий
Понятие еnd-to-end обозначает всего-навсего классификацию тестов по уровню, на котором тестируется система, и, само по себе, ничего не говорит ни о том, какие конкретно должны быть эти тесты, ни о том, какую роль они играют в общей стратегии обеспечения/проверки качества и, также, не является методикой тестирования. (Методика — это совсем другое понятие.)
Для понимания сути этого понятия хорошо сравнить его с модульным («нижний» уровень) и интеграционным («средний») тестированием на каком-нибудь конкретном примере. Давайте рассмотрим некий сферический webshop в вакууме. Предположим, в нем есть 50 классов и для большинства из них написаны модульные тесты. Они проверяют исключительно функционал конкретного модуля (чаще всего, класса), т.е. тот, что зависит только от самого модуля и ни от чего чего более. Потом есть интеграционные тесты. Они проверяют корректность работы отдельных «модулей», если их собрать вместе согласно архитектурe. Например, работает ли правильно «Корзина», состоящая, в свою очередь, из 10 классов (предварительно проверенных модульными тестами), или «Корзина», подключенная к «Вебморде» и т.д. Где-то повыше в этой иерархии есть такие интеграционные тесты, которые проверяют конкретный функционал всей системы. Например, отправляется ли юзеру мейлом копия оплаченного заказа…
И вот тут начинается самое интересное для понимания того, что такое end-to-end тестирование! Можно представить себе тест, проверяющий, что соответствующий мейл генерируется и сбрасывается SMTP серверу. Если SMTP сервер не рассматривать, как часть разрабатываемой системы, то этот тест вполне можно назвать end-to-end тестом (послали кучку HTTP запросов через «Вебморду» и проверили сброс мыла на SMTP — все зашибись!). Однако, если настройки и эксплуатация SMTP сервера — часть проекта (например, заказана разработка webshop «под ключ»), может оказаться, что это мыло будет отфильтровано каким-нибудь спам-фильтром, превысит лимит почтового ящика пользователя… короче, не дойдет до него. Тогда этот же самый тест уже нельзя считать end-to-end, а нужно бы было написать тест, проверяющий приход мыла в POP3/IMAP ящик. (Опять же, если это действительно нужно! Ибо, в зависимости от конкретных функциональных и нефункциональных требований, архитектор и QA инженер вполне могут найти возможность обеспечить адекватный контроль качества и без такого теста.)
Таким образом, end-to-end тесты, это такие интеграционные тесты, которые воздействуют на систему через ее самые внешние интерфейсы и проверяют ожидаемую реакцию системы через эти же интерфейсы. Почему именно интеграционные? Потому, что это единственное, что можно о них сказать наверняка: они по определению не могут быть модульными тестами. А все остальное: являются ли они одновременно приемочными, нагрузочными или еще какими — зависит только от общих плана/стратегии тестирования и той роли, которые эти тесты в них играют.
Про пользу E2E тестирования
В пирамиде тестирования End-to-End (E2E) тесты занимают одну из верхних ступеней. Написав один E2E тест, можно быть уверенным в результатах работы логики приложения, проверить интеграции с другими системами и создать «контракт» для вашего приложения.
К сожалению, многие из коллег, с которыми я работал, не писали E2E тесты. Отчасти потому что с головой ушли в модульное тестирование и посчитали, что оно лучше по ряду причин, включая моду на TDD. Отчасти потому что верили, что E2E тесты сложно писать, они долго исполняются, да и с инструментарием есть проблемы.
Разберемся с этими мнениями и посмотрим на плюсы, которые предлагает E2E тестирование.
Терминология
Под E2E тестами положим вид автотестов. Эти автотесты должны покрывать все функции сервиса с точки зрения клиента. Добиваются они этого, симулируя реальное взаимодействие клиента, будь это HTTP-запрос или нажатие на кнопку в UI.
Подход модульного тестирования лучше
Написание модульных тестов, по моему опыту, занимает куда больше времени, чем E2E тестов. Да, на первых порах придется разобраться как E2E тесты лучше писать, но ведь то же было верно и для модульных тестов.
Зато, в результате один E2E тест покрывает больше кода, чем один Unit-тест, хотя может занимать меньшее количество строк по сравнению с аналогичным модульным test suite.
Можно не тратить время на понимание того, как правильно мокировать зависимости, ведь ими становятся в E2E тестах внешние системы, а взаимодействие с тестируемым сервисом строится по принципу «черного ящика».
Не нужно проверять все граничные условия для отдельного метода класса. Это повышает гибкость работы с кодом, так как нет необходимости рефакторить весь test suite при малейшем изменении внутренней логики работы приложения.
Невозможно попасть в ситуацию, когда ты боишься выкинуть старый код, потому что придется пройтись по набору из 100 модульных тестов (написанных даже не тобой), которые так или иначе были завязаны на этот код.
Инструментарий и скорость прогона тестов
На сегодняшний день большинство backend-разработчиков пишут сервисы, представляющие API с помощью HTTP (возможно GraphQL) или некоторым подобием MQ. В таком случае достаточно обычного клиента HTTP, доступного в большинстве mainstream ЯП.
Frontend-разработчики пишут, в основном, для Web-платформ (браузеров) или для мобильных в виде нативных приложений. Тут ситуация немного сложнее, так как инструментарий требует более детального изучения, но не дольше любого остального инструмента, с которым Вам придется столкнуться при разработке приложений.
E2E тесты действительно требуют в среднем больше времени для прогона, нежели модульные. При этом они завязаны на скорость работы Вашей системы. Т.е. они становятся метрикой производительности отдельных операций. При необходимости, они могут просто преобразовываться в нагрузочные тесты.
Дополнительные плюсы E2E тестирования
Каждый отдельный тест покрывает реальный сценарий использования приложения и дает куда больше понимания другим разработчикам, в том числе и будущим, как именно и зачем все это работает.
По результатам работы Вы получаете «настоящий» code-coverage. Если есть код и его невозможно исполнить, выполняя клиентские запросы в реальном окружении, то, скорее всего, это лишний код. Если он проверяет граничные условия или ловит маловероятный exception, задумайтесь, возможны ли такие условия в принципе?
В целом, использование только E2E тестирования для приложения заставляет задуматься об упрощении структуры Вашей системы и улучшения документации.
E2E тесты могут использоваться как контракты API и взаимодействия с Вашим сервисом. К примеру, для backend, как только Ваш E2E тест меняется, необходимо убедиться, что frontend будет готов к таким изменениям.
Заключение
В целом, на мой взгляд, E2E тестирование предоставляет большие гарантии корректной работы системы, чем unit-тесты, большую гибкость в работе с кодом с точки зрения рефакторинга и отражает реальную суть работы приложения.
Спасибо Вам за внимание! А как Вы считаете, можно ли использовать только E2E тесты?
E2e что это в бизнесе
Понятия B2B и B2C всем давно известны. А вот значение аббревиатуры E2E, как показывает практика, знают далеко не все. Если вы нашли себя в числе этих «не всех», предлагаем разбираться вместе.
Итак, E2E сокращение с английского «End-to-end»*.
*Стоит упомянуть о том, что в мире информационных технологий существует и другое значение аббревиатуры, также имеющее расшифровку «end-to-end», однако связанное со сквозной передачей данных. Говоря об IT решениях, важно знать контекст, чтобы не перепутать одно с другим.
В обиход введено несколько лет назад Джеймсом Славетом, партнером Greylock Partners, который является инвестором компаний Airbnb и Redfin.
И обозначает собственно направление бизнеса, когда некий товар/услуга/ценность предоставляемый некоторым количеством продавцов доносится до конечного потребителя с помощью специального софтверного продукта (web-площадки, приложения) агрегирующей первых со вторыми. Такая площадка и будет представлять E2E бизнес. Употребляя термин «ценность», имеем в виду то, что объектом обмена могут быть не только товар или услуга, но также и отношения между людьми (сайты знакомств, к примеру).
Теперь о главном, откуда же собственно берутся деньги? Путей несколько, вот они:
Обычно в разном процентном соотношении одновременно работают сразу несколько схем. Е2Е проекты воплощают идеал силиконовой долины, когда сравнительно небольшая группа людей создает массово востребованный продукт.
Несмотря на то, что сейчас принято говорить о Uber и Airbnb, как о флагманах E2E, все-таки само явление в бизнесе появилось гораздо раньше. Предлагаем вспомнить о том, что booking.com был основан почти за десятилетие до нашумевшего Uber.
Другой момент, что само понятие E2E, как течения в бизнесе, появилось гораздо позже, благодаря вышеупомянутому инвестору Airbnb.
Своим стремительным ростом E2E компании сильно обязаны росту и распространению смартфонов. Телефон – кнопка, с помощью которой можно управлять жизнью. Мы вызываем такси, заказываем еду, обмениваемся информацией, перекидываем деньги на счетах в банках, общаемся. Почти весь наш офлайн управляем в онлайн. Просто представьте, что Вам будет обиднее потерять кошелек или телефон?
Если несколько лет назад можно было говорить о стремительном росте E2E, и нарастающей популярности подобных сервисов, то сегодня мы уже можем смело говорить о захвате ими рынков. Вспомните, давно ли Вы ловили частника, чтобы доехать до дома? Уже растет поколение потребителей, которым неведомо слово «бомбила». У людей появляются мысли отказаться от личного автомобиля в пользу такси из соображений экономии, потому что цены на такси действительно резко упали, благодаря агрегаторам.
Специфика Е2Е такова, что успех – это бесперебойная работа приложения, правильный маркетинг и исключительная гибкость по отношению к клиенту. Возможность оперативно меняться под его запросы.
Это, безусловно, здорово для клиента, но хотелось бы все-таки посмотреть на это все с точки зрения сервиса для HR, где в едином пространстве подобного сервиса можно будет найти услуги по рекрутменту, обучении, оценке и пр.
Итак, первый очевидный вывод, на котором не буду останавливаться долго: разработчики, которых уже дефицит, будут востребованы еще больше. IT рекрутмент будет самой быстро оборачиваемой частью рынка человеческих ресурсов. Хорошие IT рекрутеры будут наиболее высокооплачиваемыми специалистами нашей отрасли.
А вот, что же будет с рынком подбора персонала? Логика и интуиция кричат примерно о следующем: сейчас в Москве более 1000 зарегистрированных кадровых агентств и несметное количество фрилансеров. Несомненно, есть крупные игроки, но большинство агентств очень маленькие. А вот теперь давайте представим, что появляется агрегатор, который собирает в себе все эти агентства с одной стороны и компании, готовые обратиться за помощью с другой. Теперь HR менеджеру или руководителю компании не надо тратить время на встречи с представителями агентств, чтобы понять экспертизу, не надо затевать скачки, заключая договора с 5 провайдерами одновременно. Он просто набирает в приложении отрасль, название вакансии, и программа выдает агентство, которое успешно закрывало похожий проект. Вот так, одним кликом.
Есть уже попытки создания подобных сервисов, но пока не такие успешные. Мы уверенны, что это вопрос времени и того, кто первый создаст надежный агрегатор и грамотно выведет его на рынок.
На этом поставим запятую, и вернемся к теме через несколько лет, а может и меньше. Ниже вкратце рассказываем о некоторых E2E компаниях.
«Однажды вечером, в 2008 году, в Париже во время снегопада Трэвис Каланик и Гэррет Кэмп не могли поймать такси. Тогда им и пришла в голову простая идея — нажал кнопку и поехал».
Так красиво историю о себе начинает сама компания.
А вот информация про компанию с сайта ХабраХабр.ру
В 2009 году они вместе с Калаником создали Ubercab — мобильное приложение, позволявшее одним кликом вызывать личного водителя. Тогда сервисом пользовались друзья в Сан-Франциско, мало кто относился к нему серьёзно. Когда Камп спросил Каланика, будет ли он заниматься им постоянно, тот ответил отрицательно — полностью посвящать себя такой авантюре было рискованно.
Год назад основателя Трэвиса Каланика обвинили в краже идеи и технологий. Якобы Кевин Халперн из Калифорнии создал прототип сервиса для заказа такси через мобильное приложение много лет назад. Предприниматель требовал возместить ущерб на сумму в один миллиард долларов.
Халперн утверждал, что свой прототип он разработал еще в 2002 году, в своей компании Celluride Wireless. Они познакомились с Калаником в 2006 году. Тогда Халперн и продемонстрировал ему свои наработки. Каланик якобы воспользовался ими для создания собственного проекта. Заслуживает внимания упоминание об их повторной встрече в 2008 году. Именно тогда он раскрыл Каланику детали проекта. А через год после этого был запущен сервис Uber. Представители компании убеждены, что претензии безосновательны.
О будущем Ubercab много спорили. Одни говорили, что сервис нужно сфокусировать на сегменте люкс, добавив функции заказа вертолётов и самолётов. Другие предлагали делать Ubercab массовым, позволяющим ездить на дорогих чёрных машинах дешевле, чем в целом по рынку. Так считал и Каланик. Он рассуждал: «Чем больше людей захотят этим пользоваться, тем больше водителей будет готово предоставить такие услуги. Конкуренция вырастет, стоимость снизится, а время подачи машины уменьшится».
Родители Трэвиса Каланика были первыми пассажирами Uber, запустившегося в Лос-Анджелесе.
В настоящий момент, кроме Убер, существуют несколько десятков более ли менее известных такси-сервисов такого рода, однако, несмотря на критику по определенным вопросам, Уберу удается удерживать одни из самых низких цен, что позволяет быть выше конкурентов. AirBnB
Еще одна всемирно известная компания AirBnB, (изначально AirBed&Breakfast — «надувной матрас и завтрак»).
Пользователи Airbnb имеют возможность сдавать путешественникам в аренду своё жильё целиком или частично. Сайт предоставляет платформу для установления контакта между хозяином и гостем, а также отвечает за обработку транзакций. Airbnb предлагает жильё в 65 000 городов 191 страны мира. С момента основания в августе 2008 года и до апреля 2017 года через сайт Airbnb нашли жильё более 150 млн человек. За свою деятельность Airbnb взимает определённый процент — с хозяев апартаментов 3 % от суммы бронирования, с арендатора — от 6 % до 12 % (по данным на апрель 2017 года).
Airbnb был основан в августе 2008 года в Сан-Франциско. Его основателями являются Брайан Чески, Джо Геббиа и Нейтан Блечарчик. Первоначальное финансирование было получено от бизнес-инкубатора Y Combinator. Позднее Greylock Partners, Sequoia Capital и Эштон Кутчер также инвестировали в компанию.
Кроме штаб-квартиры в Сан-Франциско, компания имеет 10 региональных офисов: в Барселоне, Берлине, Гамбурге, Копенгагене, Лондоне, Милане, Париже, Сан-Паулу, Сингапуре и Сиднее.
Перед Гран-при Канады компания стала спонсором команды Manor Marussia F1 Team.
Хочется сказать о ней, как о компании появившейся значительно раньше понятия E2E.
В 1996-м компания Microsoft запустила сайт для бронирования отелей и авиабилетов Expedia.com. Основатель корпорации Билл Гейтс впоследствии сказал, что предвидел: интернет-пользователи захотят самостоятельно, безо всяких посредников планировать и подготавливать путешествия.
В то же самое время в Голландии выпускник факультета технического администрирования Университета Твенте Герт-Ян Бруинсма обзванивал гостиницы в европейских городах и просил их прислать ему по обычной почте рекламные буклеты с фотографиями номеров. Отсканированные изображения он выкладывал на сайт Bookings.nl. Через несколько лет ресурс стал недосягаемым лидером онлайн-рынка туризма.
Сервис Omnipresenz задуман, как для вечно занятых людей, у которых нет времени путешествовать или посещать встречи в других городах мира, так и для тех личностей, кому физическое состояние не позволяет покорять новые страны, к примеру, для стариков или инвалидов. Ведь зачем ехать в Венецию, если вы можете связаться с человеком, уже находящимся в этом городе, и попросить его прогуляться вдоль каналов с онлайн-камерой на голове.
Вопрос равноценности онлайн и офлайн путешествий, безусловно, спорный, но факт в том, что сервис существует и существует спрос на него.
End-to-end или E2E-процесс: что это? Сквозное тестирование
и другие поведенческие факторы.
К примеру, компания Гугл при разработке своих продуктов следует правилу «70-20-10», цифры которого показывают процентное соотношение от общего количества тестов, то есть:
70% занимают юнит-тесты;
20% занимают интеграционные тесты;
Нет единого алгоритма сквозного тестирования, так как многое будет зависеть от сложности самого проекта и что конкретно нужно тестировать. Е2Е — это лишь название процесса тестирования, а не его метод или алгоритм. Но при этом выделяют два основных типа сквозного тестирования, на которых мы немного остановимся.
Любой сквозной тест — это:
в первую очередь тестирование UI;
тяжелый и медленный тест;
применение метода «черного ящика» и найм сторонних тестировщиков, никак не связанных с разработкой программы;
тяжелый «отлов» найденной проблемы;
тестирование всех модулей и всех систем целиком, поэтому требуется сложный и эффективный софт или работа «руками»;
Заключение
нагрузку на каждый трос или балку;
поведение моста при наводнении, землетрясении, пожаре или аварии на нем;
Мы будем очень благодарны
если под понравившемся материалом Вы нажмёте одну из кнопок социальных сетей и поделитесь с друзьями.
Сквозное тестирование (end-to-end): что, зачем, почему
Тестирование в больших компаниях, в enterprise, чаще всего дело сложное и неблагодарное. Разрыв между бизнес-подразделениями и IT огромный: когда разработчик имеет видение на уровне кода, а проверку – на уровне модульных тестов, а заказчик мыслит работающими или неработающими даже не услугами, а целыми процессами, выходящими за рамки одной команды разработки, а то и целого подразделения\компании. И просит организовать бизнес-тестирование, или сквозное тестирование, или тестирование на основании сценариев от начала и до конца (end 2 end).
Давайте начнём с самого начала – с двух столпов, откуда появилось это пресловутое «сквозное бизнес-тестирование», а именно с пирамиды тестирования и со стандарта ISO9000.
Пирамида тестирования
С пирамидой тестирования, наверняка знаком любой тестировщик, поднаторевший в своей профессии и набившей шишек при общении со смежными подразделениями. Особенно часто к ней приходится апеллировать при обосновании автоматизации тестирования. Какие тесты дешевле и важнее разработать? А запустить?
Суть пирамиды тестирования не хитрая: в основе тестирования следует использовать самые простые и самые быстрые в написании и исполнении тесты – модульные тесты. Конечно, проверка интерфейсов классов и функций вряд ли та вещь, которую можно показать заказчику, но без этого прочного, монолитного, безотказного фундамента вряд ли что-то получится выстроить выше. Как правило несколько десятков функций, методов, классов реализуют какую-либо функциональность для заказчика, и по сути десяток модульных тестов можно свести к каким-то верхнеуровневым тестам. Заказчику нужна уже красивая квартира с отделкой, но при этом вряд ли он останется довольным, когда перекошенные окна в его квартире перестанут открываться, а пол и потолок пойдёт трещинами от первого подувшего ветерка. Однако самому заказчику зайти в квартиру и проверить её качество может быть не самой лучшей идеей. Согласитесь, сложно пользователю проверить качество бетона в фундаменте, так и воспроизвести все погодные условия. Так и в тестировании, конечно, верхнеуровневое тестирование нужно, то только тогда, когда у нас отработали модульные тесты, так и тесты уже более высокого уровня.
Сложнее в разработке и дольше в исполнении более высокоуровневые тесты – интеграционные тесты, которые проверяют корректность работы одновременно работающих модулей, над которыми трудилась вся команда, выпуская свой продукт (систему). То есть проверяется интеграция кода, тестируется система без учёта взаимодействия со внешними системами. Такие тесты уже подразумевают проверку высокоуровневую, скорее всего через обращение к систему через системное API или даже GUI (фронт). Работа с таким типом тестов сложнее – чтобы покрыть все ветки и нюансы кода нужно, скорее всего, задействовать большое количество сильно пересекающихся проверок на различных тестовых данных, а при автоматизации зачастую разрабатывать целый ворох условий и ветвлений в скриптах. То есть, с одной стороны мы уже приблизились к пользователю, усложнив себе жизнь, но с другой стороны, нам ещё сложно находить общий язык, нам это обходится дороже, а качества проверок всё ещё недостаточно. То есть мы можем запустить заказчика в новую квартиру, он может всё проверить, но без учёта взаимодействия с другими жильцами, погодными условиями и коммунальными службами. Согласитесь, толка от идеального мира, модели, в реальной жизни, как правило, немного.
Если мы добавим и эти условия – посмотрим как наша система взаимодействует со внешними системами – поставщиками и потребителями, с нашим окружением, то есть проведём системное тестирование, то легко увидим, что сложность тестирования тоже возрастёт. Нам нужно будет добиваться одновременной работоспособности всех взаимодействующих систем, хотя и без привлечения специалистов по ним. Нам пока что достаточно просто принять какие-то данные от наших поставщиков и передать наши данные нашим потребителям. В правильной последовательности и формате. Дальнейшая судьба данных нас не волнует. Главное – наша система работает правильно в правильном окружении. И всё бы тут хорошо – для нашего заказчика мы можем провести уже полномасштабную демонстрацию, да только в реальной жизни это ещё не все критерии успеха для нашей разработки. Конечно хорошо, что у заказчика появилась его квартира в прочном доме, но если от неё надо добираться, перелезая через колючую проволоку, затем на каноэ по озеру с крокодилами в шалаши, кишащие змеями, то, возможно, мы что-то не то и не там сделали?
Поэтому тут первая идея для сквозного тестирования – проверять не только наше окружение, но и все взаимосвязанные системы, через которые проходят данные принимаемые или отправляемые нашей системой. А это, в свою очередь, означает, что мы должны будем совместить несколько таких «пирамид тестирования» между собой. Постройка хрупкого моста, по которому мы проведём за ручку данные, ценные для пользователя.
Вот только вопрос как это делать? Кому это делать? Как собирать воедино?
ISO9000
Серия стандартов, описывающих системы менеджмента качества, в том числе говорит о том, что любой процесс в организации должен быть описан, задокументирован, даже если это процесс выдачи граблей по осени дворнику. А раз так, что ни один процесс, который проходит внутри ПО, используемого и разрабатываемого в организации, не может не быть описан. Вопрос в том, как это делать? Конечно, лучшее описание, с точки зрения BDD — это описание поведения тестами, под которыми будет лежать пирамида тестирования. Но мы сразу же вернёмся к нашей дилемме с объединением нескольких пирамид тонкими канатами от верхушки к верхушке, по которым без страховки будет ходить наш канатоходец-заказчик и его пользователи.
Process approach is a management strategy that requires organisations to manage its processes and the interactions between them. Thus you need to consider each major process of the company and their supporting processes.
All processes have:
• inputs;
• outputs;
• operational control;
• appropriate measurement & monitoring.
Each process will have support processes that underpin and enable the process to become realised
Для этой цели лучше всего подходят бизнес-диаграммы, и чаще всего используются стандарты вроде UML, BPMN, ARIS и пр. А сами процессы становятся блок-схемами с нанизанными на них «кубиками». Между «кубиками» происходит взаимодействие, в стандарте BPMN — это поток действий и поток сообщений. И вот это как раз то, что нам нужно!
Любая компания, которая хочет иметь сертификат и следует стандарту ISO9000, скорее всего, обзавелась такими схемами, и они являются неотъемлемой частью верхнеуровневых требований. Если в компании работают хорошие аналитики, то, скорее всего, к низкоуровневым требованиям будут спускаться ссылки-требования на отдельные действия из схем. Они-то нам и нужны.
Фактически, на схемах мы можем увидеть процесс целиком, и понять, какой сценарий нам нужно построить, и к какой системе\команде бежать с какими данными в какой момент.
Я тут не преуменьшаю труд разработчиков, которые пишут грамотный код, который пересылает сообщения между разными частями программно-аппаратных комплексов, но всё держать в уме невозможно. И когда процесс используется во множестве других процессов, лучше иметь такую «карту» при себе для проведения грамотного тестирования, и, тем более для построения тестовой модели.
Что на практике
Итак, мы имеем две вводных – у каждой команды\системы должна быть подготовлена пирамида из тестов – от самых мелких, модульных тестов, до сложных системных тестов, а так же тот факт, что в рамках организации у нас обязаны быть описаны требования в виде бизнес-процессов. Этот факт нам позволит быстро ответить заказчику, какой бизнес-процесс как работает, и на каком моменте из-за чего ломается, а самим, при получения дефектов с промышленной эксплуатации быстро произвести root cause analysis (анализ корневых причин возникновения дефектов). В теории.
А на практике всё опять ложится на тестировщика – как из вороха тестов, тем более чужих, выбрать нужные, выстроить их в цепочку, а на вход каждой из систем подать нужные данные и сверить с корректно определённым ожидаемым результатом?
Самый простой вариант – изначально разрабатывать тесты на основании бизнес-моделей, а деление команд делать по проектам, реализующим тот или иной бизнес-процесс. Для этого в некоторых инструментах управления тестированием есть уже возможность загружать BPMN-схемы (например для HPE ALM – поддерживается загрузка в формате XPDL). HP ALM сам разобьет схему на набор требований (действий), а при желании создаст иерархию требований (модуль Requirements->Business Models). Далее наше дело покрыть требования тестами, а далее выстроить требования, а значит и тесты в цепочки, покрывающие наш бизнес-процесс. Эти цепочки в HPE ALM называются «путями» (path), и позволяют увидеть все комбинации последовательностей. При желании требования, цепочки можно сразу сконвертировать в тесты.
Но даже если не использовать инструменты тестирования, всё равно придётся из бизнес-процесса составлять цепочки. Тем более учитывая несовершенство инструментов (не всё так радужно), а так же тот факт, что, скорее всего, тестовую модель нужно будет собирать пост-фактум, а исполнять и вовсе в виде регресса «общей командой», не прилепленной к новым проектам.
Сколькими путями может дойти белочка до шишки?
В этом случае нам нужно будет открыть тесты каждой из команд, найти привязанные к фигурирующим в бизнес-модели требованиям, и выстроить из них цепочки, сохранив в «общем пространстве». Создание общего пространства – это какой-то суррогат, но в любом случае оно должно быть, пусть в виде амбарной книги, excel, или проектной области в инструменте управления тестированием. Если снова говорить о HPE ALM, то за данный функционал отвечает модуль BPT (Business Process Testing), заодно позволяющий передавать результаты одного теста в параметры другого. Впрочем, при желании и упорном труде на HPE ALM это возможно и реализовать через перестроения тестовых наборов (Test set) в поток выполнения (Execution flow). Тогда при запуске полного набора будут по очереди вызываться тестировщики, ответственные за прохождения каждой из компонент сквозного сценария.
И, увы, одним лишь средством управления тестирования не обойтись. Из моей практики, почти что все инструменты имеют какие-то фатальные недостатки, и поэтому, если вы дойдёте до этапа автоматизации тестирования по бизнес-процессу – то придёте к созданию скрипта, который будет дёргать в нужной последовательности тесты.
В итоге, можно сделать два вывода:
1) для сквозных сценариев используются с большой долей вероятности уже ранее разработанные тесты для каждой из систем, входящей в цепочку (сценарий) бизнес-процесса
Можно все полные тестовые наборы компании представить в виде разреженной матрицы, где по столбцам распределены тесты для каждой системы (для простоты – системные), а по строкам – бизнес-процессы. То есть для тех или иных бизнес-процессов надо выбрать\создать тесты, покрывающие бизнес-процесс, установить взаимосвязи. Если покрытия нет – это повод восполнить пробелы в тестовой модели, либо удостовериться, что качество обеспечивается другими уровнями тестирования (интеграционное тестирование, модульное тестирование, ревью кода и прогон его через анализаторы).
2) Необходим инструмент наблюдения, трассирования и актуализации бизнес-процесса на предмет синхронизации с тестовой моделью.
И если с созданием тестовой модели инструменты тестирования более-менее сносно справляются, то с актуализацией всё в действительности очень плохо, зачастую проще модель пересоздать заново, чем пытаться увидеть изменения в процессе и тестовой модели. И опыт реальных команд говорит о том, что лучше создавать живую визуализацию архитектуры. Проще всего это сделать в общей зоне, воспользовавшись простой маркерной доской и стикерами. Тогда, команды, которые участвуют в бизнес-процессе могут наглядно видеть, как видоизменяется процесс (убираются и добавляются связи, убираются и добавляются действия). Главное – чтобы все имели доступ к доске. Плюс, обратите внимание, что если в процессе подразумевается сообщений между системами, то, как правило, хотя бы должно быть два теста от каждой системы – на отправку и на приём данных. Впрочем, вместо стикеров можно использовать целый лего-город (из крупных блоков), или что-то ещё более креативное. Главное тут – один язык и одно информационное пространство, чего очень в enterprise не хватает.
В заключение
Организация наглядного и правильного тестирования по бизнес-процессам – сложная и очень дорогая вещь. Обратите внимание, что E2E тестирование – это не просто приёмка, пользовательское тестирование, которое будет выполнять заказчик, это выстраивание мостика, с учётом всех возможных ситуаций, по которому пойдёт заказчик и поведёт за собой в ногу пользователей.
Ещё раз – E2E – это не прогулка на Ладе-Калине через мост, и даже не проезд на двух камазах. Это сложная инженерная работа, обвешивание мостов датчиками и проведение всех возможных проверок и ситуаций — по крайней мере описание этих сценариев.
Нужно или нет вашей компании такой идеальный чистовой прогон – дело исключительно ваших целей и потребностей. Всегда, как и при любом тестировании, следует оценить потенциальные риски от пропущенных дефектах на этой стадии, так и стоимость работ по подготовке и проведения сквозного тестирования. Оценить, что из этого обойдётся вам дороже и только потом действовать. Но в случае сквозного тестирования по бизнес-процессам следует помнить, что оно не имеет смысла без прочного фундамента в виде 100% passrate unit-тестов (
90-100% coverage), без интеграционных тестов (
60-80% coverage, 90-100% passrate), без системных тестов (20-40% coverage, 80-100% passrate). Устанавливать критерии успешности (quality gates) – это больше требования к качеству выпускаемого продукта, главное здесь помнить, что объем E2E тестов – лишь верхушка пирамиды (1-2% coverage,
99% passrate), которая не должна быть больше его основания, не быть при этом затычкой дыр с предыдущих этапов. Это – дополнение, которое априори считается закрытым на предыдущих этапах.
Организация подобного тестирования – главным образом работа по подготовке и синхронизации тестовых случаев и данных (тест-аналитика), а так же комплекс организационных мероприятий, синхронизация команд в одном месте в одно время на работоспособном тестовом полигоне. Помня это, не следует пробовать показывать заказчику «сквозное тестирование» раньше срока, чтобы не тратить время сразу большого количества людей без всех работающих компонентов, собранных воедино.