Зачем мы тестируем? Или как понять, что мы организовали это правильно 2.0

Transcript

1. зачем мы тестируем? или как понять, что мы организовали это правильно
2. > 10 лет в IT team lead / resource manager в EPAM systems on-site QA manager в Швейцарии и Бельгии enterprise проекты в телеком и финансовых доменах СТАНИСЛАВ БАДОВ
3. цели 01 подготовка 02 план результат 04 выполнение 03
4. введение промышленные проекты
5. участники
6. участники бизнес
7. участники бизнес команда разработки
8. участники бизнес команда разработки конечные пользователи
9. инфраструктура
10. модель A1 A2 B1 B2 C1 C3 C2 ресурсы
11. модель A1 A2 B1 B2 C1 C3 C2 D1 D2 D3 D4 ресурсы
12. модель A1 A2 B1 B2 C1 C3 C2 E1 E2 D1 D2 D3 D4 ресурсы
13. модель A1 A2 B1 B2 C1 C3 C2 E1 E2 D1 D2 D3 D4 ресурсы
14. модель A1 A2 B1 B2 C1 C3 C2 E1 E2 D1 D2 D3 D4 ресурсы интеграции system C system A system D system B
15. модель A1 A2 B1 B2 C1 C3 C2 E1 E2 D1 D2 D3 D4 ресурсы интеграции system C system A system D system B F1 F2 G1 G2
16. модель A1 A2 B1 B2 C1 C3 C2 E1 E2 D1 D2 D3 D4 ресурсы сервисы интеграции system C system A system D system B F1 F2 G1 G2 service A2 service A1
17. модель A1 A2 B1 B2 C1 C3 C2 E1 E2 D1 D2 D3 D4 ресурсы сервисы интеграции system C system A system D system B F1 F2 G1 G2 service A2 service A1 service B1 service B2
18. модель A1 A2 B1 B2 C1 C3 C2 E1 E2 D1 D2 D3 D4 ресурсы сервисы интеграции system C system A system D system B F1 F2 G1 G2 service A2 service A1 service B1 service B2 service C1 service C2
19. модель A1 A2 B1 B2 C1 C3 C2 E1 E2 D1 D2 D3 D4 ресурсы сервисы интеграции system C system A system D system B F1 F2 G1 G2 service A2 service A1 service B1 service B2 service C1 service C2 service D1 service D2 service D3 service D4
20. project title свойства промышленного проекта сложная архитектура огромное количество сценариев разное понимание процессов
21. многообразие сценариев A1 A2 B1 B2 C1 C3 C2 E1 E2 D1 D2 D3 D4 system C system A system D system B F1 F2 G1 G2 service A2 service A1 service B1 service B2 service C1 service C2 service D1 service D2 service D3 service D4 A1 A2 B1 B2 C1 C3 C2 E1 E2 D1 D2 D3 D4 system C system A system D system B F1 F2 G1 G2 service A2 service A1 service B1 service B2 service C1 service C2 service D1 service D2 service D3 service D4 A1 A2 B1 B2 C1 C3 C2 E1 E2 D1 D2 D3 D4 system C system A system D system B F1 F2 G1 G2 service A2 service A1 service B1 service B2 service C1 service C2 service D1 service D2 service D3 service D4 A1 A2 B1 B2 C1 C3 C2 E1 E2 D1 D2 D3 D4 system C system A system D system B F1 F2 G1 G2 service A2 service A1 service B1 service B2 service C1 service C2 service D1 service D2 service D3 service D4
22. многообразие сценариев A1 A2 B1 B2 C1 C3 C2 E1 E2 D1 D2 D3 D4 system C system A system D system B F1 F2 G1 G2 service A2 service A1 service B1 service B2 service C1 service C2 service D1 service D2 service D3 service D4 A1 A2 B1 B2 C1 C3 C2 E1 E2 D1 D2 D3 D4 system C system A system D system B F1 F2 G1 G2 service A2 service A1 service B1 service B2 service C1 service C2 service D1 service D2 service D3 service D4 A1 A2 B1 B2 C1 C3 C2 E1 E2 D1 D2 D3 D4 system C system A system D system B F1 F2 G1 G2 service A2 service A1 service B1 service B2 service C1 service C2 service D1 service D2 service D3 service D4 A1 A2 B1 B2 C1 C3 C2 E1 E2 D1 D2 D3 D4 system C system A system D system B F1 F2 G1 G2 service A2 service A1 service B1 service B2 service C1 service C2 service D1 service D2 service D3 service D4
23. project title свойства промышленного проекта сложная архитектура огромное количество сценариев разное понимание процессов
24. пересечение выполняемых сценариев конечные пользователи тестировщики
25. project title свойства промышленного проекта сложная архитектура огромное количество сценариев разное понимание процессов
26. 01 цели
27. 01 цели Как определить, что тестирование выполнено хорошо?
28. метрики Defect Containment = баги найденные до релиза баги найденные до релиза + баги найденные после релиза * 100%
29. метрики Defect Removal Efficiency = баги найденные до релиза баги найденные до релиза + баги найденные после релиза * 100% DRE измеряет способность команды разработки исправлять дефекты до релиза.
30. пересечение выполняемых сценариев тестировщики конечные пользователи тестировщики конечные пользователи
31. цели минимизировать количество багов, которые обнаружит конечный пользователь
32. цели проверять сценарии, выполняемые пользователями 1 минимизировать количество багов, которые обнаружит конечный пользователь
33. цели проверять сценарии, выполняемые пользователями 1 тестировать на конфигурации приближенной к продакшену 2 минимизировать количество багов, которые обнаружит конечный пользователь
34. 02 подготовка
35. документы стратегия долгосрочные активности время релиз 1 релиз 2
36. документы стратегия долгосрочные активности план план активности с привязкой ко времени / фазам время релиз 1 релиз 2
37. документы стратегия долгосрочные активности план план активности с привязкой ко времени / фазам подход краткосрочные активности время релиз 1 релиз 2
38. планирование окружение 1 план
39. планирование окружение 1 покрытие 2 план
40. планирование окружение 1 покрытие 2 приоритет 3 план
41. окружение smoke test 1 test 2 новый релиз
42. окружение smoke test 1 test 2 clean installation новый релиз предыдущий релиз < новый релиз
43. окружение smoke test 1 test 2 clean installation новый релиз предыдущий релиз < новый релиз backup post release
44. окружение smoke test 1 test 2 clean installation новый релиз предыдущий релиз < новый релиз backup post release - конфигурация тестовых серверов максимально возможно приближена к продакшену - сторонние библиотеки аналогичны продакшену
45. покрытие 2 профиля: сценарии состояние системы и данных
46. сценарии представители бизнеса бизнес аналитики конечные пользователи
47. состояние системы и данных new release данные созданные до установки релиза 1
48. состояние системы и данных new release данные созданные до установки релиза 1 данные созданные после установки релиза 2
49. состояние системы и данных new release данные созданные до установки релиза 1 данные созданные после установки релиза 2 незавершенный процесс запущенный до установки 3
50. приоритет CRITICAL (3 points) MEDIUM (2 points) LOW (1 point) ПРИОРИТЕТ ДЛЯ БИЗНЕСА ЧАСТОТА ИСПОЛЬЗОВАНИЯ ВЛИЯНИЕ ОТ ИЗМЕНЕНИЯ 2 3 1
51. тест план stabilization release candidate тест кейсы, различный приоритет тест установки тест обратной совместимости development DUE DATES разработки только багфикс установка поверх ревизии продакшена время
52. 03 выполнение тестирование - не чемпионат по поиску дефектов
53. 04 результат Как определить, что тестирование завершено?
54. exit criteria
55. exit criteria 100 80 20 Execution rate, % Pass Rate, %
56. acceptance criteria 2. нет открытых багов с приоритетом: blocker critical high 1. все запланированные тесты выполнены;
57. заключение
60. CMMI (Capability Maturity Model Integration) 1. Начальный • Процессы непредсказуемые, слабо контролируемые. • Процессы появляются в ответ на определенные события 2. Управляемый • Процессы определены на уровне проектов. • Зачастую процессы появляются в ответ на определенные события 3. Определенный • Процессы определены на уровне всей организации. • Процессы исполняются заблаговременно. 4. Управляемый на основе количественных данных • Процессы измеряются и контролируются. 5. Оптимизируемый • Фокус на совершенствование процессов.
61. /badov.s /stanislav-badov вопросы