Коммуникация в команде тестировщиков

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

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

Интересно возникала-ли такая проблема у кого-то еще? А особенно интересно, как вы ее решаете...

Проблема решается чтением нотификаций о новых ошибках и устным общением с коллегами.

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

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

Интересно возникала-ли такая проблема у кого-то еще? А особенно интересно, как вы ее решаете...

Еще (в дополнение к первому ответу) надо писать баги так, чтобы они находились легко. Хорошо если все в команде оперируют одними терминами. Но когда есть синонимы, старайтесь употребить оба: например context или pop-up menu. Надо адресовать баги в трэкере на правильные подсистемы. Можете использовать систему кейвордов в трэкере (если есть). Если тестируете по сценариям, то прописывыйте номера найденых багов прямо туда. Тогда следующий человек, кто будет гонять тесты по этому описанию, увидит перед собой номер дефекта, а заодно может и заверифицирует, если уже нет такого бага в продукте.

Дубликаты конечно все-равно будут и баги повторно будут находиться. Иногда при повторном натыкании на баг проводится более полный анализ другим человеком, что есть хорошо.
У нас кстати, было специальное поле в дефект-трэкере (votes вроде бы), если кто-то находил баг повторно(или писал дубликат) это поле увеличивалось на 1. Косвенно отражалось на приоритете - баги с большим количеством votes были важнее, чем с меньшим.

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

Очень правильно говорит LeshaL о правильном описании дефектов.

Рекомендация. Найдите/ купите / выпросите / ... запись моего семинара по описанию дефекта. Запись существует в двух вариантах: слайдкаст (http://trainings.sof...logue/online/47) и видео (http://www.training-...urs/detail/304/).

Варианты получения:
1) обратиться к Наталье Баранцевой
2) обратиться в УЦ Люксофт

1) Оговоренные ключевые слова. Совместно с командой составьте список ключевых слов (ограниченный, максимум слов 40), который содержит названия функциональных областей и типы проблем (usability, performance, crash, etc.) Согласуйте использование этих слов в списке ключевых или заголовке - это существенно упростит поиск.
2) В больших командах я лично использую премодерацию дефектов: по каждой функциональной области есть ответственный, который просматривает баги перед их переводом в девелопмент. Он оценивает корректность бага и его уникальность - учитывая, что все баги в этой области проходят через него, он их помнит и может эффективно искать.
3) А всегда ли дубликаты - плохо? Если есть небольшой процент дубликатов, на который команда тратит небольшое время, то цена проблемы небольшая, в то время как цена решения может быть слишком высокой и неоправданой. Иногда эффективнее объяснить смежным подразделениям, что небольшой процент дубликатов - это данность, в которой нет ничего страшного.

1) Оговоренные ключевые слова. Совместно с командой составьте список ключевых слов (ограниченный, максимум слов 40), который содержит названия функциональных областей и типы проблем (usability, performance, crash, etc.) Согласуйте использование этих слов в списке ключевых или заголовке - это существенно упростит поиск.
2) В больших командах я лично использую премодерацию дефектов: по каждой функциональной области есть ответственный, который просматривает баги перед их переводом в девелопмент. Он оценивает корректность бага и его уникальность - учитывая, что все баги в этой области проходят через него, он их помнит и может эффективно искать.
3) А всегда ли дубликаты - плохо? Если есть небольшой процент дубликатов, на который команда тратит небольшое время, то цена проблемы небольшая, в то время как цена решения может быть слишком высокой и неоправданой. Иногда эффективнее объяснить смежным подразделениям, что небольшой процент дубликатов - это данность, в которой нет ничего страшного.

Полностью согласна с Натальей. По пункту 2) дополню - еще удобно, если есть ответственный за тестирование определенной функциональности. При такой специализации ответственный (-ые) помнит какие баги он репортил. И даже если тестирование проводит не он, то такой подход сужает круг людей, к которым можно (нужно) обратиться. Хотя при мануальном и неформальном методе работы часть багов останется ненайденными при exploratory testing

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

Это реально хорошая штука. Работал в такой ситуации на заре своей карьеры. Состояние дефект трэкера получается прям на загляденье. Да и разработчикам меньше хреновых описаний достается (что их эффективность их работы, по идее, повышает). Но есть НО, как обычно.
Модерировать должен опытный товарищ. Обычно таких опытных товарищей в тестировании еще и поискать надо. Поэтому сидит такой человек и модерирует не одну функциональную область, а треть или половину всего проекта. А это его время отнимает. Мама не горюй сколько времени. Плюс такой модератор должен обладать определенным складом характера. Сам пробовал, не очень-то получалось.

1) Оговоренные ключевые слова. Совместно с командой составьте список ключевых слов (ограниченный, максимум слов 40), который содержит названия функциональных областей и типы проблем (usability, performance, crash, etc.) Согласуйте использование этих слов в списке ключевых или заголовке - это существенно упростит поиск.
2) В больших командах я лично использую премодерацию дефектов: по каждой функциональной области есть ответственный, который просматривает баги перед их переводом в девелопмент. Он оценивает корректность бага и его уникальность - учитывая, что все баги в этой области проходят через него, он их помнит и может эффективно искать.
3) А всегда ли дубликаты - плохо? Если есть небольшой процент дубликатов, на который команда тратит небольшое время, то цена проблемы небольшая, в то время как цена решения может быть слишком высокой и неоправданой. Иногда эффективнее объяснить смежным подразделениям, что небольшой процент дубликатов - это данность, в которой нет ничего страшного.

По 1) - Это называется системой тэгов (Tags)
По 2) - Это всё решается грамотным выставлением приоритетов тестовым сценариям, в начале ошибки пишется какой сценарий выполнялся. Так будет легче аналитику(если вы считаете, что он действительно нужен в данном проекте) и разработчику.
По 3) - Это решается связыванием ошибки и функционала (Feauture, User Story, Task).

По 1) - Это называется системой тэгов (Tags)
По 2) - Это всё решается грамотным выставлением приоритетов тестовым сценариям, в начале ошибки пишется какой сценарий выполнялся. Так будет легче аналитику(если вы считаете, что он действительно нужен в данном проекте) и разработчику.
По 3) - Это решается связыванием ошибки и функционала (Feauture, User Story, Task).

1. Это все-таки ключевые слова (keywords)
2. Что делать если тестирование проводится без сценариев? Что если баг воспроизводится на нескольких десятках сценариев (интерфейсный например)?
3. Это не решит проблему дубликатов. Проблема дубликатов нерешаема в принципе, можно лишь уменьшить частоту их появления.

По 1) - Это называется системой тэгов (Tags)
По 2) - Это всё решается грамотным выставлением приоритетов тестовым сценариям, в начале ошибки пишется какой сценарий выполнялся. Так будет легче аналитику(если вы считаете, что он действительно нужен в данном проекте) и разработчику.
По 3) - Это решается связыванием ошибки и функционала (Feauture, User Story, Task).

1. Это все-таки ключевые слова (keywords)
2. Что делать если тестирование проводится без сценариев? Что если баг воспроизводится на нескольких десятках сценариев (интерфейсный например)?
3. Это не решит проблему дубликатов. Проблема дубликатов нерешаема в принципе, можно лишь уменьшить частоту их появления.

1. Tag (metadata), a keyword or term associated with or assigned to a piece of information. [en.wiki]
2. Если вы проводите Ad-hoc(интуитивное) тестирование, то после него заводятся тест-кейсы по найденным ошибкам, обычно.
3. Обычно они сразу же удаляются разработчиками или вторым тестировщиком, который проверяет данную функциональность в другой среде, когда они разделены по некоторым контейнерам, как я написал выше.

Добавлено:

Что если баг воспроизводится на нескольких десятках сценариев (интерфейсный например)?

Интерфейсный - GUI? Прикрепляется к нужной User Story или таску. Всё зависит от того как правильно вы спланировали весь процесс. Эти проблемы решаемы. Конечно, всё зависит от конкретной ситуации.

P.S. Поверьте, в написанном мною тексте нет никакого негативного оттенка.

1. Tag (metadata), a keyword or term associated with or assigned to a piece of information. [en.wiki]
2. Если вы проводите Ad-hoc(интуитивное) тестирование, то после него заводятся тест-кейсы по найденным ошибкам, обычно.
3. Обычно они сразу же удаляются разработчиками или вторым тестировщиком, который проверяет данную функциональность в другой среде, когда они разделены по некоторым контейнерам, как я написал выше.

Добавлено:

Что если баг воспроизводится на нескольких десятках сценариев (интерфейсный например)?

Интерфейсный - GUI? Прикрепляется к нужной User Story или таску. Всё зависит от того как правильно вы спланировали весь процесс. Эти проблемы решаемы. Конечно, всё зависит от конкретной ситуации.

P.S. Поверьте, в написанном мною тексте нет никакого негативного оттенка.

1. Я думаю теперь вам и самому из определения должно быть видно, что ваша поправка не имеет никакого смысла :) Как бы мой комментарий по стилю был такой же как и ваш.
2. Не факт. Ну, представьте, что базы тест-кейсов нет, и мы их вообще в принципе не пишем (считаем бесполезной тратой времени). Такое часто встречается :)
3. Не важно, что с ними происходит после их обнаружения. Посыл в том, чтобы уменьшить вероятность их появления. другой стороны, в дубликатах можно найти и положительные моменты - например, их появление намекает, что бага легко воспроизводимая и её возможно стоит пофиксать поскорее. :)

P.S.: Добавил в каждый пункт по смайлику.