Опубликовано

Приемо-сдаточные испытания

Приемо-сдаточные испытания

Для того, чтобы сделать процесс сдачи проекта (этапа) более четким и однозначным, должны быть введены четкие приёмочные критерии, при выполнении которых заказчик обязан «принять» этап.

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

Изначально, на старте проекта, с заказчиком необходимо обговорить процесс сдачи каждого этапа и проекта в целом.

Таким образом, для каждого этапа набор работ будет следующим:

1. Составление перечня приемочных тестов

• QA анализирует требования к новому этапу.

• QA cоставляет список приемочных тестов для данного этапа. Лучше всего выделить эту группу в тест плане по версиям.

Набор тестов может быть прислан и заказчиком.

• QA утверждает список у PM-а.

2. Написание приемочных тестов

В отдельной тест кейс спецификации QA описывает запланированные на предыдущем шаге приемочные тесты.

3. Утверждение набора приемочных тестов

PM утверждает спецификацию приемочных тестов у заказчика.

4. Проведение приемо-сдаточных испытаний на стороне заказчика

При сдаче этапа (проекта) PM или QA на стороне заказчика демонстрирует успешное прохождение каждого утвержденного теста.

Опубликовано

Контроль версии

Контроль версии

Каждая версия (сборка) должна идентифицироваться чётким образом. Легче всего применить следующий формат версии:

XX.YY.revision , где

Revision – номер внутренней сборки (Build number). Соответствует номеру последней ревизии в SVN, вошедшей в данную версию.

YY – номер поставки заказчику (Delivery number), обнуляется при увеличении XX.

XX – номер релиза (Release number).

1. Build для тестирования

Как правило, очередной build собирает QA. Версия равна XX.YY.revision.

2. Объединение веток (merging)

Ветки объединяет руководитель проекта или техлид. Версия равна XX.YY.revision.

3. Сборка Delivery

Деливери собирает также руководитель проекта или техлид.

Версия устанавливается вручную в XX.YY (ревизия отбрасывается, YY увеличивается).

Также, рекомендуется для каждого билда писать примечание к версии (Release notes), что облегчит работу как с заказчиком, так и QA инженерами.