Какой франшизы это филиал?)) это конференция, которая родилась в Новосибирске и которой аналогов за Уралом нет. Но спорить не вижу смысла)) К сожалению, Вы не упомянули не просто многое, а даже самое основное). Из-за этого очень много недоумения.
Уважаемый автор, ответ на все Ваши вопросы (особенно в части Это проблема качественного тестирования и управления качеством.) один — надо пахать.
Учиться.
Потом пахать.
И снова пахать.
И это все — не проблема тестирования. Управление качеством касается всех участников разработки… Вот этого понимания почему-то нет. «Так исторически сложилось»
Не соглашусь с Вами и в том, что недостаточно форумов и прочего. Вот этого как раз навалом. Разговоров и размышлений навалом. Дела мало, факт.
И тогда у меня на правах опытного специалиста вопрос к Вам.
Кто если не Вы?)
Только личным примером и личным участием, уж поверьте.
" выдаёт менеджеру время на работу, за которое можно сделать пол-сайта, менеджер в недоумении и сомневается в компетенции фронтенда" это стереотипы, которые нужно ломать.
Ломать например так. Посмотрите сколько времени вы обычно тратите на поддержку FE, на регулярное регресионное тестирование, сколько времени проходит между началом разработки и попаданием фичи на продакшн. В абсолютных величинах. В какую эмоциональную стоимость вам выливается эта поддержка. И тд.
Затем попробуйте на мелкой фиче покрыть ее например таким инструментом с нуля. И понаблюдайте, изменятся ли затраты, запары, закидоны на вышеупомянутых этапах.
Как тестировщик, от работы которого успешно и регулярно избавляется автор статьи, могу заметить еще один профит — имея инструмент контроля верстки на старте и грамотный подход к архитектуре, менеджер будет вас еще больше любить и поощерять. Потому что вы становитесь гибче к изменению его требований, доставляете эти изменения быстрее, сохраняя при этом стабильность приложения.
Я как-то поняла важную вещь, изменившую взгляд на всю эту бюрократию.
Разрабы аморально работают в трекере, ПОТОМУ ЧТО ОНИ НЕ ЗНАЮТ КАК!!!
Подход к таск-трекингу может быть абсолютно разный. Но часто попадаются специалисты, которые элементарно не умеют заполнять тикеты, не понимают что такое приоритет, что такое компонент.
У меня тогда шок наступил. Столько сил было потрачено на все эти «Сам инвалид», а причина такая простая…
Инструкция помогает, если ее например преподнести как DoD задачи, или если например привести кейсы важности того или иного случая.
Т.е. все то же самое — объяснить и «продать» регламент. Хорошо бы еще, если бы менеджеры приняли этот регламент и начали им пользоваться. Если и им он поперек горла, надо менять правила… возможно и правда не важно баг или фича.
Тоже соглашусь с каждым словом.
Так и написала-бюрократия должна работать на процесс.
Если название баг или фича-только формальность, не аффектит ни на планирование, ни на жизненный цикл задачи, ни на приоритет-не о чем разговаривать.
И еще важный момент. Если регламент не прозрачный, если разрабы не понимают эти процессы и зачем эта бюрократия нужна — хоть кол на голове чеши, не будут следовать.
И снова надо встретиться и объяснить ЗАЧЕМ это нужно.
Процессу важно быть прозрачным.
«все равно каждый остается при своем мнении.» значит отсидели полчаса, а не поработали. за полчаса такие вещи не исправляются)
«Т.е. будет сэкономлено время тестировщика, разаработчика и руководителя.
В том числе и нервы, возможно. » ну да)Судя по посту, нервов очень много сэкономлено)только спокойные и удовлетворенные работой люди их пишут)
Если я Вас правильно поняла, то да, соглашусь. Каждый work-чит как он хочит) Если принято делать проблемы из статуса в багтрекере, то и ок) Но есть более эффективные способы ;))
«Сам инвалид» — это не бюрократия и рабочий кейс, а какое-то хамство. В одной команде сработает, в другой можно выхватить.
Бюрократия должна работать на процесс, а не быть бичом или регламентом ради регламента.
А взаимодействие само собой не наладится. Вам, позвольте насоветую, не посты такие абсолютно без выводов строчить, а сделать первый шаг и начать разговаривать с разработкой.
По порядку — решается одинаково.
1. Подойти поинтересоваться почему инвалид
2. Подойти, поинтересоваться почему не пофиксаны кейсы. Переоткрыть с аргументацией баг, написать новый.какая блин разница
3. просто взять и протестировать. и подойти поинтересоваться, в чем фикс
4. и 5. вообще какая разница что это? на что аффектит что вы сейчас тестируете-баг или фичу?
брать и тестировать. если непонятно-подойти и поинтересоваться про что это
6. подойти и договориться о порядке фиксов.
И поправлюсь. Дядю Сашу и дядю Славу слушать всей командой!))
Кстати да, поискала на ФИПС) Бунина не нашла)
p.s.: помню как коммерческой целью первого Codefest была покупка чайника в офис)) цели достигли. И еще на блэндер хватило =)) классные воспоминания.
я сегодня душнила дня)) Кондратюк родился в Полтаве, в Нск он жил всего несколько лет)))
Ну не могу удержаться, извините...
Город прекрасный, заслуживает теплых слов!
Откуда такая информация?)) Сам Олег Вам сказал?))
Какой франшизы это филиал?)) это конференция, которая родилась в Новосибирске и которой аналогов за Уралом нет. Но спорить не вижу смысла)) К сожалению, Вы не упомянули не просто многое, а даже самое основное). Из-за этого очень много недоумения.
1999
Плеск?
Огромный Intel еще был, а Codefest вообще во вселенной автора не существует)))) ну ок.
Вот и выросло поколение, которое не помнит Феоктистова и Раменского))) И даже likegroof))
Каков запрос, таков и ответ)
Ну, в общем мы друг друга поняли.
Удачи Вам!
Учиться.
Потом пахать.
И снова пахать.
И это все — не проблема тестирования. Управление качеством касается всех участников разработки… Вот этого понимания почему-то нет. «Так исторически сложилось»
Не соглашусь с Вами и в том, что недостаточно форумов и прочего. Вот этого как раз навалом. Разговоров и размышлений навалом. Дела мало, факт.
И тогда у меня на правах опытного специалиста вопрос к Вам.
Кто если не Вы?)
Только личным примером и личным участием, уж поверьте.
Ломать например так. Посмотрите сколько времени вы обычно тратите на поддержку FE, на регулярное регресионное тестирование, сколько времени проходит между началом разработки и попаданием фичи на продакшн. В абсолютных величинах. В какую эмоциональную стоимость вам выливается эта поддержка. И тд.
Затем попробуйте на мелкой фиче покрыть ее например таким инструментом с нуля. И понаблюдайте, изменятся ли затраты, запары, закидоны на вышеупомянутых этапах.
Как тестировщик, от работы которого успешно и регулярно избавляется автор статьи, могу заметить еще один профит — имея инструмент контроля верстки на старте и грамотный подход к архитектуре, менеджер будет вас еще больше любить и поощерять. Потому что вы становитесь гибче к изменению его требований, доставляете эти изменения быстрее, сохраняя при этом стабильность приложения.
Разрабы аморально работают в трекере, ПОТОМУ ЧТО ОНИ НЕ ЗНАЮТ КАК!!!
Подход к таск-трекингу может быть абсолютно разный. Но часто попадаются специалисты, которые элементарно не умеют заполнять тикеты, не понимают что такое приоритет, что такое компонент.
У меня тогда шок наступил. Столько сил было потрачено на все эти «Сам инвалид», а причина такая простая…
Инструкция помогает, если ее например преподнести как DoD задачи, или если например привести кейсы важности того или иного случая.
Т.е. все то же самое — объяснить и «продать» регламент. Хорошо бы еще, если бы менеджеры приняли этот регламент и начали им пользоваться. Если и им он поперек горла, надо менять правила… возможно и правда не важно баг или фича.
Так и написала-бюрократия должна работать на процесс.
Если название баг или фича-только формальность, не аффектит ни на планирование, ни на жизненный цикл задачи, ни на приоритет-не о чем разговаривать.
И еще важный момент. Если регламент не прозрачный, если разрабы не понимают эти процессы и зачем эта бюрократия нужна — хоть кол на голове чеши, не будут следовать.
И снова надо встретиться и объяснить ЗАЧЕМ это нужно.
Процессу важно быть прозрачным.
«Т.е. будет сэкономлено время тестировщика, разаработчика и руководителя.
В том числе и нервы, возможно. » ну да)Судя по посту, нервов очень много сэкономлено)только спокойные и удовлетворенные работой люди их пишут)
Если я Вас правильно поняла, то да, соглашусь. Каждый work-чит как он хочит) Если принято делать проблемы из статуса в багтрекере, то и ок) Но есть более эффективные способы ;))
Бюрократия должна работать на процесс, а не быть бичом или регламентом ради регламента.
А взаимодействие само собой не наладится. Вам, позвольте насоветую, не посты такие абсолютно без выводов строчить, а сделать первый шаг и начать разговаривать с разработкой.
По порядку — решается одинаково.
1. Подойти поинтересоваться почему инвалид
2. Подойти, поинтересоваться почему не пофиксаны кейсы. Переоткрыть с аргументацией баг, написать новый.какая блин разница
3. просто взять и протестировать. и подойти поинтересоваться, в чем фикс
4. и 5. вообще какая разница что это? на что аффектит что вы сейчас тестируете-баг или фичу?
брать и тестировать. если непонятно-подойти и поинтересоваться про что это
6. подойти и договориться о порядке фиксов.
И поправлюсь. Дядю Сашу и дядю Славу слушать всей командой!))