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

[Liliya]

Поделитесь опытом.
Есть ли у вас какая-нибудь стандартная терминология, которая служит средством борьбы с дупликатами багов.
Ведь если заголовок и описание выдержаны в единой терминологии, в последствии проще найти уже заведенный баг.
Может у вас приняты какие-нибудь специальные обороты?

[Clauster]

проблема уже обсуждалась на форуме. попробуйте поискать.
дубликат пишется через "б" :)

[Clauster]

вот http://forums.softwa...

[Clauster]

в последствии

в данном случае слитно :)

[Liliya]

Спасибо за русский язык, но дупликат - это внутренний жаргон. :)

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

[NewTester]

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

[Liliya]

Может быть я неправильно сформулировала свой вопрос...

Я про "стандарт" формирования предложения.

Например:
User gets "!!!!!" error message when ......

или "!!!" when I open........

есть ведь разница в построении предложения?! невозможность отловить копию бага иногда заключается в слишком произвольном его описании.

[Clauster]

Стоп. А вы что в качестве багтрекинга используете?
Т.е. какая разница в каком месте !!! - оно находится с помощью поиска.

[Liliya]

В качестве багтрекинга мы используем TeamSystem.

Как и везде есть свои плюсы и минусы, так вот минусом я считаю поиск.....

[rlabs]

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

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

В какой-то степени это помогает, тем не менее, полностью избавиться от дублей у вас не получится. Тем не менее, совершенно незачем делать из этого огромную проблему. Как правило, продублированное сообщение о проблеме гораздо лучше отсутствующего сообщения.

Дубируйте на здоровье!

[Clauster]

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

[Liliya]

Может вы и правы

Но большая часть тестеров находится не в Росии, поэтому необходимость введения стандарта возрастает. Надо эе как-то регулировать отношения с коллегами...

[rlabs]

Но большая часть тестеров находится не в Росии, поэтому необходимость введения стандарта возрастает. Надо эе как-то регулировать отношения с коллегами...

Что-то не бросается в глаза связь стандартов с географией.

[Clauster]

Напишите документ по менеджменту багтрекинга, если у вас нет такового. Со временем все придет.

[k155la3_1-7_BY]

По большому счёту не важно как написано.
На одном проекте я пишу и заголовок и описание бага в безличных предложениях, как на русском, так и на английском. Плюс шаги для воспроизведения.
На другом проекте заголовок- безличный, а в теле можно и личные предложения. Описание чаще всего без шагов, но с детальным описанием. Проблем с пониманием багов и на одном, и на другом проекте не было. Так что в принципе, это дело вкуса %)

[Liliya]

k155la3_1-7_BY! Дело не в понимании, а в стремлении уменьшить количество дубликатов.

[Imbecile]

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

[Liliya]

Этот механизм уже отработан.

[bvd]

Поделитесь опытом.  
Есть ли у вас какая-нибудь стандартная терминология, которая служит средством борьбы с дупликатами багов.
Ведь если заголовок и описание выдержаны в единой терминологии, в последствии проще найти уже заведенный баг.
Может у вас приняты какие-нибудь специальные обороты?

Здравствуйте, Liliya.

По поводу терминологии, то я, разрешите поделиться, пользуюсь "Microsoft® Manual of Style for Technical Publications, Third Edition" MSTP-V3.pdf (3319 KB) Лично мне очень нравится, когда одинаковые вещи названы одинаково, - не приходится выяснять, что имелось ввиду. Это же может упростить поиски потенциальных дублей в Bug Tracking системе. Для примера можно взять "рекомендации" из того самого документа MSTP-V3.pdf :

Always surround menu names with the words the and menu both in text and procedures.
Correct
On the File menu, click Open.
Incorrect
On File, click Open.
From File, click Open.

или вот относительно компонента Check box:
Element Name: Check box
Definition: Square box that is selected or cleared to turn on or off an option. More than one check box can be selected.
Usage: Select the Spaces check box.
–or–
Click to clear the Bookmarks check box.
–or–
Under Show, select the Draft font check box.
Note: Always include check box with the label name.
Example: <An image with check boxes>

В этом документе так же масса других моментов, которые возможно и Вам помогут в избежании дубликатов, как то: разница между "Access Key" и "Keyboard shortcut" и варианты их использования, капитализация компонентов, допустимые глаголы для операций над компонентами, и много другое.

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

И по поводу заведенный оборотов, можно, конечно, создать документ, в котором будут описаны термины и обороты, которые необходимо будет использовать каждому пользователю Bug Tracking системе; я же думаю, что проще пользоваться уже созданным, тем более, что как и любой другой стандарт, это позволяет, например, просто упоминать его в качестве ссылки, либо обращать внимание на соискателя, который уже знаком с ним, и пр.

А в общем, всецело поддерживаю Вас в плане поиска единой терминологии при описании багов.

Удачи.

[single player]

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