Что такое вложение (Attachment) в баг-репорте и зачем оно нужно?

А, ну вот, смотри, классика жанра! Приходит тестировщик и такой: «У вас тут всё сломалось, нажимаю кнопку — ничего не происходит». А разработчик смотрит на это и думает: «Ну и что, сука, не происходит? Может, у тебя просто палец кривой?». Вот чтобы не было этой ебалы, и придумали вложения.

Это, блядь, не просто бумажка в файлик, это — неопровержимая улика, как отпечатки пальцев на месте преступления! Ты не просто говоришь «ошибка», ты её, сука, предъявляешь. Всё равно что вместо «он меня ударил» показать синяк под глазом и видео с камеры. Уже не отвертишься.

Зачем это всё, нахуй?

1. Наглядность, ёпта. Словами «кнопка съехала на три пикселя вправо» можно долго объяснять. А ты — бац! — скриншот. И все сразу видят, что кнопка, действительно, съехала, и выглядит это как пиздец.
2. Экономия времени, которого и так ноль ебать. Разработчик не будет полчаса гадать, как ты воспроизвёл баг. Посмотрел на скринкаст — и всё, уже понял, где ты накосячил. Или где он накосячил.
3. Контекст, блядь. Иногда ошибка — она в данных. «Падает при загрузке файла». А какой файл? А вот он, файл, получай! Сам смотри, что там внутри такого, от чего твой код накрывается медным тазом.
4. Доказательство, что ты не еблан. Особенно для плавающих, хреново воспроизводимых багов. «У меня тут раз в неделю вылетает». Ага, щас. А ты приложи видео, где этот вылет зафиксирован, и все сразу поверят, что ты не гонишь.

Что обычно кидают во вложения, как говно в вентилятор?

• Скриншоты/Скринкасты. Самое очевидное. Белый экран вместо формы? Вот он, белый экран, любуйся, сука. Анимация дёргается? Вот скринкаст, смотри, как она пляшет, как мартышлюшка.
• Логи (Logs). Это святое, блядь! «В консоли какая-то херня» — это не лог. А вот файлик logcat.txt, где чётко видно NullPointerException at com.example.app.CheckoutActivity.onCreate(CheckoutActivity.java:228) — это уже диагноз. Прямо указание, в каком месте кода нужно ебнуть молотком.
• Видео. Для всего, что связано с движением, таймингом или сложными сценариями. Словами не опишешь.
• Файлы данных/конфиги. «Падает при импорте этого CSV». Ну так на, вот этот CSV, импортируй его сам и посмотри, где тебя вырвет.
• Дампы памяти, трассировки стека. Это уже для серьёзных разборок, когда приложение не просто упало, а упало с таким треском, что земля содрогнулась. Тут уже без спецсредств не разобраться.

Как это выглядит в деле, чтобы не было стыдно:

Шаги воспроизведения:
1. Зайти на страницу /checkout.
2. Добавить товар в корзину.
3. Нажать кнопку "Оплатить".

Ожидаемый результат: Открывается форма выбора способа оплаты.
Фактический результат: Появляется белый экран (см. скриншот attachment_1.png).
В логах приложения зафиксирована ошибка NullPointerException (см. logs.txt).

Видишь? Коротко, ясно, и приложено доказательство — и картинка, и логи. Разработчик открывает, видит скриншот белого экрана, открывает логи, видит строчку с NPE — и у него уже волнение ебать, он уже бежит чинить, а не тратит время на переписку «а что ты там нажал?».

Негласные правила, чтобы не быть мудаком:

• Скриншот делай полный, а не кусочек экрана размером с почтовую марку. Мы же не в разведке, чтобы головоломки разгадывать.
• Выдели проблемное место. Стрелочкой, кружочком, жирной рамочкой. Чтобы взгляд сразу цеплялся, а не искали иголку в стоге сена.
• Логи обрезай вокруг ошибки. Не надо слать файл на 500 мегабайт. Вырежи кусок за 5 секунд до падения и 5 секунд после. С временными метками! Чтобы было понятно, что к чему.
• Названия файлам давай человеческие. Не IMG_0234234.PNG, а checkout_white_screen_after_payment_click.png. Не log.txt, а logcat_npe_checkout_15_30.txt. Потом сам же искать будешь, пидарас шерстяной.

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