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