«Жизненный цикл и параметры дефектов в баг-трекинговой системе» (стр. 6 )

Статус	Категория причин – Причина возникновения дефекта
Обнаружен	только «Неопознано»
Принят	без ограничений
Переназначен	без ограничений
2-я линия	только «Неопознано»
Ожидает установки	только «Ошибки разработки – Ошибка кода Foris» «Ошибки разработки – Ошибка кода ESB» «Ошибки разработки – Ошибка кода Siebel» «Ошибки разработки – Ошибка кода NCIH» «Ошибки разработки – Ошибка кода OMS» «Ошибки разработки – Ошибка кода ESPP» «Ошибки разработки – Ошибка кода MSCP» «Ошибки разработки – Ошибка кода COCAT»
Отвергнут	только «Тестирование – Ошибка тестировщика» «Тестирование – Дефект обнаружен повторно» «Тестирование – Дефект не прошел валидацию» «Настройки маркетинговых сущностей – Не настроена услуга» «Устарели входные данные – Устарели входные данные»
Из “2-й линии” в “Отвергнут”	только «Тестирование – Ошибка тестировщика» «Тестирование – Запрос сроков доработки» «Устарели входные данные – Устарели входные данные» «Настройки маркетинговых сущностей – Не настроена услуга»
Возвращен	Может принимать значения: «Неопознано» «Ошибка интегратора – Ошибка интегратора»
Из “2-й линии” в “Возвращен”	только «Настройки ИС – Конфиг настроен неверно» «Настройки ИС – Ошибка установки патча» «Настройки ИС – Новый функционал настроен неверно» «Настройки ИС – Ошибка эмулятора» «Настройки ИС – Остановка сервиса (службы)» «Настройки ИС – Предварительные работы» «Ошибка разработки - Известная ошибка»
Ожидание доработки	только «Ошибки разработки – Ошибка документации» «Ошибки разработки – Ошибка кода Foris» «Ошибки разработки – Ошибка кода ESB» «Ошибки разработки – Ошибка кода Siebel» «Ошибки разработки – Ошибка кода NCIH» «Ошибки разработки – Ошибка кода OMS» «Ошибки разработки – Ошибка кода ESPP» «Ошибки разработки – Ошибка кода MSCP» «Ошибки разработки – Ошибка кода COCAT» «Ошибка автотеста – Ошибка кода автотеста» «Ошибка автотеста – Тестовая модель» «Ошибка автотеста – Настройки» «Ошибка автотеста – Изменение интерфейса» «Ошибка автотеста – Модуль входных данных» «Настройки КТС – Ошибка эмулятора» «Ошибка в тестовой модели – Функционал не используется» «Ошибка в тестовой модели – Запрос документации» «Настройки ИС – Новый функционал настроен неверно»
Исправлен	не может принимать значения: «Неопознано» «Ошибка интегратора – Ошибка интегратора» «Устарели входные данные – Устарели входные данные» «Риск для продуктивной среды – Риск для продуктивной среды» «Тестирование – Ошибка тестировщика» «Тестирование – Дефект обнаружен повторно» «Тестирование – Дефект не прошел валидацию» «Тестирование – Запрос сроков доработки»
Ретест	не может принимать значения «Неопознано»
Блокирован	не может принимать значения «Неопознано»
Потенциальная проблема	Только «Настройки Смежных Подразделений – Исправление смежными подразделениями» «Риск для продуктивной среды – Риск для продуктивной среды»
Предзакрыт	не может принимать значения: «Неопознано» «Ошибка интегратора – Ошибка интегратора» «Устарели входные данные – Устарели входные данные» «Риск для продуктивной среды» «Тестирование – Запрос сроков доработки»
Закрыт	не может принимать значения: «Неопознано» «Ошибка интегратора» «Устарели входные данные» «Риск для продуктивной среды» «Тестирование – Запрос сроков доработки» Права на закрытие дефекта с причиной в определенной зоне ответственности имеют следующие группы:
ЗО «Интеграция – Вендор»	Группа по анализу дефектов – вендор (входят сотрудники МТС ИТ, Siblion, InLine и др.)
ЗО «Интеграция – МТС»	Группа по анализу дефектов – интеграторы МТС (входят сотрудники МТС)
ЗО «Тестирование»	Группа по анализу дефектов – тестирование (входят сотрудники МТС)
ЗО «ТМ – МТС»	Группа по анализу дефектов – ТМ (входят сотрудники МТС)

Приложение 3. Обязанности тестировщика и область ответственности

В зоне ответственности тестировщика лежат все дефекты на Стенды или Продуктив в статусах «Исправлен», «Отвергнут», «Ретест», «Блокирован» в поле «Кому назначено» которых стоит ФИО тестировщика (это правило действует, вне зависимости от того регистрировал ли тестировщик дефект сам, или он был на него переведён). Дефекты в статусах «Исправлен, «Отвергнут», «Ретест», «Блокирован» относятся к процессу ретестирования дефектов вендором. При заведении дефектов на функционал, необходимо заполнить поля, отмеченные как обязательные (выделены желтым цветом в форме оформления дефекта), а также, обязательно проставить номер задачи (проставляется в поле «Задача ФТ», к которой относится данный дефект, и заполнить поле «Кому назначено», указав в нем сотрудника валидирующего дефекты функционала. При заведении дефекта, тестировщик обязан указать подробное описание найденной ошибки, скриншот, и, в случае наличия, приложить лог-файлы ошибки (найденные с помощью Central Logging, или самостоятельно). В случае обнаружения тестировщиком интеграционного дефекта, он назначает дефект на группового пользователя вызывающей системы, где будет проводиться первичная локализация. Если при дальнейшей локализации дефекта выявлено, что причина ошибки не в сопряжённой системе, то принимая дефект в работу, тестировщик обязан проверить корректность заполненных сотрудниками поддержки тестирования полей, указывающих на интеграционный признак дефекта («Интеграционный дефект», «Система» и «Версия системы»). В случае обнаружения ошибки, он возвращает дефект на сотрудника поддержки тестирования, который последний проводил работу по дефекту, для внесения изменений. Если в процессе работы с Интеграционным дефектом, было выявлено, что причиной дефекта является ошибка тестового случая, то значение поля «Интеграционный дефект» изменяется на «Нет», после чего работа с дефектом ведётся исходя из требований к работе с дефектом на Тестовую Модель (см. п.14). При заведении дефектов в поле «Как найдено» указывается значение «Валидация», в поле «Кому назначено» необходимо указывать ответственного за данную активность сотрудника для последующей валидации дефекта. Тестировщик обязан самостоятельно оценивать важность заводимого им дефекта. Тестировщик обязан самостоятельно осуществлять мониторинг дефектов в зоне своей ответственности (для чего ему приходят автоматические уведомления по почте от баг-трекинговой системы) и ретестировать дефекты своевременно. В случае если дефект не заблокирован, и, по предварительным оценкам, время его ретеста превышает регламентированное, тестировщик в праве запросить продление по ретесту у ответственного по направлению сотрудника МТС (процедура запроса на продление сроков ретестирования отражена в Приложении 8): При приеме дефекта в ретестирование тестировщик меняет статус «Отвергнут», «Исправлен» или «Блокирован» на «Ретест» на время ретестирования дефекта. В случае успешного ретестирования дефекта (в т. ч. на других тестовых данных), тестировщик обязан самостоятельно заполнить поле «Комментарий при закрытии», предварительно убедившись, что информация о решении, которое указал координатор, полна и корректна, а поля «Категория причин» и «Причина возникновения» заполнены исходя из сути исправления по дефекту. Далее тестировщик добавляет комментарий в поле «История изменений с комментариями», в котором указывает тестовые данные, на которых дефект был успешно ретестирован, и переводит дефект в статус «Предзакрыт»*. Если при ретестировании дефекта возникла новая ошибка, отличная от той, которая была изначально описана в дефекте, и по которой имели место качественные исправления (т. е. изначальная ошибка не повторилась при ретестировании после исправлений), то дефект закрывается, а на новую ошибку оформляется отдельный дефект с подробным описанием, к которому должен быть прилинкован первичный дефект. Если новый дефект блокирует ретестирование имеющегося, то он переводится в статус «Блокирован» до момента исправления блокирующего дефекта. Обязательно должна проводится связка блокированных дефектов, это должно отражаться на вкладке «Привязанные элементы». Если при разборе дефекта выявлено, что его причиной является исключительно ошибка, исправление которой лежит в ЗО команды поддержки тестирования (некорректная работа функционала или подсистем – ЗО интеграторов; некорректная работа КТС или отсутствие прав и настроек – ЗО администраторов стенда), то:

Тестировщик изменяет поле “Место возникновения” на значение «Контур…» (в зависимости от тестового стенда, на котором был найден дефект ); Тестировщик вносит изменения в название дефекта и его описание; в последнем комментарии тестировщик указывает сутевую часть всей информации по дефекту, достаточной для начала локализации со стороны команды поддержки тестирования;

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