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

виде программа действительно не устраивает пользователей. Или требует проверки того, что ошибка осталась и в следующей версии программы (хотя программист ее не исправлял, а просто надеется, вдруг она исчезла сама собой при исправлении других ошибок). Другой тактикой подобны:; недобросовестных программистов является так называемая песчаная буря: на профессиональном жаргоне, непонятном тестировщику, программист путанно объясняет, что внесение изменений в эту часть программного кода может подорвать основы всей системы и самым серьезным образом отра­зиться на ее надежности.

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

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

Когда проблема объявлена решенной

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

и, возможно, добавляет некоторые комментарии. Однако на этом работа с отчетом вовсе не заканчивается. Программист часто ошибается. Проблема может остаться нерешенной, или внесенные в программу изменения могут породить новые ошибки. Наш собственный опыт разработки коммерческо го программного обеспечения показывает, что 10% неудачных исправлений

— это еще очень хороший показатель. Если программист работает с таким коэффициентом, значит, нам повезло, и он исключительно профессиона­лен и внимателен. Если же 25% отчетов, помеченных программистом как исправленные, на самом деле не выдерживают проверки, мы, конечно, не в восторге, но и не считаем это чем-то из ряда вон выходящим. Как отме­чалось в главе 3, при разработке крупных систем зафиксированы гораздо большие коэффициенты неудачных исправлений, вплоть до 80%.

Повторное тестирование программы по отчету, возвращенному програм­мистом с пометкой Исправлено, лучше всего проведет тот тестировщик, который составил данный отчет. Если же его составил кто-то, кто не вхо­

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

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

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

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

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

Если же исходный тест программа прошла и “засыпалась” на связанной ошибке, лучше закрыть отчет, оставив на нем резолюцию Исправлено, и написать новый. Большинство руководителей проектов и программистов предпочитают именно такой способ работы. Отчеты получаются меньши­ми и более простыми, чем те, в которых отслеживается целая цепочка исправлений связанных ошибок.

Невоспроизводимые проблемы

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

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