Как разумно сообщать об ошибках [закрыто]

Question

Я хочу написать (или найти) руководство по эффективному сообщению об ошибках в стиле, похожем на ESR. Как задавать вопросы разумно

Каковы ваши главные советы по созданию эффективных отчетов об ошибках?

Answer 1

• Пошаговая инструкция, как воссоздать ошибку
• Убедитесь, что вы попытались изолировать ошибку от того, против чего вы на самом деле пишете ошибку, а не от чего-то еще, что может быть причиной.
• Составьте список попыток изолировать ошибку от чего-то другого, кроме программного обеспечения, для которого вы пишете ошибку.
• Будьте готовы ответить на вопросы и помочь устранить неполадку/воссоздать ошибку.

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

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

Answer 2

Сообщайте о наблюдаемых фактах , а затем интерпретируйте эти факты.

Иногда лучшие сообщения об ошибках включают что-то, что является интуитивным пониманием проблемы. Сообщения об ошибках, основанные только на фактах, обесценивают этот ценный человеческий ресурс.

Answer 3

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

Слишком часто наши специалисты по контролю качества думают, что они могут просто написать запрос «вот мое исключение» без какой-либо резервной документации.Без дополнительной информации практически невозможно воспроизвести, не говоря уже о решении проблемы.

Answer 4

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

Answer 5

Порекомендуйте эту статью: Как эффективно сообщать об ошибках

Answer 6

Для всех людей, которые не будут смотреть на что-то без шагов для воспроизведения:
Моя первая совместная работа по программированию Мне была назначена ошибка, которая была, по сути, условием случайной гонки, которая делала систему нестабильной. Это происходило в любой момент выполнения системы, и все, что у нас было, - это несколько следов стека, указывающих на фрагмент кода, который, очевидно, был в порядке. Где-то другой поток дурачился с данными, которых не должно быть, и если этот поток был в нужной точке, он потерпел бы крах. Наш QA получал сбои примерно раз в месяц. Прошло две недели, чтобы прочесать систему, чтобы найти виновника (да, неконтролируемый доступ к общим ресурсам, исправление в 2 строки) и исправить его. Там никогда не было достойных шагов для воспроизведения, потому что не было никакого общего способа воспроизвести его (за исключением того, что вы положили кучу yield () в правильное место). Если вы собираетесь работать в многопоточной системе, лучше быть готовым к устранению ошибок, которые не могут быть надежно воспроизведены, могут не иметь стабильных шагов для воспроизведения, а не просто скулить в QA, потому что вы не можете воспроизвести ошибку ,

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

Answer 7

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

Answer 8

• Всегда сообщайте номер версии тестируемого программного обеспечения.
• Всегда сообщайте версии любого другого программного обеспечения (браузера, ОС и т. д.)
• Всегда перечисляйте все оборудование
• Действия по воспроизведению
• Симптомы ошибки
• Скриншоты, трассировки, логи, другие вложения (если есть)
• Насколько критично — сбой, пользовательский интерфейс и т. д.
• Сообщите, воспроизводится ли
• Что-нибудь еще, что пробовали, воспроизводило или не воспроизводило ошибку