Я заметил, что больше всего сложностей с внедрением Agile подходов вызывает работа над приемочными тестами. Кто-то вообще над ними не работает, кто-то делает это “для галочки”. Но, на мой взгляд, это одна из самых важных и полезных Agile практик, особенно в итеративных подходах.
Все начинается с митинга по планированию итерации. Задача, которая стоит перед командой и Product Owner – не просто обсудить план работ на следующие две недели, но и зафиксировать как можно больше деталей, чтобы избежать проблем в конце итерации. На каждую итерацию команда и Product Owner подписывают внегласный контракт о выполнении определенного объема работ, который определяется совместно. Но в любом договоре стоит оговаривать правила приема-сдачи готовой работы. Без четко сформулированных приемочных критериев все договоренности остаются размытыми и обе стороны могут этим воспользоваться.
Приемочные критерии становятся самой важной целью планирования. Их четкая формулировка позволяет обеим сторонам избежать проблем и недопониманий. Процесс обсуждения приемочных критериев порождает массу вопросов, которые могли не появиться в противном случае. Приемочные критерии станут в дальнейшем почвой для разработки автоматизированных приемочных, функциональных, интеграционных и модульных тестов. Любой написанный тест должен так или иначе иметь отношение к приемочному критерию.
Не менее важный аспект приемочных критериев – хранение информации о функциональности. Когда ваш продукт развивается интенсивно, в него быстро добавляется все новый и новый функционал. Но через некоторое время удержать все это в голове становится очень и очень непросто. Приемочные тесты, которые порождены правильными приемочными критериями, способны не просто сохранить эту информацию, но и привязать ее напрямую к приложению. То есть, в любой момент времени мы имеем возможность не просто освежить в памяти работу определенной части приложения, но и посмотреть ее в действии.
Ну и наконец, приемочные тесты становятся своего рода охранниками реализованной функциональности, живой постоянно активной спецификации к ней. Это своего рода регрессионная защита, цель которой постоянно контролировать сформулированные однажды приемочные критерии и не допускать их поломки в будущем.
Тема очень интересная и я показал лишь несколько моментов, связанных с работой над приемочными критериями и тестами. Для более детального изучения я рекомендую книгу Gojko Adzic “Specification by Example”. Книга действительно очень классная и в прошлом году стала самой популярной книгой на Agile тематику. К сожалению, у Gojko не получилось вырваться на нашу конференцию XP Days Ukraine в этом году. Но мы пригласили его партнера David Evans, тренера и разработчика с 25-летним стажем в IT, приехать и провести тренинг “Specification by Example” перед конференцией. Тренинг подготовлен по материалам книги и будет полезен всем, кто работает в Agile команде, начиная от бизнес аналитиков и заканчивая разработчиками. Данный тренинг в Европе проводится по цене около 1500 евро, но мы сумели договориться на специальную цену для Украины – 3200 гривен. Тренинг пройдет 14-15 ноября и еще есть 5 вакантных мест. Торопитесь зарегистрироваться!
Не хочешь пропускать ничего интересного? Подпишись на ленту RSS или следи за нами в Twitter!
