Секреты успешной
подготовки проекта
глазами тест менеджера
astoundcommerce.com
2
Почему мы затеяли этот разговор?
Тестировать = хотя бы проверять, что
• всё то, что должно работать
• работает так, как ожидалось
Тестировать = просто в конце проекта
убедиться в том, что «оно работает»
Just to make sure everything works ©
3
Успешный проект
PMBok: “проект успешен, если
заказчик удовлетворен”.
Agile: “проект успешен, если выполнен
согласно утвержденным критериям
контракту: объёму, сроку, качеству”.
PRojects IN Controlled Environments 2
(PRINCE2): “проект успешен при
сбалансированности по крайней мере по
трем категориям — бизнеса, ориентации
на пользоателя и технологической
зрелости”.
4
Cитуация, в которой конкретная бизнес-цель
достигнута при соблюдении проектных органичений:
• бюджет,
• время,
• содержание проекта.
Успешный проект
5
Типы контрактов
a) Staff Augmentation
b) Time and Material
c) Fixed Price
6
Когда вовлекать тестировщиков в проект?
Настолько рано,
насколько это возможно 
На стадии оценок проекта,
до подписания контракта
Но зачем?
7
Как начинать проект, когда контракт
уже подписан?
● Пересмотреть требования и оценки
● Проанализировать устав проекта (Statement of Work,
SOW) на предмет скоупа, допущения, процедуры
приемочного тестирования
● Выяснить ожидания клиента по качеству и тест
процеса
● Определить риски
● Уточнить тип контракта
● Пересмотреть график работ
● Провести перепланирование тестирования
● Определить тест стратегию, и задокументировать ее
в тест-плане
● Общаться, обсуждать, уточнять
8
Когда контракт еще не подписан
Тестировщикам надо заняться следующим:
● Анализировать бизнес-требования
● Оценивать содержание тестирования (test scope),
используя допущения (assumptions)
● Уточнять график работ по проекту
● Прогнозировать структуру команды
тестировщиков
● Согласовывать процесс и критерии приемки работ
● Идентифицировать риски
● Финализировать устав проекта (Statement Of
Work)
9
Как анализировать требования?
● Выяснить бизнес-цель и приоритеты клиента
● Обсудить ожидания клиента:
● требования (функциональные и
нефункциональные)
● тестовые артефакты
● критерии качества
● окружение...
● Определить процес тестирования учитывая модель
разработки
● Обсудить процес приемки работ, критерии старта и
выхода из тестирования
● Спрашивать, обсуждать МНОГО со всеми
участниками процеса анализа
10
Как оценивать тестирование того,
чего еще нет?
● Опыт и экспертиза
● Исторические данные по схожим проектам
● Стандартизованые подходы и шаблоны к оценкам
● Оценка ВСЕХ тест-активностей и задач используя
допущения (assumptions)
● Work Breakdown Structure
● Идентификация рисков
● ОБЩЕНИЕ! Спрашивать и уточнять
11
Как оценивать тестирование того,
чего еще нет?
12
Как оценивать тестирование того,
чего еще нет?
13
Допущения (assumptions)
Обстоятельства и события, которые должны быть
выполнены на протяжении всего жизненного цикла
проекта для его успешного внедрения и
завершения.
Допущения принимаются как истинные и часто без
доказательств или демонстрации.
14
Группы допущений (assumptions)
● In/Out scope
● Browsers for desktop, mobile and tablet
● Third-party vendor delivery – dates, criteria,
expectations, impact
● Limitations to testing scope, activities and tasks
● Training needs
● Merchandizing and content
● Data migration
● Acceptance procedure
● Roles and responsibilities
Далее примеры…
15
Примеры допущений (1/2)
The following document(s) was used for the estimation
purposes: <provide document(s) name, incl. document (s) version>, last
changed on <define the date when the document was changed for the last
time>.
Test estimates will be revised if new/additional or
details/updates to available documentation or/and any
new documents/files will appear.
16
Примеры допущений (2/2)
Estimates are based on the assumption that following
desktop browsers will be used only during the test
execution: <list the browsers and its versions>.
Test estimates will be revised in case additional desktop
browsers will be added to the test scope.
17
Допущения (assumptions)
Зачем:
● Минимизировать риски и заложить базу для
управления изменениями
● Одинаково понимать скоуп с командой и клиентом
Как:
● Озвучивать и формализировать во время анализа и
оценки скоупу
● В разрезе требований, тест задач и активностей
Когда:
● Каждый раз при необходимости во время анализа и
оценки скоупа
18
• Планируйте тест процес на основе ВАШЕГО опыта и
ВАШЕЙ экспертизы.
• Выясняйте и учитывайте ожидания ВАШЕГО клиента.
Чтобы проект был успешным
19
• Оценивайте все задачи для тестировщиков. ВСЕГДА.
• Используйте допущения. Чем больше, тем лучше.
Чтобы проект был успешным
20
• Самостоятельно следите за содержанием проекта.
Он меняется на протяжении всего своего
жизненного цикла.
• Идентифицируйте и отслеживайте риски проекта.
Они всегда добавляются ВНЕЗАПНО!
Чтобы проект был успешным
21
• Утверждайте и термины, и формат, и уровень
детализации тестовой документации.
• Вовлекайте и клиента, и проектную команду в
пересмотр и утверждение ваших тестовых
артефактов.
• Be aggressive when you need info.
Чтобы проект был успешным
Questions and answers
Thank you!
Alyona Chernenko-Dyba, QA Manager
Alexey Lupan, QA Trainer

QA Fest 2015. Алена Черненко-Дыба и Алексей Лупан. Секреты успешного проекта глазами тест-менеджера

  • 1.
  • 2.
    2 Почему мы затеялиэтот разговор? Тестировать = хотя бы проверять, что • всё то, что должно работать • работает так, как ожидалось Тестировать = просто в конце проекта убедиться в том, что «оно работает» Just to make sure everything works ©
  • 3.
    3 Успешный проект PMBok: “проектуспешен, если заказчик удовлетворен”. Agile: “проект успешен, если выполнен согласно утвержденным критериям контракту: объёму, сроку, качеству”. PRojects IN Controlled Environments 2 (PRINCE2): “проект успешен при сбалансированности по крайней мере по трем категориям — бизнеса, ориентации на пользоателя и технологической зрелости”.
  • 4.
    4 Cитуация, в которойконкретная бизнес-цель достигнута при соблюдении проектных органичений: • бюджет, • время, • содержание проекта. Успешный проект
  • 5.
    5 Типы контрактов a) StaffAugmentation b) Time and Material c) Fixed Price
  • 6.
    6 Когда вовлекать тестировщиковв проект? Настолько рано, насколько это возможно  На стадии оценок проекта, до подписания контракта Но зачем?
  • 7.
    7 Как начинать проект,когда контракт уже подписан? ● Пересмотреть требования и оценки ● Проанализировать устав проекта (Statement of Work, SOW) на предмет скоупа, допущения, процедуры приемочного тестирования ● Выяснить ожидания клиента по качеству и тест процеса ● Определить риски ● Уточнить тип контракта ● Пересмотреть график работ ● Провести перепланирование тестирования ● Определить тест стратегию, и задокументировать ее в тест-плане ● Общаться, обсуждать, уточнять
  • 8.
    8 Когда контракт ещене подписан Тестировщикам надо заняться следующим: ● Анализировать бизнес-требования ● Оценивать содержание тестирования (test scope), используя допущения (assumptions) ● Уточнять график работ по проекту ● Прогнозировать структуру команды тестировщиков ● Согласовывать процесс и критерии приемки работ ● Идентифицировать риски ● Финализировать устав проекта (Statement Of Work)
  • 9.
    9 Как анализировать требования? ●Выяснить бизнес-цель и приоритеты клиента ● Обсудить ожидания клиента: ● требования (функциональные и нефункциональные) ● тестовые артефакты ● критерии качества ● окружение... ● Определить процес тестирования учитывая модель разработки ● Обсудить процес приемки работ, критерии старта и выхода из тестирования ● Спрашивать, обсуждать МНОГО со всеми участниками процеса анализа
  • 10.
    10 Как оценивать тестированиетого, чего еще нет? ● Опыт и экспертиза ● Исторические данные по схожим проектам ● Стандартизованые подходы и шаблоны к оценкам ● Оценка ВСЕХ тест-активностей и задач используя допущения (assumptions) ● Work Breakdown Structure ● Идентификация рисков ● ОБЩЕНИЕ! Спрашивать и уточнять
  • 11.
  • 12.
  • 13.
    13 Допущения (assumptions) Обстоятельства исобытия, которые должны быть выполнены на протяжении всего жизненного цикла проекта для его успешного внедрения и завершения. Допущения принимаются как истинные и часто без доказательств или демонстрации.
  • 14.
    14 Группы допущений (assumptions) ●In/Out scope ● Browsers for desktop, mobile and tablet ● Third-party vendor delivery – dates, criteria, expectations, impact ● Limitations to testing scope, activities and tasks ● Training needs ● Merchandizing and content ● Data migration ● Acceptance procedure ● Roles and responsibilities Далее примеры…
  • 15.
    15 Примеры допущений (1/2) Thefollowing document(s) was used for the estimation purposes: <provide document(s) name, incl. document (s) version>, last changed on <define the date when the document was changed for the last time>. Test estimates will be revised if new/additional or details/updates to available documentation or/and any new documents/files will appear.
  • 16.
    16 Примеры допущений (2/2) Estimatesare based on the assumption that following desktop browsers will be used only during the test execution: <list the browsers and its versions>. Test estimates will be revised in case additional desktop browsers will be added to the test scope.
  • 17.
    17 Допущения (assumptions) Зачем: ● Минимизироватьриски и заложить базу для управления изменениями ● Одинаково понимать скоуп с командой и клиентом Как: ● Озвучивать и формализировать во время анализа и оценки скоупу ● В разрезе требований, тест задач и активностей Когда: ● Каждый раз при необходимости во время анализа и оценки скоупа
  • 18.
    18 • Планируйте тестпроцес на основе ВАШЕГО опыта и ВАШЕЙ экспертизы. • Выясняйте и учитывайте ожидания ВАШЕГО клиента. Чтобы проект был успешным
  • 19.
    19 • Оценивайте всезадачи для тестировщиков. ВСЕГДА. • Используйте допущения. Чем больше, тем лучше. Чтобы проект был успешным
  • 20.
    20 • Самостоятельно следитеза содержанием проекта. Он меняется на протяжении всего своего жизненного цикла. • Идентифицируйте и отслеживайте риски проекта. Они всегда добавляются ВНЕЗАПНО! Чтобы проект был успешным
  • 21.
    21 • Утверждайте итермины, и формат, и уровень детализации тестовой документации. • Вовлекайте и клиента, и проектную команду в пересмотр и утверждение ваших тестовых артефактов. • Be aggressive when you need info. Чтобы проект был успешным
  • 22.
    Questions and answers Thankyou! Alyona Chernenko-Dyba, QA Manager Alexey Lupan, QA Trainer