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

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

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

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

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

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

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

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

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

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

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

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

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

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

В один момент времени может быть до 2х веток кода:

• Основной branch – функционал, подлежащий сдаче в ближайшем деливери (текущем этапе).
• Вторичный branch – функционал, подлежащий сдаче через деливери (следующем этапе).

• 0й – разработка
• 1й – тестирование, fix, разработка, сдача этапа (деливери)
• 2й – тестирование, fix, разработка, сдача этапа (деливери)
• 3й – тестирование, fix, сдача проекта (релиз).

Кратко процесс можно описать так:

• 1. Для ближайшего деливери PM планирует объем необходимого функционала {Ф}.
• 2. Реализуется весь заданный функционал {Ф} (о чем свидетельствует PM).
• 3. Собирается билд для QA. QA приступает к тестированию функционала для ближайшего деливери {Ф}.
• 4. PM планирует объем функционала {Ф} для следующего деливери.
• 5. Разработчики приступают к разработке нового объема функционала {Ф}, параллельно исправляя дефекты, найденные в готовящемся деливери.
• ! У дефектов приоритет всегда выше, чем у нового функционала!
• 6. По мере исправления дефектов, имеющихся в готовящемся деливери, QA собирает промежуточные билды для тестирования.
• 7. QA сигнализирует о том, что весь необходимый для деливери функционал реализован и дефекты отсутствуют. PM собирает деливери.
• ! Деливери собирается и отправляется только после одобрения QA!
  • Деливери отправляется заказчику вместе с сопроводительной документацией.
• 8. PM инициирует слияние двух веток.
• 9. По мере реализации нового функционала для следующего деливери, QA собирает промежуточные билды для тестирования.
• 10. Процесс повторяется до выпуска финальной версии.

Что входит в управление изменениями проекта:

• Анализ и сбор всех требований Заказчика.
• Фиксирование всех требований (общий бизнес-процесс, GUI, функционал) в спецификации.
• Регистрация всех требований, подлежащих реализации, в багтрекинговой системе. Соответствующая пометка тех требований, которые должны войти в деливери. Ответственный – руководитель проекта.
• Обязательный групповой анализ каждого запроса на изменение или доработку (руководитель проекта, QA, бизнес аналитик, техлид). Полное уточнение информации, принятие решения (отклонение запроса, запуск в реализацию, оформление дополнительным оплачиваемым этапом и т.п.)
• Оформление каждого запроса на изменение или доработку в форме Change Order, подлежащего подписи заказчиком (отвечает за оформление – бизнес аналитик, за подписание – руководитель проекта).
• После утверждения изменений должно проходить обязательное обновление спецификаций, тест-кейсов и т.д.
• Определение целесообразности начала тестирования следующего деливери.

Критерий начала:

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

Определяет готовность версии к тестировании по багтрекинговой системе, ответственный QA. Все требования, которые необходимо реализовать в определенном деливери, внесены в багтрекинговую систему с пометкой «Реализовать в x.y.» и, соответственно, попадают в фильтр «Деливери x.y.». Когда все или большинство требований, попадающих в фильтр, будут реализованы, версию можно передавать на тестирование QA.

• Определение готовности деливери к отправке. Критерии готовности:

• все требования, относящиеся к данному деливери (фазе), реализованы;
• открытые дефекты, относящиеся к данному деливери (фазе), отсутствуют.

Определяет по багтрекинговой системе QA и уведомляет руководителя проекта. Все требования, которые необходимо реализовать в определенном деливери, внесены в багтрекинговую систему с пометкой «Реализовать в x.y.» и, соответственно, попадают в фильтр «Деливери x.y.». Когда все требования и дефекты, попадающие в фильтр, будут закрыты, версию можно отсылать заказчику.

Мы рассмотрели пример процесса управления изменениями в ИТ проекте. Одна из распространенных ошибок – одноособное управление требованиями исходящее от руководителя проекта. Залог успеха – групповое обсуждение изменений, достижение компромисса со всеми учасниками.

План-график работ проекта (лучше всего – в MS Project). Должен показывать:

• Объем и дату каждого деливери.
• Объем работ на каждом этапе.
• Основные вехи.

Примеры основных вех:

• MILESTONE- утверждение спецификаций (в план должно быть заложено время на ревю и утверждение спецификаций заказчиком).
• MILESTONE- утверждение плана тестирования деливери Х (QA менеджер составляет план тестирования следующего деливери, который должен быть утвержден менеджером проекта).
• MILESTONE- завершение кодирования по деливери X (разработчики успешно закончили кодирование функционала, предназначенного для сдачи в деливери X).
• MILESTONE- QA приемка деливери (QA тестирует деливери на территории заказчика, если требуется, и дает «добро»).
• MILESTONE- готовность деливери Х к отправке (все фичи реализованы, а дефекты успешно исправлены – деливери можно отправлять заказчику).
• MILESTONE- готовность пользовательской документации (финальная документация, которую необходимо передать заказчику, должна пройти ревю менеджера проекта).
• MILESTONE- приемка деливери заказчиком (используя набор приемочных тестов, PM получает формальное одобрение продукта заказчиком).
• MILESTONE- проведен тренинг (заказчика необходимо обучить согласно заранее подготовленному плану).

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

• QA инженеры проинформированы об объеме проекта, сути, оценке, графике, составе проектной группы, задачах и обязанностях её членов.
• Все требования к ПО определены и приняты (зафиксированы в ТЗ и спецификациях, причём достаточно детализированы).
• Есть план разработки по версиям.
• Разработчики выполняют тестирование кода (Unit, Stress и Integration тестирование).
• Определён подход к тестированию.
• Установлена среда тестирования.

2 Работы
Объем работы зависит от качества входной информации, а именно: спецификаций, объёма и сложности проекта, требований.
Для повышения эффективности можно выполнять сразу несколько видов тестов.
Тестирование, как и разработка, носит итеративный характер. Каждую итерацию:

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

2.1 Определение требований, подлежащих тестированию
QA определяет требования, подлежащие тестированию, и определяет их приоритеты. Отталкивается QA от ТЗ, плана разработки по версиям, спецификаций – всего, что имеется в наличии и относится к требованиям к системе, которую необходимо разработать.
После этого можно создавать тест кейсы, сценарии, тестовые данные.
Эта работа тесно связана с планированием и оценкой.

2.2 Планирование тестирования
Для проекта составляется план тестирования, включающий в себя стратегию и подход, компоненты и конкретные требования, подлежащие тестированию, критерии приёмки системы, вид и глубину тест кейсов и сценариев.
Подробнее о проектном документе тест план написано здесь: http://www.seolux.com.ua/archives/89.

2.3 Тест дизайн
Подробнее тест дизайн описан здесь: http://www.seolux.com.ua/archives/103.

2.3.1 Описание сценариев
Тестирование бизнес-процесса или его логической части описывается сценарием. Сценарий виртуально моделирует поведение пользователя.
Сценарии базируются на определенных тест кейсах и представляют рабочий процесс с конечным результатом.
У каждого сценария есть описание и предварительная подготовка данных (где это необходимо).

2.3.2 Функциональные тест кейсы
Подробнее о функциональных тест кейсах написано здесь: http://www.seolux.com.ua/archives/110.

2.3.3 Чек-листы для тестирования GUI
Для того, чтобы протестировать требования к GUI (графический интерфейс пользователя), обычно достаточно составить чек-лист. Он должен опираться на стандартные соглашения в дизайне интерфейса и специальные запросы заказчика. Полезно классифицировать требования на те, что относятся ко всему приложению, и те, что относятся к отдельным частям.
Обычно для всего приложения создается общий GUI чек-лист, поскольку в большинстве случаев разные формы и части функционируют практически одинаково.

2.3.4 Подготовка тестовых данных
Чтобы составить полный тест план, необходимо определить полный набор необходимых данных в базе данных, которые, в идеале, должны быть всегда готовы на момент начала тестирования. Необходимые данные определяются на стадии написания тест кейсов (для прохождения которых необходимо наличие готовых данных в системе). Перед началом тестирования определённые тестовые данные должны быть подготовлены. Обычно данные создаются средствами GUI самой системы или с помощью скриптов, заполняющих базу данных необходимыми значениями.
Как только база данных готова, рекомендуется заархивировать базу данных для сохранения тестовых данных для тестирования следующих версий. В следующей итерации, по возможности, из архива просто восстанавливается необходимое для тестирования состояние базы данных.

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

2.4 Выполнение тестирования
Существует несколько видов тестов. Их нужно разграничить в плане проекта, так как некоторые из них можно проводить одновременно, а другие – в строгой логической последовательности.

2.5 Регистрация и прослеживание дефектов
Все найденные дефекты должны быть зарегистрированы в базе данных трекинга дефектов с соответствующими атрибутами (краткий отчет, описание, приоритет, шаги по воспроизведению, версия и др.). Затем дефекты прослеживаются QA инженером согласно процедуре трекинга дефектов.

2.6 Оценка качества
После окончания тестирования каждой версии проводится оценка результатов тестирования, и в итоге создается Test Summary Report (Итоговый отчет по тестированию). Отчет содержит следующую информацию:

• Выполненный объем тестирования
• Статистика и перечень дефектов
• Заключение о качестве продукта

На основании этих данных QA инженер делает заключение о версии – выполнены ли предъявленные к данной версии приёмочные критерии.

3 Критерии выхода
Следующие критерии показывают, может ли продукт тестирования выйти из фазы QA:

• Проект был протестирован и доведен до конца в результате итераций до совпадения с нужными критериями.
• Тестирование было выполнено согласно тест плану.
• Все тест кейсы, установленные для фазы, успешно прошли на тестовой конфигурации.
• Все найденные дефекты с высоким приоритетом были исправлены и прошли проверку.