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

Если тестировщику в рамках теста необходимо, чтобы сотрудники, ответственные за Администрирование тестовых сред, выполнили определённый скрипт или провели иные предварительные работы перед выполнением теста, попадающие в их ЗО, тогда тестировщику завести дефект с важностью Critical, и назначить его на группового пользователя команды Администрирования тестовых сред. При успешном выполнение работ со стороны Администраторов тестовых сред, дефект возвращается на тестировщика со статусом “Исправлен” и категорией причин возникновения “Тестирование - Предварительные работы перед выполнением теста”. В случае возникновения ошибки в процессе проведения работ, дефект на предварительные работы отвергается с указанием деталей, для создания нового дефекта, на устранение появившейся ошибки. Новый дефект должен заблокировать дефект на выполнение предварительных работ. Если на сотрудника поддержки тестирования назначается дефект, в рамках которого уже проводились качественные работы (имело место исправление, которое привело к устранению изначальной проблемы, указанной в описании дефекта), сотрудник обязан Отвергнуть данный дефект на тестировщика, который последним работал с дефектом, указав в комментарии что для решения проблемы отличной от изначально заявленной в описании дефекта, необходимо создать новый отдельный дефект, прилинковав к нему первичный дефект. В описании нового дефекта должно быть отражено, что он является продолжением ранее исправленного дефекта (например, ошибка на другом шаге теста). Если при локализации сотрудник поддержки тестирования обнаружил, что описание ошибки функционала в дефекте (основанное на шагах теста) отличается от отработки функционала на тестовой среде или продуктивной среде, и требуется исправление именно тестового случая, то прежде чем Отвергнуть дефект тестировщику, к дефекту должна быть приложена соответствующая документация, согласованная с ответственными подразделениями МТС или прямая ссылка на подобный документ, и указан корректный порядок отработки функционала, корректная ссылка или корректный запрос.

Приложение 7. Обязанности сотрудников группы тестовой модели и область ответственности

В зоне ответственности тест-дизайнеров лежат все дефекты на Тестовую Модель (Место возникновения: “Тестовая Модель”) в статусах «Обнаружен, «Возвращен», «Принят», «Переназначен», «Ожидает доработки», в поле «Кому назначено» которых указано значение группового пользователя или ФИО тест-дизайнера (см. п.3 Обязанностей сотрудника, ответственного за валидацию дефектов) в случае статуса дефекта «Обнаружен», «Переназначен» или «Возвращен», либо ФИО сотрудника группы тестовой модели в случае статусов дефекта «Принят», «Переназначен», «Ожидает доработки». При приеме дефекта в обработку сотрудник меняет статус на «Принят» и изменяет значение поля «Кому назначено» с группового пользователя на ФИО сотрудника группы тестовой модели, для работы с дефектом. После анализа дефекта и проведения необходимой работы сотрудник должен изменить статус на «Исправлен», «Переназначен», «Отвергнут» в зависимости от вынесенного решения. Если сотрудник интеграции или администратор ТС утверждает, что поведение функционала, описанного в тесте, отличается от отработки функционала на тестовой среде или продуктивной среде, и требуется исправление именно тестового случая, то к дефекту должна быть приложена соответствующая документация, согласованная с ответственными подразделениями МТС, или корректный пример отработки функционала (исправленная ссылка; корректный SOAP-запрос и т. д.). Если в процессе локализации по дефекту, выявлено, что была допущена ошибка со стороны разработки в составлении изначальной документации, по которой был написан тест, на который был заведён дефект, то тест-дизайнер заводит новый (отдельный дефект) на актуализацию документации. Данный дефект (вторичный) назначается на сотрудников интеграции. Первичный дефект переводится тест-дизайнером в статус “Ожидает доработки” до момента поступления актуальной версии документа. После того, как разработка предоставила всю необходимую информацию и актуальную версию документа, вторичный дефект закрывается тест-дизайнером с КП-ПВ “Ошибка разработки – Ошибка документации”, а изначальный дефект (первичный) возвращается для исправления группе тестовой модели согласно схеме ЖЦД. Оба дефекта должны быть прилинкованы к друг-другу, и в них должно содержаться детальное описание возникшей проблемы и её решения (что было актуализировано в документе).

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

Если дефект попал к сотруднику из статуса «Переназначен», то в первую очередь данный сотрудник обязан сменить статус дефекта на «Принят». [Другие поля будут не доступны для внесения изменений.] При переназначении дефекта другому сотруднику, тест-дизайнер, работающий над дефектом в данный момент, обязан поменять поле «Кому назначено» проставив в нем ФИО соответствующего сотрудника из группы тестовой модели, чья помощь необходима в рамках локализации по дефекту, и изменить статус дефекта на «Переназначен». Если при работе над дефектом, было выявлено, что причиной дефекта является ошибка отличная от ошибки тестовой модели (например, проблемы стенда или отработки функционала), сотрудник обязан вернуть дефект тестировщику, который последним работал с дефектом и оставлял комментарий в дефекте, внеся изменения только в два поля: «Кому назначено» и изменив статус дефекта на «Отвергнут». В этом случае в комментарии должна быть подробно описана причина, по которой дефект не попадает в ЗО ТМ, и приложена документация, если на неё ссылаются в указанной причине. После того, как работы в рамках дефекта завершены и требуется ретест по дефекту, сотрудник, работающий с дефектом, обязан поменять поле «Кому назначено» проставив в нем ФИО последнего тестировщика, оставившего комментарий, и изменить статус дефекта согласно схеме ЖЦД. В случае если дефект был Исправлен, тест-дизайнер должен подробно и понятно отразить суть выполненных исправлений, а также выставить соответствующие Категорию причин и Причину возникновения. В дефекте им должен быть указан номер исправленного теста (или тестов, или общего шага), номера исправленных шагов, и детали информации, которая была отредактирована или внесена в сводку теста. В самом исправленном тестовом случае (тестах) или общем шаге, тест-дизайнер должен оставить комментарий, что сущность исправлялась в рамках дефекта, и указать номер данного дефекта, добавив при этом краткую информацию, что именно было исправлено в тестовом случае. Если во время процесса локализации или к тому моменту, как тест-дизайнер взял дефект в работу, входные данные в дефекте уже устарели, т. е. информация в тесте (общий шаг, сводка, шаги и т. д.), на которую ссылаются в дефекте, была исправлена другим тест-дизайнером в рамках другого дефекта, дефект должен переведён в статус Исправлен на последнего тестировщика оставившего комментарий в дефекте. При этом в данном дефекте должен быть указан номер дефекта (или задачи), в рамках которого параллельно исправили информацию в указанном тесте. Дефект не может быть закрыт, пока изменения не внесены в тест в окончательном виде и тестировщик не подтвердил, что внесённых исправлений достаточно для беспрепятственного прохождения теста. Если в период работы над дефектом, имеющим важность «Critical», выяснилось, что сроки выработки решения по дефекту будут превышать регламентированные сроки обработки «Critical» дефекта тестовой модели, тогда в поле «Комментарий при закрытии» тест-дизайнером обязательно вносится информация о сроках, необходимых для исправления дефекта или проведения локализации по нему. Если на тест-дизайнера назначается дефект, в рамках которого уже проводились качественные работы командой интеграторов или администраторов стенда (имело место исправление, которое привело к устранению изначальной проблемы, указанной в описании дефекта), тест-дизайнер обязан Отвергнуть данный дефект на тестировщика, который последним работал с дефектом, указав в комментарии что для внесения дополнительной информации в тестовую модель на основании полученных в дефекте рекомендаций, необходимо создать соответствующий новый отдельный дефект, указав в нём номер дефекта, в котором рекомендации были получены и описав суть и цель запрашиваемых исправлений, касающихся тестовой модели.

Приложение 8. Процедура запроса на продление сроков ретестирования по дефекту

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

Установки на стенде, которые мешают проведению ретеста, и по которым нет задачи/ЗНО КТС/блокирующего дефекта (информация об установке должна быть в переписке, которую приложат к дефекту); Переключения на стенде (WebSSO; SCP; CM; COCAT); Установка на стенд сторонними вендорами; Рестарт сервиса/серверов;

Во всех иных случаях, дефект должен быть заблокирован другим открытым дефектом или иметь статус “Ожидает доработки” в соответствии с обычными правилами работы с дефектами.

срок, на который запрашивается продление (т. е. до какого времени ретест должен быть завершён), в формате: время – чч:мм, дата – дд. мм; После того как соответствующая информация была указана в дефекте, тестировщик информирует ответственного сотрудника МТС по направлению, при этом не изменяя статус дефекта и не изменяя поле “Кому назначено”; После того, как тестировщик оставил запрос на продление сроков ретеста, он обязан продолжить ретестирование дефекта, в обычном порядке. Ответственный сотрудник со стороны МТС, получив уведомление от тестировщика, анализирует дефект и запрос на продление времени ретеста, после чего оставляет в дефекте соответствующий комментарий в истории изменений: продление согласовано (Например: “Продление сроков ретестирования до <чч:мм дд. мм> согласовано.”); продление  не согласовано, с указанием причины (Например: “Продление сроков не согласовано, потому что <причина отказа в продлении сроков на ретест>.”); Продление согласовано, но на меньшее время / на большее время, чем запрашивалось, с указанием причины (Например: “Согласовано продление сроков ретестирования до <чч:мм дд. мм>, потому что <причина разницы между согласованными и запрашиваемыми сроками>.”). Если продление сроков ретестирования по дефекту было проведено с нарушением каких-либо из указанных условий (т. е. срок ретестирования в дефекте был продлён безосновательно), то данный дефект попадает в разряд штрафуемых дефектов, как для команды вендора по тестированию, так и для МТС. На весь срок запроса на продление времени, дефект будет находится в статусе “Ретест” на тестировщике, который отправил запрос на продление ретеста. Вся ответственность за корректность оформления и соблюдение сроков, касающихся подачи запроса на продление, будет лежать на команде тестирования вендора. Если ответственный сотрудник со стороны МТС не отреагировал на запрос от тестировщика в течении 30 минут, то при повторном запросе, или до закрытия дефекта (когда он был успешно ретестирован и была указана вся необходимая информация) тестировщик обязан дополнительно уведомить руководителя группы тестирования вендора о сложившейся ситуации. Контроль за правильностью заполнения полей в дефектах (в т. ч. привязка к релизу), создаваемых тестировщиками, находится в ЗО вендора по тестированию, т. о. вся ответственность при некорректном заполнении полей, будет лежать на стороне вендора по тестированию.

Приложение 9. Требования для заведения дефектов по Siebel на администраторов ТС

Необходимо указывать роли, под которыми был пройден тест; Указывать имя терминальной машины (не только Balabit) (например, x04-term05.pv. mts. ru [10.84.176.138] для TS Next или z04-term05.pv. mts. ru [10.84.176.139] для TS Real); Указать время теста; Указывать ошибку или прикладывать скриншот с проблемой Тестовые данные. Если проблема на каком-либо экране, указать информацию об экране: панель меню – Справка – Информация об экране