Тестирование-книга. Ю. Н. Артеменко Научный редактор
 Скачать 6.27 Mb.
|
|
1. Система является средством отслеживания хода работ. Информа ция, которая традиционно имелась в распоряжении только у руко водства и нескольких программистов, становится доступной широкому кругу сотрудников самых разных уровней. Система пре доставляет своим пользователям объективную и независимую оцен ку хода выполнения работ и их соответствия графику. В любой момент можно просмотреть полный список задач, которые еще дол жны быть решены. Текущее состояние продукта и его качество все гда известны. И каждый может увидеть, как продвигаются работы и насколько быстро решаются поставленные задачи. 2. Система является средством организации взаимодействия между сотрудниками. В каждой компании так или иначе решается целый ряд организационных вопросов. Когда процесс их решения автома тизирован, многое становится проще: действия сотрудников стано вятся боле регламентированными и упорядоченными. Более того, система высвечивает некоторые внутренние проблемы компании, ра нее остававшиеся скрытыми. Хорошая система, особенно сетевая, Глава 6: Система отслеживания проблем 1 3 3 позволяет практически полностью отслеживать взаимодействие меж ду сотрудниками, участвующими в выявлении и исправлении недо статков программного продукта, чтобы вовремя решать спорные вопросы и принимать меры по оптимизации работ. В частности, с ее помощью можно зафиксировать случаи некорректного поведения от дельных сотрудников или групп, злоупотребления чужим рабочим временем, необоснованных претензий и т.п. При внедрении системы отслеживания проблем необходимо решить целый ряд организационных и политических вопросов, что уже само по себе достаточно полезно. Вот наиболее важные из них. • Кто имеет право составлять отчеты о проблемах? Кто решает, следует ли ввести представленный отчет в базу данных? Кто от вечает за отнесение отчета к конкретной категории и определение его приоритета? • Кто имеет право доступа к базе данных для просмотра ее инфор мации? Кто может обращаться к ней с запросами и получать итоговые и статистические данные? • Кто отвечает за формирование результирующих документов, со держащих качественные и статистические показатели? • Кто и почему имеет право задевать чье-либо самолюбие? • Кто имеет право на рабочее время других сотрудников и чье именно? Не требуют ли программисты слишком подробных отче тов о каждой ошибке? Не предоставляют ли тестировщики слиш ком мало информации, из-за чего программисты вынуждены тратить на поиск ошибок больше времени? • Какая степень расхождений в оценках качества продукта счита ется допустимой? • Кто имеет право делать заключение о качестве продукта? Могут ли одни сотрудники опротестовывать решения других и настаи вать на том, чтобы конкретная ошибка была исправлена? За кем остается окончательное решение? 3. Система отражает производительность работы каждого сотруд ника. Из базы данных нетрудно получить любую статистическую информацию, например, о количестве отчетов, сдаваемых тестиров- щиком за день, среднем количестве ошибок, допускаемых програм мистом в неделю, среднем времени задержки, допускаемой программистом до исправления ошибки и т.п. Руководители проек тов обычно очень любят подобные цифры. И они действительно могут быть полезны для анализа хода разработки и решения текущих 1 3 4 Часть II: Приемы и технологии тестирования проблем. Иногда они могут даже служить основанием для взысканий или увольнения сотрудника. Однако у данной функции системы есть серьезный побочный эффект, сильно ограничивающий ее примене ние: хорошие сотрудники могут воспринимать эту функцию систе мы как давящую, а плохие, наоборот, манипулировать ею, чтобы создать впечатление большей производительности. 4. Система может служить оружием для межгрупповых войн. Пред положим, что сотрудники, работающие над проектом X, выбивают ся из графика, а его руководитель не хочет этого признавать. В этом случае руководитель группы тестирования или другого проекта, свя занного с первым, может воспользоваться предоставляемой системой статистикой для доказательства того, что для завершения проекта X необходимо больше времени, людей и денег, чем запланировано. В данном случае информация системы используется по назначению. Однако возможна и иная ситуация, когда корпоративные политика ны манипулируют ею ради собственных интересов, доказывая, на пример, что ситуация хуже, чем есть на самом деле. Итак, главным преимуществом системы автоматизированного отслежи вания проблем является повышение эффективности взаимодействия со трудников, участвующих в их решении. Однако у этой системы могут быть и свои издержки, связанные прежде всего с психологическими и полити ческими вопросами. Сотрудники будут осторожнее документировать най денные ошибки и свои соображения по их поводу, опасаясь, что некоторая информация может быть использована против них. В этой книге будет подробно рассказано и о достоинствах, и о недостатках данной системы, чтобы вы смогли извлечь максимальную пользу из первых и минимизиро вать вторые. Основное назначение системы отслеживания проблем Система отслеживания проблем служит прежде всего для исправления максимально возможного числа ошибок. Все, что не служит достижению этой цели, является побочным эффектом. Проектируя систему отслеживания проблем, к ее функциям стоит отне стись очень внимательно. Некоторые из них, как, например, формирова ние итоговых отчетов для руководящего персонала, вполне согласуются с ее основной целью. Но каждую новую предлагаемую функцию следует Глава 6: Система отслеживания проблем 1 3 5 обязательно проанализировать на соответствие задачам системы, и, если она не способствует их решению, ее лучше отклонить. Задачи системы Для достижения основной цели системы отслеживания проблем необ ходимо следующее: 1. Каждый, кому следует знать о проблеме, должен узнавать о ней сразу же после составления отчета. 2. Ни одна из ошибок не должна остаться неисправленной просто по тому, что о ней забыли или потому что так решил программист. 3. Минимум ошибок должны оставаться неисправленными из-за про блем взаимодействия сотрудников. В этом списке не случайно так мало задач. Они, и только они являют ся ключевыми, и к добавлению дополнительных задач следует относиться крайне осторожно. Процесс отслеживания проблемы Определив основные цели и задачи системы отслеживания проблем, можно перейти к рассмотрению ее работы: отследить, что происходит с отчетами после их составления, и разобраться с основными трудностями и проблемами, возникающими на их пути. Проблема документируется С чего все начинается, рассказывалось в главе 5. Тестировщик обнару живает проблему, изучает ее и составляет ее подробное описание в форме отчета. Далее отчет должен быть введен в систему отслеживания проблем. В одних компаниях составители отчетов сами вводят их в базу данных. В других отчеты пишутся вручную, а в базу данных их вводит отдельный сотрудник. Бывает и так, что тестировщики вводят свои отчеты самостоя тельно, а другие сотрудники, например администраторы, сотрудники груп пы технической поддержки или группы маркетинга, сначала предоставляют свои отчеты ответственному сотруднику (тестировщику, системному анали тику или руководителю проекта), который решает, следует ли их вводить в систему. Система отслеживания проблем может быть как одно-, так и много пользовательской. Типичная однопользовательская система устанавливается на компьютере в отделе тестирования. Непосредственный доступ к ней имеют только тестировщики. Для остальных исходные и итоговые отчеты 1 3 6 Часть II: Приемы и технологии тестирования распечатываются одним из тестировщиков, который специально назначен для этой работы. В случае же с многопользовательской системой ситуация принципиально иная. База данных системы устанавливается на одном из компьютеров корпоративной сети. Непосредственный доступ к ней полу чают все тестировщики и руководители проекта и, как правило, также программисты и авторы технической документации. Сотрудники групп маркетинга и технической поддержки могут работать с системой не во всех компаниях, хотя, на наш взгляд, у них должно быть это право. Права доступа к системе различных сотрудников могут включать возможность вводить собственные отчеты, вводить данные в определенные поля отчетов, составленных другими сотрудниками, запрашивать сведения из базы дан ных и печатать итоговые отчеты. Отчет поступает руководителю проекта Как только отчет введен в базу данных, его копия должна поступить руководителю проекта. В многопользовательской системе это происходит автоматически — у руководителя проекта имеется непосредственный дос туп к базе данных, а значит, и к только что введенному отчету. В однопользовательской системе сотрудник группы тестирования периодичес ки передает руководителю проекта распечатанные копии отчетов. Как правило, руководитель определяет приоритеты проблем и переда ет отчеты программистам. Однако здесь возможны варианты. • В большинстве случаев руководитель проекта оценивает важность проблемы, добавляет собственные комментарии и передает отчет программисту. Отчет с наиболее низким приоритетом не рассматри вается программистом до тех пор, пока не будут исправлены боле важные недостатки программы. В некоторых компаниях программи сты все же просматривают такие низкоприоритетные отчеты, чтобы исправить описанные в них ошибки по ходу исправления более важных ошибок в той же части кода. Как правило, если определить, что ошибки относятся к одному фрагменту кода, их гораздо проще и быстрее исправить все вместе. Однако компании, в которых при- нята такая технология работы, обычно полагаются на правильную группировку отчетов тестировщиками или программистами, а это в некоторых случаях может и не сработать. • Руководитель проекта может попробовать воспроизвести проблему самостоятельно. В случае неудачи он возвращает отчет тестировщику на доработку. • Руководитель проекта может вернуть отчет тестировщику на дора ботку, и не пытаясь воспроизвести проблему. Например, он может запросить дополнительную информацию — данные о конфигурации Глава 6: Система отслеживания проблем 1 3 7 системы, дополнительные пояснения или тестовые файлы. Хорошая система отслеживания проблем позволяет руководителю проекта и программисту записать все свои вопросы в отдельных полях отчета, а тестировщику — внести в этот же отчет ответы. Таким образом, вся информация, касающаяся решения конкретной проблемы, хра нится в одном месте. Тестовые файлы обычно нельзя включить прямо в базу данных, но ничто не мешает включить в отчет ссыл ки на эти файлы. В организации работ по тестированию программного обеспечения важную роль играет достижение правильного баланса между коли чеством работы, выполняемой тестировщиком для доку ментирования проблемы, и количеством усилий, затрачиваемых программистом на ее воспроизведение. Иногда от тестировщиков требуют чересчур подробных отчетов и тестовых файлов для каждой, даже самой маленькой и очевидной ошибки. В других компаниях, наоборот, пытаются обойтись самыми краткими описаниями, и в результате программисты тратят массу времени на повторный поиск найденных тестировщиками ошибок и воссоздание тестовых данных, вместо того чтобы просто запросить дополнительные материалы. Какой баланс будет "правильным", однозначно ответить нельзя. Но ниже приводится ряд соображений по этому поводу. • Время тестировщика обычно дешевле, нем время программиста. Однако опытный в отладке программист по короткому, но хоро шо написанному отчету часто находит и исправляет ошибку го раздо быстрее, чем тестировщик собирает всю связанную с ней информацию. • В конце разработки важность быстрого и надежного исправле ния ошибок резко возрастает — чем быстрее проблемы будут решены, тем быстрее продукт выйдет в продажу. В этом случае важно, чтобы программисты получали от тестировщиков макси мум информации, сколько бы ни стоил труд последних. Кроме того, на завершающих стадиях проекта гораздо проще подключить к нему дополнительных тестировщиков, чем программистов. • Иногда у тестировщиков гораздо больший опыт отладки, нем у программистов, или они больше заинтересованы в обнаружении и исправлении ошибок. В подобных случаях основной упор мож но сделать на ресурсы группы тестировщиков, особенно если программисты упрямы и их нельзя заменить. Так бывает, когда контракт с программистом плохо составлен, и в нем не предус мотрено никаких поощрений и санкций, связанных с качеством его работы. Однако опытные тестировщики требуют, чтобы пере- 1 3 8 Часть II: Приемы и технологии тестирования распределение нагрузки в таком случае было выполнено офици ально и их группа была пополнена дополнительным персоналом. • Ни при каких обстоятельствах недопустимы намеренные потери чьего-либо времени. Тестировщик никогда не должен лениться включить в отчет дополнительную информацию или тестовые данные, если существует вероятность, что программисту они могут понадобиться. А программист или руководитель проекта, в свою очередь, не должны требовать от тестировщика дополни тельных исследований, которые не являются действительно необ ходимыми. • Наконец, руководитель проекта может вообще отвергнуть отчет или написать на нем резолюцию Соответствует проекту. Возможно так же, что он попросит тестировщика классифицировать отчет как Расхождение с документацией и передаст его авторам документации, чтобы они отразили в ней соответствующий вопрос (скорее всего, в разделе разрешения проблем). После того как дополнительная информация по отчету будет предостав лена, руководитель проекта решит его окончательную судьбу — направит программисту или отложит (с резолюцией Соответствует проекту, Не вос производится или по иным мотивам). Некоторые руководители проектов случайно или намеренно задерживают отдельные отчеты, не отвечая на них какое-то время, но хорошие итоговые отчеты системы отслеживания про блем немедленно выявляют такие вещи. Руководитель проекта передает отчет программисту Передавая отчет программисту, руководитель проекта ожидает от него исправления программы или некоторого исследования и пояснения того, почему описанная проблема не может быть решена. Ошибки, разумеется, обычно исправляются. Вместо исправления программист может запросить у тестировщика дополнительную информацию или ответить (иногда и вполне обоснованно), что ошибку невозможно воспроизвести, слишком сложно исправить, что описанная ситуация вообще не является ошибкой, что ни один нормальный пользователь программы с ней никогда не столкнется, что тестовый при мер составлен некорректно или проблема не стоит внимания по какой-либо иной причине. Некоторые программисты всячески избегают исправления ошибок. Бывает, что программист игнорирует отдельные отчеты, надеясь, что этого никто не заметит, пока уже не будет слишком поздно. Или же программист всячески усложняет жизнь тестировщику, надеясь, что тот сдастся и будет документировать меньше ошибок: спорит, требует допол нительных материалов, новых исследований, подтверждений, что в таком Глава 6: Система отслеживания проблем 1 3 9 виде программа действительно не устраивает пользователей. Или требует проверки того, что ошибка осталась и в следующей версии программы (хотя программист ее не исправлял, а просто надеется, вдруг она исчезла сама собой при исправлении других ошибок). Другой тактикой подобных недобросовестных программистов является так называемая песчаная буря: на профессиональном жаргоне, непонятном тестировщику, программист путанно объясняет, что внесение изменений в эту часть программного кода может подорвать основы всей системы и самым серьезным образом отра зиться на ее надежности. С подобным сопротивлением можно бороться. В частности, для этой цели может послужить поле отчета Комментарии. В него следует вносить каждый комментарий, объяснение, каждое возражение или предложение. В многопользовательской системе программист сам должен будет ввести в отчет все свои аргументы. В однопользовательской их нужно записать са мостоятельно. Тон этих записей должен быть абсолютно нейтральным, и в них точно должно быть отражено все сказанное. Хороший руководитель проекта обязательно просмотрит эти комментарии и сам примет необходи мые меры. На практике почти в каждом проекте тестировщики с определенного момента начинают чувствовать необоснованное сопротивление со стороны программистов. Часто они ошибаются. Подробные комментарии в каждом отчете о проблеме могут помочь руководителю проекта или группы тести рования разобраться в недоразумениях и ослабить напряженность, возник шую между тестировщиками и программистами. Когда проблема объявлена решенной Исправив ошибку, программист делает на отчете пометку Исправлено и, возможно, добавляет некоторые комментарии. Однако на этом работа с отчетом вовсе не заканчивается. Программист часто ошибается. Проблема может остаться нерешенной, или внесенные в программу изменения могут породить новые ошибки. Наш собственный опыт разработки коммерческо го программного обеспечения показывает, что 10% неудачных исправлений — это еще очень хороший показатель. Если программист работает с таким коэффициентом, значит, нам повезло, и он исключительно профессиона лен и внимателен. Если же 25% отчетов, помеченных программистом как исправленные, на самом деле не выдерживают проверки, мы, конечно, не в восторге, но и не считаем это чем-то из ряда вон выходящим. Как отме чалось в главе 3, при разработке крупных систем зафиксированы гораздо большие коэффициенты неудачных исправлений, вплоть до 80%. Повторное тестирование программы по отчету, возвращенному програм мистом с пометкой Исправлено, лучше всего проведет тот тестировщик, который составил данный отчет. Если же его составил кто-то, кто не вхо- 1 4 0 Часть II: Приемы и технологии тестирования дит в группу тестирования, стоит сначала воспроизвести проблему в исход ной версии программы, а потом уже тестировать исправленную версию. (Старайтесь работать так, чтобы три последние версии программы всегда были у вас под рукой, тогда вы в любой момент сможете сравнить поведе ние программы с тем, каким оно было до внесения исправлений.) Получив обратно отчет об исправленной ошибке, начните с повторения того теста, который описан в отчете. Вы будете немало удивлены, как часто даже эти исходные тесты не срабатывают. Если исходный тест программа пройдет успешно, попробуйте его вари ации. Обязательно прочтите все примечания программиста и другие име ющиеся в отчете комментарии. Какие части программы затрагивают внесенные изменения? Что они могли нарушить? Проведите несколько гестов на возможные побочные эффекты. Еще раз протестируйте исправ ленную часть программы. Где была одна ошибка, возможны и другие. Подумайте о возможности существования более глобальной проблемы, частью которой была та, что уже решена, и о том, какие еще проблемы могут быть с ней связаны. Тестировщики часто тратят на анализ и тести рование уже решенных проблем и исправленных ошибок гораздо меньше времени, чем они того заслуживают. Если программа не проходит первоначальный тест, напишите об этом в исходном отчете и исправьте его резолюцию с Исправлено на Рассмат ривается, после чего снова отошлите отчет руководителю проекта или программисту. Если же исходный тест программа прошла и "засыпалась" на связанной ошибке, лучше закрыть отчет, оставив на нем резолюцию Исправлено, и написать новый. Большинство руководителей проектов и программистов предпочитают именно такой способ работы. Отчеты получаются меньши ми и более простыми, чем те, в которых отслеживается целая цепочка исправлений связанных ошибок. Невоспроизводимые проблемы Если программист и руководитель проекта не могут воспроизвести описанную в отчете ошибку и не знают, в чем ее причина, они отмечают отчет как Не воспроизводится и возвращают его вам. В этом случае оста ется только попытаться все же воспроизвести ситуацию, прибегнув к так тике, описанной в главе 5. Если это удастся, внесите в отчет дополнительные комментарии. В случае необходимости можно даже лич но продемонстрировать ошибку программисту или руководителю проекта. Передайте им видеозаписи или тестовые файлы. Все, что будет приложе но к отчету, обязательно перечислите в соответствующем разделе. Если в текущей версии программы воспроизвести ошибку не удается, зато удается в предыдущей, лучше всего пометить отчет как Исправлено и Глава 6: Система отслеживания проблем 1 4 1 закрыть его. Как правило, это означает, что при последнем изменении соответствующего фрагмента кода ошибка была исправлена. Однако перед закрытием отчета всегда лучше уточнить у программиста, действительно ли было именно так. Обязательно впишите в план тестирования соответству ющую заметку и в нескольких последующих версиях программы проведи те повторные тесты, чтобы убедиться, что ошибки и в самом деле больше нет. Если ошибка не воспроизводится ни в одной из версий программы, оставьте отчет еще на некоторое время открытым — возможно, до следу ющего этапа разработки. При поступлении каждой новой версии проводите повторное тестирование: может быть, ошибку все же удастся обнаружить. И только если найти ее так и не удастся, закройте отчет окончательно. Отложенные отчеты и спорные вопросы Если на отчете стоит резолюция Отложено, это означает, что руково дитель признал существование ошибки, но решил не исправлять ее в дан ной версии программного продукта. В некоторых коллективах разработчиков используется и еще одна похожая формулировка — Не может быть исправлено, означающая, что исправление ошибки отложено на неопределенное время. В каждом программном продукте, даже сделанном со всей тщательностью и хорошо отлаженном, все равно остается некото рое количество подобных ошибок. В самом конце разработки, когда вре мени остается в обрез, риск побочных последствий, связанных с исправлением каждой ошибки, перевешивает необходимость исправления самых незначительных из них. То же самое касается и усовершенствования проекта — эта работа может всячески поощряться, но за несколько недель до завершения разработки ее необходимо прекратить. Вся ответственность за то, какие ошибки будут исправлены, а какие — нет, лежит на руково дителе проекта. Многие руководители объясняют сотрудникам, почему решение той или иной проблемы отложено, вписывая свои соображения в отчет в поле Комментарий. В случае, если у сотрудников появятся возражения, и осо бенно при разработке следующего выпуска программы, эти записи будут очень полезны. Приступая к работе над следующим выпуском продукта, необходимо прежде всего открыть все отложенные отчеты и повторно их проанализи ровать. К этому моменту после завершения предыдущего выпуска может пройти уже несколько лет, может смениться персонал. Для нового руково дителя все записи отложенных отчетов будут представлять большую цен ность, да и прежний за такое время вполне может забыть подробности и собственные мотивации. 142 Часть II: Приемы и технологии тестирования Если руководитель написал на отчете Соответствует проекту, значит, именно так программа и должна работать — описанная в отчете ситуация не является ошибкой. Если такая пометка сделана на отчете, классифици рованном вами как Ошибка проектирования, посмотрите, что руководитель написал в поле Комментарий. Необходимо убедиться, что руководитель понял: вы знаете, что работа программы соответствует проекту, однако, на ваш взгляд, в данном случае она неверно спроектирована. Если из коммен тариев это не очевидно, лучше спросить у самого руководителя. Некоторые руководители проекта боятся ответственности, связанной с откладыванием проблем. Они относятся к каждому отложенному отчету как к разрешению оставить в программе серьезный недостаток, и, вместо того чтобы написать на подобном отчете Отложено, пишут Соответствует про екту. Так они чувствуют себя спокойнее: хотя ошибка при этом никуда не девается, однако общая статистика разработки выглядит гораздо лучше. В ходе разработки проводятся специальные совещания для обсуждения отло женных отчетов. И разумеется, такие неправильно помеченные отчеты оказываются просто "спрятанными под сукно" — на совещания они не попадают. Конечно, бывают ситуации, когда руководитель проекта и тестировщик действительно расходятся во мнениях. Честен руководитель в своей оцен ке или нет, но во многих коллективах в таких случаях принято, чтобы тестировщики самостоятельно меняли резолюцию на спорном проекте на Отложено. Однако наш опыт показывает, что резолюцию руководителя проекта лучше оставить неизменной, а вот в поле Считать отложенным написать Да. В этом случае отчет благополучно попадет на совещание по отложенным проблемам. Когда начнется работа над следующим выпуском программного продукта, отчет можно будет открыть снова. Каждые несколько недель, а ближе к завершению проекта и чаще, ру ководитель группы тестирования собирает совещание для обсуждения от кладываемых проблем. На этом совещании рассматриваются все накопившиеся отчеты с резолюцией Отложено или значением Да в поле Считать отложенным. Лучше всего, если на этих совещаниях присутству ют менеджер по маркетингу, руководитель или представитель группы тех нической поддержки, руководитель или представитель группы документирования, руководитель проекта, ведущий тестировщик и, воз можно, их непосредственный начальник. На совещании принимается окончательное решение о судьбе каждой из отложенных проблем. Именно здесь представитель группы тестирования может высказать свое мнение о важности решения части обсуждаемых вопросов в текущем выпуске продукта. Для совещания следует подготовить копии всех отложенных отчетов (в полном объеме, а не только краткие описания проблем). Каждый приглашенный имеет право высказать соб- Глава 6: Система отслеживания проблем 1 4 3 ственное суждение. И если, несмотря на возражения тестировщиков или других сотрудников, принимается решение отложить определенный отчет, он окончательно считается закрытым. Только приступив к работе над сле дующей версией продукта, его можно будет снова открыть. Для успешного проведения работ подобные регулярные совещания исключительно важны. Прежде всего, если у тестировщиков и персонала группы технической поддержки не будет официальной возможности опро тестовывать принятые руководителем решения, они найдут для этого не формальные средства. Они могут демонстрировать ошибки, которые считают особенно важными, персоналу группы маркетинга, директорам, вице-президентам, президенту компании, газетчикам и т.д. В результате маленькая производственная проблема может превратиться в большую политическую. Если же позволить каждому заинтересованному сотрудни ку официально высказать свои аргументы, до политических баталий дело не дойдет. И когда участники совещания согласятся с решением руководи теля проекта отложить определенный отчет, это решение будет окончатель ным и больше вопросу не будет уделяться ни внимания, ни рабочего времени сотрудников. Для сравнения предположим, что единственное со вещание по отложенным проблемам проводится в самом конце разработ ки — за две недели до завершения тестирования. Если на нем будут пересмотрены решения более чем по двум-трем отчетам, то разработчики рискуют не уложиться в сроки. В результате участники совещания не бу дут иметь полной свободы выбора: им придется прежде всего учитывать оставшееся время, а от этого пострадает качество конечного продукта. Зная это, все заинтересованные лица будут стремиться поднять важные вопро сы задолго до официального совещания, а значит, снова производственные вопросы превратятся в политические. Поэтому безусловно, лучше всего решать все подобные проблемы на регулярной и официальной основе, т.е. с самого начала тестирования программного продукта проводить достаточ но частые совещания по откладываемым отчетам. Нерешенные проблемы Случается, что отдельные отчеты о проблемах теряются, их рассмотре ние намеренно откладывается, о них забывают или им назначают слишком низкий приоритет. До завершения разработки все они обязательно долж ны быть рассмотрены. Это очень важное правило, и, если ему не следовать, это породит безалаберность со всеми вытекающими последствиями. Чтобы гарантировать обязательное решение всех зафиксированных в системе проблем, можно регулярно формировать сводные отчеты с переч нем всех рассматривающихся отчетов о проблемах. Очень полезно перед началом каждого нового этапа разработки про сматривать эти сводные отчеты вместе с руководителем проекта, чтобы 1 4 4 Часть II: Приемы и технологии тестирования решить, какие из исправлений лучше внести до начала нового этапа. Таким образом можно не только гарантировать, что часть серьезных недостатков программы будет быстро исправлена, но и твердо, но ненавязчиво напом нить руководителю, что и менее важные проблемы все же обязательно должны быть решены. Кроме того, когда все открытые проблемы сведены вместе, руководитель может сделать некоторые выводы о работе отдельных сотрудников или несколько перераспределить между ними нагрузку. Отчеты о состоянии проекта Эти полезные отчеты показывают, сколько ошибок выявлено в ходе тестирования, какая их часть еще ожидает исправления, каково соотноше ние количества исправленных и отложенных ошибок, сколько ошибок выявили тестировщики и сколько — остальной персонал. В отчетах фикси руются как данные за неделю, так и общие итоги. Отчеты о состоянии проекта помогают руководству оценить эффектив- ность работы тестировщиков и программистов, текущее качество программ ного продукта, а также определить соотношение количества выявляемых и исправляемых ошибок, по которому можно составить предположения от носительно даты завершения разработки. Пользователи системы отслеживания проблем В предыдущем разделе рассказывалось о том, какой путь проходят ис ходные отчеты в системе отслеживания проблем: что с ними происходит, кто их читает и дополняет новой информацией, как они теряются и нахо дятся снова. Теперь на этот же процесс полезно посмотреть глазами сотруд- ; ников компании. Каковы их нужды и требования? И чем может им помочь автоматизированная система отслеживания проблем? Пользователями системы являются составители исходных отчетов, те кто их читает, вносит собственную информацию или получает итоговые сведения. Очевидно, что речь идет не только о тестировщиках, но и о целом ряде других сотрудников, участвующих в разработке и тестировании.; программного продукта. Поэтому система принадлежит не только группе тестирования — она принадлежит всей компании. Ведущий тестировщик Этот сотрудник руководит работами по тестированию программного продукта и отвечает за их качество и за документирование выявляемых проблем. Он анализирует все спорые отчеты, включая и те, которые воз вращены тестировщикам из-за невозможности воспроизвести ситуацию, Глава 6: Система отслеживания проблем 1 4 5 или запросом дополнительной информации. Ведущий тестировщик про сматривает все отчеты с резолюциями Отложено и Соответствует проекту и решает, какие из них следует повторно обсудить на соответствующем совещании. Он готовит и передает руководству итоговые отчеты, а также просматривает их сам, чтобы вовремя выявлять возникающие проблемы. Из отчетов он узнает о неэффективном взаимодействии сотрудников, низ кой производительности работы отдельных тестировщиков (недостаточном количестве предоставляемых ими отчетов или, наоборот, слишком большом количестве отчетов о пустяках), а также о разногласиях или проблемах, связанных с исправлением ошибок, которые стоит обсудить с руководите лем проекта в личной беседе. Рядовые тестировщики Рядовые тестировщики составляют отчеты о проблемах и просматрива ют их после того, как эти проблемы решаются. Они повторно тестируют программу, проверяя качество исправлений. Отчеты, которые отложены или отвергнуты с резолюцией Соответствует проекту, они анализируют повторно и в отдельных случаях составляют новые отчеты с более убеди тельными описаниями проблем. Руководитель проекта Руководитель проекта отвечает за качество продукта и своевременное завершение его разработки. Его задача — поддерживать оптимальное соот ношение межу стоимостью работ, их производительностью, надежностью продукта, его возможностями и сроками разработки, подключая при необ ходимости дополнительные ресурсы или перераспределяя имеющиеся. В этой работе база данных системы отслеживания проблем становится ис ключительно важным источником информации о текущем состоянии про дукта и его соответствии календарному плану. Руководитель проекта определяет, какие из выявленных проблем дол жны быть решены и в каком порядке. Ряд вопросов он откладывает, и они могут быть повторно рассмотрены на соответствующем совещании. Многие руководители каждую неделю просматривают все открытые отчеты, выявляя проблемы взаимодействия сотрудников (в том числе свя занные и с межличностными отношениями), большие группы ошибок, сигнализирующие о слабости отдельных фрагментов программного кода, ошибки, плохо поддающиеся исправлению или повторяемые регулярно. Если программист или группа программистов постоянно повторяет одни и те же ошибки, возможно, следует обратить на это их внимание и принять Дополнительные меры. Если ошибки связанны с недостаточными знания ми или опытом в определенном вопросе, то можно провести консультации или найти необходимую литературу; возможно также, что программистам 1 4 6 Часть II: Приемы и технологии тестирования требуются дополнительные средства отладки или не хватает каких-либо ресурсов. Одной из основных задач руководителя проекта является имен но выяснение и удовлетворение потребностей персонала в технической помощи. Информацию об этих потребностях он получает, в частности, и при анализе отчетов о проблемах и имеющихся в них комментариев. Серьезное недовольство руководителя могут вызвать следующие обсто ятельства. • Отсутствие оперативных ответов. Это ситуация, когда руководи тель возвращает тестировщикам отчет о проблеме, которую не мо жет воспроизвести или по которой требуется дополнительная информация, и этот отчет остается без ответа. Будет описанная в отчете проблема решена или нет, но в любом случае важно опреде литься. Если такие нерешенные вопросы накапливаются, это нару шает нормальный процесс разработки и ставит под угрозу ее календарный план, поскольку блокирует возможность правильного принятия решений о том, сколько еще исправлений необходимо внести в программу до завершения очередного этапа. • Внесенные в программу исправления не тестируются по нескольку дней или даже недель. В такой ситуации состояние программного продукта становится неопределенным. Если исправление не проте стировано, то неизвестно, исправлена ли ошибка на самом деле и не появились ли в программе новые ошибки. О плохих новостях руко водителю проекта необходимо узнавать сразу же, чтобы своевремен но принимать соответствующие меры. • Одна и та же отложенная проблема рассматривается по нескольку раз. Добавив очередной неубедительный аргумент в пользу решения проблемы, тестировщик снова изменяет резолюцию отложенного отчета на Рассматривается. Как правило, руководители проекта поощряют повторное рассмотрение отложенных отчетов, но только при условии, если новые аргументы и материалы, приведенные те- стировщиками, действительно заслуживают внимания. И без очень весомых причин этого не следует делать более одного раза. • База данных изобилует дублирующими друг друга и не заслуживаю щими внимания отчетами. Особенно серьезной эта проблема ста новится в конце разработки или когда похоже, что это делается намеренно для завышения показателей продуктивности работы от дельных тестировщиков или необоснованной демонстрации того, что программа все еще полна ошибок. Кроме того, большое количество отчетов о недостатках исходного проекта, даже если они абсолютно объективны, может оказывать обескураживающее психологическое воздействие. Впрочем, хороший руководитель поощряет такие отче- Глава 6: Система отслеживания проблем 1 4 7 ты даже в конце разработки, когда никакие изменения пользователь ского интерфейса и функциональной структуры программы уже не допускаются — ведь со временем выйдет и следующий выпуск про дукта, в который можно будет внести все полезные изменения, предложенные в ходе тестирования. Только не переусердствуйте с такими предложениями, они должны строго соответствовать общей концепции программного продукта. • В итоговых отчетах с перечнем неисправленных ошибок имеются ошибки, которые уже исправлены, но еще не протестированы, или ошибки, которые вообще не воспроизводятся. В результате создается неверная картина выполнения работ — производительность програм мистов представляется меньшей, чем на самом деле, а состояние программы — худшим. • В итоговых отчетах неверно интерпретируются текущие данные. Например, если в конце разработки за определенный период ис правлено 40 ошибок и выявлено 40 новых, из которых 35 являются незначительными недостатками проектирования, а в итоговом отчете сказано, что большинство исправлений влечет за собой новые ошиб ки, это неверно. На самом деле ошибки исправляются прекрасно, и работы успешно продвигаются. Все дело просто в некорректности составления отчета — достаточно типичном явлении в ситуациях, когда количество обнаруживаемых ошибок примерно равно или даже превышает количество исправлений. • Высшему руководству регулярно передаются упрощенные итоговые отчеты, особенно те, в которых отражается количество ошибок, оставшихся неисправленными в конце каждой недели. Как будет рассказано далее, руководители часто очень любят подобные "пока зательные" отчеты, а их подчиненным (в данном случае руководи телям проекта) они приносят только лишние неудобства и заставляют предпринимать действия, благодаря которым цифры выглядят лучше, а эффективность процесса документирования и исправления ошибок страдает, что в конечном счете отражается на качестве продукта. • Информация базы данных используется для личных нападок на ру ководителя проекта или других сотрудников или для искаженного представления проекта и его прогресса. Программист Программист читает отчет о проблеме и отвечает на него. Его недоволь ство могут вызвать следующие обстоятельства: 1 4 8 Часть II: Приемы и технологии тестирования • Отчет не совсем четкий и понятный, он недостаточно способствует исправлению ошибки. • Из отчета неясно, против чего возражает тестировщик или что дол жен сделать программист. Бывает, что отчет больше похож на абст рактное описание поведения программы. Прочитавший его человек может остаться озадаченным: "Ну хорошо, а в чем же, собственно, проблема?" • Описанная в отчете ситуация не воспроизводится. • Отчет, возвращенный с запросом о дополнительной информации, снова поступает программисту в исходном виде. • Тестовый пример очень сложен, а тестировщик не приложил к от чету вспомогательные материалы для его воспроизведения. • Формулировки отчета могут быть восприняты как персональная критика. • Руководство использует статистические данные системы отслежива ния проблем для анализа личной производительности сотрудников. Менеджер по маркетингу Менеджера по маркетингу интересует все, что связано с конкурентос пособностью будущего программного продукта и стоимостью его техничес кой поддержки. Поэтому менеджеры по маркетингу продукта часто являются самыми активными защитниками его качества. В некоторых слу чаях они считают более важным уложиться в сроки разработки, но и тог да отказываются выпустить на рынок продукт с коммерчески неприемлемыми недостатками. Как правило, менеджер по маркетингу слишком занят, чтобы читать отчеты обо всех отложенных проблемах, он не хочет или не может эффек тивно пользоваться базой данных. Поэтому стоит распечатывать для него персональные итоговые отчеты и выделять в них наиболее важные пробле мы. Группа технической поддержки Сотрудники группы технической поддержки будут отвечать на вопросы пользователей продукта. Они заинтересованы в том, чтобы снизить сто имость поддержки продукта и правильно отразить в технических обзорах его качество. Поэтому сотрудники этой группы возражают против каждой отложенной ошибки — ведь им предстоит отвечать за нее перед пользова телями. Они настаивают на исправлении всех ошибок, решении всех про блем, исправлении всех недостатков исходного проекта и всех неточностей документации. И если исправление не вносится, они должны знать, что Глава 6: Система отслеживания проблем 1 4 9 отвечать пользователям. Незадолго до выпуска, когда программа уже дос таточно стабильна, группа технической поддержки обычно просматривает ее вместе с руководством и составляет ряд собственных отчетов о пробле мах. В этих отчетах отражаются вопросы, которые вызовут наибольшее количество звонков недовольных или не сумевших разобраться в программе пользователей. Вообще, звонки пользователей — это один из наиболее точных и важных индикаторов качества программы. Кроме того, они об ходятся компаниям в значительные суммы. Поэтому, если группа техничес кой поддержки сильно обеспокоена некоторыми недостатками продукта, лучше всего немного отложить его выпуск или начать работу над следую щей, исправленной версией сразу после выхода текущей. Сотрудники группы технической поддержки очень часто посещают совещания по пересмотру отложенных проблем и настаивают на решении тех из них, которые вызовут наибольшее количество звонков пользовате лей. Во многих компаниях к их мнению прислушиваются гораздо внима тельнее, чем к доводам остальных сотрудников, включая и тестировщиков. Часто группа технической поддержки требует предоставления ей отче тов обо всех отложенных проблемах с объяснениями того, что следует говорить недовольным пользователям. Поскольку на внесение в отчеты этой информации требуется время, а программисты и так загружены до предела, эту работу часто поручают тестировщикам. Однако не все компа нии выбирают такую стратегию. В некоторых вместо этого принято вклю чать в руководство пользователя большие разделы о разрешении возможных проблем. Каждое выдаваемое программой сообщение об ошибке подробно описывается, и приводятся инструкции, как избежать подобных ошибок. Перед печатью очередного тиража документации, в нее вносится информа ция обо всех обнаруженных ошибках и ответы на наиболее часто задава емые пользователями вопросы. Кроме того, существует практика, когда персонал технической поддержки руководит бета-тестированием продукта (предпродажной стадией тестирования с участием пользователей), изучает его результаты и готовит материалы, которые будут использоваться для под держки пользователей после выпуска продукта. Сотрудники группы технической поддержки пользуются базой данных отслеживания проблем и после выпуска продукта. Когда пользователи со общают о новой ошибке, о ней составляется отчет и вносится в базу дан ных. Затем сотрудники группы сообщают об ошибке руководству и выясняют, когда и кем она будет исправлена. При этом желательно исправить ошибку как можно быстрее — пользователь, как известно, ждать не любит. Авторы технической документации Авторы технической документации (технические писатели) отвечают за руководство пользователя, другие технические материалы, сопровождающие 1 5 0 Часть II: Приемы и технологии тестирования программный продукт, а также за самостоятельную техническую и марке тинговую документацию. Они должны отслеживать все изменения исход ного проекта и знать обо всех отложенных ошибках, влияющих на поведение программы. Поэтому они тоже пользуются системой отслежива ния проблем, причем делают это и после окончательного выпуска продукта. Кроме самого продукта, технических писателей интересует и то, как про двигается работа и укладываются ли разработчики в график — от этого зависит, следует ли техническому писателю поторопиться или, наоборот, подождать, пока определенная часть продукта будет завершена и можно будет приступить к ее описанию. Особенно им важно знать, когда будут прекращены изменения пользовательского интерфейса. При написании документации ее авторы нередко сталкиваются с ошиб ками программы. Как и тестировщики, они могут составлять отчеты об обнаруженных проблемах и вводить их в базу данных. i Тестировщики, в свою очередь, периодически выявляют ошибки в до кументации. Часто они пишут свои замечания прямо на копии документа ции, но, если расхождение между ней и программой достаточно серьезно, и особенно когда документация соответствует спецификации, обязательно составляется отдельный отчет о проблеме. И если затем в программу вно сятся изменения, они обязательно должны быть отражены в документации. Отчеты о некорректном поведении программы передаются техническому писателю и в том случае, когда ошибка не исправляется — для внесения со ответствующей информации в раздел разрешения проблем. Можно сказать, что работа автора документации во многом сходна с работой программи ста: он получает отчет о проблеме, вносит исправления в документацию, пишет на отчете резолюцию Исправлено и возвращает его для повторного тестирования. Руководитель группы тестирования Руководитель группы тестирования отвечает за административную часть i организации работ по тестированию и их качество. Анализируя отчеты, составляемые каждым сотрудником, он определяет, не требуется ли этому тестировщику пройти дополнительное профессиональное обучение. Кроме того, он согласовывает работу группы тестирования с работой других под разделений, отвечает за их взаимодействие и решает ряд других админис тративных вопросов. Некоторые руководители групп тестирования поддаются искушению собирать предоставляемую системой статистическую информацию работы отдельных тестировщиков. Сколько, например, каждый тестировщик доку- . ментирует ошибок за неделю? Такая статистика помогает отслеживать тен денций в работе группы, но, прежде чем делать на ее основании выводы об эффективности работы сотрудников, следует ответить на следующие воп росы: Глава 6: Система отслеживания проблем 1 5 1 • Кто документирует больше ошибок: тестировщики, технические писатели, группа технической поддержки или руководитель проек та? Обычно больше всего ошибок находят тестировщики, однако многие проблемы выявляет и руководитель проекта или его помощ ник. Помощник руководителя проекта тестирует продукт независи мо и не так, как это делают тестировщики: он пытается работать с программой как обычный пользователь, ориентируясь не на поиск ошибок по строго заданной схеме, а скорее, на недостатки общего функционирования. Если такая работа выполняется в течение не скольких недель, она может принести определенную пользу, но если она длится до самого конца разработки, то фактически дублирует работу группы тестирования. Однако, если оказывается, что подоб ный сотрудник работает эффективнее профессиональных тестиров щиков, имеет смысл пересмотреть выбранную стратегию тестирования — похоже, что она неэффективна. • Действительно ли количество выявленных за неделю проблем отра жает производительность работы тестировщика? В самом нача ле тестирования обычно обнаруживается очень много ошибок. Следующий подъем этого показателя наблюдается по окончании первого этапа разработки, поскольку код к этому времени еще очень нестабилен. Далее все зависит от конкретного проекта. Если продукт нестабилен, периоды с очень высокими показателями обнаруженных ошибок могут чередоваться с неделями затишья, когда составляется пять-шесть отчетов за неделю. На других проектах вначале наблю дается увеличение количества обнаруживаемых ошибок, по мере того как тестировщики знакомятся с продуктом, а затем постепен ный спад, отражающий стабилизацию программы. Таким образом, невозможно составить универсальную схему — развитие событий может быть очень различным, и зависит оно от множества обстоя тельств. Пожалуй, единственное, на что стоит обратить пристальное внимание, — это постоянное и не слишком большое количество отчетов у какого-либо тестировщика. Так бывает, если человек по стоянно меняет область тестирования: ставит одну задачу, посвящает ей несколько дней, составляя по нескольку отчетов за день, затем переключается на другую задачу. Дополнительным показателем не добросовестности может служить то, что в отчетах этого сотрудни ка описываются большей частью самые очевидные недостатки проектирования и наиболее легко выявляемые ошибки. Кроме того, стабильные показатели могут быть у тестировщиков, работающих по плохо составленному плану. 1 5 2 Часть II: Приемы и технологии тестирования Наш собственный опыт показывает, что в оценке производительности работы тестировщиков не стоит полагаться на простые данные о количестве составляемых ими отчетов, а следует внимательнейшим образом изучить сами отчеты. Например, некоторые тестировщики исследуют программу тщательнее других, больше времени тратят на попытки воспроизвести труд ноуловимые ошибки или работают с более сложными частями программы. Не удивительно, что они выявляют меньше ошибок, чем их коллеги, одна ко та часть программы, с которой они поработали, в результате гораздо более надежна, чем у других. Таких сотрудников мы называем старшими тестировщиками и уж никак не считаем их работу наименее производи тельной. Мы всегда резко возражаем против любых ссылок на количество выяв ляемых тестировщиком ошибок, в личной ли беседе или публичных заяв лениях. Некоторые люди реагируют на такие упоминания очень болезненно, у них возникает чувство, что руководитель намеренно внима тельно отслеживает именно их производительность, хотя на деле это может быть и совсем не так. Тем более недопустимо явно интерпретировать по добные данные как показатели производительности — это наверняка будет воспринято как несправедливая оценка работы и вызовет бурю эмоций. После таких высказываний руководства рядовые сотрудники немедленно начнут корректировать свои действия, пытаясь подогнать показатели под желаемые. Ведь они теперь будут полагать, что руководство отслеживает их производительность, оценивая ее по количеству составляемых отчетов. А чтобы подогнать показатели, им придется работать менее добросовестно: составлять отчеты только о легко выявляемых ошибках и не тратить мно го времени на тщательное исследование тестируемой области программы. Некоторые из сотрудников заходят еще дальше, заполняя базу данных отчетами о совершенно незначительных, не стоящих внимания недостатках программы или отчетами с чуть различающимися описаниями одних и тех же проблем. Иногда мы просматриваем статистику выявления ошибок, но делаем это не каждую неделю и не афишируем результаты. Вместо этого, если какие- либо показатели привлекают наше внимание, мы тщательно изучаем соот ветствующие отчеты и, если проблема действительно имеется, принимаем меры. Высшее руководство Руководители высшего уровня не занимаются отдельными ошибками, если только речь не идет об исключительно серьезных проблемах, решение которых приходится отложить. О таких проблемах они могут узнать от ведущего тестировщика, руководителя группы тестирования, руководителя проекта, а также от любого сотрудника, посчитавшего, что к определенной |