1.
Секреты успешной
подготовки проекта
глазами тест менеджера
astoundcommerce.com

2.
2
Почему мы затеяли этот разговор?
Тестировать = хотя бы проверять, что
• всё то, что должно работать
• работает так, как ожидалось
Тестировать = просто в конце проекта
убедиться в том, что «оно работает»
Just to make sure everything works ©

3.
3
Успешный проект
PMBok: “проект успешен, если
заказчик удовлетворен”.
Agile: “проект успешен, если выполнен
согласно утвержденным критериям
контракту: объёму, сроку, качеству”.
PRojects IN Controlled Environments 2
(PRINCE2): “проект успешен при
сбалансированности по крайней мере по
трем категориям — бизнеса, ориентации
на пользоателя и технологической
зрелости”.

4.
4
Cитуация, в которой конкретная бизнес-цель
достигнута при соблюдении проектных органичений:
• бюджет,
• время,
• содержание проекта.
Успешный проект

5.
5
Типы контрактов
a) Staff Augmentation
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.
11
Как оценивать тестирование того,
чего еще нет?

12.
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)
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.
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.
17
Допущения (assumptions)
Зачем:
● Минимизировать риски и заложить базу для
управления изменениями
● Одинаково понимать скоуп с командой и клиентом
Как:
● Озвучивать и формализировать во время анализа и
оценки скоупу
● В разрезе требований, тест задач и активностей
Когда:
● Каждый раз при необходимости во время анализа и
оценки скоупа

18.
18
• Планируйте тест процес на основе ВАШЕГО опыта и
ВАШЕЙ экспертизы.
• Выясняйте и учитывайте ожидания ВАШЕГО клиента.
Чтобы проект был успешным

19.
19
• Оценивайте все задачи для тестировщиков. ВСЕГДА.
• Используйте допущения. Чем больше, тем лучше.
Чтобы проект был успешным

20.
20
• Самостоятельно следите за содержанием проекта.
Он меняется на протяжении всего своего
жизненного цикла.
• Идентифицируйте и отслеживайте риски проекта.
Они всегда добавляются ВНЕЗАПНО!
Чтобы проект был успешным

21.
21
• Утверждайте и термины, и формат, и уровень
детализации тестовой документации.
• Вовлекайте и клиента, и проектную команду в
пересмотр и утверждение ваших тестовых
артефактов.
• Be aggressive when you need info.
Чтобы проект был успешным

22.
Questions and answers
Thank you!
Alyona Chernenko-Dyba, QA Manager
Alexey Lupan, QA Trainer