QA Fest 2014. Игорь Бондаренко. Agile crystal. Создание процесса нацеленного на максимальное качество продукта
Report
QAFestFollow
Nov. 4, 2014•0 likes•835 views
1 likes
Be the first to like this
Show More
views
Total views
0
On Slideshare
0
From embeds
0
Number of embeds
0
Check these out next
QA Fest 2014. Игорь Бондаренко. Agile crystal. Создание процесса нацеленного на максимальное качество продукта
Nov. 4, 2014•0 likes•835 views
1 likes
Be the first to like this
Show More
views
Total views
0
On Slideshare
0
From embeds
0
Number of embeds
0
Report
Technology
В своем докладе я расскажу о том, как мы адаптировали процесс разработки, в команде, где упор делался на максимальное качество и при этом был всего 1 тестировщик. Доклад будет состоять из двух частей. В первой я расскажу как взяв за основу методологию Crystal Agile мы скомпоновали набор из необходимых нам практик, отсекая все лишнее и получили процесс полностью устраивающий команду, направленный на обеспечение максимального качества. В этой части будут подниматься следующие вопросы: •Какие практики наиболее ценны с точки зрения тестировщика •Как безболезненно добавить практики XP и Kanban в Scrum процесс •Как не отсечь лишнего -Как превратить скомпонованный набор практик в работающий подход Вторая часть доклада будет посвящена непосредственно тому, как облегчить жизнь единственного тестировщика на большом проекте, в частности будут рассмотрены такие вопросы? •Как научить заказчика писать требования •Быстрое создание и поддержка тестовой документации, миф или реальность? •Быстрое внедрение автоматизации •Тестирование нефункциональных требований
QAFestFollow
Recommended
Crystal Agile, или как мы приспособили процесс разработки для обеспечения мак...SQALab
Роль ретроспектив в создании эффективного процесса разработкиDmitry Lobasev
Введение в performance managementCEE-SEC(R)
ALM & AgileAskhat Urazbaev
Практики масштабирования гибкой разработкиAskhat Urazbaev
Собираем кубик РубикаCEE-SEC(R)
QA Fest 2014. Игорь Бондаренко. Agile crystal. Создание процесса нацеленного на максимальное качество продукта
- Crystal Agile: процесс обеспечивающий качество
- Состав команды • 5 Менеджеров • Распределенная команда: – 3 центра разработки – 11 разработчиков • Разработчики имеют выраженную специализацию • 1 тестировщик
- Внедрение процесса
- Артефакты 1.Резерв проекта 2.Резерв спринта 3.Планирование с игрой в покер 4.Ежедневные митинги 5.Диаграмма сгорания
- Что-то пошло не так? • Тестирование «внезапно» стало сваливаться на последние 4-5 дней итерации • Резерв спринта не закрывался после планирования • Митинги отнимают много времени • Автоматизация отсутствует
- Анализ проблем • Неэффективное планирование. • Система оценки времени на разработку неэффективна • Невозможно закрыть спринт после планирования итерации • В угоду скорости страдает качество кода, накапливается технический долг • Время тестировщика тратится на активности не связанные с тестированием
- Что дальше? Лучше.Хуже Время col1
- Выбираем решение • Прогнуться под процесс • Своя методология
- Crystal Agile • Human-powered • Ultralight • Stretch-to-fit
- Решение проблем
- Внутреннее качество 1.Внедряем TDD 2.Сталкиваемся с проблемами на этапе внедрения 3.Отказываемся от TDD в пользу BDD
- Проблемы планирования • Члены команды разбиты на группы, поддерживающие разные модули • Разработчики используют разные языки программирования • Внутри групп используются различные по сложности технологии • Покер планирования не работает
- Проблемы покера • Каждый член команды имеет равный вес, что влечет за собой возможность недооценки или переоценки необходимого времени • Время тестировщика оценивается всей командой
- Что делать? Переходим от покера планирования к методу взвешенных экспертных оценок 1. В планировании участвуют только те кто будет разрабатывать 2. Вес голоса зависит от «релевантности» разработчика 3. Коэффициенты зависят от предыдущей эффективности 4. Обязательно вводим в планирование время на юнит тесты, не даем оценок только по функционалу 5. Время на тестирование оценивается тестировщиком совместно с ответственным разработчиком 6. Планирование нацелено на сокращение простоев тестировщика
- Плючы подхода • Оценки стали более точными, что позволяет рационально планировать время тестировщика в спринте • Оценки учитывают все аспекты разработки (BDD, интеграционное тестирование)
- Спринт не резиновый • Некоторые страны не успевают дать список задач до начала планирования • В любой момент может появиться «горящая» задача
- Двух зайцев одним выстрелом 1. Работаем с «горящими» задачами При 10-дневном спринте каждый загружается на 9 дней. В итоге каждый член команды имеет день в запасе на urgent задачи. Как мы работаем с такими задачами: • Если приходит задача емкость которой в человеко-часах больше, чем наш резерв – задача переносится на следующий спринт • Задачи меньшего размера берутся в работу лишь до того момента, пока есть резерв 2. Уменьшаем технический долг
- Технический долг Внутренний бэклог проекта содержит такие задачи как: • Рефакторинг • Написание юнит- и компонентных тестов • Написание автотестов по готовым сценариям • Работа с to-do
- Митинги Проблема: 5 менеджеров в разных странах. Количество звонков порой доходило до 5 в день. Решение проблемы: • Назначение ответственного за разработку задачи • Ограждение обычных разработчиков от лишних обсуждений • Смена ответственных по окончании итерации
- Стендапы не нужны? Перенос этой активности в Jira: • Start Work – Stop Work • Активность за день описывается в таске одним кратким, но понятным комментарием.
- Внедряем автоматизацию Наличие «некрасивого» автотеста значительно лучше, нежели его отсутсвие
- Плюсы «некрасивых» тестов Плюсы таких тестов в начале проекта: • Быстро создаются • Предоставляют быструю обратную связь • Помогают вовлечь разработчиков в тестирование • Являются заготовками для будущих «красивых» тестов
- Сервисы? • Низкий порог вхождения • Возможность быстро создать test suite для запуска полного теста в один клик • Тесты можно включить в CI • Возможность разрабатывать тесты используя Mocks параллельно с имплементацией • Возможность создания Load и Security тестов
- Резработчики: привлекаем внимание Цель: «Подсадить» программистов на тестирование 1. Демонстрация работы автотестов и объяснение основого смысла: - Быстрая обратная связь - Возможность быстро и самостоятельно проверить качество перед коммитом 2. Демонстрация Selenium IDE
- Разработчики: обучение 1. Возвращаем «подсевших» на качество разработчиков в родную стихию: - Переход от IDE к RC или WebDriver - Выделение времени на перевод старых тестов с IDE на Java 2. SoapUI тесты для неподдатливых: - Обучение созданию - Расширение возможностей с Groovy - CI
- Agile?
- Заключение • Гибкая методология может быть гибко приспособлена под нужды команды • Не стоит бояться экспериментов с техниками • По настоящему высокого качества можно достигнуть лишь тогда когда над этим работает вся команда. • В команде должен быть человек, который недоволен текущим процессом
- +375-44-751 75 99 Вопросы Igor.bondarenko@neklo.com
Editor's Notes
- Решение этой проблемы начали со внедрения TDD, как самого популярного средства в подобных ситуациях. Однако внедрение затянулось и даже почти застопорилось. Почему? Фраза «напиши тест» действует на разработчик магическим образом, он перестает понимать чего от него хотят. Что является критерием достаточности теста для каждого отдельного случая? А может быть стоит писать юнит тесты по тестовым сценариям? Если да, то какие группы тестов использовать? А как быть, если разработка началась, но тестировщик не успел написать тестовые сценарии? Вместо TDD внедряем BDD (Behavior Driven Developement). Что это такое? Фактически это техника, с помощью которой можно научить разработчика критически оценивать свой код и писать тесты. Для составления достаточного количества тестов разработчику необходимо определить поведение системы в ситуациях прямо покрытых требованиями и покрыть тестами лишь эти ветви кода. (Пример вынес в Notes) Фрэнк: Что такое стек? Линда: Это структура данных, хранящая объекты в порядке «первым вошел, последним вышел» или «последним вошел, первым вышел». Обычно у этой структуры есть API с такими методами, как push() и pop(). Иногда присутствует метод peek(). Фрэнк: Что делает метод push()? Линда: Метод push() принимает входной объект, например, foo и помещает его во внутренний контейнер, например, массив. Метод push() обычно ничего не возвращает. Фрэнк: Что будет, если передать методу push() два объекта, например, сначала foo, а потом bar? Линда: Второй объект bar должен оказаться наверху концептуального стека, содержащего по крайней мере два объекта, так что при вызове метода pop() объект bar должен быть извлечен первым, до первого объекта foo. Если метод pop() вызвать еще раз, должен быть возвращен объект foo и стек должен стать пустым (предполагается, что в нем ничего не было до того, как мы добавили эти два объекта). Фрэнк: Так метод pop() удаляет самый последний элемент, добавленный в стек? Линда: Да, метод pop() должен удалить верхний элемент, при этом предполагается, что в стеке есть элементы, чтобы их удалять. Метод peek() работает точно также, но при этом объект не удаляется. Метод peek() должен оставить верхний элемент в стеке. Фрэнк: Что будет, если вызвать метод pop(), когда в стек еще ничего не было добавлено? Линда: Метод pop() должен выдать исключение, показывающее, что в стек еще ничего не добавлялось. Фрэнк: Что будет, если выполнить команду push() null? Линда: Стек должен выдать исключение, так как null не является допустимым значением для метода push().
- Вторая проблема – плохое планирование. И дело не в сложности оценки в часах, дело в том, что команда разбита на группы, которые занимаются различными модулями проекта, а также используют разные технологии. Что же в таком случае плохо в Planning Poker? Каждый член команды имеет равный вес (пример 1 в ноутах) что влечет за собой возможность недооценки или переоценки необходимого времени. В итоге недооценка грозит срывом планов тестировщика. Переоценка же позволяет разработчику «филонить» в начале спринта и сдать фичу только в конце, тем самым перегружая тестировщика в конце спринта. Время тестировщика оценивается всей командой. В связи с этим сложно обосновать такие активности как написание тест-кейсов или составление спецификации по business stories.
- Каждый член команды имеет равный вес (пример 1 в ноутах) что влечет за собой возможность недооценки или переоценки необходимого времени. В итоге недооценка грозит срывом планов тестировщика. Переоценка же позволяет разработчику «филонить» в начале спринта и сдать фичу только в конце, тем самым перегружая тестировщика в конце спринта. Время тестировщика оценивается всей командой. В связи с этим сложно обосновать такие активности как написание тест-кейсов или составление спецификации по business stories. Пример 1: На планировании находятся 2 Java девелопера, 1 верстальщик, 1 тестировщик, 1 Flex/Flash разработчик, 1 JavaScript девелопер. На обсуждение выносится задача по разработке front-end приложения на Flex. Оценка флексера – 12 часов. Оценка тестировщика и верстальщика – 20 часов. Остальные оценивают в 4 часа, хотя тонкостей не знают. В итоге, даже обосновав правильность своей оценки основной разработчик уменьшает время в угоду остальным до 10 часов и в итоге не укладывается в него. То же самое с переоценкой времени, если никто не понимает как работает твой модуль, очень легко обосновать 40 часов вместо необходимых 12. Такой же пример будет для каждого пункта, их у меня из личной практики не одна сотня наберется.
- Если разрабатывается функциональность затрагивающая один модуль приложения – участвуют только ответственные за эту часть разработчики веса их голосов равны Если затрагивается комплексная фича – каждый член команды, в зависимости от модуля и используемой технологии разработки получает вес голоса Введение персональных коэффициентов зависящих от предыдущей эффективности члена команды (пример в ноутах) Обязательно вводим в тестирование время на юнит тесты, не даем оценок только по функционалу Время на тестирование оценивается тестировщиком совместно с непосредственно ответственным за разработку девелоперам Планирование ведется с учетом того, чтобы тестировщик начал работу в первый день спринта и не имел простоев в середине цикла и не был перегружен в конце (пример в ноутах) Пример: Разработчик 1 последние три спринта недооценивал время – даем ему повышающий коэффициент 1.2 Разработчик 2 наоборот имеет склонность к переоценке времени – вводим понижающий коэффициент 0.7 Пример 2: Идеальный цикл таков: Дни 1-2: Составление чеклистов по новым фичам Дни 3-4: Начало тестирования, либо написание автотестов на фичи из предыдущих релизов Дни 5-8: Тестирование по функциональностей по мере готовности День 9: Code freeze и полная регрессия День 10: Поставка и UAT Также будет сопровождающая пояснения временная диаграмма