Инструкция по работе c проектом RSBalanceNew в PVCS-Tracker

Материал из RSB-Doc
Перейти к: навигация, поиск
Для этой страницы существуют ограничения, связанные с безопасностью

Содержание

Область применения

Настоящая документированная процедура определяет структуру и состав полей, а также порядок ввода, обработки и закрытия запросов в проекте в информационной системе PVCS Tracker, - RSBalanceNew - предназначенном для отслеживания хода работ над запросами к системе RS-Balance 3, разрабатываемой Департаментом систем управления предприятием (далее Департамент) компании R-Style Softlab (далее используется термин «трекер»).

Настоящая документированная процедура применяется в качестве методического документа, регламентирующего правила работы с трекером во всех подразделениях департамента.

Нормативные документы и ссылки

В настоящем документе используются ссылки на следующие стандарты и документы:

Определения

В настоящем документе применяются следующие термины и определения:

Трекер - проект RSBalanceNew в информационной системе PVCS-Tracker, предназначенный для отслеживания хода работ над запросами к системе RS-Balance 3, разрабатываемой Департаментом систем управления предприятием.

Обозначения и сокращения

Общие положения

  1. Общие правила по работе с информационной системой PVCS-Tracker, описание стандартных полей и их значений, а также правила установки системы и настройки на нужный проект, приведены в ДП «Как установить и работать с PVCS Tracker».
  2. Исполнителями работ (владельцами запросов) в трекере являются сотрудники Департамента.
  3. Администрирование трекера осуществляют:
    • отдел системного администрирования – в технической части обеспечения работы информационной системы (создание/удаление проекта, полей и значений полей, сохранение/восстановление базы данных, устранение технических проблем и т.п.).
    • начальник ОПР Департамента – в «идеологической» части работы с данным проектом (определение/изменение структуры проекта и набора значений полей, порядка обработки запросов и т.п.)
  4. Возможные изменения в структуре проекта и правилах работы с ним должны согласовываться с руководителями подразделений Департамента, работающих с трекером. О факте проведенных изменений начальник ОПР должен своевременно оповещать подразделения департамента, и вносить соответствующие изменения в настоящую ДП.
  5. Трекер организован таким образом, чтобы позволять использовать его, как инструмент для планирования работы по установленной в компании системе и получать необходимую отчётную информацию об изменениях в RS-Balance 3.

Структура трекера

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

Стандартные поля

Поле Тип Описание
ID Целое Порядковый номер запроса. Заполняется автоматически, в дальнейшем не меняется.
Title Строка Заголовок, кратко описывающий содержание запроса. Обязательное.
Description Строка Подробное описание запроса. Указать в чем заключается проявление ошибки. Как должно быть и почему. Описание условий повторения ошибки.
Submitter Пользователь Автор запроса. Автоматически инициализируется именем пользователя, вводящего запрос. Только для чтения.
Submit Date Дата Дата внесения запроса в базу данных. Автоматически инициализируется текущей датой. Только для чтения.
Owner Пользователь Сотрудник, отвечающий в данный момент за исправление ошибки.
State Перечислитель Состояние запроса.
  • Open — открыт
  • Close — закрыт

По-умолчанию открыт.

Close Date Дата Дата закрытия. Автоматически устанавливается в момент закрытия запроса. Только для чтения.

Дополнительные поля

Поле Тип Описание
Module Перечислитель Подсистема, в которой обнаружена ошибка.
  • Общее
  • Установка и удаление системы
  • Права доступа
  • Терминальный клиент
  • Комплексные операции
  • Картотеки
  • Торговый зал
  • Старый торговый зал
  • Контур НСИ
  • Печатные формы
  • Взаиморасчеты
  • Затраты
  • Документооборот
  • Комплекты
  • Отчеты
  • Контур БНУ
  • Контур ТЛ
  • Общие прикладные объекты
  • Контур ЗП и КС
  • Утилита администратора
  • TypeInfoEditor

Обязательное.

Category Перечислитель Поле, конкретизирующее место или условие возникновения ошибки.
  • Instrument
  • Perfomance
  • Connection
  • Installation
  • Upgrade
  • UserDoc
  • Help
  • RS-Forms
  • HASP
FoundInVer Строка
Menu Строка Полный путь к пункту меню, в котором обнаружена ошибка.
Request Type Перечислитель Тип запроса
  • Error - запрос содержит описание ошибки (по-умолчанию)
  • Suggestion - запрос содержит предложение.
  • Development – запрос содержит описание планируемой разработки (только для программистов)
  • Request – запрос содержит вопрос о работе продукта, описание которого отсутствует в документации.
Current State Перечислитель Текущее состояние запроса
  • <<None>> — при вводе нового запроса ставится по умолчанию. Означает, что запрос не рассмотрен в ОПР.
  • Approved — запрос принят к исполнению.
  • InProgress — запрос выполняется.
  • Fixed — разработчик исправил ошибку.
  • Eng. Rejected — разработчик отверг данный запрос. Причина конкретизируется в примечании
  • Eng. Delayed — разработчик принял решение отложить исправление ошибки (вводит разработчик). Причина указывается в примечании.
  • Eng. Need More Info — имеющаяся в запросе информация является недостаточной или непонятной исполнителю. Используется в случаях, когда владельцу запроса не хватает информации для понимания сути запроса и его исправления или реализации.
  • QA Rejected — ОТ обнаружил, что ошибка не исправлена.
  • QA Need More Info — имеющаяся в запросе информация является недостаточной для проверки произведенных доработок, запросов с неправильным или неполным описанием реализации либо с отсутствием описания.
  • Pending — запрос будет выполнен после выполнения связанного запроса. Информация о связанном запросе указывается в комментарии.
Severity Перечислитель Важность запроса.
  • Low
  • Medium
  • High
  • Test Break
  • Calculate
Submit Depatment Перечислитель Источник появления запроса. Указывается подразделение, обнаружившее ошибку и поместившее ее в трекер. Обязательное.
  • Test — ОТ (по умолчанию)
  • Support — ОПВ,
  • Analytic — АО,
  • Sale — ОРК,
  • Doc — документаторы,
  • Engineer — ОПР
  • Client — информация поступила непосредственно от пользователя.
Client Name Строка Название организации-заказчика. Заполняется в случае, когда информация об ошибке была получена от заказчика.
Planned Перечислитель Yes/No. Признак плановой работы. Обязательное поле. По умолчанию Yes. Значение No проставляет начальник ОПР по указанию зам. директора департамента по производству. Установленное значение Yes не говорит о том, что запрос уже запланирован в разработку. Это значит, что запрос должен планироваться в обычном порядке, не является внеплановым, "горящим".
Planned Start Date Дата Дата планового начала работ по запросу. Заполняется начальником ОПР.
Planned Fix Date Дата Дата планового завершения работ по запросу. Заполняется начальником ОПР.
Engineering Started Date Дата Дата фактического начала работ по запросу. Заполняется владельцем запроса одновременно с установкой значения поля CurrentState = InProgress.
Engineering Fixed Date Дата Дата фактического выполнения запроса. Заполняется владельцем запроса одновременно с установкой значения поля CurrentState = Fixed.
QA Consent Перечислитель Поле предназначено для идентификации запросов с Current State = Eng. Rejected и служит для разделения:
  • Запросов, ошибочно или необоснованно введённых в ИС PVCS Tracker и поэтому отвергнутых сотрудниками отделов разработки
  • Запросов, отвергнутых сотрудниками отделов разработки по причинам, не связанным с некорректностью запроса или отсутствием ошибки, например из-за невозможности исправить в момент обработки запроса, нецелесообразности реализации имеющимися ресурсами или прекращении поддержки компанией подсистемы, по которой и был введён запрос.

Состояния поля – YES/NO

  • YES – отвергнутый запрос был введён ошибочно (по-умолчанию)
  • NO – причина ввода запроса существует
Eng. Consent Перечислитель Поле предназначено для идентификации запросов с Current State = QA Rejected и служит для разделения запросов ошибочно отвергнутых ОТ или подразделением поддержки. Неправомерно отвергнутыми считаются запросы, отвергнутые по причине неправильной проверки реализации, выявлении повторения ошибки в ситуации не соответствующей описанию в запросе.

Состояния поля – YES/NO

  • YES – отвергнутый запрос был отвергнут правомерно (по-умолчанию)
  • NO – причины для отвержения запроса не существует
MustFixedInDate Дата Требуемая дата завершения работ по запросу. Заполняется автором запроса.
Percent Целое Процент выполнения запроса. Заполняется владельцем запроса в конце рабочего дня, если работа над запросом ведется более одного дня.
QA Owner Пользователь Сотрудник, отвечающий в данный момент за проверку запроса.
QA Planned Date Дата Плановая дата проверки запроса
QA Date Дата Фактическая дата проверки запроса

Неиспользуемые и устаревшие после введения новой технологии версионирования поля

Поле Тип Описание
Found in Version Перечислитель Номер версии системы, в которой обнаружена ошибка. По умолчанию - текущая версия системы. Устарело, т.к. не отражает возможность существования нескольких поддерживаемых стабильных веток.
Found in Build Целое Номер сборки системы, в которой обнаружена ошибка. Содержит номер сборки продукта и номер установленного патча. Устарело, т.к. не отражает возможность существования нескольких поддерживаемых стабильных веток.
Fixed In Version Eng. Перечислитель Номер версии системы, в которой выполнен запрос. Устарело, т.к. не отражает возможность существования нескольких поддерживаемых стабильных веток.
Fixed In Build Eng. Целое Номер сборки системы, начиная с которой выполнен запрос. Устарело, т.к. не отражает возможность существования нескольких поддерживаемых стабильных веток.
Fixed In Version QA Перечислитель Номер версии системы, в которой тестировщики подтвердили исправление ошибки. Устарело, т.к. не отражает возможность существования нескольких поддерживаемых стабильных веток.
Fixed In Build QA Целое Номер сборки системы, в которой тестировщики подтвердили исправление ошибки. Устарело, т.к. не отражает возможность существования нескольких поддерживаемых стабильных веток.
MustFixedInBuild Целое Поле предназначено для явного указания номера сборки и номера патча, в которых необходимо исправить запрос. Устарело, т.к. не отражает возможность существования нескольких поддерживаемых стабильных веток.
QA Error Перечислитель Не используется
News Перечислитель Не используется
Publish Перечислитель Не используется

Порядок работы с трекером

Жизненный цикл запроса

SCR.png

На рисунке приведена диаграмма состояний запроса трекера.

Прямоугольниками со скругленными углами обозначены состояния запроса, стрелками - возможные переходы из одного состояния в другое, направление стрелки соответствует направлению перехода.

Надписи рядом со стрелками показывают когда именно происходит переход и при каких условиях он возможен:

Создание запроса

В состояние "Создан" запрос переходит непосредственно после его ввода в трекер.

Запросы вводятся в трекер сотрудниками департамента. При вводе запроса указывается следующая обязательная информация:

Также заполняются остальные поля, доступные сотруднику, если их значения известны.

Если запрос описывает ошибку, возникшую в дистрибутивной поставке, в нем обязательно должна быть указана база данных, на которой эту ошибку можно повторить. Эта база должна быть расположена на сервере БД, доступном сотрудникам ОПР.

Если описываемая ошибка возникла в клиентском проекте, кроме базы данных необходимо также указывать расположение клиентского среза файлов RS-Balance 3 для повторения ошибки. Срез также должен быть расположен на ресурсе, доступном сотрудникам ОПР.

Если при написании запроса известны файлы, в которых необходимы изменения, должны быть указаны полные пути этих файлов в репозитории SVN (дистрибутивные) или VSS (проектные).

Если запрос описывает разработку новой функциональности для конкретного проекта внедрения, в нем должен быть указан путь в VSS, куда разработчику необходимо выложить созданные файлы. По сложившейся технологии публикации клиентских конфигураций это должен быть подпроект проекта $/NewBalance/Vnedrenie/<Имя проекта внедрения>/Addons

Запрос, описывающий разработку новой или доработку существующей функциональности, обязательно должен содержать ссылку на ТЗ. По возможности должен быть приведен максимально подробный алгоритм повторения ошибки. Кроме данной информации в поле Description должна указываться любая дополнительная информация полезная для выяснения причины ошибки. Например, зависимость от операционной системы, режима исполнения, название прикладного модуля и т.п.

Существует вид запросов, оформление которых требует предоставления некоторой обязательной информации, полученной по определенной схеме. Это запросы, описывающие ошибку «Система хранения данных неработоспособна или не может выполнить запрашиваемую операцию». Такая формулировка сообщения об ошибке свидетельствует об отправке сервером приложений RS-Balance некорректного SQL-запроса серверу баз данных. Подробная информация об этом запросе и ошибке сервера базы данных записывается в лог сервера приложений. Поэтому при оформлении запроса, к нему в обязательном порядке необходимо приложить лог сервера приложений. Во избежание случаев добавления пустого или замусоренного предыдущей работой лога используется следующая процедура его получения:

  1. Первое получение ошибки.
  2. Перезагрузка сервера, при запуске сервера должна стоять опция «перезаписывать лог».
  3. Повторение ошибки, после получения окна сообщения об ошибке ничего больше делать не надо.
  4. Сохранение лога.
  5. Оформление запроса, приложение к нему сохраненного лога.

Из состояния "Создан" запрос может перейти в состояния "Запланирован" или "Отклонен разработкой"

Правила установки типа запроса

Типы запроса Error, Suggestion, Request могут проставляются всеми сотрудниками департамента без ограничений. Тип Development имеют право проставлять директор ДСУП, начальник ОПР и руководители групп ОПР. Все остальные сотрудники вместо Development должны ставить тип Suggestion.

Запросы, имеющие тип Suggestion, подлежит согласованию, после чего они получают тип Development, либо отклоняются, если предложение доработок не было принято при согласовании.

Разработчик не имеет права принимать в работу запросы типа Suggestion, даже если они ему уже запланированы. В этом случае он должен уведомить своего непосредственного руководителя, о том, что запланированы неутвержденные запросы либо забыли поменять тип запроса.

Правила определения версии появления ошибки

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

Теперь от версии, в которой нашли ошибку, по приведенному списку вверх (т.е. в более ранних версиях) нужно найти ту, в которой ошибка появилась впервые. Более поздние версии не интересует, там эта ошибка есть точно. Искать можно прямым перебором, т.е. тестировать все версии подряд, а можно воспользоваться принципом двоичного поиска

Номер найденной версии вписывается в поле запроса FoundInVer.

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

Планирование запросов к исполнению

В состояние "Запланирован" запрос переходит из состояний "Создан" или "Согласован" Предварительному согласованию подлежат запросы типа Suggestion, после чего их тип должен измениться на Development.

Запланированными считаются запросы с заполненными полями Owner, Planned Start Date, Planned Fix Date. Планирование осуществляется в соответствии с установленными документированными процедурами.

Планированию подлежат запросы с незаполненным полем Owner или запросы, владельцами которых являются сотрудники ОПР, с незаполненными полями Planned Start Date и/или Planned Fix Date.

Запросы планируются в работу в соответствии со следующим приоритетом (в порядке убывания приоритета):

№ п/п Описание типа запроса Идентификация (заполнение полей) Когда будет запланирован Примечание
1 Внеплановые запросы об ошибках и доработках от групп внедрения /сопровождения, инициированные в проектах внедрения/сопровождения Submit Department = Support, Client;

Client Name = не пусто;

Planned = No;

RequestType = кроме Development;

В текущем отчетном периоде со сдвигом плановых задач в этом периоде Запросы данного вида сортируются также по следующим полям (порядок сортировки):

Severity: TestBreak, High, Medium, Low.

RequestType: Error, Suggestion.

2 Запросы, запланированные, но не выполненные в предыдущем отчетном периоде. Owner = сотрудник ОПР;

Planned Start Date = в предыдущем периоде или ранее;

Planned Fix Date = в предыдущем периоде или позже;

CurrentState = кроме Fixed;

В планируемом отчетном периоде
3 Плановые запросы об ошибках и доработках от групп внедрения /сопровождения, инициированные в проектах внедрения/сопровождения Submit Department = Support, Client;

Client Name = не пусто;

Planned = Yes;

RequestType = кроме Development;

В следующем отчетном периоде Запросы данного вида сортируются также по следующим полям (порядок сортировки):

Severity: TestBreak, High, Medium, Low.

RequestType: Error, Suggestion.

4 Плановые запросы об ошибках от тестировщиков. Submit Department = Test;

Planned = Yes;

RequestType = Error

В следующем отчетном периоде или позднее Запросы данного вида сортируются также по следующим полям (порядок сортировки):

Severity: TestBreak, High, Medium, Low.

5 Плановые запросы об ошибках от остальных подразделений департамента. Submit Department = кроме Test, Support, Client;

Planned = Yes;

RequestType = Error;

-//- -//-
6 Плановые запросы о доработках от тестировщиков. Submit Department = Test;

Planned = Yes;

RequestType = Suggestion

-//- -//-
7 Плановые запросы о доработках от остальных подразделений департамента Submit Department = кроме Test, Support, Client;

Planned = Yes;

RequestType = Suggestion

-//- -//-
8 Запросы о плановой разработке RequestType = Development -//- -//-
9 Прочие запросы. Кроме вышеперечисленных -//- -//-


Примечание 1: Для включения в работу запросов из п.1 как внеплановых автор запроса или руководитель проекта должны согласовать сроки начала и завершения работ по запросу с зам. директора департамента по производству и начальником ОПР.

Примечание 2: В случае наличия на начало отчетного периода (1-3 число каждого месяца) высокоприоритетных запросов, не попадающих в приоритетные категории, авторы запросов или руководители проектов должны согласовывать их планирование с зам. директора департамента по производству и начальником ОПР.

В процессе планирования работы, назначается исполнитель работы, определяется трудоёмкость и планируемые даты начала и завершения работы. Если запрос не запланирован для реализации, в комментариях указывается причина, по которой запрос не принимается в работу, и статус запроса получает признак Eng. Delayed или Eng. Rejected. Если нужна дополнительная информация, запрос получает статус Eng. Need More Info.

Внеплановые работы тоже вносятся в трекер. Такие запросы оформляются также как и плановые, но поле Planned устанавливается в No.

Из состояния "Запланирован" запрос может перейти в состояния "Выполняется"

Уточнение запроса

Иногда возникают ситуации, когда в оформленном запросе недостаточно данных для повторения и исправления ошибки или реализации новой функциональности. В этом случае при планировании поле текущего состояния запроса устанавливается в Eng. Need More Info, добавляется комментарий типа Engineering Note с подробным описанием недостающей информации, и запрос переводится на автора. Авторы запросов регулярно должны проверять свои запросы на необходимость уточнения.

При уточнении автор запроса добавляет комментарий типа Submitter Note с недостающей информацией, если необходимо, прикладывает файлы, устанавливает текущее состояние запроса в <None> и переводит его на сотрудника, запросившего уточнение.

Оба сотрудника, автор и владелец запроса, при изменении запроса должны посылать друг другу уведомления с содержимым запроса (контекстное меню трекера Notify User).

Запрос может также в случае необходимости уточняться владельцем во время выполнения.

Согласование запроса

Запросы типа Suggestion, а также любые спорные запросы направляются на согласование в аналитический отдел – в поле Owner проставляется начальник аналитического отдела и запросу устанавливается статус Eng. Need More Info.

В процессе согласования запрос анализируется, после чего принимается решение о его принятии или отклонении. При принятии решения аналитик в случае необходимости консультируется с руководством ОПР.

В случае принятия запроса в разработку аналитик добавляет комментарий типа Analitical Note, устанавливает текущее состояние запроса в <None> и переводит его на сотрудника, запросившего согласование. Также этому сотруднику посылается уведомление с содержимым запроса (контекстное меню трекера Notify User).

Отклонение запроса ОПР или АО

В некоторых случаях может быть принято решение об отсутствии необходимости выполнения запроса.

При отклонении запросу устанавливается текущее состояние Eng. Rejected. Запрос, отклоненный сотрудникам ОПР при выполнении, по желанию автора может быть направлен на согласование. Если запрос был отклонен неправомерно, он возвращается в состояние планирования и, далее, выполняется.

Выполнение запроса

При принятии запроса в работу владелец устанавливает запросу статус Approved. Принятие запросов в работу производится владельцем запросов после получения плана работ. Перед непосредственным выполнением запроса ему устанавливается статус InProgress и заполняет поле Start InProgress Date. В процессе работы запрос может получить состояние Eng. Delayed, если выполнение запроса откладывается по причинам, не зависящим от владельца. Если в процессе выполнения выясняется, что для окончания работы над запросом требуется завершение работы над другим запроса, используется статус Pending, при этом в комментарии указывается номер связанного запроса. Причина перевода запроса в Eng. Delayed, Eng. Rejected или Pending указывается в комментариях.

Владелец запроса исправляет ошибку в версии, указанной в запросе и фиксирует изменения в соответствующей ветке. Ветка определяется следующим образом:

Затем изменения, сделанные по запросу, должны быть перенесены во все более поздние стабильные ветки и trunk. Это гарантирует исправление найденной ошибки в следующих стабильных версиях и основной линии разработки.

Кроме того, необходимо проверить наличие кода, порождавшего ошибку, во всех более ранних поддерживаемых стабильных ветках, так как не исключена ошибка ОТ при определении самой ранней версии с ошибкой. В случае обнаружения ошибки в более ранних ветках необходимо исправить ее и там. После этого необходимо скорректировать номер версии, в которой найдена ошибка, в запросе.

Также разработчик добавляет в запрос примечание, в котором перечисляются все ветки c исправленной ошибкой, а также ревизии, в которых были зафиксированы изменения по запросу в каждой ветке Пример примечания:

Ошибка исправлена в ветках:
branches/Stable/3.20 (356)
branches/Stable/3.22 (357)
branches/Stable/3.24 (359)
trunk (367)

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

Владелец запроса при завершении работы над запросом устанавливает состояние запроса в Fixed, отмечает дату завершения (Engineering Fixed Date). При работе с дистрибутивными файлами также необходимо в комментарии указать все ревизии репозитория SVN, в которые попали изменения по запросу в каждую поддерживаемую ветку. При работе с пользовательскими файлами проектов внедрения - полные пути файлов в VSS. При необходимости в комментарии указывается дополнительная информация по реализации запроса.

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

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

Планирование запроса к проверке

Для того чтобы запрос был проверен, он должен быть запланированным к проверке. Для организации процесса планирования служат два поля: QA Owner и QA Planned Date. Если указанные поля заполнены, то запрос считается запланированным к проверке.

Поля QA Planned Date и QA Date не могут быть заполнены, пока не заполнено поле QA Owner По умолчанию все поля являются незаполненными.

Поля QA Owner и QA Planned Date имеют право заполнять директор ДСУП, начальник ОТ, начальник ОПР и сотрудники ОПВ. К полю QA Date доступ открыт всем.

После окончательной проверки запроса (при установке State = Closed) QA Owner заполняет поле QA Date текущей системной датой. Поля QA Owner и QA Planned Date позволяют вести планирование работ по проверке запросов и могут эффективно использоваться не только ОТ, но и сотрудниками ОПВ.

Для распределения незапланированных к проверке запросов руководитель ОТ составляет в трекере запрос: QA Owner = <<Unassigned>> And Current State = Fixed, затем для каждого запроса назначаются проверяющий и плановая дата проверки.

Сотрудник ОТ должен каждый день просматривать непроверенные запросы, которые за ним закреплены. Для этого в трекере составляется запрос: QA Owner = {Имя проверяющего} And QA Planned Date before {Текущая системная дата} And State = Open

Проверка запроса

Выполненные запросы (Current State = Fixed) после выхода очередной сборки должны быть проверены авторами.

В сообщении о выходе очередной сборки (любой версии) указываются номера запросов, выполненных в данной версии, которые нужно проверить.

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

После того как запрос проверен во всех ветках (включая trunk), он закрывается (поле State устанавливается в состояние Сlosed) Реализованные, но незакрытые автором, запросы могут быть закрыты начальником ОПР по истечении 2-x месяцев после реализации запроса.

Возврат запроса на доработку

Если в новой версии, куда попали изменения по запросу, не исправлена указанная в запросе ошибка или новая функциональность разработана некорректно или не полностью, запрос получает статус QA Rejected, очищается поле Engineering Fixed Date, добавляется комментарий типа Test Note с причиной возврата на доработку и владельцу запроса отсылается уведомление с содержанием запроса. После этого владелец запроса должен внепланово устранить ошибки и недочеты по запросу.

Личные инструменты
Пространства имён
Варианты
Действия
Навигация
Для разработки
Инструменты