В учебных программах по дисциплине "Обеспечение качества и тестирование программ" есть вопросы: "Описание дефекта (Bug Report). Составление отчетов о проблеме" и "Правила составления отчета об ошибке, формальные требования и частые проблемы".

В программе обучения базового уровня International Software Testing Qualifications Board "Сертифицированный тестировщик" указано на необходимость помнить содержание отчета об инцидентах согласно «Стандарту по Тестовой Документации для Программного Обеспечения» (IEEE Std- 829-1998) и уметь написать отчет об инцидентах, описывающий наблюдения за отказами во время тестирования.

«Тестирование программного обеспечения. Фундаментальные концепции менеджмента бизнес-приложений», Сэм Канер, Джек Фолк и Енг Кек Нгуен, Москва, ДиаСофт, 2001. 102- страницы:

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

Целью составления отчета об ошибке является ее исправление.

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

• Объясните, как воспроизвести ошибку или проблемную ситуацию. Программисты игнорируют отчеты об ошибках, которых не могут увидеть своими глазами.
• Тщательно проанализируйте ошибку, чтобы описать ее предельно кратко. Слишком пространное описание проблемы затрудняет понимание ее сути. Кроме того, встретив длинный отчет, программист подумает, что речь идет о чем-то сложном, и с большой вероятностью отложит его рассмотрение.
• Составьте полный, понятный и непротиворечивый отчет. Если отчет путает программиста или недостаточно отчетливо и ясно со­ ставлен, он едва ли послужит хорошей мотивацией для устранения ошибки.

Отчет следует составлять немедленно

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

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

Структура отчет о проблеме

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

Программа

Если тестируемый программный продукт состоит из нескольких про­ грамм или же компания разрабатывает несколько программных продуктов одновременно, следует обязательно указать, в какой именно программе обнаружена ошибка.

Выпуск и версия

В отчете обязательно должно быть указано, к какой именно версии программного кода он относится. Например, идентификатор версии может быть таким: 1.01д. Он означает, что речь идет о пятой (д) черновой версии выпуска программы номер 1.01.

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

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

Тип отчета

В графе "Тип отчета" указывается тип обнаруженной проблемы.

1. Ошибка кодирования. Программа ведет себя не так, как должна по мнению тестировщика. Например, если программа утверждает, что 2 + 2 = 3, то это явная ошибка кодирования. Программист же в от­ вет на отчет о такой ошибке вполне может написать Соответствует проекту.
2. Ошибка проектирования. Программа соответствует проектной доку­ ментации, но в определенном вопросе тестировщик с этой докумен­ тацией не согласен. Так особенно часто случается с элементами пользовательского интерфейса. На отчете данного типа программист не может написать Соответствует проекту, и если он считает, что проект верен, тогда он пишет Не согласен с предложением.
3. Предложение. Отчет такого типа не означает, что в программе что- то не так. В нем описывается идея, реализация которой, по мнению тестировщика, может улучшить программу.
4. Расхождение с документацией. Программа ведет себя не так, как описано в руководстве или интерактивной справке. В этом случае в отчете следует указать, в каком именно документе и на какой стра­ нице найдено несоответствие. При этом в отчете вовсе не утвержда­ ется, что ошибка именно в документации, а не в самой программе. Отчеты о расхождении с документацией обязательно должны совме­ стно рассматриваться программистом и автором документа­ ции. О функциях программы, которые вообще нигде не описаны, также следует составлять отчеты данного типа.
5. Взаимодействие с аппаратурой. Проблемы этого рода связаны с не­ удачным взаимодействием программы и определенного вида аппа­ ратного обеспечения. Если причина неудачи заключается в неисправности устройства, отчет о ней составлять не нужно. Одна­ ко если программа не может работать ни с одной платой или устрой­ ством конкретного типа — это уже проблема, которую следует документировать.
6. Вопрос. Программа делает что-то, чего тестировщик не ожидает или не понимает. Отчет-вопрос стоит составить при любых сомнениях. Если они окажутся основанными на действительной ошибке, про­ граммист ее исправит. Если же программист откажется исправить ошибку или его объяснение не покажется вам достаточно разумным, можно будет составить отчет об ошибке проектирования.

Степень важности

В этой графе тестировщик указывает, насколько, по его мнению, серьезна выявленная проблема.

К сожалению, для определения степени важности проблемы не существует строгого критерия. Бейзер (Beizer, 1984, с. 20), например, предлагает шкалу от 1 (незначительная ошибка, например грамматическая) до 10 (фатальная, вызывающая сбои в других системах, войны, убийства и т.д.). Такой взгляд на вещи свойствен многим программистам. Но на деле имен­ но такие субъективные характеристики влияют на впечатление пользовате­ ля о программе. А во сколько, по-вашему, обойдется раздражение пользователей, выраженное в появившихся в прессе обзорах? Можно ска­зать только одно — у каждой конкретной компании могут быть свои критерии важности ошибок.

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

Приложения

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

Проблема

В этой графе суть проблемы формулируется очень коротко — в одной-двух строчках. Но при этом описание должно быть и достаточно информа­ тивным, чтобы прочитавший его сотрудник смог сразу составить себе четкое представление о проблеме. Именно по нему он будет искать нуж­ ный отчет, если захочет возвратиться к нему повторно. Кроме того, следует иметь в виду, что в сводных перечнях ошибок, как правило, будут присут­ ствовать всего несколько полей: "Номер отчета", "Степень важности", возмож­но "Тип отчета" и "Проблема".

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

Даже если две проблемы очень похожи, в отчетах их краткие описания ни в коем случае не должны совпадать.

В графе "Проблема" не следует рассказывать, как воспроизвести ошибку. Примером хорошего описания может быть такая строчка: "Сбой програм­ мы при попытке сохранения файла под недопустимым именем".

Можете ли вы воспроизвести проблемную ситуацию?

Ответом может быть "Да", "Нет" или "Не всегда". Если с повторением ситу­ ации возникли сложности, лучше отложить составление отчета до тех пор, пока дело не прояснится: либо вы убедитесь, что не знаете, как ее воспро­ извести (и напишете "Нет"), либо поймете, что она носит нерегулярный характер (и напишете "Не всегда"). В последнем случае описать способ вос­ произведения ситуации нужно особенно тщательно, указав, при каких обстоятельствах ошибка проявляется, а при каких — нет. Следует помнить, что, если написать в отчете "Да" или "Не всегда", программист может попро­сить продемонстрировать описанную ситуацию, и если вы не сможете этого сделать, то зря потратите его время и потеряете доверие. С другой сторо­ны, отчет о проблеме, которую невозможно воспроизвести, программистс. большой вероятностью просто отложит, пока не появятся дополнительные отчеты.

Подробное описание проблемы и как ее воспроизвести

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

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

Составляя данное описание, тестировщик часто обнаруживает, что не знает точно, при каких условиях проявляется ошибка. Лучше увидеть это сразу и потестировать программу еще немного, чем давать программисту повод усомниться в вашей аккуратности.

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

Предлагаемое исправление

Эта графа отчета не является обязательной. Если решение проблемы очевидно или, наоборот, у вас нет конкретного предложения, оставьте ее пустой.

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

Отчет представлен сотрудником

Обязательно укажите здесь свою фамилию. Если у программиста воз­ никнут вопросы, он должен знать, к кому обратиться. А анонимные отче­ ты часто вообще игнорируются.

Дата

В этой графе следует указать дату обнаружения проблемы. Это не дата написания отчета и не дата ввода его в компьютер. Поскольку программи­ сты не всегда меняют номер версии программы после внесения в нее оче­ редных изменений (иногда просто забывая это сделать), указанная в отчете дата поможет идентифицировать версию программы, к которой он относится.

Примечание. Следующие графы отчета предназначены только для команды разработчиков. Внештатные составители отчетов, такие как бета-тестировщики и просто пользователи, не должны их заполнять.

Функциональная область

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

«Ключевые процессы тестирования. Планирование, подготовка, проведение, совершенствование», Рекс Блэк, Москва, Лори, 2006. 396-427 страницы:

Отчет об ошибке (Bug Report). Технический документ, описывающий симптомы для 1) информирования о влиянии и обстоятельствах возникновения проблемы; 2) назначения ошибке приоритета для исправления; 3) помощи программисту в локализации дефекта и его исправления.

«Сертифицированный тестировщик Программа обучения Базового уровня». Версия 2011 (от 13 апреля 2011 года), International Software Testing Qualifications Board, Андрей Конушин (председатель), Александр Александров, Алексей Александров, Татьяна Смехнова, Елена Абрамова. 29-34/101 страница:

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

Инциденты могут быть обнаружены во время разработки, рецензирования, тестирования или использования ПО. Они могут быть найдены в коде, работающей системе, документации любого типа, включая требования, документы разработки, тестовые документы и документы для пользователей, например «Справка» или руководство по установке.

Цели отчета по инцидентам:

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

Отчета об инцидентах может содержать:

• Дату нахождения, нашедшую организацию и автора инцидента;
• Ожидаемый и фактический результат;
• Идентификатор тестового (конфигурационного) элемента и окружение;
• Жизненный цикл ПО или системы, в котором был обнаружен инцидент;
• Описание, необходимое для воспроизведения и решения инцидента, включая логи, дампы базы или снимки экрана;
• Уровень влияния на заинтересованные стороны;
• Серьезность влияния на систему;
• Срочность\приоритет для исправления;
• Статус инцидента (например, открыт, отложен, копия, ожидает исправления, ожидает подтверждающего тестирования, закрыт);
• Заключение, рекомендации и подтверждение;
• Общие проблемы, например, другие области, которые могут быть затронуты при решении инцидента;
• История изменений, например, последовательность действий, принятых членами команды проекта для изолирования, исправления и подтверждения исправления инцидента;
• Ссылки, включая идентификатор на спецификацию тестового сценария, который выявил проблему.

Структура отчета об инцидентах также описана в «Стандарте по тестовой Документации для Программного Обеспечения» (IEEE Std 829-1998).

Рекомендуемая литература - : Practical Tools and Techniques for Managing Hardware and Software Testing, (третье издание), R. Black, 2009 год, John Wiley & Sons: New York.

Резюмируя

В этой заметке поделюсь чек-листом по которому готовлю отчеты о недостатках программных продуктов. Пункт чек-листа не равнозначен пункту отчета. Пункт отчета о дефекте может состоять из одного или нескольких элементов приведенного чек-листа. Пункты чек-листа являются обстоятельствами, ключевыми точками на которых следует сосредоточить свое внимание. Чек-лист сформирован на основе материалов из книг Канера, Фолка и Нгуена, Романа Савина, Программы обучения Базового уровня ISTQB "Сертифицированный тестировщик".

1. Предварительный шаг - проверить наличие ранее созданного отчета о недостатке, записей об истории исправления аналогичной или подобной аномалии, запроса или требований о новом функционале программы. Ожидаемый результат:
   • Текст ошибки не упоминается в официальной справочной системе программы в разделе о наиболее частых ошибок.
   • Результаты поиска в Redmine или Jira по тексту ошибки не содержат уже созданных задач по недостатку.
   • Если задачи с упоминанием текста ошибки есть, то они касаются других модулей программы.
2. Название отчета из краткого описания недостатка.
   • Название прошло проверку в веб-сервисе Багред и получило заключение «Поздравляем, это крутое название!».
3. Название программы или функциональной области обязательно указывать в случае, «если тестируемый программный продукт состоит из нескольких программ или же компания разрабатывает несколько программных продуктов одновременно» (Канер, Фолк и Нгуен «Тестирование программного обеспечения»).
   • Главная страница, "шапка" сайта.
4. Версия программы или ветка веб-сервиса, поскольку "программа все время находится в процессе усовершенствования, программист может не найти ошибку в ее текущей версии. В этом случае он посмотрит, с какой версией работал тестировщик, и обратиться к ней, чтобы все-таки воспроизвести ошибку и гарантировать, что она исправлена" (Канер, Фолк и Нгуен «Тестирование программного обеспечения»).
5. Дата и время обнаружения недостатка. Канер, Фолк и Нгуен: "Это не дата написания отчета и не дата ввода его в компьютер. Поскольку программисты не всегда меняют версии программы после внесения в нее очередных изменений (иногда просто забывая это сделать), указанная в отчете дата поможет идентифицировать версию программы, к которой он относится".
   • 19 февраля 2017 года в 21:05:50.
6. Среда воспроизведения. Тестовая, предрелизная или боевая.
7. Серьезность Степень влияния на систему - "степень воздействия бага (magnitude of impact) на программное обеспечение, исходя из принадлежности к определенной технической категории", Роман Савин. Влияние на работоспособность тестируемой системы, ее ключевых функций с точек зрения бизнес логики, безопасности, времени воздействия, возможности работы тестируемой функции из различных входных точек:
   • Блокирующий, критический, значительный, незначительный, тривиальный.
8. Тип отчета. Ошибка кодирования, ошибка проектирования, предложение, расхождение с документацией, взаимодействие с аппаратурой, вопрос.
9. Статус недостатка. Новый, в работе, ожидание, решен, проверен, отклонен, закрыт.
10. Предварительные шаги. Например, наличие такой-то учетной записи с такими-то правами.
11. Шаги воспроизведения. Канер, Фолк и Нгуен: "Если вы знаете, как воспроизвести ситуацию, опишите этот процесс очень аккуратно, шаг за шагом, чтобы программист смог сразу его повторить".
    • Пункты воспроизведения недостатка с проставлением гиперссылок на упоминаемые разделы веб-сервиса, гиперссылок на тестовые примеры, где иллюстрируется недостаток.
    • В случае, если выстроить последовательность не удается четкое, то честное указание "воспроизвести не удалось".
12. Ожидаемый результат. Точное описание ожидаемых выходных данных или реакции программы.
13. Фактический результат. Описать ситуацию на момент обнаружения недостатка.
14. Подробное описание.
    • Гиперссылка на страницу Graylog, Apache_error_log или Facebook Open Graph Debugger с текстом ошибки и цитата ошибки из указанного веб-сервиса.
    • Данные из вкладки Console в панели разработчика браузера.
15. Повторяемость. Дата и ссылка на место повторного проявление недостатка, перечень IP-адресов с ошибкой. Это тот пункт в который собирается информация, если исправление недостатка откладывают в долгий ящик.
16. Предложения. Если решение неочевидно, то не ограничиваться одним вариантом. Перечислить два или три возможных варианта исправления недостатка.
17. Связанные проблемы.
    • Указать аналогичные фрагменты коды веб-проекта, аналогичные версии страницы на других языках, аналогичные шаблоны торговой процедуры, другие области, которые могут быть затронуты при решении инцидента.
18. Приложения
    • Скриншот с названием файла по форме "Название веб-сервиса или программы + Среда продукта (TEST, PROD) + Название и версия операционной среды + Название и версия браузера + Раздел + Текст ошибки или вопрос + Выполненное действие + Дата и время". Дату и время создания снимка достойные программы создания скриншотов добавляют самостоятельно. Например, Screenpresso.
    • Короткая видеозапись весом до десяти мегабайт, на которой видно куда нужно нажимать и что происходит. С созданием видеоролики также поможет Screenpresso. А если уложиться в указанный вес файла, то его можно прикрепить и к обновлению задачи в Redmine.
    • Входные данные для заполнения веб-формы, например, когда пользователь испытывает трудности при регистрации.
    • Выходные данные, например, txt-файл с полным логом ошибки, дамп базы данных.
19. Проверка правописания, стилистики и чистоты текста.
    • Google Chrome не подчеркивает отдельные слова, рекомендуя изменить правописание или пунктуацию.
    • Microsoft Word сообщает "Проверка правописания в документе завершена".
    • Веб-сервис Главред дает близкую к десяти баллам оценку словесный чистоты и синтаксиса, сообщает об отсутствии стоп-слов.
20. Пометка о лице обнаружившем недостаток для внутренней статистики и аналитики. Например группа обеспечения качества, пользователи веб-сервиса, системные администраторы.
21. История изменений. Последовательность действий членов команды проекта для изолирования, исправления и подтверждения исправления инцидента.

12.02.2017.