Тестирование облачных сервисов

Несколько лет назад в индустрии сервисов и производства ПО произошли существенные изменения — технологии и инфраструктура Интернета достигли уровня, достаточного для того, чтобы всерьез говорить о возможности предоставления приложений в виде сервисов (Software as a Service, SaaS). Данная модель стала наиболее распространенной при работе с облаками, и это позволило аналитикам Gartner утверждать, что в 2012 году рынок решений SaaS вырастет на 18% и достигнет 14,5 млрд долл. В качестве примера реализации решения SaaS для публичного облака можно назвать сервис Team Foundation Services на платформе Windows Azure, предназначенный для контроля версий, сборки и выполнения другой функциональности совместной работы над проектами по разработке программного обеспечения. Вместе с тем переход от традиционной модели создания и распространения программ к модели SaaS связан с изменением процессов разработки ПО, требующих теперь более короткого цикла выпуска обновлений и релизов при более высоком, чем при традиционной разработке, качестве выпускаемого продукта. Иначе говоря, модель разработки программ меняется с каскадной (waterfall) модели на модель скорой (agile) разработки. Если для первой важно полное понимание требований клиента еще до начала дизайна или разработки, то agile-модель направлена на учет изменений уже в процессе разработки, что позволяет реагировать на динамизм бизнес-среды и запросы клиентов. Все это означает, что разработчики должны не только быстрее публиковать приложения, но и более оперативно вносить изменения на протяжении всего жизненного цикла облачного приложения.

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

Таким образом, качество обслуживания и качество предоставляемого продукта могут стать определяющими в борьбе за место на рынке, где учитывается, в частности, такой показатель, как коэффициент «текучести» клиентской базы (churn rate) — процент подписчиков, решивших отказаться от сервиса. Повышение и поддержание качества сервиса являются одной из мер, направленных на снижение churn rate. Качество стало сегодня фактором повышения темпов разработки, что обусловлено наличием платформ, способных адаптироваться к новым требованиям, например, за счет добавления новой возможности без возврата назад и изменения существующего кода. Фундаментом для достижения требуемого качества решения является внедрение полноценного процесса управления жизненным циклом приложения (Aplication Lifecycle Management, ALM), отсутствие которого обычно ведет к дополнительным расходам, снижению потребительских характеристик решения и появлению негативных отзывов клиентов (рис. 1).

Рис. 1. Проблемы, возникающие при отсутствии полноценного процесса ALM

­

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

Для управления жизненным циклом приложений корпорация Microsoft предлагает Visual Studio Team Foundation Server (TFS) — центр организации совместной работы (рис. 2), в котором реализованы ключевые службы управления жизненным циклом:

• выпуск программного обеспечения и управление невыполненной работой;
• отслеживание рабочих элементов и интеграция с SharePoint Server для упрощения совместной работы группы;
• управление версиями;
• интеграция и развертывание;
• интегрированные службы отчетов и аналитики.

Рис. 2. Инструменты управления жизненным циклом приложений в Visual Studio

К средствам групповой разработки Visual Studio, интегрирующимся с TFS, относятся: Visual Studio Ultimate, Visual Studio Premium, Visual Studio Professional, Visual Studio Test Professional и Visual Studio Team Explorer Everywhere. Следует заметить, что TFS — открытая платформа, функции которой доступны в качестве стандартизированных Web-сервисов, поэтому аналогичную интеграцию можно провести и для сред и средств других производителей. Инструменты, входящие в состав Visual Studio и TFS, предоставляют средства и функции, необходимые для управления жизненным циклом приложения.

1. Планирование и отслеживание проектов. Visual Studio Application Lifecycle Management позволяет управлять потребностями клиентов, например, можно создать высокоуровневый план, дающий возможность разбить проект на отрезки (итерации), которые могут быть детализированы и выполняться и контролироваться по отдельности.

2. Проектирование и моделирование приложений. В Visual Studio Ultimate можно создавать модели с различными уровнями детализации и связывать их друг с другом, с тестами и планом разработки. Создание и разработка моделей в течение жизненного цикла приложения может быть составной частью процесса разработки. Visual Studio поддерживает UML, доменный язык (DSL), схему слоев, граф зависимостей и схему последовательностей, основанную на коде.

3. Сборка приложения. Team Foundation Builde Server позволяет реализовать автоматический процесс проверки и сборки приложения, обеспечить соответствие кода и приложения установленным правилам и требованиям качества.

4. Тестирование приложения. Выполняется с помощью ручных или автоматических тестов, включая тесты производительности и нагрузочные тесты. Visual Studio Ultimate и Visual Studio Test Professional позволяют повысить качество системы за счет полноценного этапа тестирования, который включает планирование, проведение тестов и отслеживание хода выполнения работ. Инструмент Microsoft Test Manager помогает определять работы по тестированию и управлять ими посредством плана тестирования, который содержит все необходимые наборы тестов, тестовые случаи и конфигурации. Созданный план позволяет измерять ход тестирования при выполнении тестов и формировать отчеты по оставшейся работе.

5. Развертывание в виртуальных средах. Позволяет реализовать сложные сценарии разработки и тестирования. Visual Studio Lab Management представляет собой расширение Microsoft Test Manager, позволяющее оптимизировать работу с технологией Hyper-V при тестировании, создании и разработке приложений в Visual Studio. Решение Visual Studio Lab Management интегрировано с System Center 2012 Virtual Machine Manager, благодаря чему можно управлять несколькими физическими компьютерами и виртуальными машинами.

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

Тестирование сервисов

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

Для создания непрерывного процесса сборки и тестирования необходимо автоматизировать всю процедуру, например, для этой задачи можно использовать Team Foundation Server

Реальная облачная среда

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

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

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

Еще одной особенностью локального эмулятора является работа с хранилищем: хранилище эмулируется средствами SQL Server, тогда как реальное облачное хранилище в Windows Azure — это самостоятельное распределенное хранилище, а не реляционная база данных. В связи с этим эмулятор не предназначен для работы с файлами, размер которых превышает 2 Гбайт (для Windows Azure допускается только 1 Тбайт). Кроме того, необходимо предусмотреть добавление фиктивных записей ко всем таблицам в эмуляторе хранилища, чтобы не возникало ошибок при обращении к ним.

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

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

Среды тестирования

В Windows Azure приложение можно развернуть в промежуточной или эксплуатационной среде. Обычный сценарий включает первоначальную публикацию в промежуточной среде с последующим переносом стабильной версии в эксплуатационную среду. Обе среды абсолютно идентичны и отличаются лишь URL-адресом для доступа к ним (в промежуточной адрес имеет вид http://bb7ea70c3be24eb08a08b6d39f801985.cloudapp.net, а в эксплуатационной — это обычный адрес типа http://пример.cloupapp.net). Это позволяет тестировать новые и обновленные приложения в закрытой среде. Также можно менять местами содержимое production и staging в обе стороны (с помощью Swap VIP — изменения виртуальных IP адресов), что позволяет выполнять откат приложения к предыдущей версии. При выполнении тестов рекомендуется разворачивать приложение в промежуточной среде, а после успешно пройденных тестов переносить (Swap VIP) приложение в эксплуатационную среду, для которой также надо провести ряд выборочных тестов, что позволит в случае проблем откатиться на предыдущую версию.

IntelliTrace

Часто процесс отладки может быть продолжением того или иного этапа тестирования, поэтому качественные и функциональные средства отладки как для локальной среды, так и промежуточной или эксплуатационной среды очень важны. Одно из таких средств — IntelliTrace, позволяющее в Visual Studio Ultimate записывать расширенные отладочные сведения для экземпляра роли, запущенного в Windows Azure. Если необходимо найти причину ошибки, то можно использовать журналы IntelliTrace для пошагового выполнения кода в Visual Studio так, как будто бы он выполняется в среде Azure. Решение IntelliTrace записывает ключевые данные выполнения и среды во время работы приложения в качестве размещенной службы в Windows Azure и позволяет воспроизводить записанные данные в Visual Studio. В Visual Studio 2012 можно установить IntelliTrace на эксплуатационный сервер без непосредственной установки самой Visual Studio, что позволяет не нагружать сервер ненужными компонентами и не приобретать дополнительную лицензию, получив при этом полные дампы поведения программы, состояние стека, перечень исключительных ситуаций, значения переменных и т. д. для выявления причин возникновения ошибки.

Модульное тестирование

Модульное тестирование позволяет проверить на корректность отдельные части приложения, изолируя их от всей программы. С точки зрения тестирования облачных сервисов основное внимание при модульном тестировании следует сосредоточить на поведении конкретного объекта класса, а не на взаимодействии этого объекта с другими компонентами приложения. Например, для Windows Azure любой тест, зависящий от хранилища Windows Azure, требует сложной настройки и дополнительно логики для обеспечения доступности корректных данных при выполнении тестирования. Вследствие этого разработчики специально для тестирования часто создают специальный модуль доступа к данным. В частности, это средство позволяет выполнять тестирование классов хранения данных независимо от облачного хранилища Windows Azure. Например, можно создать специальный модуль (wrapper) для компонентов хранилища Windows Azure, заменяющий хранилище Windows Azure фиктивными (mock) объектами.

Для выполнения модульных тестов в Visual Studio предлагается инструмент MSTest автоматического запуска и выполнения тестов. В Visual Studio 2012 предусмотрено средство непрерывного выполнения модульных тестов в фоновом режиме, в то время как разработчики продолжают работу над кодом, одновременно наблюдая результаты тестирования. Visual Studio поддерживает также сторонние инструменты модульного тестирования: TypeMock, Moq и RhinoMock, NUnit, xUnit.

Интеграционное тестирование

Интеграционное тестирование предназначено для проверки взаимодействия и интерфейсов между компонентами, подсистемами и т. п. После того как разработаны основные компоненты облачного приложения, необходимо создать интеграционные тесты. Если у приложения нет Web-интерфейса, то интеграционные тесты могут быть и функциональными. Для разработки интеграционных тестов может быть использован инструмент MSTest, но в отличие от модульного тестирования подход mock-объекты не применяется — тестирование полагается на реальную, а не фиктивную реализацию компонентов. Надо отметить, что для проведения интегрального тестирования в Windows Azure необходимо, чтобы все модули приложения уже были развернуты в локальной или облачной среде. Поэтому для проведения таких тестов важна автоматизация сборки и публикация решения, это может быть выполнено с помощью Team Foundation Server.

Функциональное тестирование

В ходе функционального тестирования определяется, решает ли приложение задачи, для которых оно было разработано, соответствует ли требованиям и ожиданиям пользователей. Обычно функциональное тестирование включает также тестирование пользовательского интерфейса. Для планирования и выполнения функционального тестирования облачных сервисов может быть использован инструмент Microsoft Test Manager Visual Studio 2012, причем в самом начале жизненного цикла приложения, начиная с публикации в среде эмуляции. В конце этапа испытаний необходимо создать тестовую публикацию приложения на реальную облачную среду Azure и провести финальное функциональное тестирование. Кроме выполнения ручного тестирования, можно использовать модуль Coded UI Test, позволяющий автоматизировать процесс тестирования интерфейса приложения.

С помощью Visual Studio Ultimate или Visual Studio Premium можно создавать автоматические тесты для отладки пользовательского интерфейса, называемые закодированными тестами. Эти тесты позволяют проверить, что после внесения изменений в код пользовательский интерфейс функционирует правильно. Они выполняются быстрее, чем ручные тесты, поэтому их можно выполнять чаще.

Нагрузочное тестирование

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

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

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

С появлением облака становится доступной новая возможность для выполнения нагрузочного тестирования — генерирование нагрузки непосредственно в облаке, и сегодня уже многие провайдеры предлагают подобные услуги. Инструменты Visual Studio могут быть в полной мере использованы для подобного сценария (рис. 3): агенты, генерирующие нагрузку, и контроллер, управляющий агентами, развертываются на виртуальных машинах в среде Windows Azure, а не локально.

Рис. 3. Нагрузочное тестирование в Visual Studio: агенты и контроллер располагаются в облаке

В общем случае при принятии решения о том, где будет генерироваться нагрузка, следует учитывать следующее:

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

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

Другая специфика нагрузочного тестирования непосредственно связана с особенностями архитектуры Windows Azure. Фактически при генерации нагрузки из Visual Studio основная ее часть приходится не только на приложение, но и на балансировщик нагрузки Windows Azure и на Fabric Controller (управляющее ядро виртуальной машины, на котором развернуто приложение или сервис), так как само облачное приложение или сервис располагается за их фасадом. Перенесение генерации нагрузки в облако позволяет разгрузить балансировщик и Fabric Controller.

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

В отличие от тестирования традиционного приложения, выполнить полноценное тестирование облачного приложения без автоматизации практически невозможно. Автоматизировать процесс тестирования (а значит, сборки, публикации на локальный эмулятор и публикации в облако) можно с помощью Team Foundation Server и его компонента Lab Management.

Автоматизация публикации для локального эмулятора может быть выполнена посредством утилиты CSRun, которая разворачивает приложение в эмулятор среды Windows Azure и управляет запущенной службой. Для автоматизации публикации в облако потребуются Windows Azure Service Management и Certificate API. Далее с помощью Team Foundation Server можно автоматизировать весь процесс — от сборки пакета Windows Azure до его тестирования и публикации в эксплуатационной среде. Team Foundation Server предоставляет полнофункциональные средства автоматизации создания сборок. Можно адаптировать Team Foundation Build и конфигурировать триггеры для ручного запуска процесса сборки, непрерывной интеграции, в режиме предварительной сборки или же запуска в соответствии с графиком. Режим предварительной сборки (gated check-in) обеспечивает работу команды в единой ветке кода, предотвращая потерю времени из-за ошибок. Сборка в этом режиме производится в изолированном хранилище до того, как код будет отправлен в основное хранилище. Новый механизм сборки поддерживает Windows Workflow с возможностями управления очередями на сборку, позволяя гибко настраивать, управлять и масштабировать среду сборки.

***

Интеграция во имя качества

 

Чарльз Стерлин: «В Visual Studio 2012 реализовано множество новых возможностей, но ключевым является переход от ориентации на функции к разработке на основе сценариев»

Чарльз Стерлин, менеджер программ в команде Microsoft Visual Studio Team System, уже более пятнадцати лет работает в области инструментальных средств разработки, однако начинал он карьеру как морской биолог. Получив статусы сертифицированного инженера и разработчика Microsoft, Стерлин перешел в корпорацию в качестве инженера поддержки средств разработки. Постоянно отвечая на одни и те же претензии пользователей, он увидел свою миссию в том, чтобы добиваться совершенствования инструментария разработки Microsoft, и о последних результатах работы в этом направлении Стерлин рассказал редактору журнала «Открытые системы» Наталье Дубовой.

Что вы вкладываете в понятие качества ПО?

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

Какое влияние такое представление о качестве оказывает на продукты Microsoft?

Исторически так сложилось, что Microsoft предоставляла инструменты отдельно для архитекторов, отдельно для разработчиков, отдельно для тестировщиков, обеспечивая при этом магистраль информационного обмена, которая поддерживала их взаимодействие между собой, однако теперь мы немного изменили свой подход и постарались комплексно взглянуть на весь процесс разработки. Такой подход мы называем разработкой на базе сценариев (scenario-based) в противоположность разработке на базе функций (feature-based). Нам удалось уйти от ориентации на функции к ориентации на взаимодействие, в результате чего все участники процесса: архитектор, разработчик, тестировщик — получают более целостную картину, видят, как отдельные компоненты взаимодействуют друг с другом и как совместно обеспечивают достижение конечной цели продукта. Например, в Visual Studio 2012 нашла воплощение интересная идея «раскадровки» (storyboarding), позволяющая всем участникам процесса быть в курсе того, что происходит. Инструмент Storyboarding потому и получил такое «киношное» название, что позволяет раскрыть перед всеми членами команды сценарий работы программы, подобно тому как на основе сценария снимается кино или ставится пьеса.

В работе со Storyboarding принимают участие разные персонажи: архитектор, тестировщик, разработчик, а также «владелец продукта» (product owner) — представитель компании-заказчика. Когда мы используем этот инструмент в своих разработках, на первом слайде Storyboarding всегда показываются фотографии участников процесса, поэтому всякий раз, приступая к разработке нового продукта, видим, что он будет создаваться для конкретного человека и в процессе будут принимать участие разные люди, выполняющие разные роли. С самого начала инструмент заставляет нас думать о том, что будут делать другие участники и как будет использовать продукт его владелец. И когда раскадровка будет создана, все участники процесса — архитектор, разработчик, тестировщик — будут четко понимать, какой продукт мы должны предоставить заказчику. Storyboarding представляет собой надстройку над Microsoft PowerPoint — вся раскадровка создается в привычном интерфейсе этой системы.

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

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

Появятся ли в Visual Studio 2012 новые инструменты тестирования?

Новый инструмент для запуска функциональных тестов в Visual Studio 11 позволяет исключить прерывания в работе и улучшить координацию с разработчиками. Старая версия Test Runner функционировала в синхронном режиме, и потому разработчику приходилось прерывать работу и ждать, когда инструмент закончит тестирование. Теперь он работает асинхронно, позволяя продолжать писать код, пока идет тестирование готовых модулей. При этом Visual Studio 2012 поддерживает различные среды тестирования, а не только инструменты от Microsoft.

В Visual Studio 2012 также реализована новая концепция исследовательского тестирования (exploratory testing). Если при традиционном подходе тестирование проводится в соответствии с формальным планом, определенным тестировщиком, то исследовательское тестирование не предполагает формальных тестовых кейсов, а проводит исследование приложения по определенным темам, заданным, например, владельцем продукта и отражающим различные аспекты работы будущей системы. Мы реализовали множество новых возможностей, но хочу подчеркнуть, что ключевым является изменение подхода к разработке — от ориентации на функции к разработке на основе сценариев. Такое изменение приведет к повышению качества разработок, поскольку исчезнут проблемы интеграции между разными этапами — целостный взгляд на все задачи позволит выявлять ошибки и неточности на возможно более ранних этапах разработки.

Новый подход лучше всего коррелирует именно с методиками скорой разработки?

Можно вести разработку в стиле agile и при этом не ориентироваться на сценарии. Так сложилось, что в Microsoft мы совмещаем эти два подхода и видим, что они очень гармонично сочетаются. В подходе, ориентированном на сценарии, мы постоянно думаем о том, для кого мы делаем разработку и как достичь поставленных целей наилучшим образом, и это соответствует принципам agile-методик. Поддерживает разработку в стиле agile и реализованная в Visual Studio 2012 новая функция обратной связи, которая упрощает взаимодействие команды разработчиков с заказчиками. Однако я не стал бы рекомендовать одновременно переходить на agile-методы и внедрять сценарный подход, поскольку это потребует от команды разработчиков сразу слишком больших изменений. Наша платформа разработки дает им возможность выбирать ту методику, которую они предпочитают, будь то Scrum, MSF или разработка в соответствии с требованиями CMMI, то есть традиционный «водопадный» подход.

Тестирование — один из ключевых этапов разработки облачных приложений, для которого семейство продуктов Visual Studio и Team Foundation Server предоставляет набор инструментов разработки, локального тестирования и публикации в облако, а также средства автоматизированного построения процесса тестирования в соответствии с методологиями Agile и CMMI.

Наталья Ефимцева (natale@microsoft.com) — эксперт по технологиям разработки ПО компании Microsoft (Москва).