“Важный тренд в разработке ПО — рост популярности методов Agile”

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

Именно эти изменения в процессах разработки оказались в центре внимания прошедшей в конце марта в Москве очередной ежегодной конференции Microsoft Quality Assurance Day. На ней с основным докладом выступил президент компании RBCS Рекс Блек, который известен в среде программистов как гуру в области тестирования, автор целого ряда книг по этой тематике, активно выступающий с лекциями и семинарами на профильных мероприятиях по всему миру. С ним беседует обозреватель PC Week/RE Андрей Колесов.

PC Week: Вопросы управления качеством ПО часто ассоциируют с задачами тестирования. Насколько такая связь верна?

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

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

PC Week: Тестирование — тема из разряда вечных. Но порой кажется, что всё, что говорится сегодня, — это повторы того, что уже давно было сказано. И возникает вопрос: происходят ли какие-то качественные изменения в области тестирования ПО?

Р. Б.: Я согласен, что во многом мы так или иначе повторяем уже известные вещи. Но сразу подчеркну необходимость делать это, причем регулярно: ведь постоянно меняется сама аудитория. При этом, конечно, можно и нужно говорить о появлении всё новых и новых моментов в тестировании — как в плане техники этого дела, так и его организации. Если посмотреть на прогресс за последние 20—40 лет, то можно точно констатировать переход от схемы “натурального хозяйства”, когда написанием кода и его тестированием занимались во многом одни и те же люди, к системе разделения труда. А это потребовало создания не только новых методов управления взаимодействием участников процесса разработки, но и совершенно иных технических средств тестирования. Например, можно уверенно говорить, что сегодня инструменты тестирования позволяют обнаруживать ошибки на более ранних этапах разработки ПО, что они дают возможность не только констатировать факт наличия дефекта, но и определять его причину.

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

Заметно также то, что повысилась роль тестирования в процессе разработки ПО. Тут качественные изменения видны по уровню осведомленности людей о данной проблематике. Причем это касается не только внутренних участников процесса разработки, но и внешних — потребителей, бизнес-руководителей. Налицо повышение статуса тестировщика в общей команде создателей ПО. Это можно проиллюстрировать на таком простом примере: в 1990-х уже были очень популярны различные программы сертификации разработчиков ПО, но для тестировщиков таких предложений просто не было. Лишь в 1999 г. появилась такая программа — ISTQB (International Software Testing Qualifications Board), и сейчас более 220 тыс. человек по всему миру имеют ее сертификаты.

PC Week: В последние годы можно наблюдать рост популярности методов Agile, при этом порой и выступающие, и слушающие люди часто представляют тему как нечто принциально новое, ранее невиданное. Но ведь это, конечно, не так. Методы быстрой разработки существуют ровно столько, сколько существует сама разработка ПО. Что вы можете сказать по этому поводу?

Р.Б.: Конечно, многие методические темы в ИТ (и не только в ИТ) исторически развиваются волнами. В предыдущие, наверное, лет 15—20 доминировали идеи последовательной этапности с достаточно жесткими схемами управления разработкой. Сейчас растет волна Agile, причем я оцениваю сегодняшнее нахождение “синусоиды” примерно в точке пересечения нуля, волна будет продолжать расти.

Но напомню, что исторический процесс все же идет не по кругу, а по спирали, то есть мы приходим, казалось бы, в ту же точку, но на качественно ином уровне. Все же сама разработка ПО сегодня — это совсем не то, что было 20, а тем более 30 или 40 лет назад. Например, применять методы Agile для группы в 3—5 человек, сидящих в одной комнате, — это одно, а использовать их в проектах, где задействовано десятки и даже сотни программистов, разбросанных по всему миру, — это совсем другое дело.

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

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

PC Week: В среде сторонников модели Open Source бытует устойчивое мнение, что именно этот подход к разработке ПО имеет преимущества перед проприетарными схемами в плане качества кода — за счет вовлечения огромного числа независимых программистов, которые выполняют и функции тестировщиков. A каково ваше мнение?

P. Б.: Да, такое представление существует, но вы правильно заметили, что оно распространено именно внутри этого сообщества, а вне его, в среде независимых экспертов, оно не пользуется серьезной поддержкой. Я также не приверженец того, что повышение качества можно обеспечить простым увеличением числа тестировщиков. И это мое мнение основано на фактах, в том числе на данных разного рода статистики. Можно провести массу аналогий (типа “ополчение” и “профессиональная армия”) или вспомнить народные мудрости, в том числе русскую “У семи нянек дитя без глазу”.

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

PC Week: Идеи Agile выглядят вполне понятно и привлекательно. Но не кажется ли вам, что на пути их более широкого применения стоят не только объективные трудности, но субъективные моменты, включая позицию менеджеров, которые не хотят брать на себя дополнительную ответственность?

Р. Б.: Я как раз на этот момент делал акцент в своем выступлении на конференции. Каждый метод имеет свои плюсы и минусы, выигрывая в одном, вы можете проиграть в другом. Agile позволяет сократить затраты на разработку, в том числе по срокам, но зато у этих методов более высокие риски в плане достижения результатов. Точнее даже не так: Agile как раз позволяет получать более гарантированный результат, поскольку проект выполняется шагами, на каждом из которых имеется полезный результат. Но управление Aglie-проектом является более сложным, тут нужна более высокая квалификация менеджеров (да и разработчиков тоже), а от управленцев требуется взятие на себя большей ответственности.

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

PC Week: Вернемся к вопросам тестирования. Какова все же сегодня роль группы тестирования в общем коллективе разработчиков, как эта роль меняется в последние годы?

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

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

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

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

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

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

Так вот, по моим оценкам, лишь у 10% компаний или проектов имеется соответствие между тем, что нужно делать, и тем, что непосредственно реализуется. У остальных 90% заметен существенный разрыв, причем совсем не в позитивном направлении: тех, кто уделяет вопросам тестирования внимания больше, чем требуется, просто нет.

PC Week: Тестирование ПО ведется постоянно, при этом есть разные этапы, на которых задействованы разные группы тестировщиков. Сначала к поиску ошибок приступает сам программист, потом этим занимается профессиональный тестировщик, на этапе бета-тестирования к работе подключается избранная группа пользователей, а затем, после выхода продукта на рынок, — все конечные пользователи. Есть ли какие-то критерии перехода от одного этапа тестирования к другому?

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

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