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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Управление изменениями проекта.

Управление изменениями проекта

В любом проекте происходят изменения инициированные заказчиком или командой. Для успешного завершения проекта этими изменениями придется управлять руководителю проекта. Иначе проект может оказаться вечным.

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

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

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

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

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

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

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

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

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

Как проверить сайт.

Как проверить сайт

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

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

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

Не стесняйтесь напоминать о себе исполнителю, чем чаще, тем лучше. Ведь о Вас могут попросту забыть.  А еще лучше требуйте посмотреть промежуточный результат.

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

Как проверить, что сайт соответствует именно вашим требованиям, изложенным в техническом задании? Обратиться к специалисту по контролю качества QA. Скорее всего, это будет именно тот аналитик, что помогал составлять техническое задание. Хотя в идеале это должны быть совсем разные люди. Будьте уверены, Ваш сайт еще на протяжении минимум двух недель будет дорабатывать компания с раздутым именем.

Как известно, скупой платит дважды, в редких случаях трижды. Заложив в бюджет создания сайта работу по описанию требований и их тестированию от 20% до 30% стоимости всей разработки, позволит Вам избежать многих подводных камней на пути к успеху.