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

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

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

Классификация проекта

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

го до того, как у вас появится достаточно информации. Поэтому вам нужна

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

ми их стоимости.

•

Начните с определения сложности продукта. Воспользуйтесь трех-

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

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

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

•

Затем сделайте предположения о том состоянии, в котором про-

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

льной шкалой. Сколько ошибок предполагается найти в программе?

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

программах других. То же самое относится и к программистам. Если

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

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

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

• Определив шкалы сложности и надежности проектов, можно соста-

вить таблицы оценки их стоимости и длительности. Пример такой

таблицы с совершенно гипотетическими цифрами приведен на рис.

14.1. Ее данные можно интерпретировать так: на тестирование не-

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

мистом уходит неделя; более сложное изменение в крайне ненадежной

программе (или выполненное плохим программистом) тестируется 64

недели.

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

Повторяющиеся задачи и задачи, выполняющиеся

фиксированное число раз

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

вторяются многократно.

•

Задачи, выполняющиеся фиксированное число раз. Большая часть из

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

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

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

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

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

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

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

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

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

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

не меняется.

Еще одним примером одноразовой работы является написание плана

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

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

сертификация альфа-версии, сертификация бета-версии и многие

тесты устройств. Близки к этому типу и многие тесты граничных

условий — те, которые выполняются очень редко.

• Повторяющиеся задачи. Большая их часть выполняется на каждом

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

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

быстрое тестирование ее функциональности.

• Многие регрессионные тесты можно проводить на каждом втором

или каждом третьем цикле. Это тоже повторяющиеся задачи, и ко-

личество их повторений зависит от общей длительности тестирова-

ния: если, например, программа пройдет 30 циклов тестирования,

эти регрессионные тесты будут выполнены 10 или 15 раз.

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

мы, складывается:

• из суммы длительностей всех фиксированных заданий,

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

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

количество циклов.

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

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

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

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

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

Советы

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

•

Если один человек тестирует несколько продуктов, учтите дополни-

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

ними. Каждый раз, переходя от одного проекта к другому, такому

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

что делать дальше.

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

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

совещания, составление отчетов и прочие подобные дела. Постарай-

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

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

где-нибудь в кафе в спокойной располагающей обстановке и побе-

седуйте с ними на эту тему. Подготовьте список затрат времени,

неизбежность которых можно убедительно объяснить руководству.

Если ваши подчиненные тратят на тестирование по шесть часов в день,

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

•

Изучите индивидуальные особенности своих подчиненных. Одни

люди по природе более быстрые, чем другие. Некоторые охотно

остаются после работы. Одни обладают прекрасными способностя-

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

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

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

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

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

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

об их желаниях и склонностях просто обязаны.

•

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

сотрудников. Если, не вкладываясь в график, вы решите нанять

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

нить стандартные формальности, обучить и ввести их в курс дела.

(Подробнее все эти временные издержки описывает в своей книге

Брукс (Brooks, 1975).)

•

Если приходится сокращать объем работ, делайте это крайне ос-

мотрительно. Проведите еще одно планировочное совещание, вер-

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

сформировавшегося понимания проекта. Отберите задания, которые

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

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

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

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

та: разумеется, оно пострадает, но ущерб должен быть минималь-

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

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

• Совещания. Совещания — вещь полезная, но не следует проводить

их без необходимости или дольше, чем положено. Для тестировщи-

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

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

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

времени, которое он мог бы провести с семьей.

Избегайте отчетных собраний. Нет ничего скучнее, чем целый час

сидеть и слушать, кто что сделал за истекшую неделю. Если же в

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

сотрудникам брать на них с собой какую-нибудь работу.

Персонал

Управление персоналом — работа не из легких, и вам наверняка при-

годятся советы по следующим вопросам:

• Кого нанимать

• Моральная поддержка

• Карьерный рост

Кого нанимать

Программисты отнюдь не обязательно являются хорошими тестировщи-

ками.

Плохие программисты обычно являются и плохими

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

увольняемых из других подразделений.

Вот несколько характеристик хорошего тестировщика.

•

Последовательность и нацеленность на качество.

•

Психология экспериментатора, а не теоретика. Каждый тест пред-

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

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

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

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

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

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

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

информацию о количестве звонков в отдел технической поддержки,

вызванных данной проблемой в предыдущем выпуске продукта. Со-

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

явить в этом вопросе изобретательность и инициативу.

• Образование. Чем его "больше", тем лучше. Особенно ценно уни-

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

навыки, особенно в области человеческого фактора, а также все

знания и навыки, связанные с компьютером.

•

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

не является определяющим фактором — целый ряд превосходных

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

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

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

Другие сотрудники смогут время от времени обращаться к нему за

советом.

• Опыт работы со многими компьютерами и разнообразным про-

граммным обеспечением.

• Знание комбинаторики. Тестировщик должен уметь приблизитель-

но оценить или же точно вычислить количество тестов, необходимых

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

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

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

•

Умение хорошо выражать свои мысли в письменной и устной фор-

ме. Каждому тестировщику постоянно приходится составлять отче-

ты о выявленных проблемах и устно объяснять их суть — это

неотъемлемая часть его работы. Кроме того, он должен уметь пред-

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

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

могут быть неверно поняты.

• Талант поиска ошибок. Хороший тестировщик никогда не ограни-

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

же, он обладает интуицией и воображением, он способен

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

программы. Этот талант бесценен.

•

Развитое абстрактное мышление.

• Умение разрешать сложные и запутанные проблемы, находить

выход из тупиковых ситуаций.

• Умение эффективно использовать время. Если этой способности

поначалу нет, со временем ее можно развить.

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

•

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

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

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

• Навыки планирования или способность к их развитию.

•

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

• Воображение и способность представить себя на месте другого

человека. Например, тестировщик может спросить себя: "Какие бы

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

с компьютером?"

•

Умение читать и писать спецификации.

Подводя итог, можно сказать, что идеальный тестировщик образован,

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

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

смыслом. Он — творческая личность с организаторскими и техническими

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

того, который необходим хорошему программисту.

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

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

тировщиками. Однако в целом эти два умения не связаны между собой:

можно преуспевать на одном поприще и быть посредственностью на дру-

гом.

Моральная поддержка

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

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

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

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

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

Вы будете просить своих подчиненных описывать найденные ошибки

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

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

тестировщикам времени и сил. Не удивительно, что люди будут протесто-

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

тать сверхурочно.

Помните, что ваша прямая обязанность — защищать своих подчинен-

ных и оказывать им моральную поддержку.

Поощряйте хорошую работу в личном порядке и публично. Выделяйте

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

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

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

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

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

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

тов.

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

ограничивайтесь административным взглядом на вещи — старайтесь вни-

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

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

цените, когда кто-то из них:

• проявляет особую дипломатичность;

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

граммы;

• находит особенно интересные ошибки;

• хорошо держится в напряженных ситуациях, сохраняя собранность

и высокую работоспособность;

• составляет прекрасные отчеты о проблемах;

• успешно обучает кого-то еще;

• работает сверхурочно;

• берет на себя работу, которой все стараются избежать;

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

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

ной задачи, даже если этот способ не срабатывает.

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

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

людей, гордящихся своим профессионализмом, радующихся успехам друг

друга и активно поддерживающих своих товарищей. Каждому тестировщи-

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

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

Тестировщик должен чувствовать, что его открытия важны и желанны. В

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

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

вслух выразить ему свое восхищение.

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

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

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

Постарайтесь оградить тестировщиков от несправедливых нападок со

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

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

ворите им о возможных изменениях графика, пока эти изменения не будут

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

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

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

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

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

дело с вами и вы будете защищать своих людей всеми возможными спосо-

бами. Если руководитель проекта хочет, чтобы кто-то из тестировщиков

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

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

чтобы он свободно мог отказаться. И если он откажется, вы сами должны

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

вы не должны говорить, что выбор был сделан тестировщиком. Ваша обя-

занность — принять огонь на себя, защищая и оберегая своих людей, где

только возможно.

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

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

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

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

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

четко понять, что оно никогда и никаким образом не имеет права давить

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

uх о помощи, выражающейся в более напряженной или сверхурочной ра-

боте.

Итак, стойте стеной за своих людей, и пусть они это видят. Тестиров-

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

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

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

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

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

и положение, их репутацию. Не сомневайтесь, что они это увидят и оце-

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

заслужите их уважение.

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

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

но с ними ознакомьтесь. И если вы согласны с мнением тестировщика,

готовьтесь его отстаивать.

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

те с ним. Если это невозможно, пошлите с ним ведущего тестировщика или

хотя бы просто приятеля.

Итак, в ответ на честный и самоотверженный труд люди должны чув-

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

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

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

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

Карьерный рост

Большинство людей хочет профессионально расти. Они хотят учиться

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

ные возможности. Помогите им в этом.

Для многих тестирование является первым шагом в индустрии про-

граммного обеспечения. Они планируют стать программистами, техничес-

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

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

талантливые люди или профессионалы с очень нестандартным и ценным

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

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

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

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

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

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

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

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

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

пании. Сможет ли он научиться за это время чему-то, что его интересует?

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

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

ся тестировщиком. И мало кто из тех, кто надолго остался в этой

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

так.

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

стремления. Старайтесь, чтобы люди могли извлечь из каждого занятия

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

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

фессиональный опыт.

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

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

ровали. Но все они будут работать с энтузиазмом — а это важнее всего.

Вы будете приобретать новых и новых друзей — навсегда.

Приложение

Распространенные

программные

ошибки

Назначение

ЭТОГО

приложения

В данном приложении описано более 400 ошибок. Эти описания очень ко-

ротки, в них содержится лишь самая интересная информация.

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

ва для дальнейшей работы. Лучше всего прочесть это приложение полнос-

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

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

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

— широкую и очень полную картину всех возможных проблем и ошибок,

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

Набор тестовых материалов — это не что иное, как список

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

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

имеются ли они на самом деле.

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

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

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

Конкретной программы. Именно такой пример стандартного списка и пред-

лагается вашему вниманию.

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

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

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

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

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

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

1. Оценка тестовых материалов, разработанных кем-то другим.

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

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

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

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

полученные материалы и самостоятельно заполнить пробелы. Наш опыт

показывает, что тестовые агентства нередко пропускают целые группы

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

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

чего в них не хватает.

Вот тут-то вам и придет на помощь готовый список всех возможных

ошибок. Формируя на его основе список ошибок для конкретной про-

граммы, включайте в него все, что только может в ней встретиться, не-

зависимо от того, насколько это вероятно. Затем просмотрите

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

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

целые классы пропущенных проблем.

2. Разработка собственных тестов.

Составьте список ошибок, которые могут встретиться в программе,

пользуясь для этого данным приложением. Затем разработайте тесты для

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

возможны ли в программе ошибки какого-либо типа, спросите об этом

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

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

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

организовать и упорядочить работу и гарантировать, что ничего не будет

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

3. Невоспроизводимые ошибки.

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

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

мент ее возникновения.

Однако не стоит отчаиваться — обратитесь за помощью к

этому приложению.

Попытайтесь соотнести зарегистрированные симптомы с описаниями оши-

бок из этого списка. Постарайтесь проявить максимальную гибкость,

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

Приложение. Распространенные программные ошибки 455

4. Неожиданные ошибки.

Если выявленная ошибка оказывается для вас совершенно неожиданной

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

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

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

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

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

Понятие пользовательского интерфейса объединяет все аспекты продук-

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

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

как:

• функциональность;

• быстрота изучения программы новым пользователем;

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

• производительность;

• вероятность возникновения ошибок пользователя;

• удовлетворенность пользователя программой.

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

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

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

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

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

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

перечисленных ниже ошибок пользовательского интерфейса, она вполне

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

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

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

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

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

решение. Подробное обсуждение вопросов, связанных с разработкой

Пользовательского интерфейса, можно найти у таких авторов, как Бейкер

и Бакстон (Ваескег & Buxton, 1987), Хеландер (Helander, 1991), Лорел

(Laurel, 1990, 1991), Рубенштейн и Херш (Rubenstein & Hersh, 1984),

Шнейдерман (Schneiderman, 1987), Смит и Мойзер (Smith & Moiser, 1984).

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

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

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

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

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

гибкость.

Функциональность

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

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

в ней имеется функциональная ошибка.

Избыточная функциональность

Это ошибка, в которой очень трудно убедить разработчиков (Брукс

(Brooks, 1975)). Универсальная система, предназначенная для выполнения

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

и в эксплуатации. Ее пользователи постоянно забывают, как выполнить то

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

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

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

разделы руководств чересчур объемны. Кроме того, многофункциональные

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

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

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

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

следующий: если редко используемые функции программы усложняют

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

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

Ложное впечатление о наборе функций

продукта

Руководства и маркетинговая литература ни в коем случае не должны

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

самом деле.

Неадекватность реализации базовых функций

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

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

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

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

то не захочет ею пользоваться.

Пропущенная функция

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

необходимая функция.

Приложение: Распространенные программные ошибки 457

Неверно работающая функция

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

ствии со спецификацией), а делает нечто другое.

Функция должна быть реализована

пользователем

"Если система обладает всеми необходимыми пользователю возможно-

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

ностей, пользователь должен "собрать" сам, то можно сказать, что она

является инструментальным набором, а не завершенной программой".

(Рубенштейн и Херш (Rubenstein & Hersh, 1984).)

Программа не делает того, что ожидает от

нее пользователь

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

кто-то станет ожидать что имена будут сортироваться в порядке ASCII.

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

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

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

зить это в ее названии и документации, и желательно еще и внести в нее

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

Взаимодействие программы и пользователя

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

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

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

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

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

ошибках.

Пропущенная информация

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

экране. Желательно также, чтобы на экране отображалась информация,

которую среднестатистический пользователь найдет полезной.

Отсутствие инструкций на экране

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

шу нажать, чтобы получить справочную информацию? Если в программе

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

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

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

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

сы к руководству.

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

печатная документация

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

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

Недокументированные возможности

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

позаботьтесь, чтобы были перечислены и все остальные. Пропуск несколь-

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

не узнает, решив, что на экране есть все, что нужно, и не догадавшись

заглянуть в документацию.

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

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

описаниях и для всех остальных.

СОСТОЯНИЯ,

ИЗ

которых

сложно

найти

выход

Если пользователю сложно определить, как выйти из нежелательного

состояния программы или прервать нежелательный процесс, это так же

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

Отсутствие курсора

Курсор — один из основных инструментов пользователя. Он указыва-

ет на активную точку экрана, а также подтверждает, что программа рабо-

тает и ждет указаний. Поэтому курсор (текстовый или указатель мыши)

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

программе.

Программа не распознает ввод

Интерактивная программа должна реагировать на ввод информации

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

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

чения не являются ошибками:

• программа находится в процессе перехода из одного состояния в

другое;

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

• пользователем дана команда не отображать ввод;

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

Приложение: Распространенные программные ошибки 459

Длительное отсутствие активности

Выполняя длительное задание (занимающее более двух секунд), про-

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

лась или остановилась. Иначе пользователь не будет знать, нужно ли ему

перезапустить компьютер или просто немного подождать. Желательно ото-

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

и сколько времени еще осталось.

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

команда

Программа может выполнить команду не тогда, когда этого ожидает

пользователь, или не отобразить на экране внесенные изменения. Напри-

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

ватель не выйдет из текущего режима. Подобные ситуации человек

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

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

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

несколько раз

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

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

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

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

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

дважды открыл файл My_Doc, в одном окне этот файл должен иметь имя

My_Doc:l, а в другом — My_Doc:2 (или что-то в этом роде). В качестве

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

мент.

Неверная или смущающая пользователя

информация

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

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

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

тель может сделать неверные обобщения или выводы, — обычно наиболее

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

сложнее всего.

Простая фактическая ошибка

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

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

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

команды на экране нередко остается информация предыдущего режима,

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

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

информацию на экране на предмет ее оптимального соответствия новому

состоянию.

Синтаксические ошибки

Программисты не особенно заботятся об ошибках правописания, а вот

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

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

Неаккуратное упрощение

Пытаясь описать ситуацию или функцию программы как можно проще,

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

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

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

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

понимание сообщения. Обращайте внимание на такие ошибки. Помните,

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

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

Неудачные метафоры

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

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

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

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

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

многих программах для команды удаления файлов. Если удаленный файл

можно вытащить из корзины, метафора верна. Однако, если файл исчеза-

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

тель бумаги.

Неточные названия команд и функций

Команда СОХРАНИТЬ не должна использоваться для удаления файла

или сортировки его содержимого. Если в русском (английском) языке за

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

да должна ему соответствовать.

Несколько названий одной функции

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

ний. Пользователь не должен ломать голову над тем, чем отличаются ко-

манды Тень и Наложить тень.

Приложение: Распространенные программные ошибки 461

Избыточность информации

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

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

информация среди них просто теряется. Если, на ваш взгляд, все эти тех-

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

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

В некоторых случаях чересчур подробное руководство является просто

попыткой компенсировать неудачное конструкторское решение. Действи-

тельно ли пользователю нужна вся приведенная информация? И нет ли

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

мой?

Когда сохраняются данные?

Предположим, что вы вводите информацию, которую программа должна

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

ной команде пользователя, каждые 15 минут или как-то еще? У пользова-

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

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

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

ботают в этом вопросе несогласованно.

Неудачная внешняя структура

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

понентов. Насколько легко разобраться в назначении каждого из них?

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

отпугивает новичков. Чем меньше необходимо знать пользователю для

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

Справочная система и сообщения об ошибках

Их текст часто рассматривается как незначительная составляющая про-

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

кими писателями. Изменения этого текста выполняются в последнюю

очередь.

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

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

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

на помощь, а не дополнительный повод для раздражения.

Высокий уровень сложности

С экрана читать труднее, чем с бумаги (Шнейдерман (Schneiderman,

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

сложности текста на экране является уровень 5. И уж во всяком случае

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

текст интерактивной справочной системы и сообщений об ошибках не

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

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

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

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

специалистом.

МНОГОСЛОВНОСТЬ

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

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

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

информацию, лучше предоставить к ней отдельный быстрый доступ. Не

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

Неуместная эмоциональность

Сообщения программы должны быть эмоционально нейтральными и

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

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

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

комфорт.

В сообщениях об ошибках не должно быть восклицательных знаков —

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

ство" программы, а в других — как сигнал опасности. Тщательно подбирай-

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

ошибке уже заставляет пользователя напрячься. Поэтому тон сообщения

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

"сбой", "разрушение", "потеря данных" крайне нежелательны на экране,

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

что множество так называемых ошибок носят совершенно рабочий харак-

тер — это просто ситуации, требующие от пользователя определенных

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

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

мист — предусмотрительнее).

Фактические ошибки

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

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

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

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

Контекстные ошибки

Контекстно-зависимые справочные системы и подсистемы обработки

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

Приложение: Распространенные программные ошибки 463

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

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

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

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

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

ные данные. В хорошем сообщении об ошибке указываются также ее

причина и способ выхода из ситуации.

Шестнадцатиричный код - это не сообщение об ошибке

Сообщения вроде Error 010 в обычных прикладных программах не-

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

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

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

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

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

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

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

вателю о неудаче, но и объяснить ее причины. Сообщения "Принтер уже

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

действий.

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

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

форме, и только тогда, когда ошибка действительно имеет место. Если же

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

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

Ошибки отображения

Ошибки отображения информации на экране — это то, что может дис-

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

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

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

экране что-то немного не так. А зря, потому что ошибки на экране часто

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

Два курсора

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

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

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

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

серьезные программные ошибки.