Канер С. Тестирование программного обеспечения

Подождите немного. Документ загружается.

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

Программирование на этапе проверки целостности

Задача программистов по-прежнему остается неизменной — они ис-

правляют ошибки, выявленные на этой последней стадии проекта. Возмож-

но, дорабатывается также демо-версия программы. Затем вся работа

архивируется, делаются последние записи, все приводится в порядок.

Тестирование на этапе проверки целостности

Многие компании к началу этого этапа прекращают тестирование про-

граммы. Фактически это просто означает, что описанная в этом разделе

работа выполняется на предыдущем этапе.

В других компаниях определяется отдельный этап последнего тестиро-

вания продукта перед выпуском его в производство. Такое тестирование

часто называют проверкой целостности. Иногда проверку целостности

выполняет группа маркетинга или другая группа тестирования. Вот ее цели.

•

Оценить надежность программы в первый день ее использования.

Для этого с продуктом работают так, как это будет делать сам

пользователь в первый день его эксплуатации. Особое внимание уде-

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

тировщики пытаются представить себе проблемы, с которыми может

столкнуться большинство новых владельцев программы.

•

Предупредить негативные оценки обозревателей. Это последний

шанс что-то исправить до того, как обозреватели наткнутся на ос-

тавшиеся огрехи.

Последняя проверка целостности предполагает базовое, а не нагрузоч-

ное тестирование. Тестировщик делает то, что будет делать типичный по-

купатель или обозреватель, знакомясь с новым продуктом. Он не пытается

вывести его из строя, а просто изучает, как он работает. Однако если про-

верка целостности выполняется кем-то другим, подготовьте для этого че-

ловека все тестовые материалы, включая план тестирования, отчеты о

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

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

ваться списком вероятных ошибок, аналогичным приведенному в конце

этой книги. В этом случае он будет по очереди выбирать ошибки из этого

списка и выяснять, могли ли они быть выявлены проведенными тестами.

После завершения проверки целостности начинается подготовка уста-

новочных дисков. Для этого берутся новые никогда не бывшие в исполь-

зовании диски, форматируются и проверяются на вирусы и сбойные

секторы. Проверяется объем свободного пространства на каждом диске. За-

тем на диски копируются установочные файлы. Результирующие файлы

сверяют с исходными, чтобы убедиться, что копирование прошло полно-

стью успешно. Затем диски снова проверяются на вирусы.

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

После подготовки образцов дисков программа устанавливается с них на

компьютер. Эта процедура гарантирует, что установочная утилита работа-

ет правильно и все необходимые ей файлы успешно найдены. (Особенно

это важно в случае, если какие-то из файлов не поместились на один диск

и в последнюю минуту были перенесены на другой.)

Кроме этой основной работы, в ходе выпуска продукта выполняется

следующее:

• Архивация образцов установочных дисков.

• Архивация исходного кода.

• Распространение среди заинтересованных сотрудников последних

дополнений списка отложенных проблем и сбор подписей на необ-

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

• Обычно массовое производство установочных дисков начинается с

того, что выпускаются их первые несколько наборов и возвращаются

вместе с образцами назад для тестирования. Получив эти первые

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

а затем установите программу на компьютер с одного из них. Ско-

пируйте все файлы с одного из наборов дисков на другие диски,

чтобы убедиться в отсутствии ошибок ввода/вывода. И еще раз про-

верьте их на вирусы.

Выпуск

Убедившись, что дупликатор правильно копирует диски, можно начи-

нать их массовое производство. Готовые диски упаковываются вместе с

другими материалами в коробки и запечатываются.

Если у вас остались хоть какие-то сомнения, продолжайте тестирование!

Продукт попадет в руки пользователей не завтра, а значит, у вас есть еще

время, возможно, несколько дней или недель. Если за это время будут

найдены катастрофические ошибки, можно будет даже остановить произ-

водство. Конечно, это дорого обойдется компании, но выпуск некачествен-

ного продукта может обойтись значительно дороже.

Другим выходом из ситуации может быть немедленный выпуск новой

исправленной версии продукта. Пользователи купят продукт как есть, а

вскоре получат его исправления.

Автоматизация тестирования на этом этапе полностью прекращается.

Исключение могут составлять лишь тесты, которые просто нельзя выпол-

нить вручную. На этапе выпуска продукта все ваше внимание должно быть

сосредоточено только на выполнении тестов — ни планирования, ни доку-

ментирования.

Еще одной вашей важной задачей на данном этапе является подготов-

ка к тестированию следующего выпуска. Придется ли этим заниматься вам

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

или кому-то другому, эта работа может, а значит, и должна быть очень

хорошо подготовлена. У вас сейчас максимум знаний о продукте, макси-

мум опыта, вы помните каждую деталь. Когда придет время следующего

выпуска, многое уже позабудется, тем более, что это может быть не ско-

ро и в промежутке вы будете заняты на другом проекте.

Наведите порядок в документации. Напишите заметки и рекомендации

для специалиста, который будет работать после вас. Распечатайте списки

имеющихся тестовых материалов, снабдив самые важные записи подробны-

ми комментариями. Ваша цель — максимально облегчить тестирование сле-

дующего выпуска продукта.

После выпуска

Во многих компаниях по окончании работ проводится их заключитель-

ный анализ. Вас могут попросить подготовить отчет обо всем, что проис-

ходило в ходе работы над проектом: что прошло удачно, что нуждается в

доработке или усовершенствовании, каковы были самые серьезные пробле-

мы и какие важные работы так и не были выполнены. Этот отчет может

быть подан в письменном виде или прочитан на ближайшем совещании.

Для вас как для руководителя группы тестирования заключительный

отчет о проведенной работе является важным политическим документом.

Будучи правильно составлен, он принесет вам большую пользу, а в против-

ном случае может нанести большой вред. Поэтому, несмотря на крайнюю

усталость, подготовьте его очень тщательно. Следующие несколько советов

помогут вам выбрать правильный подход.

• Отчет должен быть конструктивным. Главным образом пишите о

том, что можно улучшить, а не о том, что было сделано плохо.

• Сделайте особый акцент на достижениях и успехах. Выделите луч-

шие идеи, расскажите, кто и чем помог облегчить вашу работу.

• Не делайте вид, что проблем не существует вовсе. Если програм-

мист, исправляя одно, постоянно портил другое, не стоит утверж-

дать, что исправление ошибок проходило прекрасно и он хорошо

делал свою работу. Можно вообще об этом не упоминать или опи-

сать проблему в мягкой безличностной форме, но не стоит отрицать

ее существование и вводить в заблуждение слушателей или читате-

лей отчета. Если человек работал плохо или не выполнял своих обя-

занностей, утверждать, что все хорошо, было бы неразумно.

• Избегайте жалоб. Не указывайте ни на кого пальцем. Не извиняй-

тесь и не оправдывайтесь. Не становитесь в позицию защиты.

• Никогда не говорите и не намекайте, что кто-то должен быть уво-

лен.

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

• Не критикуйте дизайн и не вспоминайте о старых ошибках.

• Говорите о проблемах в форме констатации, в нейтральной безэмо-

циональной манере.

• Если вы считаете выпущенный продукт плохим, хорошо подумайте,

прежде чем сказать об этом именно сейчас. Не забывайте, что тес-

тировщик сознательно настраивается на поиск недостатков, это

обязательная психологическая составляющая его работы. Тестиров-

щик должен считать продукт плохим, желать его сбоев. Поэтому

ваша оценка может быть необъективной, и вполне вероятно, что

какое-то время спустя она изменится.

Однако, даже если продукт и в самом деле халтурный, заявлять об

этом вовсе не обязательно. Если вы хорошо сделали свою работу,

руководству и так об этом известно. Это вопрос его политики и

внутренних стандартов качества. Может быть, стоит просто улыб-

нуться и поискать другую работу.

"Хорошо подумайте" вовсе не означает "никогда не говорите". Если,

на ваш взгляд, вопрос о стандартах качества или процессе разработ-

ки может быть конструктивно решен и это пойдет компании на

пользу, поднимайте его.

• У слушателей или читателей вашего отчета ни в коем случае не

должно сложиться мнение, что вы плохо сделали свою работу. Са-

мокритика полезна, но не в данной ситуации. И она всегда должна

сопровождаться конструктивными решениями.

• Будет замечательно, если ваш отчет сможет сначала прочитать хоро-

ший друг, мнению которого вы доверяете.

Глава

Управление

группой

тестирования

Назначение этой главы

Поднятые в этой главе вопросы представляют интерес главным образом для

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

пособие для руководящего персонала. Скорее, это описание нашего соб-

ственного опыта, принципов и приемов, помогавших нам в работе, и оши-

бок, которых легко можно избежать.

Наше видение роли группы тестирования в обеспечении качества разрабаты-

ваемого компанией продукта очень отличается от общепринятого. Традици-

онно считается, что за качество целиком и полностью отвечает руководство

компании. Однако, на наш взгляд, руководителю группы тестирования вов-

се не обязательно ограничиваться принятыми в компании стандартами каче-

ства, особенно если эти стандарты откровенно невысоки. Именно с позиции

личной ответственности тестировщиков за качество их работы и самых вы-

соких критериев его оценки и рассматриваются все поднимаемые в данной

главе вопросы.

Обзор

Говоря о руководстве группой тестирования, необходимо в первую очередь

определить ее задачи. Какую роль она играет в компании? Традиционно

руководители групп тестирования стремятся осуществлять полный контроль за

качеством продукта. Наши представления о собственной роли несколько

скромнее — мы рассматриваем группу тестирования как техническую служ-

бу, в задачи которой входит выполнение определенных работ и предостав-

ление остальным участникам проекта определенной информации.

Глава 14: Управление группой тестирования 429

Многие считают, что независимые тестовые лаборатории могут служить

хорошим дополнением или даже альтернативой собственным командам

тестировщиков. Хорошим дополнением они, возможно, и являются, но уж

никак не альтернативой. Группа тестирования держит под контролем все

работы по тестированию всех продуктов компании, включая и работу неза-

висимых тестовых лабораторий.

Далее в главе рассматривается составление календарного плана работ и

способы оценки их производительности. Как оценить время, необходимое для

полного тестирования продукта? Как защитить своих подчиненных от авралов,

когда приходится либо бесплатно работать день и ночь, либо заслужить ре-

путацию людей, способных отказаться помочь компании в самый трудный

момент?

Последняя часть главы посвящена подбору персонала. Каких специалистов

необходимо будет нанять? Какой должна быть их квалификация? Как в самых

тяжелых ситуациях поднять моральный дух своих подчиненных?

Библиография

Если вам еще никогда не приходилось занимать руководящие должности,

почитайте книгу Друкера (Drucker, 1966).

На наш взгляд, для руководителя группы тестирования понимание современ-

ных тенденций в области работы над качеством гораздо важнее, чем даль-

нейшее изучение литературы по тестированию. Этой теме посвящены книги

таких авторов, как Деминг (Deming, 1982), Фейгенбаум (Feigenbaum, 1991),

Ишикава (Ishikawa, 1985), Джуран (Juran, 1989).

Техника проведения совещаний хорошо описана в книгах таких авторов, как

Дойл и Страус (Doyle & Straus, 1976), Фридман и Вейнберг (Freedman &

Weinberg, 1982). Вам наверняка придется вести множество переговоров. Нам

нравится, как об этом пишут Фишер и Эри (Fisher & Ury, 1981) и Каррас

(Karras, 1986).

Главной работой сотрудников группы тестирования является поиск и

документирование ошибок. Бывает, что результаты этой работы заставля-

ют руководство отказаться от проекта. Случается и так, что пересматрива-

ется календарный план работ и выпуск продукта откладывается на месяцы

и даже годы. Такие задержки могут стоить программистам и их руководи-

телям работы, а начинающей компании — независимости.

Практически любой компании выгодно иметь собственную группу про-

фессиональных тестировщиков. Преимущества, которые она получает, та-

ковы.

• Компетентность. Тестировщики специализируются на тестирова-

нии, и в этом деле они профессионалы. Они вместе обучаются,

конструктивно критикуют друг друга и знают свою работу так, как

ее не знает никто другой.

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

• Экономия времени. Когда каждый занимается своим делом: тести-

ровщик — тестированием, программист — программированием, а

технический писатель — составлением документации, тогда их рабо-

чее время используется с максимальной эффективностью. Все рабо-

ты ведутся параллельно, и никто не отрывается от своего основного

дела. Ни программист, ни технический писатель все равно не могут

протестировать программу как следует, поскольку эта работа требует

серьезной подготовки и организации и не может делаться от случая

к случаю. Занимаясь тестированием, они бы очень непродуктивно

тратили драгоценное время.

• Независимость. Поскольку тестировщики подотчетны не руководи-

телю проекта, а своему собственному шефу (компетентному и дос-

таточно независимому), они могут делать свою работу самым

наилучшим образом, не заботясь о том, как будет выглядеть руко-

водитель проекта, когда в программе обнаружатся серьезнейшие

недостатки.

Руководство группой тестирования — это очень большая ответствен-

ность. Это бесконечные проблемы с неопытным персоналом. И очень мало

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

велика, что они чаще всех других сотрудников меняют место работы. Их

политическая роль в компании крайне невыгодна — ведь они изобличают

недостатки продукта, которые всегда являются чьими-то недоработками, а

значит, сплошь и рядом наживают себе врагов.

Однако не все так мрачно. Можно создать прекрасную команду, кото-

рую будут ценить за огромный вклад в повышение качества разрабатыва-

емых продуктов, и при этом сохранить мирные и конструктивные

отношения с другими подразделениями компании. Можно сделать это без

давления на своих подчиненных, организуя их работу так, чтобы не было

авралов и штурмовщины, причем добиться этого не за чужой счет и не

жертвуя собственными морально-этическими установками.

В чем же секрет успеха, и что позволит не оступиться на таком труд-

ном пути, когда порой приходится буквально ходить по лезвию бритвы?

Честность, профессионализм и уважение к людям являются главным

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

Роль группы тестирования

Существует четыре основных типа тестовых групп. У каждой из них

своя роль в компании и свои задачи.

• Группа контроля качества следит за соблюдением стандартов.

• Группа обеспечения качества пытается тем или иным способом га-

рантировать соблюдение стандартов.

Глава 14: Управление группой тестирования 431

• Служба тестирования ищет и документирует ошибки.

•

Служба поддержки разработки выполняет ряд технических задач, и

в том числе тестирование.

Группа контроля качества

Теоретически это очень влиятельное подразделение. Инспектор группы

контроля качества (Quality Control) может задержать выпуск продукта до тех

пор, пока не будут соблюдены все стандарты и процедуры и исправлены

все ошибки. Какой заманчивой кажется сотрудникам служб тестирования

и разработки такая власть! Но ничто не дается даром.

Инспектор группы контроля качества не просто снимает с конвейера

пару бракованных банок консервов. Он останавливает всю линию, возмож-

но, единственную линию компании, и делает это не на пару минут, а на

несколько дней, недель или месяцев. Руководство компании реагирует на

такие события немедленно и может запросто отменить решение группы

контроля качества и распорядиться выпускать продукт, каким бы ни было

его качество.

Настоящей группой контроля качества в любой компании

является ее руководство.

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

информацию о текущих проблемах разработки и степени их серьезности.

Однако предоставление информации — это одно, а принятие решений —

совсем другое. Здесь группа контроля качества обладает несколько более

высокими полномочиями, чем обычная группа тестирования, поскольку

может задержать выпуск продукта, не удовлетворяющего определенным

требованиям. Однако сделать это она может только на некоторое время —

пока руководство не проанализирует ситуацию, чтобы принять окончатель-

ное решение.

Группа обеспечения качества

Группа обеспечения качества (Quality Assurance) делает то, чего не может

сделать обыкновенная группа тестирования, — она обеспечивает качество

продукта. Для этого группа обеспечения качества участвует в разработке от

первого до последнего дня, устанавливая стандарты, определяя процедуры

контроля и обучая людей тому, как лучше проектировать и разрабатывать

программные продукты. Таким образом, недостатки программ не просто

устраняются, а предотвращаются. Группа обеспечения качества занимает-

ся также и тестированием, но это далеко не единственная ее работа.

Чтобы справиться со своей задачей, группа обеспечения качества дол-

жна обладать огромными полномочиями, а ее сотрудники — высочайшей

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

квалификацией в целом ряде профессий. Они должны быть высококласс-

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

тировщиками и аналитиками. Иначе им просто не будут доверять.

В любой компании имеется группа, отвечающая за определение стан-

дартов, обучение персонала, управление работой и повышение ее эффек-

тивности, — это руководство компании. Именно оно обеспечивает качество

выпускаемых продуктов.

С политической точки зрения создание в компании отдельной группы

обеспечения качества — это палка о двух концах. Ведь за качество продукта

должен отвечать каждый, кто так или иначе участвует в разработке, и осо-

бенно руководство компании. Если же у людей появляется хоть малейшая

возможность переложить эту ответственность на кого-то другого, они не-

медленно ею пользуются. Даже руководитель проекта может заявить: "Мое

дело — вовремя выпустить продукт, а за его качество отвечает соответству-

ющая группа". Любому, кто достаточно долго проработал тестировщиком,

наверняка не раз приходилось слышать подобные высказывания.

Служба тестирования

В задачи службы тестирования (Testing Services) входит поиск ошибок и

недостатков программы, их описание и предоставление этой информации

всем, кому она необходима. Решений относительно выпуска продукта ру-

ководитель службы тестирования не принимает, он только предоставляет

руководству информацию о том, насколько продукт протестирован и како-

во его качество.

Роль службы тестирования в разработке продукта может быть различ-

ной. В некоторых компаниях основными тестировщиками считаются сами

программисты, а служба тестирования им только помогает.

Как бы там ни было, служба тестирования отвечает за техническую

сторону этой работы: анализ объекта тестирования, проектирование и под-

готовку тестов, их выполнение и документирование. Все это требует опре-

деленной квалификации, которая имеет полное право быть предметом

профессиональной гордости сотрудников службы. Ее руководитель должен

поощрять это чувство, которое способствует созданию в коллективе благо-

приятного психологического климата и профессионального энтузиазма.

Как известно, многим людям свойственно избегать ответственности и

по возможности перекладывать ее на других. Именно поэтому руководите-

ли проекта часто пытаются переложить ответственность за качество продук-

та на службу тестирования. Но это в корне неверно. Поэтому, если

руководитель проекта утверждает, что программисты вообще не должны

тестировать написанный ими код, или хочет, чтобы вы взяли на себя от-

ветственность за каждую имеющуюся в программе ошибку, не поддавайтесь

на провокацию.

Глава 14: Управление группой тестирования 433

За качество продукта отвечает руководитель проекта. Служба

тестирования только снабжает его технической информацией,

сопровождая данные собственной интерпретацией.

Все это вовсе не означает, что служба тестирования вообще ни за что

не отвечает. Она отвечает за качественное тестирование, интерпретацию его

результатов и их своевременное предоставление руководству, документиро-

вание своей работы. Но ни контролирующей, ни руководящей роли у нее

нет. Участие службы тестирования в управлении проектом скорее косвен-

ное, чем непосредственное. Ее сила заключается в собираемых данных и

умении правильно их представить. И сила эта немалая. Переговорами и

убеждением нередко удается достичь гораздо большего, чем просто отме-

ной выпуска продукта или вводом новых процедур и стандартов.

Серьезной проблемой, с которой сталкивается руководитель службы

тестирования, является узость ее функций. Из-за этого у части персонала

группы мало возможностей для профессионального роста. Тестировщики,

которые хотят заниматься этой работой всегда, такие возможности имеют:

они могут совершенствоваться в своем деле, изучать новые технологии

тестирования и его автоматизации, новые подходы к планированию работ,

новые стандарты. Но как быть с теми сотрудниками, которые стремятся

сделать карьеру, чьи конечные цели лежат далеко за пределами тестирова-

ния?

Служба поддержки разработки

Концепция службы поддержки разработки (Developing Services) является

расширением концепции службы тестирования. Обе они являются служба-

ми, а значит, предоставляют чисто технические услуги — это не админи-

стративные, не контролирующие и, как правило, аполитичные группы. Они

помогают улучшить продукт, созданный другими сотрудниками (програм-

мистами), используя для этого профессиональные навыки, которых у про-

граммистов нет. Если служба тестирования только тестирует продукт, то у

службы поддержки разработки есть и другие задачи. Ее сотрудники прини-

мают в разработке гораздо большее участие, а значит, имеют и больше

возможностей для профессионального роста.

Основной задачей службы поддержки разработки остается тестирование.

Но в зависимости от нужд конкретной компании могут выполняться сле-

дующие задачи.

• Отладка.

• Техническая поддержка пользователей, особенно в первые недели

после выпуска продукта.

• Редактирование копии руководства пользователя.

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

• Техническое редактирование руководства (с правом вносить измене-

ния, которого обычные тестировщики не имеют).

• Анализ эксплуатационных характеристик продукта.

• Сравнительная оценка продукта.

• Изучение пользовательского удовлетворения продуктом.

Такой широкий круг задач позволит большинству тестировщиков рас-

ширить свой профессиональный опыт и найти работу по душе. Расспросите

своих подчиненных, какая деятельность им больше нравится, и соответ-

ственно распределите дополнительные обязанности. Однако имейте в виду,

что их выполнение не должно превалировать над тестированием, которое

всегда остается основной работой службы поддержки разработки.

Рекомендации

На наш взгляд, концепция служб гораздо более удачна, чем традицион-

ные концепции групп контроля и обеспечения качества. Идея службы

поддержки разработки нам очень нравится, но на деле нам еще ни разу не

пришлось опробовать ее полный вариант. Что касается службы тестирова-

ния, то это проверенная временем и прекрасно зарекомендовавшая себя

структура. Однако ее руководитель должен уделять самое пристальное

внимание возможностям карьерного роста своих подчиненных, иначе в

группе будет сильная текучесть кадров.

Группа тестирования — не избавление

программистов

Если в подразделении разработки программного обеспечения нет груп-

пы тестирования, программисты знают, что правильная работа программы

лежит полностью на их ответственности. Однако как только такая группа

появляется, программисты расслабляются и некоторые ошибки остаются

ими незамеченными. (Собственно говоря, ведь за это тестировщикам и

платят, не так ли?)

Эта ситуация не совсем верна. Программисты обязаны тщательно тес-

тировать свои программы, они должны заботиться об их правильности и

стабильности. Зная программный код как свои пять пальцев, они находят

ошибки гораздо быстрее тестировщиков, причем могут обнаружить такие

проблемы, которые тестировщикам самостоятельно не найти. В свою оче-

редь, тестировщики анализируют программу с иной точки зрения и видят

те ее недостатки, которых не замечают программисты. Поэтому для полно-

ценного тестирования программы необходимы объединенные усилия обе-

их сторон.

Глава 14: Управление группой тестирования 435

Поиск ошибок программистами сравнительно более дешев. Вспомните

рисунок 3.1 из главы 3 — чем раньше проблема выявлена, тем дешевле

обходится ее решение. Этому есть несколько причин.

• Программисту нет нужды повторять тесты, чтобы выяснить, что идет

не так. Он сразу обращается к программному коду, где быстро на-

ходит причину ошибки и немедленно ее исправляет.

• Программисту не приходится описывать проблему для кого-то еще.

• Программист не тратит времени на выяснение того, как должна

работать программа. Ему не нужно составлять отчет о проблеме,

отслеживать ответные действия и комментарии других сотрудников

и печатать итоговые и сводные отчеты. Он не занимается никакой

бумажной работой — просто быстро находит и исправляет ошибку.

Нередко в ходе проекта получается, что программисты тестируют свою

работу все меньше и меньше. Часто это происходит под давлением не в

меру амбициозного руководителя проекта, который таким образом пытает-

ся ускорить разработку, невзирая на то, что в результате страдает качество

продукта. Когда эта ситуация достигает своего предела, только что напи-

санный программный код сбоит сразу же, как только попадает в руки те-

стировщиков.

Хотя эта тенденция и мешает разработке, с ней приходится считаться.

Набирая команду тестировщиков, имейте в виду, что вам придется выпол-

нять и некоторую лишнюю работу, которую в идеале должны были бы

делать программисты. Это одна из причин того, почему мы рекомендуем

составлять команду как минимум из троих тестировщиков, не считая их

руководителя.

Альтернатива: независимые тестовые

агентства

Вовсе не обязательно, чтобы компания тестировала разрабатываемые

программные продукты исключительно своими силами. Можно обратить-

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

грамму и черновики руководства, сотрудники этой фирмы проведут ряд

циклов тестирования.

Традиционно считается, что продукт будет надежнее, если его протес-

тирует абсолютно независимая компания.

Так утверждается во многих книгах по тестированию программного

обеспечения. Теоретически у высокопрофессиональных тестировщиков,

которые ни от кого не зависят и не испытывают давления со стороны

руководства проекта, гораздо больше возможностей. Но наш собственный

опыт этого не подтверждает. Напротив, имея дело с независимыми тесто-

выми агентствами, мы сталкивались с целым рядом проблем.

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

• Тестовые агентства не так независимы, как кажется. Они рабо-

тают по контракту и заинтересованы в его продлении. Следователь-

но, их главная цель — не протестировать продукт как следует, а

удовлетворить заказчика, которым является руководство проекта. И

если руководителю проекта хочется, чтобы продукт выглядел лучше

или быстрее ушел в производство, независимое агентство будет

пропускать проблемы, лишь бы быстрее объявить, что все в поряд-

ке.

•

Стандарты агентства могут быть недостаточно высоки. В час-

тности, сотрудники агентства едва ли станут критиковать дизайн

продукта. Если плохо спроектированная программа полностью соот-

ветствует спецификации и руководству пользователя, тестовое аген-

тство выдаст заключение о ее правильности и отсутствии каких бы

то ни было проблем.

•

Персонал тестового агентства может не обладать достаточной

квалификацией. В одном из известных нам агентств работали необу-

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

но в жизни не прочел ни одного учебника по тестированию. Едва ли

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

ные значения данных и зачем их тестировать. Хотя сотрудники

большинства тестовых агентств более профессиональны, упомянутая

фирма до сих пор работает. Так что не стесняйтесь как следует

побеседовать с персоналом фирмы, прежде чем подписывать с ней

контракт.

Примите во внимание и тот факт, что у тестового агентства большие

накладные расходы, так что вы платите за каждого его тестировщика

втрое больше, чем он в действительности получает. Если, например,

тестовое агентство получает от вас $24 за каждый час работы одно-

го тестировщика, ему будут платить только $8 в час. Таких низко-

квалифицированных сотрудников, которые согласились бы работать

за эту плату, мы никогда не нанимаем.

Нам приходилось читать огромное количество плохо составленных

отчетов о проблемах, предоставленных тестовыми агентствами. В то

же время собственные наши сотрудники проходят специальное обу-

чение и выполняют такую работу всегда качественно.

• Агентства пропускают значительные участки программы. Напри-

мер, нам никогда не приходилось встречать тестов для условий го-

нок, разработанных независимыми агентствами. Зато мы видели

катастрофические ошибки, которые были вызваны ситуациями го-

нок и которые тестовые агентства пропустили или неверно докумен-

тировали.

Глава 14: Управление группой тестирования 437

Еще один пример: агентство, получившее $250 тыс. за тестирование

продукта средней сложности, практически не проработало его вы-

ходные документы. Убедившись, что программа правильно вычисля-

ет выходные значения, сотрудники не удосужились проверить, как

она отображает эти значения в графиках и диаграммах, где оказал-

ся целый ряд серьезных ошибок.

• Агентства могут не обеспечивать достаточного контроля и под-

держки тестовых работ проекта. Не думайте, что, как только

подписан контракт с независимым агентством, собственных тести-

ровщиков можно тут же перебросить на другой проект. Каким бы

хорошим ни было агентство, кто-то должен контролировать его

работу, взаимодействовать с его сотрудниками, обучая их принятым

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

чтобы проблемы, о которых они сообщают, вовремя решались.

•

Вовсе не обязательно, что агентство поможет вам реалистичес-

ки спланировать бюджет тестирования. Заключая договор на два

цикла тестирования, планируйте, что потребуется еще и третий,

четвертый и т.д. Кроме того, не ждите, что продукт будет протести-

рован за меньшее количество циклов, чем понадобилось бы вашей

собственной группе.

•

Обычно агентство недостаточно знает тестируемый программ-

ный продукт. Оно может не знать, как должны работать подобные

программы, каковы преимущества вашей, не знают требований рын-

ка и того, на какие уступки конструкторы продукта готовы пойти,

а на какие — нет. Независимые тестировщики плохо представляют

себе процесс реальной эксплуатации продукта и не знают, в чем

пользователь может нагружать программу до предела и какие гра-

ничные значения данных он может попытаться превысить.

Итак, продумайте, что вы хотите получить от тестового агентства. Уч-

тите, что все это будет стоить немалых денег и времени. Решите, нужны ли

вам полностью документированные тестовые материалы, пригодные для

повторного использования. Как насчет автоматизированных тестов? Воз-

можно, все, что вам требуется, — это несколько циклов основательного

тестирования без подробных сопроводительных материалов. Только четко

определив свои нужды и приоритеты, можно приступать к поиску соответ-

ствующего тестового агентства и переговорам о контракте.

В целом, на наш взгляд, результаты работы независимых тестовых

агентств можно назвать посредственными. Кое-что они делают неплохо, и

многие компании успешно пользуются их услугами.

У независимых тестовых агентств есть и определенные достоинства. В

частности, их услуги можно использовать как основу для собственной

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

работы. Вместо того чтобы платить за длительное тестирование, можно

заказать агентству разработку плана тестирования, наборов тестов и пред-

ложений по дальнейшей работе. Это задание достаточно сложное, и аген-

тству придется поручить его своим лучшим специалистам. Однако вы

получите то, за что заплатите. У специалистов агентства наверняка гораз-

до больший опыт тестирования, чем у вас, они работали с большим коли-

чеством разнообразных типов программного обеспечения и могут

предложить тесты для выявления проблем, которые вам никогда и в голо-

ву бы не пришли, или же интересные и нестандартные способы анализа и

тестирования программы. Объединив их работу со своей, можно получить

прекрасные результаты, а заодно и кое-чему научиться.

Последняя рекомендация: заключая контракт с тестовым агентством,

назначьте для тестирования продукта и несколько собственных сотрудни-

ков. Их работа будет заключаться в следующем.

•

Воспроизводить каждую ошибку, найденную сотрудниками агентства.

При необходимости ваш персонал должен дополнять отчеты, чтобы

четкость описания ошибок соответствовала стандартам компании.

• Искать связанные проблемы. Это отнюдь не дублирование работы

агентства. Ваш персонал знает продукт и его разработчиков гораздо

лучше, а значит, знает, где искать проблемы и какими они могут

быть.

•

Критически анализировать пользовательский интерфейс программы

независимо от того, входит ли это в обязанности сторонних тести-

ровщиков. Цели компании и стиль ее продуктов известны вашим

сотрудникам лучше, чем сотрудникам агентства, которым трудно

судить, соответствует ли данный сомнительный аспект программы

стандартам компании или это явная недоработка.

• Оценивать охват продукта проводимым тестированием. Все ли

важные аспекты и области программы тестируются сотрудниками

агентства? Ищутся ли все возможные типы ошибок? В одних случаях

ваши сотрудники будут указывать на слабые места в работе тести-

ровщиков агентства, в других — разрабатывать и выполнять недоста-

ющие тесты самостоятельно.

Итак, независимое тестовое агентство не решает всех проблем компа-

нии и не может от начала и до конца взять на себя ответственность за

полноценное тестирование продукта. Найм сторонних специалистов может

служить лишь дополнением к вашей собственной работе. Будет ли это

дополнение значительным или совсем небольшим, ответственность за ка-

чество тестирования целиком лежит на вас и компании все равно необхо-

дим персонал, контролирующий работу тестового агентства и

выполняющий то, чего агентство сделать не может.

Глава 14: Управление группой тестирования 439

Советы по планированию

Как руководитель группы тестирования вы отвечаете за часть работ по

планированию проекта. Сроки тестовых работ оценивать очень сложно,

поскольку они зависят от работы других сотрудников. Если программисты

не будут укладываться в график, затянется и работа вашей группы. То же

самое случится, если ошибок в программе будет больше, чем предполага-

лось, или если пользовательский интерфейс будет постоянно меняться.

Хотя все эти трудности вполне объективны, прятаться за ними не следует.

Обязанность руководителя — предусмотреть все возможные проблемы и

составить план работ своей группы с их учетом. Вот каковы его цели.

• Предоставить необходимую информацию руководителю проекта.

Руководитель проекта должен знать, какие задачи стоят перед груп-

пой тестирования и сколько времени потребуется на их выполнение.

•

Продумать возможные экстренные меры для обеспечения своевре-

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

Заранее выделите те задачи программистов и технических писателей,

которые могут задержать другие части общей работы и поэтому

обязательно должны быть выполнены вовремя. Определите те эта-

пы разработки, на которых дополнительные ресурсы могут значи-

тельно ускорить ее ход. Многие руководители проекта охотно идут

на выделение этих ресурсов, особенно если речь идет о дополни-

тельных тестировщиках или программистах. Ведь в конечном счете,

оплатив определенное количество человеко-дней и выпустив продукт

на неделю раньше, компания сэкономит на оплате недельного тру-

да всех тех, кто работает над проектом. И при этом она раньше

выйдет на рынок и раньше начнет получать прибыль. Так что подоб-

ные затраты окупаются с лихвой.

• Быть честным со своими подчиненными. Руководитель проекта

может попытаться ускорить выпуск продукта за счет сверхурочной

неоплачиваемой работы персонала. Однако полученная при этом до-

полнительная прибыль может дорого обойтись для вас и вашей ком-

пании: вы теряете право называться порядочными людьми,

ухудшаете психологический климат в коллективе, качество работы

усталых сотрудников оставляет желать лучшего, а текучесть кадров

сильно повышается. Зато руководитель, добившийся такой ценой

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

Одной из главных обязанностей руководителя группы

тестирования является защита своих подчиненных.

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

• Повысить производительность труда. Люди с готовностью постара-

ются уложиться в жесткий, но выполнимый график. Однако, если

плохое планирование приведет к необходимости постоянной сверху-

рочной работы, не ждите от них энтузиазма. Уставшие сотрудники

становятся невнимательными, работают неохотно, перестают пред-

лагать усовершенствования, чтобы не затянуть проект еще сильнее,

и наконец, некоторые из них, как правило самые высококлассные

специалисты, просто увольняются.

Итак, честные и объективные оценки сроков работ жизненно необхо-

димы и вам, и компании. В следующих разделах приведены советы по их

формированию.

Оценка производительности и продуктивности

В главе 6 рассказывалось о том, почему систему отслеживания проблем

ни в коем случае нельзя использовать для оценки производительности

труда программистов. Теперь же мы поговорим о том, какую пользу может

принести отслеживание производительности собственных подчиненных.

Разница здесь в том, что программисты не являются вашими подчиненны-

ми. Поэтому любые попытки оценки их деятельности будут восприняты в

штыки. С другой стороны наблюдение за производительностью собствен-

ного персонала поможет улучшить его работу и не приведет к конфликтам,

поскольку результаты наблюдений не выйдут за стены вашей рабочей ком-

наты.

Страстным приверженцем оценки производительности персонала явля-

ется такой известный автор, как Деминг (Deming, 1982). Он считает, что

получаемые данные позволяют значительно повысить качество работы. Вот

какие преимущества может вам дать оценка производительности работы со-

трудников группы тестирования.

• Можно определить, сколько времени требуется в среднем на выпол-

нение конкретной задачи. На основе этих данных можно планиро-

вать работу в дальнейшем.

• Если например, известно, что в среднем тестировщик находит око-

ло 8 ошибок в день, обычно от 1 до 25, вы не удивитесь, если кто-

то из сотрудников найдет за день 24 ошибки, но, если их окажется

120, вы сразу поймете, что здесь что-то не так.

• Наблюдая за динамикой показателей производительности подчинен-

ных, можно оценить, каковы результаты ваших собственных усилий

по ее повышению. Помогает ли данный тип обучения? Ускоряет ли

работу автоматизация определенных тестов или видов деятельности?

Для оценки пользы усовершенствований необходима возможность ана-

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

Глава 14: Управление группой тестирования 441

Вот несколько примеров того, что можно определить.

•

Среднее количество циклов тестирования. Наш опыт показывает,

что типичная программа достигает коммерчески приемлемого каче-

ства после восьми полных циклов тестирования. Однако эта оцен-

ка не универсальна — для некоторых продуктов могут потребоваться

десятки циклов, а есть и такие простые программы, которые отла-

живаются за несколько циклов.

• Длительность типичного цикла тестирования. Этот показатель

имеет смысл только тогда, когда каждая версия программы или

определенной ее части всегда проходит полный цикл тестирования.

Если же новая версия программы поступает каждую неделю незави-

симо от того, насколько протестирована предыдущая, данная оцен-

ка теряет смысл.

•

Количество ошибок, документируемых за день одним тестировщи-

ком. Если один тестировщик находит за день в среднем 5 ошибок и

вы предполагаете, что всего в программе их будет найдено около

1000, значит, на ее тестирование потребуется 200 человеко-дней.

•

Время тестирования одного устройства. При этом время настройки

устройства следует учитывать отдельно.

• Количество страниц документации, проверяемых за один час.

Конечно, это время зависит от типа документации и целей ее проверки.

• Количество сообщений об ошибках, тестируемых за один час.

Сколько времени займет тестирование всего блока обработки оши-

бок?

•

Часть (количество страниц) плана тестирования, выполняемая за

один час. Сколько времени уйдет на выполнение всего плана?

Можно придумать и множество других примеров. Целый ряд показате-

лей продуктивности программного обеспечения приводит в своей книге

Джонс (Jones, 1991).

Собранные данные послужат убедительной аргументацией в перегово-

рах с руководителем проекта. Оперируя конкретными цифрами, гораздо

легче объяснить, почему для тестирования программного продукта потре-

буется не два цикла, как хотелось бы руководителю проекта, а восемь.

Покажите, сколько времени занимает в среднем каждый цикл тестирова-

ния, и объясните почему. Благодаря такой обстоятельности вы сможете

получить больше времени и персонала, а значит, обеспечить более спокой-

ную работу с гораздо лучшими результатами.

Статистические данные о производительности персонала полезны, но

только при правильном употреблении. Если вы попытаетесь использовать

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

их для давления на подчиненных, утверждая, что они работают недостаточ-

но быстро, ничего хорошего от этого не ждите. В частности, такой извес-

тный автор, как Деминг (Deming, 1982), решительно выступает против

подобного использования собранной информации.

Если вы работаете в компании, где статистические данные о

производительности труда могут быть использованы против

отдельных тестировщиков, не собирайте эту информацию.

Определение и оценка каждой задачи

Прежде чем пытаться оценить общий объем необходимого тестирова-

ния, составьте полный список его задач. В этом списке ничто не должно

быть упущено. Понятно, что составить такой список и оценить сроки

выполнения каждой из задач не так-то просто, и одному человеку с этим

не справиться. Вот хороший способ, как это сделать.

Попросите руководство выделить вам на день или два конференц-зал

или большую комнату. Соберите вместе всех тестировщиков, которым

предстоит работать над продуктом. Если проект невелик и программу бу-

дет тестировать один-единственный сотрудник, пригласите еще кого-ни-

будь, имеющего опыт тестирования и знающего продукт (возможно, того,

кто тестировал его предыдущий выпуск). Принесите на собрание специфи-

кацию, план тестирования, план тестирования предыдущего выпуска, ру-

ководства пользователя, заметки и любые другие материалы, которые

помогут в определении задач.

Возьмите лист бумаги, запишите на нем все основные задачи тестиро-

вания и прикрепите его к стене. У вас может получиться 5, 10 или 20

крупных задач — едва ли больше. Затем для каждой из основных задач

перечислите на отдельном листе бумаги все ее составляющие. Эти листы

также развесьте по стенам. Некоторые из подзадач могут оказаться настоль-

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

перечислите на отдельных листах. Придумав еще одну базовую задачу, вы

будете дописывать ее в главный список, а затем брать новый лист бумаги

и перечислять на нем все ее составляющие.

Когда все будет готово, можно начинать собрание. Вначале каждый

сотрудник несколько раз обойдет комнату, переходя от списка к списку и

дописывая в него новые элементы. Каждый должен увидеть, что дописали

другие, и убедиться, что больше добавить нечего.

Собрание должно проводиться по принципу мозгового штурма. Его

первая цель — собрать максимум идей. Поэтому пока не критикуйте ни

одну из них. Пусть все, что приходит людям в голову, попадет на бумагу.

Отобрать правильные идеи вы сможете позднее.

Глава 14: Управление группой тестирования 443

Составив списки, соберитесь все вместе для группового обсуждения. По

очереди выбирая из списка каждую задачу, попытайтесь определить, сколь-

ко времени потребуется на ее выполнение. Везде, где только возможно,

разбивайте задачи на более мелкие и определяйте время выполнения их со-

ставляющих. Оценивая время, записывайте три значения: кратчайший срок,

длиннейший и средний.

Нередко оценки, даваемые вашими сотрудниками, будут казаться вам

Преувеличенными. Это нормально. Поощряйте совершенно свободное

выражение людьми своего мнения, только пусть они обязательно обосно-

Цвывают высказываемые заключения. Ведь в конечном счете должна соста-

виться реальная картина, а не нечто желаемое, но невыполнимое.

Не допускайте, чтобы сотрудник, высказавший неверную на чей-

либо взгляд оценку, почувствовал себя глупым или виноватым.

Напротив, всячески поощряйте свободное выражение

сотрудниками собственного мнения. Оно вполне может

оказаться верным. Если же нет, они сами поймут это в ходе

дискуссии или некоторое время спустя.

Когда вы сложите время всех предложенных в ходе обсуждения задач,

результат окажется огромным. Он может в 5 или 10 раз превышать запла-

нированную длительность всего проекта. Это нормально. А вот если ока-

жется, что предполагаемые работы по тестированию прекрасно

укладываются в график проекта, тогда стоит обеспокоиться.

Теперь, имея четкий список задач, можно приступать к принятию ре-

шений.

• Выделите задачи, которые не могут быть выполнены.

• Распределите приоритеты между остальными.

• Решите, какие из задач будут выполнены только частично и какие

это будут части. (При этом, выбирая тесты, вы в одних случаях

будете полагаться на логику, а в других действовать методом случай-

ного отбора.)

• Выделите задачи, требующие наиболее быстрого выполнения (для

тех из них, которые к тому же будут часто повторяться, можно зап-

ланировать автоматизацию).

• В случае необходимости напишите подробную и убедительную док-

ладную записку, поясняющую, почему тестирование не может быть

выполнено в запланированные руководством сроки или почему вам

требуются дополнительные тестировщики, а также чего можно до-

стичь при большем количестве времени, людей или денег.