Visual Studio 2012

Тестирование при непрерывной разработке

Ларри Брейдер
Алан Кэмерон Кэмерон

В этой статье обсуждается предварительная версия Visual Studio 2012. Любая изложенная здесь информация может быть изменена.

Продукты и технологии:
Visual Studio 2012, Visual Studio Team Foundation Server, Microsoft Test Manager

В статье рассматриваются:

• тестирование в цикле DevOps;
• тестирование в Visual Studio 2012;
• автоматизированное и ручное тестирование;
• автоматизация ручных тестов;
• управление лабораторной средой;
• отчеты в Visual Studio Team Foundation Server;
• Visual Studio 2012 и непрерывная разработка (continuous development).

Веб-приложения обычно обновляются или расширяются каждые несколько недель (или даже дней) в ответ на изменение потребностей бизнеса и обратную связь с клиентами. Для поддержки непрерывной разработки каждый аспект цикла разработки должен быть более эффективным и облегченным, чем традиционные процессы. Например, природа программного обеспечения такова, что даже самое мелкое изменение требует протестировать все заново. Но повторение полного набора ручных тестов через каждые несколько дней просто невозможно. А это означает, что тесты в конечном счете должны быть автоматизированы, даже если они изначально были исследовательскими. В этой статье мы покажем, как Microsoft Visual Studio 2012 поддерживает тестирование в среде непрерывной разработки.

Цикл DevOps

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

Рис. 1. Цикл непрерывной разработки

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

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

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

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

Тестирование в цикле DevOps

Важная задача тестирования — продемонстрировать, что пользовательские истории (user stories) и другие требования были реализованы. Самый эффективный способ сделать это — запустить приложение вручную и проверить каждую пользовательскую историю точно так же, как работали бы конечные пользователи. Опытный тестер применяет разнообразные стратегии для выявления ошибок и исследует все варианты и граничные случаи поведения приложения.

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

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

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

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

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

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

На рис. 2 показан постепенный (во времени) переход от ручных тестов к автоматизированным, при этом модульные тесты расширяются вместе с кодом приложения. На этой схеме представлена идеальная картина; на практике в большинстве групп автоматизируют только некую часть ручных тестов. Visual Studio 2012 (и другие версии) поддерживает частичную автоматизацию, которую можно использовать для ускорения тестов без написания кода.

Рис. 2. Идеальный переход со временем от ручных тестов к автоматизированным

Тестирование в Visual Studio 2012

Давайте обсудим, как поддерживается тестирование в Visual Studio 2012 и связанных с ней продуктах — Visual Studio Team Foundation Server (TFS) и Microsoft Test Manager (MTM).

Если вы специализируетесь на тестировании приложений в целом, вас больше заинтересует поддержка, предоставляемая MTM. Если же вы разработчик, вам скорее всего больше подойдет поддержка автоматизированного тестирования в Visual Studio 2012. Однако непрерывная разработка требует более тесной взаимосвязи между этими двумя ролями, и в некоторых группах даже обходятся без разделения на эти роли. В связи с этим инструментарий Visual Studio 2012 проектировался так, чтобы интегрировать разные стили тестирования, и он поддерживает широкий спектр методик тестирования — от более традиционных подходов до непрерывной разработки.

Автоматизированное тестирование с помощью Visual Studio 2012

Автоматизированное тестирование охватывает все типы тестов, которые определяются написанием или генерацией программного кода. Вы создаете автоматизированные тесты в Visual Studio 2012, где изначально выполняете их для отладки.

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

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

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

В Visual Studio 2012 можно писать тесты, которые используют любую из нескольких инфраструктур тестирования, например NUnit, xUnit и VSTest (по умолчанию). Когда вы запрограммировали тесты в любой из этих инфраструктур, вы просто открываете окно Test Explorer и выбираете Run All. Результаты тестов суммируются в этом окне.

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

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

Visual Studio 2012 предоставляет два механизма, собирательно называемых имитациями (fakes), для отключения модуля от его зависимостей. Вызовы из вашего модуля методов за его границами могут быть обработаны небольшими блоками кода, которые пишете вы. Например, вы можете определить прослойку (shim), которая перехватывает вызовы любого внешнего метода, такого как DateTime.Now. Поскольку ваш модуль всегда получает один и тот же ответ от прослойки, он будет демонстрировать одно и то же поведение при каждом его вызове. Вы также можете определить заглушки (stubs), которые предоставляют заменяющие реализации методов в незагруженных сборках.

Инструментарий Visual Studio 2012 проектировался так, чтобы интегрировать разные стили тестирования, и он поддерживает широкий спектр методик тестирования.

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

Запрограммированные UI-тесты Позволяют выполнять приложение и генерировать код, который управляет UI приложения. Visual Studio 2012 включает специализированные инструменты для создания и редактирования таких тестов; кроме того, вы можете редактировать и добавлять их в код самостоятельно. Например, вы могли бы создать простую процедуру для покупки чего-либо на веб-сайте, а затем отредактировать код, чтобы добавить в него цикл, совершающий покупки множества товаров.

Запрограммированные UI-тесты особенно полезны, когда в UI (скажем, на веб-странице) имеются проверки и другая логика. Их можно использовать либо как модульные тесты для UI, либо как интеграционные тесты для приложения в целом.

Ручное тестирование с помощью Microsoft Test Manager

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

Как правило, ручные тесты связываются с пользовательскими историями (или с элементами незавершенных работ по продукту [product backlog], или с другими требованиями), а результаты этих тестов отображаются в отчетах на информационной панели проекта. То есть любой может быстро посмотреть, какие истории были успешно реализованы.

Исследовательское тестирование (exploratory testing) Это подразумевает простую работу с приложением в попытке найти ошибки в нем. Но почему нужен MTM, чтобы вести такое тестирование?

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

Рис. 3. Запись экранного снимка и добавление заметок в окне исследовательского тестирования

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

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

Планируемое тестирование с применением тестовых сценариев Тестовые сценарии (test cases) — это ручные тесты, определяемые как набор этапов, которые должен выполнить тестер. На рис. 4 показаны этапы, определенные в одном из тестовых сценариев.

Рис. 4. Определение этапов и ожидаемые результаты в тестовом сценарии

Тестовые сценарии — отличный способ прояснить, что именно нужно пользователям. В начале спринта (sprint), когда вы обсуждаете истории или требования с пользователями и другими заинтересованными лицами, вы можете использовать этапы как точный пример того, что смогут делать пользователи к концу спринта. Каждый тестовый сценарий — это просто один экземпляр требования, а каждое требование можно сопоставить более чем с одним тестовым сценарием. Например, если требование заключается в том, чтобы была возможность покупать мороженое, то один тестовый сценарий детализировал бы этапы, необходимые для покупки мороженого с конкретным вкусом, а другой тестовый сценарий описывал бы покупку мороженого со смесью вкусовых добавок. Главное правило обсуждения с заинтересованными лицами должно быть таким: «Когда вы сможете успешно выполнить эти тестовые сценарии, тогда мы рассмотрим историю, которую нужно реализовать».

В TFS истории (или требования) и тестовые сценарии представляются рабочими элементами. Вы можете связать их, чтобы по результатам тестов отслеживать прогресс в ходе выполнения требования.

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

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

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

Вы также можете сгенерировать планируемый тестовый сценарий (planned test case) на основе сеанса исследовательского тестирования (exploratory session). Это помогает убедиться в том, что вы всегда выполняете тест, используя одни и те же действия.

Автоматизация ручных тестов

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

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

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

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

Даже если вы не полностью автоматизировали тест, быстрое и надежное воспроизведение помогает сократить цикл DevOps. Эта функциональность не требует наличия Visual Studio 2012, и никакого кода писать не нужно.

Генерация программных тестов UI Вы можете сгенерировать полностью автоматизированный программный тест UI на основе записанного ручного прогона тестового сценария. Сгенерированный код выполняет те же операции, что и ручной тест. С помощью специального редактора в Visual Studio 2012 (рис. 5) можно расширить тест для проверки результатов и его обобщения, чтобы повторять этот тест с разными входными данными.

Рис. 5. Редактирование UI-операций в Visual Studio 2012

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

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

Управление лабораторной средой

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

Рис. 6. Пример лабораторной среды для тестирования веб-сайта

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

В MTM все это упрощает функция Lab Center. Lab Center позволяет определять лабораторные среды. Лабораторная среда — это набор компьютеров, которые будут использоваться как группа для тестовых целей.

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

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

Использование Lab Center и, в частности, таких его механизмов, как VM, может значительно ускорить подготовку лабораторной среды в сравнении с более традиционными подходами. Lab Center вносит существенный вклад в уменьшение времени, затрачиваемого на каждый цикл DevOps.

Автоматизированное тестирование в TFS

Автоматизированные тесты изначально выполняются в Visual Studio 2012 на компьютере разработчика. После отправки кода в репозитарий исходного кода тесты интегрированного кода могут выполняться сервисом сборки несколькими способами.

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

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

Лабораторное развертывание Как мы уже говорили, вы можете назначить группу лабораторных компьютеров для тестирования с применением Lab Center. Определив лабораторную сборку, вы можете автоматизировать этот процесс. Когда запускается сборка (например, при постановке кода на учет или в конкретное время суток), этот процесс начинается с компиляции всего приложения и тестового кода. Если этот этап прошел успешно, назначается лабораторная среда, и, если она виртуальная, ее можно сбросить в исходное состояние. После этого на соответствующих компьютерах развертываются компоненты вашего приложения, и тесты устанавливаются на заданную клиентскую машину, откуда они будут управлять приложением.

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

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

Отчеты

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

Например, отчет User Story Test Status, показанный на рис. 7, отображает список историй, над которыми вы работаете в текущем спринте. В дополнение к задачам разработки, выполняемым для каждой истории, на диаграмме отмечаются успешно и неудачно выполненные тесты. Если при выполнении тестов были неудачн, отчеты об ошибках также связываются с требованиями.

Рис. 7. Отчет User Story Test Status

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

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

Отчет Test Plan Progress, представленный на рис. 8, показывает, сколько тестовых сценариев было создано для текущего спринта и сколько из них выполнено.

Рис. 8. Отчет Test Plan Progress для спринта

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

Visual Studio 2012 и непрерывная разработка

Теперь вы более-менее знакомы со средствами тестирования в Visual Studio 2012 — от модульных тестов до ручных тестов приложения в целом.

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

Средства Visual Studio 2012 могут существенно сократить время, затрачиваемое на тестирование приложения. Ниже изложены некоторые моменты, о которых следует помнить.

• Лабораторные среды можно быстро и автоматически очищать, особенно при применении VM. Используйте преимущества Lab Center.
• Запись действий при исследовательском и планируемом тестировании позволяет быстро и надежно создавать отчеты об ошибках, уменьшая вероятность того, что эта ошибка исчезнет, когда кто-то другой попытается воспроизвести ее.
• Вы можете реализовать постепенный переход с ручных тестов на автоматизированные. Автоматизированные тесты обрабатывают основную часть регрессионного тестирования, тогда как ручные тесты используются главным образом для новых и обновленных историй.
  • На основе исследовательских тестов можно генерировать воспроизводимые ручные тестовые сценарии.
  • Вы можете вести запись при прогонах тестов и потом быстро и надежно воспроизводить их.
  • Вы можете сгенерировать программные тесты UI на основе выполненных тестов. В качестве альтернативы можно селективно связывать программные интеграционные тесты с тестовыми сценариями.

На рис. 9 показан переход от исследовательских тестов к автоматизированным.

Рис. 9. Прогресс тестов

• Тестовые сценарии помогают точно описывать пользовательские истории. Вы можете писать их этапы совместно с заинтересованными лицами, чтобы снять любое недопонимание, связанное с пользовательскими историями.
• Тесты связываются с требованиями (или пользовательскими историями, или с элементами списка незавершенных работ по проекту), что позволяет видеть исчерпывающие отчеты о том, насколько реализованы требования пользователей. Причем не просто в плане оставшейся работы, а с указанием того, насколько успешно проделаны уже выполненные работы. Тесты определяют цель для группы разработки в каждом спринте.
• Тестовые сценарии и требования можно связывать с раскадровками (storyboards) в PowerPoint, документами требований или моделями Unified Modeling Language (UML). Когда вы вносите изменения в раскадровку, вы можете отслеживать необходимые изменения в тестах.
• План тестов связывается с тестовыми сценариями, кодом, требованиями, тестовыми средами, параметрами тестов и групповым проектом. Если группе придется отвлечься на несколько месяцев для работы над другим проектом, а потом вернуться к дальнейшему улучшению данного продукта, она сможет реконструировать все, что нужно для тестирования.

Мы дали вам обзор того, какое место занимает Visual Studio 2012 в цикле DevOps. Теперь вы должны понимать, зачем нужен описанный подход к тестированию и какие средства Visual Studio 2012 помогут вам в его реализации. Если вам требуется дополнительная информация, прочитайте документ «Testing for Continuous Delivery with Visual Studio 2012 RC» в MSDN Library по ссылке bit.ly/KHdOq4. Это углубленное руководство, охватывающее каждый аспект инфраструктуры тестирования, предоставляемой Visual Studio 2012. Мы также рекомендуем статьи «Verifying Code by Using Unit Tests» (bit.ly/dz5U3m) и «Testing the Application» (bit.ly/NbJ01v).

Ларри Брейдер (Larry Brader) — в последние несколько лет был старшим тестером в группе Microsoft Patterns & Practices. До этого работал в качестве разработчика и тестера в области военных и медицинских технологий.

Алан Кэмерон Уиллс (Alan Cameron Wills) — технический писатель, отвечающий за документацию в Microsoft Developer Division. В прежних жизнях был разработчиком, архитектором ПО и консультантом по методам разработки.

Выражаем благодарность за рецензирование статьи экспертам Хоуи Хилликеру (Howie Hilliker), Кэтрине Лайон-Смит (Katrina Lyon-Smith), Питеру Провосту (Peter Provost) и Рохиту Шарме (Rohit Sharma).