Документ обсуждает темы, связанные с тестированием и управлением процессами разработки в веб-приложении системы ЭДО. Он описывает использование различных инструментов (Jira, Confluence, Selenium) и обращает внимание на проблемы, возникающие из-за увеличения числа задач и разработчиков. Основные выводы включают важность гибкости в подходах к тестированию и документированию процессов.

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