Дефицит ресурсов тестирования... или нет?
- 1. Дефицит ресурса тестирования… или нет? Леншмидт Анастасия АвтоТрансИнфо, Санкт-Петербург skype: a.lenshmidt a.lenshmidt@gmail.com Масштаб бедствия: 19 слайдов
- 2. Будем знакомы ● Система ЭДО (web-приложение) ● 7 разработчиков ● 2 тестировщика ● 4 интеграционных проекта Слайд 2 из 19
- 3. Основы основ Что мы используем: • jira + confluence • git + stash • selenium • slack Слайд 3 из 19
- 4. Ой, все... Слайд 4 из 19
- 5. Где собака зарыта? На что обращаем внимание: • Cycle time или время жизни задачи: сколько раз проходит цикл разработка-тестирование- разработка • Work in progress: количество одновременно тестируемых задач (возможность распараллеливать задачи) • Testability: предоставил ли разработчик инструменты и сведения о том, как тестировать Слайд 5 из 19 Почему задачи долго в тестировании?
- 6. Помнишь, как все начиналось… ● StartUp ● Разработка “в закрытую” ● 3 разработчика ● 1 тестировщик Flow: ● Есть только ветка master ● Разработчики все “сливают” сами в master ● Редкие выкладки ● Hotfix’ов мало Слайд 6 из 19 ЭТАП 0
- 7. Слайд 7 из 19 Время жизни задач ЭТАП 0
- 8. Кто решает? Flow: ● По-прежнему существует только master ● Что вливаем? Когда? – решают тестировщики ● Нужна стабильная “ветка” ● Проект запустили ● Появились пользователи ● 5 разработчиков ● 2 тестировщика ● 2 интеграционных проекта Слайд 8 из 19 ЭТАП 1
- 9. Время жизни задач Слайд 9 из 19 ЭТАП 1
- 10. Больше людей-больше веток ● 7 разработчиков ● 2 тестировщика ● 4 интеграционных проекта Flow: ● Стабильный master ● Много задач → много “веток” ● Требуется больше коммуникаций (особенно на начальном этапе) ЭТАП 2 Слайд 10 из 19
- 11. Время жизни задач Слайд 11 из 19 ЭТАП 2
- 12. Слайд 12 из 19 Что из этого вышло: ● “Релизами” (выкладкой) управляют тестировщики ● Выкладки 3-4 раза в неделю ● При попадании на тестовый стенд разработчик быстро получает feedback (нет сомнений, чей код сломал ветку) ● В любой момент времени можем выложить hotfix или срочную задачу
- 13. Ближайшие цели: Прогон автотестов локально на ветках разработчиков: ● feedback максимально рано (на любом этапе разработки) ● разработчики не тратят время на проверку базового функционала Слайд 13 из 19
- 14. Еще немножко Слайд 14 из 19 “историй из жизни”
- 15. Автотесты Слайд 15 из 19
- 16. Локальные тестовые стенды Хорошо, если он не 1. И их не 1 000, а ровно столько, сколько нужно тестировщику Слайд 16 из 19 или
- 17. Удобно-это так: Слайд 17 из 19
- 18. Выводы: ● Всегда ориентируйтесь на ситуацию ● Будьте готовы к переменам ● Делайте удобные процессы ● Пишите документацию ● Расставляйте приоритеты ● Договаривайтесь Слайд 18 из 19
- 19. На заметку • Slack https://slack.com/is • Errbot http://errbot.io/ • ChatOps https://speakerdeck.com/jnewland/chatops-at-github • Про наши автотесты http://sqadays.com/ru/talk/16562 • Behave http://behave.readthedocs.org/en/latest/tutorial.html Слайд 19 из 19