Сообщений в теме: 32

[caboverde]

Здравствуйте
Я в тестировании человек новый, хочу с опытными и знаюшими обсудить ситуацию сложившуюся у нас на проекте. В команде нашей 4 чел. + старший группы(играюший тренер). Ежедневно мы сдаём отчеты о сделанных тестах и описания найденных багов.
Старший всё ето собирает в один документ и раз в 2 дня заседает с разработчиками на предмет продвижения проекта и статуса проверок. Т.к тестеры делают ротацию- меняются тестами чтобы каждый мог лучше познакомиться со всей системой. Они начинают подавать уже открытые кем-то ранее баги(на сегодня открыто несколько сот штук) Разработчики етим недовольны, начальник проекта настаивает на выучвании тестерами всех открытых багов. Всвязи с етим вопрос: как боротся с "даблами"? Как их отсеивать? Какая практика наиболее еффективна и приемлема в описанной мною ситуации? :help:
Спасибо

[dlg99]

практики, работающие у нас:

0. 'shared understanding' pattern
общее понимание необходимости происходящего, вреда дубликатов.

1. 'unified bug description' pattern.
- В описание багов включаются "ключевые слова", облегчающие поиск позже (названия задетых подсистем, окон и т.п.).
- Для описания проблем используются "стандарный" набор слов, т.е. не случается ситуаций, когда один пишет "crashed", другой - "terminated", а третий - "died" :)

2. 'Search before addition'/'doublecheck' pattern
перед тем как добавить баг, каждый обязан search BTS for existing bugs.
если за 2-3 попытки не нашел - можно добавлять.
Исключение - новая feature которую никто еше не тестировал.

3. 'root analysis' patern

Обсуждение возможных причин появивления дубликата.
- нарушено правило номер 0
- существовавший баг нарушал правило номер 1 (почему?)
- автор нового бага (или старого?) не понимал какие посистемы задеты, использовал неправильные "ключевые слова" для поиска (описания бага?)
- нарушено правило номер 2
- что-то еще

По результатам - "ликбез" по продукту, процессу и т.п.


4. 'not 100% sure' pattern
в помощь девелоперам ставить cross-references между похожими багами, на случай если это разные проявления одной проблемы, но "сходу" (например, без дебаггера) это не определить.

Количество дубликатов при использовании этих практик сокращается.
О полном избавлении не говорю, иначе на п.2 или подобные activity начинает уходить нецелесообразно много времени.

Если что-то не так, то пусть "товарищи поправят" :-)

[I_G]

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

[serega]

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

[Vasiliy]

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

[Romich]

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

[caboverde]

наш старший просто сливает все описания багов и линки на иллюстрации в таблицу Excel. Тблица доступна всем. Можно впринципе там искать, но поиск затруднен свободным стилем описания багов разными/разношёрстными авторами

[Nadezhda]

Если я правильно поняла исходный пост, то проблема состоит в том, что в отделе не применяется какая-либо BTS, а описания бага сдаются в отчетах. В таком случае я не только не представляю, как можно отслеживать дубликаты, но и как вообще ведется жизненный цикл бага: как тестировщики узнают, что баг починен и его нужно проверить, что делают, если при проверке обнаружено, что баг не починен? Единственной рекомендацией в таком случае может быть внедрение BTS.
Однако, если BTS все-таки применяется, то в добавок к предыдущим постам могу рассказать, как мы боремся с дубликатами. Мы ведем чеклист в Excel, где каждая строчка - это тест, каждый лист - это версия. Если в ходе проведения теста обнаружена ошибка, то ее номер в BTS мы записываем в ячейку напротив теста. Когда мы получаем новую версию, мы создаем новый лист в Excel посредством копирования последнего. Таким образом, в ячейке напротив каждого теста накапливаются номера багов. В результате, если в ходе проведения теста обнаружена ошибка, мы просматриваем баги в BTS с номерами, указанными для данного теста, и вероятность добавления дубликата значительно снижается.

[Clauster]

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

Вам не кажется это нерациональным? Баги могут быть закрыты, их может быть очень много и т.п. Т.е. временные затраты на просмотр багов окупаются?
Лично моё мнение, если количество дубликатов в районе 5-7%, с этим можно спокойно жить и работать. У нас пока хватает поиска похожего бага перед добавлением и нотификации о добавленных багах.

[van]

Добрый день!

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

1. Использование системы отслеживания ошибок (BTS).

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

3. Структурированное хранение ошибок (запросов). Например, создание подзапросов или подошибок. В случае необходимости, облегчает поиск за счет сужения области поиска.

4. Создание в BTS некоторого набора свойств (например, компоненты, объекты системы и т.п.), которые также позволяют оперативно искать и просматривать ошибки в достаточно узкой области.

5. Формирование заголовка ошибок в строго определенном формате.

6. Распараллеливание работ при планировании таким образом, чтобы функциональность поминимуму пересекалась.

[Mila]

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

В дополнение к вышеперечисленному:
Фактически вы не до конца передаете дела друг другу. Имеет смысл читать все открытые баги, найденные предшественником. Так же передавая кусок системы можно делать сводный отчет о проблемах за период, в который включаются все баги, по которым шло дополнительное обсуждение требований, плохо просмотренные места и т.п. За один день по такому отчету вполне можно суметь "вьехать в тему"

[SALar]

Всвязи с етим вопрос: как боротся с "даблами"? Как их отсеивать? Какая практика наиболее еффективна и приемлема в описанной мною ситуации? 

1. Учитесь описывать баги. На мой взгляд, ключевая практика. Тексты описаний (или по крайней мере названия) по одной ошибке у всех тестеров должны быть примерно одинаковы. Эта практика также помогает программистам анализировать ошибки. Вложения в обучение описанию окупаются многократно.
По моему опыту, после года работы и непрерывного анализа, обучения и конроля, все тестеры начинают писать примерно одинаково. Не надейтесь, что вы достигнете этого за три месяца. Это утопия. Но через месяц это обучение уже начнет приносить дивиденты.

2. Кусочек работы с одним исполнителем. Разбейте систему на части. Примите за правило, что в один день каждую часть тестирует не более одного тестера.

3. Пользуйтесь поиском.

4. Контроль обстановки. В конце рабочего дня или просто в перерывах между работой просматривайте дефекты внесенные остальными тестерами. Делайте это каждый день. Достаточно если это будет делать ведущий тестировщик проекта.
Для остальных просмотр чужих описаний поможет выработке единого стиля, см. [1].

наш старший просто сливает все описания багов и линки на иллюстрации в таблицу Excel. Тблица доступна всем. Можно впринципе там искать, но поиск затруднен свободным стилем описания багов разными/разношёрстными авторами

Вам очень поможет внедрение систему управления дефектами. Критерием перехода на нее и отказа от фиксации ошибок в Excel/ новостных лентах/ форумах будет рубеж 100-200 дефектов.

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

Не рекомендую. Постоянно сыплющиеся письма в течении рабочего дня - очень отвлекают. Если вам известен термин "час сосредоточения", то я именно о нем. Потоки информации должны быть разделены по каналам в зависимости от срочности:
* Требующие мгновенного (до 15 мин) реагирования
* быстрого до 4 часов
* ... и т.д.
Оставьте почте критерий "быстро".

Лично моё мнение, если количество дубликатов в районе 5-7%, с этим можно спокойно жить и работать. У нас пока хватает поиска похожего бага перед добавлением и нотификации о добавленных багах.

Согласен с оценкой. 5-7% - риск оптимум при значительном числе (300-3000) багов. Не пытайтесь достигнуть одного процента. Это невыгодно!

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

[van]

Сергей, думаю, что это даже полезно :)

В своей практике тестирования я придерживаюсь следующих принципов:
- больше - не меньше
- повторение - мать учения
:)

[dlg99]

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

т.е. на каждые 5 тестировщиков - выделенного full time "читателя багов"?
забавно.

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

не все баги фиксаются в ближайшем релизе.
людей полезно слегка 'rotate' между тестируемыми областями, что бы избежать "эффекта замыленного глаза" (или как там оно называется).
+ приходят новые люди, иногда уходят старые.
А заболевшего товарища подменять никогда не приходилось?

нелепо игнорировать предыдущий опыт/результаты

В своей практике тестирования я придерживаюсь следующих принципов:
- больше - не меньше
- повторение - мать учения

т.е. каждый баг в трех экземплярах, превентивно?

[caboverde]

1. Учитесь описывать баги. На мой взгляд, ключевая практика. Тексты описаний (или по крайней мере названия) по одной ошибке у всех тестеров должны быть примерно одинаковы. Эта практика также помогает программистам анализировать ошибки. Вложения в обучение описанию окупаются многократно.
По моему опыту, после года работы и непрерывного анализа, обучения и конроля, все тестеры начинают писать примерно одинаково. Не надейтесь, что вы достигнете этого за три месяца. Это утопия. Но через месяц это обучение уже начнет приносить дивиденты.

Хочу учиться оптимально описывать баги, где и как ето сделать?

[Damir]

Вообще любое приложение можно разбить на какие-либо функциональности (К примеру: Регистрация, главная страница, страница с товарами, страница поддержки и т.п.). Далее в BTS (Например в JIRA) можно добавить специальное поле, которое будет включать в себя список функциональностей, тех самых, на которые разбито приложение. Далее все просто, если тестер начинает тестирование регистрации, то при нахождении бага, он всегда может просто составить запрос, в котором будут присутствовать все открытые баги в регистрации, а далее искать по ним уже будет совсем просто. В больших приложениях, где количество багов более 1000 - проверено, работает. Парных багов было всего лишь несколько штук, да и то связанных с тем, что пришел новый человек, который не пользовался поиском - научили, дубликаты исчезли.

[caboverde]

Тестируем мы систему CRM/Billing компании связи. Всвязи с етим хочу спросить есть ли у кого подобный опыт, каковы специфические моменты тестирования систем CRM? Мне кажется наши тесты а их сейчас около 500 не покрывают всей функциональности, она очень разветвлённая.
Например, параллельно с нами тестируют по-переменно юзеры етой системы из самых различных подразделений (продаюшие, поддерживаюшие, агенты, управленци и т.п) Девочка из продаж открывает баг - "система продала пакет услуг "А" клиенту- обладателю свийстава "Б". А вот в ныне работаюшей системе етого не происходит. ("В,Г..." можно а вот "Б" нет)"
В нашей документации не описаны подобные бизнес правила, значит я не могу впринципе выйти на подобные баги. Ето нормально? Или я что-то упускаю?

[Vuk]

Тестируем мы систему CRM/Billing компании связи. Всвязи с етим хочу спросить есть ли у кого подобный опыт, каковы специфические моменты тестирования систем CRM?

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

Мне кажется наши тесты а их сейчас около 500 не покрывают всей функциональности, она очень разветвлённая.

На счёт разветвлённости верю, но количеством тестов не определишь покрываемость. Если есть ощущения, то надо искать эти неохваченные места и дописывать тесты. А вообще, я считаю, что для биллинговой системы 500 тестов это мало.

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

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

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

Смеюсь, просто потому, что я сталкнулся с такой сутуацией, что вообще нет документации, в которой описаны бизнес правила. Они передаются словестно из "покаления в покаление" :) . Так что, на своём опыте, могу сказать, что возможно писать тесты и без неё.

[astik]

Попробуите использовать такои метод.
Наиденные и зафиксированные баги, тестируются другим тестировщиком.
Исключается возможность фиксации одних и тех же ошибок.
Если же баг не исправлен.
То создаеться запись и отправляеться разработчикам на дороботку.
Реетест проводит следующии тестеровщик.
Убиваете двух заицев, вся команда знакома с ПО и ее ошибками.

[Clauster]

Попробуите использовать такои метод.
Наиденные и зафиксированные баги, тестируются другим тестировщиком.
Исключается возможность фиксации одних и тех же ошибок.
Если же баг не исправлен.
То создаеться запись и отправляеться разработчикам на дороботку.
Реетест проводит следующии тестеровщик.
Убиваете двух заицев, вся команда знакома с ПО и ее ошибками.

Будет работать только в случае с двумя тестировщиками. А вообще, в идеале, верифицировать должен тот же человек, который обнаружил дефект.