Методология и практика тестирования ПО

СЕМИНАРЫ

Вряд ли имеет смысл говорить о важности тестирования в общем процессе разработки ПО, ведь давно известно, что реализация каждого этапа жизненного цикла приложений является необходимым условием для появления качественного программного продукта. Но, сказав слова о равенстве всех видов работ, нужно признать: в течение всей истории разработки ПО - а она насчитывает более 50 лет - тестирование выступало в роли падчерицы, которой достается самая трудоемкая, рутинная и непрестижная работа*. Далеко за примерами ходить не нужно: авторские права разработчиков закреплены законодательством, их имена можно при желании легко узнать. А что нам известно о тех, кто тестирует приложения, и это при том, что именно на их долю приходится в среднем около трети затрат по созданию ПО?

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

Нужно отметить парадоксальную ситуацию: при обилии методической литературы и курсов по проектированию и кодированию ПО наблюдается практически полное отсутствие материалов по тестированию и отладке! Как сказал известный американский автор книг по разработке ПО Джон Роббинс: "Даже если у вас есть специальное образование, бьюсь об заклад, что вы никогда не сталкивались со специальным курсом, посвященным отладке" (см. PC Week/RE, N 9/2004, с. 61).

Однако ситуация несколько меняется, одним из свидетельств чего являются проведенные в конце февраля в Москве компанией "Аплана" при поддержке московского представительства IBM практические семинары "Эффективная организация процессов тестирования в ходе разработки и сопровождения корпоративных систем". Тема оказалась настолько актуальной, что Центр технологий IBM не смог вместить всех желающих в один день, поэтому семинар пришлось проводить дважды. Изначально мероприятие было ориентировано на ИТ-подразделения корпораций, ведущие собственные внутрифирменные разработки, однако большой интерес к нему проявили и специализированные фирмы - создатели заказного и тиражируемого ПО. В общей сложности в семинарах приняли участие более 80 руководителей и специалистов корпоративных и ведомственных центров разработки и внедрения, а также ИТ-компаний.

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

Особенности организации тестирования

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

· неудовлетворительное организационное, методическое и техническое обеспечение всего процесса разработки;

· сжатые сроки исполнения проекта;

· сложность проекта, большое число требований и их изменений по ходу работы;

· недостаточная квалификация разработчиков.

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

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

Виды тестирования по методологии Rational Unified Process

Говоря об особенностях процедур тестирования в ИТ-подразделениях, наверное, надо выделить три основных, весьма противоречивых аспекта.

1. Объем тестирования очень велик. Дело в том, что именно в случае внутрифирменных разработок очень часто вносятся изменения (многие слушатели семинара говорили о непрерывном потоке корректировок по запросам подразделений-заказчиков). А ведь, как известно, классическое правило разработки ПО гласит: изменение одной строки кода требует повторного проведения полного цикла тестирования.

2. Как это ни цинично звучит, но разработчики очень часто не заинтересованы в снижении количества ошибок в ПО, передаваемом в эксплуатацию. Руководство компаний оценивает работу ИТ-отдела в первую очередь по его умению уложиться в бюджет (время и деньги), а проблемы эксплуатации программ его волнуют значительно меньше. Поэтому получается, что увеличение объемов тестирования повышает издержки ИТ-подразделения без выделения соответствующих ресурсов со стороны начальства**.

3. Проведение качественного тестирования требует наличия специалистов и инструментов соответствующего профиля. А из п. 2 следует, что ИТ-подразделениям держать собственные группы тестировщиков просто невыгодно.

Общие вопросы тестирования

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

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

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

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

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

Тестирование - процесс также итерационный. После обнаружения и исправления каждой ошибки обязательно следует повторение тестов, чтобы убедиться в работоспособности программы. Более того, для идентификации причины обнаруженной проблемы может потребоваться проведение специального дополнительного тестирования. При этом нужно всегда помнить о фундаментальном выводе, сделанном профессором Эдсжером Дейкстрой в 1972 г: "Тестирование программ может служить доказательством наличия ошибок, но никогда не докажет их отсутствие!".

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

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

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

Ручное и автоматизированное тестирование. По мере повышения сложности проекта доля задач, решаемых с помощью автоматизированных методов (использование скриптов, программ-имитаторов и пр.), неуклонно растет. Подавляющее число задач нагрузочного тестирования может решаться исключительно с их помощью.

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

Решение проблемы - центры тестирования

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

В рамках семинара специалистами компании "Аплана" рассматривались возможности автоматизированного тестирования на примере средств тестирования IBM Rational, которые в настоящее время получили значительное распространение среди российских разработчиков (см. врезку "Методология и инструментарий IBM Rational"). Обсуждались также различные сценарии их применения при создании ПО корпоративного уровня. Среди конкретных программных продуктов особое внимание было уделено наиболее популярной сегодня системе IBM Rational Robot.

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

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

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

· выполнение полного комплекса работ по тестированию ПО или отдельных его этапов на стенде Центра или на площадке заказчика;

· консалтинг и обучение заказчиков по вопросам организации процессов тестирования внутри организации;

· аудит тестирования, проводимого сторонними компаниями;

· аутсорсинг технических и программных ресурсов для проведения тестирования.

В заключение стоит отметить еще один любопытный момент: проведя семинары, компания "Аплана" одной из первых в нашей стране фактически объявила о продвижении нового вида услуг в области разработки ПО. Первопроходцы же довольно часто попадают в двойственное положение. Так и на этом семинаре: бесплатный курс консалтинга и обучения пришлось дать не только потенциальным заказчикам, но и конкурентам... 4*Не забывая о значимости вопросов тестирования, нужно помнить о том, что один из классиков современных методов разработки ПО, голландский профессор Эдсжер Дейкстра еще в конце 60-х годов прошлого столетия обосновал необходимость применения методов структурного программирования, исходя именно из задачи снижения трудозатрат на тестирование.**Специфика тестирования заключается еще и в том, что в отличие от других этапов разработки ПО, имеющих достаточно формальные критерии их окончания, данный процесс, в общем случае, бесконечен. Ведь, как известно, "каждая последняя найденная ошибка является на самом деле предпоследней". Правильно определить реально необходимый объем тестирования - это отдельная непростая задача.***Говоря о тестировании, надо также обязательно упомянуть о важности верификации ПО (систематической процедуры проверки правильности). Тонкое различие между этими понятиями заключается в том, что тестирование базируется на возможности сравнения полученных результатов с эталонными. Однако есть достаточно большой класс задач, когда эталонных данных попросту нет. Классический пример такого варианта - построение сложных математических моделей с решением десятков тысяч дифференциальных уравнений, хотя аналогичные ситуации возникают и тогда, когда имеешь дело с бизнес-приложениями. В этом случае требуется включение в ПО дополнительных функций и проведение специальных исследований, чтобы у пользователя появилась уверенность (пусть даже не 100-%), что программа действительно работает правильно.