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

Это можно видеть и на примере прошедшей в конце февраля в Москве конференции Microsoft Quality Assurance Day (“день гарантии качества”) в рамках серии мероприятий ALM Roadshow, проводимых в России корпорацией Microsoft. Центральной фигурой конференции стал выступивший с двумя докладами Брайан Келлер — ведущий технический евангелист Microsoft, известный в мире эксперт в области ALM и Visual Studio. О проблемах повышения качества ПО и роли тестирования в общем процессе создания приложений с ним беседует обозреватель PC Week/RE Андрей Колесов.

PC Week: Какую основную идею вы хотели донести до аудитории конференции?

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

PC Week: Но ведь это довольно известная истина. Или вы считаете, что российские разработчики о ней не знают?

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

Второй аспект проблемы связан со спецификой положения Microsoft на этом рынке. Мы очень давно занимается созданием средств разработки, фактически — чуть ли не с начала деятельности компании в 1980-х. Но исторически сложилось так, что до относительно недавнего времени мы делали основной акцент на собственно разработчиках ПО, программистах. По сути лишь с выпуском Visual Studio 2005 корпорация четко обозначила курс на создание полномасштабной ALM-платформы, охватывающей все этапы создания и сопровождения ПО. Поэтому для традиционного сообщества пользователей наших инструментальных средств идея необходимости комплексного подхода к разработке является свежей. Если вы посмотрите на динамику развития Visual Studio за последние годы, то увидите, как быстро расширяются в этой платформе именно возможности тестирования ПО, причем в качестве интегрированной части всего ALM-процесса.

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

PC Week: Что нового для тестировщиков появилось в последней версии Visual Studio 2010?

Б. К.: Хотя развитые средства тестирования появились, как я уже сказал, в версии 2005 и потом постоянно развивались, все же я должен признать, что до сих пор в плане поддержки командной работы (за это в нашей платформе отвечает Team Foundation Server) основной акцент делался на роли архитектора, разработчиков и менеджера проектов. Тестировщики стояли тут несколько особняком, этот этап рассматривался как автономный. Но в версии 2010 эта ситуация радикально поменялась, фокус был сделан как раз на роли тестировщика. При этом главное, что мы приложили большие усилия по интеграции тестирования в единый ALM-цикл, чтобы обеспечить прозрачность процесса поиска и устранения ошибок, обратную связь между тестировщиком и разработчиком.

PC Week: На какую целевую группу направлены ваши “послания” — на самих тестировщиков, на руководителей проектов или на заказчиков?

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

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

PC Week: Какие конкретно новшества для тестировщиков появились в последних версиях Visual Studio?

Б. К.: В версиях 2005 и 2008 были средства тестирования, но они были предназначены больше для разработчиков, а не для профессиональных тестировщиков. Речь, в частности, идет о нагрузочном и модульном тестировании, о профилировании. В вышедшем год назад Visual Studio 2010 появились инструменты ручного тестирования и различный сопутствующий функционал для планирования работы, обеспечения взаимодействия тестировщика с разработчиком.

PC Week: Но ведь ручные методы — это, кажется, далеко не самые современные способы тестирования?

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

PC Week: Вы сказали, что для Microsoft направление профессионального тестирования является сравнительно новым. Как вы оцениваете свои сегодняшние позиции в этой сфере создания ПО?

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

PC Week: А что вы можете сказать о вашем видении проблемы тестирования на уровне комплексных систем?

Б. К.: Если говорить об этом уровне, то конечно же любой профессионал в первую очередь вспомнит о средствах HP Mercury. Мы также двигаемся в этом направлении, но опять же с учетом своей специфики и возможностей. Mercury абстрагируется от разработки, фокусируясь исключительно на тестировании. Мы же идем от разработки ПО. Более того, мы идем от нашей платформы .NET, от нашего глубокого знания ее внутреннего устройства. У нас есть представление о внутреннем устройстве кода, т. е. приложение для нас — это не просто “черный ящик”. Это дает нам мощное конкурентное преимущество в плане обеспечения связи между тестировщиком и разработчиком и эффективного процесса обнаружения причин ошибки и ее устранения. Например, мы можем довольно точно оценить степень покрытия тестами программного кода, в том числе в ситуации, когда в программу вносятся те или иные изменения. У независимых поставщиков средств тестирования, которые не имеют глубокого представления о платформе исполнения, таких возможностей нет.

PC Week: На конференции вы представили слушателям метод исследовательского тестирования [exploratory testing]. В чем его особенности и что он дает создателям ПО?

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

В последние годы исследовательское тестирование стремительно завоевывает популярность благодаря доказанным преимуществам: быстрый поиск ошибок, уменьшение временных потерь на документирование. Но все же в отрасли есть мнение, что данный метод не подходит для крупных проектов. При этом в качестве его недостатков порой называют нехватку метрик и отслеживаемой информации об ошибках. Часто его ассоциируют с подходом monkey testing [“обезьянье тестирование”, набор хаотичных массовых тестов]. Я считаю, что такие представления об исследовательском тестировании неверны, они относятся к разряду ошибочных мифов. В своем докладе на эту тему я в качестве примера привел данные нашего подразделения Visual Studio ALM о внутреннем проекте Microsoft, в котором применялось исследовательское тестирование при разработке большого корпоративного продукта с несколькими тысячами пользователей; длительность его разработки составила два года, а команда разработчиков превышала сто человек.

PC Week: Еще два вопроса. Каким образом люди становятся тестировщиками, как они приходят в эту профессию? И насколько престижна эта роль в единой команде создателей ПО?

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

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

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

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

PC Week: Спасибо за беседу.