Список групповых пользователей по подсистемам:
Foris | Интеграторы от компании вендора-разработчика (МТС ИТ), отвечающие за систему Foris |
Ts_support | Сотрудники группы управления тестовыми средами, отвечающие за поддержку системы Foris (МТС) и за работоспособность КТС |
ESB | Сотрудники группы управлениям тестовыми средами, поддерживающие работу подсистемы ESB (МТС) |
ESB_dev | Сотрудники разработки со стороны компании-вендора |
MSCP | Сотрудники интеграции от компании вендора-разработчика (МТС ИТ) MSCP |
ESPP | Поддержка ТС ESPP (МТС) |
NCIH | Интеграторы от компании вендора-разработчика (МТС ИТ), отвечающие за систему NCIH. |
NCIH_support | Сотрудники группы управления тестовыми средами, отвечающие за поддержку системы NCIH (МТС) |
Siebel | Сотрудники группы управления тестовыми средами, отвечающие за поддержку системы Siebel (МТС) |
Siebel_dev | Сотрудники интеграции и разработки со стороны компании вендора-разработчика Siebel (Siblion) |
Performance Management | Поддержка системы мониторинга со стороны компании-разработчика. |
Autotest | Поддержка автоматизированных тестов |
Примечание: крайне важно корректно заполнять данное поле т. к. оно напрямую влияет на весь процесс локализации по дефекту. В случае завышения критичности, время, потраченное сотрудниками группы поддержки тестирования на подобный дефект, приостановит локализацию по другим более приоритетным (с корректно заполненными полями) дефектам. В случае занижения, критичный блокирующий дефект будет локализован позже чем необходимо, что в целом крайне негативно отразится на всём процессе тестирования (локализации по другим дефектам, сроках ретестирования и на итоговых сроках сдачи задачи).
Возможные значения:
|
|
|
|
Поле «Система» заполняется через выбор значения из предоставленного выше выпадающего списка;
Версия системы – «-» (по умолчанию недоступно для редактирования; значения поля доступны в зависимости от значения поля «Система»); Место возникновения – среда, на которой обнаружен дефект.Возможные значения поля описаны в Приложении 1;
Описание и комментарии – полное описание дефекта с указанием дополнительной информации (номера телефонов, текст сообщений об ошибках и т. Д);Важно: При оформлении дефекта в поле «Описание и комментарии» необходимо указывать, с какой терминальной машины при прохождении теста запускался сервис\клиент;
При оформлении и закрытии дефекта нужно обязательно указывать все тестовые данные, на которых проводился ретест;
Вложения – лог-файлы ошибки, собранные тестировщиком самостоятельно или с помощью программы Central Logging, а также дополнительные вложения при оформлении дефекта по необходимости;Скриншот необходимо сжимать в формат JPEG или PNG и ни в коем случае BMP!
Задача ФТ – поле не отмечено звездочкой, но заполнять его нужно обязательно в случае функционального тестирования (в поле “Найдено в пачке” проставлено значение “Новый функционал”): Тестируется новый функционал – в поле «Задача ФТ» требуется указать уникальный номер задачи ITG (нового функционала) или идентификатор проекта, в рамках которого проходит тестирование. Тестируется патч из RFC – в поле «Задача ФТ» требуется указать номер RFC. Например - RFC 2873tmts. Ответственность – поле заполняется вручную в случае, если поле “Найдено в пачке” заполнено значением “Новый функционал”. В данном поле указывается вендор, в чьей ЗО находится дефект, для последующего переноса информации в акт приёмки. Привязка к тесту/SRQ/INC/PBI – указывается ID теста в случае обнаружения дефекта в рамках регрессионного тестирования. Во время тестирования промышленных систем, поле заполняется через “/” номерами сущности из Remedy, накопительным итогом, для формирования единого связанного отчёта по всем Ошибкам с продуктивной среды. Соответственно: SRQ – номер Изменения, INC – номер Инцидента, PBI – номер проблемы.При появлении дополнительной информации по существующему дефекту при необходимости дополнить описание дефекта и/или приложить новые файлы скриншотов или описаний.
Полный список значений, которые могут принимать поля дефекта в TFS указан в Приложении 1.
Список значений, которые могут принимать поля Категория причин и Причина возникновения (при переводе дефекта из одного статуса в другой, а также при закрытии), указан в Приложении 2.
В случае необходимости проведения дополнительных работ (отличных от работ, проводимых в рамках сущности “Ошибка”) со стороны администраторов тестовых стендов, сотрудники интеграции вендора-разработчика должны создать ЗНО КТС. Работа с сущностью Запрос на Обслуживание КТС регламентируется иными нормами и описана в другом документе – Жизненном Цикле Запроса на Обслуживание КТС.
III. Время обработки дефектов участниками процесса тестирования
Обязанности и ответственность участников процесса тестирования, отражены в Приложениях 3, 4, 5, 6 и 7.
Термин | Обозначение |
Срок реагирования | Время, за которое группа поддержки тестирования должна перевести дефект в статус «Принят» (например: «Обнаружен», «Возвращен», и «Переназначен») |
Срок вынесения решения по дефектам | Время, за которое группа поддержки тестирования / администратор / интегратор / 2-я линия должны перевести дефект в статус «Исправлен», «Отвергнут», «2-я линия» (и «Ожидает установки») с соответствующими статусам требованиями, либо эскалация (передача) вопроса непосредственному руководителю или сотруднику, имеющему соответствующую квалификацию для решения вопроса. Время, за которое в дефекте «2-я линия» и «Ожидает установки» должен быть заполнен комментарий с номером доотгрузки на тестовый стенд. |
Срок ретестирования | Время, за которое тестировщик должен провести ретестирование дефекта и перевести его в один из трех возможных статусов «Закрыт», «Возвращен», «Блокирован». |
Срок валидации | Время, за которое валидатор должен вынести решение по дефекту. |
Срок согласования категории причин возникновения | Время, за которое сотрудники группы по анализу корневой категории причин возникновения должны согласовать категорию причин и причину возникновения дефекта. |
Согласно важности дефектов, группа поддержки тестирования / администратор / интегратор должны среагировать на дефект за время, указанное ниже (время нахождения в статусах Обнаружен, Возвращен, Переназначен):
Важность дефекта | Срок реагирования |
Critical* | 1 час |
High | 2 часа |
Medium | 4 часа |
Low | 8 часов |
*Обязательное информирование по почте о переводе Critical дефекта всем заинтересованным лицам.
Группа поддержки тестирования / администратор / интегратор должны вынести решение по дефекту за указанное время (суммарное время нахождения дефекта в статусе Принят / Переназначен на определенной команде до перевода дефекта на следующий этап, а именно: 2 линия, Исправлен, Отвергнут):
Важность дефекта | Срок вынесения решения |
Critical | 2 часа |
High | 4 часов |
Medium | 8 часов |
Low | По согласованию, но в рамках текущей активности |
Группа поддержки тестирования / администратор / интегратор должны предоставить решение по дефекту за указанное время (время нахождения дефекта в статусе 2 линия):
Важность дефекта | Срок вынесения решения |
Critical | 2 часа |
High | 4 часов |
Medium | 8 часов |
Low | По согласованию, но в рамках текущей активности |
Расчет времени нахождения дефекта на 2-ой линии проводится по следующей схеме:
При выработке решения по дефекту, требующему установки исправляющего патча, дефект переводится в статус «Ожидает установки»:- Если после ретеста дефект закрывается без возврата в команду Партнера (без повторного перевода в статус «2 линия»), то время нахождения дефекта на 2-ой линии считается равным периоду нахождения в статусе «2 линия». Если после ретеста дефект возвращается в команду Партнера (перевод в статус «2 линия»), то время нахождения дефекта на 2-ой линии (начальная итерация) считается равным суммарному периоду нахождения в статусах «2 линия» и «Ожидает установки».
Группа тестирования должна ретестировать дефект за указанное время:
|
Из за большого объема этот материал размещен на нескольких страницах:
1 2 3 4 5 6 7 8 9 |
