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

[Solovey_PO]

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

[bobylev]

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

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

 

P.S. Очень редко заголовок бага достаточно информативен и не требует доп. описаний.

[gako]

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

[SALar]

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

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

 

P.S. Очень редко заголовок бага достаточно информативен и не требует доп. описаний.

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

Чем лучше вы умеете описывать, тем короче описание.

Чем короче описание, тем лучше.

 

Вот поэтому меня так бесит, когда кто-то делает поле "описание" обязательным.

 

 

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

Потрясающе количество программистов не знает зачем нужна версия программы. Сколько же я с этим воевал!

[gako]

Потрясающе количество программистов не знает зачем нужна версия программы. Сколько же я с этим воевал!

 

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

[Solovey_PO]

Сайт МТС наверняка состоит из разных частей (веб-портал...

Спасибо за ответ. У меня в сообщении конкретно и написано про версию веб-портала (или версия компонента, кстати кто нибудь может объяснить мне этот термин?)
P.S. Можно пример ваш тогда с описанием, если не хватает заголовка, когда в поле с номером телефона можно вбить спецсимвол, на строго указанной для тестирования странице. 
Я лично не вижу причин расписывать в этом случае поэм для программиста. 

[bobylev]

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

В процессе описания бага тестировщик может провести дополнительную аналитическую работу.

Например:

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

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