How to report windows 10 bug?

Wow MS really don’t want user participation when it comes to reporting bug in win10.

Just spent 10 min googling about and cant seem to find anyway to do it, so lets hope this thread gets the message to them.

So install Win10 Pro 64b over Win7 Pro 64b and it mostly went well inasmuch as the OS works and the MS programmes I ran all worked well.

However it would not run Alibre Design 11.2 or the Data Migration tool as both just crashed without error message and the compatibility finder tool didn’t fix the problem. To be fair these only worked in Win7 with a register hack so was bit of a unfair test.

But the GigaByte ET6 utility lockuped Win10 big time, mouse still worked but system just didn’t respond to clicks, the start menu no longer functions so cant re boot or shutdown also it kills the on/off button so only way out is to pull the power cord.

System rebooted ok after power cord unplugged.

Looks like you have a bit more compatibility testing guys.

And by the way do provide a simply tool to report bugs as some are trying to help 😉

Was this discussion helpful?

Sorry this didn’t help.

Great! Thanks for your feedback.

How satisfied are you with this discussion?

Thanks for your feedback, it helps us improve the site.

How satisfied are you with this discussion?

Thanks for your feedback.

Replies (39) 

* Please try a lower page number.

* Please enter only numbers.

* Please try a lower page number.

* Please enter only numbers.

20 people found this reply helpful

Was this reply helpful?

Sorry this didn’t help.

Great! Thanks for your feedback.

How satisfied are you with this reply?

Thanks for your feedback, it helps us improve the site.

How satisfied are you with this reply?

Thanks for your feedback.

52 people found this reply helpful

Was this reply helpful?

Sorry this didn’t help.

Great! Thanks for your feedback.

How satisfied are you with this reply?

Thanks for your feedback, it helps us improve the site.

How satisfied are you with this reply?

Thanks for your feedback.

bitMasters Can you be a little bit more specific please. Thanks

7 people found this reply helpful

Was this reply helpful?

Sorry this didn’t help.

Great! Thanks for your feedback.

How satisfied are you with this reply?

Thanks for your feedback, it helps us improve the site.

How satisfied are you with this reply?

Thanks for your feedback.

Windows 10 development methodology has certainly changed drastically since XP. Windows XP OS was designed to run just about any piece of hardware and software on the market. Post XP OS development moved to supporting MS products and services more or less exclusively. ( Onedrive, Essentials, Office..) Third party software has never been supported by MS, and now is second in consideration when the OS is concerned. Support services has been farmed out or contacted to outside of North America (Even if that company has a building in the USA), where they don’t have access to the source code and have no real way of fixing OS issues. The last two sessions with MS AnswerTech, level One support, end in reinstall or pay for a subscription. The ‘pay now or pay me later’ fix.

I think it’s time we see new OSs’ that can meet the or beat MS Windows OS. Maybe MS products will have problems, then they will understand the folly behind these changes.

14 people found this reply helpful

Was this reply helpful?

Sorry this didn’t help.

Great! Thanks for your feedback.

How satisfied are you with this reply?

Thanks for your feedback, it helps us improve the site.

Баг репорт (bug report): оформление и пример

Баг репорт (bug report) – это документ, содержащий отчет о любом недостатке в компоненте или системе, который может привести компонент или систему к невозможности выполнить требуемую функцию.

Bug report c определением в самом общем случае – это несоответствие требованиям или функциональным спецификациям (или здравому смыслу). То есть это отклонение фактического результата (actual result) от ожидаемого результата (expected result).

В данной статье мы рассмотрим основные моменты, связанные с созданием баг репорта, а также в конце предоставим баг репорт пример с возможностью скачивания.

Содержание

Определения понятия баг

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

• «Быстрое тестирование» (Роберт Калбертсон, Крис Браун, Гэри Кобб): «Программная ошибка – ни что иное, как изъян в разработке программного продукта, который вызывает несоответствие ожидаемых результатов выполнения программного продукта и фактически полученных результатов.»
• «Тестирование Дот Ком, или Пособие по жестокому обращению с багами в интернет-стартапах» (Роман Савин): «Итак, баг (bug) – это отклонение фактического результата (actual result) от ожидаемого результата (expected result). В соответствии с законом исключённого третьего у нас есть баг при наличии любого фактического результата, отличного от ожидаемого.»
• Википедия. «В целом, разработчики различают дефекты программного обеспечения и сбои. В случае сбоя программа ведёт себя не так, как ожидает пользователь. Дефект – это ошибка/неточность, которая может быть (а может и не быть) следствием сбоя.»
• Сергей Мартыненко (блог «255 ступеней»). «Дефект – поведение программы, затрудняющее или делающее невозможным достижение целей пользователя или удовлетворение интересов участников. Подразумевает возможность исправления. При невозможности исправления переходит в разряд ограничения технологии.»

Мы будем использовать простое определение:

Дефект (баг, глюк, ошибка; defect, bug) – это несоответствие требованиям или функциональным спецификациям.

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

Баги могут встречаться в любой документации, в архитектуре и дизайне, в коде программы и т.д.

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

Управление инцидентами перед оформлением баг репорта

Инцидент (incident) — это любое событие, требующее исследования.

Любое существенное, незапланированное событие, которое происходит во время тестирования, что требует дальнейшего исследования и / или коррекции:

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

Если есть расхождения между фактическими и ожидаемыми результатами, то прежде чем делать send bug report (отправь баг репорт), баг должны быть зарегистрированы как инциденты.

Инцидент (Test Incident) – любое событие, наблюдение, найденное в рамках тестирования, требующее исследования. Инцидент может возникнуть:

• В документации (требования, документы по разработке, тестовая документация, информация для пользователя);
• Во время тестирования в тестируемой системе или в тестовом окружении или во время использования продукта;
• В коде.

Виды инцидентов

Есть практика выделять два вида тестовых инцидентов: дефект и запрос на улучшение. Если давать определения этим понятиям, то можно назвать следующее

• Дефект (Defect, Bug) – любое состояние тестируемой системы, которое не соответствует ожидаемому поведению, основанному на спецификациях к проекту, требований, проектной документации, пользовательской документации, стандартов и т.п., или исходя из чьего-либо восприятия, опыта и здравого смысла. Дефекты бывают разных классификаций в зависимости от вида тестирования. Например, функциональное тестирование, тестирование документации, тестирование производительности и т.п. Синонимы: ошибка, отклонение, недочет, аномалия, помеха, отказ, проблема.
• Запрос на изменение (Improvement, Feature) – это любое предложение об усовершенствовании продукта или его отдельных свойств. Распространенные синонимы: Change Request, Issue, Enhancement, Usability.

back to menu ↑

Документирование инцидента

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

• Отчет по инциденту (Incident Report) – документ, описывающий событие, которое произошло, во время тестирования, и которое необходимо исследовать.
• Отчет о дефекте (Defect Report) – документ, описывающий ситуацию или последовательность действий, приведшую к некорректной работе объекта тестирования, с указанием причин и ожидаемого результата.
• Отчет о запросе на изменение (Improvement Report) – документ, описывающий предложение об усовершенствовании продукта. Включает в себя детальное описание предложения и обоснование внесения изменений в программное обеспечение.

Для управления и контроля над тестовыми инцидентами и баг репортами используются специализированные программы о них и поговорим ниже.

Инструмент управления дефектами и инцидентами

Оформление баг репорта или отчета об инциденте удобно делать если есть специальный инструмент управления дефектами (Defect Management Tool, Bug or Issue Tracker Tool) – инструмент, обеспечивающий фиксирование дефектов и изменений, а также поддержку их состояний. Часто имеет процессно-ориентированные возможности для поддержки и контроля распределения, исправления и повторной проверки дефектов, а также возможности отчетности. Помимо стандартной функциональности, хороший инструмент управления дефектами должен иметь возможности:

• поиска по критериям
• сохранять историю изменений
• гибкой настройки нотификаций.

В свою очередь хороший отчет о дефекте (баг репорт) должен обладать рядом свойств и характеристик, о которых давайте поговорим ниже.

Оформление баг репорта: основные принципы

Определения для понятия bug report мы навали выше, поэтому начнем с характеристик, которыми должен обладать отличный баг репорт. Качественное оформление баг репорта должно отвечать на следующие вопросы:

• Где? В каком месте интерфейса пользователя или архитектуры программного продукта находится проблема.
• Что? Что происходит или не происходит согласно спецификации или вашему представлению о нормальной работе программного продукта. При этом указывайте на наличие или отсутствие объекта проблемы, а не на его содержание (его указывают в описании). Если содержание проблемы варьируется, все известные варианты указываются в описании.
• Когда? В какой момент работы программного продукта, по наступлению какого события или при каких условиях проблема проявляется.

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

Цель баг репорта

Целью составления отчета о дефекте является ее исправление, поэтому не имеет смысла создавать отчеты ради отчетов. Чем больше хорошо задокументированных отчетов поступает от команды тестирования, тем больше доверия к тестированию. Целью отчёта об ошибке (bug-report) является:

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

Отчёт об ошибке – один из основных результатов работы тестировщиков. И, к слову, именно этот результат работы видят коллеги (другие тестировщики и люди, не входящие в команду тестировщиков), при этом заказчики видят работающий продукт.

И если подводить черту под смыслом написания баг репорта, то основная цель написания отчёта об ошибке – устранение ошибки.

Поэтому стоит помнить, что хороший тестировщик – не тот, кто написал за день 1000 бесполезных и бессмысленных отчётов, а тот, по чьим отчётам (вне зависимости от их количества) было исправлено большое количество ошибок.

Баг репорт: пример полей для заполнения (атрибуты)

Ниже предоставлен список основных полей отчета о дефекте. Будем перечислять возможные атрибуты, а также останавливаться и объяснять наиболее важные. Звездочками помечены обязательные поля для заполнения.

Название проекта * (Project) – официальное название проекта

Здесь, в принципе, все понятно и каких-либо дополнительных объяснений не нужно.

Уникальный номер отчета * (ID) – идентификатор отчета о дефекте

У каждого отчёта об ошибке должен быть уникальный идентификатор. Как правило, системы управления ошибками (bug tracking systems) позволяют формировать идентификатор в виде некоторого шаблона, например аббревиатура проекта + дата + порядковый номер

Либо, каким-нибудь другим видом, при этом ID, будет позволять идентифицировать баг.

Дата создания * (Created Date) – дата создания отчета

Опять-таки, здесь все предельно понятно.

Дата обновления (Update Date) – дата обновления (изменение, закрытие)

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

Краткое описание * (Summary, Title, Subject, Synopsis) – заголовок отчета

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

Например:

• «Отсутствует логотип на странице приветствия, если пользователь является администратором».
• «Невозможно открыть файл с именем длиннее 500 символов».
• «Приложение виснет при попытке ввести пустой пароль на странице авторизации пользователей»

Краткое описание иногда предваряется префиксом, указывающим область работы с приложением, для которой актуален баг, например:

• [EN] «Опечатка в сообщении о неверном логине/пароле на странице авторизации пользователей» – баг актуален для английской версии ПО.
• [Opera] «Ошибка JavaScript при просмотре личных сообщений в профиле пользователя» – ошибка возникает только в браузере Opera.

Примечание:

• Слова, что нельзя произносить… 
• Плохая картинка, не работает, ошибка, неверное поведение…
• Can’t reproduce

Текущий статус * (Status) – состояние инцидента

Набор статусов зависит от выбранного процесса разработки. Базовые статусы:

О правилах переходов из состояния в состояние будет сказано в статье про жизненный цикл бага.

Резолюция (Resolution) – пояснение к статусу

К примеру, дефект может быть закрыт, но причины закрытия могут быть разными: сделан, дубликат, отклонен. Набор резолюций зависит от выбранного процесса разработки. Базовый набор возможных резолюций:

• Unresolved
• Fixed
• Won‘t Fix
• Duplicate
• Cannot Reproduce
• Verified

Подробнее о резолюциях будет сказано в отдельной статье.

Приоритет (Priority) – свойство, указывающее на очередность выполнения задачи или устранения дефекта

Также является важным атрибутом bug report, чем выше приоритет сущности, тем быстрее нужно приступить к ее реализации. Набор приоритетов завит от выбранного процесса разработки и зачастую, данную информацию отражает тест план. Базовый набор приоритетов:

• High — наивысшая или (ASAP, as soon as possible). Присваивается ошибкам, наличие которых делает невозможным дальнейшую работу над проектом или передачу заказчику текущей версии проекта.
• Major — Присваивается ошибкам, которые нужно исправить в самое ближайшее время.
• Medium — Присваивается ошибкам, которые следует исправлять в порядке общей очереди.
• Low — Присваивается ошибкам, которыми отделу разработки следует заниматься в последнюю очередь (когда и если на них останется время).

Приоритет может выставляться инженером по тестированию, но, как правило, приоритет редактируется менеджером проекта.

Строгость (Severity) – техническая оценка инцидента

Набор степеней строгости дефектов завит от выбранного процесса разработки и договоренностей между участниками проекта. Базовый набор:

• Критическая (critical). Это самые страшные ошибки, выражающиеся в крахе приложения или операционной системы, серьёзных повреждениях базы данных, падению веб-сервера или сервера приложений.
• Высокая (major). Серьёзные ошибки, такие как: потеря данных пользователя, падение значительной части функциональности приложения, падение браузера или иного клиента и т.п.
• Средняя (medium). Ошибки, затрагивающие небольшой набор функций приложения. Как правило, такие ошибки можно «обойти», т.е. выполнить требуемое действие иным способом, не приводящим к возникновению ошибки.
• Низкая (minor). Ошибки, не мешающие непосредственно работе с приложением. Как правило, сюда относятся всевозможные косметические дефекты, опечатки и т.п.

Тип инцидента (Incident Type) *

Принято выделять два вида тестовых инцидентов:

• дефект (Bug)
• запрос на улучшение (Improvement).

Категория инцидента (Category)

Данное свойство отображает, к какой характеристике проекта относится инцидент. Базовый набор категорий:

• Functional
• Text
• Design (баг репорт на косметический дефект)
• Documentation
• Performance
• Technical

Компонент (ы) (Component)

Здесь отображается область объекта тестирования, к которой относится инцидент.

Версия приложения, для которой инцидент актуален (Affects Version)

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

(Fix Version)

Версия приложения, в которой инцидент был закрыт.

Создатель отчета * (Reporter)

Этот атрибут хранит в себе имя создателя отчета. Создателем отчета не обязательно должен быть специалистом по тестированию, им может быть любой участник проекта или даже пользователи.

На кого назначен отчет (Assignee)

Здесь отражается имя сотрудника, назначенного на решение задачи.

Метки (Labels)

Метки используются для систематизации информации. В дальнейшем метки служат для сбора метрик, поиска дефектов и т.п.

Окружение (Environment)

Окружение, на котором найден дефект – операционная система, браузер, версия браузера, сервер и т.п. Если дефект воспроизводится на всех окружениях, то ставится соответствующий комментарий.

Описание * (Description)

Также чрезвычайно важный атрибут. Описание должно быть лаконичным и ясным, как и Summary, но в более развернутой форме. Если есть альтернативные шаги, то их также нужно указать. В описание можно оставлять любые полезные примечания – повторяемость, уточнения и т.п. Пример Description в баг репорте:

Если администратор заходит на страницу приветствия, то логотип пропадает.

Actual result: логотипа нет. (Реальный результат)

Expected result: логотип в правом верхнем углу. (Ожидаемый результат)

Requirement ID: #45 (пункт требований)

Reproduced on: Win10, IE11, 1200x800dpi (на чем воспроизводиться)

Workaround: Да, логотип отображается, если обновить страницу повторно

For more details, please, see attached files:

Как видно из примера Описание (Description) имеет набор атрибутов, которые входят в его состав, давайте некоторые поясним

Приложения (Attachments)

Любая информация, которая поможет воспроизвести ситуацию:

Воспроизводимость (reproducible, reproducibility)

Это поле показывает, воспроизводится ли баг всегда («always») или лишь иногда («sometimes»). Баги, воспроизводящиеся всегда, гораздо проще диагностировать.

Примечание:

Рекомендация: пройдитесь по своим шагам воспроизведения хотя бы 2-3 раза прежде, чем писать, что баг воспроизводится всегда.

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

Возможность «обойти баг» (workaround)

Это поле косвенно влияет на важность и срочность устранения ошибка. Если некое действие можно выполнить в обход сценария, приводящего к ошибке, поле принимает значение «да» («yes»), в противном случае – поле принимает значение «нет» («no»).

Шаги воспроизведения (steps to reproduce, STR)

Данная информация в отчёте об ошибке является крайне важной. Именно она позволяет разработчику быстро воспроизвести и устранить проблему. Это поле следует заполнять максимально подробно, т.к. будучи незнакомым с внутренней структурой приложения, тестировщик не может знать, какие из выполненных им действий наиболее существенны для диагностирования данной ошибки (steps в тест кейсе, в какой-то степени, похожи STR).

Несколько рекомендаций:

• Описывайте каждый шаг, пока не столкнётесь с дефектом.
• Найдите точный путь, чтобы воспроизвести дефект.
• Попытайтесь найти кратчайший путь.
• Повторите все описанные шаги несколько раз и убедитесь, что всё верно.
• Описывайте каждое действие, которой вы делаете, в отдельном шаге.

Пример:

1. Open www.mysite.com
2. Click on [Account] button
3. Fill in sing-in form with admin/admin123
4. Click on [Sing in] button – user is redirected on a greeting page, site logo is absent.

Дополнительная информация (additional info)

В это поле можно писать всё то, что вы считаете необходимым отметить, но что не подходит для размещения в других полях.

Требования, тест-кейсы, среда нахождения ошибки, билд, рассуждения, комментарии, мысли, анализ возможных причин появления бага и путей его устранения – всё это пишется здесь.

Симптом (symptom)

Это поле показывает, к какой категории относится ошибка. Наиболее широко распространённые симптомы:

• Косметический дефект (cosmetic flaw) – опечатки, повреждённые картинки, не тот цвет, не тот размер, не там расположено и т.п. другими словами баг репорт на косметический дефект.
• Повреждение/потеря данных (data corruption/loss) – в результате ошибки данные повреждаются или теряются.
• Проблема в документации (documentation issue) – такой симптом присваивается ошибке, если она описывает проблему не в приложении, а в документации.
• Некорректная операция (incorrect operation) – например: 2+2=5, или: хотим сохранить файл в c:/ , а он сохраняется в d:/
• Проблема инсталляции (installation problem) – ошибки, возникающие на стадии установки или удаления приложения.
• Ошибка локализации (localisation issue) – что-то не переведено или переведено неверно.
• Нереализованная функциональность (missing feature) – например: приложение сохраняет файлы только в формате DOC, а должно ещё и в XML.
• Низкая производительность (slow performance) – некоторые действия и/или условия работы приводят к тому, что приложение начинает «тормозить».
• Крах системы (system crash) – приложение или операционная система или (веб-сервер / сервер приложений / СБД) виснет, перезагружается, «вываливается» (закрывается).
• Неожиданное поведение (unexpected behavior) – например: комбинация клавиш Ctrl-O вызывает не открытие, а печать файла; в полях формы появляются странные значения по умолчанию. (Как правило связано с usability)
• Недружественное поведение (unfriendly behavior) – например: на сайте есть голосование, пользователь выбирает вариант, нажимает «Проголосовать» и… его просят зарегистрироваться.
• Расхождение с требованиям (variance from spec) – под этот симптом попадает почти любая ошибка, но рекомендуется писать его только тогда, когда к ошибке не подходит ничего из вышеперечисленного.
• Предложение по улучшению (enhancement) – строго говоря, это – не баг, и во многих фирмах не принято его писать в список багов; имеется в виду, что приложение работает по требованиям, но можно улучшить его работу, если внести предлагаемые изменения.

Примечание: Может ли у ошибки быть сразу несколько симптомов? Да, может. Но выбирать лучше самый важный (наиболее показательный).

Должен ли баг репорт содержать весь набор атрибутов?

Вроде бы, мы рассмотрели наиболее распространенные атрибуты для bug report. Все из перечисленных полей(атрибутов) заполняются создателем отчета. Поле приоритет редактируется менеджером проекта.

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