Тестирование-книга. Ю. Н. Артеменко Научный редактор
 Скачать 6.27 Mb.
|
|
Программирование после "замораживания" пользовательского интерфейса Программисты продолжают исправлять ошибки, но делают это так, чтобы внешне ничего не менялось. Они работают над повышением произ- 4 1 6 Часть III: Управление проектами и группами водительности программы, разрабатывают образцы файлов данных, пишут установочное программное обеспечение. Зная, что программа установки разрабатывается или, по крайней мере, дорабатывается в последнюю оче редь, авторы документации обычно откладывают описание процесса уста новки программы. Если предполагается распространять демонстрационную версию продукта, то ее разработка обычно также начинается после "замо раживания" пользовательского интерфейса. Маркетинговая деятельность после "замораживания" пользовательского интерфейса Поскольку дизайн продукта "заморожен", обозреватели периодических изданий больше не могут требовать его изменений. Группа маркетинга приступает к массированной подготовке рынка, работая над тем, как эф фектнее представить продукт будущим пользователям. Ее сотрудники гото вятся к рассылке демонстрационной версии продукта, дорабатывают наклейки, этикетки и прочие графические и текстовые материалы, чтобы то, что написано и нарисовано на коробке, полностью соответствовало ее содержимому и реклама продукта была достоверной. На этот этап приходится пик активности группы маркетинга, но боль шая часть ее деятельности никак не касается тестирования. Впрочем, если продукт выйдет позже запланированного срока, вся маркетинговая работа окажется проделанной впустую — пользователи забудут об анонсированном продукте, и всю рекламную деятельность придется начинать сначала. Документирование после "замораживания" пользовательского интерфейса С этого момента может быть "заморожен" и текст справочной системы, хотя чаще это делается несколькими днями или неделями позже. В неко торых компаниях используется прямо противоположная стратегия, когда основная часть текста справочной системы пишется после "заморажива ния" пользовательского интерфейса. Это наилучшее время для снятия копий экранов и последней провер ки точности руководства. Вслед за этим руководство верстается и отправ ляется в печать. Одни компании придерживают руководство до тех пор, пока не будет готов окончательный вариант программы, в других готовится первая печатная копия, которая еще раз редактируется перед началом финального тестирования. Тестирование после "замораживания" пользовательского интерфейса Заранее запланируйте время для проверки точности руководства пользо вателя. Если вы прорабатывали его достаточно тщательно, на этот раз Глава 13: Объединяющая 4 1 7 довольно беглого просмотра. Задержитесь только на подробных описани ях процедур или последовательностей событий, пошаговых инструкциях и копиях и описаниях экранов. На проверку каждых десяти страниц долж но уходить примерно около часа. К этому времени каждая область программы уже тщательно вами иссле дована. Оставшееся время, скорее всего, будет затрачено на регрессионное тестирование. Следуйте своему плану. Пора пересмотреть сложившийся список регрессионных тестов, особен но для тех областей программы, которые зарекомендовали себя лучше всего. • Если пара тестов похожа, слабейший из них можно удалить. Мож но его заархивировать, но попадаться вам на глаза он больше не должен. • Проверьте, нет ли в наборе неэффективных тестов. Если програм ма постоянно проходит определенные тесты, заархивируйте их и удалите из регрессионного набора. Некоторые из таких тестов мож но оставить, но выполнять не на каждом цикле тестирования. Скорее всего, вы продолжите тестирование некоторых внешних уст ройств, даже если программа будет уже работать с ними вполне коррект но. А вот поиск недостатков дизайна после его "замораживания" прекраща ется. Важнее убедиться, что не осталось никаких серьезных функциональ ных ошибок. Продолжайте добавлять в план важные или интересные тесты. Что касается остальных, то не стоит тратить много времени на их докумен тирование — просто выполняйте их и все. Пользуясь теперь уже фундаментальными знаниями о программе, по ищите пути разрушения данных. Изменяйте их чуть-чуть и очень сильно, меняйте сами данные и их формат по отдельности и вместе. Отслеживай те изменения содержимого и объема памяти программы в поисках возмож ных предпосылок будущих проблем. Просмотрите открытые отчеты об ошибках. Почему эти ошибки до сих пор не исправлены? • Еще раз протестируйте программу по всем открытым отчетам. Может быть, какие-то из описанных в них ошибок на самом деле уже исправлены. Однако то, что проблему не удается воспроизвес ти, еще не значит, что это так. Проверьте, воспроизводится ли ошибка в той версии программы, по которой составлялся отчет. Затем спросите у руководителя проекта, действительно ли ошибка исправлена. • Попробуйте упростить оставшиеся отчеты. 418 Часть III: Управление проектами и группами • В ответ на игнорирование ошибок действуйте эффективно. В кон це проекта может наметиться тенденция к массовому исчезновению, откладыванию и забыванию отчетов, они могут попадать к програм мистам с большими задержками. Сознательно или несознательно вся команда, включая и руководителя проекта, может стремиться изба виться от составляемых вами отчетов, вместо того чтобы активнее исправлять описанные в них ошибки. Пусть это послужит вам сиг налом, что люди устали и деморализованы бесконечными задержка ми и проблемами. Постарайтесь в такой ситуации действовать профессионально. В обстановке, когда общее напряжение достигло предела, эмоции и открытое выражение недовольства только навредят делу. Вашим оружием в этой битве может стать система отслеживания проблем. Еженедельно составляйте отчеты об отложенных и нере шенных вопросах и направляйте их не только младшему, но и сред нему и высшему руководству. Если вашим непосредственным руководителям это не понравится, настаивайте на том, что такое широкое распространение отчетов в конце разработки является стан дартной процедурой. Постоянное напоминание о недоделанной ра боте заставит сотрудников понять, что, пряча голову в песок, ошибок не исправить. Если эта тактика не сработает, напишите докладную записку и спро сите у руководителя, как вам быть. Удачи! Подготовка к финальному тестированию На этом этапе доделывается все, что еще не готово, в частности, дора батываются файлы данных и установочные утилиты. К его началу не дол жно остаться ни одного открытого отчета о проблеме. Иногда в начале этого же этапа "замораживается" пользовательский интерфейс. Тестирование программы, однако, продолжается, и вполне возможно обнаружение еще нескольких серьезных ошибок. После их исправления, когда больше ничего серьезного найти не удается, начинается этап после дней проверки целостности. Программирование на этапе подготовки к финальному тестированию Программисты исправляют только те ошибки, о которых распорядится руководитель проекта. Остальные остаются неисправленными, даже если исправить их совсем несложно. Руководитель проекта откладывает эту Глава 13: Объединяющая 4 1 9 работу до следующего выпуска программы, поскольку слишком велик риск, что исправление одной ошибки повлечет за собой другие, которые останут ся незамеченными. Документирование на этапе подготовки к финальному тестированию Технические писатели готовят сопутствующие материалы, проспекты, тексты файлов. Все это вам необходимо будет проверить. Значительная часть информации приложений будет исходить от вас. Прежде всего, это сведения о самых последних изменениях продукта, вне сенных уже после того, как руководство пользователя ушло в печать. Тех ническим писателям важны изменения дизайна продукта (измененные диалоговые окна, меню, команды), новые предупреждения и сообщения об ошибках и изменения возможностей программы (например, максимальное количество одновременно обрабатываемых объектов). Тестирование на этапе подготовки финальной версии Для тестировщиков этап подготовки к выпуску финальной версии яв ляется особенно важным. Если в программе остались настолько серьезные ошибки, что ее нельзя выпускать в производство, это ваш последний шанс их найти. Главными направлениями работы сейчас являются следующие. • Продолжайте поиск серьезных проблем. Если в течение определен ного времени ни одной такой проблемы найти не удастся, это будет означать, что работа окончена. Дальше будет выполнена последняя проверка целостности продукта, после чего он уйдет в производство. На этом этапе на первый план снова выходит стратегия поиска ошибок под руководством интуиции и опыта, а не формального плана. Проверьте все наиболее слабые точки программы, выполняй те любые тесты, которые кажутся вам наиболее обещающими. • Убедитесь, что при последних исправлениях ошибок ничего не нару шилось. Когда вы получаете по три новых версии в день, а на вы полнение тестового плана требуется две человеко-недели, эта задача оказывается не из легких. В этом случае наиболее эффективна сле дующая технология. Получив очередную версию программы, преж де всего проверьте, как работает последний исправленный фрагмент и ничего ли не нарушено вокруг него. Затем перейдите к общему те стированию по плану, продолжив его с того места, на котором вы остановились, получив данную версию. Выполнив таким образом весь план и меняя версии программы по его ходу, начинайте новый цикл. 4 2 0 Часть III: Управление проектами и группами • Поиск упущенного. Возможно, что, еще раз проверив всю докумен тацию, вы найдете несколько невыполненных тестов, не до конца протестированных устройств и другие неоконченные или вообще забытые задачи. По окончании данного этапа ни один критический тест не должен остаться невыполненным. На бумаге все выглядит просто, но на деле это самый напряженный и изнурительный из всех этапов проекта. Скорее всего, вы найдете несколько достаточно серьезных ошибок, которые придется исправить. После каждого исправления вам будет немедленно передаваться новая версия программы. Это может происходить каждый день или даже дважды либо трижды в день. И тестировать ее необходимо будет немедленно. Иногда случается, что руководитель проекта забывает сказать вам об изменениях, внесенных в самую последнюю минуту. Поэтому после полу чения каждой новой версии лучше всего сравнивать все ее файлы с их предыдущими вариантами. Заметив отличие, не связанное с тем изменени ем, о котором вам сообщили, спросите у руководителя проекта, что оно означает. Проведите еще один цикл тестирования устройств. Убедитесь, что каж дое из них проверено во всех возможных режимах. Прогоните еще раз архивные тесты — программа их почти наверняка пройдет, но убедиться в этом еще раз все же не помешает. Проверьте, как ведет себя каждая исправленная часть программы, окон чательно ли покончено с найденными ошибками. В последний раз раздайте сотрудникам список отложенных проблем. Поскольку все их команда разработки уже рассматривала на последнем совещании, это чистая проформа. Однако руководство все же должно на последок еще раз оценить качество выпускаемого продукта. Оценка надежности продукта После окончания последнего этапа тестирования продукта он либо отправляется в производство и затем в продажу, либо передается в руки тех, кому предстоит выполнить его приемочное тестирование. Перед тем как продукт покинет стены компании, тестировщиков попро сят дать оценку качества программы. Готова ли она к выпуску? Руковод ство компании вполне может проигнорировать ваше мнение на этот счет и поступить по-своему, однако узнать его захочет наверняка. У качества продукта множество составляющих, включая интерфейс, функциональные возможности, полезность и надежность. Однако руковод ство, скорее всего, мало интересует, что вы думаете о дизайне программы, ему важно ваше мнение о ее надежности. Поэтому заранее подготовьтесь высказать свою оценку именно этой составляющей качества, возможно, лишь с некоторыми комментариями по поводу дизайна. Глава 13: Объединяющая 4 2 1 Высокая надежность продукта означает, что пользователи едва ли най дут в нем ошибки. Если же такая вероятность достаточно велика и особен но если в процессе эксплуатации могут проявиться достаточно серьезные ошибки, надежность продукта считается низкой. Обычно большинство ру ководителей устраивает следующая система оценки. • Низкая надежность. В продукте имеются серьезные ошибки, кото рые пользователь, скорее всего, обнаружит. Все это известные офи циально отложенные проблемы. • Средняя надежность. Посредине между высокой и низкой. • Высокая надежность. Продукт хорошо протестирован, и больше ни одной серьезной проблемы в нем найти не удается. Возможно, ка кие-то проблемы и остались не замеченными тестировщиками, но и пользователи едва ли их заметят. • Степень надежности неизвестна. Программа не была адекватно протестирована, или тестировщики сделали все от них зависящее, ничего ужасного не нашли, но уверены, что некоторые серьезные проблемы еще остались. В этом случае необходимо объяснить, на чем основаны ваши подозрения, и предложить четкий план выявле ния предполагаемых проблем. Этим планом может предусматривать ся помощь сторонних консультантов или аренда необходимого аппаратного обеспечения, причем и то, и другое должно выполнять ся очень быстро. Минимальная надежность Ни одна компания не выпустит продукт, не соответствующий ее мини мальным стандартам качества. Вам эти стандарты могут быть неизвестны, поскольку едва ли они документально зафиксированы. Однако в общем случае как минимум требуется следующее. • Все граничные значения входных данных протестированы. Если программа отвергает определенные значения, она должна делать это корректно. • Последняя версия руководства тщательно проверена. Она правиль но описывает поведение программы. Тестировщики выполняли все упомянутые в ней команды, выбирали все возможные значения опций, выполняли все описанные последовательности действий и отвечали на все задаваемые программой вопросы всеми возможны ми способами. Все это работает, по крайней мере, если речь не идет о каких-либо совершенно неожиданных комбинациях. • Протестированы все основные аппаратно-программные конфигура ции. Программа работает как минимум с наиболее распространенны- 4 2 2 Часть III: Управление проектами и группами ми типами аппаратуры и системного программного обеспечения из тех, с которыми она должна быть совместима. • Редактирование параметров команд, повторение действий и любые их последовательности не должны выводить программу из равнове сия. • Система устойчива к любым ошибкам, которые может допускать пользователь. На самом деле стандарты компании должны быть гораздо выше, и так оно, скорее всего, и есть. Попробуйте составить свой собственный список, дополняя вышеперечисленные критерии теми, о которых вам удастся уз нать. Этот список может стать вашей опорой в обосновании ненадежнос ти выпускаемой программы, если такая необходимость возникнет. Если программа не соответствует какому-либо из перечисленных критериев, степень ее надежности считается неизвестной. Сообщив об этом руковод ству, вполне можно получить дополнительное время для тестирования ее ненадежной области. Нередко на рынке появляются продукты, явно не соответствующие даже базовым критериям надежности. На наш взгляд, в этом полностью вино ваты тестировщики. Если бы они вовремя поставили руководство в изве стность о ненадежности определенной области программы, проблема вполне могла бы быть решена. Оценка надежности каждой составляющей продукта Надежность каждой области или составляющей программного продук та имеет смысл оценивать отдельно. Насколько вероятен сбой? Чтобы от ветить на этот вопрос, необходимо знать уровень тестирования каждой из областей и то, как программа проходила выполняемые тесты. Можно даже регулярно публиковать отчеты о состоянии продукта с перечнем всех его функциональных областей и классов выявленных проблем и с оценками надежности каждой области. Если оценка надежности определенной области программы оказывает ся низкой, перечислите в отчете все проблемы, на которых основано такое заключение. Если, на ваш взгляд, целый ряд проблем еще только предстоит выявить, напишите и об этом. Укажите, сколько примерно времени пона добится для того, чтобы подтвердить или опровергнуть ваши предположе ния. Будьте готовы объяснить, как вы собираетесь это сделать. Если определенная область программы не протестирована как следует, степень ее надежности неизвестна. Однако одной констатации этого фак та мало. Укажите в отчете, сколько времени потребуется на проведение неформального тестирования, позволяющего хотя бы приблизительно оце- Глава 13: Объединяющая 423 нить надежность данной области. Приведите примеры возможных ошибок. В случае затруднений обратитесь к приложению этой книги. Опишите наиболее серьезные проблемы, которые не могли быть выявлены уже про веденными тестами. Вы не можете утверждать, что в программе имеются конкретные ошибки. Однако если вы пока не уверены в их отсутствии, об этом необходимо сказать. Окончательное решение Последнее слово всегда остается за руководством. Оценивать степень риска и вероятность успеха — это его работа. В одних случаях принимается решение немедленно выпустить несколько несовершенный продукт, в дру гих же — решение выпустить его в следующем году, но зато уж абсолют но безупречным. Факторов, влияющих на принятие того или иного решения, может быть очень много, и прежде всего для этого необходимо глубокое знание рынка и четкое видение собственной позиции и целей компании, которое имеется только у ее руководства. Работа руководителя группы тестирования заключается в другом — гарантировать правильное понимание руководством степени риска. Во что обойдется этот риск компании, руководство знает и так, как и то, что поставлено на карту. Руководству известно, во что обходится каждая неделя задержки. Ему известна стоимость проводимых работ. От вас ему важно узнать о степени вероятности серьезных сбоев программы, которые могут повлиять на ее популярность или иметь другие неприятные для компании последствия. Таким образом, ваша обязанность заключается в том, чтобы предостав лять людям, принимающим решения, всю необходимую для этого инфор мацию, касающуюся вашей работы. Информация о качестве продукта должна поступать им вовремя, в понятной и простой форме, не оставляю щей возможности для домыслов и недопонимания. Еще раз: и окончательное решение о выпуске продукта, и стандарты его качества принимаются не вами, а руководством компании. Какого бы мнения вы ни были об этих стандартах, ваша задача выполнить свою ра боту настолько хорошо, насколько это возможно. И если вы будете следо вать описанной в данной главе стратегии, это у вас получится. |