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

[vinogradoff]

И еще один вопрос назрел. 3. Есть ли у вас в проектах KPI связанный с Severity или Priority (не только для тестировщиков, а для проекта в целом или разработчиков), и если есть - то какой.

[clipsa]

 

У нас на проекте Severity обозначает критичность дефекта для работы функционала, а Priority - приоритет исправления дефекта. Т.о. вполне могут быть критичные, но не приоритетные дефекты (например, если данный функционал внедряется не в текущем релизе, а в одном из последующих)

Да, так везде и пишут в интернете :) Т.е. на 1-ый вопрос ответ - "да". А на второй?

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

 

Действительно, не ответила, отвлекли, наверное :)

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

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

 

Думаю, что это не секретная информация и я могу выложить эту табличку :)

 

 

6-Блокирующий

·         Присваивается дефектам, блокирующим новые или дорабатываемые в тестируемом релизе интеграционные взаимодействия, при этом отсутствует обходной путь проверки этих интеграционных взаимодействий из интерфейса ЕРИБ, либо любым другим способом указанным в РО.

·         Присваивается дефектам, блокирующим прохождение одного или более тест кейсов, при этом отсутствует обходной путь проверки заблокированных тест кейсов нового и регрессионного функционала из интерфейса ЕРИБ, либо любым другим способом указанным в РО.

 

5-Критический

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

·         UX дефекты (опечатки, ошибки дизайна, разметки и т.д.), несущие репутационный риск

4-Условно критичный

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

3- Существенный

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

2-Средний

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

 

 

 

>> И еще один вопрос назрел. 3. Есть ли у вас в проектах KPI связанный с Severity или Priority (не только для тестировщиков, а для проекта в целом или разработчиков), и если есть - то какой.

 

У нас нет, возможно есть у программистов, но я этого наверняка не знаю, т.к. они аутсорс :)

[vinogradoff]

Спасибо большое!

>> 2-Средний

 

>> не несущим .. рисков, не влияющим на функциональность ... не мешающим выполнению...

 

нормально так начали с 2 и среднего ;) Типа - неважных дефектов не бывает!!

[clipsa]

 

Типа - неважных дефектов не бывает!!

 

Конечно! :)