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