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

[van]

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

Где:
Книга С. Канера "Тестирование программного обеспечения".
Материал сайта software-testing.ru, посвященный багтрекингу.

Как:
Методом прочтения.

[astik]

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

Будет работать и с четыремя. В случае верификации очень полезен "свежии" взгляд. Так как тестировшик идет про проторенному пути.
Могу превести пример: тестирование однои функции через различные ветви.
получается полу метод "четырех глаз" ;)

[astik]

Если же говорить о команде в 20-30 человек. То их целесообразно разбивать на подгруппы от двух - до пяти человек в зависимости от сложности темы. Опыт показывает - качество и скорость тестирования от этого только повышаеться.

[Clauster]

Будет работать и с четыремя. В случае верификации очень полезен "свежии" взгляд. Так как тестировшик идет про проторенному пути.
Могу превести пример: тестирование однои функции через различные ветви.
получается полу метод "четырех глаз" ;)

Вы не путаете тестирование и верификацию?

[Clauster]

В случае верификации очень полезен "свежии" взгляд. Так как тестировшик идет про проторенному пути.

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

[SALar]

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

Маститых писателей часто спрашивают, как научиться писать книги. Ответ тривиален: "Пишите". Все остальное: семинары, статьи, обучение - вторично.

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

PS. Если попадете ко мне на работу, я вас научу.

[caboverde]

Проблема в том, что и учиться не у кого. Команда из не опытных(ето я себя имею ввиду) и не очень опытных. То что я читаю в BTS как описание бага мне кажется могло бы быть удачнее. Баги не имеют названий (правда указан номер тест-кейса), просто в клетке EXCEL пишется: в прицессе таком-то, сделал то-то и то-то, произошло так-то. И пока ты не прочтёшь весь рассказ , не поймёш в чём проблема.
Наши опусы никто не правит. Сравнивать мне не с чем.
А информацию я ишю и уже нахожу. Етот форум, например, меня очень продвинул в понимании предмета, спасибо всем, кто принял учавствие в обсуждении.

[SALar]

Орфографические ошибки ухудшаю понимание. Стилистические делают понимание невозможным.

Возможно, эти комментарии вам помогут:
не опытных - пишется слитно
опытных(ето - неправильная расстановка пробелов
Команда из не опытных(ето я себя имею ввиду) и не очень опытных. - рекомендую восстановить пропущенное слово состоит.
То что я читаю в BTS как описание бага мне кажется могло бы быть удачнее. - пропущены знаки препинания. Смысл фразы не понятен.
ето - орфографическая ошибка
То что я читаю в BTS как описание бага мне кажется могло бы быть удачнее. - плохое построение фразы.
прицессе - орфографическая ошибка
Баги не имеют названий (правда указан номер тест-кейса), просто в клетке EXCEL пишется: в прицессе таком-то, сделал то-то и то-то, произошло так-то. - лучше разбить на несколько предложений.
поймёш - орфографическая ошибка
рассказ , не - неправильная расстановка пробелов
ишю - орфографическая ошибка
Етот - орфографическая ошибка
учавствие - орфографическая ошибка
То что я читаю ... Баги не имеют названий ... пишется: ... И пока ты не прочтёшь - стилистический разнобой. См. http://www.rsdn.ru/a...wNotTowrite.xml

PS. Для участника команды умение ясно излагать свои мысли не менее важно, чем наличие технических навыков (см. статью Джоела Спольски).

[astik]

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

Вы же знаете, что от человеческого фактора ни кто не застрахован :)
А остальные описанные вами проблемы легко решаются при помоши тулов позволяюшит тестировать автоматизировано или же банального решения, по шагового тест чек листа.

[Clauster]

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

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

[SALar]

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

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

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

2Clauster. Термин верификация имеет еще одно значение. Чтобы не было двузначности толкования, предлагаю использовать "проверка исправления ошибки".

[Clauster]

2Clauster. Термин верификация имеет еще одно значение. Чтобы не было двузначности толкования, предлагаю использовать "проверка исправления ошибки".

Согласен, но из моего контекста должно было быть ясно, что я имею ввиду

[Glorius]

В нашей CTS почти 50 000 багов (за 8 лет), конечно, дубликаты есть, но никто никогда не считал и не считает это серьезной проблемой. Это нормальная практика. Все кейсы-дубликаты закрываются со ссылкой на исходный кейс, закрывает тот, кто первый это заметил. Обычно это Project Manager.

Хотя у нас не одна сотня девелоперов, тестеров, PjM никакого особого хаоса нет. Тестеры занимаются какой-то своей отдельной областью и в чужие не лезут. Если все-таки находят не из своей области, то подходят к созданию кейсов с большей осторожностью, например, сначала спросят у тех, кто за это ответственен. Поиск по CTS обычно больших результатов не дает, поскольку один и тот же баг может быть описан по-разному. Создав кейс, тестер делает его владельцем, как правило, PjM который имеет более широкую картину и затем этот PjM делает владельцем кейса ответственного девелопера. Когда девелопер исправляет его, то переводит статус кейса в «untested» и указав номер пофиксенного билда, делает его владельцем тестера, который должен снова протестировать проблему и если она исчезла, то закрыть кейс.
Такой вот круговорот :)