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