1. Цель презентации:
• Побудить аудиторию пользоваться описанными техниками, которые могут помочь уменьшить количество «фейлов» со стороны QA команды в Agile-based проектах.
• Сфокусировать внимание на «фишках» которые особенно пропагандируются в Agile, которые помогают выпускать более качественный продукт
2. Какова практическая ценность презентации для аудитории:
• Поделиться конкретным опытом использования всяческих Agile-техник : Sprint Planning на основе QA оценок, Создание командного Vision-a на основе Product Canvas, First Release Baseline
• Поделиться некоторыми hint-ами когда ты вроде бы test team lead, но по факту менеджишь еще и команду разработки.
3. Для кого предназначена:
• QA которые уже работали по Agile (Scrum в частности)
• Начинающие ПМs и QA Team Leads
• Ребята которым скоро придется лидать Agile-проекты
4. Короткий план презентации по шагам:
• Чего могут жать от работы QA команды к зависимости от специфики проекта\компании
• Чего ожидают от QA в Agile
• Какие техники могут помочь выпустить более правильный\успешный\ качественный продукт
o Как формировать у команды общий Vision и как это помогает снижать дефекты в продукте
o Как планировать спринт отталкиваясь от QA-команды чтобы снизить овертаймы
o Как First Release Baseline помогает спланировать регрессию, когда совсем не осталось на нее времени
1 of 32
Download to read offline
More Related Content
Anton Stoliar SQADays2012 Управление качеством в Agile. Как опередить баги.
2. Антон Столяр
- >3 лет Agile экспертизы
- Проекты: от 3 до 70 человек
- Senior Software Testing Engineer
Email: anton.stolyar@gmail.com
FB: https://www.facebook.com/anton.stolyar
7. А бывает иначе!
• Agile Манифест 2.1
• Команда и ответственность важнее индивидуумов и взаимодействия
• Бизнес ценность важнее
рабочего продукта. Сам продукт
не имеет ценности. Важно то,
что вы можете сделать при его
помощи.
• Развитие партнёрских отношений важнее сотрудничества с клиентом
• Готовиться к изменениям важнее реакции на изменения
10. Еще момент!
• У Вас достаточно полномочий /
лидерства
• Ваш Scrum действительно напоминает
Scrum (а не только Stand-ups)
• Вы хотите улучшить текущий процесс.
14. Виденье продукта
Преимущества
• Легко внедрить
• У всей команды одинаковое понимание продукта
• Как следствие меньше ошибок в реализации логики
• Меньше переделок
Подводные камни
• Вы сами не понимаете в чем заключается Vision продукта
• Очень хлопотно получить от заказчика этот злосчастный Vision
16. Планируем Спринт
Задача 1:
Команда разработки набрала задач учитывая
Dev Velocity.
Команда QA оценила тестирование всех задач
в 240 часов.
Capacity всей QA команды 100 часов.
Вопрос: где взять еще 140 часов на
тестирование?
22. Планируем Спринт
Итого:
• Планируем спринт так чтобы успело УЗКОЕ ЗВЕНО.
• Не даем разработчикам тянуть с фиксами коммитами до
последнего дня.
• При спринте в 10 дней: 6-й день – Feature Freeze, 8-й день –
Code Freeze
23. Планируем Спринт
Преимущества
• Внедряется за 1-2 спринта
• Планируем более пессимистично -> более правдоподобно
• Снижаем вероятность овертаймов для QA
• Закладываем время на регрессию
Подводные камни
• Не можем менять процесс разработки
• Не пользуемся Story Points и Velocity
• А у нас и так все хорошо
25. Минимальная
функциональность для релиза
• Этому учат на тренингах Certified Product Owner
26. Минимальная
функциональность для релиза
Преимущества
• Все горит, а регрессию еще не начинали
• Понимаем что покрываем регрессией в первую очередь
Подводные камни
• Ну нас достаточно времени чтобы протестировать все
• Есть четкие и ясные приоритеты
27. Выводы Vision
• Дешево и быстро внедрить
Sprint
• Понимание ценности Planning
продукта для бизнеса
позволяет принимать Min
Release
правильные решения и делать
правильные вещи
• I’s just a thinking tools :-)