Напомню в чем смысл каждой из них по версии ISTQB:
- Кanban — гибкая методология семейства Agile, основная цель которой визуализировать поток работы, оптимизировать его и сократить время разработки.
Отличительными особенностями Kanban являются:
- Наличие Kanban Board — доски, на которой видны состояния тех или иных задач, связанных с конкретными видами деятельности, например находятся эти задачи в стадии разработки или тестирования.
- Work-in-Progress Limit. Это означает, что на каждой стадии на Kanban Board может находится определенное число задач. Брать новую задачу в разработку можно только если закончена одна из предыдущих. Также если на одной из стадий закончились задачи, ответственные за эту стадию могут отправится помогать выполнять задачи на стадию предшествующую.
- Lead Time. У каждой задачи есть фиксированное время между ее созданием и закрытием, которого необходимо придерживаться.
- Наличие Kanban Board — доски, на которой видны состояния тех или иных задач, связанных с конкретными видами деятельности, например находятся эти задачи в стадии разработки или тестирования.
- XP — гибкая методология семейства Agile, основная цель которой обеспечить высокую скорость написания кода, а так же использовать основные практики программирования в парах, делая обширный обзор кода, модульное тестирование всего кода, а также достижение простоты и ясности в коде. При использовании Scrum часто внедряются основные практики XP.
- Scrum — гибкая методология семейства Agile, набор принципов, на которых строится процесс разработки, позволяющий в жёстко фиксированные и небольшие по времени итерации, называемые спринтами (sprints), предоставлять конечному пользователю работающее ПО с новыми возможностями, для которых определён наибольший приоритет.
Отличительными особенностями Scrum являются:
- Product Increment — команда работает равными промежутками времени, называемыми спринтами, за которые обязуется разработать, протестировать и ввести в эксплуатацию определенный функционал приложения.
- Product Backlog, Sprint Backlog — функционал приложения разбит на задачи, которые приоритезируются в список и выполняются в соответствии с ним.
- Definition of Done — по завершении работы над функционалом должны быть выполнены заранее утвержденные требования, называемые Definition of Done. Требования устанавливаются заранее и обсуждаются всей командой.
- Daily Stand Up Meeting — ежедневная встреча, основная цель которой получить ответы от каждого члена команды на 3 вопроса: “Что я сделал вчера”, “Что буду делать сегодня” и “Какие у меня есть трудности”. Это увеличивает видимость всего процесса разработки для всей команды.
У всех вышеописанных методологий одна цель — быстро доставить до конечного пользователя качественный продукт. Все это — гибкие методологии. Если при использовании водопадной модели процесс тестирования весьма прост и понятен, потому что выполняется последовательно, после завершения активной фазы разработки, то в Scrum все не так легко.
А как построен Scrum у нас?
Команда состоит из PO (Product owner), Scrum Master и Developing Team, которая в свою очередь состоит из 1 QA Automation, 1 Backend developer, 1 Frontend developer, 1 UX и 1 верстальщика. Разработка идет итерационно, спринтами по 2 недели. Во время каждого спринта проводится несколько типов встреч:
- Planning — планирование спринта, набор задач на ближайшие 2 недели из Backlog проекта.
- Backlog refinement — разбор Road map проекта, оценка задач, лежащих в Backlog.
- Demo — показ результатов спринта, оценка проведенных работ, принятие решения об успешности спринта.
- Retro — обсуждение положительных и отрицательных моментов спринта, поиск решений, необходимых для устранения отрицательных моментов.
- Daily meeting — ежедневный митинг для того, чтобы увидеть ситуацию на проекте от лица каждого члена команды.
Процесс выполнения задачи проходит следующим образом:
- На планировании задача попадает в Backlog текущего спринта из Backlog проекта
- После переходит в статус In dev на Scrum Board и разработчики приступают к выполнению
- Результат выполнения задачи заливается в отдельную feature ветку в git
- Задача переходит из статуса “In dev” в статус “In test“на Scrum Board
- Результат выливается на тестовый стенд и тестируется
- Реализуются автотесты на выполненную задачу
- После этого написанные автотесты и реализованный функционал отправляются в основную ветку проекта в Git — в develop
- Когда все задачи выполнены и покрыты автотестами происходит их сборка на CI. При успешном выполнении сборки (пройдены все unit и автотесты) приложение автоматически раскатывается на внутренний демо стенд для проведения демо.
- Если результат спринта принят успешно — сборка раскатывается на пром сервер.
Что же происходит в начале спринта для автоматизатора тестирования и в конце спринта для разработчика? Ведь казалось бы в начале спринта еще нет выполненных задач, а в конце спринта уже не остается задач, которые не были бы переведены на тестирование. А происходит приблизительно одно и то же, оптимизация кода, рефакторинг, внедрение новых инструментов и тому подобное.
Как пример для автоматизатора — внедрение Allure отчетов, для девелопера — оптимизация работы запросов.
Тестирование в Scrum
В начале процесса автоматизации тестирования необходимо настроить CI, чтобы проводить регрессионное тестирования автоматически. Цель — свести ручную работу к минимуму. Потому что времени ни на что нет, нужно работать быстро. После этого стоит заняться репозиторием, настроить запуск сборки по Merge request. Если кто-то из разработчиков отправил что то в основную ветку проекта, запускается сборка и по ее результатам можно понять корректны ли внесенные изменения.
Перед тем как приступить к написанию тестов, необходимо разобраться в основной бизнес-идее проекта, чтобы определить области высокого риска на которые обращается внимание в первую очередь. Все таки будем реалистами, полностью покрыть тестами приложение, пусть оно и маленькое, не получится. Сазерленд писал, что на реализацию всего Бэклога никогда нет времени, поэтому он всегда применял к Backlog принцип Парето. Пишем 20% автотестов, покрывающих 80% возможных дефектов.
При написании тестов нужно добиваться максимальной абстракции. Не стоит писать код функции, которую можно будет использовать только при определенных условиях. Намного лучше реализовать ее так, чтобы максимально переиспользовать код, изменяя входные параметры.
Эффективная работа в Scrum невозможна без тесной работы с разработчиком, потому что времени для самостоятельного изучения кода мало. Быстрее и качественнее получится результат, если получать информацию из первых уст. Как реализован тот или иной функционал, что при этом использовалось. Это важно для понимания внутренней структуры.
Необходимые качества автоматизатора тестирования
Автоматизатор, а в Scrum особенно, должен быть технически подкован, чтобы понимать как работает приложение так сказать “под капотом”. Важно уметь быстро и легко переходить с одной технологии на другую. Например, при изменении базы данных, нужно быть готовым изменить способ подключения к ней. Стек технологий должен быть как можно шире.
Scrum предполагает быструю реакцию на изменения, срочное внесение исправлений. Предположим, что пользователи обнаружили некое несоответствие в работе приложения, команда разработки должна как можно быстрее отреагировать и выпустить патч. Для этого важно уметь очень точно локализовать проблему. В этом очень хорошо помогает автотестирование. Допустим у нас есть трехуровневое web-приложение: есть DB, frontend, backend. Где то в приложении есть баг. При использовании ручного тестирования поиск проблемы может занять не один день, затем проблему нужно будет исправить и вновь протестировать. При автотестировании мы запускаем регрессоное тестирование и в течение пары часов получаем полный отчет, в котором отражено точное местоположение бага.
Комментарии (21)
osigida
22.12.2016 23:33+1Все больше и больше набирает обороты использование методологий семейства Agile, так называемых гибких методологий, в сфере IT
Вот уже лет двадцать как, а у кого то, все еще, обороты не набраны :-(VolCh
23.12.2016 09:51Вы удивитесь, но много где Agile или даже не пытались внедрять, или попытки провалились.
SSul
26.12.2016 18:05Полностью согласен с одним из комментаторов. Вы удивитесь, но многие даже не слышали о том, что есть такая методология. Полноценно набирать популярность в бизнесе они начинают сейчас.
i_vino
26.12.2016 05:26Заголовок — «Автоматизация тестирования по методологии Scrum» — явно ошибочен. Scrum никак не описывает автоматизацию тестирования (а описывает управление проектом), и даже, строго говоря, не является методологией. Впрочем статья в целом никак не соотносится с SEO-ориентированным заголовком.
По теме статьи, считаю, что ветвь — выделения в команду QA-автоматизатора, чтобы «свести ручную работу к минимуму» — тупиковая, ну и особенно, если других тестировщиков в команде нет. Так называемая «ручная» работа, а на самом деле «мозговая» — является краеугольным камнем тестирования, она приносит наибольшую пользу всему проекту, поэтому нет никакого смысла сводить её к минимуму. Что вероятно имел в виду автор — свести к минимум регрессионное тестирование (небольшую часть работы тестировщика), что разумно — но работает это гораздо лучше, когда сами программисты занимаются этой частью автоматизации. Роль типичного «автоматизатора» должна по моему мнению заключаться в обучении программистов и помощи им в технических вопросов. Или другими словами — автоматизатор, это такой же девелопер, с бОльшими познаниями в технологии написания автотестов.VolCh
26.12.2016 14:00Считаю неправильным в общем случае навешивать на разработчиков основного кода и автоматизацию тестирования на уровне большем чем юнит-тесты, ну, максимум, интеграционные тесты. Роль типичного автоматизатора должна, по моему мнению, заключаться в разработке функциональных, приёмочных, нагрузочных и прочих высокоуровневых тестов. Да, ему нужны навыки разработки, но несколько другие чем у обычных разработчиков, в общем случае ему не обязательно даже знать основной язык на котором разрабатывается система. Полезно, позволяет упростить/ускорить тестирование отдельных кейсов, но не обязательно. Вполне может обходиться высокоуровневыми средствами, абстрагированными от основного языка разработки.
tundrawolf_kiba
26.12.2016 17:50+1Согласен с вами. Зачем в принципе программисту изучать тот же TestComplete для Blackbox-тестирования десктопного приложения. Учитывая, что по времени написание таких тестов будет примерно аналогично собственно разработке функционала.
i_vino
26.12.2016 21:21> Учитывая, что по времени написание таких тестов будет примерно аналогично собственно разработке функционала.
Если считать это верным (к счастью, это не всегда верно) — то можно сразу поставить крест или на скраме. или на автоматизации с TestComplete — просто не будете успевать в одной итерации решить эти две задачи.tundrawolf_kiba
26.12.2016 22:44Ну тут можно поступить так:
а) Автоматизация — это хорошо и полезно, но не настолько, чтобы тормозить из-за этого весь процесс, она может идти параллельно
б) BDD — если ручные тестировщики начнут писать в этом формате, а ароматизаторы только имплементировать эти шаги, то после первичного завала, через несколько месяцев объем работы будет уже вполне вменяемый
VolCh
27.12.2016 09:49А зачем их решать в одной итерации? Задача разработки в одной итерации, её результат — оттестированый вручную сценарий, покрытие автотестами в следующей, её результат фиксация этого оттестированного и, может, уже работающего в проде сценария.
i_vino
26.12.2016 21:20Хочу напомнить, что «юнит-тесты и интеграционные» и должны составлять львиную долю автотестов (см. «пирамида автотестирования», так что даже противоречия тут никакого нет.
Считаю, что высокоуровневые автотесты не могут ускорить тестирование — только замедлить могут.
Ускорить можно прогоны регрессии. Успевать с автоматизацией высокоуровневой регрессией в скраме — чрезвычайно сложно, хотя наверное возможно, если иметь хороших специалистов. В данном случае важно убедить всех членов команды, что спринт не может считаться успешным, если не закончены задачи автоматизации регрессии. На практике — очень непростое дело.VolCh
27.12.2016 09:46Количественно, в штуках, да, львиную. По времени при нормальной архитектуре юнит-тесты практически не отнимают времени, интеграционные (в узком понимании) отнимают побольше, но не сильно. А вот тестирующее всё приложение в целом — много.
Основная задача автотестов — именно выявление регрессий. Грубо, в случае высокоуровневых сначала проходим сценарий ручками, а потом фиксируем его поведение автотестом. Вплоть до трансляции событий ручного прохождения в код, даже не глядя в результат трансляции.
Необязательно закрывать спринт задачами автоматизации выявлений регрессий, можно закрывать ручным тестированием, а открывать следующий автоматизацией. Так можно и устранить временной разрыв. В начале спринта тестировщики пишут автотесты на прошлый, а по мере готовности задач разработчиков тестируют их ручками.
SlavikF
Ко всем этим скрамам подходит фраза «Гладко было на бумаге, да забыли про овраги»…
Причём даже не в том смысле, что реальная жизнь отличается от теории.
А в том, что сама теория (методология) кривая.
Сам я какое-то время работал QA manager, потом уехал в США и здесь SDET.
Проблема тестирования в скраме в том, что предполагается, что разработчики работают над определённым количеством задач (фич, багов) в течении спринта, а тестеры их тестируют. Так вот — тестерам всегда нужно какое-то время ПОСЛЕ разработчиков для того, чтобы:
1) протестировать то, что накодили разработчики
2) протестировать на регрессию
Понятно, что разработчики не будут в это время сидеть без дела и ждать, что там тестеры найдут, поэтому они берутся за новые задачи. Но это должны быть или задачи из следующего спринта (а этого как бы быть не должно — мы же ещё в этом спринте), или добавляются задачи в текущий спринт, но тогда тестерам нужно дополнительное время опять же ПОСЛЕ разработчиков.
Это ещё дополняется отношением разработчиков, к спринту: «ну так у нас ещё 3 дня до конца спринта». Это если у них 3 дня, то у тестеров тогда не остаётся ничего.
Поэтому с точки зрения тестирования, скрам — это костыльный процесс.
Автоматизация помогает, но
1) как автор заметил — полностью всё авто-тестами не покроешь
2) для написания тестов тоже нужно время и обычно ПОСЛЕ разработчиков.
SlavikF
Кстати, по описанию, в Канбане, вроде бы не должно быть этой проблемы — там как раз по процессу есть время на тестирование ПОСЛЕ разработки.
Не знаю, может это мне не повезло, но вот никогда не работал по Канбану — всегда, где я работал, когда говорят Agile, то обычно это скрам со спринтами. Может потому, что он бизнесу больше нравится из-за того, что там вроде как есть бОльшая управляемость / прогнозируемость?
VolCh
Там есть планы хотя бы на две недели :)
koropovskiy
В Канбане возможны очень те же «проблемы», собственно там будет происходить так нелюбимый всеми «простой ресурсов» из-за узких мест, которые хорошо выявляет наличие ограничения по WiP.
Аналитики могут завалить разработчиков и ждать пока те разгребут проанализированные задачи. Разработчики -> тестировщиков. Если есть жизнь после тестирования — то тестировщики следующих за ними (например «специалисты по развертыванию»)
Конечно хорошо бы все эти узкие места расширять. Но в моей практике не взлетело. В результате спринты остались лучше по прогнозируемости чем канбан.
AnisimovAM
Лучше всего, когда тестами покрывают свой код сами разработчики. У нас обычно перед слиянием своего кода, ты его сам покрываешь автотестами.
ApeCoder
1) Почему нельзя разработчикам добавлять новый код в ветке относящейся к следующему спринту. Так будет выпущен стабильный оттестированный спринт n и не затормозится работа над спринтом n+1
2) В идеологии канбан, насколько я помню, команд должна работать как единое целое и над тем, чтобы задачи прошли через доску быстрее. То есть часть разработчиков может вполне заняться тетированием.
ApeCoder
What are developers expected to do during testing in the latter half of each Sprint?
FractalizeR
Я, наверное, чего-то не понимаю, но причем тут скрам? Да, я часто сталкивался с теми проблемами, которые вы описываете, но мне кажется, что это всего лишь неумение руководства грамотно организовать процесс разработки. Разработчики всегда кодят, а тестеры всегда за ними тестируют. И если рассуждать в вашем ключе, тестеры никогда не будут успевать протестить все, что накодили разработчики, просто по определению.
Скрам ведь не говорит, что разработчики должны кодить всю неделю фичи из спринта. Скрам говорит всего лишь об итерациях, в течение которых происходит разработка. Но ведь эти итерации нужно грамотно реализовать, не так ли? Скажем, использование TDD несколько снижает нагрузку на тестеров в конце спринта. И мне бы хотелось поработать в компании, где сумели грамотно TDD применить.
SSul
Вы пишете правильные вещи, я согласен. Но конкретно в нашем случае мы решаем эти проблемы следующим образом:
1) начало спринта. задач в тестировании нет, автотестер занимается тем, что вкручивает дополнительные фичи в проект (как пример, Allure отчеты, реализация паралелизации тестов в GRID и так далее). Либо же оптимизация кода, рефакторинг. В общем есть чем заняться.
2) конец спринта. задачи все в тестировании, либо закрыты, на разработке задач не осталось. Разработчики занимаются тем же самым. Оптимизация кода, рефакторинг, внедрение дополнительно функционала, не так ценного для бизнеса, но очень ценного технически.
3) На мой взгляд все подобные проблемы решаются грамотным планированием, пониманием, что такое Agile и правильно построенными коммуникациями.
SlavikF
Эта фраза означает, что «да, нам нужны костыли».
То, что этот костыль вы называете «грамотным планированием» особо ничего не меняет.
Это означает, что применением Скрама не получается делать нормальное планирование, поэтому приходиться добавлять «понимание».
Такие вот реалии.