ALMELN.ru

Хранилище текстов, отзывов и закладок о тестировании, обеспечении качества и литературе

View the Project on GitHub

Правила составления отчета об ошибке

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

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

Содержание

  1. Тестирование программного обеспечения. Фундаментальные концепции менеджмента бизнес-приложений
  2. Ключевые процессы тестирования. Планирование, подготовка, проведение, совершенствование
  3. «Сертифицированный тестировщик. Программа обучения Базового уровня»
  4. Резюме

«Тестирование программного обеспечения. Фундаментальные концепции менеджмента бизнес-приложений»

Сэм Канер, Джек Фолк и Енг Кек Нгуен, Москва, ДиаСофт, 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. Перейти на Главную страницу