Теперь представьте что у вас большая и сложная система, и что много чего в ней нужно настроить и выполнить, чтобы получить ошибку. Например, была у меня ошибка, которая возникала на втором этапе второго цикла согласования документов. Сначала нужно написать, что и где требуется заполнить в карточке документа, чтобы можно было запустить согласование. Затем запустить согласование. Затем полностью описать действия согласующего, консолидатора согласования на первом цикле согласования, чтобы дойти до второго, затем описать действия согласующего на первом этапе второго цикла. Ещё существует куча предусловий, например, корректно запущенный workflow-сервис и в достаточном объёме выданные права.
Иногда получается довольно внушительный объём информации, поэтому я своим коллегам и предлагаю структурировать всё, это: разбить на пункты, описывать простыми предложениями, убрать лишние слова, очевидные действия сократить, где непонятно расписать подробнее (например, у нас не все разработчики в курсе, как запустить согласование), слова употреблять однозначно и понятно (чтобы разработчик не размышлял, что такое «виза»), а в конце перечитать всё получившееся.
Кстати, в своём примере вы и сами соблюли большинство из моих правил, хотя сами себе в этом не признаётесь =)
Я рада, что по наитию вы сразу всё пишите просто и понятно. Так делают, к сожалению, не все.
Шаги воспроизведения входят в описание ошибки. Под словом «Описание» я понимаю алгоритм воспроизведения, ожидаемое поведение, наблюдаемое поведение — это всё и есть описание (в контексте моей статьи). Как вы себе представляете описание без шагов? Вот только они могут быть написаны сплошным текстом, а могут быть структурированы в соответствии с описанными мной рекомендациями.
>>> сложно научить человека составлять предложения так, чтобы они были понятны всегда и всем
Сложно. Но можно попытаться направить поток его сознания в нужное русло. Именно на это направлены мои рекомендации.
Если все эти действия приводят к идентичному результату и от этого не зависит воспроизведение ошибки, то можно так сильно не детализировать.
Допустим, ошибка происходит в новой сессии. Для этого нужно открыть программу, что создаст новую сессию. Но КАК открыть программу — мышкой открыть или из консоли — да как угодно, это не нужно конкретизировать, главное открыть.
Иногда в большом куске информации есть всё, что нужно, но выуживать это нужное приходится по крупицам и из разных мест текста. Для меня это помехи в канале передачи информации, которые замедляют мою работу.
Я бы назвала это «рекомендации по оформлению баг-репорта». Существуют же всяческие рекомендации по оформлению кода, чтобы его легче было читать. Если следовать вашей логике, то это тоже своего рода каприз и можно писать весь код вообще в одну строчку, а переменные называть zxcvbn =)
видимо, вы невнимательно прочитали: я не писала о том, ЧТО писать в баг-репорте (такой информации в интернете более чем достаточно), я писала о том, КАК это писать.
Скрины и прочие вложения не должны заменять собой описание. Первое, на что посмотрит разработчик при открытии багтрекинга (по крайней мере нашего багтрекинга) — описание, до вложений ещё нужно добраться, поэтому описание должно быть максимально понятным.
Информация
В рейтинге
Не участвует
Откуда
Санкт-Петербург, Санкт-Петербург и область, Россия
Иногда получается довольно внушительный объём информации, поэтому я своим коллегам и предлагаю структурировать всё, это: разбить на пункты, описывать простыми предложениями, убрать лишние слова, очевидные действия сократить, где непонятно расписать подробнее (например, у нас не все разработчики в курсе, как запустить согласование), слова употреблять однозначно и понятно (чтобы разработчик не размышлял, что такое «виза»), а в конце перечитать всё получившееся.
Кстати, в своём примере вы и сами соблюли большинство из моих правил, хотя сами себе в этом не признаётесь =)
Я рада, что по наитию вы сразу всё пишите просто и понятно. Так делают, к сожалению, не все.
>>> сложно научить человека составлять предложения так, чтобы они были понятны всегда и всем
Сложно. Но можно попытаться направить поток его сознания в нужное русло. Именно на это направлены мои рекомендации.
Допустим, ошибка происходит в новой сессии. Для этого нужно открыть программу, что создаст новую сессию. Но КАК открыть программу — мышкой открыть или из консоли — да как угодно, это не нужно конкретизировать, главное открыть.