Глава 13: Объединяющая 387

Почти наверняка окажется, что большая часть жалоб связана со срав­нительно небольшим количеством проблем. Это хорошо известный принцип Парето (Pareto Principle, Джуран и Грайне (Juran & Gryna, 1980), Мак-Кейб и Шалмейер (McCabe & Schulmeyer, 1987)). Собрав данные, отсортируйте жалобы в порядке убывания их частоты. (Не удивляйтесь, если окажется, что этот порядок для разных источников окажется различным. Обозрева­тели отмечают иные проблемы, нежели пользователи, пишущие письма и звонящие в отдел технической поддержки. А мнения пользователей, ото­бранных случайным образом и опрошенных сотрудниками компании, бу­дут отличаться от мнений первых двух категорий.) На наш взгляд, самым удобным представлением информации являются таблицы жалоб пользова­телей, отсортированных по частоте. Но есть и более классический подход

— составление диаграммы Парето (Pareto Chart), лучше всего описанной в книге Уолтона (Walton, 1986). Если возможно, приведите в таблицах циф­ры затрат на техническую поддержку (затраты на чтение писем и ответы на них, средняя стоимость телефонного звонка, среднее время телефонного разговора с пользователем о каждой из проблем и т.п.).

Анализ пользовательского интерфейса

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

Обсуждение даты начала тестирования

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

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

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

388 Часть III: Управление проектами и группами

Что еще включает процесс приготовления к тестированию

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

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

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

Реализация базовых функций

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

Программирование после реализации базовых функций

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

Тестирование после реализации базовых функций

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