Se ha denunciado esta presentación.
Utilizamos tu perfil de LinkedIn y tus datos de actividad para personalizar los anuncios y mostrarte publicidad más relevante. Puedes cambiar tus preferencias de publicidad en cualquier momento.

Тестирование в условиях Lean: как приручить MVP?

9.682 visualizaciones

Publicado el

Доклад Нины Белан на конференции SQA Days-19, 20-21 мая 2016 г., Санкт-Петербург

Publicado en: Educación
  • Sé el primero en comentar

  • Sé el primero en recomendar esto

Тестирование в условиях Lean: как приручить MVP?

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

×