End-to-End
End-to-end simply refers to every step of a product’s development from start to finish. The phrase can be used to mean a product is ready for launch, i.e. that the roadmap has been achieved, from end-to-end.
But designers can also adopt an end-to-end view of the development journey as a whole. In this instance, designers are not just concerned with the building of the software, they’re also involved in carrying the initial design concept through to launch, and providing ongoing customer support to increase its value.
Once product teams have this they might involve launching an MVP to establish a user base and gather feedback — adding new features and refining performance creates a more efficient, satisfying product over time.
So we can view roadmaps from end-to-end, and teams can be involved in a product’s development from start to finish, but there are other ways to use the phrase "end-to-end", too.
For one: suppliers can be end-to-end. You may have cause to work with an end-to-end marketing agency, that handles everything from advertising ideas right the way through to social media management and performance tracking. You may be an end-to-end supplier yourself, delivering the full breadth of a product or service, without the support of third-party vendors.
We can view the user experience from end-to-end also. In fact, understanding the holistic user journey from first exposure to your product to — hopefully! — loyal advocacy can nurture a more meaningful partnership, increasing lifetime value and commercial results.
End to end что означает
Понятия B2B и B2C всем давно известны. А вот значение аббревиатуры E2E, как показывает практика, знают далеко не все. Если вы нашли себя в числе этих «не всех», предлагаем разбираться вместе.
Итак, E2E сокращение с английского «End-to-end»*.
*Стоит упомянуть о том, что в мире информационных технологий существует и другое значение аббревиатуры, также имеющее расшифровку «end-to-end», однако связанное со сквозной передачей данных. Говоря об IT решениях, важно знать контекст, чтобы не перепутать одно с другим.
В обиход введено несколько лет назад Джеймсом Славетом, партнером Greylock Partners, который является инвестором компаний Airbnb и Redfin.
И обозначает собственно направление бизнеса, когда некий товар/услуга/ценность предоставляемый некоторым количеством продавцов доносится до конечного потребителя с помощью специального софтверного продукта (web-площадки, приложения) агрегирующей первых со вторыми. Такая площадка и будет представлять E2E бизнес. Употребляя термин «ценность», имеем в виду то, что объектом обмена могут быть не только товар или услуга, но также и отношения между людьми (сайты знакомств, к примеру).
Теперь о главном, откуда же собственно берутся деньги? Путей несколько, вот они:
- % взимаемый с конечных пользователей, как например, в случае с такси-сервисами, где доход получаемый от поездки таксист делит с компанией-агрегатором;
- может также существовать некая фиксированная абонентская плата для одной из заинтересованных сторон (например, как Avito, Pomogatel.ru);
- компания может зарабатывать с помощью дополнительных платных опций (вышеупомянутые сайты знакомств, функция выделения поднять объявление на авито и пр.);
- ну, и традиционную продажу рекламного пространства также никто не отменял.
Обычно в разном процентном соотношении одновременно работают сразу несколько схем. Е2Е проекты воплощают идеал силиконовой долины, когда сравнительно небольшая группа людей создает массово востребованный продукт.
Несмотря на то, что сейчас принято говорить о Uber и Airbnb, как о флагманах E2E, все-таки само явление в бизнесе появилось гораздо раньше. Предлагаем вспомнить о том, что booking.com был основан почти за десятилетие до нашумевшего Uber.
Другой момент, что само понятие E2E, как течения в бизнесе, появилось гораздо позже, благодаря вышеупомянутому инвестору Airbnb.
Своим стремительным ростом E2E компании сильно обязаны росту и распространению смартфонов. Телефон – кнопка, с помощью которой можно управлять жизнью. Мы вызываем такси, заказываем еду, обмениваемся информацией, перекидываем деньги на счетах в банках, общаемся. Почти весь наш офлайн управляем в онлайн. Просто представьте, что Вам будет обиднее потерять кошелек или телефон?
Если несколько лет назад можно было говорить о стремительном росте E2E, и нарастающей популярности подобных сервисов, то сегодня мы уже можем смело говорить о захвате ими рынков. Вспомните, давно ли Вы ловили частника, чтобы доехать до дома? Уже растет поколение потребителей, которым неведомо слово «бомбила». У людей появляются мысли отказаться от личного автомобиля в пользу такси из соображений экономии, потому что цены на такси действительно резко упали, благодаря агрегаторам.
Специфика Е2Е такова, что успех – это бесперебойная работа приложения, правильный маркетинг и исключительная гибкость по отношению к клиенту. Возможность оперативно меняться под его запросы.
Это, безусловно, здорово для клиента, но хотелось бы все-таки посмотреть на это все с точки зрения сервиса для HR, где в едином пространстве подобного сервиса можно будет найти услуги по рекрутменту, обучении, оценке и пр.
Итак, первый очевидный вывод, на котором не буду останавливаться долго: разработчики, которых уже дефицит, будут востребованы еще больше. IT рекрутмент будет самой быстро оборачиваемой частью рынка человеческих ресурсов. Хорошие IT рекрутеры будут наиболее высокооплачиваемыми специалистами нашей отрасли.
А вот, что же будет с рынком подбора персонала? Логика и интуиция кричат примерно о следующем: сейчас в Москве более 1000 зарегистрированных кадровых агентств и несметное количество фрилансеров. Несомненно, есть крупные игроки, но большинство агентств очень маленькие. А вот теперь давайте представим, что появляется агрегатор, который собирает в себе все эти агентства с одной стороны и компании, готовые обратиться за помощью с другой. Теперь HR менеджеру или руководителю компании не надо тратить время на встречи с представителями агентств, чтобы понять экспертизу, не надо затевать скачки, заключая договора с 5 провайдерами одновременно. Он просто набирает в приложении отрасль, название вакансии, и программа выдает агентство, которое успешно закрывало похожий проект. Вот так, одним кликом.
Есть уже попытки создания подобных сервисов, но пока не такие успешные. Мы уверенны, что это вопрос времени и того, кто первый создаст надежный агрегатор и грамотно выведет его на рынок.
На этом поставим запятую, и вернемся к теме через несколько лет, а может и меньше. Ниже вкратце рассказываем о некоторых E2E компаниях.
- Компания Uber известная своим феноменальным взлетом, а также неоднозначной репутацией.
«Однажды вечером, в 2008 году, в Париже во время снегопада Трэвис Каланик и Гэррет Кэмп не могли поймать такси. Тогда им и пришла в голову простая идея — нажал кнопку и поехал».
Так красиво историю о себе начинает сама компания.
А вот информация про компанию с сайта ХабраХабр.ру
В 2008 году Каланик встретился на одной из конференций с основателем сервиса StumbleUpon Гарретом Кэмпом. Тот рассказал, как в Новый год нанял с друзьями лимузин с водителем за $800. Кэмпу цена показалась грабительской. Ему в голову пришла идея разработать приложение, которое позволит делить машину с другими желающими из Кремниевой долины.
В 2009 году они вместе с Калаником создали Ubercab — мобильное приложение, позволявшее одним кликом вызывать личного водителя. Тогда сервисом пользовались друзья в Сан-Франциско, мало кто относился к нему серьёзно. Когда Камп спросил Каланика, будет ли он заниматься им постоянно, тот ответил отрицательно — полностью посвящать себя такой авантюре было рискованно.
Год назад основателя Трэвиса Каланика обвинили в краже идеи и технологий. Якобы Кевин Халперн из Калифорнии создал прототип сервиса для заказа такси через мобильное приложение много лет назад. Предприниматель требовал возместить ущерб на сумму в один миллиард долларов.
Халперн утверждал, что свой прототип он разработал еще в 2002 году, в своей компании Celluride Wireless. Они познакомились с Калаником в 2006 году. Тогда Халперн и продемонстрировал ему свои наработки. Каланик якобы воспользовался ими для создания собственного проекта. Заслуживает внимания упоминание об их повторной встрече в 2008 году. Именно тогда он раскрыл Каланику детали проекта. А через год после этого был запущен сервис Uber. Представители компании убеждены, что претензии безосновательны.
О будущем Ubercab много спорили. Одни говорили, что сервис нужно сфокусировать на сегменте люкс, добавив функции заказа вертолётов и самолётов. Другие предлагали делать Ubercab массовым, позволяющим ездить на дорогих чёрных машинах дешевле, чем в целом по рынку. Так считал и Каланик. Он рассуждал: «Чем больше людей захотят этим пользоваться, тем больше водителей будет готово предоставить такие услуги. Конкуренция вырастет, стоимость снизится, а время подачи машины уменьшится».
Родители Трэвиса Каланика были первыми пассажирами Uber, запустившегося в Лос-Анджелесе.
В октябре 2011-го Каланик привлёк к проекту внимание ведущих венчурных инвесторов, включая сооснователя Netscape Марка Андриссена, который вошёл в совет директоров сервиса. Шервин Пишевар из Menlo Ventures купил долю и инвестировал $20 миллионов. В сервис вложился Джефф Безос, глава Amazon. Uber стали пользоваться голливудские звёзды, с которыми Каланик был знаком: Эштон Катчер, Jay Z, Эдвард Нортон и другие.
Благодаря этому Uber стал известным. За пять лет компания получила $8,21 миллиарда от ведущих венчурных фондов, наняла 3000 сотрудников и открыла офисы в десятках стран. Каланику удалось то, что не удавалось Facebook и Google, — выйти на китайский рынок и завоевать аудиторию, несмотря на сопротивление местных игроков.
В настоящий момент, кроме Убер, существуют несколько десятков более ли менее известных такси-сервисов такого рода, однако, несмотря на критику по определенным вопросам, Уберу удается удерживать одни из самых низких цен, что позволяет быть выше конкурентов. AirBnB
- 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 и Эштон Кутчер также инвестировали в компанию.
Всего с момента основания компании и до апреля 2017 года в проект было инвестировано около $3,4 млрд. Одним из инвесторов стал фонд DST Global российского предпринимателя Юрия Мильнера.
Кроме штаб-квартиры в Сан-Франциско, компания имеет 10 региональных офисов: в Барселоне, Берлине, Гамбурге, Копенгагене, Лондоне, Милане, Париже, Сан-Паулу, Сингапуре и Сиднее.
Перед Гран-при Канады компания стала спонсором команды Manor Marussia F1 Team.
- Booking.com
Хочется сказать о ней, как о компании появившейся значительно раньше понятия E2E.
В 1996-м компания Microsoft запустила сайт для бронирования отелей и авиабилетов Expedia.com. Основатель корпорации Билл Гейтс впоследствии сказал, что предвидел: интернет-пользователи захотят самостоятельно, безо всяких посредников планировать и подготавливать путешествия.
В то же самое время в Голландии выпускник факультета технического администрирования Университета Твенте Герт-Ян Бруинсма обзванивал гостиницы в европейских городах и просил их прислать ему по обычной почте рекламные буклеты с фотографиями номеров. Отсканированные изображения он выкладывал на сайт Bookings.nl. Через несколько лет ресурс стал недосягаемым лидером онлайн-рынка туризма.
- Кроме супер известных компаний, на рынке существует огромное количество менее известных, сфера деятельности многих имеет достаточно узкую аудиторию, а концепция некоторых может даже показаться странной. Расскажем про один из таких проектов.
Сервис Omnipresenz задуман, как для вечно занятых людей, у которых нет времени путешествовать или посещать встречи в других городах мира, так и для тех личностей, кому физическое состояние не позволяет покорять новые страны, к примеру, для стариков или инвалидов. Ведь зачем ехать в Венецию, если вы можете связаться с человеком, уже находящимся в этом городе, и попросить его прогуляться вдоль каналов с онлайн-камерой на голове.
Вопрос равноценности онлайн и офлайн путешествий, безусловно, спорный, но факт в том, что сервис существует и существует спрос на него.
Сквозное тестирование (end-to-end): что, зачем, почему
Тестирование в больших компаниях, в enterprise, чаще всего дело сложное и неблагодарное. Разрыв между бизнес-подразделениями и IT огромный: когда разработчик имеет видение на уровне кода, а проверку – на уровне модульных тестов, а заказчик мыслит работающими или неработающими даже не услугами, а целыми процессами, выходящими за рамки одной команды разработки, а то и целого подразделения\компании. И просит организовать бизнес-тестирование, или сквозное тестирование, или тестирование на основании сценариев от начала и до конца (end 2 end).
Давайте начнём с самого начала – с двух столпов, откуда появилось это пресловутое «сквозное бизнес-тестирование», а именно с пирамиды тестирования и со стандарта ISO9000.
Пирамида тестирования
С пирамидой тестирования, наверняка знаком любой тестировщик, поднаторевший в своей профессии и набившей шишек при общении со смежными подразделениями. Особенно часто к ней приходится апеллировать при обосновании автоматизации тестирования. Какие тесты дешевле и важнее разработать? А запустить?
Суть пирамиды тестирования не хитрая: в основе тестирования следует использовать самые простые и самые быстрые в написании и исполнении тесты – модульные тесты. Конечно, проверка интерфейсов классов и функций вряд ли та вещь, которую можно показать заказчику, но без этого прочного, монолитного, безотказного фундамента вряд ли что-то получится выстроить выше. Как правило несколько десятков функций, методов, классов реализуют какую-либо функциональность для заказчика, и по сути десяток модульных тестов можно свести к каким-то верхнеуровневым тестам. Заказчику нужна уже красивая квартира с отделкой, но при этом вряд ли он останется довольным, когда перекошенные окна в его квартире перестанут открываться, а пол и потолок пойдёт трещинами от первого подувшего ветерка. Однако самому заказчику зайти в квартиру и проверить её качество может быть не самой лучшей идеей. Согласитесь, сложно пользователю проверить качество бетона в фундаменте, так и воспроизвести все погодные условия. Так и в тестировании, конечно, верхнеуровневое тестирование нужно, то только тогда, когда у нас отработали модульные тесты, так и тесты уже более высокого уровня.
Сложнее в разработке и дольше в исполнении более высокоуровневые тесты – интеграционные тесты, которые проверяют корректность работы одновременно работающих модулей, над которыми трудилась вся команда, выпуская свой продукт (систему). То есть проверяется интеграция кода, тестируется система без учёта взаимодействия со внешними системами. Такие тесты уже подразумевают проверку высокоуровневую, скорее всего через обращение к систему через системное API или даже GUI (фронт). Работа с таким типом тестов сложнее – чтобы покрыть все ветки и нюансы кода нужно, скорее всего, задействовать большое количество сильно пересекающихся проверок на различных тестовых данных, а при автоматизации зачастую разрабатывать целый ворох условий и ветвлений в скриптах. То есть, с одной стороны мы уже приблизились к пользователю, усложнив себе жизнь, но с другой стороны, нам ещё сложно находить общий язык, нам это обходится дороже, а качества проверок всё ещё недостаточно. То есть мы можем запустить заказчика в новую квартиру, он может всё проверить, но без учёта взаимодействия с другими жильцами, погодными условиями и коммунальными службами. Согласитесь, толка от идеального мира, модели, в реальной жизни, как правило, немного.
Если мы добавим и эти условия – посмотрим как наша система взаимодействует со внешними системами – поставщиками и потребителями, с нашим окружением, то есть проведём системное тестирование, то легко увидим, что сложность тестирования тоже возрастёт. Нам нужно будет добиваться одновременной работоспособности всех взаимодействующих систем, хотя и без привлечения специалистов по ним. Нам пока что достаточно просто принять какие-то данные от наших поставщиков и передать наши данные нашим потребителям. В правильной последовательности и формате. Дальнейшая судьба данных нас не волнует. Главное – наша система работает правильно в правильном окружении. И всё бы тут хорошо – для нашего заказчика мы можем провести уже полномасштабную демонстрацию, да только в реальной жизни это ещё не все критерии успеха для нашей разработки. Конечно хорошо, что у заказчика появилась его квартира в прочном доме, но если от неё надо добираться, перелезая через колючую проволоку, затем на каноэ по озеру с крокодилами в шалаши, кишащие змеями, то, возможно, мы что-то не то и не там сделали?
Поэтому тут первая идея для сквозного тестирования – проверять не только наше окружение, но и все взаимосвязанные системы, через которые проходят данные принимаемые или отправляемые нашей системой. А это, в свою очередь, означает, что мы должны будем совместить несколько таких «пирамид тестирования» между собой. Постройка хрупкого моста, по которому мы проведём за ручку данные, ценные для пользователя.
Вот только вопрос как это делать? Кому это делать? Как собирать воедино?
ISO9000
Серия стандартов, описывающих системы менеджмента качества, в том числе говорит о том, что любой процесс в организации должен быть описан, задокументирован, даже если это процесс выдачи граблей по осени дворнику. А раз так, что ни один процесс, который проходит внутри ПО, используемого и разрабатываемого в организации, не может не быть описан. Вопрос в том, как это делать? Конечно, лучшее описание, с точки зрения BDD — это описание поведения тестами, под которыми будет лежать пирамида тестирования. Но мы сразу же вернёмся к нашей дилемме с объединением нескольких пирамид тонкими канатами от верхушки к верхушке, по которым без страховки будет ходить наш канатоходец-заказчик и его пользователи.
Для этой цели лучше всего подходят бизнес-диаграммы, и чаще всего используются стандарты вроде 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), которая не должна быть больше его основания, не быть при этом затычкой дыр с предыдущих этапов. Это – дополнение, которое априори считается закрытым на предыдущих этапах.
Организация подобного тестирования – главным образом работа по подготовке и синхронизации тестовых случаев и данных (тест-аналитика), а так же комплекс организационных мероприятий, синхронизация команд в одном месте в одно время на работоспособном тестовом полигоне. Помня это, не следует пробовать показывать заказчику «сквозное тестирование» раньше срока, чтобы не тратить время сразу большого количества людей без всех работающих компонентов, собранных воедино.
What Is End-To-End? A Full Process, From Start to Finish
Yarilet Perez is an experienced multimedia journalist and fact-checker with a Master of Science in Journalism. She has worked in multiple cities covering breaking news, politics, education, and more. Her expertise is in personal finance and investing, and real estate.
What Is End-to-End?
End-to-end describes a process that takes a system or service from beginning to end and delivers a complete functional solution, usually without needing to obtain anything from a third party. It often refers to vendors that can see a project through from beginning to end, and supply everything needed to create a workable solution—be it hardware, software, labor, written materials, and procedures.
End-to-end solutions also adhere to a philosophy that eliminates as many middle layers or steps as possible, which helps to optimize the performance and efficiency of a business. This includes pulling in minimal parties along the full project life cycle to ensure minimal disruptions are incurred from start to finish. It is most commonly used in the information technology (IT) sector.
Key Takeaways
- End-to-end refers to delivering complex systems or services in functional form after developing it from beginning to end.
- End-to-end is most common in the IT sector and is used during the planning, implementation, and evaluation stages.
- End-to-end processing can help optimize a business's performance and efficiency by eliminating the middle man.
- When dealing with complex services or systems, end-to-end arrangements are often cost-effective.
- Logistics, when service providers take care of inventory management, storage, and distribution, is an example of end-to-end in industries outside of IT.
End to End
Understanding End-to-End in Information Technology
Generally, end-to-end solutions are used with vendors that offer comprehensive systems that keep pace with a business’s ever-changing infrastructure requirements, and the changing demands of the IT sector itself. End-to-end suppliers generally handle all of a system's hardware and software, including installation, implementation, and maintenance. An end-to-end solution might cover everything from the client interface to data storage.
A company that offers end-to-end video conferencing products, for example, will provide everything including the monitors and network connections. In e-commerce, end-to-end processing occurs when one company provides a service to another in which it manages the sales, order tracking, and delivery of a product.
When dealing with complex systems or services, it is often easier and more cost-effective for the customer to have only one supplier and one point of contact. Also, IT solutions that involve multiple providers for different parts of the workflow only increase the cost of managing the process so are not considered to be true end-to-end solutions.
End-to-end processes are often used to embrace operational efficiency. For example, the Bureau of the Fiscal Service’s Office of Financial Innovation and Transformation of the Federal government developed end-to-end frameworks. This framework strives to reduce unnecessary steps, automate processes, and achieve large-scale efficiencies. By transforming end-to-end services, the department has identified up to $3 billion of potential cost savings.
Examples of End-to-End Services
In the world of procurement, an end-to-end process could mean analyzing each and every point in a company’s supply chain, from sourcing and ordering raw materials to the distribution of goods to end consumers. End-to-end procurement software solutions offer organizations a total overview of their supply chain, such as how long it takes for goods to be sent from suppliers and how much those goods cost.
Another example of end-to-end processing is in logistics, where service providers take care of inventory management, storage, and distribution. By eliminating as many layers and steps as possible, a logistics specialist can optimize distribution and minimize disruptions from road congestion, vehicle breakdowns, and the like.
In the petroleum industry, for example, transportation and logistics companies offer customers flexible and cost-effective end-to-end services, from order planning to inventory monitoring, loading, and transportation, to delivery. The latter includes supplying fuel and lubricants to service stations, aviation fuel to airports, and bitumen to the asphalt industry.
What Does the Phrase End-to-End Mean?
End-to-end refers to a full process from start to finish. It is often used to describe a service that sees something through from the kick-off or initiation through the final product. It may be used to describe a one-time project (i.e. implementation of new software) or may be an internal process (i.e. setting up a new vendor in an accounting system from start to finish).
What Is an End-to-End Product?
An end-to-end product is an item that manages the full development process of a new product from the start of development through final delivery to customers. The end-to-end process may incorporate multiple departments, but it refers to the full span of activities needed from start to finish to furnish the final deliverable.
What Is a Full Project Life Cycle?
The project management lifecycle often consists of four stages: initiation, planning, execution, and close-out. An end to end process will often consist of all four stages, as the process begins with the start of a project or process and ends with the final wrap-up after product or project delivery has been made.
How Is End-to-End Services Implemented in IT?
End-to-end services are often utilized in IT as it meshes well with the implementation and utilization of software. Often, a provider will offer support in the set-up of a product. The provider will then offer ongoing support services including troubleshooting, assistance upgrading to new versions, and daily operational support. The provider's goal is to offer assistance in every facet of the software that may be used from start to finish.