Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 53
Есть ещё разростание бага когда делают новый функционал, и в результате тестирования нового функционала находят баг в старом функционале, но вешают на задачу нового функционала. И пошло поехало.
Тут, на мой взгляд, когда находится баг в старом функционале, надо его написать в виде отдельного репорта. А при чьей-либо попытке задубликатить его на какую-то задачу нужно подходить к этому человеку, смотреть на него с укоризной и говорить неприятные слова.
Извините, не нашёл как отправить личное сообщение.
Знаю, что зануда, но всё-таки
Знаю, что зануда, но всё-таки
разрАстание
«2. Недофикс»
А чем плох статус «переоткрыт»? Баг дофикшен не до конца — так и написать в комментарий, что вторая кнопка не появилась.
А чем плох статус «переоткрыт»? Баг дофикшен не до конца — так и написать в комментарий, что вторая кнопка не появилась.
В простейшей ситуации это хорошо, баги не плодятся. Но если оригинальный баг был, к примеру, блокером (к примеру, кнопка добавления пользователя отсутствовала вообще), то после фикса он вполне может стать менее серьезным (критикал или мажор) — кнопка все-таки появилась, но не во всех местах. Получается, переоткрывать блокер некрасиво. Ну, можно снизить серьезность (severity) и потом переоткрыть, да, согласен.
Тут еще имеет место забота о человеке, который занимается первичной сортировкой багов (пофиксить / отложить / не фиксить). Если баг с длинной историей переоткрытий, и каждый раз в него вставлялись новые скриншоты, аттачились новые логи и указывалась информация о той инсталляции, где он был найден, то найти нужные скриншоты в жире, например, это трата времени. А поскольку сортировкой багов занимается в основном начальство, оно требует повышенного к себе внимания и заботы. Свежий баг ему читать легче.
Почему некрасиво?
«На машине нет колес» — «пофикшено, поставили 2 колеса». Какой же тут фикс? Колес (комплекта) как не было, так и нет.
Тем более, закрываться же баг должен тестером?
«На машине нет колес» — «пофикшено, поставили 2 колеса». Какой же тут фикс? Колес (комплекта) как не было, так и нет.
Тем более, закрываться же баг должен тестером?
Я с вами вот как раз согласен (сам разработчик).
Насчет второго пункта: во многих трекерах есть статус «fixed» (ставит разработчик, мол, починил) и «verified» (ставит тестер, мол, проверил — действительно исправлено).
Насчет второго пункта: во многих трекерах есть статус «fixed» (ставит разработчик, мол, починил) и «verified» (ставит тестер, мол, проверил — действительно исправлено).
А, ну это просто разные инструменты используются.
У нас своя среда со своими заданиями, которые могут быть на фикс, на тестирование и соединяются в цепочки.
Т.е. создан task на проблему, ты работаешь над ней, потом отдаешь тестировщикам, они создают дочерний task на тестирование, и ты не можешь свой закрыть, пока дочерний не закрыт. Они тестируют, находят проблемы — прикрепляют их как дочерние task'и к task'у на тестирование и т.д.
У нас своя среда со своими заданиями, которые могут быть на фикс, на тестирование и соединяются в цепочки.
Т.е. создан task на проблему, ты работаешь над ней, потом отдаешь тестировщикам, они создают дочерний task на тестирование, и ты не можешь свой закрыть, пока дочерний не закрыт. Они тестируют, находят проблемы — прикрепляют их как дочерние task'и к task'у на тестирование и т.д.
Для багов-фич хочется некоторой «атомарности». Простые задачи проще для разработчиков, проще для тестеров, проще для систем контроля версий, проще для code review, проще для CI. Но если слишком усердствовать с дроблением задач на маленькие и простые подзадачи то становится неудобно с этим работать уже в баг трекере. В процессе работы коллектив приходит(если у коллектива есть возможность что-то менять) к некоторому оптимальному балансу. И получается что в зависимости от команды, стиля работы, используемых инструментов и прочих обстоятельств искомый баланс может быть на разном уровне.
Пример с «недофиксом» можно рассматривать как неявное объединение двух задач. Иногда удобно переоткрыть. Но иногда удобно закрыть тикет сделанный частично, отправив написанный и проверенный код дальше по процессу и открыть еще один тикет для работы над оставшейся частью.
Пример с «недофиксом» можно рассматривать как неявное объединение двух задач. Иногда удобно переоткрыть. Но иногда удобно закрыть тикет сделанный частично, отправив написанный и проверенный код дальше по процессу и открыть еще один тикет для работы над оставшейся частью.
Верифаили, верифаили да не доверифаили.
Тьху, неруси :-D
прочитала.
ичо?
ичо?
Поясню.
Почему вместо того чтобы поработать над командным взаимодействием возник этот псто?
Послушайте хотяб старый добрый Стратоплан, или дядю Славу и дядю Сашу по отдельности…
Почему вместо того чтобы поработать над командным взаимодействием возник этот псто?
Послушайте хотяб старый добрый Стратоплан, или дядю Славу и дядю Сашу по отдельности…
А вы не в одной компании с топикстартером работаете?
Тогда ваш коммент стал бы более понятен :)
Тогда ваш коммент стал бы более понятен :)
что именно непонятно?
Я бы сказал, что бывают ситуации, когда даже если тестировщик дойдет до разработчика и они пол часа «поработают над командным взаимодействием», все равно каждый остается при своем мнении.
В этой ситуации можно или эскалировать вопрос руководителю, или нажать пару кнопок в трекере.
Во втором случае вопрос все равно имеет шанс дойти до руководителя, но этот шанс меньше.
Т.е. по общему количеству, будет сэкономлено время тестировщика, разаработчика и руководителя.
В том числе и нервы, возможно.
В этой ситуации можно или эскалировать вопрос руководителю, или нажать пару кнопок в трекере.
Во втором случае вопрос все равно имеет шанс дойти до руководителя, но этот шанс меньше.
Т.е. по общему количеству, будет сэкономлено время тестировщика, разаработчика и руководителя.
В том числе и нервы, возможно.
«все равно каждый остается при своем мнении.» значит отсидели полчаса, а не поработали. за полчаса такие вещи не исправляются)
«Т.е. будет сэкономлено время тестировщика, разаработчика и руководителя.
В том числе и нервы, возможно. » ну да)Судя по посту, нервов очень много сэкономлено)только спокойные и удовлетворенные работой люди их пишут)
Если я Вас правильно поняла, то да, соглашусь. Каждый work-чит как он хочит) Если принято делать проблемы из статуса в багтрекере, то и ок) Но есть более эффективные способы ;))
«Т.е. будет сэкономлено время тестировщика, разаработчика и руководителя.
В том числе и нервы, возможно. » ну да)Судя по посту, нервов очень много сэкономлено)только спокойные и удовлетворенные работой люди их пишут)
Если я Вас правильно поняла, то да, соглашусь. Каждый work-чит как он хочит) Если принято делать проблемы из статуса в багтрекере, то и ок) Но есть более эффективные способы ;))
Послушаю, спасибо. Я согласен, что если в команде налажено взаимодействие, то бюрократии меньше, особенно если члены команды находятся рядом друг с другом, и можно прийти и лично поговорить. Но ситуации бывают разными, а жестокая бюрократия помогает в жестоких ситуациях :)
«Сам инвалид» — это не бюрократия и рабочий кейс, а какое-то хамство. В одной команде сработает, в другой можно выхватить.
Бюрократия должна работать на процесс, а не быть бичом или регламентом ради регламента.
А взаимодействие само собой не наладится. Вам, позвольте насоветую, не посты такие абсолютно без выводов строчить, а сделать первый шаг и начать разговаривать с разработкой.
По порядку — решается одинаково.
1. Подойти поинтересоваться почему инвалид
2. Подойти, поинтересоваться почему не пофиксаны кейсы. Переоткрыть с аргументацией баг, написать новый.какая блин разница
3. просто взять и протестировать. и подойти поинтересоваться, в чем фикс
4. и 5. вообще какая разница что это? на что аффектит что вы сейчас тестируете-баг или фичу?
брать и тестировать. если непонятно-подойти и поинтересоваться про что это
6. подойти и договориться о порядке фиксов.
И поправлюсь. Дядю Сашу и дядю Славу слушать всей командой!))
Бюрократия должна работать на процесс, а не быть бичом или регламентом ради регламента.
А взаимодействие само собой не наладится. Вам, позвольте насоветую, не посты такие абсолютно без выводов строчить, а сделать первый шаг и начать разговаривать с разработкой.
По порядку — решается одинаково.
1. Подойти поинтересоваться почему инвалид
2. Подойти, поинтересоваться почему не пофиксаны кейсы. Переоткрыть с аргументацией баг, написать новый.какая блин разница
3. просто взять и протестировать. и подойти поинтересоваться, в чем фикс
4. и 5. вообще какая разница что это? на что аффектит что вы сейчас тестируете-баг или фичу?
брать и тестировать. если непонятно-подойти и поинтересоваться про что это
6. подойти и договориться о порядке фиксов.
И поправлюсь. Дядю Сашу и дядю Славу слушать всей командой!))
Всячески согласен, что обcуждать спорные ситуации лучше вживую — лицом к лицу, по телефону, скайпу и так далее. Ни в коем случае не нужно сужать канал общения до комментов и статусов багтрекера.
Всячески согласен, что бюрократия должна работать на процесс, а процесс на результат
А вот про отуствие разницы между багом и фичей не соглашусь. Само по себе оно неважно, конечно, как в багтрекере сущность обозвана. Различие между фичей и багом — как раз в том, какие процессы накручены вокруг этих понятий, а процессы эти могут сильно отличаться.
Например: если один общий продукт разрабатывают команды из пяти городов, едва ли кто-то может удержать в голове все нюансы работы продукта. Типичная практика в таких случаях — хотя бы сообщать всем о планируемых и/или внедренных фичах: вдруг кто-то знает, чем неожиданным это слово отзовется в будущем, и вовремя подскажет. [Бывают и более сложные процессы для совместной работы с фичами, см например пост]
Для фич такие процессы можут работать, а для багов заведомо нежизнеспособны. Отсюда и разница между багом и фичей, и важность правильного названия в трекере, если с этого названия стартует остальной процесс.
Всячески согласен, что бюрократия должна работать на процесс, а процесс на результат
А вот про отуствие разницы между багом и фичей не соглашусь. Само по себе оно неважно, конечно, как в багтрекере сущность обозвана. Различие между фичей и багом — как раз в том, какие процессы накручены вокруг этих понятий, а процессы эти могут сильно отличаться.
Например: если один общий продукт разрабатывают команды из пяти городов, едва ли кто-то может удержать в голове все нюансы работы продукта. Типичная практика в таких случаях — хотя бы сообщать всем о планируемых и/или внедренных фичах: вдруг кто-то знает, чем неожиданным это слово отзовется в будущем, и вовремя подскажет. [Бывают и более сложные процессы для совместной работы с фичами, см например пост]
Для фич такие процессы можут работать, а для багов заведомо нежизнеспособны. Отсюда и разница между багом и фичей, и важность правильного названия в трекере, если с этого названия стартует остальной процесс.
Тоже соглашусь с каждым словом.
Так и написала-бюрократия должна работать на процесс.
Если название баг или фича-только формальность, не аффектит ни на планирование, ни на жизненный цикл задачи, ни на приоритет-не о чем разговаривать.
И еще важный момент. Если регламент не прозрачный, если разрабы не понимают эти процессы и зачем эта бюрократия нужна — хоть кол на голове чеши, не будут следовать.
И снова надо встретиться и объяснить ЗАЧЕМ это нужно.
Процессу важно быть прозрачным.
Так и написала-бюрократия должна работать на процесс.
Если название баг или фича-только формальность, не аффектит ни на планирование, ни на жизненный цикл задачи, ни на приоритет-не о чем разговаривать.
И еще важный момент. Если регламент не прозрачный, если разрабы не понимают эти процессы и зачем эта бюрократия нужна — хоть кол на голове чеши, не будут следовать.
И снова надо встретиться и объяснить ЗАЧЕМ это нужно.
Процессу важно быть прозрачным.
Спасибо, что прочитали!
Верифаить — WAT? Верифицировать, уж если на то пошло. Хотя это пошло.
В этом случае полезным может быть комментарий типа «Дайте информацию, как верифаить, или поверифайте, пожалуйста, сами». Такая фраза, в сочетании с назначением бага на разработчика, работает лучше, чем просто «Дайте информацию, как верифаить».
Почему не разработать обязательную к исполнению внутреннюю инструкцию, которая требует при передаче «дела» разработчиком тестировщику описывать конкретные пункты (как у нас сделали)
1) в чем была проблема
2) как пофикшено
3) изменения с внутренней точки зрения
4) изменения с пользовательской т.з.
5) возможные риски
6) видеозапись-демка, которая показывает, что фикс есть, и все работает, как надо
7) описание в деталях, как проверять (дополнительное тестирование по необычным usecase'ам тестировщики разработают сами).
К сожалению (а может и к счастью), обязательные к исполнению внутренние инструкции не очень-то работают, если человек не понимает их смысла или, еще хуже, не согласен с ними. А если понимает и согласен, то и инструкция, в общем, не нужна.
Единственный вариант, когда она может пригодиться, имхо, — чтоб ознакомить новичка с принятыми в компании/проекте процессами. И ответить на его комментарии/вопросы по этому поводу.
Как фиксация каких-то договоренностей подобная инструкция, может, и полезна, но стоит понимать, что в реальной жизни
— инструкция будет нарушаться ежедневно, просто из соображений здравого смысла
— смысл и дух инструкции нужно будет неоднократно разъяснять всем вокруг
— в какой-то момент (и зачастую довольно скоро) инструкция начнет устаревать и не соответствовать жизни, а обновлять ее никто не будет
В общем, фиксация правил и договоренностей — это полезно, но без налаженного взаимодействия, общения и взаимопонимания она ничем не поможет.
Так что нужно налаживать это самое взаимодействие и взаимопонимание, а инструкции после уже приложатся если все же сильно нужны окажутся.
Единственный вариант, когда она может пригодиться, имхо, — чтоб ознакомить новичка с принятыми в компании/проекте процессами. И ответить на его комментарии/вопросы по этому поводу.
Как фиксация каких-то договоренностей подобная инструкция, может, и полезна, но стоит понимать, что в реальной жизни
— инструкция будет нарушаться ежедневно, просто из соображений здравого смысла
— смысл и дух инструкции нужно будет неоднократно разъяснять всем вокруг
— в какой-то момент (и зачастую довольно скоро) инструкция начнет устаревать и не соответствовать жизни, а обновлять ее никто не будет
В общем, фиксация правил и договоренностей — это полезно, но без налаженного взаимодействия, общения и взаимопонимания она ничем не поможет.
Так что нужно налаживать это самое взаимодействие и взаимопонимание, а инструкции после уже приложатся если все же сильно нужны окажутся.
Я как-то поняла важную вещь, изменившую взгляд на всю эту бюрократию.
Разрабы аморально работают в трекере, ПОТОМУ ЧТО ОНИ НЕ ЗНАЮТ КАК!!!
Подход к таск-трекингу может быть абсолютно разный. Но часто попадаются специалисты, которые элементарно не умеют заполнять тикеты, не понимают что такое приоритет, что такое компонент.
У меня тогда шок наступил. Столько сил было потрачено на все эти «Сам инвалид», а причина такая простая…
Инструкция помогает, если ее например преподнести как DoD задачи, или если например привести кейсы важности того или иного случая.
Т.е. все то же самое — объяснить и «продать» регламент. Хорошо бы еще, если бы менеджеры приняли этот регламент и начали им пользоваться. Если и им он поперек горла, надо менять правила… возможно и правда не важно баг или фича.
Разрабы аморально работают в трекере, ПОТОМУ ЧТО ОНИ НЕ ЗНАЮТ КАК!!!
Подход к таск-трекингу может быть абсолютно разный. Но часто попадаются специалисты, которые элементарно не умеют заполнять тикеты, не понимают что такое приоритет, что такое компонент.
У меня тогда шок наступил. Столько сил было потрачено на все эти «Сам инвалид», а причина такая простая…
Инструкция помогает, если ее например преподнести как DoD задачи, или если например привести кейсы важности того или иного случая.
Т.е. все то же самое — объяснить и «продать» регламент. Хорошо бы еще, если бы менеджеры приняли этот регламент и начали им пользоваться. Если и им он поперек горла, надо менять правила… возможно и правда не важно баг или фича.
Разрабы аморально работают в трекере, ПОТОМУ ЧТО ОНИ НЕ ЗНАЮТ КАК!!!
Категорически согласен!
Но часто попадаются специалисты, которые элементарно не умеют заполнять тикеты, не понимают что такое приоритет, что такое компонент.
Не могли бы вы хотя бы кратко описать правильное понимание полей приоритет и компонет?
— инструкция будет нарушаться ежедневно, просто из соображений здравого смысла
Ну, значит, нарушитель будет лишаться квартальной премии. Проблема-то?
— в какой-то момент (и зачастую довольно скоро) инструкция начнет устаревать и не соответствовать жизни, а обновлять ее никто не будет
Я вас умоляю. Пол-страницы текста обновить несложно.
В общем, фиксация правил и договоренностей — это полезно, но без налаженного взаимодействия, общения и взаимопонимания она ничем не поможет.
Извините, но то, что вы описываете, называется «разгильдяйство». Т.е. в коллективе нет дисциплины. Это проблема совсем иного плана.
У нас, например, решение об упомянутой инструкции принималось коллективно начальником отдела тестирования и самыми крупными тимлидами, которые довели инструкцию до нас, разработчиков попроще. Естественно, ВСЕ поля заполняются только если процесс тестирования сложен. Есть обязательные поля, есть «для сложных случаев». Такая разбивка как раз и сделана исходя «из здравого смысла». Но раз и навсегда, а не так, что каждый сам делает, как хочет. Никому в голову не придет нарушать, просто потому что это не культурно — все равно, извините, что накидать окурков посреди чистого опен-спейса.
— инструкция будет нарушаться ежедневно, просто из соображений здравого смысла
Ну, значит, нарушитель будет лишаться квартальной премии. Проблема-то?
Карать за здравый смысл очень разумная практика
Пол-страницы текста обновить несложно.
Обновить мало. Надо еще чтоб все причастные перечитали, поняли что изменилось, зачем изменилось и так далее. Ну и момент, когда уже пора обновлять, надо не упустить. И поди еще обновлять может только строго ограниченный круг лиц?
Впрочем, если вы видите свою задачу как просто точное исполнение записанной инструкции (отступление от которой бьет по карману и прочим нежным местам), то менять ее вряд ли когда понадобится: никто просто не скажет, что что-то в ней не важно, не нужно или устарело — этак и недисциплинированным можно прослыть.
А вообще, формализм и дисциплина — это немножко разные вещи. Мне так кажется.
Карать за здравый смысл очень разумная практика
Более чем. «Здравый смысл» у каждого свой. Вон у того парня проехать на красный свет — здравый смысл. А чо, никого ж нет.
Такие ситуации, когда что-то делается опционально, должны вносится в инструкцию. Да, любой «здравый смысл» должен быть описан. В данном конкретном случае — если репликация бага простая, не нужно, например, вставлять ролик с записью. Это все оговаривается инструкцией. Что не оговаривается — делается обязательно.
Обновить мало. Надо еще чтоб все причастные перечитали, поняли что изменилось, зачем изменилось и так далее
В чем проблема прочитать? Доводим то тимлидов, они делают в тот же день пятиминутную летучку и объясняют остальным, что поменялось.
Ну и момент, когда уже пора обновлять, надо не упустить. И поди еще обновлять может только строго ограниченный круг лиц?
Это забота начальника отдела тестирования, начальника разработки, ну и может, крупнейших тимлидов.
Впрочем, если вы видите свою задачу как просто точное исполнение записанной инструкции (отступление от которой бьет по карману и прочим нежным местам), то менять ее вряд ли когда понадобится: никто просто не скажет, что что-то в ней не важно, не нужно или устарело — этак и недисциплинированным можно прослыть.
О, какой знакомый разговор. Прям как в жизни, право слово. Вон тот закон нам кажется дурацким — исполнять не будем.
Не, почему ж прослыть недисциплинированным? Наоборот — нашел косяк, хоть в коде, хоть в инструкции, проявил инициативу — молодец.
Принцип простой:
1)Инструкция выполняется. Точно.
2)ВСЕГДА
3)Да, даже если она дурацкая
4)Если она дурацкая — добиваемся внесения изменений, а не сидим на попе ровно, обсуждая в курилке «начальник — дурак».
А вообще, формализм и дисциплина — это немножко разные вещи. Мне так кажется.
Дисциплина — следование правилам. Формализм — следование дурацким правилам без попыток их отменить/изменить, кмк.
Дисциплина — следование правилам. Формализм — следование дурацким правилам без попыток их отменить/изменить, кмк.
Перефразируя Черчилля, можно сказать, что бюрократия — очень плохая система ведения дел, проблема в том, что все остальные — еще хуже.
Здравый смысл у каждого свой — и это прекрасно. Именно из того, что люди неодинаковы и получаются команды, а не набор взаимозаменяемых элементов.
Инструкции могут работать, пока их немного, пока они просты, как инструкция по заполнению багрепорта, которая по сути своей — чеклист, позволяющий не забыть, какие данные надо указать.
Если инструкций много, а деятельность сложна — уже возникают неявные конфликты, одна инструкция становится приоритетней другой в зависимости от ситуации, да и просто забываются.
Можно конечно лечить созданием метаинструкций по пользованию и управлению инструкциями, но едва ли это то, к чему кто-то правда стремится.
Слово «всегда» вообще выглядит неуместным, когда речь идет о сколько-то интеллектуальной человеческой деятельности. Я понимаю, что программистам, тестировщикам и математикам интересней работать с крайними точками — сам такой. Но люди не ПО, и большинство из них находится где-то между крайними точками, на красный свет не едут, но пустую дорогу перейти не по пешеходному переходу могут. И это вполне нормально. Разумнее это понимать и использовать, чем пытаться устранить, особенно в нашей обычно не шибко угрожающей жизни деятельности.
Кстати, точное следование инструкциям, даже в высшей степени разумным, называется «итальянская забастовка».
Потому что ни одна инструкция не содержит весь необходимый контекст и дух деятельности, и редкая инструкция поясняет, зачем и почему нужно делать именно так.
Так что от общения, взаимодействия и взаимопонимания никуда не деться. Во всяком случае инструкциями их не заменишь.
Инструкции могут работать, пока их немного, пока они просты, как инструкция по заполнению багрепорта, которая по сути своей — чеклист, позволяющий не забыть, какие данные надо указать.
Если инструкций много, а деятельность сложна — уже возникают неявные конфликты, одна инструкция становится приоритетней другой в зависимости от ситуации, да и просто забываются.
Можно конечно лечить созданием метаинструкций по пользованию и управлению инструкциями, но едва ли это то, к чему кто-то правда стремится.
Слово «всегда» вообще выглядит неуместным, когда речь идет о сколько-то интеллектуальной человеческой деятельности. Я понимаю, что программистам, тестировщикам и математикам интересней работать с крайними точками — сам такой. Но люди не ПО, и большинство из них находится где-то между крайними точками, на красный свет не едут, но пустую дорогу перейти не по пешеходному переходу могут. И это вполне нормально. Разумнее это понимать и использовать, чем пытаться устранить, особенно в нашей обычно не шибко угрожающей жизни деятельности.
Кстати, точное следование инструкциям, даже в высшей степени разумным, называется «итальянская забастовка».
Потому что ни одна инструкция не содержит весь необходимый контекст и дух деятельности, и редкая инструкция поясняет, зачем и почему нужно делать именно так.
Так что от общения, взаимодействия и взаимопонимания никуда не деться. Во всяком случае инструкциями их не заменишь.
Здравый смысл у каждого свой — и это прекрасно. Именно из того, что люди неодинаковы и получаются команды, а не набор взаимозаменяемых элементов.
Здесь обычная ошибка — вы путаете интеллектуальный творческий процесс и рутину. Какими бы интеллектуальными и самостоятельными мы ни были, мы все равно все моем руки перед едой и вытираем ноги перед входом. Обязательно. И отмазка «я не буду вытирать ноги, потому что я личность» не к месту. Команда получается из разносторонних людей, т.к. они могут работать с разными проблемами, по-разному смотреть на них. А не потому, что часть команды — обязательные люди, а часть — как бог на душу положит.
Тут все просто — либо есть правила, и они соблюдаются, либо мы наслаждаемся тем, как тестеры и разрабы играют тасками в пинг-понг. Ну, кому что нравится.
Инструкции могут работать, пока их немного, пока они просты, как инструкция по заполнению багрепорта, которая по сути своей — чеклист, позволяющий не забыть, какие данные надо указать
Я говорил именно об этой инструкции.
Слово «всегда» вообще выглядит неуместным, когда речь идет о сколько-то интеллектуальной человеческой деятельности… и далее по тексту
См. выше тезис номер 1 про «я — личность». Заполнение тасков — интеллектуальная, но не творческая деятельность.
Кстати, точное следование инструкциям, даже в высшей степени разумным, называется «итальянская забастовка».
Не совсем так. Итальянская забастовка — это когда делается только то, что есть в инструкции, и на грамм больше. Обязанность следовать инструкции, описывающий минимум, не итальянская забастовка.
Я говорил именно об этой инструкции.
Выходит, мы говорили о разных вещах
Извините, но диалог начался с моего сообщения
http://habrahabr.ru/post/241955/#comment_8100713
http://habrahabr.ru/post/241955/#comment_8100713
Если документация к продукту и конечный продукт не соответствуют друг другу, то это либо баг в продукте, либо баг в документации.
Раз уж после обсуждения решили, что в продукте бага нет, значит баг в документации. Следовательно нужно в багтрекере отправить блейм/баг/репорт на документацию, дабы кто-то взялся и переписал ее.
Раз уж после обсуждения решили, что в продукте бага нет, значит баг в документации. Следовательно нужно в багтрекере отправить блейм/баг/репорт на документацию, дабы кто-то взялся и переписал ее.
Если пинг-понг массовый, то его обычно можно зарулить организацией встречи/обсуждения, или померить его средствами трекера, чтобы понять насколько это массовая проблема (иногда оказывается, что страдают этим вполне конкретные люди).
Недофикс в описанном кейсе вообще не возник бы, поставь тестировщик сразу два бага, а не объединяй он кучку в один репорт. Ну или если уж совсем невмоготу, то ставить в графе «ожидаемый результат» однозначную трактовку, несоответствие которой при проверке даст четкое понимание разрабочтику почему ему вернули ошибку на доработку. (Кстати количество таких возвратов тоже можно мерить, если массово).
Чтобы разработчики (менеджеры, админы, дирекция и т.д.) ставили понятные баги, достаточно при постановке тикета сделать минимальный шаблон для всех (тестировщикам жизнь упростит, а ксеносам путь истинный укажет), а также рядом поместить ссылочку на FAQ, если вдруг постановщик не в курсе происходящего:) Достаточно простого:
Нужно быть особо одарённым, чтобы стереть шаблон и написать отсебятину, или в рамках шаблона написать что-то запредельно непонятное, чтобы не удалось самостоятельно проверить исправление:)
Закрывать баги разработчикам вообще не рекомендуется, достаточно правами это ограничить, или настроить фильтр с выдачей багов, которые закрыли сами разработчики, для анализа менеджером/лидом/и т.д.
Трансформация бага в feature request вполне распространённая практика, хорошо работает в том случае, когда тестировщик (или другой участник) в состоянии сформулировать свою идею шире, чем просто «хочу-чтобы-было» и подкрепить аргументами.
Недофикс в описанном кейсе вообще не возник бы, поставь тестировщик сразу два бага, а не объединяй он кучку в один репорт. Ну или если уж совсем невмоготу, то ставить в графе «ожидаемый результат» однозначную трактовку, несоответствие которой при проверке даст четкое понимание разрабочтику почему ему вернули ошибку на доработку. (Кстати количество таких возвратов тоже можно мерить, если массово).
Чтобы разработчики (менеджеры, админы, дирекция и т.д.) ставили понятные баги, достаточно при постановке тикета сделать минимальный шаблон для всех (тестировщикам жизнь упростит, а ксеносам путь истинный укажет), а также рядом поместить ссылочку на FAQ, если вдруг постановщик не в курсе происходящего:) Достаточно простого:
Нужно быть особо одарённым, чтобы стереть шаблон и написать отсебятину, или в рамках шаблона написать что-то запредельно непонятное, чтобы не удалось самостоятельно проверить исправление:)
Закрывать баги разработчикам вообще не рекомендуется, достаточно правами это ограничить, или настроить фильтр с выдачей багов, которые закрыли сами разработчики, для анализа менеджером/лидом/и т.д.
Трансформация бага в feature request вполне распространённая практика, хорошо работает в том случае, когда тестировщик (или другой участник) в состоянии сформулировать свою идею шире, чем просто «хочу-чтобы-было» и подкрепить аргументами.
Очень сложно разработчикам в наше время использовать простые русские слова вместо англоязычной фиговины.
Это я про «верифаить», который вполне нормально на русском звучит как «проверить».
Конечно, всем все понятно, но блин. Ваш чекинг и верифаинг это что-то.
Это я про «верифаить», который вполне нормально на русском звучит как «проверить».
Конечно, всем все понятно, но блин. Ваш чекинг и верифаинг это что-то.
Это не проверить в данном контексте, это — подтвердить.
Был СССР, была своя русская терминология.
Отладка.
Забой (backspace кто не в курсе).
Математический адрес.
И так далее. Что-то нам осталось с тех пор — переменная, массив, отладка и т.д. А то, что появилось позже, особенно связанное с процессом разработки ПО — калька. Ныне основным языком является английский, терминология английская. Это печально, но вот так есть.
Конечно, всем все понятно, но блин. Ваш чекинг и верифаинг это что-то.
Был СССР, была своя русская терминология.
Отладка.
Забой (backspace кто не в курсе).
Математический адрес.
И так далее. Что-то нам осталось с тех пор — переменная, массив, отладка и т.д. А то, что появилось позже, особенно связанное с процессом разработки ПО — калька. Ныне основным языком является английский, терминология английская. Это печально, но вот так есть.
Слово «Верификация» в русском языке есть уж минимум полсотни лет (а скорее всего и больше) и корни у него латинские, а не англоязычные.
>Это печально, но вот так есть.
Язык свой надо лучше знать, тогда вместо калькирования всех незнакомых слов внезапно окажется, что у половины из них есть вполне благозвучные и подходящие аналоги.
А «верифаить», на мой взгляд — это исключительно от безграмотности, а не от того, что много ИТ-терминов кальки, с чем я и не спорю…
>Это печально, но вот так есть.
Язык свой надо лучше знать, тогда вместо калькирования всех незнакомых слов внезапно окажется, что у половины из них есть вполне благозвучные и подходящие аналоги.
А «верифаить», на мой взгляд — это исключительно от безграмотности, а не от того, что много ИТ-терминов кальки, с чем я и не спорю…
Слово «Верификация» в русском языке есть уж минимум полсотни лет (а скорее всего и больше) и корни у него латинские, а не англоязычные.
Так lexx2real именно о «верифаить» сказал.
Язык свой надо лучше знать, тогда вместо калькирования всех незнакомых слов внезапно окажется, что у половины из них есть вполне благозвучные и подходящие аналоги.
У половины. Именно.
А «верифаить», на мой взгляд — это исключительно от безграмотности, а не от того, что много ИТ-терминов кальки, с чем я и не спорю…
Не обязательно от безграмотности. Тут вопрос привычки тоже играет большую роль. Как я указывал выше, основной язык в IT сфере — английский, множество статей, документации, обсуждения на форумах ведутся на английском. Поневоле какие-то слова «впечатываются». Кто-то, как я, например, работает к тому же в англоязычном коллективе, это еще сильнее усугубляет проблему.
Плюс, что еще важнее — у некоторых слов есть _коннотация_. И это очень, очень важно. Например, то же «верифаить», являясь по сути безграмотной калькой, тянет за собой незримый абзац смысла — о процессе тестирования, о том, как кооперируются разработчики и тестировщики и пр. А слово «подтвердить», являясь точным аналогом, тем не менее коннотации не имеет. Безграмотное «поверифаить исправление ошибки» не то же самое что и «подтвердить исправление ошибки», хотя перевод-то точный. Да даже «ошибка» и «баг» не одно и то же. (коннотация разная).
> У половины. Именно.
А остальное — это развитие языка. Нет языков, в которых не было бы заимствований и изменении слов.
> Безграмотное «поверифаить исправление ошибки» не то же самое что и «подтвердить исправление ошибки», хотя перевод-то точный.
Можно было сказать, например, «верифицировать исправление ошибки» (== доказать ее исправление), если подтвердить/проверить не нравится. Хотя, в контексте этой фразы я большой разницы не вижу. В любом случае подразумевается некоторая процедура верификации/проверки исправления.
> Да даже «ошибка» и «баг» не одно и то же. (коннотация разная).
А тут соглашусь. «Ошибка» — гораздо более узкое и конкретное понятие.
А остальное — это развитие языка. Нет языков, в которых не было бы заимствований и изменении слов.
> Безграмотное «поверифаить исправление ошибки» не то же самое что и «подтвердить исправление ошибки», хотя перевод-то точный.
Можно было сказать, например, «верифицировать исправление ошибки» (== доказать ее исправление), если подтвердить/проверить не нравится. Хотя, в контексте этой фразы я большой разницы не вижу. В любом случае подразумевается некоторая процедура верификации/проверки исправления.
> Да даже «ошибка» и «баг» не одно и то же. (коннотация разная).
А тут соглашусь. «Ошибка» — гораздо более узкое и конкретное понятие.
«верифицировать исправление ошибки» (== доказать ее исправление),
«верифицировать» != «доказать» в данном контексте. Доказать могу я, разработчик. Мол, смотри, раньше делали так и так и получали AV, теперь — все чисто, а в коде это выглядит вот так и так. Таки мобразом, я доказал исправление ошибки. (да и слово «исправление» можетозначать незаврешенный процес — в таком случае я докажу, что я исправлял ошибку, т.е. доказал исправление, т.к. «исправление» имеет 2 смысла) А тестировщик может verify, т.е. подтвердить, что это действительно так, что процесс завершен.
«verify» имеет коннотацию «провести собственное исследование-тестирование и подтвердить, что ошибка исправлена», а «подтвердить исправление» — нет. По крайне мере, мое чувство языка мне так подсказывает.
А тут соглашусь. «Ошибка» — гораздо более узкое и конкретное понятие.
Мне, напротив, кажется, что «ошибка» — более широкое понятие. Например, опечатка в сообщении — ошибка, а отказ в обслуживании — результат bug'а. (он же — логическая ошибка, например).
> «верифицировать» != «доказать» в данном контексте. Доказать могу я, разработчик.
Тестировщик тоже может доказать в смысле, что раньше воспроизводилось, а сейчас нет.
Доказательство от программиста может быть другое по сути, только если это результат формальной верификации, а это зверь очень редкий в дикой природе.
> Мне, напротив, кажется, что «ошибка» — более широкое понятие.
Не каждый баг — это ошибка программиста.
У меня были случаи, когда приложения работали некорректно (или вообще не компилировались) из за ошибок в компиляторах. Был ли это баг моего приложения? С точки зрения внешнего пользователя — думаю да, но была ли при этом ошибка в программе?
Баг, на мой взгляд, включает в себя еще и проблемы окружения, когда ошибка есть, но находится за пределами нашей области возможного воздействия (если в определенной версии GCC есть ошибка и этот GCC у пользователя, то я не могу посоветовать ему сменить компилятор) и ради исправления которого придется городить обходной путь (Workaround).
P.S. А чем опечатка не баг пользовательского интерфейса?
Тестировщик тоже может доказать в смысле, что раньше воспроизводилось, а сейчас нет.
Доказательство от программиста может быть другое по сути, только если это результат формальной верификации, а это зверь очень редкий в дикой природе.
> Мне, напротив, кажется, что «ошибка» — более широкое понятие.
Не каждый баг — это ошибка программиста.
У меня были случаи, когда приложения работали некорректно (или вообще не компилировались) из за ошибок в компиляторах. Был ли это баг моего приложения? С точки зрения внешнего пользователя — думаю да, но была ли при этом ошибка в программе?
Баг, на мой взгляд, включает в себя еще и проблемы окружения, когда ошибка есть, но находится за пределами нашей области возможного воздействия (если в определенной версии GCC есть ошибка и этот GCC у пользователя, то я не могу посоветовать ему сменить компилятор) и ради исправления которого придется городить обходной путь (Workaround).
P.S. А чем опечатка не баг пользовательского интерфейса?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Бюрократия баг-трекера