Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 31
У вас Типографические ошибки и технические и дизайнерские, не совсем понял, каким боком они к техническим относятся.
Логические ошибки в вашей классификации очень разные. Связи между логической ошибкой в коде и логической ошибкой в функционале — практически никакой нет и объединять их в одну сущность довольно странно.
Если вы хотите сгруппировать ошибки так, чтобы в одном классе существовали какие-то общие правила для того чтобы найти ошибки принадлежащие этому классу и подклассам в нем, то боюсь такая идея заранее провальная, поскольку даже в довольно логичном классе «дизайнерские» — непонятный дизайн — это нефункциональное требование, а все остальное — функциональное. И как вы сможете привести рекомендации по поиску к одному виду по диаметрально разным требованиям мне совершенно непонятно.
Логические ошибки в вашей классификации очень разные. Связи между логической ошибкой в коде и логической ошибкой в функционале — практически никакой нет и объединять их в одну сущность довольно странно.
Если вы хотите сгруппировать ошибки так, чтобы в одном классе существовали какие-то общие правила для того чтобы найти ошибки принадлежащие этому классу и подклассам в нем, то боюсь такая идея заранее провальная, поскольку даже в довольно логичном классе «дизайнерские» — непонятный дизайн — это нефункциональное требование, а все остальное — функциональное. И как вы сможете привести рекомендации по поиску к одному виду по диаметрально разным требованиям мне совершенно непонятно.
Логические и типографические в технических — очень просто, это ошибки в коде (синтаксис, опечатки и т.п.), как и та ошибка в коде, которая позволяет функционалу работать, но работать неправильно. Дизайнерские тоже могут напрямую зависеть от кода: например, опечатка, которая проявляется в тексте на сайте. Как-то так. Хотя согласна с Вами, что это довольно спорный момент, и, вероятно, я таки их из группы логической уберу.
Я именно предприняла попытку как-то так сгруппировать, чтобы было легче их потом находить, это черновой вариант, потому и вынесено на обсуждение для внесения поправок. Благодарю за комментарии!
Я именно предприняла попытку как-то так сгруппировать, чтобы было легче их потом находить, это черновой вариант, потому и вынесено на обсуждение для внесения поправок. Благодарю за комментарии!
Спасибо, интересно.
Классификации обычно вводятся для того, чтоб как-то упростить жизнь тем, кто работает с предметной областью.
Как эта классификация помогает в повседневной работе? Для каких ролей на проекте она актуальна? Как её правильно использовать?
Не стекутся ли 70% багов в категорию «Комбинированые»?
Классификации обычно вводятся для того, чтоб как-то упростить жизнь тем, кто работает с предметной областью.
Как эта классификация помогает в повседневной работе? Для каких ролей на проекте она актуальна? Как её правильно использовать?
Не стекутся ли 70% багов в категорию «Комбинированые»?
В повседневной работе тестировщика такая штука помогает как-то разложить баги «по полочкам», чтобы заранее понимать, что можно найти при анализе. Как правильно использовать — это самый сложный вопрос, на который я буду искать ответ после того, как «причешу» эти группы.
Нет, 70% в комбинированные не упадут, это мой опыт. В комбинированные вообще могут упать единицы, я даже не припомню сходу какой-то такой баг, чтобы был комбинированным, хотя для других групп примеров полно.
Нет, 70% в комбинированные не упадут, это мой опыт. В комбинированные вообще могут упать единицы, я даже не припомню сходу какой-то такой баг, чтобы был комбинированным, хотя для других групп примеров полно.
А, уже чуть понятней.
То есть пока вырисовывается, что эти категории могут помочь, например, при тест-дизайне, если их использовать как некие разбиения (подобласти) рабочего домена, или даже как некие эвристики.
И соответственно актуальны для тестировщиков.
Правда даже для нужд тест-дизайна список кажется слишком абстрактным, для конкретных программ/проектов его надо будет адаптировать на мой взгляд. Но как некая стартовая точка может и помочь, наверное
Я просто поначалу воспринял пост так, будто вы в багтрекер предлагаете такие категории внести, что пока кажется лишней активностью: непонятно, как могло бы пригодиться.
То есть пока вырисовывается, что эти категории могут помочь, например, при тест-дизайне, если их использовать как некие разбиения (подобласти) рабочего домена, или даже как некие эвристики.
И соответственно актуальны для тестировщиков.
Правда даже для нужд тест-дизайна список кажется слишком абстрактным, для конкретных программ/проектов его надо будет адаптировать на мой взгляд. Но как некая стартовая точка может и помочь, наверное
Я просто поначалу воспринял пост так, будто вы в багтрекер предлагаете такие категории внести, что пока кажется лишней активностью: непонятно, как могло бы пригодиться.
эти категории могут помочь, например, при тест-дизайне, если их использовать как некие разбиения (подобласти) рабочего домена, или даже как некие эвристики.
И соответственно актуальны для тестировщиков.
Да, мне вот оболегчает понимание того, что я ищу и где. Ведь понятно, что баги дизайна не найдутся при статическом анализе, ибо джизайна как такового еще и нет на уровне девелопмента.
вы в багтрекер предлагаете такие категории внести
Нет, нет, ни в коем случае! Такого мусора там не надо. Это для понимания тестировщиков, не более.
а я бы внес в багтрекер такие категории, только их начальство должно выставлять, а не рядовые тестировщики
Логично. Но предложить можно, а начальству уже решать.
А какой интерес начальству расставлять эти категории? Что они начальству дают?
Тестировщику могут помочь с тест-дизайном, это выяснили. А начальству зачем?
И кстати: кто тут подразумевается под «начальством»?
Тестировщику могут помочь с тест-дизайном, это выяснили. А начальству зачем?
И кстати: кто тут подразумевается под «начальством»?
А начальству зачем?
Для анализа сфер проблем и попыток улучшить качество работы людей, которые могут эти баги предупредить.
Как дополнительную информацию использовать при желании можно, только не очень понятно, что делать с информацией, что 25% проблем Логические, 30% Технические, 35% Соотношения и 10% Локализированые.
К тому же мне все-таки кажется, что в большинстве случаев баг можно отнести к нескольким категориям сразу, но возможно на ваших проектах иначе. Впрочем, если разрешить в трекере вешать на баг несколько категорий, то это и не так страшно.
И вне остального контекста и истории проекта распределение в любом случае мало о чем говорит. Может, слабо проработанные требования для конкретной некритичной фичи — это было вынужденное и лучшее из возможных решений, которое позволило детальней проработать важную функциональность?
В общем, я бы поостерегся полагаться только на эти данные в любом случае.
К тому же мне все-таки кажется, что в большинстве случаев баг можно отнести к нескольким категориям сразу, но возможно на ваших проектах иначе. Впрочем, если разрешить в трекере вешать на баг несколько категорий, то это и не так страшно.
И вне остального контекста и истории проекта распределение в любом случае мало о чем говорит. Может, слабо проработанные требования для конкретной некритичной фичи — это было вынужденное и лучшее из возможных решений, которое позволило детальней проработать важную функциональность?
В общем, я бы поостерегся полагаться только на эти данные в любом случае.
Может, слабо проработанные требования для конкретной некритичной фичи — это было вынужденное и лучшее из возможных решений, которое позволило детальней проработать важную функциональность?
Вот потому и надо это анализировать, чтобы знать наверняка, кто недоработал. Обычно вообще некоторые юз-кейсы не рассматриваются никем, покуда не начинается тестинг вдоль и впоперек. Да и не всегда тестировщик к этому «цепляется», ведь раз не описано — значит, все ок.
я бы поостерегся полагаться только на эти данные в любом случае.
Конечно, только на эти данные полагаться не стоит. А как дополнительную информацию — можно. В любом случае, я просто предложила рассмотреть такой вариант.
Выглядит слишком сложно и непрактично, по-моему.
А оригинальная подробная классификация — вообще мрак. Классификация должна быть достаточно простая и логичная, чтобы не надо было сверяться со специальным документом на каждый новый открытый баг.
Только категории Дизайнерские и Документации понятны простому смертному, а все остальные категории нуждаются в расшифровке.
В результате может получиться, что только один человек в конторе будет знать, что какая категория означает, а все остальные привыкнут тупо ставить Комбинированную.
Немного более подробно:
Категория Логические перекрывается частично Технической и частично Дизайном — сама по себе она невнятная.
Категория Локализованные — название очень неинтуитивное, хотя идея и понятна.
Категория Соотношения — тоже очень мутная.
При создании категоризации нужно плясать от того, для чего (принятия каких решений или какого анализа) категоризация нужна, и кто будет отвечать за назначение категорий. В данном случае это явно не QA, так как предложенные категории слишком технические. А зачем они нужны программерам — не совсем понятно.
А оригинальная подробная классификация — вообще мрак. Классификация должна быть достаточно простая и логичная, чтобы не надо было сверяться со специальным документом на каждый новый открытый баг.
Только категории Дизайнерские и Документации понятны простому смертному, а все остальные категории нуждаются в расшифровке.
В результате может получиться, что только один человек в конторе будет знать, что какая категория означает, а все остальные привыкнут тупо ставить Комбинированную.
Немного более подробно:
Категория Логические перекрывается частично Технической и частично Дизайном — сама по себе она невнятная.
Категория Локализованные — название очень неинтуитивное, хотя идея и понятна.
Категория Соотношения — тоже очень мутная.
При создании категоризации нужно плясать от того, для чего (принятия каких решений или какого анализа) категоризация нужна, и кто будет отвечать за назначение категорий. В данном случае это явно не QA, так как предложенные категории слишком технические. А зачем они нужны программерам — не совсем понятно.
Категория Логические перекрывается частично Технической и частично Дизайном — сама по себе она невнятная.
Согласна с Вами, но пока что более внятного названия придумать не могу. Просто в моей практике логических багов — именно нарушенной логики работы функционала — просто море. А это по факту как бы и не баг, ведь код написан правильно, ui в порядке и все красиво. А вот работает невнятно для пользователя.
Категория Локализованные — название очень неинтуитивное
И тут согласна, может, у кого-то будут идеи для более понятного названия. Я пока не могу найти более понятного выражения…
Категория Соотношения — тоже очень мутная
Была мысль назвать маппингом или связями, но это тоже как-то не фонтан.
А зачем они нужны программерам
Программерам по факту вообще все равно. Это больше для тестировщиков, чтобы было понятно, что за баг, где и откуда, и чего ждать при анализе той или иной области.
У нас все ошибки классифицируются
по веткам: разработка, стабилизация, релиз. Позволяет определить ветку в которой этот баг править.
по типам: баг, доработка (используется если реализованный функционал отличается от описания требования). Позволяет оценить что является основной причиной багов. Плохо формализованные требования и/или непонимание требований, или ошибки в разработке. Сейчас класс доработка применяется редко, т.к. проблему с формализацией требований в основном решили.
Какую выгоду вы получаете от применения такой сложной классификации?
по веткам: разработка, стабилизация, релиз. Позволяет определить ветку в которой этот баг править.
по типам: баг, доработка (используется если реализованный функционал отличается от описания требования). Позволяет оценить что является основной причиной багов. Плохо формализованные требования и/или непонимание требований, или ошибки в разработке. Сейчас класс доработка применяется редко, т.к. проблему с формализацией требований в основном решили.
Какую выгоду вы получаете от применения такой сложной классификации?
Какую выгоду вы получаете от применения такой сложной классификации?
Чисто субъективную. Во-первых, я знаю, что я могу искать вообще. Во-вторых, я знаю, где искать. В-третьих, как я заметила, часто именно логические упущения в работе функционала вообще могут не приниматься во внимание — мол, пока не опишут в спеке, до тех пор не баг. Но с другой стороны нарушения именно логической стороны использования функционала могут быть критическими с точки зрения бизнеса.
Не понял. Вот есть баг. Его заводят и присваивают ему класс. Затем идет жизненный цикл:
1. Баг попадает к разработчикам на исправление.
2. Баг возвращается в QA на проверку.
3. Баг закрывается и может быть использован team lead-ом или менеджером проекта для анализа.
Вот, на каком из 3-х шагов класс используется и как? Или у вас есть еще этапы и класс используется там? Спасибо.
1. Баг попадает к разработчикам на исправление.
2. Баг возвращается в QA на проверку.
3. Баг закрывается и может быть использован team lead-ом или менеджером проекта для анализа.
Вот, на каком из 3-х шагов класс используется и как? Или у вас есть еще этапы и класс используется там? Спасибо.
Смотрите, группировка багов может быть использована:
1. Тестировщиком при тест-дизайне и в процессе тестирования.
2. Лидом при анализе статистики, в каких группах чаще всего баги.
В процессе фикса никакие группы уже не имеют смысла вообще. Мне, как тестировщику, важно понять, что и где мне искать, на что обратить внимание при составлении тест-кейсов.
1. Тестировщиком при тест-дизайне и в процессе тестирования.
2. Лидом при анализе статистики, в каких группах чаще всего баги.
В процессе фикса никакие группы уже не имеют смысла вообще. Мне, как тестировщику, важно понять, что и где мне искать, на что обратить внимание при составлении тест-кейсов.
Спасибо. А, если это не большой секрет, можно посмотреть количество багов по классам за последний месяц. А еще лучше в понедельном или подневном разрезе за последние пару месяцев — полгода. Можно в личку…
Можно и в личку.
Но смотрите какой нюанс: группы багов будут зависеть от проекта. Далее следуют мои субъективные оценки групп, поскольку четко еще никто не считал.
Например, на проекте по изменениям на сайтах, львиную долю (приблизительно %50) составляли баги дизайна, на логические вообще редко обращали внимания, на технические падало порядка 35%, 10: на локальные баги браузеров и 5% на документацию.
На проекте с базами данных львиная доля упала на логические (30-40%), на баги неправильных связей где-то 25%, дизайн — мелочь, где-то до 10%, документацию — около 10% и остальное на технические.
Но смотрите какой нюанс: группы багов будут зависеть от проекта. Далее следуют мои субъективные оценки групп, поскольку четко еще никто не считал.
Например, на проекте по изменениям на сайтах, львиную долю (приблизительно %50) составляли баги дизайна, на логические вообще редко обращали внимания, на технические падало порядка 35%, 10: на локальные баги браузеров и 5% на документацию.
На проекте с базами данных львиная доля упала на логические (30-40%), на баги неправильных связей где-то 25%, дизайн — мелочь, где-то до 10%, документацию — около 10% и остальное на технические.
Вы уже используете предложенную классификацию или только предложили ее нам?
первое. При попытке внедрить ее возникнут интересные сайд-эффекты, так как в большинстве случаев нашедший дефект black-box тестировщик самостоятельно не сможет отнести дефект к группе Соотношения или Технические. Вообще, скорее всего он будет относить почти все дефекты только к двум группам — Логические и Дизайнерские.
Получается затем ему придется выяснять у программиста или менеджера куда отнести дефект или следить за тем, чтоб эти ребята все проставили. То есть у трех ролей в команде с размаху появляется масса интересной работы, про которую надо еще и не забыть.
Второе. Очень важное. Поясните мысль:
Под нахождением здесь подразумевается поиск старых багов в трекере или поиск новых багов в продукте? Разница принципиальная.
первое. При попытке внедрить ее возникнут интересные сайд-эффекты, так как в большинстве случаев нашедший дефект black-box тестировщик самостоятельно не сможет отнести дефект к группе Соотношения или Технические. Вообще, скорее всего он будет относить почти все дефекты только к двум группам — Логические и Дизайнерские.
Получается затем ему придется выяснять у программиста или менеджера куда отнести дефект или следить за тем, чтоб эти ребята все проставили. То есть у трех ролей в команде с размаху появляется масса интересной работы, про которую надо еще и не забыть.
Второе. Очень важное. Поясните мысль:
выделить какие-то правила по нахождению, а для этого требуется классификация
Под нахождением здесь подразумевается поиск старых багов в трекере или поиск новых багов в продукте? Разница принципиальная.
Вы уже используете предложенную классификацию или только предложили ее нам?
Я использую интуитивно, базируясь на опыте, вот впервые решила этот как-то оформить словесно.
При попытке внедрить
Нет, пока нет предложения внедрять, пока это слишком сырой вариант. Скорее, на данный момент передо мной стоит цель уложить опыт и знания в какой-то тезис, на основании которого можно будет другим объяснять, учить, подсказывать, и самой это помогает быстрее сориентироваться еще при тест-дизайне.
поиск новых багов в продукте?
Я имела ввиду это, но поиск багов в трекере тоже интересная мысль!
Искать новые баги при помощи классификации старых — странная идея. Обычно для поиска новых используют классификацию рисков, это немного другое, хоть и близко.
Я бы предложил вам идти от юзкейсов. Что делают с багами и как поможет классификация. Поиск и расстановка приоритетов для починки — типовые кейсы, на мой взгляд.
Для поиска классификация должна быть непересекающейся, однозначной и запоминающейся (4-6 одинаково понятных всем пункта).
Для приоритетов — сложнее, зависит от процесса. Влияние на пользователя, ресурсы, требуемые для починки и так далее.
Я бы предложил вам идти от юзкейсов. Что делают с багами и как поможет классификация. Поиск и расстановка приоритетов для починки — типовые кейсы, на мой взгляд.
Для поиска классификация должна быть непересекающейся, однозначной и запоминающейся (4-6 одинаково понятных всем пункта).
Для приоритетов — сложнее, зависит от процесса. Влияние на пользователя, ресурсы, требуемые для починки и так далее.
4-6 одинаково понятных всем пункта
ВОт же ж, у меня 7 вышло… но про понятность у меня есть упущения, тут еще думать и думать.
Данные группы при анализе помогут выделить «слабые» места разработки проекта, как по мне. Впрочем, могу ошибаться. Потому приоритеты тут тоже могут быть затронуты, но это, действительно, сложнее. Но я над этим обязательно подумаю.
Спасибо за статью!
Данная классификация полезна, на мой взгляд, при поиске слабых мест в команде. Кого наградить, кого наказать.
За логические ошибки должен отвечать составитель ТЗ, а при отсутствии ТЗ — руководитель разработки, как допустивший разработку без ТЗ.
За технические — непосредственно программист.
За дизайнерские — дизайнер.
За ошибки соотношения (я бы их назвал ошибками интеграции) — системный архитектор, а при отсутствии такового — руководитель разработки, не наладивший взаимодействие между разными людьми.
За ошибки документации — составитель ТЗ или тех. писатель
За комбинированные ошибки — совокупность тех людей, которые их допустили. Например, за дизайнерско-техническую ошибку должны отвечать дизайнер и программист.
Остаются локализированные ошибки. В них виноваты третьесторонние разработчики, не обеспечившие одинаковые стандарты работы своего ПО
Данная классификация полезна, на мой взгляд, при поиске слабых мест в команде. Кого наградить, кого наказать.
За логические ошибки должен отвечать составитель ТЗ, а при отсутствии ТЗ — руководитель разработки, как допустивший разработку без ТЗ.
За технические — непосредственно программист.
За дизайнерские — дизайнер.
За ошибки соотношения (я бы их назвал ошибками интеграции) — системный архитектор, а при отсутствии такового — руководитель разработки, не наладивший взаимодействие между разными людьми.
За ошибки документации — составитель ТЗ или тех. писатель
За комбинированные ошибки — совокупность тех людей, которые их допустили. Например, за дизайнерско-техническую ошибку должны отвечать дизайнер и программист.
Остаются локализированные ошибки. В них виноваты третьесторонние разработчики, не обеспечившие одинаковые стандарты работы своего ПО
Кстати, да, Вы правы.
Но есть нюанс. Порой логические ошибки возникают там, где их не ждали. То есть редкий аналитик опишет задание так, чтобы предусмотреть все. ОН может даже не подумать, что ситуация может развернуться другим путем. Потому тут может и не быть виноватых.
За это отдельное спасибо!
Но есть нюанс. Порой логические ошибки возникают там, где их не ждали. То есть редкий аналитик опишет задание так, чтобы предусмотреть все. ОН может даже не подумать, что ситуация может развернуться другим путем. Потому тут может и не быть виноватых.
я бы их назвал ошибками интеграции
За это отдельное спасибо!
Действительно. Пока все будут перепихивать ошибку друг другу и решать кто за нее должен отвечать, тестировщику и отдохнуть можно.
Не вижу особого смысла решать, кто в чем виноват. Куда полезней — решить, кто и как будет чинить.
Ну за кроме самых крайних и особо выдающихся случаев (но в таких случаях обычно и так понятно, кто главный факапер, и отдельная классификация для этого не нужна).
Не вижу особого смысла решать, кто в чем виноват. Куда полезней — решить, кто и как будет чинить.
Ну за кроме самых крайних и особо выдающихся случаев (но в таких случаях обычно и так понятно, кто главный факапер, и отдельная классификация для этого не нужна).
Предлагаю рассмотреть такую классификацию:
1. Ошибки анализа
— данных (нелогичный протокол, ошибка в схеме данных)
— связей (компонент А не может эффективно или вообще работать с компонентом Б)
— требований (заказчик хотел одно, а в ТЗ или задачах для программиста напридумывали)
2. Ошибки дизайна
…
3. Ошибки реализации(баги продукта, воспроизводятся всегда и везде)
…
4. Ошибки выполнения(воспроизводятся на отдельном окружении)
— несоответствие среды
— частичное выполнение задачи
1. Ошибки анализа
— данных (нелогичный протокол, ошибка в схеме данных)
— связей (компонент А не может эффективно или вообще работать с компонентом Б)
— требований (заказчик хотел одно, а в ТЗ или задачах для программиста напридумывали)
2. Ошибки дизайна
…
3. Ошибки реализации(баги продукта, воспроизводятся всегда и везде)
…
4. Ошибки выполнения(воспроизводятся на отдельном окружении)
— несоответствие среды
— частичное выполнение задачи
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Альтернативная классификация багов