Примеры оформления багов с КоТэ

Всем привет! Сегодня выступала на КоТэ, конференции для тестировщиков с мастер-классом по заведению дефектов. Перед мастер-классом я дала домашнее задание — потестировать 4 разных сайта.

Ребята справились с ДЗ на «УРА»! Целых 130 ответов!!! Честно говоря, я столько не ожидала ツ

Гуглодока ответов — https://docs.google.com/spreadsheets/d/1ew8qXDZnODDLWxukfLkxYcxIJ6f6PAmHaWJ76dXaEjQ/edit#gid=558356532

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

На докладе я дала некоторые номера строк гуглодоки как образцы. Вот они:



Название

Хорошее: 3, 4, 12, 14, 114
Можно улучшить: 6 и 104, 23, 59, 100 (но сам баг классный)


Описание

Хорошее, причем без шаблона: 57, 109, 35, 34 (хотя ссылочку бы и скриншот)
Хорошее:  41, 43, 27, 18...
Можно улучшить: 115, 104, 48, 47, 29, 14, 37, 54, 88...

Домашнее задание

Проверьте себя — попробуйте улучшить те номера, которые я указала. 

А также найти новые примеры, по 3 штучки:

• Хорошего оформления 
• Оформления, которое можно улучшить — что именно там не так? Как переписать?

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

Материал в помощь

Шаблон бага → Как выглядит типичный баг
Шаблон улучшения → Как продумывать свое улучшение с примером, когда это приводит к отказу от постановки задачи.

Как заводить задачи в баг-трекер → Подробнее о том, как ставить задачу и заполнять обязательные поля.

Не пишите в баге «Ввести 6,9»! → это плохо кончится

Паттерны и антипаттерны обоснования багов → Как убедить разработчика, что задачу стоит поправить?