Тестирование-книга. Ю. Н. Артеменко Научный редактор
 Скачать 6.27 Mb.
|
|
Глава 13: Объединяющая 3 6 9 процесс в дальнейшем. Например, они могут заняться автоматиза цией тестов или формированием дополнительных файлов тестовых данных. Необходимо также разработать эффективную стратегию подключения к проекту дополнительных людей, если в последнюю минуту придется прибегнуть к такому варианту. Многие простые, но рутинные операции можно поручить неквалифицированному или не имеющему опыта работы с данной программой персоналу, повысив тем самым отдачу от основного состава группы. Однако задачи для подключаемых людей должны быть определены заранее, и вся схе ма действий должна быть достаточно продумана, поскольку, когда сроки начнут сильно поджимать, времени на это уже не будет. • Тестирование - это наиболее ответственный этап разработки. К моменту начала тестирования программа уже практически полно стью написана. После прекращения поиска ошибок она сразу же выходит в свет. Если проект достаточно велик для подключения нескольких тестировщиков, подумайте о том, чтобы назначить одно- го-двух человек для постоянного выполнения неформального тести рования. Цель работы такого сотрудника — каждую неделю находить пару настолько серьезных ошибок или недостатков, что выпустить с ними продукт просто невозможно. Во время исправления этих оши бок остальная часть группы будет последовательно "прочесывать" программу в соответствии с планом. Эта тактика особенно хорошо зарекомендовала себя на больших и серьезных проектах, где она позволяет сэкономить очень много времени. (Предупреждение: ни когда не откладывайте документирование серьезных ошибок, прибе регая их на случай, если за неделю не удастся выявить ничего серьезного. Такие вещи могут очень дорого вам обойтись, особенно если кто-нибудь об этом узнает. Никогда этого не делайте. Никог да об этом даже не думайте.) А вот каковы следствия выбора эволюционного метода. • Планируйте рано начать тестирование. Как только будет сформи рован базовый набор функций программы, необходимо будет при ступить к тестированию ее надежности. • Планируйте периодическое проведение анализа функциональности и удобства программы. Если только что добавленная часть програм мы покажется вам неудачной, у вас будут все шансы добиться ее из менения. • Планируйте разработку тестового плана параллельно с тестирова нием. Заранее разработать его не удастся — ведь не будет ни пред мета тестирования, ни даже спецификации. 370 Часть III: Управление проектами и группами Глава 13: Объединяющая 371 • Планируйте выполнить самую серьезную часть тестирования как можно раньше. Никогда не откладывайте критические тесты "на потом". Руководитель проекта может в любое время остановить разработку, и они так и останутся невыполненными. Такое действи тельно случается: двоим авторам этой книги приходилось выпускать продукты за три месяца до запланированного срока. Затраты на качество Затраты на качество продукта — это затраты на предотвращение оши бок, их поиск и исправление. С точки зрения бизнеса деньги вкладываются в тестирование потому, что выпуск продукта с ошибками в конечном сче те обходится дороже. Если удастся доказать, что определенный вид тести рования сэкономит компании деньги, его финансирование вам обеспечено. Продумав, как согласовать работу своей команды с общей стратегией разработки продукта, вы, возможно, захотите включить в свой план рабо ты, которые обычно в компании не практикуются. Например, в компании может быть не принято, чтобы тестировщики анализировали внешний дизайн продукта, или же им может не выделяться для этого достаточно времени. Другими примерами подобных нестандартных работ может быть анализ записей группы поддержки пользователей, автоматизация тестов, выполнение рутинной работы низкоквалифицированными тестировщика- ми или вообще непрофессионалами, подключаемыми к работе в крайних случаях, тестирование на совместимость с широким диапазоном внешних устройств или организация бета-тестирования. В каждом случае вам при дется доказывать руководству, что проведение соответствующих работ по зволит предотвратить серьезные потери или затраты в будущем. Чем больше вам известно о затратах компании, связанных с качеством программного продукта, тем больше у вас шансов доказать необходимость новых тестовых процедур. Обычно эти затраты подразделяются на четыре категории (Кампанелла (Campanella, 1990)). • Затраты на предотвращение ошибок: все расходы на предотвраще ние ошибок в программном обеспечении и документации. • Затраты на исправление программы: стоимость работ по тестиро ванию и всего остального, что делается компанией для поиска оши бок. • Стоимость сбоев, происходящих в стенах компании: расходы из-за ошибок, обнаруживаемых в процессе разработки и тестирования продукта. • Стоимость сбоев, происходящих вне компании: расходы из-за оши бок, обнаруживаемых (обычно пользователями) после выпуска про дукта. 3 7 2 Часть III: Управление проектами и группами Примеры каждого из этих четырех видов затрат приведены на рис. 13.2. Исследования Фейгенбаума (Feigenbaum, 1991) показали, что типичная компания тратит на предотвращение ошибок от 5 до 10 процентов общих затрат на качество, еще 20—25 процентов уходит на исправление програм мы, и оставшиеся 65—75 процентов суммы "съедают" последствия внутрен них и внешних сбоев. Глава 13: Объединяющая 3 7 3 Группы контроля качества обычно систематически собирают всю ин формацию о соответствующих затратах. Если получить к ней доступ не удается, не отчаивайтесь. Многое можно выяснить у сотрудников группы технической поддержки, кое-что может рассказать руководство, а об ос тальном можно и догадаться. Проанализировав собранную информацию, вы поймете, как повышение затрат на предотвращение и исправление ошибок помогает уменьшить последствия внутренних и внешних сбоев, а значит и снизить соответствующие расходы. На этой основе можно строить соб ственные аргументы в пользу проведения необходимых видов работ. Последовательность этапов проекта Обычно руководитель проекта публику ет календарный план, важнейшие этапы которого носят названия альфа и бета. Первый из них завершается объявлением о готовности альфа-версии программы, а вто рой — объявлением о готовности бета-вер сии. Точные определения этих состояний разработки от компании к компании меня ются. В общем случае альфа-версия про граммы — это полностью завершенный, хотя и еще полный ошибок, продукт, в то время как бета-версия уже почти готова к выпуску. Основные этапы проекта пред ставлены на рис. 13.3. Разбиение разработки на этапы вовсе не означает, что все поставленные задачи ре шаются последовательно, одна за другой. Как раз наоборот, многие работы выполня ются параллельно, например, в то время как одни части программы только пишутся, другие уже могут тестироваться и описы ваться в руководстве пользователя. При эволюционном методе разработки в то же самое время может выполняться и разра ботка требований к продукту, создание его прототипа и написание спецификации. На рис. 13.4 (а, б, в и г) приведен наш вариант календарного плана работ (разуме ется, без конкретных сроков). 3 7 4 Часть III: Управление проектами и группами Глава 13: Объединяющая 3 7 5 3 7 6 Часть III: Управление проектами и группами Глава 13: Объединяющая 377 3 7 8 Часть III: Управление проектами и группами Глава 13: Объединяющая 3 7 9 3 8 0 Часть III: Управление проектами и группами Глава 13: Объединяющая 3 8 1 Необходимо подчеркнуть, что это только пример, ни одна известная нам компания не придерживается в точности этой схемы. В каждой ком пании определяются собственные базовые этапы разработки, но, как пра вило, они очень похожи на приведенные в этой книге, поскольку это наиболее естественный и логичный порядок решения перечисленных стан дартных задач. Далее в этой главе подробно анализируются приведенные таблицы и рассказывается о том, какие работы по тестированию программного про дукта соответствуют каждому из перечисленных этапов. (Примечание: многие из используемых в этой главе терминов определялись в главе 3.) Проектирование продукта Это самый первый этап разработки, на котором определяется, что же будет представлять собой задуманный программный продукт. При проек тировании первым делом формулируются требования к продукту, а затем разрабатывается его внутренняя и внешняя структура. Подробное описание этого процесса можно найти у таких авторов, как Де Макро (De Macro, 1979), Гаус и Вейнберг (Gause & Weinberg, 1989), Гилб (Gilb, 1988), Голд и Льюис (Gould & Lewis, 1985), Оулд (Ould, 1990), Вейнберг (Weinberg, 1982), Йордан (Yourdon, 1975), Йордан и Константайн (Yourdon & Constantine, 1979). Программирование на этапе проектирования продукта Приступая к проектированию программы, ее конструкторы или предста вители заказчика прежде всего определяют требования к программе и про думывают свои предложения по их реализации, оформляют все это в виде отдельных документов, после чего составляется контракт. Только после этого может начаться собственно программирование. Если разработка ве дется методом водопада, на этапе проектирования разрабатываются внут ренняя и внешняя спецификации. Более детальное планирование внутренней и внешней структуры продукта может быть продолжено и по зднее. Маркетинговая деятельность на этапе проектирования продукта В это же самое время в отделе маркетинга ведется активная исследова тельская работа. Ее цель — помочь конструкторам продукта в формирова нии его видения, собрав для этого максимум информации о требованиях рынка и нуждах пользователей. Для этого из потенциальных пользователей продукта формируются небольшие дискуссионные группы, которым пред- 3 8 2 Часть III: Управление проектами и группами лагается обсудить его возможности, часто на примере прототипов програм мы. Сотрудники отдела маркетинга могут провести опрос пользователей, работавших либо с предыдущими версиями разрабатываемого продукта, либо с другими аналогичными программами. Они расспросят пользовате лей о том, какие функции желательно было бы включить в программу, как они оценивают качество конкурирующих продуктов (и почему) и сколько они могли бы заплатить за подобный продукт. Возможно, что в этой работе потребуется и ваше участие. Документирование на этапе проектирования продукта Некоторые группы документирования на этом этапе помогают состав лять спецификации продукта. Тестирование на этапе проектирования продукта Если повезет, вам предложат проанализировать проектные документы, как только они будут написаны. Это прекрасная возможность познакомить ся с продуктом и начать планирование собственной работы. В главе 3 уже рассказывалось о том, какие недостатки может найти в проектной документации тестировщик. Однако на деле тестировщики редко высказывают какие-либо замечания. Они скорее пользуются предоставлен ной возможностью пораньше ознакомиться с программой. Если же вы все же окажетесь активно вовлеченным в процесс проектирования, обратитесь к книгам таких авторов, как Гаусс и Вейнберг (Gause & Weinberg, 1989) и Фридман и Вейнберг (Freedman & Weinberg, 1982). Если в компании строго соблюдается принцип водопада, рецензирова ние проектной документации пользовательского интерфейса может быть для вас единственной возможностью изменить что-то в этой области. В этом случае следует отнестись к делу со всей серьезностью и проанализи ровать проект продукта самым тщательным образом. Обратитесь в группу технической поддержки за статистической информацией о расходах, свя занных с недостатками пользовательского интерфейса предыдущих разра боток компании. Это поможет доказать руководству, что время, которое вы собираетесь потратить на анализ проектной документации, будет потраче но не зря. Подготовка к автоматизации тестирования Нередко самое важное, что вы можете сделать на этапе проектирования, — это продумать, какой программный код поможет автоматизировать про цесс тестирования или сделать его более эффективным. Этот код может быть включен прямо в продукт или написан в виде отдельных служебных программ. Вовсе не обязательно, что все, о чем вы попросите, будет сде- Глава 13: Объединяющая 3 8 3 лано. Но если высказать свои пожелания вовремя, т.е. на этапе проекти рования, да еще подкрепить их веской аргументацией, четко объяснив назначение каждого средства, тогда у вас будут все шансы получить если не все, то хотя бы часть задуманного. Вот несколько примеров подобного инструментария. • Автоматизация печати. Для этой цели вам потребуется возмож ность управления печатью из командной строки запуска программы. Это означает, что программа должна принимать как минимум сле дующие параметры: имя файла, который необходимо распечатать, имя выходного файла, если печать выполняется не на принтер, а в файл, имя принтера (возможно, и его драйвер) и настроечную ин формацию (шрифт и разрешение печати). По окончании печати программа должна немедленно завершать свою работу. Обладая та ким средством, можно сформировать пакетный файл, который запу стит программу, передаст ей всю необходимую для печати информацию, сравнит результирующий файл с его предыдущей вер сией и напечатает результат, после чего запустит следующий тест. В разделе главы 8 "Несколько полезных замечаний о тестировании печати" этот вопрос рассматривается подробнее. • Исследование памяти. Иногда исключительно полезной оказывается возможность в любой точке программы нажать определенную кла вишу и получить информацию об использовании и содержимом оперативной памяти. Информация эта может быть самой разной. В одних случаях достаточно выяснить объем свободной памяти. В других может потребоваться перечень свободных блоков памяти и их размеров. Просто невероятно, сколько можно придумать новых те стов и сколько трудновоспроизводимых ошибок можно отловить благодаря одному только знанию доступного объема памяти перед началом определенного процесса, по его ходу и после завершения. Тестировщики просто отказываются этому верить, пока не убедят ся на собственном опыте. • Клавиши быстрого перемещения. Речь идет о скрытых командах, позволяющих быстро переместиться в определенную точку програм мы. Это особенно полезно при тестировании некоторых игр. • Копии экрана. Вам наверняка потребуется быстрый способ копиро вания содержимого экрана на принтер или в файл (а может быть, и в последовательный порт, если данные анализируются в реальном времени за другим компьютером). Утилита, копирующая экран, должна обладать возможностью перехватывать не только изображе ние, но и текстовый курсор или указатель мыши. Одной из полез ных возможностей такого средства является сохранение копии 3 8 4 Часть III: Управление проектами и группами последней информации, выводимой программой при ее разрушении. И если готовой утилиты, способной выполнить подобную работу, найти не удастся, можно попросить программистов создать ее. Подготовка тестов для приемки продукта, разработанного по контракту Если программный продукт разрабатывается по заказу другой компа нии, исключительно важно включить в контракт приемочные тесты. Набор этих тестов заранее согласовывается с заказчиком и выполняется им по завершении разработки. Если программа проходит приемочные тесты, зна чит, работы по контракту выполнены и дальнейшие изменения продукта должны оплачиваться отдельно. Приемочные тесты должны быть очень строгими и однозначными. Перед тем как передавать готовый продукт за казчику, их обязательно необходимо выполнить самим, чтобы убедиться, что все в порядке. Ни в коем случае нельзя допустить, чтобы заказчик готовил приемочные тесты самостоятельно, без вашего участия. Не буду чи профессионалом в тестировании, он может создать слишком неопреде ленные, сложные или длительные по времени выполнения тесты либо тесты, для выполнения которых потребуется такой уровень качества про граммы, который не соответствует стоимости разработки. Посоветуйтесь об этом с корпоративным юристом. Анализ стабильности приобретений Если решено приобрести для целей разработки или тестирования про дукты других компаний, все эти продукты должны быть протестированы. Только убедившись, что продукт достаточно стабилен, можно тратить на него деньги. Скольких проблем можно было бы избежать, если бы програм мы всегда тестировались перед покупкой! Анализ пользовательских данных Качество — понятие сложное. Высококачественный программный про дукт должен обладать всеми необходимыми пользователю возможностями и при этом не иметь ошибок (Джуран (Juran, 1989)). И прежде всего о качестве продукта позволяют судить отзывы его пользователей. Если разрабатывается уже не первый выпуск продукта, обязательно проанализируйте информацию, полученную от его пользователей, причем начните эту работу как можно раньше. Для обратной связи с пользовате лями существует целый ряд способов. • Пресса. Это журнальные и газетные статьи, рецензии, обзоры, груп пы новостей в Internet. • Письма от пользователей. Читайте все получаемые письма, особен но самые длинные из них. Глава 13: Объединяющая 3 8 5 • Телефонные звонки пользователей. Если ваша компания настолько велика, что звонков очень-очень много, попросите у сотрудников группы технической поддержки сводные данные о типах жалоб и количестве звонков по поводу каждой из проблем. Скорее всего, сотрудники этой группы смогут отслеживать до 15 категорий жалоб. Сядьте вместе с ними и сформируйте список наиболее важных для вас проблем. • Дискуссионные группы и другие беседы с выбранными пользователя ми. Сотрудники группы маркетинга часто интервьюируют неболь шие группы пользователей, чтобы выяснить их мнения по отдельным вопросам. Иногда их интересует реакция пользователей на новые идеи, в других же случаях — мнения об уже эксплуатиру ющемся продукте. По возможности обязательно посещайте все та кие обсуждения. • Телефонные опросы. Сотрудники отдела маркетинга могут обзвонить полсотни или сотню пользователей и спросить, какие изменения они хотели бы видеть в следующей версии продукта и что им особенно не нравится в текущей версии. Можно позвонить и просто зареги стрированным пользователям, и тем из них, кто сам звонил с жало бами, и задать им одни и те же вопросы. Основной упор в подобных опросах следует делать на надежность продукта. Из перечисленных источников можно получить множество полезных сведений о качестве продукта. Например, обозреватели периодических изданий могут указать на отсутствие функций, о которых большинство нынешних пользователей программы пока еще даже и не думают. Однако в этом вопросе было бы опрометчиво ориентироваться на мнение пользо вателей — через год оно кардинально изменится. В то же время обозрева тели часто не упоминают о самых вопиющих ошибках. Как правило, они знакомятся с продуктом поверхностно, не эксплуатируя его в реальном режиме, поэтому большинства ошибок они просто не замечают. Совсем иначе обстоит дело с пользователями — рано или поздно они сталкивают ся даже с наиболее скрытыми и редко проявляющимися ошибками. Их звонки и письма гораздо чаще указывают именно на ошибки в программе, а не на ее недостающие возможности. Собирая всю описанную информацию, тестировщик преследует такие цели. • Выявить пропущенные ошибки. При тестировании последнего вы пуска программы в нем наверняка были найдены не все ошибки. Не сомневайтесь: о том, что осталось, охотно сообщат пользователи. Их письма и звонки помогут заполнить пробелы тестового плана. 3 8 6 Часть III: Управление проектами и группами • Определение важности незамеченных или отложенных проблем. Выделите 10 или 15 проблем, из-за которых компании пришлось потратить больше всего времени и денег. Если удастся выяснить, во сколько конкретно обошлась поддержка пользователей по поводу каждого из вопросов — замечательно. Руководитель проекта навер няка счастлив будет наконец избавиться от старых и дорогостоящих ошибок и охотно зарезервирует средства для их исправления. • Основа для оценки откладываемых проблем. Во многих программах имеется целый ряд ошибок и недостатков, которых пользователи так никогда и не заметили. Сравнивая список отложенных ошибок пре дыдущего выпуска программы со списком полученных жалоб пользователей, можно предсказать, какие из ошибок вызовут наи худшую реакцию. Когда руководитель проекта решит отложить про блему, которая, на ваш взгляд, вызовет бурю недовольства пользователей, можно будет показать ему сводки пользовательских звонков по похожим вопросам и то, во сколько это обходится ком пании. • Обоснование затрат на дальнейшее тестирование. Предположим, что покупка компьютеров для проверки их совместимости с разра батываемой программой обойдется в $20 тыс. Если предыдущий выпуск программы уже эксплуатируется и никто из пользователей не жалуется на ее несовместимость с этой техникой, нет нужды идти на такие затраты. Если же, напротив, звонки недовольных пользовате лей этих компьютеров обходятся группе технической поддержки в $40 тыс., приобретение оборудования полностью окупится. Собранные данные о мнениях, пожеланиях и жалобах пользователей представляют значительный интерес не только для вас, но и для руководи теля проекта и персонала отдела маркетинга. Всех их интересуют предло жения по усовершенствованию продукта, информация об изменениях демографической или пользовательской базы. И хотя эти вопросы в дан ной книге не рассматриваются, следует иметь в виду, что ваши изыскания могут быть частью более обширных исследований, проводимых компани ей для повышения эффективности ее работы. Мы рекомендуем составить подробные многостраничные таблицы про блем и вопросов пользователей. Подсчитайте количество обращений по каждому вопросу. Для каждого источника данных заведите отдельную таб лицу. Прежде всего просмотрите письма, обзоры и результаты опросов — это поможет идентифицировать проблемы и составить их список. Оставь те в таблицах побольше места для тех вопросов, которые поначалу будут пропущены. Для каждого из проектных предложений подсчитайте, сколь ко человек одобряет включение в программу данной возможности, а сколь ко не одобряет. Глава 13: Объединяющая 3 8 7 Почти наверняка окажется, что большая часть жалоб связана со срав нительно небольшим количеством проблем. Это хорошо известный принцип Парето (Pareto Principle, Джуран и Грайне (Juran & Gryna, 1980), Мак-Кейб и Шалмейер (McCabe & Schulmeyer, 1987)). Собрав данные, отсортируйте жалобы в порядке убывания их частоты. (Не удивляйтесь, если окажется, что этот порядок для разных источников окажется различным. Обозрева тели отмечают иные проблемы, нежели пользователи, пишущие письма и звонящие в отдел технической поддержки. А мнения пользователей, ото бранных случайным образом и опрошенных сотрудниками компании, бу дут отличаться от мнений первых двух категорий.) На наш взгляд, самым удобным представлением информации являются таблицы жалоб пользова телей, отсортированных по частоте. Но есть и более классический подход — составление диаграммы Парето (Pareto Chart), лучше всего описанной в книге Уолтона (Walton, 1986). Если возможно, приведите в таблицах циф ры затрат на техническую поддержку (затраты на чтение писем и ответы на них, средняя стоимость телефонного звонка, среднее время телефонного разговора с пользователем о каждой из проблем и т.п.). Анализ пользовательского интерфейса Некоторые тестировщики (и авторы документации) обладают талантом выявлять недостатки пользовательского интерфейса еще на этапе его про ектирования. Если среди ваших подчиненных есть такой специалист, под ключите его к анализу проектной документации как можно раньше. Пусть у этого сотрудника будет время как следует прочитать ее и обдумать. Это принесет разработке большую пользу. Обсуждение даты начала тестирования В хорошей команде разработчиков тестирование начинается еще до того, как написан весь программный код. Если же работа организована плохо, в начале проекта масса времени тестировщиков тратится зря. Поэто му с самого начала обсудите с руководителем проекта схему действий. Обычно руководитель охотно пересматривает порядок выполнения про граммистских задач, с тем чтобы повысить эффективность тестирования. Если вы укажите, какие из частей программы сложнее всего протестировать и какие могут содержать наибольшее количество серьезных ошибок, он со гласится, чтобы они были написаны и переданы на тестирование в первую очередь. Если, например, важнейшей из функций разрабатываемой программы является высококачественная печать и если программа должна безукориз ненно работать с самым широким диапазоном принтеров, обсудите с руко водителем проекта, какие из частей программы связаны с реализацией этой функции и какие из них могут быть готовы уже в первой версии програм мы, которая будет передана на тестирование. 3 8 8 Часть III: Управление проектами и группами Что еще включает процесс приготовления к тестированию Если предполагается тестировать программу с определенными видами оборудования, с его производителями следует связаться как можно раньше. Особенно это важно в тех случаях, когда необходимые устройства предпо лагается не купить, а взять напрокат (см. главу 8). Подумайте об исследовании конкурирующих продуктов. Ведущий тес- тировщик проекта должен знать рынок программ разрабатываемого типа и быть в курсе общих для них всех ошибок. Начните поиск бета-тестировщиков. Хороших специалистов найти все гда сложно. Вполне возможно, что вы найдете добровольцев среди бета- тестировщиков конкурирующих продуктов. Однако имейте в виду, что они будут рассказывать конкурентам о достоинствах и недостатках вашей про граммы и о ходе разработки. Некоторые из них передадут копии програм мы своим друзьям или поместят их в Internet. Так что, во-первых, тщательно отбирайте людей, а во-вторых, будьте готовы ко всем возмож ным последствиям. Реализация базовых функций На этом этапе программа может работать только в одном видеорежиме. Она может печатать только на одном принтере. В ней может отсутствовать большая часть задуманных возможностей. Она наверняка полна ошибок. А при эволюционном методе разработки на данном этапе вообще готово только ее ядро. Программирование после реализации базовых функций Программисты продолжают определение частных задач, проектируют все новые и новые модули и пишут программный код. Только при методе водопада к этому времени все проектные работы уже завершены. Еще одно исключение составляют программисты-анархисты, которые сначала пишут программный код, а потом его спецификацию. Тестирование после реализации базовых функций Как только ядро программы готово, можно и нужно приступать к те стированию. Программисты, конечно, проверяют свою работу, но кто- то должен делать это извне. Это может быть тот же программист, его помощник или профессиональный тестировщик. На данном этапе тес тирование может быть еще достаточно неформальным. Можно просто путешествовать по программе, экспериментировать с ней без какого бы то ни было плана. Глава 13: Объединяющая 3 8 9 Однако если разработка ведется эволюционным методом, именно на данном этапе начинается самое что ни на есть серьезное тестирование, цель которого — добиться полной стабильности ядра программного продукта. Для начала определите цели тестирования. Набросайте список ключе вых задач, подумайте, кто из сотрудников может их решать, и приблизи тельно оцените, сколько на это потребуется времени. То, что получится, будет первым черновиком календарного плана и бюджета работ. Несмот ря на свою приблизительность, этот документ очень важен, поскольку послужит основой для дальнейшей работы. Как только продукт оказывается в состоянии делать что-то полезное, кто-нибудь из сотрудников компании должен начать его использовать. В одних компаниях этим занимаются главным образом тестировщики, в дру гих — менеджеры. Особого значения это не имеет, главное, чтобы тести ровщики были в курсе всех выявляемых проблем и вовремя их документировали. Эксплуатация программы в реальном режиме играет в тестировании очень важную роль. Если не работать с продуктом так, как это делает пользователь, целый ряд проблем ускользнет от вашего внима ния. Кроме того, многие ошибки или недостатки интерфейса кажутся не значительными, пока вы не натыкаетесь на них каждый день или каждые пять минут или пока они не затрудняют решение жизненно важной для вас задачи. Именно практика, а не просто эксперименты с программой и од норазовое выполнение ее команд позволяет понять реальную ценность ее возможностей и реальное значение ее недостатков. Почти альфа На этом этапе большая часть программы уже готова, а значит, опреде лился ее стиль и характер. В некоторых компаниях начало альфа-этапа является определенным рубежом, на котором меняются основные направления работы. Например, с этого момента может начаться планирование и выполнение тестов, напи сание руководства. Если так организован и ваш проект, ряд подготовитель ных работ стоит провести заранее, за несколько недель до начала альфа-этапа. Ведущий тестировщик должен поработать с программой и подумать, не осталось ли в ней настолько серьезных проблем и не упуще ны ли настолько значительные функции, что назвать то, что имеется, пол ноценной альфа-версией пока еще нельзя. Кроме того, на этом подготовительном этапе ведутся интенсивные обсуждения с руководителем проекта целого ряда ключевых вопросов. Как можно больше времени за резервируйте для тестирования: ведь необходимо будет убедиться, что все согласованные изменения и исправления успешно внесены. Как правило, окончательная проверка соответствия программы требованиям, предъявля емым к альфа-версии, выполняется руководителем проекта и тестировщи- ками совместно. 3 9 0 Часть III: Управление проектами и группами Альтернативой проверки состояния программы перед официальным объявлением готовности альфа-версии является ее проверка после этого события. Однако в этом случае, хотя руководитель проекта искренне верит, что с программой все в порядке, при дальнейшем тестировании, как пра вило, выявляется еще целый ряд серьезных ошибок. Программирование накануне завершения альфа-версии На этом этапе продолжается постановка задач, проектирование, коди рование, исправление ошибок и тестирование "стеклянного ящика". Документирование накануне завершения альфа-версии План документации, скорее всего, уже практически готов. В одних компаниях тестировщиков привлекают к работе над этим планом, в других — нет. Если вы будете работать на планом, то, скорее всего, от вас потре буется отдельный анализ руководства, интерактивной справочной системы, учебника и других дополнительных материалов (например, библиотеки файлов примеров). Уделите особое внимание календарному плану работ по документированию продукта — если вам придется в них участвовать, ана лиз и редактирование документации не должны совпасть с самыми напря женными периодами тестирования. Как правило, план документации включает ее оглавление и приблизи тельные оценки объема каждого раздела. Вы можете помочь техническим писателям, указав, объемы каких разделов ими недооценены. Если речь зайдет об особенно сложных функциях программы, их выявление может помочь не только техническим писателям. Если руководитель проекта уви дит, что определенная функция настолько сложна, что ее трудно даже описать в руководстве, он может принять решение о переработке проекта программы и упрощении этой функции. Структурой интерактивной справочной системы может определяться и то, как пользователь будет переходить от одной темы к другой. В большин ство современных систем встраиваются перекрестные ссылки, упрощающие работу пользователя, но сильно усложняющие задачу тестировщика. Как протестировать все эти ссылки? Возможно, вы найдете инструментальные средства, упрощающие эту работу. Тестирование накануне завершения альфа-версии Прежде всего позаботьтесь о необходимом для работы оборудовании. Закажите то, что планируется купить, и поищите возможности взять напро кат остальное. Глава 13: Объединяющая 3 9 1 Переговоры с компаниями, у которых можно одолжить необходимую технику, следует начать как можно раньше. Учтите, что придется выпол нить ряд формальностей, заполнить бумаги. Могут возникать неожиданные сложности и задержки, и, если времени до выпуска у вас не так уж мно го, например, месяца три-четыре, вы рискуете не получить того, что заду мано. Если цели и ключевые задачи тестирования еще не определены, откла дывать дальше некуда. Оцените, сколько времени и людей потребуется для решения поставленных задач. Подготовьте первую версию плана тестирования. Начните с самого очевидного, оставив детали "на потом". Во-первых, они еще не раз могут поменяться, а во-вторых, многие подробности станут очевидны позднее, в ходе освоения объекта тестирования. Прежде всего включите в план сле дующее. • Перечислите поддерживаемые устройства (такие, как принтеры). • Составьте список основных функций программы, команд меню, опций, т.е. составьте первый вариант списка тестируемых функций. • Подготовьте структуру плана тестирования, перечень его основ ных разделов. Например, подготовьте место для списка граничных условий, который будет составлен позднее. Стоит еще раз подчеркнуть, что документации не должно быть слиш ком много. Это ваш рабочий инструментарий, который должен отвечать практическим задачам. Все, что не требуется для тестирования, не требу ется вообще. И не поддавайтесь искушению проводить целые дни, состав ляя документацию и вообще не занимаясь тестированием. Обязательно проверяйте на деле все, о чем пишете. Так и документация будет точнее, и основное дело — поиск ошибок — будет продвигаться вперед. Проведите базовое тестирование программы. Выполните самые очевид ные тесты, не затрачивая слишком много времени на каждую из областей или функций. На этом этапе больше внимания уделите полноте охвата продукта, а не глубине анализа каждой детали. Если программа предлага ет пользователю выбор из нескольких вариантов, проверьте их все, одна ко если вариантов десяток, протестируйте два-три из них. Не следует также тестировать все возможные комбинации входных значений — для этого время еще не пришло. Введите информацию везде, где это возможно, но не старайтесь нагрузить программу свыше ее возможностей. Если гранич ные значения данных известны, проверьте их, а если нет — оставьте это на будущее. Посмотрите, как ведет себя программа в нормальном режиме работы, не сбоит ли она даже в тех случаях, когда ее пользователь очень аккуратен. И только если у вас после этого останется еще немного време- 3 9 2 Часть III: Управление проектами и группами ни, подумайте, что могло бы привести программу к сбою, и попробуйте это выполнить. Такое весьма поверхностное тестирование позволит выявить огромное количество ошибок. Прежде чем оно будет выполнено, не стоит вдаваться в нюансы работы отдельных функций и тратить время на те фрагменты программы, которые просто написаны пока еще очень поверхностно, без проработки деталей. Альфа Строгого определения альфа-версии программы не существует. Можно выбрать один из предложенных ниже вариантов, а можно сформировать собственные критерии, отвечающие нуждам конкретного проекта. • В альфа-версии программы имеются практически все ее основные функции. Однако некоторые из них могут еще отсутствовать или работать крайне нестабильно. Индивидуальность программы на этом этапе уже полностью сформирована, виден ее характер и основные возможности. А вот такие детали оформления, как музыка и графи ка, могут пока еще отсутствовать. Если программа должна поддер живать ряд устройств, форматов данных, взаимодействовать с рядом однотипных приложений и т.п., в альфа-версии может поддержи ваться только несколько экземпляров из этого набора. • В альфа-версии программы имеются все ее функции, хотя в неко торых из них могут еще оставаться серьезные ошибки; поддержива ются все типы устройств, но работает только по нескольку устройств каждого типа. Спецификация и конструкторская документация практически готовы, все основные программистские задачи выпол нены. Никаких неожиданных трудностей в дальнейшем не предви дится. • При эволюционном методе разработки в альфа-версии ядро про граммы полностью сформировано. Кроме того, написаны все важ нейшие функции программы, она представляет собой, хотя и ограниченный в своих возможностях, но уже вполне приемлемый продукт. Им можно пользоваться, видны его идеология и характер, однако многих полезных функций пока еще нет. Программирование после завершения альфа-версии По достижении альфа-рубежа у программистов остается еще очень много работы: доработка функций, исправление ошибок, пересмотр внеш него дизайна и спецификации в ответ на замечания пользователей и тес- тировщиков, переработка внутренней структуры программы в целях повышения ее производительности. Начинается (или продолжается) рабо- |