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

• Стоит ли документировать недостатки интерфейса после того, как этап разработки, на котором разрешено его изменять, завершен?

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

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

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

1. Вы решите не документировать новую ошибку из-за ее сходности с предыдущей.

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

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

2. Вы решите, что, вероятнее всего, столкнулись с разными ошибками, и составите новый отчет.

• Если вы правы, обе ошибки будут исправлены.

• Если нет, будет зря затрачено время сотрудников компании: ваше

— на составление отчета, руководителя проекта — на его чтение и оценку, программиста — на исследование и анализ, в результате которого он выяснит, что ошибка уже исправлена, и снова ваше

— на повторное тестирование и закрытие отчета. Это риск произ­водителя — ведь в конечном счете все это выливается для него в дополнительные материальные и временные затраты.

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

	Вы документируете ошибку	Вы ее игнорируете
Это новая	Ошибка	Ошибка остается
ошибка	исправляется	(риск пользователя)
Это старая	Потеря времени	Ошибка
ошибка	(риск производителя)	исправляется

РИСУНОК 6.11. Проблема похожих ошибок

Получается, что за каждую вашу ошибку платит одна из сторон. Как же быть и чем лучше рискнуть?

Внедряя в коллективе тестировщиков определенные принципы и выс­казывая требования и пожелания, необходимо принять во внимание ряд психологических особенностей исполнителей, которые отразятся на каче­стве их работы. Канер описал эти особенности на основе исследований уже упоминавшейся теории интерпретации сигналов (Green & Sweets, 1966). Вот к каким выводам он пришел.

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

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

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