Хочешь читать реальные кейсы про российский бизнес? Жми сюда!
Хочешь читать реальные кейсы про российский бизнес? Жми сюда!
Хочешь читать реальные кейсы про российский бизнес? Жми сюда!
Хочешь читать реальные кейсы про российский бизнес? Жми сюда!
Хочешь читать реальные кейсы про российский бизнес? Жми сюда!
Хочешь читать реальные кейсы про российский бизнес? Жми сюда!
Хочешь читать реальные кейсы про российский бизнес? Жми сюда!
Хочешь читать реальные кейсы про российский бизнес? Жми сюда!
Хочешь читать реальные кейсы про российский бизнес? Жми сюда!
Хочешь читать реальные кейсы про российский бизнес? Жми сюда!
Хочешь читать реальные кейсы про российский бизнес? Жми сюда!
Хочешь читать реальные кейсы про российский бизнес? Жми сюда!
Хочешь читать реальные кейсы про российский бизнес? Жми сюда!

Информационнаябезопасностьвредитвашейкомпании

Перевод статьи Stephan Schwab «How information security can harm your company»

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

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

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

Информационная безопасность лишает разработчиков ПО даже самого простого инструментария

Это может быть нечто совсем безобидное, как, например, установка Ruby и выполнение gem install cucumber, чтобы создать быструю демонстрацию принципа разработки через приемочное тестирование (ATDD). В теории на скачивание, установку и использование такого инструмента должно уходить около часа, но в реальности на это уходит несколько дней.

Другая проблема — отсутствие прав у разработчиков на установку ПО или управление конфигурацией компьютера, на котором они работают. Из-за этого ОС Windows, которую используют большинство разработчиков, не дает установить скачанное.

Прокси-серверы не решают проблему информационной безопасности

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

Самое распространенное средство ограничения доступа в интернет — прокси-сервер. У этого способа есть несколько проблем.

  1. Конфигурация для использования прокси-сервера настраивается автоматически только для веб-браузеров. Для других средств, которые нужны разработчикам, необходимо установить переменную среды http_proxy и указать имя хоста и порт прокси-сервера. Здесь нарушаются основополагающие правила информационной безопасности: прокси-сервер требует аутентификации и сотрудники указывают свое имя и пароль открытым текстом. Например, так:
    http_proxy=http://username:password@10.203.0.1:5187/
  2. Настоящий кошмар начинается, когда средства разработки конфликтуют между собой или просто нет способа задать верную конфигурацию прокси-сервера на виртуальной машине. Распространенный обходной прием — использование так называемой технической учетной записи, но это всего лишь полумера, которая позволяет чуть дольше не отказываться от плохого решения.

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

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

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

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

Защита данных клиентов

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

Общий регламент по защите данных (GDPR) определяет псевдонимизацию как процесс, необходимый при хранении данных (в качестве альтернативы другому варианту — полному обезличиванию данных) для преобразования персональных данных таким образом, чтобы данные, полученные по завершении текущего процесса, было невозможно связать с конкретным субъектом данных без использования дополнительной информации. Пример тому — шифрование, при котором исходные данные становятся нечитаемыми, а процесс является необратимым без правильного ключа расшифрования. Общий регламент по защите данных устанавливает требования, согласно которым дополнительная информация (такая, как ключ расшифрования) должна храниться отдельно от псевдонимизированных данных.
— European Union General Data Protection Regulation

Хранение данных в открытом виде не оправдано. Данные клиентов должны храниться в зашифрованном виде, а возможность расшифровать должен иметь только уполномоченный пользователь. На рисунке ниже показана соответствующая структура сети:
Информационная безопасность
Зашифрованные данные клиентов защищены от внешних и внутренних злоумышленников

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

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

Защита информации компании

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

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

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

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

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

Защита систем от вредоносного ПО и сетевых атак

Перед обеспечением защиты всегда полезно сначала провести оценку риска. Важность оценки возрастает, когда заранее известно, что обеспечить защиту на 100% невозможно.

Большой опыт в данной области накопили в авиации. Как пилот, имеющий допуск к правилам полетов по приборам, могу сказать, что в сложных метеорологических условиях я ожидаю, что некоторые системы самолета могут отказать. Я не отменяю полет из-за облачности или вероятности гроз. При этом я обязательно оцениваю риск и разрабатываю планы по снижению риска. Если метеоусловия ухудшатся, я могу изменить маршрут полета или даже уйти на запасной аэродром. Если произойдет отказ одной из бортовых систем, я могу продолжить полет с использованием резервной системы или выполнить посадку из предосторожности. Именно по этой причине критически важные системы самолета дублируются. Такой принцип также называют моделью швейцарского сыра — [Swiss Cheese Model].(https://en.wikipedia.org/wiki/Swiss_cheese_model).

К компьютерным сетям и программным комплексам можно применить модель швейцарского сыра

Предположим, с внешней стороны нашей сети установлен простой межсетевой экран. Его настройки пропускают весь сетевой трафик изнутри во внешнюю сеть (это означает открытый доступ к интернету), и мы используем NAT (трансляцию сетевых адресов). Данный межсетевой экран с NAT — это наш первый рубеж обороны или первый ломтик швейцарского сыра. Да, в этом ломтике есть дырки, но нет прямого способа установить подключение к внутренней системе извне.
Информационная безопасность
Простая сеть с ДМЗ

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

Можно использовать операционную систему, менее уязвимую к атакам и вредоносному ПО: Linux и OS X защищены сильнее, чем Windows. Можно установить межсетевой экран напрямую в системе, которую необходимо защитить, и закрыть для этой системы многие каналы связи. Или можно создать подсеть, защищенную еще одним межсетевым экраном с более строгими правилами.
Информационная безопасность
Сеть с изолированными сегментами

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

Еще одна важная сторона — потенциальный ущерб после успешной атаки или последствия отказов, вызванных заражением вредоносным ПО

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

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

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

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

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

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

Вместо подключения сети с конфиденциальными данными и уязвимыми системами к другой сети применяется физическая изоляция (air gap). Для переноса данных через этот барьер можно использовать одноразовые носители: DVD-диски или USB-накопители.

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

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

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

Сергей Лобин

Поделиться
Вотсапнуть
Отправить
Ещё по теме
Перевод статьи Томаса Сандберга: http://www.thinkcode.se/blog/2016/06/22/cucumber-antipatterns Это расшифровка и изложение подкаста, в котором участвовали Aslak Hellesøy, Matt Wynne и Steve Tooke из Cucumber Ltd, они обсуждали BDD: инструмент Cucumber и анти-паттерны, которые встречали. Я изменил порядок описанных шаблонов, перефразировал некоторые части и добавил несколько своих мыслей. Официальный подкаст доступен по ссылке. Он стоит того, чтобы потратить на него своё время.Cucumber спроектирован как инструмент взаимодействия для создания живой документации, которую можно автоматизировать и которая описывает желаемое поведение системы. Поведение системы описывается на языке Gherkin. Если вы не знакомы с Gherkin, почитайте сейчас немного о нем. Дальнейшая часть предполагает, что вы знакомы с Gherkin и его формат Допустим/Когда/Тогда не выглядит для вас странным.

Анти-паттерн «Плохое взаимодействие»

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

Неверное время написания feature-файлов

Наверное, худший анти-паттерн при использовании Gherkin — писать feature-файлы после того как был написан код. Так часто бывает, если вы только начинаете использовать Cucumber и BDD. На самом деле сценарии нужно писать до того, как вы взялись за ПО. Это позволит полноценно использовать сценарии для разработки и документирования то, что было написано. Почему следует писать на Gherkin до того как написан софт? Документация желаемого поведения — это способ убедиться в том, что все согласны с тем, что должно делать ПО. Когда вы достигли согласия и у вас есть общее понимание проблемы — это хороший момент для начала реализации и создания кода. Если писать код до того, как все пришли к общему пониманию, то позже его точно нужно будет переделывать. Cucumber — инструмент тестирования, который позволяет проверять предположения и понимание проблемы до того, как будет написан код, решающий эту проблему. Инструмент позволяет прояснить желаемое поведение и решает неоднозначности, которые ранее не были обнаружены. Конкретные примеры, которые появятся еще до реализации решения, проверят, одинаковое ли у всех понимание. У владельца продукта или бизнес-аналитика, разработчика, тестировщика свои взгляд на проблему. Понимание этих разных взглядов до написания кода увеличивает шансы создания чего-то, что на самом деле нужно конечному пользователю.

Бизнес создает сценарии в изоляции

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

Разработчики и тестировщики пишут сценарии без общения с бизнесом

Это похоже на случай, когда владелец продукта или бизнес-аналитик пишет сценарии в одиночку. Если разработчики и тестировщики пишут сценарии самостоятельно без бизнеса, то их примеры скорее всего будут не реалистичными, а иногда получатся действительно сухими. Примеры не будут говорить о реальных пользователях, персонах, скорее об абстрактных «Пользователе 1» и «Пользователе 2». Так разработчики упускают возможность использовать настоящих пользователей, настоящие данные, это приводит к чему-то действительно скучному и далекому от реальной жизни.

Сценарии слишком верхнеуровневы

Если сценарий слишком поверхностный, ему нельзя по-настоящему доверять. Так происходит, потому что из-за туманности ситуации нельзя сказать, что на самом деле там происходит. Например: Допустим есть банковский счет. Когда я снимаю какую-то сумму. Тогда баланс должен быть равен первоначальному балансу за вычетом снятой суммы Этот пример описывает бизнес-правило, но не содержит конкретного примера. Вы не знаете начальный баланс и не знаем сумму, которую сняли, поэтому мы не можем понять результат. Пример ничего не иллюстрирует. Другой пример: Допустим система включена Когда я использую ее Она должна работать превосходно Такой сценарий дает слишком много свободы для того, кто будет это реализовывать. Он также верит в то, что реализующий владеет великолепным пониманием и не сделает ошибку. Это абсолютно бесполезный примера для ведения разработки. В эту ловушку легче попасть, если владелец продукта или бизнес-аналитик пишет сценарий в одиночку. Когда в написание сценария вовлечено больше людей, рассматривается больше взглядов. Туманные примеры можно сделать более четкими, неясные примеры можно уточнить, неявные правила могут быть обнаружены. Поиск правильного баланса между слишком туманным сценарием и сценарием, в котором слишком много деталей, сложен. Это то, что приходит с опытом, поэтому не ждите от команды совершенства с самого начала. Это сложно дается даже тем, у кого много опыта.

Анти-паттерн «Нет живой документации»

Cucumber — это инструмент для документирования и может быть использован для создания хорошей, живой документации по системе.

Плохая документация

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

Случайные детали

Бывает, что вместо хорошей истории пользователя перегружают слишком большим объемом информации и случайными деталями. Так бывает, если автор пишет скорее текст, а не документацию желаемого поведения. Например, Когда я логинюсь как Мэтт, мой пароль — пароль, подтверждение пароля — пароль, я проверяю баланс своего счёта Тогда я вижу $100 Цель этого сценария — проверить баланс, поэтому логин и пароль Мэтта не важны. Но они появляются в документации, потому что автору нужны значения для авто-теста. Проблема с такими случайными деталями в том, что они замутняют суть сценария. Становится сложно понять, что мы на самом деле пытаемся протестировать. В этом случае читатель должен угадать: мы тестируем функциональность ввода пароля или мы тестируем баланс банковского счета? Или тестируем и то, и то в одном сценарии? Детали о паролях и о балансе банковского счета делают цель этого сценария неясной.

Сложно сказать, что вы тестируете

Вы тестируете одно правило или вы тестируете несколько правил в одном сценарии? В этом случае появляются 2 проблемы:
  • Тестирование нескольких вещей в за один раз
  • Не создается понятная документация для проверки желаемого поведения
В такой ситуации придется искать между строчками, о чем же на самом деле этот сценарий. Более того, такой сценарий может быть бессмысленным: он расфокусирован и нацелен одновременно на всё сразу.

Неудачное название сценария

Удачное название сценария говорит читателю, о чем он. Отсутствие название заставляет читателя гадать. Если название пытается суммировать полное поведение сценария, оно становится скучным и читатель теряет интерес. Например: Сценарий: Зарегистрироваться, залогиниться, перейти на экран баланса, выйти Хороший вариант — это подытоживание сути сценария в его названии. Например так: Сценарий: Проверка баланса Название показывает, что любые детали обо всём остальном случайны и должны быть удалены. Если для автоматизации необходим пароль, он может быть добавлен на уровне автоматизации. Хороший алгоритм для названий может быть использование метафоры «Друзья»: Это когда... Вот примеры:
  • Это когда баланс положительный
  • Это когда у меня есть овердрафт на моём счёте
  • Это когда я меняю свой пароль
Затем описывается поведение в сценарии при помощи Допустим/Когда/Тогда

Не используется описательная часть feature-файла

Первая часть в feature-файле называется описательной частью. Вы можете написать туда все, что хотите. Вы можете её не заполнять или добавить туда полезные детали. Когда вы не заполняете описательную часть или добавляете туда пользовательский сценарий как тот, что ниже — это два разных анти-паттерна. Как пользователь, Я хочу проверить свой счёт и я знаю какой у меня баланс на нём Этот пользовательский сценарий не добавляет вам никакой дополнительной информации и поэтому довольно бесполезен. Вместо этого поместите полезную информацию для читателя в начале файла. Опишите бизнес-правила, абстрактные правила которые мы дополним примерами. Например: После того как вы сняли деньги, это снятие должно появиться в списке транзакций. Формат, в котором вы описываете бизнес-правила не имеет значения. Опишите их при помощи списка, если вам так больше нравится. Примеры, которые будут следовать ниже, уточнят их. Описательная часть — это также место, где можно поместить вопросы или какие-то элементы неопределенности. Относитесь к feature-файлу как к живой документации, куда вы помещаете найденные правила и неотвеченные вопросы, известные неизвестные. Это текущее понимание фичи. Здесь есть и то, что мы уже знаем и то, что нам ещё неизвестно.

Ошибки новичков

Дальше приведены ошибки, которые обычно совершают новички.

Куча деталей по UI

Система используется через пользовательский интерфейс (UI). Иногда это приводит к сценариям, в которых говорится о переходе по определенному url, клику по линку, поиску элементов, использующих определенные селекторы css и тд. На самом деле все это не говорит нам о цели использования программы.

Детали UI дают две проблемы:

  • сложно понять, почему пользователь хочет пройти именно этот путь,
  • интерфейс меняется гораздо более часто, чем лежащая под ним предметная логика.
UI имеет тенденцию меняться чаще, чем реальный бизнес, и это ломает тесты, даже если бизнес не поменялся. UI тесты очень медленные и хрупкие, на запуск тестовой утилиты уходит много времени. Тестируя через UI, вы застреваете на вершине пирамиды тестирования: все ваше тестирование будет выполняться через UI — медленно и хрупко. Кроме того, сценарии, написанные с деталями UI, делают невозможным протестировать что-либо ниже пользовательского интерфейса. Слишком много деталей об интерфейсе также приводит к плохой документации. Трудно понять бизнес-правила, разбираясь как работает навигация по системе. При это навигация по программе не говорит нам, почему мы используем программу. Проблема, которую вы решаете, используя эту программу, описана без использования слов предметной области, она описана с использованием общих терминов пользовательского интерфейса. Не бизнес-домена. Вы не указали существительные и глаголы, которые описывают вашу бизнес-проблему, которые вы бы хотели использовать глубоко ниже в вашем коде. Этот анти-паттерн обычно возникает из-за того, что вы на самом деле пишете сценарии после того как написали решение.

Описание действий через личные местоимения

Большинство систем используют много пользователей или акторов, поэтому нужно говорить о конкретном пользователе, персоне, если возможно. Персона даст вам контекст о том, что может система для поддержки конкретных категорий пользователей. Если система поддерживает университет, то в ней должна быть есть разница между 21-летним студентом и 53-летним администратором. Роль «студент» или «администратор» дает вам разный контекст. Возможно, возраст тоже может дать вам ценную информацию.

Документирование скучных сценариев

Некоторые сценарии очень скучные и, возможно, они были нужны только в начале проекта. Например: Допустим мой счёт в банке пустой Когда я проверяю свой баланс Тогда он должен быть равен 0 Возможно, вам были нужны подобные сценарии в начале проекта или когда вы только начали разрабатывать определенную фичу. Некоторые из них, однако, станут очевидными через какое-то время и будут покрыты другими тестами.

Вечное хранение всех сценариев

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

Нет четкого разделения между Допустим/Когда/Тогда

Начинающим сложно понять разницу между Допустим, Когда и Тогда. Проблема в том, что с технической точки зрения между ними нет разницы, Cucumber использует их одинаково. Разница все-таки есть:
  • Допустим — это контекст о прошлом
  • Когда — это действие которое изменяет систему, настоящее
  • Тогда — это ожидаемый результат, ближайшее будущее
Попробуем проследить разницу с помощью метафоры «поход в театр». Вы сидите на стуле и занавес опущен. За занавесом готовятся множество работников, они расставляют вещи по местам. Это Допустим. Вы настраиваете вашу систему, создавая начальные объекты, подготавливаете базу данных, переходите на конкретную страницу и так далее. Занавес поднимается и начинается пьеса. Вещи появляются, одна вещь ведет к другой. Актеры начинают перемещаться и произносить свой текст. Это Когда. Запускается важное событие, которое нам важно в определенном контексте. Одно событие на сцене ведёт к другому, ожидаемому результату. Это происходит как результат того, что сделал актер. Это Тогда. Видимое изменение, которое мы хотим подтвердить. Надеюсь, при помощи это метафоры Допустим и Когда проще понять. Но возможно часть Тогда менее ясна.
  • Прошлое, подготовка — Допустим
  • Настоящее, действие — Когда
  • Ближайшее будущее, ожидаемый результат — Тогда

Несколько Когда

Бывает, что в сценарии появляются повторения Когда или множество И. Иногда это нормально. Допустим, если несколько человек делают два разных действия на шаге Когда. Это могут быть похожие события. Но если у нас два полностью разных события, скорее всего объединять их через И в Когда — плохая идея. Возможно, надо разбить этот сценарий на два, чтобы описать два разных поведения. Не делайте этого в одном сценарии.

Обоюдоострый меч

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

Структура сценария

Структура сценария — пример того, что может быть использовано не по назначению и может привести к медленным тестам. Это особенно касается тех случаев, когда они содержат множество деталей по UI. Очень легко добавить множество сценариев, когда вы используете структуру. Если сценарий медленный, то это приведет вас к медленному набору тестов. Использование структуры сценариев для очень сложных алгоритмов может быть хорошей идеей. Но, возможно, не через медленный UI. Примером может быть проверка сложного страхового алгоритма, у которого много параметров, изменение которых приводит к различным результатам. В этом случае важно, чтобы вы могли добраться до алгоритма без UI. Важно, чтобы система создавалась тестируемой. Если сценарии быстрые, то возможно нормально использовать Структуру сценариев. Если сценарии медленные, не используйте их.

Множество Тогда в одном и том же сценарии

Это не обязательно анти-паттерн. Например, если что-то возвращается в розничной системе:
  • Пользователю должны вернуться деньги
  • Список товаров должен обновиться
  • Финансовая система должна быть обновлена
  • На склад должно быть отправлено сообщение о том, что нужно забрать возврат
Это всё связано и проверка их одновременно может быть хорошей идеей. В то же время, это является результатом одновременно четырех различных бизнес-правил, поэтому разделение их на четыре разных сценария может сделать бизнес-правила более явными и, возможно, поможет понять систему лучше. Разделение также позволит команде разработки реализовать эти правила инкрементально. Бывают примеры, когда связанные операции невозможно разделить на сценарии. Например, снятие денег с банковского счёта:
  • Пользователь должен получить свои деньги из банкомата, допустим 5000р
  • Со счета пользователя должны быть сняты 5000р
Эти результаты зависят друг от друга и не могут быть разделены на разные сценарии. Банку не понравится, если пользователи получат деньги без их списания со счёта. С другой стороны, что тоже правда, большинство пользователей не будут рады, если с их счета деньги будут списаны, а наличные они не получат.

Фотки из отпуска

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

Заключение

Когда вы используете Cucumber и BDD, вы можете сделать кучу ошибок. Однако, если вы их совершите, конец света не произойдет. Возможно вы совершите больше ошибок, но это жизнь. Вы живёте и вы учитесь. Сейчас вы вооружены знанием о некоторых анти-паттернах. Если вы вспомните ошибку, которую вы совершили и хотите этим поделиться, используйте комментарии ниже. Или пришлите нам письмо.
На тренингах Алексея Пикулева спрашивают, почему срочная работа — это плохо. Объясняем на примере очереди в аэропорте. Представьте, что вы стоите в Шереметьево в огромной очереди на регистрацию. Самолет через полтора часа, очередь еле ползёт. Работают три окошка регистрации, рядом пустует проход для пассажиров бизнес-класса, девушка за стойкой скучает. Вдруг подбегает менеджер с компанией людей, опаздывающих на свой рейс, и «втыкает» их в начало очереди. Он решил свою проблему, но представьте недовольство людей. Более того, из-за них теперь вы опаздываете на свой рейс и просите менеджера провести вас вне очереди. Впередистоящие пассажиры вас ненавидят. Что происходит: нормальная работа сбилась из-за малого количества стоек регистрации и действий менеджера. Это означает, что авиакомпания не умеет управлять потоком задач и использовать ресурсы на максимум. Какие последствия: получается замкнутый круг. Решение срочных задач сбивает налаженную работу, из-за чего возникают новые авралы. Это стресс для сотрудников, постоянное недовольство пассажиров, ухудшение репутации компании. Как исправить: искать системное решение проблемы. В этом помогут инструменты Канбана вроде системных диаграмм или техники «5 почему». Возможно, авиакомпании стоит открыть больше стоек регистрации или сделать так, чтобы люди могли зарегистрироваться самостоятельно. Гибкие подходы — это не прихоть, это продуманная организация работы. Замените очереди в аэропорту на поток задач в вашей компании — ничего не изменится. Канбан поможет наладить и то, и другое.
Комментарии
Подпишитесь на нас:
Телеграм Группа в фейсбуке