Anton Stoliar SQADays2012 Управление качеством в Agile. Как опередить баги.
Download as PPTX, PDF0 likes347 views
Документ касается управления качеством в agile, с фокусом на предотвращение дефектов и улучшение процессов тестирования. Основные принципы включают важность командной ответственности, понимание видения продукта и реализацию времени на тестирование в спринтах. Также обсуждаются практические советы по планированию спринтов и минимальной функциональности для релиза, чтобы избежать проблем с регрессией.
More Related Content
Similar to Anton Stoliar SQADays2012 Управление качеством в Agile. Как опередить баги.(20)
Anton Stoliar SQADays2012 Управление качеством в Agile. Как опередить баги.
- 1. Управление качеством вAgile. Как опередить баги. Антон Столяр. EPAM Systems
- 2. Антон Столяр - >3лет Agile экспертизы - Проекты: от 3 до 70 человек - Senior Software Testing Engineer Email: [email protected] FB: https://www.facebook.com/anton.stolyar
- 3. Чего от васждет ваш проект как от QA?
- 4.
- 5. Поддержка? Уровень сопровождения продукта(SLA) Мы гарантируем качество ТОЛЬКО на критическом пути
- 6.
- 7. А бывает иначе! • Agile Манифест 2.1 • Команда и ответственность важнее индивидуумов и взаимодействия • Бизнес ценность важнее рабочего продукта. Сам продукт не имеет ценности. Важно то, что вы можете сделать при его помощи. • Развитие партнёрских отношений важнее сотрудничества с клиентом • Готовиться к изменениям важнее реакции на изменения
- 8. Полезные советы! Несколько практик,как QA может улучшить продукт не найдя ни одного дефекта. Фокус на предотвращение дефектов.
- 9. Давайте договоримся! Не путаем Scrum И Scrumно
- 10. Еще момент! • УВас достаточно полномочий / лидерства • Ваш Scrum действительно напоминает Scrum (а не только Stand-ups) • Вы хотите улучшить текущий процесс.
- 11. Виденье продукта Есть лиу каждого участника команды единое понимание Виденья продукта?
- 12. Виденье продукта продукта?
- 13.
- 14. Виденье продукта Преимущества • Легко внедрить • У всей команды одинаковое понимание продукта • Как следствие меньше ошибок в реализации логики • Меньше переделок Подводные камни • Вы сами не понимаете в чем заключается Vision продукта • Очень хлопотно получить от заказчика этот злосчастный Vision
- 15.
- 16. Планируем Спринт Задача 1: Командаразработки набрала задач учитывая Dev Velocity. Команда QA оценила тестирование всех задач в 240 часов. Capacity всей QA команды 100 часов. Вопрос: где взять еще 140 часов на тестирование?
- 17. Планируем Спринт Задача 2:Эффектнабегающей волны
- 18. Планируем Спринт Задача 2:Эффектнабегающей волны
- 19.
- 20.
- 21.
- 22. Планируем Спринт Итого: • Планируемспринт так чтобы успело УЗКОЕ ЗВЕНО. • Не даем разработчикам тянуть с фиксами коммитами до последнего дня. • При спринте в 10 дней: 6-й день – Feature Freeze, 8-й день – Code Freeze
- 23. Планируем Спринт Преимущества • Внедряется за 1-2 спринта • Планируем более пессимистично -> более правдоподобно • Снижаем вероятность овертаймов для QA • Закладываем время на регрессию Подводные камни • Не можем менять процесс разработки • Не пользуемся Story Points и Velocity • А у нас и так все хорошо
- 24. Минимальная функциональность для релиза Release is coming…. А регрессия и не начиналась
- 25. Минимальная функциональность для релиза • Этому учат на тренингах Certified Product Owner
- 26. Минимальная функциональность для релиза Преимущества • Все горит, а регрессию еще не начинали • Понимаем что покрываем регрессией в первую очередь Подводные камни • Ну нас достаточно времени чтобы протестировать все • Есть четкие и ясные приоритеты
- 27. Выводы Vision • Дешево и быстро внедрить Sprint • Понимание ценности Planning продукта для бизнеса позволяет принимать Min Release правильные решения и делать правильные вещи • I’s just a thinking tools :-)
- 28.
- 29.
- 30.
- 31.
- 32.