Как дополнительную информацию использовать при желании можно, только не очень понятно, что делать с информацией, что 25% проблем Логические, 30% Технические, 35% Соотношения и 10% Локализированые.
К тому же мне все-таки кажется, что в большинстве случаев баг можно отнести к нескольким категориям сразу, но возможно на ваших проектах иначе. Впрочем, если разрешить в трекере вешать на баг несколько категорий, то это и не так страшно.
И вне остального контекста и истории проекта распределение в любом случае мало о чем говорит. Может, слабо проработанные требования для конкретной некритичной фичи — это было вынужденное и лучшее из возможных решений, которое позволило детальней проработать важную функциональность?
В общем, я бы поостерегся полагаться только на эти данные в любом случае.
А какой интерес начальству расставлять эти категории? Что они начальству дают?
Тестировщику могут помочь с тест-дизайном, это выяснили. А начальству зачем?
И кстати: кто тут подразумевается под «начальством»?
Действительно. Пока все будут перепихивать ошибку друг другу и решать кто за нее должен отвечать, тестировщику и отдохнуть можно.
Не вижу особого смысла решать, кто в чем виноват. Куда полезней — решить, кто и как будет чинить.
Ну за кроме самых крайних и особо выдающихся случаев (но в таких случаях обычно и так понятно, кто главный факапер, и отдельная классификация для этого не нужна).
А, уже чуть понятней.
То есть пока вырисовывается, что эти категории могут помочь, например, при тест-дизайне, если их использовать как некие разбиения (подобласти) рабочего домена, или даже как некие эвристики.
И соответственно актуальны для тестировщиков.
Правда даже для нужд тест-дизайна список кажется слишком абстрактным, для конкретных программ/проектов его надо будет адаптировать на мой взгляд. Но как некая стартовая точка может и помочь, наверное
Я просто поначалу воспринял пост так, будто вы в багтрекер предлагаете такие категории внести, что пока кажется лишней активностью: непонятно, как могло бы пригодиться.
Классификации обычно вводятся для того, чтоб как-то упростить жизнь тем, кто работает с предметной областью.
Как эта классификация помогает в повседневной работе? Для каких ролей на проекте она актуальна? Как её правильно использовать?
Не стекутся ли 70% багов в категорию «Комбинированые»?
Здравый смысл у каждого свой — и это прекрасно. Именно из того, что люди неодинаковы и получаются команды, а не набор взаимозаменяемых элементов.
Инструкции могут работать, пока их немного, пока они просты, как инструкция по заполнению багрепорта, которая по сути своей — чеклист, позволяющий не забыть, какие данные надо указать.
Если инструкций много, а деятельность сложна — уже возникают неявные конфликты, одна инструкция становится приоритетней другой в зависимости от ситуации, да и просто забываются.
Можно конечно лечить созданием метаинструкций по пользованию и управлению инструкциями, но едва ли это то, к чему кто-то правда стремится.
Слово «всегда» вообще выглядит неуместным, когда речь идет о сколько-то интеллектуальной человеческой деятельности. Я понимаю, что программистам, тестировщикам и математикам интересней работать с крайними точками — сам такой. Но люди не ПО, и большинство из них находится где-то между крайними точками, на красный свет не едут, но пустую дорогу перейти не по пешеходному переходу могут. И это вполне нормально. Разумнее это понимать и использовать, чем пытаться устранить, особенно в нашей обычно не шибко угрожающей жизни деятельности.
Кстати, точное следование инструкциям, даже в высшей степени разумным, называется «итальянская забастовка».
Потому что ни одна инструкция не содержит весь необходимый контекст и дух деятельности, и редкая инструкция поясняет, зачем и почему нужно делать именно так.
Так что от общения, взаимодействия и взаимопонимания никуда не деться. Во всяком случае инструкциями их не заменишь.
— инструкция будет нарушаться ежедневно, просто из соображений здравого смысла
Ну, значит, нарушитель будет лишаться квартальной премии. Проблема-то?
Карать за здравый смысл очень разумная практика
Пол-страницы текста обновить несложно.
Обновить мало. Надо еще чтоб все причастные перечитали, поняли что изменилось, зачем изменилось и так далее. Ну и момент, когда уже пора обновлять, надо не упустить. И поди еще обновлять может только строго ограниченный круг лиц?
Впрочем, если вы видите свою задачу как просто точное исполнение записанной инструкции (отступление от которой бьет по карману и прочим нежным местам), то менять ее вряд ли когда понадобится: никто просто не скажет, что что-то в ней не важно, не нужно или устарело — этак и недисциплинированным можно прослыть.
А вообще, формализм и дисциплина — это немножко разные вещи. Мне так кажется.
К сожалению (а может и к счастью), обязательные к исполнению внутренние инструкции не очень-то работают, если человек не понимает их смысла или, еще хуже, не согласен с ними. А если понимает и согласен, то и инструкция, в общем, не нужна.
Единственный вариант, когда она может пригодиться, имхо, — чтоб ознакомить новичка с принятыми в компании/проекте процессами. И ответить на его комментарии/вопросы по этому поводу.
Как фиксация каких-то договоренностей подобная инструкция, может, и полезна, но стоит понимать, что в реальной жизни
— инструкция будет нарушаться ежедневно, просто из соображений здравого смысла
— смысл и дух инструкции нужно будет неоднократно разъяснять всем вокруг
— в какой-то момент (и зачастую довольно скоро) инструкция начнет устаревать и не соответствовать жизни, а обновлять ее никто не будет
В общем, фиксация правил и договоренностей — это полезно, но без налаженного взаимодействия, общения и взаимопонимания она ничем не поможет.
Так что нужно налаживать это самое взаимодействие и взаимопонимание, а инструкции после уже приложатся если все же сильно нужны окажутся.
Всячески согласен, что обcуждать спорные ситуации лучше вживую — лицом к лицу, по телефону, скайпу и так далее. Ни в коем случае не нужно сужать канал общения до комментов и статусов багтрекера.
Всячески согласен, что бюрократия должна работать на процесс, а процесс на результат
А вот про отуствие разницы между багом и фичей не соглашусь. Само по себе оно неважно, конечно, как в багтрекере сущность обозвана. Различие между фичей и багом — как раз в том, какие процессы накручены вокруг этих понятий, а процессы эти могут сильно отличаться.
Например: если один общий продукт разрабатывают команды из пяти городов, едва ли кто-то может удержать в голове все нюансы работы продукта. Типичная практика в таких случаях — хотя бы сообщать всем о планируемых и/или внедренных фичах: вдруг кто-то знает, чем неожиданным это слово отзовется в будущем, и вовремя подскажет. [Бывают и более сложные процессы для совместной работы с фичами, см например пост]
Для фич такие процессы можут работать, а для багов заведомо нежизнеспособны. Отсюда и разница между багом и фичей, и важность правильного названия в трекере, если с этого названия стартует остальной процесс.
Я, что и понятно, книгу не читал, а только пару минут смотрел на картинку
Насколько я понял, ключевая идея в том, что система неким образом замечает и репортит проблему, после чего происходит остановка вплоть до устранения проблемы.
по этому поводу есть две мысли:
1. Не всегда подходы, работающие на материальном производстве, применимы один в один к разработке ПО. Простейший пример: если где-то как-то нашлась проблема, то пока ее не устранили — конвейер, если его не остановить, будет клепать эту проблему в каждое изделие. В случае ПО это не совсем так.
Я хочу сказать, что зачастую подходы производства нужно как-то адаптировать к разработке ПО, а не тупо копировать. Вполне допускаю, что автор подобную адаптацию делал, но не зная в деталях исходного процесса и примененных адаптаций — трудно говорить на одном языке.
2. С другой стороны, идея останова присутствует во многих практиках разработки ПО. Только эти остановы вынесены в процесс разработки, а не в процесс работы приложения. (но и на картинке останавливается производство (line), а не конкретное изделие).
Примеры остановов в разработке ПО:
— не собрался билд
— билд собрался, но приемочные тесты (на билд или фичу) не прошли
— приемочные тесты прошли, но далее нашлись критичные баги, которые блокируют релиз.
И — линия останавливается, в том смысле что новое изделие не поставляется клиентам.
Такое впечатление, что автор как раз предлагает переместить останов в саму программу, то есть в работающее изделие (автомобиль на трассе). Но не вполне понятно, как это реализовывать, какие бенефиты (насколько заметные) это дает, и как избежать останова на продакшене (выключения двигателя во время движения).
Приемочные тесты — во-первых, это ну совсем базовые вещи (по кр. мере у нас так). Это никак не обещает, что при шаге в сторону все продолжит работать. Всегда приходится искать баланс между «больше проверок» и «быстрее». Достаточно скоро мы попадаем в ситуацию, когда билды собираются много чаще, чем успевает отработать приемка. И тогда начинаются вопросы: а зачем вы используете такой старый билд?
Кроме того — приемочные тесты это регрессия, а тестировать мы стремимся новые фичи, нет? Они не покрыты приемочными тестами по определению, и запросто могут не работать. Далее по тексту — баги, обходные маневры, время потраченное в багтрекер, тестровщик глядящий на дождь за окном.
>Функциональные тесты — обязательно
>Юнит-тесты — желательно, но зависит от настроения разработчиков
Я бы в зависимость от прям вот настроения не ставил. Если ждать вдохновения — то никаких юнит тестов не будет.
И тогда легко и быстро скатиться к ситуации, когда
— 30% времени билд тупо не собирается или собирается, но не проходит базовые проверки
— 30% времени тестировщики тратят время на описание «простых и очевидных» багов в трекере, продираются через эти баги, обходят их как-то
— 10% времени тестировщики объясняют, почему тестирование движется так медленно
— 5% времени уходит на перепланирование в связи с поплывшими сроками
— 25% времени тратится на тестирование (включая сюда анализ, тест-дизайн, настройку окружения, репорты и т.д.)
Утрировано, но, думаю, идея понятна. Если программист снимает с себя ответственность за качество (проверять — это ж работа тестировщика!), то никакой отдел тестирования уже ничего не спасет. Разве что тестировщики начнут чинить процессы разработки и внедрять полезные практики, вместо того чтоб грызть кактус…
Тестировщик не может воспроизвести в собственном окружении — я бы повесил баг на него до повторения. Программист тут разве что советом помось может.
Тестировщик видит проблему и может повторить, но не понимает, что/как происходит, — тут уже и программиста не грех привлечь вплотную. Или — сесть вместе разбираться: программист лучше знает кишки продукта, а тестировщик — тестового окружения. Вместе справятся.
С одной стороны — позитивный сценарий обязан работать, когда фича пришла в тестирование.
С другой — с тестировщиков это ответственности не снимает. Помогайте расставлять приоритеты. Пусть тестировщики показывают high-level план тестирования фичи разработчикам (аналитикам, и прочим заинтересованным лицам) — это всегда полезно.
Ну едва ли они отмахиваются просто потому, что плохо воспитаны.
Для вас они «не умеют читать логи», а для них лог — мешанина малопонятных строк. И не исключено, что они правы, и логи действительно мало говорят непосвященным. Покажите, как определить и отфильтровать нужную транзакцию в логе. Расскажите общую логику построения логов.
А с архитектурой они знакомы? Если нет, то и разумные предположения, куда смотреть в случае проблем, им сделать трудно.
ID сущности сложно определить? Упростите ее получение.
Покажите уровень дубликатов и инвалидов; если он аномально высок — договоритесь с тестлидом, как будете решать проблему. Только не указывайте, пусть он сам что-нибудь придумает. И объясните, почему это — проблема.
Дайте пошаговую инструкцию исследования типичных проблем, простую — шагов на пять-семь.
Расскажите про черный и белый ящик наконец, что ли )
В общем, если коротко, то — учите и объясняйте. Ругаться смысла нет.
Если не хочется учить всех — учите тестлида или просто самого толкового из тестировщиков втихушку ). Он потом научит остальных.
Вы кстати знаете, кто из ваших тестировщиков — самый толковый? )
Тестирование при том всего лишь, что оно — часть процесса разработки, и не стоит его искусственно отделять в специальную песочницу ).
Согласен, проблема не относится исключительно к тестированию — так же, как она не относится исключительно к разработке продукта или к планирование проекта. Планирование тестирования в контексте разработки конкретного продукта, как-то так.
Типичная проблема границ и взаимодействия компонент. )
К тому же мне все-таки кажется, что в большинстве случаев баг можно отнести к нескольким категориям сразу, но возможно на ваших проектах иначе. Впрочем, если разрешить в трекере вешать на баг несколько категорий, то это и не так страшно.
И вне остального контекста и истории проекта распределение в любом случае мало о чем говорит. Может, слабо проработанные требования для конкретной некритичной фичи — это было вынужденное и лучшее из возможных решений, которое позволило детальней проработать важную функциональность?
В общем, я бы поостерегся полагаться только на эти данные в любом случае.
Тестировщику могут помочь с тест-дизайном, это выяснили. А начальству зачем?
И кстати: кто тут подразумевается под «начальством»?
Не вижу особого смысла решать, кто в чем виноват. Куда полезней — решить, кто и как будет чинить.
Ну за кроме самых крайних и особо выдающихся случаев (но в таких случаях обычно и так понятно, кто главный факапер, и отдельная классификация для этого не нужна).
То есть пока вырисовывается, что эти категории могут помочь, например, при тест-дизайне, если их использовать как некие разбиения (подобласти) рабочего домена, или даже как некие эвристики.
И соответственно актуальны для тестировщиков.
Правда даже для нужд тест-дизайна список кажется слишком абстрактным, для конкретных программ/проектов его надо будет адаптировать на мой взгляд. Но как некая стартовая точка может и помочь, наверное
Я просто поначалу воспринял пост так, будто вы в багтрекер предлагаете такие категории внести, что пока кажется лишней активностью: непонятно, как могло бы пригодиться.
Классификации обычно вводятся для того, чтоб как-то упростить жизнь тем, кто работает с предметной областью.
Как эта классификация помогает в повседневной работе? Для каких ролей на проекте она актуальна? Как её правильно использовать?
Не стекутся ли 70% багов в категорию «Комбинированые»?
Выходит, мы говорили о разных вещах
Инструкции могут работать, пока их немного, пока они просты, как инструкция по заполнению багрепорта, которая по сути своей — чеклист, позволяющий не забыть, какие данные надо указать.
Если инструкций много, а деятельность сложна — уже возникают неявные конфликты, одна инструкция становится приоритетней другой в зависимости от ситуации, да и просто забываются.
Можно конечно лечить созданием метаинструкций по пользованию и управлению инструкциями, но едва ли это то, к чему кто-то правда стремится.
Слово «всегда» вообще выглядит неуместным, когда речь идет о сколько-то интеллектуальной человеческой деятельности. Я понимаю, что программистам, тестировщикам и математикам интересней работать с крайними точками — сам такой. Но люди не ПО, и большинство из них находится где-то между крайними точками, на красный свет не едут, но пустую дорогу перейти не по пешеходному переходу могут. И это вполне нормально. Разумнее это понимать и использовать, чем пытаться устранить, особенно в нашей обычно не шибко угрожающей жизни деятельности.
Кстати, точное следование инструкциям, даже в высшей степени разумным, называется «итальянская забастовка».
Потому что ни одна инструкция не содержит весь необходимый контекст и дух деятельности, и редкая инструкция поясняет, зачем и почему нужно делать именно так.
Так что от общения, взаимодействия и взаимопонимания никуда не деться. Во всяком случае инструкциями их не заменишь.
Карать за здравый смысл очень разумная практика
Обновить мало. Надо еще чтоб все причастные перечитали, поняли что изменилось, зачем изменилось и так далее. Ну и момент, когда уже пора обновлять, надо не упустить. И поди еще обновлять может только строго ограниченный круг лиц?
Впрочем, если вы видите свою задачу как просто точное исполнение записанной инструкции (отступление от которой бьет по карману и прочим нежным местам), то менять ее вряд ли когда понадобится: никто просто не скажет, что что-то в ней не важно, не нужно или устарело — этак и недисциплинированным можно прослыть.
А вообще, формализм и дисциплина — это немножко разные вещи. Мне так кажется.
Единственный вариант, когда она может пригодиться, имхо, — чтоб ознакомить новичка с принятыми в компании/проекте процессами. И ответить на его комментарии/вопросы по этому поводу.
Как фиксация каких-то договоренностей подобная инструкция, может, и полезна, но стоит понимать, что в реальной жизни
— инструкция будет нарушаться ежедневно, просто из соображений здравого смысла
— смысл и дух инструкции нужно будет неоднократно разъяснять всем вокруг
— в какой-то момент (и зачастую довольно скоро) инструкция начнет устаревать и не соответствовать жизни, а обновлять ее никто не будет
В общем, фиксация правил и договоренностей — это полезно, но без налаженного взаимодействия, общения и взаимопонимания она ничем не поможет.
Так что нужно налаживать это самое взаимодействие и взаимопонимание, а инструкции после уже приложатся если все же сильно нужны окажутся.
Всячески согласен, что бюрократия должна работать на процесс, а процесс на результат
А вот про отуствие разницы между багом и фичей не соглашусь. Само по себе оно неважно, конечно, как в багтрекере сущность обозвана. Различие между фичей и багом — как раз в том, какие процессы накручены вокруг этих понятий, а процессы эти могут сильно отличаться.
Например: если один общий продукт разрабатывают команды из пяти городов, едва ли кто-то может удержать в голове все нюансы работы продукта. Типичная практика в таких случаях — хотя бы сообщать всем о планируемых и/или внедренных фичах: вдруг кто-то знает, чем неожиданным это слово отзовется в будущем, и вовремя подскажет. [Бывают и более сложные процессы для совместной работы с фичами, см например пост]
Для фич такие процессы можут работать, а для багов заведомо нежизнеспособны. Отсюда и разница между багом и фичей, и важность правильного названия в трекере, если с этого названия стартует остальной процесс.
Насколько я понял, ключевая идея в том, что система неким образом замечает и репортит проблему, после чего происходит остановка вплоть до устранения проблемы.
по этому поводу есть две мысли:
1. Не всегда подходы, работающие на материальном производстве, применимы один в один к разработке ПО. Простейший пример: если где-то как-то нашлась проблема, то пока ее не устранили — конвейер, если его не остановить, будет клепать эту проблему в каждое изделие. В случае ПО это не совсем так.
Я хочу сказать, что зачастую подходы производства нужно как-то адаптировать к разработке ПО, а не тупо копировать. Вполне допускаю, что автор подобную адаптацию делал, но не зная в деталях исходного процесса и примененных адаптаций — трудно говорить на одном языке.
2. С другой стороны, идея останова присутствует во многих практиках разработки ПО. Только эти остановы вынесены в процесс разработки, а не в процесс работы приложения. (но и на картинке останавливается производство (line), а не конкретное изделие).
Примеры остановов в разработке ПО:
— не собрался билд
— билд собрался, но приемочные тесты (на билд или фичу) не прошли
— приемочные тесты прошли, но далее нашлись критичные баги, которые блокируют релиз.
И — линия останавливается, в том смысле что новое изделие не поставляется клиентам.
Такое впечатление, что автор как раз предлагает переместить останов в саму программу, то есть в работающее изделие (автомобиль на трассе). Но не вполне понятно, как это реализовывать, какие бенефиты (насколько заметные) это дает, и как избежать останова на продакшене (выключения двигателя во время движения).
Или я статью и картинку совсем неправильно понял?
Согласен, приемочный тест на фичу сильно упрощает жизнь.
подумаю, как бы нам к такому приблизиться
Кроме того — приемочные тесты это регрессия, а тестировать мы стремимся новые фичи, нет? Они не покрыты приемочными тестами по определению, и запросто могут не работать. Далее по тексту — баги, обходные маневры, время потраченное в багтрекер, тестровщик глядящий на дождь за окном.
>Юнит-тесты — желательно, но зависит от настроения разработчиков
Я бы в зависимость от прям вот настроения не ставил. Если ждать вдохновения — то никаких юнит тестов не будет.
И тогда легко и быстро скатиться к ситуации, когда
— 30% времени билд тупо не собирается или собирается, но не проходит базовые проверки
— 30% времени тестировщики тратят время на описание «простых и очевидных» багов в трекере, продираются через эти баги, обходят их как-то
— 10% времени тестировщики объясняют, почему тестирование движется так медленно
— 5% времени уходит на перепланирование в связи с поплывшими сроками
— 25% времени тратится на тестирование (включая сюда анализ, тест-дизайн, настройку окружения, репорты и т.д.)
Утрировано, но, думаю, идея понятна. Если программист снимает с себя ответственность за качество (проверять — это ж работа тестировщика!), то никакой отдел тестирования уже ничего не спасет. Разве что тестировщики начнут чинить процессы разработки и внедрять полезные практики, вместо того чтоб грызть кактус…
Тестировщик видит проблему и может повторить, но не понимает, что/как происходит, — тут уже и программиста не грех привлечь вплотную. Или — сесть вместе разбираться: программист лучше знает кишки продукта, а тестировщик — тестового окружения. Вместе справятся.
С другой — с тестировщиков это ответственности не снимает. Помогайте расставлять приоритеты. Пусть тестировщики показывают high-level план тестирования фичи разработчикам (аналитикам, и прочим заинтересованным лицам) — это всегда полезно.
Для вас они «не умеют читать логи», а для них лог — мешанина малопонятных строк. И не исключено, что они правы, и логи действительно мало говорят непосвященным. Покажите, как определить и отфильтровать нужную транзакцию в логе. Расскажите общую логику построения логов.
А с архитектурой они знакомы? Если нет, то и разумные предположения, куда смотреть в случае проблем, им сделать трудно.
ID сущности сложно определить? Упростите ее получение.
Покажите уровень дубликатов и инвалидов; если он аномально высок — договоритесь с тестлидом, как будете решать проблему. Только не указывайте, пусть он сам что-нибудь придумает. И объясните, почему это — проблема.
Дайте пошаговую инструкцию исследования типичных проблем, простую — шагов на пять-семь.
Расскажите про черный и белый ящик наконец, что ли )
В общем, если коротко, то — учите и объясняйте. Ругаться смысла нет.
Если не хочется учить всех — учите тестлида или просто самого толкового из тестировщиков втихушку ). Он потом научит остальных.
Вы кстати знаете, кто из ваших тестировщиков — самый толковый? )
Согласен, проблема не относится исключительно к тестированию — так же, как она не относится исключительно к разработке продукта или к планирование проекта. Планирование тестирования в контексте разработки конкретного продукта, как-то так.
Типичная проблема границ и взаимодействия компонент. )