Командная работа: из традиционного тестирования в гибкое

Красиво, когда продукт выделяется среди своих конкурентов, как художественная гимнастка в толпе газонокосилок. Но для этого нужно уметь предугадывать желания целевых клиентов и муштровать проект в этом ключе, постоянно тестируя и корректируя функционал.

И,

Чтобы новые продукты танцевали как гимнастки на пике карьеры, компании переходят от традиционных методов разработки и тестирования (Waterfall) к гибким (Agile).

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

Но люди-то не любят перемены. Традиционно у нас всё максимально формализовано – требования, процедуры и даже сферы ответственности. А в гибких методологиях некоторые звенья размываются, способы взаимодействия становятся более личными. И что потом с этим делать – непонятно. Особенно заметна ситуация с точки зрения тестирования и QA.

Какие-то компании нанимают специальных тренеров, гуру гибких методологий, кто-то справляется своими силами и обучает команду шаг за шагом. Мы в Webmart QA ребята самостоятельные, поэтому на своём опыте уже научились, что и как лучше делать. Так что предлагаем наше видение на переход из Waterfall в Agile – с матчастью, шагами и разбором проблем в контексте тестирования. Поехали!

Процесс разработки продукта в Agile состоит из ряда циклов по 1-4 недели, называемых итерациями. Каждая итерация считается обособленным проектом и включает в себя планирование, проектирование, написание кода, тестирование и ретроспективу.

Как это всё вообще работает:

• Круглый стол

Гибкая разработка не любит формальностей, поэтому решения по проекту принимает вся команда. Тестеры участвуют во всех встречах команды – сидят на ежедневных митингах, говорят на ретроспективе, вносят свои предложения и правки. Даже если сидят отдельно от разработчиков!

• Планирование

Как мы уже сказали, Agile реализуется в форме итераций. Для успешного завершения каждого цикла, команда тщательно планирует для себя пул задач, и да, тестировщики тоже сидят и планируют. Вообще мы считаем участие тест-специалиста в оценке объёмов работ самым прямым инвестированием в успех проекта. Потому что только так о тестировании не забудут, и качество готового продукта будет на высшем уровне.

К функционалу ПО относятся строго. Если функция сделана, но не протестирована – задача не считается закрытой. Все члены команды это понимают, поэтому работают над планом итерации очень тщательно. Спасибо командной ответственности, которая позволяет избежать раздувания функционала продукта.

• Общая ответственность

Задачи итерации – это задачи для всей команды. Конечно, дизайнер вряд ли может помочь разработчикам. Но если у тестера есть время, то он готов предложить свои руки и голову кодерам. Из этого принципа, кстати, и происходит практика разработки через тестирование (TDD, Test Driven Development ). Мы обязательно подробнее расскажем об этой интересной практике в следующих статьях, не пропустите!

В свою очередь, если тестер зашивается в работе, а конец (итерации) близок, то прогеры выступают единым фронтом и проводят, к примеру, тестирование производительности.

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

• дизайнера и разработчика (применённый новый внешний вид);
• разработчика и тестировщика (стабилизированная функция или новая фича);
• разработчика, тестировщика и менеджера (собранная стабильная версия);
• владельца продукта и менеджера проекта (актуальная информация, своевременное управление запросами и требованиями, обратная связь).

А чтобы конечный результат всех устроил, важно правильно перейти от традиционных методов разработки и тестирования к гибким. Приведём ниже наше видение этапов перехода.

Из Waterfall в Agile за 5 шагов:

1. Митинги.

Первым и самым действенным шагом будет внедрение ежедневных 15-минутных stand-up встреч команды. Суть встреч в том, чтобы каждый участник рассказал, чем он занимался вчера, каких результатов добился, чем будет заниматься сегодня и какие цели перед собой ставит. Параллельно обсуждаются возникающие затруднения и сложности, по которым коллектив может выработать решение, а менеджер – подтвердить тот или иной план реализации.

2. Переоценка.

Затем менеджер проекта меняет подход к оценке разработки требований. Он делит весь жизненный цикл на 1-4 недельные итерации, которые наполняются соответствующими задачами для успешного релиза конечного продукта. Обязательными задачами будут: реализация требований, тестирование, стабилизация, демонстрация/ретроспектива, релиз (на актуальный тестовый либо продуктивный контур). Для эффективного планирования каждой итерации требуется высокая квалификация как менеджера проекта, так и ведущих специалистов направлений разработки и тестирования.

3. Дефектология.

Теперь изменяется система ведения учета задач и дефектов. Каждое требование, задача назначается на определенную версию продукта, билда, программы, приложения. Команда участвует в планировании сроков и объемов работ. Т.е. подразумевается изменение таск- и баг-трекинга и информирование команды.

4. Роли.

Редактируем ответственность за отдельные результаты работы команды. Необходимо назначить на каждую активность одного основного исполнителя. Здесь одним из главных критериев эффективности будет отсутствие перегрузки ответственностью одного участника и недогрузки других. Так что менеджеру проекта придётся научиться жонглировать людьми и задачами.

5. Документирование.

В соответствии с разработанными планами итераций, все требования, доработки, тесты и исправление существующих проблем планируются также в связке с версией продукта (или определенной итерацией).

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

Проблемы при переходе от Waterfall к Agile:

• Документационная амнезия.

То, что при каскадной разработке без документов никак – это знают все. Но и с Agile стандарты, шаблоны, планы тестирования и тест-кейсы никуда не пропадают!

Это очень большая составляющая работы по обеспечению качества (QA), и мы не советуем ей пренебрегать. Стандарты помогают приводить процессы, требования и критерии к общему знаменателю. Используйте документы в лёгкой форме, тогда не возникнет диссонанс по поводу того, что «мы вроде гибкие, работаем в agile, а тут снова куча бумажек». Бумажки и не нужны, просто старайтесь письменно подводить итоги митингов и каждой итерации – это поможет определить направление, в котором вы идёте и сопоставить его с вашими целями.

Делайте доступные для команды документы на общем облачном диске или используйте инструменты вроде OneNote. Обязательно организуйте всю команду для участия в ведении таск- и баг-трекинга. Для этого всего, в том числе и для учёта требований, лучше использовать единую систему.

• Цикличное тестирование.

В Waterfall этап тестирования идёт прямо перед выпуском готового продукта. До его начала тестировщики могут не иметь ни малейшего понятия о функционале и целях создаваемого ПО. А в Agile тестировать необходимо в каждой итерации, вникая во все детали и полностью погружаясь в проект. К этому нужно привыкнуть. Пока проверять ещё нечего, тестеры изучают требования, пишут тест-кейсы и разрабатывают авто-тесты.

Автоматизация очень важна в Agile, поскольку короткие временные промежутки требуют частых проверок. Мы рекомендуем специально закладывать время на создание новых и модернизацию существующих тестов в план каждой итерации.

Затем каждый новый билд проверяется на живучесть, а вместе с ним и все последовательно добавляемые функции. Здесь тестирование – это не одноразовое мероприятие, а постоянный процесс.

За 2 дня до конца итерации функционал не пополняется, тестируется версия билда, которая будет показана владельцу проекта на демонстрации в последний день итерации.

• Хромающая дисциплина.

Командная ответственность, к сожалению, не всегда приводит к общей дисциплинированности. И мы думаем, что для Agile важно всей командой сесть и выработать DOD – Definition of Done или параметр «Готово». Это позволит определить, насколько таск выполнен и выполнен ли он вообще. При этом, для каждого случая и каждой команды DOD уникален!

Что касается тестирования, вы можете определять готовность, к примеру, так:

Для задачи:

• На основные моменты написаны авто-тесты
• Тесты успешно проходятся

Для функции:

• Написаны приёмочные авто-тесты
• Неавтоматизированные тесты добавлены в чек-лист
• Функция идёт со статусом Validated

Для итерации:

• Билд прошёл тестирование и не крэшится
• Билд понравился владельцу проекта на демонстрации
• Добавлены заявленные функции
• Вся документация одобрена

И так далее. Напоминаем, это только пример. Вся суть DOD и его предназначение – дисциплинировать вашу команду, чтобы каждый участник согласился с критериями готовности и применял их к себе. Так коллективная ответственность будет на высоком уровне.

Да, оказывается, переход из Waterfall в Agile вряд ли будет лёгким и беззаботным, придётся много общаться, решать конфликты и создавать культ круговой поруки. Но! Это сторицей окупится, поскольку:

1. Продукт будет постоянно развиваться и каждые 2-4 недели вы будете получать успешно реализованный объём функциональности.

2. Вы сможете управлять объёмами работ, увеличивая и уменьшая задачи, входящие в версию.

3. Проектная команда будет не конкурирующими отделами, а станет большой дружной семьей, которая сфокусирована на общих целях в рамках итерации и всего жизненного цикла проекта.

4. Тестировщики будут постоянно работать с проектом, смогут на самом деле консультировать, обеспечивать и контролировать его качество.

5. Соответственно, качество продукта не поставит конечного пользователя в тупик.

6. Ваше ПО будут использовать, покупать и советовать друзьям.

7. PROFIT!

Поделитесь своим опытом в комментариях. Приходилось ли вам менять модель тестирования, как вы это делали, возникли ли проблемы, тормозящие разработку нового продукта, и как вы с ними разобрались? Мы тоже присоединимся к обсуждению ;)