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

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

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

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

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

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

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

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

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

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

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

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

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

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

Итак, вот мое мнение:

• Автоматизация рутинных задач: вкалывают роботы, счастлив человек - да
• TPI NEXT: оптимизируем процесс тестирования по-взрослому - нет
• Команда, где каждый лидер - да
• Полезные "фишки" для построения успешного тестирования - да
• Собеседование тестировщиков: что спросить и как ответить - да
• Жизненный цикл коммуникативных дефектов - да
• Сессионное тестирование: совмещаем управляемость и творчество - да
• 10 советов художника тестировщику - да
• Как изменить мир, или как взять в свою команду тестировщика от Бога? - да
• Эффект горизонта в тестировании - нет
• Идеальный скринкастер для тестировщиков - да

Для затравки:

• When do we stop a test?
• When do we stop test: one more sure thing
• When do we stop testing (в слайдах)

спасибо ))

Не помню где, но неоднократно звучала мысль, что иногда нужно сказать "стоп" и завершить тестирование. Как вы думаете стоит ли прекращать тестирование какого-то объема функционала, если даже программа работает, вроде все хорошо. Если да, то по каким признакам можно понять, что время пришло? ))

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

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

1) Не все люди одинаково адекватны. С кем-то мы не можем договориться потому, что сами неправильно что-то делаем, а с кем-то - потому, что они ну вот такие. Твой случай ИМХО второй!

2) Каким бы проблемным ни был заказчик, тестирование всё равно надо стараться делать максимально грамотным! Продукт и пользователи не виноваты!

3) Ты один из самых талантливых и конструктивных тестировщиков и тест-менеджеров, которых я встречала. А ещё и коммуникатор отличный! Ну кто ещё справится с такой нетривиальной ситуацией, если не ты?

захвалишь

Стараюсь относится к этому с умом, но разве не стоит попробовать объяснить человеку, в чем весь затык произошел? Быть может, если до него донести весь смысл произошедшего, может такое и вовсе не произойдет или же это бесполезно и не стоит тратить на это время и силы?

В общем, старайтесь понять проблемы заказчика и показывайте ему, что вы понимаете его проблемы. Тогда он начнёт прислушиваться к вам, и тогда можно будет говорить не об оправданиях и не об объяснении причин, почему что-то было сделано плохо, а о совместном поиске решения в возникшей ситуации.

Спасибо за конструктивный ответ :)

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

Эх, видно действительно ничего с этим не сделать. Значит будем учится выключать эмоции :)

Можете, конечно, попробовать. Но опыт подсказывает, что донести мысль до иностранца, который заказывает музыку (а значит, платит за неё) бывает катастрофически сложно. Зато можно испортить отношения с человеком, если начать ему перечить и указывать на его просчёты.

То есть проще все выслушать, проанализировать, сделать выводы и забыть?

Был такой опыт. Правда не от заказчика, а от руководства в одно время.
Совет только один, вероятно. Относитесь к этом филофски и дышите глубже))

Стараюсь относится к этому с умом, но разве не стоит попробовать объяснить человеку, в чем весь затык произошел? Быть может, если до него донести весь смысл произошедшего, может такое и вовсе не произойдет или же это бесполезно и не стоит тратить на это время и силы?

После очередной порции негатива со стороны заказчика у меня родилось несколько вопросов:
У всех ли случаются такие ситуации, когда идут обвинения, не подкрепленные фактами?
Как можно разрулить такие ситуации и при этом остаться в хорошем настроении?
Есть ли какие методы, чтобы вообще не допускать таких ситуаций?

Поделитесь советами, буду очень благодарна :)