2.6. Тестирование и верификация

Тестирование — важнейшая фаза процесса разработки. В общем случае можно дать сле­дующее определение.

Тестирование (testing) — это проверка соответствия требованиям.

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

2.6.1. Процесс контроля качества

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

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

2.6.2. Методы «белого ящика» и «черного ящика»

В случае контроля качества методом «черного ящика» приложение (или какая-либо его законченная часть) анализируется как целое. Этот метод используется для проверки того, что приложение (его часть) отвечает предъявляемым требованиям. Контроль качества ме­тодом «белого (стеклянного) ящика» осуществляется на уровне компонентов, из которых построено тестируемое приложение (его часть).

Чаще всего о методах «черного» и «белого ящика» говорят в контексте тестирования. Од­нако эти методы применимы и к другим способам контроля качества. Метод «белого ящи­ка» основан на рассмотрении анализируемого артефакта с точки зрения его структуры, формы и назначения; здесь применяются формальные методы и рассматриваемое в сле­дующем разделе инспектирование. Метод «черного ящика» задается вопросом «Обладает ли построенный объект требуемым поведением?». При этом для тестирования по методу «черного ящика» достаточно иметь набор пар «вход-выход», чтобы можно было прове­рить правильность поведения.

2.6.3. Инспектирование и обзоры

Инспектирование — это техника «белого ящика» для обеспечения качества. Инспектиро­вание состоит в проверке частей проекта (требований, результатов проектирования, про­граммного кода и т. п.) на наличие дефектов.

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

Принцип инспектирования может быть обобщен четырьмя правилами.

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

• Участие коллег. Инспектирование проводится внутри группы разработчи­ков программного обеспечения и не предполагает вовлечения отношений начальник - подчиненный. Инспектируется текущая работа, а не способно­сти ее автора. Автор несет ответственность только за конечный продукт, то­гда как инспектирование проводится до того, как работа сдана. Однако ра­бота, представленная автором для инспектирования, должна быть лучшим вариантом, но ни в коем случае не черновиком. Было бы пустой тратой ре­сурсов группы искать, находить и описывать дефекты, которые автор, при­ложив некоторые усилия, в состоянии найти сам.

• Распределение ролей. Каждый из участников проекта берет на себя одну из следующих ролей. При нехватке кадров один человек может выполнять сра­зу две роли. Обычно ведущий может одновременно быть и секретарем. Од­нако для достижения беспристрастной проверки автор не должен выполнять никаких других ролей.

• Ведущий ответственен за правильное проведение инспектирования. Ведущий также является инспектирующим.

• Автор несет ответственность за свою работу и за исправление всех найденных в ней дефектов. Автор является одновременно и инспек­тирующим.

• Секретарь отвечает за учет описания и классификацию дефектов, как это принято в команде. Секретарь также участвует в инспектирова­нии.

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

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

Обзор - это собрание, на котором обсуждается как уже завершенная, так и текущая рабо­та.

Примером тому является обзор, на котором может обсуждаться альтернативная архитек­тура приложения. Хотя обзоры являются неотъемлемой частью проекта, они не требуют такой детальной подготовки, как инспектирование. К тому же участникам обзоров, в от­личие от ситуации с инспектированием, не надо играть никаких ролей. Тем не менее, об­зоры необходимо проводить, причем регулярно с участием максимального возможно чис­ла разработчиков. Обзоры задают «пульс» проекта, подтверждают его жизнеспособность и служат фактором положительной мотивации персонала.

Регулярные обзоры — это самое надежное средство добиться того, чтобы все были «в курсе» и могли избегать ошибок, порождаемых непониманием общего контекста проекта.