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