Новости

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

Книга представляет собой краткий справочник, но ее также можно читать и подряд, от корки до корки. Каждая практика в частях II–IV предназначена для самостоятельного чтения. Блоки «См. также» и ссылки на источники помогут вам сопоставить информацию. Вдобавок печатное издание можно открыть в любом месте и быстро просмотреть интересующую информацию. Можете пролистать книгу и остановиться, чтобы прочитать какую-то врезку более внимательно, если она привлечет ваше внимание.

Если вы менеджер или руководитель высшего звена, который хочет понять, как Agile может или должен работать в вашей компании, то прочитайте часть I. Если вы руководитель командного уровня, то прочтите еще и раздел «Менеджмент» главы 10 и, возможно, другие практики, рассматриваемые в той же главе.

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

Если вы часть Agile-команды и просто хотите получить знания, которые позволят выполнять вашу работу, то можете сосредоточиться на практиках, изложенных в частях II и III. Начните с главы 1, чтобы получить общую картину, затем перейдите к тем практикам, которые использует ваша команда.

Если вы не являетесь частью Agile-команды, но работаете с одной из них, то посоветуйтесь с ними, что почитать. Продакт-менеджеры, владельцы продукта, дизайнеры могут начать с главы 8 и раздела «Цель» главы 7. Сотрудникам отделов безопасности и отделов эксплуатации рекомендую разделы «Сборка для эксплуатации» главы 15, «Обнаружение слепых зон» и «Анализ инцидентов» главы 16. Тестировщики, ознакомьтесь с главой 16.

Если вам просто любопытно узнать об Agile, то начните с главы 1. После этого ознакомьтесь с частями II–IV. Начните с наиболее интересных для вас практик. Можете читать их в любом порядке.

Обнаружение слепых зон

Мы выявляем пробелы в своем мышлении.
Аудитория: тестировщики, вся команда

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

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

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

Подтвержденное знание

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

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

Не считайте, что ваша команда должна создавать то, что ей приказали создать. Лучше предположите обратное: никто на самом деле не знает, что вы должны создать, даже люди, которые просят об этом. Работа вашей команды состоит в том, чтобы взять идеи, протестировать их и узнать, что вам на самом деле нужно сделать. Перефразируя The Lean Startup [Ries2011], фундаментальная деятельность любой команды Agile — превращать идеи в продукты, наблюдать за реакцией заказчиков и пользователей и затем решать, что делать дальше: разворачиваться или продолжать двигаться в этом направлении. Это называется подтвержденным знанием.

Многие команды первый раз тестируют свои идеи в тот момент, когда выполняют релиз своего ПО. Это довольно рискованно. Лучше использовать цикл Риса «создать — измерить — изучить» (Build-Measure-Learn).

1. Создать. Посмотрите на цель и план вашей команды. Каковы ваши базовые предположения о вашем продукте, заказчике и пользователях? Выберите для тестирования одно из них, а потом подумайте: «Какой самый маленький элемент мы можем продемонстрировать реальным заказчикам и пользователям?» Это не обязательно должен быть реальный продукт (в некоторых случаях вполне подойдут макет или бумажный прототип), и вам не обязательно вовлекать каждого пользователя, но нужно вовлечь людей, которые на самом деле будут покупать и использовать ваш продукт.

2. Измерить. Прежде чем показывать людям, что вы создали, решите, какие данные вам нужно увидеть, чтобы сказать, подтвердились ваши предположения или нет. Данные могут быть субъективными, но измерения должны быть объективными. Например, «70 % наших заказчиков говорят, что нас любят» — объективное измерение субъективных данных.

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

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

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

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

Больше информации о подтвержденном знании и связанной с ним концепции открытия заказчика вы найдете в [Ries2011] и [Blank2020b].

Исследовательское тестирование

Разработка через тестирование гарантирует, что код, написанный программистами, будет делать то, что они от него хотят. Но что, если намерения программистов неверны? Например, программист может думать, что правильный способ определить длину строки в JavaScript — это использовать string.length, но это может привести к тому, что в слове naïve будет насчитано шесть букв.

«Исследовательское тестирование» — это техника для поиска подобных слепых зон. Это скрупулезный подход к тестированию, подразумевающий «планирование и выполнение быстрой последовательности крошечных экспериментов, где результаты предыдущего эксперимента используются в качестве вводной информации для следующего» [Hendrickson2013] (гл. 1). Эта техника состоит из следующих шагов.

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

2. Наблюдение. Используйте ПО. Чаще всего вы будете делать это через UI, но также можете использовать инструменты, чтобы исследовать API и сетевой трафик; кроме того, вы можете наблюдать за скрытыми частями системы, такими как журналы событий и базы данных. Обращайте внимание на две вещи: все, что выбивается из разряда обычного, и все, что вы можете изменить, например URL, поле формы или загрузку файла, что в результате может привести к неожиданному поведению. Делайте заметки в процессе, чтобы вы могли отследить свои шаги, когда это будет необходимо.

3. Изменение. Не просто используйте ПО обычным образом; расширьте его границы. Добавьте эмодзи в текстовое поле. Введите значение размера как ноль или отрицательное значение. Загрузите файл с нулевым байтом, поврежденный файл или «взрывающийся» ZIP-файл, который расширяется до терабайтов данных. Редактируйте URL. Измените сетевой трафик. Искусственно замедлите свою сеть или сделайте запись в файловую систему, в которой нет свободного места.

По мере продвижения используйте свои наблюдения и понимание системы, чтобы решить, что исследовать дальше. Вы вполне можете дополнить эти идеи, просмотрев код и рабочие журналы событий. Если вы исследуете возможности безопасности, то можете использовать модель угроз вашей команды как источник вдохновения или создать собственную. (См. подраздел «Моделирование угроз» главы 15.)

Исследовательское тестирование предоставляет гораздо больше возможностей, чем я могу описать в этой книге. Больше информации и отличный набор эвристик о том, что можно варьировать, вы найдете в [Hendrickson2013].

Хаос-инжиниринг

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

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

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

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

2. Приготовьтесь изменить систему каким-либо образом: убрать один узел, ввести задержку, изменить сетевой трафик, искусственно повысить количество запросов и т. д. (Если это ваш первый тест, то начните с малого, чтобы ограничить влияние сбоя.) Сформулируйте гипотезу о том, что произойдет. Составьте план прерывания эксперимента, если все пойдет слишком плохо.

3. Внесите изменение и понаблюдайте, что происходит. Была ли правильной ваша гипотеза? Система все еще работает адекватно? Если нет, то вы обнаружили слепую зону. В любом случае обсудите результаты с вашей командой и усовершенствуйте коллективную ментальную модель системы. Используйте то, что вы узнали, чтобы решить, какой эксперимент проводить следующим.

Многие истории, касающиеся хаос-инжиниринга, связаны с использованием автоматизированных инструментов, например Chaos Monkey от Netflix. Однако при использовании хаос-инжиниринга внутри команды не фокусируйтесь на создании инструментов. Гораздо ценнее проводить множество экспериментов, чем автоматически повторять один. Вам понадобится некий базовый инструментарий для поддержки вашей работы, и со временем он будет становиться все более и более усложненным. Но старайтесь проводить максимально широкий набор экспериментов, используя наименьший объем работы.

Принципы хаос-инжиниринга можно найти на principlesofchaos.org. Подробное изложение темы в формате книги см. в [Rosenthal2020].

Тестирование на проникновение и оценка уязвимостей

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

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

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

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

Некоторые оценки уязвимостей выполняют статический анализ вашего кода и зависимостей. Если они достаточно быстрые, то могут быть добавлены в вашу сборку непрерывной интеграции. (Если нет, то вы можете использовать многоступенчатую интеграцию, как описано в подразделе «Многоступенчатые интеграционные сборки» главы 13.) Со временем вендор, выполняющий оценку, будет добавлять в инструмент дополнительные сканирования, которые будут оповещать вашу команду о новых потенциальных уязвимостях.

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

Оценка уязвимостей может быть «зашумленной» ложными результатами. Скорее всего, вам понадобится кто-то с навыками в сфере безопасности, кто сможет просмотреть ее и рассортировать результаты. Вам также может понадобиться какой-то безопасный способ игнорировать неактуальные результаты. Например, одна из оценок выполняла сканирование на уязвимые URL, но была недостаточно «умной», чтобы следовать HTTP-перенаправлениям. Каждый месяц она выдавала отчет, в котором каждый URL объявлялся уязвимостью, хотя сервер просто выполнял общее перенаправление (blanket redirect).

В целом начинайте с моделирования угроз (см. подраздел «Моделирование угроз» главы 15) и чек-листов безопасности, таких как OWASP Топ-10 (https://www.owasp.org), чтобы обосновать ваши усилия по программированию и исследовательскому тестированию. Используйте автоматизированные оценки уязвимостей для отслеживания и исправления дополнительных угроз и поиска слепых зон. Затем переходите к тестированию на проникновение, чтобы понять, что вы упустили.

Вопросы

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

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

Предварительные требования

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

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

Показатели

Когда вы хорошо используете практику обнаружения слепых зон:

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

Альтернативы и эксперименты

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

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

Что касается экспериментов, техники, которые я описал, — это лишь начало. Основная идея — подтвердить ваши скрытые предположения. Все, что вы сможете сделать, чтобы их определить и протестировать, будет объектом исследования. Еще одна техника, которую вы можете изучить, — фаззинг (fuzzing). Она подразумевает создание большого количества вводных данных и мониторинг непредвиденных результатов.