Проблемы с локализацией багов

Который раз замечаю за собой, что локализация багов у меня все-таки страдает. Что можно предпринять, чтобы усовершенствовать данный навык?

То, что надо тренироваться, тренироваться и тренироваться - это мне и так понятно. Меня интересует, если какие методы, которые существенно помогут улучшить локализацию?

Который раз замечаю за собой, что локализация багов у меня все-таки страдает. Что можно предпринять, чтобы усовершенствовать данный навык?

То, что надо тренироваться, тренироваться и тренироваться - это мне и так понятно. Меня интересует, если какие методы, которые существенно помогут улучшить локализацию?

Главное правило в локализации:
1. писать то, что ты видишь, а не понимаешь.

например у нас:
gangsters - в нашем приложении это аналог энергии, штучка которая тратится при клике на какой-то обьект.

но есть еще energy - аналогичная штучка которая тратится при попытке поломать /убить что-то.

в описании багов часто встречаю:

воспроизведение:
..
3. потратить 10 энергии из 20 возможных...

все. ступор.
какой энергии?
куда потратить?

правильно будет писать так:
3. потратить 10 gangsters из 20 возможных.

сразу понятно какая энергия, и что потратить ее можно только на сбор обьектов.

2. краткость
но без фанатизма

вариант с ошибкой:
1. войти на страницу входа в игру
2. ввести логин Аватар и пароль 12345
3. нажать кнопку "войти"
4. нажать кнопку "Играть"
5. дождаться входа в игру
6. войдя в игру ...
(дальше воспроизведение бага который ни малейшего отношения к авторизации не имеет вообще)

правильный вариант.
1.сразу воспроизведение бага

не нужно описывать как вы пошли к холодильнику, сделали бутерброд, как не нашли сахара, наступили на хвост кошке, пришли к компу, а там БАГ!

3. правильное название.
не маловажно.
из названия вашего бага должно быть понятно о чем он.

Неправильный вариант:
При открытии вулбуфера не отправляется трава другу

Правильный вариант
Не отправляется бонусный обьект при клике по вулбуферу.


Но это все элементарные вещи. Я все же думаю у вас проблема не в этом. Можно какие-нибудь примеры?

Но это все элементарные вещи. Я все же думаю у вас проблема не в этом. Можно какие-нибудь примеры?

Со всеми советами, что были приведены выше я согласна, знакома и научилась применять в жизни.
Моя проблема заключается в том, что я нашла ошибку, как мне показалась нашла в чем ее причина. Данная ошибка оформляется по всем правилам и отправляется на исполнителя.

Например, есть такое условие, что если ячейка не заполнена элементом, который должен быть воспроизведен, то данная ячейка должна быть проигнорирована и пропущена. А если в ней есть элемент - то быть залочена и проиграна.) Я нахожу эту багу, что ячейка не пропускается, когда она остается незаполненной. Несколько раз воспроизвожу и уверена, что причина именно в том, что данное условие не выполняется. Завожу багу по всем нормам, отправляю на девелопера.

Проходит время и мне возвращают багу с комментарием, что она будет исправлена, а причина ошибки совершена в другом, а не в том, что указана в тикете. В данном случае был виноват фильтр, который зашит внутри кода, который требуется девелоперу для реализации других сторонних задач.

Так вот и получается, что бага все-таки локализована была неправильно

Проходит время и мне возвращают багу с комментарием, что она будет исправлена, а причина ошибки совершена в другом, а не в том, что указана в тикете. В данном случае был виноват фильтр, который зашит внутри кода, который требуется девелоперу для реализации других сторонних задач.

Радуйтесь! Далеко не все программисты вам возвращают багу с комментом, где же она реально была. Некоторые просто правят. И даже на прямые вопросы "в чем там дело было то??" не отвечают.

Записывайте отдельно пропущенные задачи, анализируйте их => будете глубже погружаться в продукт, зная. что на что может повлиять, хотя, "казалось бы... ". Вообще тут тоже надо учитывать, кому проще время потратить.

Если вы нашли абсолютно точные шаги для выполнения баги - это уже хорошо!
И подумайте, вам копать, что там случилось. И программисту, который за 5 минут продебажит.

Если соотношение трудозатрат наоборот - вам проще локализовать, то опять же, анализируйте тщательнее :)

Проходит время и мне возвращают багу с комментарием, что она будет исправлена, а причина ошибки совершена в другом, а не в том, что указана в тикете. В данном случае был виноват фильтр, который зашит внутри кода, который требуется девелоперу для реализации других сторонних задач.

Радуйтесь! Далеко не все программисты вам возвращают багу с комментом, где же она реально была. Некоторые просто правят. И даже на прямые вопросы "в чем там дело было то??" не отвечают.

В таком случае я обычно стараюсь добиться хотя бы устного ответа в чем была причина бага. И за редким исключениям разработчики всегда дают нормальный ответ. Хотя это уже момент коммуникаций между отделами.

В таком случае я обычно стараюсь добиться хотя бы устного ответа в чем была причина бага. И за редким исключениям разработчики всегда дают нормальный ответ. Хотя это уже момент коммуникаций между отделами.

"Я не знаю!" мало похоже на момент коммуникаций между отделами :) Но бывает!

Проходит время и мне возвращают багу с комментарием, что она будет исправлена, а причина ошибки совершена в другом, а не в том, что указана в тикете. В данном случае был виноват фильтр, который зашит внутри кода, который требуется девелоперу для реализации других сторонних задач.

Так вот и получается, что бага все-таки локализована была неправильно

Изучайте используемые технологии, изучайте внутреннее устройство продукта. Со временем придет понимание как оно работает, как оно устроено. Выгода, кстати, не только в том, что вам будет проще локализировать и описывать проблемы (а в ряде случаев и фиксить всякую мелочь), но и в том, что вы получите отличный дополнительный арсенал для моделирования отказов и сбоев.

Изучайте используемые технологии, изучайте внутреннее устройство продукта. Со временем придет понимание как оно работает

Продукт изучается, знания совершенствуются, но хотелось бы использовать возможности по максимуму и по-максимуму облегчать процесс испоавления баг.

Но это все элементарные вещи. Я все же думаю у вас проблема не в этом. Можно какие-нибудь примеры?

Со всеми советами, что были приведены выше я согласна, знакома и научилась применять в жизни.
Моя проблема заключается в том, что я нашла ошибку, как мне показалась нашла в чем ее причина. Данная ошибка оформляется по всем правилам и отправляется на исполнителя.

Например, есть такое условие, что если ячейка не заполнена элементом, который должен быть воспроизведен, то данная ячейка должна быть проигнорирована и пропущена. А если в ней есть элемент - то быть залочена и проиграна.) Я нахожу эту багу, что ячейка не пропускается, когда она остается незаполненной. Несколько раз воспроизвожу и уверена, что причина именно в том, что данное условие не выполняется. Завожу багу по всем нормам, отправляю на девелопера.

Проходит время и мне возвращают багу с комментарием, что она будет исправлена, а причина ошибки совершена в другом, а не в том, что указана в тикете. В данном случае был виноват фильтр, который зашит внутри кода, который требуется девелоперу для реализации других сторонних задач.

Так вот и получается, что бага все-таки локализована была неправильно

Я думаю, большинству тестировщиков было бы полезно попрограммировать. Думаете программист сам догадался что виной всему фильтр? :) Ммм, вряд ли. Скорее всего он увидел это в режиме отладки. Изучать и локализировать баги дело конечно полезное, но то, что мы, будем искать 2 часа, перебирая разные комбинации входных параметров в черном ящике, можно найти под дебагом через 2 минуты (ну за исключением некоторых специфических языков и ситуаций)
Так что я считаю, что достаточно шагов воспроизведения, при которых баг повторяется 100%

Продукт изучается, знания совершенствуются, но хотелось бы использовать возможности по максимуму и по-максимуму облегчать процесс испоавления баг.

Исправьте баги сами , это облегчит процесс на 100% :)

У меня иногда возникают трудности с локализацией критических багов, или сразу завожу в багтрекер из-за их срочности, но с неточной локализацией, или наборот, пытаясь локализовать как можно точнее, торможу. Нечто среднее получить не всегда удается.

хм... я не понимаю.
Локализовать баг программисту -- это значит посидел он в дебаггере, и понял что вот конкретно в этих строчках кода (каковые относятся к конкретной функции..объекту и тыпы ) сделана ошибка.

А локализовать баг тестировщику? Это значит посидеть-тесты погонять и сказать --- вот при таких-то действиях или входных данных получается баг.

Я так понимаю.

А локализовать баг тестировщику? Это значит посидеть-тесты погонять и сказать --- вот при таких-то действиях или входных данных получается баг.

Формально, если по описываемым действиям действительно стабильно появляется баг, то тестировщик свою работу выполнил и может спокойно писать репорт. Другое дело, что этот баг может быть следствием другого бага, либо некоторые из указанных в описании входных параметров необязательны и т.п.
Уточнение деталей в этом случае помогает:

• Быстрее локализовать дефект на уровне кода (разработчику)
• Найти другие баги, которые являлись причиной найденного.
• Сэкономить время разработчика на починку связанных дефектов, которые исчезнут сами после фикса основного бага.

Ну а вообще, дефекты вида "Не отрабатывает ajax-запрос на записях с NULL в таблице REFERENCES" нравятся разработчикам на порядок больше, чем описание "крутится круглый значок и ничего не появляется". Хотя конечно всегда приходится искать баланс между своим временем и трудозатратами разработчиков.

Ну а вообще, дефекты вида "Не отрабатывает ajax-запрос на записях с NULL в таблице REFERENCES" нравятся разработчикам на порядок больше, чем описание "крутится круглый значок и ничего не появляется". Хотя конечно всегда приходится искать баланс между своим временем и трудозатратами разработчиков.

Баги вида "НИЧЕГО НЕ РАБОТАЕТ!" (общий случай бага "крутится круглый значок и ничего не появляется") это в худшем случае совершенно бесполезная паника (читать как "вредительство"), а в лучшем просто флажок вида "копать тут". ответ на вопрос кому копать во многом зависит от задач, которые ставятся. Если нужно посмотреть (поверхностно) как можно больше в сжатые сроки - тогда копать разработчику (тут, правда, предполагается что его время не казенное). Если нужно искать проблемы, причем проблемы серьезные - копать тестировщику.

Я счас скажу дикие вещи :
в ваши обязанности входит тестирование на уровне кода?

т.е. если вы нашли баг, воспроизвели его, описали, описание такое что по нему можно воспроизвести? - вы свою задачу сделали.

Программист зашел , посомтрел ваше описание, и говорит нет, это не потому что там вот это окошко всплывает, а потому что мы слеш дето провтыкали.

Вы не ясновидящая, не гадалка, и не программист.
Вы нашли, описали, программист увидел у себя ошибку исправил -окей.

Бывают случаи когда воспроизведений несколько.
вы пишите одно, а программист находит другое - но оба работают. оба воспроизводят. пусть даже пофиксить достаточно только тот, что нашел программист.


Каждый должен заниматься своим делом.

Да, если у вас есть желание, возможность и время для вникания в продукт до уровня разработчика - это круто.
Но если я вникну до уровня разработчика - может я и фиксить сама буду?
что будет в итоге?
я стану разработчиком.
вы этого хотите?
вам это нужно - окей, вперед.

Я не считаю в данном случае что вы неправильно локализовываете баг, у вас недостаточно информации как это работать ДОЛЖНО, как это работает.

И в вашем случае 100% программисту открыть и увдеть где у него баг проще было в разы, нежели вам догадаться.

Да, бывают баги которые вы в теории могли понять в чем причина, но ошиблись, тут другое.
Но вот так страдать из-за того что вы не догадались, что в коде какой - то программист нарисовал гоблина из циферок и у вас что-то упало, при этом воспроизводится каким то феерическим способом - ой.


Но опять же если в ваших обязанностях есть тестирование белого-серого ящиков - то все выше сказанное верно, трабл ваш.
И тут только вникать изучать и трясти разработчиков если что-то не понятно.

Например, есть такое условие, что если ячейка не заполнена элементом, который должен быть воспроизведен, то данная ячейка должна быть проигнорирована и пропущена. А если в ней есть элемент - то быть залочена и проиграна.) Я нахожу эту багу, что ячейка не пропускается, когда она остается незаполненной. Несколько раз воспроизвожу и уверена, что причина именно в том, что данное условие не выполняется. Завожу багу по всем нормам, отправляю на девелопера.

Проходит время и мне возвращают багу с комментарием, что она будет исправлена, а причина ошибки совершена в другом, а не в том, что указана в тикете. В данном случае был виноват фильтр, который зашит внутри кода, который требуется девелоперу для реализации других сторонних задач.

Спорно, с моет точки зрения.
Если бы Вы отфильтровали ячейки по какому-то критерию, и Ваш баг повторялся только для них, а Вы про фильтр в баге не указали - тогда да. Но в Вашем случе фильтр зарыт в коде. Т.е., Вы сами про него первый раз узнали, когда комментарий к багу прочитали, так ведь? Как Вы могли это знать, если не смотрите в код? И... Вот Вам про такой фильтр сказали. Хорошо. В будущем, описывая другой баг, не глядя в код, сможете распознать, что именно этот фильтр в коде создаёт проблему?
В общем... Думаю, проблема надумана.

Например, есть такое условие, что если ячейка не заполнена элементом, который должен быть воспроизведен, то данная ячейка должна быть проигнорирована и пропущена. А если в ней есть элемент - то быть залочена и проиграна.) Я нахожу эту багу, что ячейка не пропускается, когда она остается незаполненной. Несколько раз воспроизвожу и уверена, что причина именно в том, что данное условие не выполняется. Завожу багу по всем нормам, отправляю на девелопера.

Проходит время и мне возвращают багу с комментарием, что она будет исправлена, а причина ошибки совершена в другом, а не в том, что указана в тикете. В данном случае был виноват фильтр, который зашит внутри кода, который требуется девелоперу для реализации других сторонних задач.

Спорно, с моет точки зрения.
Если бы Вы отфильтровали ячейки по какому-то критерию, и Ваш баг повторялся только для них, а Вы про фильтр в баге не указали - тогда да. Но в Вашем случе фильтр зарыт в коде. Т.е., Вы сами про него первый раз узнали, когда комментарий к багу прочитали, так ведь? Как Вы могли это знать, если не смотрите в код? И... Вот Вам про такой фильтр сказали. Хорошо. В будущем, описывая другой баг, не глядя в код, сможете распознать, что именно этот фильтр в коде создаёт проблему?
В общем... Думаю, проблема надумана.

Это пример лишь и не совсем удачный. Суть поста в том, что хотелось бы иметь какой-то инструмент (если таковой имеется), чтобы лучше локализовывать баги.

Но в основном я поняла мысль - нужно тренироваться и лучше узнавать продукт, который тестируется.

Да, если у вас есть желание, возможность и время для вникания в продукт до уровня разработчика - это круто.
Но если я вникну до уровня разработчика - может я и фиксить сама буду?
что будет в итоге?
я стану разработчиком.
вы этого хотите?
вам это нужно - окей, вперед.

Вы не поверите, но читать код и писать код это две большие разницы.

ЗЫ: У меня нет должностной инструкции. У меня теперь нет обязанностей? Или есть? Можно я буду считать что мои обязанности это кушать пончики и смотреть телек? "Если в ваши обязанности не входит..." - аж ругаться хочется от такого рудимента.

Суть поста в том, что хотелось бы иметь какой-то инструмент (если таковой имеется), чтобы лучше локализовывать баги.

Основной инструмент тестировщика это его мозг. Все остальные инструменты применяются когда мозга уже явно недостаточно (я не про наркотики!)

Если нужно посмотреть (поверхностно) как можно больше в сжатые сроки - тогда копать разработчику (тут, правда, предполагается что его время не казенное). Если нужно искать проблемы, причем проблемы серьезные - копать тестировщику.

Ну в общем да, and what are you talking about, как говорится. Иногда надо копать самому, ибо разработчик может и сутки провозиться, просто пытаясь воспроизвести баг у себя, а приходилось и табличку ставить с надписью "Здесь баг", ибо тестировщиков и времени мало, а разработчиков много.