20150701

"Правильные" и "неправильные" баги.




Как правильно писать заголовок бага?
Да как угодно.
Если это устраивает всех участников процесса и продуктивность от этого выше чем от названий, указанных в каких-то методичках, то почему бы и нет?

Какая должна быть длина заголовка бага?
Да любая, лишь бы информативно.
Если ваш менеджер настолько туп, что не может удержать в голове предложение из больше чем 10 слов - поздравляю, вы работаете с дебилом.
А уж если он закрывает баги не глядя, то явно долго не продержится на своем месте.

"Стоп-слова" в названии бага?
Я слышал, что "стоп-слово" - это такой термин в ролевых играх, обозначающее что партнер больше не прикидывается и не играет, а говорит серьёзно. Я сейчас не только про те ролевые игры, но и про всякие тренинги по дискуссиям и прочему.

Подискутируем?

19 комментариев:

  1. Да что тут дискутировать.
    Я уже писала в QA Helpe, следующие доклады (судя по восторженным отзывам) надо начинать с информации "что такое адресная строка", " как правильно составить ключевые слова, чтоб найти что-то в поиске яндекс/гугл", писать видео -гайды по этому всему делу, и тогда будет успех.

    А потом мы говорим, что люди "тупеют".

    Не, ну я могу поворчать, что когда я начинала писать баги и тестировать в целлом, то самостоятельно приходилось перерывать тонны поисков-статей-книг-блогов и из всего имеющегося изобретать свой велосипед.
    не говорю, что это правильно, но закалило отлично.

    А вообще. если я буду по пол дня сидеть проверять правильно ли я составила заголовки в багах на 30-40 найденных багов за день - прикинем насколько увеличится время на это?
    И это только проверка. А недайбох там что-то не так? И я буду еще над каждым багом думать, как же его переписать....

    Это не говорит о том, что надо писать херь в названиях, но - имхо- если вас понимают разработчики и не задают лишних вопросов... ну вы поняли.

    ОтветитьУдалить
    Ответы
    1. Мой четвертый или пятый баг в жизни был заведен правильно. Почему? Мне хорошо объяснили.
      Точка.

      Удалить
  2. Этот комментарий был удален автором.

    ОтветитьУдалить
  3. Этот комментарий был удален автором.

    ОтветитьУдалить
  4. я все время рассказываю эту историю, и наверняка присутствующим в посте уже рассказывала. Когда я работала на своем первом месте работы вообще без опыта просто чистый белый лист, а не тестировщик :) , мне прогер постоянно говорил - заводи баги правильно!
    а правильно, это (далее цитата) "чтобы я по тайтлу понял в чем проблема, а прочитав дескрипшен знал в какой строке пофиксить". Не знаю удавалось ли мне второе, но первое я всегда держу в голове. И неважно как я добьюсь этого - длинным названием или словом-маркером в начале по типу "Дашборды: бла-бла-бла", которые назвали нечеловечными и проч.

    ОтветитьУдалить
    Ответы
    1. Я тоже активно юзаю слова-маркеры) про себя называю их префиксами, считаю дико удобно, когда в начале бага сразу видно к какой фиче или платформе он относится

      Удалить
    2. Ооо, девушки, полностью с вами согласен.

      Удалить
  5. Если холивар предлагается на тему багреда, дык этот сервис позиционируется джуниорским и мидлам и выше оно точно не надо, чего тут спорить)

    А по поводу джуниоров...ну мало кому из них можно сказать "пиши заголовок так, чтобы было понятно" и они напишут так, что будет понятно, им нужно дать какое-то правило на первых порах, привести примеры, поправить их первые ляпы... я тренила группу ребят и их первые баг-репорты- это та еще бугагашенька, багред был бы точно не лишним в ходе тренинга.

    Единственное что: я бы не тратила столько сил на подобный сервис, чтобы сделать реально круто, по-хорошему надо полгода фигачить, собирать фитбеки, править баги, а пользоваться сервисом будет каждый джуниор по разу максимум

    ОтветитьУдалить
    Ответы
    1. Ну Савин же!
      прочел - и все понятно.

      Я реально не понимаю проблемы джуниоров.
      Я обучала 60 человек который к тестированию не имели вообще отношения ( и к ИТ в большинстве тоже)
      и вот как-то ни у кого не возникало проблемы.

      Единственной моей фразой было - старайтесь указать где проблема и в чем она состоит.

      Все.

      Удалить
    2. Ну я видела другое: в теории все прекрасно понимают, что надо писать понятно, на практике с первого раза понятно никто не пишет и тоже самое касается тест кейсов и чек листов - у многих там поэмы по полстраницы на кейс. А Савина половина группы клялась что читала и все равно в репортах словечки про "некорректно"/"неправильно/ не работает" и т.д
      Пара практических кейсов с разбором "что не так" проблему решают.

      Удалить
    3. А еще...если по сути поста: пиши как удобно, если команда не жалуется, то норм

      Если работаешь в компании "я и программисты" - ну может и правда фиг бы с ним, пиши как хочешь. Но на большом проекте с немаленькой командой тестирования, с кучей открытых (за тыщу) багов хотелось бы, чтобы список заголовков был максимально информативным
      Я, например, как последняя зануда не люблю плодить дубли и каждый раз ищу не запостил ли мой баг уже кто-то до меня, дык заголовки типа "Некорректное завершение обработки запроса" или "Неверный результат вычисления итоговой суммы" приходится открывать и смотреть детали, что ж там некорректного, тк у меня запрос тоже некорректно завершился : 500 ошибкой, а у предыдущего тестировщика некорректность была в том, что не та страничка после отсылки отобразилась. это неудобно

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

      Удалить
    4. Бог с вами. Никакого обсуждения багреда! Хорошо, что сервис появился и я вижу у него большое будущее. Я рад за Олю и желаю ей успехов и дальше! Идея и правда нова и интересна!
      Багред был всего лишь поводом для холивара, вот и всё )

      Удалить
    5. Таня, условие было о том, что "устраивает всех участников процесса" :)

      Удалить
    6. Таня (да не робот я блин)7/01/2015 12:39:00 ПП

      нене, я про то, что даже если всех-всех на этом устраивает "ну как-нибудь", то все равно очень полезно завести себе привычку писать четко. Приучилась один раз и на всех проектах молодец на автомате. А критерии "четкости" в "этих самых методичках" давно прописаны и не особо сложны :что? где? когда? и избегать двусмысленности

      Удалить
    7. а что не так с словами -не корректо-не работает- и прочие?
      и почему их нельзч использовать?
      и для кого существует блин краткое описание бага?

      Удалить
    8. краткое, описание - для того, кто собирается этот баг процессить: верифаить, фиксить и т.д. а для тех, кто по разным причинам работает со списком багов, состоящим из заголовков (менеджер, другие тестировщики в команде, любой чел который делает выгрузку багов в репорт) -заголовок "некорректно завершается репорт" -это ящик Пандоры, выше приводила свой пример почему

      Удалить
  6. Мне кажется, что умение джуниора правильно заводить баг зависит того кто учит и от того кто учится заводить баг. Ведь усвоить формулу "Что где когда" достаточно просто.
    А значит проблема только в коммуникациях реципиента и передатчика.
    Один не умеет учить, а второй не хочет учиться.
    Но, как педагог, я могу сказать, что ученик виноват лишь в малом проценте случаев.
    Остальное - косяк преподавателя.

    ОтветитьУдалить
    Ответы
    1. Кстать, если есть желание и энтузиазм выссказаться, то было бы круто почитать мнение педагога об ошибках в обучении начинающих тестировщиков, как со стороны преподавателя, так и со стороны учеников

      Удалить
  7. Анонимный7/01/2015 01:11:00 ПП

    Еще момент, к пунктам Андрея. Через год, и даже через два после заведения бага - должно быть понятно в чём есть или была причина его заведения. Это должно пониматься из его заголовка + описания + доп. материалам к багу.
    PS: желательно Заголовок должен быть понятен всем участникам процесса, а не только программистам и ПМ, чтоб другие личности дубли не плодили.

    ОтветитьУдалить

Ваш комментарий очень важен для нас.