Комментарии 18
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
Пример такой баги: Не могу создать аккаунт.
а как стоило бы написать заголовок, чтобы он не был общим?
Писать так как есть :)
«Не могу создать аккаунт» — значит, что аккаунт создать невозможно. Вообще никак. Вообще лучше звучит «Невозможно создать аккаунт».
Если существуют ошибки в процедуре создания аккаунта, например у автора
Такой аккаунт уже существует (или в имени аккаунта введены недопустимые символы), а проблема в том, что сообщение об ошибке не отобразилось (возможно, что только на определенной версии браузера);
то название ошибки «Создание аккаунта. Не отображается сообщение об ошибке при вводе ошибочных данных в поле „Логин“».
А вообще у ошибок есть атрибуты:
— идентификатор;
— название;
— суть ошибки;
— условия воспроизведения;
— критичность.
«Не могу создать аккаунт» — значит, что аккаунт создать невозможно. Вообще никак. Вообще лучше звучит «Невозможно создать аккаунт».
Если существуют ошибки в процедуре создания аккаунта, например у автора
Такой аккаунт уже существует (или в имени аккаунта введены недопустимые символы), а проблема в том, что сообщение об ошибке не отобразилось (возможно, что только на определенной версии браузера);
то название ошибки «Создание аккаунта. Не отображается сообщение об ошибке при вводе ошибочных данных в поле „Логин“».
А вообще у ошибок есть атрибуты:
— идентификатор;
— название;
— суть ошибки;
— условия воспроизведения;
— критичность.
Замечательная картинка про баги :)
Почему то картинка не вставляется… habrastorage.org/storage2/1ec/969/928/1ec9699283fa95eeb62ecc9dc190675c.jpg
Если в трекере полно репортов с вышеуказанными признаками, то виной тому обычно три причины:
— информационная (тестер сам не понял как он этого добился, соответственно не может дать подробного описания);
— методологическая (тестер не был обучен работе с трекером);
— орнитологическая (тестер дятел).
— информационная (тестер сам не понял как он этого добился, соответственно не может дать подробного описания);
— методологическая (тестер не был обучен работе с трекером);
— орнитологическая (тестер дятел).
Основные косяки в описании дефектов обычно не от тестеров, а от самих программистов :)
Обычно дело: короткое описание и кусок кода в подробностях.
Ну и с пунктом 5 не совсем согласен. Понятие «приятности» очень субъективно же.
Обычно дело: короткое описание и кусок кода в подробностях.
Ну и с пунктом 5 не совсем согласен. Понятие «приятности» очень субъективно же.
<< Очень подробные pre-steps, очень краткое описание.
Не согласен. Как раз чем подробнее — тем лучше. Пусть хоть 10кб текста напишет, это лучше, чем мы что-нибудь упустим.
<< На каждое проявление ошибки создать отдельный баг-репорт
Если пользователь, нашедший ошибку, эту систему не писал — скорее всего, он не сможет УГАДАТЬ, связаны ли проблемы. Лучше будут два тикета, а разработчики разберутся (разберемся:) ).
<< Использование специфических сокращений и аббревиатур
Об этом вообще в первый раз слышу. Есть такая проблема? Чтобы пользователь сокращения использовал?
Не согласен. Как раз чем подробнее — тем лучше. Пусть хоть 10кб текста напишет, это лучше, чем мы что-нибудь упустим.
<< На каждое проявление ошибки создать отдельный баг-репорт
Если пользователь, нашедший ошибку, эту систему не писал — скорее всего, он не сможет УГАДАТЬ, связаны ли проблемы. Лучше будут два тикета, а разработчики разберутся (разберемся:) ).
<< Использование специфических сокращений и аббревиатур
Об этом вообще в первый раз слышу. Есть такая проблема? Чтобы пользователь сокращения использовал?
В общем, я не согласен с советами в общем случае. Если человек — тестировщик, да, часть советов имеет смысл. Но если это обычный пользователь? Он заметил баг, решил прислать, а тут — 10-20 полей, обязательных для заполнения, а еще нужно пробежаться по всей базе (в поиске могут быть фильтры, но например, он может не знать, к какому модулю это относится. Этим грешат в phpstorm), а еще — максимально коротко, но достаточно длинно…
Главное — скриншот, чтобы видеть проблему, максимально много информации (но не заставлять пользователя ее писать, иначе он вообще тикет не создаст), и описание проблемы «как ее видит пользователь».
Главное — скриншот, чтобы видеть проблему, максимально много информации (но не заставлять пользователя ее писать, иначе он вообще тикет не создаст), и описание проблемы «как ее видит пользователь».
> Как раз чем подробнее — тем лучше. Пусть хоть 10кб текста напишет, это лучше, чем мы что-нибудь упустим.
А у нас вот кодеры ругаются, когда в описании видят простыню текста — они её читают по диагонали и делают основные выводы о баге из его заголовка. Всё же краткость — сестра таланта. Но только когда она рука об руку с ясностью изложения, конечно.
> Чтобы пользователь сокращения использовал?
Вы именно про пользователей продуктом или про пользователей баг-трекером (тестировщиков)? Я довольно часто в некоторых проектах использую. Стараюсь делать это только в тех случаях, когда сокращения очевидны. Например, при тестировании админского клиента для приложения могу использовать AC (Admin Client).
А у нас вот кодеры ругаются, когда в описании видят простыню текста — они её читают по диагонали и делают основные выводы о баге из его заголовка. Всё же краткость — сестра таланта. Но только когда она рука об руку с ясностью изложения, конечно.
> Чтобы пользователь сокращения использовал?
Вы именно про пользователей продуктом или про пользователей баг-трекером (тестировщиков)? Я довольно часто в некоторых проектах использую. Стараюсь делать это только в тех случаях, когда сокращения очевидны. Например, при тестировании админского клиента для приложения могу использовать AC (Admin Client).
Я говорил про общий случай, когда трекером пользуется пользователь приложения/сервиса (да и тестировщик). В любом случае, не представляю, чтобы такие люди использовали сокращения. Вот кодеры — да, это беда.
Ну, я тестировщик.
Есть у нас один проект, например. Грубо говоря, там есть три различных клиентских приложения — Admin Client, Cashier Client и User Client. При описании какой-нибудь хитрой длинной баги я вполне могу начать называть их AC, CC и UC соответственно. Вероятно, о подобных (но менее очевидных) случаях и идёт речь в статье.
Всё же зависит от проекта в первую очередь, мне думается.
Есть у нас один проект, например. Грубо говоря, там есть три различных клиентских приложения — Admin Client, Cashier Client и User Client. При описании какой-нибудь хитрой длинной баги я вполне могу начать называть их AC, CC и UC соответственно. Вероятно, о подобных (но менее очевидных) случаях и идёт речь в статье.
Всё же зависит от проекта в первую очередь, мне думается.
Об этом вообще в первый раз слышу. Есть такая проблема? Чтобы пользователь сокращения использовал?
У нас, например, карточная игра. Точнее, карточные игры. И вот, игроки, случается, используют аббревиатуры. Например, ХС (читается ХаСэ) — это Хозяин Склепа, а вот ХоСу — Хозяин Судеб. Если сам не играешь, поди догадайся, что ХС это именно хозяин склепа, а не судеб :).
Тестировщиков — новичков я обычно прошу прочитать старенькую статью Джоэла Спольски
«Работа над ошибками малой кровью» (по-русски или по-английски).
Там в общем-то довольно очевидные вещи написаны:
"… Каждое хорошее описание ошибки должно содержать ровно три вещи:
Какие шаги привели к ошибке.
Что вы ожидали увидеть.
Что вы в самом деле увидели..."
Обычно после прочтения качество баг репортов заметно повышается.
«Работа над ошибками малой кровью» (по-русски или по-английски).
Там в общем-то довольно очевидные вещи написаны:
"… Каждое хорошее описание ошибки должно содержать ровно три вещи:
Какие шаги привели к ошибке.
Что вы ожидали увидеть.
Что вы в самом деле увидели..."
Обычно после прочтения качество баг репортов заметно повышается.
На старой работе мы немного переработали нашу систему интеграционных тестов, и в конце-концов заставили каждого тестера в ней разобраться и изучить, как писать тесты.
В итоге, в багах было просто краткое описание проблемы и название теста. Нам же оставалось только обновить тестовую ветвь и запустить у себя в IDE тест.
Правда, специфика системы была такова, что все действия пользователя легко эмулировались.
В итоге, в багах было просто краткое описание проблемы и название теста. Нам же оставалось только обновить тестовую ветвь и запустить у себя в IDE тест.
Правда, специфика системы была такова, что все действия пользователя легко эмулировались.
Не вошёл в список наиболее распространённый (по крайней мере из тех, с которыми я работал) горе-багрепорт: «У вас программа медленно грузится, иконка не того цвета, при вводе текста ошибка случается, пункт меню — не скажу какой-именно — не работает. Да и погода к тому же плохая — дождь идёт». (видимо, от разработчкаи требуется написать Not Reproduced — дождь уже кончился).
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Распространенные ошибки при составлении баг-репортов