5. Где собака зарыта?
На что обращаем внимание:
• Cycle time или время жизни задачи: сколько
раз проходит цикл разработка-тестирование-
разработка
• Work in progress: количество одновременно
тестируемых задач (возможность
распараллеливать задачи)
• Testability: предоставил ли разработчик
инструменты и сведения о том, как
тестировать
Слайд 5 из 19
Почему задачи долго в тестировании?
6. Помнишь, как все начиналось…
● StartUp
● Разработка “в закрытую”
● 3 разработчика
● 1 тестировщик
Flow:
● Есть только ветка master
● Разработчики все “сливают” сами в master
● Редкие выкладки
● Hotfix’ов мало
Слайд 6 из 19
ЭТАП 0
8. Кто решает?
Flow:
● По-прежнему существует только master
● Что вливаем? Когда? – решают тестировщики
● Нужна стабильная “ветка”
● Проект запустили
● Появились пользователи
● 5 разработчиков
● 2 тестировщика
● 2 интеграционных проекта
Слайд 8 из 19
ЭТАП 1
10. Больше людей-больше веток
● 7 разработчиков
● 2 тестировщика
● 4 интеграционных проекта
Flow:
● Стабильный master
● Много задач → много “веток”
● Требуется больше коммуникаций (особенно на
начальном этапе)
ЭТАП 2
Слайд 10 из 19
12. Слайд 12 из 19
Что из этого вышло:
● “Релизами” (выкладкой)
управляют тестировщики
● Выкладки 3-4 раза в неделю
● При попадании на тестовый
стенд разработчик быстро
получает feedback (нет
сомнений, чей код сломал
ветку)
● В любой момент времени можем
выложить hotfix или срочную
задачу
13. Ближайшие цели:
Прогон автотестов локально на ветках разработчиков:
● feedback максимально рано (на любом этапе
разработки)
● разработчики не тратят время на проверку базового
функционала
Слайд 13 из 19