Глава 3: Типы тестов ... 51

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

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

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

Замечание

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

Позвольте предложить вам несколько советов.

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

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

52 Часть I: Основы

• Студентам, планирующим в дальнейшем заниматься тестированием программного обеспечения, мы бы рекомендовали подытожить ин­формацию этой главы, представив ее в виде схемы, похожей на при­веденную на рис. 13.3. Не тратьте слишком много времени на терминологию разработчиков, ограничьтесь теми понятиями, которые объяснит вам преподаватель. В дальнейшем для изучения главы 13 мы рекомендуем сделать учебное пособие в виде таблицы, представлен­ной на рис. 13.4, и включить в него материал этой главы.

Обзор

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

• Обзор стадий разработки

• Стадии планирования

• Тестирование на этапе планирования

• Стадии проектирования

• Тестирование на этапе проектирования

• Тестирование "стеклянного ящика" на стадии кодирования

• Регрессионное тестирование

• Тестирование "черного ящика"

• Сопровождение

Серьезные программные продукты редко разрабатываются одиночками: обычно этим занимаются группы людей, иногда довольно многочисленные. В такой группе, называемой командой разработчиков (development team), у каждого сотрудника своя роль. Даже если вам приходилось создавать про­граммы абсолютно самостоятельно или в паре с приятелем, это просто означает, что вы по очереди или одновременно выполняли функции всех необходимых членов команды. Давайте рассмотрим стандартный набор функций, выполняемых членами команды разработчиков, предположив для простоты, что каждая роль принадлежит отдельному сотруднику. Конечно, на практике в большинстве маленьких компаний сотрудники часто выпол­няют по нескольку функций.

• Руководитель проекта (project manager, также называемый software development manager или producer) отвечает за качество программно­го продукта, планирование работ и составление бюджета разработ­ки. Мы будем считать, что все отчеты проектировщиков и разработчиков непосредственно передаются ему.

• Проектировщиков (designers) продукта может быть несколько и среди них следующие.