В 2014 году Фредерик Лалу, консультант, коуч и фасилитатор, выпустил книгу «Открывая организации будущего», в которой предположил, что все организации можно поделить на 5 типов. Каждый тип для наглядности получил свой цвет: красный, янтарный, оранжевый, зеленый и бирюзовый. Не буду подробно рассказывать всю теорию, остановлюсь на нескольких основных примерах.
«Красная» система представляет собой организацию, где есть вождь и его племя, ведущие борьбу с враждебным миром и другими такими же организациями. «Янтарный» уровень предполагает иерархию, где все подчиняются скорее не одному человеку, а жестким неизменным правилам. Большинство корпораций сегодня находятся на следующем, «оранжевом» уровне. В них уже нет правильного и неправильного, а есть эффективное и неэффективное. У сотрудников появляются ответственность и контроль за ситуацией вместо обязанности слепо исполнять приказы.
В «зелёных» организациях отношения внутри группы и общие ценности команды важнее выгоды. Миссия такой компании — быть новаторами. Все вместе они хотят изменить мир, и каждый член команды верит, что делает это своим вкладом в большое дело. Долгое время именно эта стратегия считалась самой современной и выигрышной, однако Лалу заметил, что компании, выбирающие этот путь, не всегда становятся успешными и умеют зарабатывать.
Почему E2E? — Тестирование
Так появилась новая ступень — то самое «бирюзовое» управление. Оно состоит из трех основных принципов: самоуправление, целостность и эволюционная цель. Ее отличие от «зеленой» в том, что каждый сотрудник видит в работе не только общую миссию компании — изменить мир — но и отлично понимает свое место и цели компании, на которые он влияет. В ней еще больше свободы и ответственности на каждом члене команда. Это та самая модель, к которой сегодня стремятся современные digital-компании, и мы в «Манго Страхование» в этом смысле не исключение.
Однако стартануть сразу «бирюзовыми» не так-то и просто. Это такое золотое Эльдорадо, куда все стремятся прийти, но для этого все сотрудники, а особенно лидеры, должны очень хорошо понимать особенности бизнеса, быть самостоятельными и ориентированными на результат. Чтобы стать «бирюзовыми», люди в каждой команде должны не только вырасти, но еще и сработаться между собой.
Наша компания сейчас зависает где-то между «зелёной» и «бирюзовой» организацией. Я бы сказала, что мы ближе к «зелёной» компании с «бирюзовыми» вкраплениями.
Наша иерархия сейчас выглядит следующим образом:
- Топ-менеджмент состоит из пяти человек, его возглавляет фаундер Виктор Лавренко. Я отвечаю за продуктовую разработку, генеральный директор Павел Конев — за всю страховую часть, CMO Диана Акчурина — за бренд и продвижение, CFO Елена Колесник — финансы и бухгалтерия. У каждого своя зона ответственности.
- End-to-end команды — это костяк, где находится большая часть сотрудников. В каждую команду входят продакт-менеджер, менеджер по маркетингу, разработчики и представитель службы заботы о клиентах.
- Дизайн-команда временно вынесена за пределы end-to-end команд, чтобы навести порядок в наших коммуникациях. Через какое-то время, когда будет выработан фреймворк работы дизайнеров, они вернутся обратно в команды.
- Команда цифровых коммуникаций, которая ведет наши соцсети, блог и несет миру знание о нас и о ценности современного страхования.
- Cлужба заботы о клиентах — это лицо и голос компании. Задача ребят — максимально оперативно и дружелюбно решать любые проблемы пользователей.
Топ-менеджмент не руководит командами, а выступает кураторами. Это очень важно для понимания уровня ответственности и свободы внутри компании. Причем в разный период времени за нами закреплены разные команды. Допустим, в команде «Страхование животных» в этом квартале нужно усилить диджитал часть — тогда я беру их себе в кураторство и помогаю разобраться.
Подход выделения сквозных (End-To-End | E2E) бизнес-процессов
Если нужно подтянуть страховую часть — подключается директор Паша Конев. Все зависит от целей команды в тот или иной период времени.
KPI: ставить или не ставить?
По моему мнению KPI (ключевой показатель эффективности) уже устарел. Мы используем OKR (objective and key results) — это другая методология, которая предполагает более гибкое отношение к целям. Строится она на том, что вся компания имеет стратегический бизнес-план примерно на пять лет, в котором очень крупными мазками написано, каких показателей мы хотим достигнуть в долгосрочной перспективе: сколько денег заработаем, сколько клиентов привлечем. Там же обязательно есть миссия и позиционирование по ключевым вопросам. Условно, что мы делаем и не делаем, в какие отрасли идем, а в какие нет.
Следующим уровнем идёт уже OKR компании на год. Их разрабатывают топ-менеджеры, обсудив с лидерами команд. Мы получаем обратную связь и совместно, в несколько итераций, добиваемся общих целей с конкретными метриками. Глядя на общий OKR, команды рисуют свои цели на квартал, синхронизируются с друг другом и согласовывают с нами.
Мы, менеджеры борда, отвечаем за общую стратегию и процессы в компании. Ответственность же за достижение целей лежит на лидерах команд.
Для контроля достаточно двух регулярных мероприятий: еженедельная планерка и ежемесячная отчетная встреча на всю компанию, которая у нас называется «Царь-Демо». Команды делятся друг с другом проделанной работой и результатами, получают обратную связь и с нашей помощью корректируют планы.
Больше свободы и ответственности
По опыту работы в «Альфа-Банке» я могу сказать, что в крупных компаниях продуктовые команды хоть и пытаются работать более-менее автономно, все равно отвечают за локальный набор метрик. Например, за скачивание приложения или конверсию. То есть они почти никогда не отвечают за общий результаты, такой как привлеченные клиенты или прибыль. Мы осознанно заносим эту ответственность внутрь команды, чтобы продакты всегда держали в голове юнит-экономику и продумывали, как каждое их решение влияет на цели компании.
Такой подход дает больше ответственности и свободы. Лидеры команд сами распоряжаются своим бюджетом на маркетинг. Обычно это происходит так: продакт продумывает, какой бюджет им будет необходим на следующий квартал, приходят со своим маркетологом на собрание по согласованию бюджета. Мы даем обратную связь. Иногда говорим, что это слишком дорого или наоборот не слишком амбициозно и стоит подумать еще, а иногда согласовываем сразу.
Кроме того, мы стремимся, чтобы у каждого лидера команды была ответственность и за людей внутри: за их найм, зарплаты, мотивацию и прочее. В идеале руководитель команды должен уметь сам увольнять и нанимать сотрудников. Мы хотим создать мини-CEO внутри каждой команды. Это один из шагов в сторону «бирюзовой» организации. Но пока для самих людей тяжело принять на себя много свободы и ответственности одновременно.
Если мы видим, что человек справляется с наймом людей, он этим занимается. Если же ему пока тяжело, мы не будем настаивать и оставим за собой эту функцию. Например, разработчиков в команды пока еще помогаю набирать я, а вот маркетологов ребята уже ищут и собеседуют сами под присмотром CMO.
Где найти ответственных людей
Обычно на этапе собеседования уже видно, насколько человек радуется той структуре компании, которую мы описываем. Реакция соискателя многое говорит о том, впишется он в команду или нет. Люди с бизнес-мышлением, например, продакты или маркетологи, обычно счастливы получить свободу. А вот исполнители, привыкшие работать по указке сверху, зачастую теряются. Это важно обнаружить как можно раньше, поэтому финального кандидата у нас собеседуют несколько людей с разным бэкграундом.
По поиску людей круче всего работает нетворкинг — когда текущие сотрудники зовут своих знакомых, друзей и бывших коллег.
Сейчас у нас почти половина сотрудников как раз те, кого привели наши текущие работники. Это создает общий культурный фон, который тоже крайне важен.
Важно быть готовым к тому, что своих сотрудников придется растить, так как даже самый крутой профессионал может не сразу быть готовым ко всему спектру ответственности. Однако такие вложения для стартапа лишь плюс. Со временем сотрудник, который развивается вместе с компанией, станет вашим лояльным, ответственным и заинтересованным партнером, а не просто наемным работником.
Пять советов, как организовать структуру в стартапе и не бояться перемен:
- Определите цели и систему оценки. KPI, OKR или любые другие методики — это важнейший инструмент принятия решения. Они помогают определять, куда вы движетесь и как измерять результат.
- Внимательно выбирайте лидеров команд. Лидер — человек, готовый взять на себя ответственность за достижение метрик, которые вы вместе выбрали. Не ищет оправданий, предлагает решения, умеет их реализовывать. Это не значит, что он никогда не ошибается. Даже наоборот — он обязан бесконечно проверять различные гипотезы и не бояться ошибаться, но делать это быстро. Выбирайте на роль руководителей команд людей, которых не надо контролировать, а достаточно направлять.
- Доверяйте сотрудникам и давайте им свободу. Будучи фаундером или топ-менеджером, вы можете представить себе какую угодно структуру и пытаться ее внедрить, но никогда не получите ни «зеленую», ни уж тем более «бирюзовую» организацию. Для самостоятельных команд достаточно определить метрики успеха. Они сами будут предлагать способы их достижений, изменения в процессах или даже в структуре. Ваша задача — помогать сотрудникам держать общее направление. Также важно уметь вовремя прощаться с человеком, которому не комфортно жить в таких условиях.
- Старайтесь организовать гибкую и простую структуру. Выбирайте способы организации коллектива, при которых можете быстро внедрять изменения. Например, деление на автономные команды позволяют быстро разворачивать новые направления или отказываться от старых, не теряя целостность всей компании. Гибкость также дает краткосрочное планирование: если мы завтра резко поменяем цель, то багодаря коротким спринтам через две недели команды уже будут бежать в сторону новых вводных.
- Собирайте обратную связь. Оставайтесь в курсе происходящего в каждой отдельной команде и давайте возможность всем участникам процесса высказывать и получать фидбэк. Важно сохранять общее целевое и ценностное единство, даже если работа сотрудников не пересекается ежедневно. Узнавайте, все ли в порядке и как идет процесс, организуйте общие собрания и помните, что компания — живой организм. А все организмы должны постоянно меняться и адаптироваться, как завещал дядюшка Дарвин.
Источник: rb.ru
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, (изначально AirBedhttps://www.vizavi.ru/blog/e2e/» target=»_blank»]www.vizavi.ru[/mask_link]
Сквозное тестирование (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.
Поэтому проще всего воспользоваться абстракциями – создать хотя бы схему процесса, и указать её входы и выходы, сделать процесс контролируемым и измеряемым, обеспечить взаимосвязь с родительскими и дочерними процессами, как того и требует ISO9000
All processes have:
• inputs;
• outputs;
• operational control;
• appropriate measurement 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), которая не должна быть больше его основания, не быть при этом затычкой дыр с предыдущих этапов. Это – дополнение, которое априори считается закрытым на предыдущих этапах.
Организация подобного тестирования – главным образом работа по подготовке и синхронизации тестовых случаев и данных (тест-аналитика), а так же комплекс организационных мероприятий, синхронизация команд в одном месте в одно время на работоспособном тестовом полигоне. Помня это, не следует пробовать показывать заказчику «сквозное тестирование» раньше срока, чтобы не тратить время сразу большого количества людей без всех работающих компонентов, собранных воедино.
P.S. описанные инструменты, а так же практики – сугубо для примера, автор не ставил цели себе рекламировать продукты и декламировать единственно верным данный подход к сквозному тестированию.
- тестирование
- тестирование по
- управление тестированием
- e2e
- end-to-end
- сквозное тестирование
- тест-менеджемент
- тест-дизайн
- end-to-end testing
- end-to-end тестирование
- end2end
- бизнес-тестирование
- бизнес-процессы
- iso9000
- bpmn
- hp alm
- alm
- hpe alm
- Тестирование IT-систем
- Управление проектами
- Управление продуктом
Источник: habr.com
