Привет, я по поводу бага! 👋🏼
(с) сообщение от разработчика в большинстве случаев, когда вы неправильно оформляете баг репорт. А дальше море времени на объяснения-разъяснения, что, как и почему. Чтобы избежать недоразумений и нерациональной траты времени, старайтесь изначально не допускать ошибок и "заводить" баг в баг-трекер правильно.
❌ Типичные ошибки при написании отчётов о дефектах
Логические ошибки:
🔱 Выдуманные дефекты.
Одной из наиболее обидных для тестировщика причин отклонения отчёта о дефекте является так называемое «описанное поведение не является дефектом» («not a bug»), когда по какой-то причине корректное поведение приложения описывается как ошибочное.
🔱 Чрезмерно заниженные (или завышенные) важность и приоритет.
С этой бедой достаточно эффективно борются проведением общих собраний и пересмотром отчётов о дефектах силами всей команды (или хотя бы нескольких человек), но если эти показатели занижены именно чрезмерно, есть высокая вероятность, что пройдёт очень много времени, прежде чем до такого отчёта просто дойдёт очередь на следующих митингах.
🔱 Отнесение расширенных возможностей приложения к дефектам.
Самым ярким примером этого случая является описание как дефекта того факта, что приложение запускается под операционными системами, не указанными явно в списке поддерживаемых. Лишь в очень редких случаях при разработке неких системных утилит и тому подобного ПО, крайне зависящего от версии ОС и потенциально способного «поломать» неподдерживаемую, это можно считать ошибкой (с точки зрения общего здравого смысла ,такое приложение действительно должно показывать предупреждение или даже сообщение об ошибке и завершать работу на неподдерживаемой ОС).
🔱 Концентрация на мелочах в ущерб главному.
Здесь стоит упомянуть хрестоматийный пример, когда тестировщик нашёл проблему, приводящую к краху приложения с потерей пользовательских данных, но записал её как косметический дефект (в сообщении об ошибке, которое «перед смертью» показывало приложение, была опечатка). Всегда думайте о том, как произошедшая с приложением неприятность повлияет на пользователей, какие сложности они могут из-за этого испытать, насколько это для них важно, тогда шанс увидеть реальную проблему резко повышается.
🔱 Техническая безграмотность.
Представьте себе такое краткое описание (оно же идентично продублировано в подробном, т.е. это и есть всё описание дефекта): «Количество найденных файлов не соответствует реальной глубине вложенности каталога». А что должно? Это ведь почти то же самое, что «цвет кошки не соответствует её размеру» 🤷🏼♀️
🔱 Указание в шагах воспроизведения неважной для воспроизведения ошибки информации.
Стремление прописать всё максимально подробно иногда принимает нездоровую форму, когда в отчёт о дефекте начинает попадать чуть ли не информация о погоде за окном и курс национальной валюты.
🔱 Отсутствие в шагах воспроизведения информации, важной для воспроизведения дефекта.
🔱 Игнорирование «последовательных дефектов».
Иногда один дефект является следствием другого (допустим, файл повреждается при передаче на сервер, а затем приложение некорректно обрабатывает этот повреждённый файл). Да, если файл будет передан без повреждений, то второй дефект может не проявиться. Но может и проявиться в другой ситуации, т.к. проблема никуда не исчезла: приложение некорректно обрабатывает повреждённые файлы. Потому стоит описать оба дефекта.
#QAглазамиДжуна_полезное #тестоваядокументация #QAглазамиДжуна_понятия #багрепорт #отчетодефекте
(с) сообщение от разработчика в большинстве случаев, когда вы неправильно оформляете баг репорт. А дальше море времени на объяснения-разъяснения, что, как и почему. Чтобы избежать недоразумений и нерациональной траты времени, старайтесь изначально не допускать ошибок и "заводить" баг в баг-трекер правильно.
❌ Типичные ошибки при написании отчётов о дефектах
Логические ошибки:
🔱 Выдуманные дефекты.
Одной из наиболее обидных для тестировщика причин отклонения отчёта о дефекте является так называемое «описанное поведение не является дефектом» («not a bug»), когда по какой-то причине корректное поведение приложения описывается как ошибочное.
🔱 Чрезмерно заниженные (или завышенные) важность и приоритет.
С этой бедой достаточно эффективно борются проведением общих собраний и пересмотром отчётов о дефектах силами всей команды (или хотя бы нескольких человек), но если эти показатели занижены именно чрезмерно, есть высокая вероятность, что пройдёт очень много времени, прежде чем до такого отчёта просто дойдёт очередь на следующих митингах.
🔱 Отнесение расширенных возможностей приложения к дефектам.
Самым ярким примером этого случая является описание как дефекта того факта, что приложение запускается под операционными системами, не указанными явно в списке поддерживаемых. Лишь в очень редких случаях при разработке неких системных утилит и тому подобного ПО, крайне зависящего от версии ОС и потенциально способного «поломать» неподдерживаемую, это можно считать ошибкой (с точки зрения общего здравого смысла ,такое приложение действительно должно показывать предупреждение или даже сообщение об ошибке и завершать работу на неподдерживаемой ОС).
🔱 Концентрация на мелочах в ущерб главному.
Здесь стоит упомянуть хрестоматийный пример, когда тестировщик нашёл проблему, приводящую к краху приложения с потерей пользовательских данных, но записал её как косметический дефект (в сообщении об ошибке, которое «перед смертью» показывало приложение, была опечатка). Всегда думайте о том, как произошедшая с приложением неприятность повлияет на пользователей, какие сложности они могут из-за этого испытать, насколько это для них важно, тогда шанс увидеть реальную проблему резко повышается.
🔱 Техническая безграмотность.
Представьте себе такое краткое описание (оно же идентично продублировано в подробном, т.е. это и есть всё описание дефекта): «Количество найденных файлов не соответствует реальной глубине вложенности каталога». А что должно? Это ведь почти то же самое, что «цвет кошки не соответствует её размеру» 🤷🏼♀️
🔱 Указание в шагах воспроизведения неважной для воспроизведения ошибки информации.
Стремление прописать всё максимально подробно иногда принимает нездоровую форму, когда в отчёт о дефекте начинает попадать чуть ли не информация о погоде за окном и курс национальной валюты.
🔱 Отсутствие в шагах воспроизведения информации, важной для воспроизведения дефекта.
🔱 Игнорирование «последовательных дефектов».
Иногда один дефект является следствием другого (допустим, файл повреждается при передаче на сервер, а затем приложение некорректно обрабатывает этот повреждённый файл). Да, если файл будет передан без повреждений, то второй дефект может не проявиться. Но может и проявиться в другой ситуации, т.к. проблема никуда не исчезла: приложение некорректно обрабатывает повреждённые файлы. Потому стоит описать оба дефекта.
#QAглазамиДжуна_полезное #тестоваядокументация #QAглазамиДжуна_понятия #багрепорт #отчетодефекте