В своем докладе я расскажу о том, как мы адаптировали процесс разработки, в команде, где упор делался на максимальное качество и при этом был всего 1 тестировщик. Доклад будет состоять из двух частей. В первой я расскажу как взяв за основу методологию Crystal Agile мы скомпоновали набор из необходимых нам практик, отсекая все лишнее и получили процесс полностью устраивающий команду, направленный на обеспечение максимального качества. В этой части будут подниматься следующие вопросы: •Какие практики наиболее ценны с точки зрения тестировщика •Как безболезненно добавить практики XP и Kanban в Scrum процесс •Как не отсечь лишнего -Как превратить скомпонованный набор практик в работающий подход Вторая часть доклада будет посвящена непосредственно тому, как облегчить жизнь единственного тестировщика на большом проекте, в частности будут рассмотрены такие вопросы? •Как научить заказчика писать требования •Быстрое создание и поддержка тестовой документации, миф или реальность? •Быстрое внедрение автоматизации •Тестирование нефункциональных требований

1. Crystal Agile: процесс
обеспечивающий качество

2. Состав команды
• 5 Менеджеров
• Распределенная команда:
– 3 центра разработки
– 11 разработчиков
• Разработчики имеют выраженную специализацию
• 1 тестировщик

3. Внедрение процесса

4. Артефакты
1.Резерв проекта
2.Резерв спринта
3.Планирование с игрой в покер
4.Ежедневные митинги
5.Диаграмма сгорания

5. Что-то пошло не так?
• Тестирование «внезапно» стало сваливаться на
последние 4-5 дней итерации
• Резерв спринта не закрывался после
планирования
• Митинги отнимают много времени
• Автоматизация отсутствует

6. Анализ проблем
• Неэффективное планирование.
• Система оценки времени на разработку
неэффективна
• Невозможно закрыть спринт после
планирования итерации
• В угоду скорости страдает качество кода,
накапливается технический долг
• Время тестировщика тратится на активности не
связанные с тестированием

7. Что дальше?
Лучше.Хуже
Время
col1

8. Выбираем решение
• Прогнуться под
процесс
• Своя методология

9. Crystal Agile
• Human-powered
• Ultralight
• Stretch-to-fit

10. Решение проблем

11. Внутреннее качество
1.Внедряем TDD
2.Сталкиваемся с проблемами на этапе
внедрения
3.Отказываемся от TDD в пользу BDD

12. Проблемы планирования
• Члены команды разбиты на группы,
поддерживающие разные модули
• Разработчики используют разные языки
программирования
• Внутри групп используются различные по
сложности технологии
• Покер планирования не работает

13. Проблемы покера
• Каждый член команды имеет равный вес,
что влечет за собой возможность
недооценки или переоценки необходимого
времени
• Время тестировщика оценивается всей
командой

14. Что делать?
Переходим от покера планирования к методу взвешенных
экспертных оценок
1. В планировании участвуют только те кто будет разрабатывать
2. Вес голоса зависит от «релевантности» разработчика
3. Коэффициенты зависят от предыдущей эффективности
4. Обязательно вводим в планирование время на юнит тесты, не
даем оценок только по функционалу
5. Время на тестирование оценивается тестировщиком совместно
с ответственным разработчиком
6. Планирование нацелено на сокращение простоев
тестировщика

15. Плючы подхода
• Оценки стали более точными, что
позволяет рационально планировать время
тестировщика в спринте
• Оценки учитывают все аспекты разработки
(BDD, интеграционное тестирование)

16. Спринт не резиновый
• Некоторые страны не успевают дать список
задач до начала планирования
• В любой момент может появиться
«горящая» задача

17. Двух зайцев одним
выстрелом
1. Работаем с «горящими» задачами
При 10-дневном спринте каждый загружается на 9 дней.
В итоге каждый член команды имеет день в запасе на urgent задачи.
Как мы работаем с такими задачами:
• Если приходит задача емкость которой в человеко-часах больше, чем наш
резерв – задача переносится на следующий спринт
• Задачи меньшего размера берутся в работу лишь до того момента, пока есть
резерв
2. Уменьшаем технический долг

18. Технический долг
Внутренний бэклог проекта содержит такие
задачи как:
• Рефакторинг
• Написание юнит- и компонентных тестов
• Написание автотестов по готовым
сценариям
• Работа с to-do

19. Митинги
Проблема:
5 менеджеров в разных странах. Количество звонков порой
доходило до 5 в день.
Решение проблемы:
• Назначение ответственного за разработку задачи
• Ограждение обычных разработчиков от лишних обсуждений
• Смена ответственных по окончании итерации

20. Стендапы не нужны?
Перенос этой активности в Jira:
• Start Work – Stop Work
• Активность за день описывается в таске
одним кратким, но понятным
комментарием.

21. Внедряем автоматизацию
Наличие
«некрасивого»
автотеста
значительно лучше,
нежели его
отсутсвие

22. Плюсы «некрасивых»
тестов
Плюсы таких тестов в начале проекта:
• Быстро создаются
• Предоставляют быструю обратную связь
• Помогают вовлечь разработчиков в тестирование
• Являются заготовками для будущих «красивых» тестов

23. Сервисы?
• Низкий порог вхождения
• Возможность быстро создать test suite для запуска полного
теста в один клик
• Тесты можно включить в CI
• Возможность разрабатывать тесты используя Mocks
параллельно с имплементацией
• Возможность создания Load и Security тестов

24. Резработчики: привлекаем
внимание
Цель: «Подсадить» программистов на тестирование
1. Демонстрация работы автотестов и объяснение основого
смысла:
- Быстрая обратная связь
- Возможность быстро и самостоятельно проверить качество
перед коммитом
2. Демонстрация Selenium IDE

25. Разработчики: обучение
1. Возвращаем «подсевших» на качество разработчиков в родную
стихию:
- Переход от IDE к RC или WebDriver
- Выделение времени на перевод старых тестов с IDE на Java
2. SoapUI тесты для неподдатливых:
- Обучение созданию
- Расширение возможностей с Groovy
- CI

26. Agile?

27. Заключение
• Гибкая методология может быть гибко приспособлена под
нужды команды
• Не стоит бояться экспериментов с техниками
• По настоящему высокого качества можно достигнуть лишь тогда
когда над этим работает вся команда.
• В команде должен быть человек, который недоволен текущим
процессом

28. +375-44-751 75
99
Вопросы
Igor.bondarenko@neklo.com