Глава 6: Система отслеживания проблем 143

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

Для успешного проведения работ подобные регулярные совещания исключительно важны. Прежде всего, если у тестировщиков и персонала группы технической поддержки не будет официальной возможности опро­тестовывать принятые руководителем решения, они найдут для этого не­формальные средства. Они могут демонстрировать ошибки, которые считают особенно важными, персоналу группы маркетинга, директорам, вице-президентам, президенту компании, газетчикам и т.д. В результате маленькая производственная проблема может превратиться в большую политическую. Если же позволить каждому заинтересованному сотрудни­ку официально высказать свои аргументы, до политических баталий дело не дойдет. И когда участники совещания согласятся с решением руководи­теля проекта отложить определенный отчет, это решение будет окончатель­ным и больше вопросу не будет уделяться ни внимания, ни рабочего времени сотрудников. Для сравнения предположим, что единственное со­вещание по отложенным проблемам проводится в самом конце разработ­ки — за две недели до завершения тестирования. Если на нем будут пересмотрены решения более чем по двум-трем отчетам, то разработчики рискуют не уложиться в сроки. В результате участники совещания не бу­дут иметь полной свободы выбора: им придется прежде всего учитывать оставшееся время, а от этого пострадает качество конечного продукта. Зная это, все заинтересованные лица будут стремиться поднять важные вопро­сы задолго до официального совещания, а значит, снова производственные вопросы превратятся в политические. Поэтому безусловно, лучше всего решать все подобные проблемы на регулярной и официальной основе, т.е. с самого начала тестирования программного продукта проводить достаточ­но частые совещания по откладываемым отчетам.

Нерешенные проблемы

Случается, что отдельные отчеты о проблемах теряются, их рассмотре­ние намеренно откладывается, о них забывают или им назначают слишком низкий приоритет. До завершения разработки все они обязательно долж­ны быть рассмотрены. Это очень важное правило, и, если ему не следовать, это породит безалаберность со всеми вытекающими последствиями.

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

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

144 Часть II: Приемы и технологии тестирования

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

Отчеты о состоянии проекта

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

Отчеты о состоянии проекта помогают руководству оценить эффектив­ность работы тестировщиков и программистов, текущее качество программ­ного продукта, а также определить соотношение количества выявляемых и исправляемых ошибок, по которому можно составить предположения от­носительно даты завершения разработки.

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

В предыдущем разделе рассказывалось о том, какой путь проходят ис­ходные отчеты в системе отслеживания проблем: что с ними происходит, кто их читает и дополняет новой информацией, как они теряются и нахо­дятся снова. Теперь на этот же процесс полезно посмотреть глазами сотруд­ников компании. Каковы их нужды и требования? И чем может им помочь автоматизированная система отслеживания проблем?

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

Ведущий тестировщик

Этот сотрудник руководит работами по тестированию программного продукта и отвечает за их качество и за документирование выявляемых проблем. Он анализирует все спорые отчеты, включая и те, которые воз­вращены тестировщикам из-за невозможности воспроизвести ситуацию,