Как правильно писать заголовок бага?
Да как угодно.
Если это устраивает всех участников процесса и продуктивность от этого выше чем от названий, указанных в каких-то методичках, то почему бы и нет?
Какая должна быть длина заголовка бага?
Да любая, лишь бы информативно.
Если ваш менеджер настолько туп, что не может удержать в голове предложение из больше чем 10 слов - поздравляю, вы работаете с дебилом.
А уж если он закрывает баги не глядя, то явно долго не продержится на своем месте.
"Стоп-слова" в названии бага?
Я слышал, что "стоп-слово" - это такой термин в ролевых играх, обозначающее что партнер больше не прикидывается и не играет, а говорит серьёзно. Я сейчас не только про те ролевые игры, но и про всякие тренинги по дискуссиям и прочему.
Подискутируем?
Да что тут дискутировать.
ОтветитьУдалитьЯ уже писала в QA Helpe, следующие доклады (судя по восторженным отзывам) надо начинать с информации "что такое адресная строка", " как правильно составить ключевые слова, чтоб найти что-то в поиске яндекс/гугл", писать видео -гайды по этому всему делу, и тогда будет успех.
А потом мы говорим, что люди "тупеют".
Не, ну я могу поворчать, что когда я начинала писать баги и тестировать в целлом, то самостоятельно приходилось перерывать тонны поисков-статей-книг-блогов и из всего имеющегося изобретать свой велосипед.
не говорю, что это правильно, но закалило отлично.
А вообще. если я буду по пол дня сидеть проверять правильно ли я составила заголовки в багах на 30-40 найденных багов за день - прикинем насколько увеличится время на это?
И это только проверка. А недайбох там что-то не так? И я буду еще над каждым багом думать, как же его переписать....
Это не говорит о том, что надо писать херь в названиях, но - имхо- если вас понимают разработчики и не задают лишних вопросов... ну вы поняли.
Мой четвертый или пятый баг в жизни был заведен правильно. Почему? Мне хорошо объяснили.
УдалитьТочка.
Этот комментарий был удален автором.
ОтветитьУдалитьЭтот комментарий был удален автором.
ОтветитьУдалитья все время рассказываю эту историю, и наверняка присутствующим в посте уже рассказывала. Когда я работала на своем первом месте работы вообще без опыта просто чистый белый лист, а не тестировщик :) , мне прогер постоянно говорил - заводи баги правильно!
ОтветитьУдалитьа правильно, это (далее цитата) "чтобы я по тайтлу понял в чем проблема, а прочитав дескрипшен знал в какой строке пофиксить". Не знаю удавалось ли мне второе, но первое я всегда держу в голове. И неважно как я добьюсь этого - длинным названием или словом-маркером в начале по типу "Дашборды: бла-бла-бла", которые назвали нечеловечными и проч.
Я тоже активно юзаю слова-маркеры) про себя называю их префиксами, считаю дико удобно, когда в начале бага сразу видно к какой фиче или платформе он относится
УдалитьОоо, девушки, полностью с вами согласен.
УдалитьЕсли холивар предлагается на тему багреда, дык этот сервис позиционируется джуниорским и мидлам и выше оно точно не надо, чего тут спорить)
ОтветитьУдалитьА по поводу джуниоров...ну мало кому из них можно сказать "пиши заголовок так, чтобы было понятно" и они напишут так, что будет понятно, им нужно дать какое-то правило на первых порах, привести примеры, поправить их первые ляпы... я тренила группу ребят и их первые баг-репорты- это та еще бугагашенька, багред был бы точно не лишним в ходе тренинга.
Единственное что: я бы не тратила столько сил на подобный сервис, чтобы сделать реально круто, по-хорошему надо полгода фигачить, собирать фитбеки, править баги, а пользоваться сервисом будет каждый джуниор по разу максимум
Ну Савин же!
Удалитьпрочел - и все понятно.
Я реально не понимаю проблемы джуниоров.
Я обучала 60 человек который к тестированию не имели вообще отношения ( и к ИТ в большинстве тоже)
и вот как-то ни у кого не возникало проблемы.
Единственной моей фразой было - старайтесь указать где проблема и в чем она состоит.
Все.
Ну я видела другое: в теории все прекрасно понимают, что надо писать понятно, на практике с первого раза понятно никто не пишет и тоже самое касается тест кейсов и чек листов - у многих там поэмы по полстраницы на кейс. А Савина половина группы клялась что читала и все равно в репортах словечки про "некорректно"/"неправильно/ не работает" и т.д
УдалитьПара практических кейсов с разбором "что не так" проблему решают.
А еще...если по сути поста: пиши как удобно, если команда не жалуется, то норм
УдалитьЕсли работаешь в компании "я и программисты" - ну может и правда фиг бы с ним, пиши как хочешь. Но на большом проекте с немаленькой командой тестирования, с кучей открытых (за тыщу) багов хотелось бы, чтобы список заголовков был максимально информативным
Я, например, как последняя зануда не люблю плодить дубли и каждый раз ищу не запостил ли мой баг уже кто-то до меня, дык заголовки типа "Некорректное завершение обработки запроса" или "Неверный результат вычисления итоговой суммы" приходится открывать и смотреть детали, что ж там некорректного, тк у меня запрос тоже некорректно завершился : 500 ошибкой, а у предыдущего тестировщика некорректность была в том, что не та страничка после отсылки отобразилась. это неудобно
и я уже давно не задумываюсь о четкости заголовков у багов и тем более производительность от внятного их описания у меня никак не падает, оно само уже пишется ясно-понятно, на автомате. поэтому мне кажется лучше бы приучаться с малолетства писать заголовки четко,один раз привыкнешь и вопрос закрыт
Бог с вами. Никакого обсуждения багреда! Хорошо, что сервис появился и я вижу у него большое будущее. Я рад за Олю и желаю ей успехов и дальше! Идея и правда нова и интересна!
УдалитьБагред был всего лишь поводом для холивара, вот и всё )
Таня, условие было о том, что "устраивает всех участников процесса" :)
Удалитьнене, я про то, что даже если всех-всех на этом устраивает "ну как-нибудь", то все равно очень полезно завести себе привычку писать четко. Приучилась один раз и на всех проектах молодец на автомате. А критерии "четкости" в "этих самых методичках" давно прописаны и не особо сложны :что? где? когда? и избегать двусмысленности
Удалитьа что не так с словами -не корректо-не работает- и прочие?
Удалитьи почему их нельзч использовать?
и для кого существует блин краткое описание бага?
краткое, описание - для того, кто собирается этот баг процессить: верифаить, фиксить и т.д. а для тех, кто по разным причинам работает со списком багов, состоящим из заголовков (менеджер, другие тестировщики в команде, любой чел который делает выгрузку багов в репорт) -заголовок "некорректно завершается репорт" -это ящик Пандоры, выше приводила свой пример почему
УдалитьМне кажется, что умение джуниора правильно заводить баг зависит того кто учит и от того кто учится заводить баг. Ведь усвоить формулу "Что где когда" достаточно просто.
ОтветитьУдалитьА значит проблема только в коммуникациях реципиента и передатчика.
Один не умеет учить, а второй не хочет учиться.
Но, как педагог, я могу сказать, что ученик виноват лишь в малом проценте случаев.
Остальное - косяк преподавателя.
Кстать, если есть желание и энтузиазм выссказаться, то было бы круто почитать мнение педагога об ошибках в обучении начинающих тестировщиков, как со стороны преподавателя, так и со стороны учеников
УдалитьЕще момент, к пунктам Андрея. Через год, и даже через два после заведения бага - должно быть понятно в чём есть или была причина его заведения. Это должно пониматься из его заголовка + описания + доп. материалам к багу.
ОтветитьУдалитьPS: желательно Заголовок должен быть понятен всем участникам процесса, а не только программистам и ПМ, чтоб другие личности дубли не плодили.