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

статков исходного проекта программы, руководитель группы тести­рования может попросить сократить количество подобных отчетов. В противном случае руководство может интерпретировать большое количество составляемых отчетов как показатель ненадежности про­граммы. На самом же деле значительная часть недостатков проекти­рования так и не будет исправлена, особенно ближе к концу разработки — а раз так, вероятно их не стоит документировать. Такая логика конечно же не идет на пользу разработке. Во-первых, те ошибки кодирования, которые приняты тестировщиком за ошиб­ки проектирования, не документируются и в результате остаются неисправленными. А во-вторых, когда наступает черед следующего выпуска программного продукта, база данных, в которой могла бы присутствовать информация о недостатках первого выпуска, оказы­вается пустой, и все приходится начинать “с нуля”.

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

Администрация компании нередко требует предоставить наглядные сведения, позволяющие оценить производительность работы конкретного сотрудника, особенно если хочет его уволить или оказать на него давление. И конечно, в первую очередь источником такой информации считают базу данных. Ведь в ней масса готовой подробной информации о каждом тес­тировщике, программисте, руководителе проекта. Практически отражен почти каждый их шаг. Можно узнать среднее количество ошибок, выявля­емых конкретным тестировщиком и сравнить его с показателями других сотрудников. Можно сравнить количество ошибок, допускаемых разными программистами. Можно сравнить количество ошибок, выявляемых в раз- 111, [х проектах, и по ним сравнить работу их руководителей. Кроме того, можно сравнить количество откладываемых и отвергаемых ими отчетов.

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

Против всех подобных попыток оценки производительности сотрудни­ков по статистическим данным необходимо возражать самым решительным образом, кто бы ни запросил соответствующие данные. Это могут сделать как руководители, так и сами сотрудники, но в любом случае, какими бы настойчивыми ни были требования, как бы ни давило на вас руководство, сколько беспокойства ни причинял бы сотрудник, оказавшийся в центре внимания, — не сдавайтесь. Система предназначена для отслеживания проблем с тестируемым программным обеспечением, а не производитель­ности персонала, которую хранящиеся в ней данные не отражают с доста­точной объективностью. Если ее использовать для анализа производительности сотрудников, это безнадежно подорвет их доверие к системе (см. перечни литературы о компьютеризированном анализе произ­водительности персонала в обзоре Ирвинга, Хиггинса и Сейфейни (Irving, Higgins, Safayeni, 1986)). В результате сопротивления персонала нормаль­ное функционирование системы отслеживания проблем будет нарушено, и из полезного и эффективного средства организации работы она превратится в ее тормоз и инструмент для выяснения отношений. Вам, как руководи­телю группы тестирования, это дорого обойдется. Поэтому использование базы данных для анализа производительности персонала — это одна из самых серьезных тактических ошибок, какие только можно допустить.

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

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