QA в Agile. Старая сказка на новый лад.

Время от времени мне на голову сваливаются вопросы. Вот недавно знакомый попросил рассказать о том, какие особенности тестирования в аджайле.

Вот, скажем, есть в организации проект. Реализовывать его планируется с помощью какой-нибудь из гибких методологий, благо их теперь много. Ну, скажем, пускай это будет скрам, хотя это и не принципиально. Под этот новый проект выделили народ. Все как положено: разработчиков, тестировщиков, продакт овнера и Бог знает кого еще, неважно, но тестировщики есть точно. Так вот, проект этот стартует со дня на день и надо понять, что надо учесть при формировании команды и организации ее работы, чтобы шишек поменьше (то, что они будут в любом случае, не обсуждается :) набить?

Вообще, вопрос про QA и Agile на голову сваливается постоянно, мы даже на работе сравнительно недавно его обсуждали, хотя, казалось бы, давно уж аджайлим. И не мы одни, куча умных дядек пишут и говорят много, долго и, к сожалению, разное. В чем же подвох такой с этой проблемой, что никак не получается прийти к одному мнению. Я вот тоже решил добавить путаницы и «вкинуть свои пять копеек», т.е. изложить свое мнение, а заодно испортить карму товарищу, который меня снова к этому размышлению вернул :)

Мне кажется, что решить эту задачку не получается по одной простой причине — она не с той стороны решается. Давайте посмотрим на гибкие методологии с точки зрения истории их возникновения. Помнится мне, что одной из первых таких методологий, которая получила более-менее широкую известность, было экстремальное программирование (ХР). Если же посмотреть на более поздних ее сородичей, можно увидеть, что базовые технические (!) принципы у них очень схожи с ХР, а учитывая ее «первичность», то я лично считаю, что они унаследованы из ХР.

Что такое ХР — это методология, созданная программистами для программистов. Если посмотреть на ее принципы, то видно, что тестировщиков там вообще не предвиделось: в ХР от тестирования по сути остается только модульное тестирование, к которому тестировщики обычно не имеют отношения, и приемочное, которое выполняется либо на стороне заказчика, либо группой QA, которая все равно отделена от команды разработки. В любом случае, тестировщики выпадают из этой методологии, их роль не определена, технологии и принципы взаимодействия не прописаны. Вот отсюда, как мне кажется, и растут ноги у нашей проблемы, ну, как минимум, левая нога. Решением проблемы, с моей точки зрения, является, как ни странно, игнорирование проблемы. За прошедшее время тестировщики наработали кучу методов и принципов тестирования, надо просто забыть о том, что это какая-то новая методология и применять то, что уже успешно наработали в рамках того же ватерфола. Ведь не отменяет же аджайл, скажем, ООП для разработчиков, так почему она должна изымать что-то из арсенала тестировщиков?

Ладно, с технической стороной понятно, используем старые методы. Но ноги должно быть две, это вам любой ребенок скажет :) Вот вторая нога растет из проблем понимания роли документации в аджайле и проблем с планированием, и тут, как мне кажется, и кроется основное различие между аджайлом и «не очень аджайлом».

Тестировщики очень любят документацию, хотя бы потому, что она здорово облегчает жизнь, на ее основе мы строим критерии завершения тестирования, определяем необходимое покрытие и т.д. Так случилось, что часто в проектах, использующих гибкие методологии, документации нет или вместо нее написано что-то очень странное и совсем бесполезное, ибо «мы же гибкие». Знаю, сейчас любители аджайла, и особенно скрама, закидают меня камнями, мол это глупость, методология позволяет нам иметь ту документацию, которую мы хотим иметь. Позволяет, но на практике я видел гораздо больше команд, которые не пишут документацию, или пишут вместо документации какое-то недоразумение, объясняя это тем, что так надо согласно методологии, чем тех, которые здраво и взвешенно к этой самой документации подходят. Так что вывод — документация нужна, иначе тестировщики у вас зачахнут, а это чревато не только для них.

К уже описанной проблеме с документацией добавляется проблема планирования. Вот как раньше жили тестировщики, мы четко (да, я идеалист) знали, что сейчас вот закончится фаза девелопмента, и готовились тестировать. И под это у нас четко было определено время, мы успевали написать кучу тестовых сценариев, планов, подготовить тестовые данные и т.д. А дальше начинался кавардак, потому как после первого же дефекта, это все шло лесом — код переписывался, добавлялись/менялись сценарии, сдвигались сроки. Собственно потому и появились новые методологии. Теперь этот кавардак, хоть и в гораздо меньшей степени, мы имеем на каждой итерации. Спасает то, что итерации маленькие, и проще корректировать планы на будущее. Но нас догоняет старое доброе «плохое планирование», только чуть в другой ипостаси. Дело теперь не в том, что времени на задачу заложили мало или, наоборот, много, а в том, что при планировании учитывается только вес самого таска, без учета взаимодействия между субкомандами, скажем QA и разработчиков. Да, я знаю, что в рамках гибких методологий никаких субкоманд нет, команды не делятся, но раз уж мы делаем все-таки разную работу, это надо учитывать и лично мне удобнее представлять наличие таких вот «команд в командах». Вот простой пример, который постоянно наблюдается: скрам, спринт, планирование провели, выбрали несколько историй так, чтобы они поместились в спринт. А потом радостно завалили этот самый спринт сразу по двум причинам — во-первых не учли, что тестировщики могут начать тестирование только тогда, когда есть хоть какой-то функционал в рамках задачи (а если это начало проекта, то проблема будет еще веселее, т.к. функционала вообще зачастую поначалу нет), т.е. тестирование начнут не с начала спринта, соответственно и закончат, не тогда, когда планировали, и во-вторых, почему-то всегда забывают про то, что задача включает в себя еще и исправление багов, а они вообще не просто появятся только тогда, когда тестировщики наконец начнут тестирование (я предполагаю, что подготовка к нему все же началась с начала спринта), а будут продолжать появляться, причем параллельно девелоперы будут еще допедаливать остаток функционала и исправлять найденные уже дефекты, порождая новые. Не знаю почему, но на эти грабли в тот или иной момент наступили все команды, с которыми пришлось работать, или в которых работают мои знакомые.

Если сравнивать аджайл с тем же ватерфолом, то по большому счету мы просто имеем кучу релизов и если убрать указанный «зазор» в планировании, который больше связан с человеческим фактором, то для тестировщика практически ничего не изменится, — получается то же деление итерации на фазу разработки, тестирования и стабилизации, но просто в меньшем масштабе. Так что я упорно склоняюсь к тому, что особенностей тестирования и его планирования в Agile по сравнению с водопадом практически нет, просто объем помельче и релизы почаще :)

Напоследок хочется таки указать на одну серьезную особенность. В аджайле здорово возрастает значение регрессионного тестирования, причем не в том странном виде, когда регрессией считается перепроверка дефектов, а в том, что при внесении изменений в продукт нужно перепроверить ранее написанный функционал на предмет появления новых ошибок. Почему так, просто потому, что функционал меняется чаще. В том же водопаде код мог очень сильно меняться, однако это случалось не так часто, обычно такое изменение было спровоцировано либо найденным дефектом уровня архитектуры либо изменениями в требованиях, но это действительно было нечасто, хотя бы потому, что все понимали как это дорого :) В аджайле изменение кода превращено в правило, так что хотим мы этого или не хотим, но от регрессионного тестирования нам никуда не деться. Причем его объем будет постоянно расти от спринта к спринту и к этому надо быть готовым. Например, наконец начать автоматизацию :)

Но это пожалуй и все особенности, так что товарищу, если он еще сам не прочитал :), я порекомендую писать документацию (или напрячь кого-нибудь другого :), учитывать особенности планирования тестирования в спринте и автоматизировать то, что нужно автоматизировать, и тестить, тестить, тестить :)