Тестирование в условиях Lean: как приручить MVP?
Download as PPTX, PDF0 likes9,997 views
Документ обсуждает практики тестирования в условиях Lean, акцентируя внимание на минимально жизнеспособном продукте (MVP) как способе получения обратной связи от пользователей. Нина Белан делится своим опытом в тестировании и описывает методы бизнес-анализа, работы с рисками и градации качества. Основная цель – оптимизация процессов и поддержание баланса между качеством и скоростью разработки.
Тестирование в условиях Lean: как приручить MVP?
- 1. Тестирование в условиях Lean: как приручить MVP?
- 2. О себе: Нина Белан - 3 года в тестировании - Участвовала в проектах разного масштаба и направленности - Была единственным тестировщиком на проекте, работала в команде 1
- 3. 230сотрудников 12 млнпосетителей в месяц 2003год основания 600 тыс.посетителей в день Tutu.ru — самый посещаемый сервис туристических услуг в России (по результатам исследования comScore). О Туту.ру 2
- 4. Lean Startup? О чем это? 3 1. Минимизация ненужных расходов и экономия всех возможных средств 3. Получение максимального кол-ва информации о клиенте в единицу времени 2. Вовлеченность в процесс оптимизации каждого сотрудника
- 5. MVP (Minimum Viable Product) 4 Минимальный жизнеспособный продукт, позволяющий получить осмысленную обратную связь от пользователей
- 6. MVP: Minecraft 5 - 6 дней кодинга - 1 разработчик - больше 100 релизов за 1 год
- 7. О чем мы мечтаем? - Максимальный уровень качества - Много новых крутых фич Что нам для этого нужно? - Ресурсы (деньги, время) 6
- 8. Быть может, максимальный уровень качества … не нужен? Как масштабировать тестирование под нужды проекта? 7
- 9. 8 Методологии и инструменты: 1. Бизнес-анализ задачи 2. Работа с рисками 3. Градации качества 4. Acceptance criteria для разработчиков 5. Отложенное написание документации
- 10. 9 Бизнес-анализ задачи: 1. Вовлечение в процесс оптимизации бизнеса каждого сотрудника 2. Максимальная ориентация на потребителя
- 11. 10 Работа с рисками Риски допустимые недопустимые
- 12. Фича: добавляем время обновления предложений Недопустимые риски: 11
- 15. Основные и дополнительные сценарии 14
- 16. Acceptance criteria, пример. Что проверяем? 15
- 17. 16 Acceptance criteria, как это выглядит? и так далее…
- 18. 1. Меньше сырых задач Почему это нравится тестировщикам? 17 2. Тестировщики раньше включаются в процесс работы над задачей 5. У нас есть возможность посмотреть на задачу с точки зрения нескольких человек 4. Мы учимся формулировать, конкретно и четко выделяем узкие и проблемные места в продукте 3. На тестирование задач с АС уходит меньше времени, чем на тестирование аналогичных без них
- 19. 18 Почему это нравится разработчикам? 1. Четкий список сценариев с конкретными данными, которые надо проверить 2. Предварительный анализ задачи 3. Статистика и обратная связь
- 21. 20 Отложенная документация - Пишем кейсы только на устоявшийся функционал - Без лишней детализации - Несколько раз подумаем, прежде чем написать кейс
- 22. 21
- 23. 22 Что в итоге? Все вышеперечисленные инструменты в наших реалиях правда работают – мы проверяли Они помогают нам поддерживать баланс между качеством и скоростью.
- 24. Нина Белан nbelan@tutu.ru +7 926 061-06-33 Skype: railven_milva Старший тестировщик