Тестирование-книга. Ю. Н. Артеменко Научный редактор
 Скачать 6.27 Mb.
|
|
Глава 6: Система отслеживания проблем 1 5 3 проблеме необходимо привлечь внимание руководства. Среди ошибок, заслуживающих внимания высшего руководства, можно выделить следую щие: • Поведение программы дискредитирует компанию. Так можно ска зать о грубом тоне сообщений об ошибках, порнографических или не вполне пристойных изображениях и текстах, ругательствах, вклю ченных в программный код. Даже если программа не выводит их на экран и большинство пользователей программы их не увидит, навер няка найдутся энтузиасты, которые прочтут текст программных файлов и поделятся своими открытиями с окружающими, так что в конечном счете эта информация всплывет в Internet и печатной периодике. • Ошибки программы лишают ее тех преимуществ или блокируют те ее функции, которые были объявлены в рекламных анонсах, либо блокируют возможности, которых ожидает от нее каждый разум ный пользователь. Если текстовый процессор не способен распеча тывать тексты и руководитель проекта решил не исправлять этот недостаток, тогда должен вмешаться руководитель более высокого уровня. То же самое касается и более мелких функций программы, от которых, тем не менее, зависит ее конкурентоспособность. • Поведение программы вызовет резкое недовольство здравомысляще го пользователя. Если подсистема защиты от несанкционированного копирования стирает всю информацию на жестком диске нарушите ля, об этом необходимо поставить в известность президента или юриста компании, прежде чем выпускать такую программу в прода жу. О менее серьезных проблемах руководству сообщать не стоит, как и о тех, которые пока еще не отложены руководителем проекта. Иначе вы просто потеряете доверие руководства. Руководство прежде всего интересует состояние проекта, ему требует ся наглядная и объективная итоговая информация, а на анализ подробно стей у него нет времени. Вам придется предоставлять отчеты с еженедельными данными о количестве выявленных, исправленных и ожи дающих исправления ошибок. С этими цифрами следует обращаться осо бенно осторожно, избегая их интерпретации как показателей производительности работ. Именно на этой почве возникает множество проблем и конфликтных ситуаций. Вот несколько примеров. • Неверная интерпретация руководством статистических данных препятствует привлечению к работе над проектом новых тести ровщиков. Когда новый тестировщик начинает работать с програм- 1 5 4 Часть II: Приемы и технологии тестирования мой, он, как правило, вносит ряд проектных предложений и повтор- но поднимает вопросы о некоторых отложенных проблемах. В ре- зультате количество составляемых отчетов повышается, и это создает впечатление, что качество программы неожиданно ухудшилось. Ру- ководителю проекта приходится объяснять все это начальству каж дый раз, когда к работе над проектом подключается новый сотрудник, и в конце концов он просит руководителя группы тести рования не расширять больше свою группу. • Неверная интерпретация руководством статистических данных препятствует проведению последнего критического анализа интер фейса продукта перед тем, как все дальнейшие его изменения будут запрещены. Незадолго до запрещения дальнейших изменений пользовательского интерфейса программы руководители проекта ; часто распространяют среди как можно более широкого круга со- 1 трудников копии экранов, некоторые проектные документы и бета- копии программного обеспечения. Цель этой акции — собрать как можно больше замечаний от технических писателей, тестировщиков, сотрудников групп маркетинга и технической поддержки и внести все изменения, которые будут найдены полезными, пока это еще возможно. Поскольку все критические замечания и предложения будут внесены в базу данных, это вызовет резкий подъем статиста- ческих показателей количества выявляемых проблем, и, хотя на самом деле надежность продукта при этом не изменится, руководи- телю проекта придется оправдываться перед начальством, объясняя настоящие причины такого "обвала" ошибок. Чтобы избежать таких ситуаций, руководители проекта часто отказываются от проведения такого финального массированного анализа проекта или же не вно- сят его результаты в базу данных. Нечего и говорить, что в резуль тате страдает качество разрабатываемого продукта. * Контроль руководством статистических данных заставляет руко- водителя проекта следить, чтобы в базу данных не попадали отче- ты об одной и той же проблеме, составленные разными \ тестировщиками. Если четыре тестировщика обнаружат одну и ту \ же проблему и составят о ней отчеты, статистическая сводка пока жет четыре ошибки вместо одной. Чтобы улучшить показатели, ру- ководитель проекта вынужден будет отслеживать подобные ситуации, попусту тратя рабочее время — свое или сотрудников. Под давлением статистического контроля со стороны руководства . руководитель проекта может попросить тестировщиков не со- ставлять отчеты об ошибках проектирования. Обратив внимание, что некоторые тестировщики документируют слишком много недо- Глава 6: Система отслеживания проблем 1 5 5 статков исходного проекта программы, руководитель группы тести рования может попросить сократить количество подобных отчетов. В противном случае руководство может интерпретировать большое количество составляемых отчетов как показатель ненадежности про- граммы. На самом же деле значительная часть недостатков проекти рования так и не будет исправлена, особенно ближе к концу разработки — а раз так, вероятно их не стоит документировать. Такая логика конечно же не идет на пользу разработке. Во-первых, те ошибки кодирования, которые приняты тестировщиком за ошиб ки проектирования, не документируются и в результате остаются неисправленными. А во-вторых, когда наступает черед следующего выпуска программного продукта, база данных, в которой могла бы присутствовать информация о недостатках первого выпуска, оказы вается пустой, и все приходится начинать "с нуля". • Под давлением статистического контроля со стороны руководства руководитель проекта закрывает отложенные отчеты раньше вре мени. Некоторые руководители проектов слишком поспешно откла дывают проблемы, которые, возможно, еще могли бы быть решены. Безапелляционным решением они закрывают соответствующие от четы, чтобы улучшить статистические показатели. Более разумные и опытные руководители назначают откладываемым отчетам низкий приоритет, с тем чтобы, если у программиста останется время, он мог все же исправить описанные в них ошибки — возможно, по ходу исправления других ошибок в той же части кода. В результате многие мелкие ошибки и косметические недостатки программы исправляются по ходу основных работ по отладке, ничуть не затя гивая разработку. Хотя один такой мелкий недостаток не влияет на качество результирующего продукта, если исправить 50 из 100 таких недостатков, продукт наверняка произведет более достойное впечат ление. Администрация компании нередко требует предоставить наглядные сведения, позволяющие оценить производительность работы конкретного сотрудника, особенно если хочет его уволить или оказать на него давление. И конечно, в первую очередь источником такой информации считают базу данных. Ведь в ней масса готовой подробной информации о каждом тес- тировщике, программисте, руководителе проекта. Практически отражен почти каждый их шаг. Можно узнать среднее количество ошибок, выявля емых конкретным тестировщиком и сравнить его с показателями других сотрудников. Можно сравнить количество ошибок, допускаемых разными программистами. Можно сравнить количество ошибок, выявляемых в раз ных проектах, и по ним сравнить работу их руководителей. Кроме того, можно сравнить количество откладываемых и отвергаемых ими отчетов. 1 5 6 Часть II: Приемы и технологии тестирования Против всех подобных попыток оценки производительности сотрудни ков по статистическим данным необходимо возражать самым решительным образом, кто бы ни запросил соответствующие данные. Это могут сделать как руководители, так и сами сотрудники, но в любом случае, какими бы настойчивыми ни были требования, как бы ни давило на вас руководство, сколько беспокойства ни причинял бы сотрудник, оказавшийся в центре внимания, — не сдавайтесь. Система предназначена для отслеживания проблем с тестируемым программным обеспечением, а не производитель ности персонала, которую хранящиеся в ней данные не отражают с доста точной объективностью. Если ее использовать для анализа производительности сотрудников, это безнадежно подорвет их доверие к системе (см. перечни литературы о компьютеризированном анализе произ водительности персонала в обзоре Ирвинга, Хиггинса и Сейфейни (Irving, Higgins, Safayeni, 1986)). В результате сопротивления персонала нормаль ное функционирование системы отслеживания проблем будет нарушено, и из полезного и эффективного средства организации работы она превратится в ее тормоз и инструмент для выяснения отношений. Вам, как руководи телю группы тестирования, это дорого обойдется. Поэтому использование базы данных для анализа производительности персонала — это одна из самых серьезных тактических ошибок, какие только можно допустить. Перечисленные выше проблемы в основном касались попыток отслежи вания производительности тестировщиков. Они будут еще серьезнее, если дело коснется сотрудников, которые вам не подчиняются, — программис тов и руководителей проектов. Если и их работа будет отслеживаться по статистическим данным, предоставляемым системой отслеживания про блем, то каждый раз, когда в базу данных будет вноситься информация, так или иначе ухудшающая их показатели, эти сотрудники будут просить ее удалить. Если вы откажетесь, программист или руководитель проекта об ратится за поддержкой к своему начальнику, руководителю отдела анали за человеческого фактора, и неизвестно, к кому еще. И это будет только справедливо. Если система предоставляет руководству информацию о про изводительности сотрудников, затрагивая тем самым их жизненные инте ресы, им придется защищаться. Начнется самая настоящая война, и вот как будут действовать в ней ваши противники. • Вас будут просить удалять из базы данных все дублирующиеся отчеты о проблемах. Если отчеты и в самом деле дублируют друг друга, это еще ничего, хотя и будет стоить вам времени. Но как быть с отчетами о похожих ситуациях, которые могут быть вызваны од ной и той же ошибкой, но могут и разными. Если удалить все по хожие отчеты, оставив только один из них, это может означать потерю информации о связанных с ними ошибках. Глава 6: Система отслеживания проблем 157 Вас будут просить удалять из базы данных все, пусть даже и не похожие, отчеты о проблемах, вызванных одной и той же внутрен ней ошибкой программы. Нередко случается, что совершенно раз личные симптомы вызываются одной и той же ошибкой программы. Следует ли в этом случае отозвать все связанные с ней отчеты, кроме одного? Хорошо бы, но только как определить, что причина всех описанных в них ситуаций одна и та же? Довериться програм мисту? Самостоятельно проанализировать программный код? Не поверить программисту и положиться на собственное суждение? (Имейте в виду, что подобное недоверие всегда воспринимается крайне болезненно.) Вас будут просить удалять из базы данных все вопросы, поскольку они не являются отчетами об ошибках. Соответственно нечего и ждать, что вы получите на них ответы. Вас будут просить удалять из базы данных все предложения и боль шинство отчетов об ошибках проектирования. Конечно, если по ведение программы соответствует спецификации, оно не считается ошибкой. Однако, по нашему опыту, около 15% всех предлагаемых тестировщиками изменений воплощаются, если не в текущем, то, по крайней мере, в следующем выпуске программного продукта. Они очень помогают усовершенствовать программу, сделать ее более удобной и полезной. Стоит ли удалять из базы данных такую цен ную информацию? Приготовьтесь целые дни проводить в спорах о том, какая ошиб ка отражена в конкретном отчете — ошибка кодирования или проектирования. Особенно горячими эти споры будут в случае, если вы согласитесь включать в статистические отчеты о производитель ности программистов только ошибки кодирования. Приготовьтесь к резким нападкам не ваших подчиненных каждый раз, когда они сами будут допускать ошибки в отчетах или при тестировании. Вас будут просить удалять из базы данных все отчеты о невосп роизводимых ошибках. Бывает, что ни воспроизвести ситуацию, ни найти ее причину и в самом деле не удается даже после самого доб росовестного анализа кода опытным программистом. У некоррект ного или неожиданного поведения программы могут быть самые разные причины, и не всегда это ошибки в ее коде. Например, ошибку может допустить сам пользователь, проблема может быть вызвана аппаратным сбоем или скачком напряжения питания. И если программист не находит ошибки, отчет ухудшает статистичес кие показатели качества его работы. Как долго он должен искать описанную в отчете ошибку? 1 5 8 Часть II: Приемы и технологии тестирования • Не ждите, что программисты или руководитель проекта будут документировать ошибки, выявляемые ими в процессе разработки. • И однажды вам будет предъявлен судебный иск. Нередко люди, которых уволили с работы или которые сами уволились из-за ока зываемого на них давления, подают на своих бывших работодателей в суд. Если вы являетесь руководителем группы тестирования и на основе своей базы данных предоставляли руководству сведения о производительности работы сотрудника, который судится с вашей компанией, то обвинение может быть предъявлено и лично вам. Адвокаты будут беседовать с вами перед судебным заседанием гораз до более серьезно, чем если бы вы являлись простым свидетелем. Звучит смешно? Но кто будет платить в конечном счете? Если вы думаете, что компания, то глубоко ошибаетесь. Вероятно, вам будет позволено воспользоваться услугами штатного юриста. Но если он найдет способ помочь компании за ваш счет, как вы думаете, что будет тогда? Наверное, это зависит от компании и от юриста. Назначение базы данных — способствовать исправлению ошибок, а не собирать статистические сведения для руководства. Юристы Вся информация базы данных открыта для изучения юристами при любом судебном процессе, инициированном вашей компании или возбуж денном против нее. • Отчеты о проблемах, в комментариях которых тестировщик обвиня ет программиста в непрофессионализме, могут быть использованы против вас, даже если эти обвинения абсолютно справедливы. • В пользу компании может говорить тот факт, что информация базы данных подтверждает тщательность тестирования программного продукта и проведение обстоятельного анализа каждой выявляемой проблемы, учитывающего интересы пользователей. • Удаление информации из базы данных в целях сокрытия важных для судебного процесса сведений считается противозаконным. Реализация базовых функций системы отслеживания проблем Однажды вам придется проектировать собственную систему отслежива ния проблем либо настраивать или перерабатывать уже готовый программ- Глава 6: Система отслеживания проблем 159 ный комплекс. В этом разделе предполагается, что выбор структуры инфор мации и функций системы полностью зависит от вас. Ряд советов по ее реализации, которые приведены далее, основываются на нашем собствен ном опыте эксплуатации подобных систем. Разумеется, возможны и другие варианты решений, которые могут быть и удобными, и полезными, но данный вариант показался нам оптимальным. Документирование новых проблем Отчет о проблеме, приведенный на рис. 5.1 (глава 5), является стандар тной формой документирования выявляемых проблем. Все его поля были подробно описаны в главе 5. Мы рекомендуем разрешить составление от четов о проблемах всем сотрудникам компании. Одни из них, и прежде всего тестировщики, будут самостоятельно вводить свои отчеты в базу данных, другие же могут предоставлять отчеты в письменном виде, а вво дить их будут сотрудники вашей группы. При вводе отчета в базу данных система проверяет его информацию на допустимость. Неверные или неполные отчеты она отвергает. Поэтому, если кто-либо из сотрудников не знает, как правильно заполнить все поля формы, попросите его составить отчет на бумаге. Сотрудник группы тес тирования воспроизведет проблему, откорректирует отчет и введет его в компьютер. В однопользовательской системе, а также в некоторых многопользова тельских после ввода отчета в базу данных система распечатывает три его копии. Первую оставляет у себя составитель отчета. Вторая передается программисту, как правило, через его руководителя. Третья копия остает ся в архиве группы тестирования. (В случае возникновения проблем с электронными носителями информации вы будете счастливы, что сохрани ли твердую копию каждого отчета.) Еженедельные итоговые отчеты В конце каждой недели формируются итоговые отчеты. В работе с ними требуются аккуратность и последовательность: передавайте их всегда одним и тем же людям и делайте это регулярно, каждую неделю. Сводные отчеты о выявленных за неделю проблемах содержат информацию обо всех проблемах, обнаруженных за истекшую неделю. На рис. 6.1 по казан пример одного из таких отчетов, отсортированного по функциональ ным областям. На рис. 6.2 приведен отчет с теми же данными, но отсортированными по степеням важности проблем. Одни руководители предпочитают первый способ сортировки, а другие — второй, так как здесь лучше проявить гибкость и предоставить данные в той форме, которая кажется каждому из них наиболее удобной. 1 6 0 Часть II: Приемы и технологии тестирования Еженедельные отчеты о состоянии проекта (рис. 6.3) отражают текущее состояние разработки и изменения, произошедшие в нем за неделю. Этот отчет очень популярен и, безусловно, полезен, но приведенные в нем цифры обязательно следует сопровождать подробными комментариями о причинах необычных изменений показателей. Глава 6: Система отслеживания проблем 1 6 1 Конец цикла тестирования В конце каждого цикла тестирования печатается отчет Завершение цик ла тестирования (рис. 6.4). В течение одного цикла тестирования проводит ся полный набор тестов очередной рабочей версии программного продукта. Например, если тестируется программный продукт Calcdog 2.10, в одном из циклов тестируется версия Calcdog 2.10д, а в следующем цикле — Calcdog 2.10е. 1 6 2 Часть II: Приемы и технологии тестирования В отчете Завершение цикла тестирования суммируются данные о состо янии проекта. Он очень похож на еженедельные отчеты о состоянии про екта, но функции их различны. Еженедельные отчеты удобны тем, что формируются достаточно часто, но сравнивать их данные не имеет смыс ла: в течение цикла тестирования проверяются разные участки и функци ональные области программы, и итоговые данные за одну неделю могут сильно отличаться от данных за другую. А вот отчеты, составляемые по завер шении цикла, позволяют сравнить показатели, поскольку относятся к одному и тому же набору тестов. Решенные и нерешенные проблемы После внесения в программу изменений или принятия иного решения по отчету о проблеме он снова возвращается к вам. Изменения в программу вносятся не всегда. Одни отчеты откладываются, другие отвергаются вов се. Если на отчете стоит резолюция Исправлено, воспроизведите описан ную в нем ситуацию, чтобы убедиться, что это и в самом деле так. Если окажется, что проблема решена только частично, закройте отчет и составьте новый, в который включите ссылку на первый отчет. Если исправление вообще не работает, откройте отчет снова с корректным замечанием. Для каждой неисправленной ошибки (отчет о которой возвращен с резолюцией Не может быть исправлено, Соответствует проекту или Не согласен с предложением) необходимо решить, следует ли написать Да в поле Считать отложенным (см. главу 5, раздел "Структура отчета о пробле ме: Считать отложенным"). Копии возвращенных программистами отчетов о решенных проблемах следует передавать их составителям. Именно они эффективнее всего смо гут проверить результативность исправлений. Бывает, что отчеты о проблемах теряются или игнорируются. Поэтому периодически, примерно раз в две недели, имеет смысл распечатывать Сводный отчет о нерешенных проблемах (рис. 6.5). Этот отчет, составляемый в целях выявления затерявшихся документов, должен носить совершенно обыденный и беспристрастный характер. Никогда не высказывайте ника ких личностных оценок ни в нем, ни опираясь на его данные. Проблемы группируются по степеням важности без указания того, кто конкретно отвечает за их решение. На рис. 6.6 показана более персонифицированная модификация отче та о нерешенных проблемах. В ней указывается, какой конкретно сотруд ник или отдел отвечает за решение описанных в отчетах проблем. Не стоит распространять такие отчеты публично — лучше передавать их конкретным руководителям при личных встречах. 1 6 4 Часть II: Приемы и технологии тестирования Отложенные проблемы Если в вашей компании не проводятся регулярные совещания по пере смотру отложенных проблем, имеет смысл, по крайней мере, каждые две недели распространять среди сотрудников Сводный отчет об отложенных проблемах (см. рис. 6.7). В этом отчете перечисляются все проблемы, в отчетах о которых стоит резолюция Отложено, наложенная программистом или руководителем проекта. Эти отчеты сможет просмотреть высшее руко водство и в случае необходимости изменить решения, принятые по отдельным вопросам. Кроме того, все отложенные проблемы остаются перед глазами сотрудников, и иногда случается, что программист придумывает простое и быстрое решение проблемы, которая была отложена из-за трудоемкости или просто потому, что хорошего способа ее решения до сих пор никто не пред ложил. Если же совещания по пересмотру отложенных проблем проводятся в компании регулярно, сводные отчеты будут на них весьма полезны, толь ко стоит добавить в них еще поля Подробное описание проблемы и как ее воспроизвести и Комментарии. Можно поступить и иначе: распечатать отчет в том виде, в котором он приведен на рис. 6.7, а к нему приложить полные копии всех исходных отчетов. Сводные отчеты лучше раздать уча стникам совещания заранее, чтобы они могли подготовиться к их обсуж дению. |