Все больше и больше набирает обороты использование методологий семейства Agile, так называемых гибких методологий, в сфере IT. К этому семейству, как вы знаете, относятся такие методологии, как Kanban, XP, Scrum и прочие, менее известные методологии.
Напомню в чем смысл каждой из них по версии ISTQB:
- Кanban — гибкая методология семейства Agile, основная цель которой визуализировать поток работы, оптимизировать его и сократить время разработки.
Отличительными особенностями Kanban являются:
- Наличие Kanban Board — доски, на которой видны состояния тех или иных задач, связанных с конкретными видами деятельности, например находятся эти задачи в стадии разработки или тестирования.
- Work-in-Progress Limit. Это означает, что на каждой стадии на Kanban Board может находится определенное число задач. Брать новую задачу в разработку можно только если закончена одна из предыдущих. Также если на одной из стадий закончились задачи, ответственные за эту стадию могут отправится помогать выполнять задачи на стадию предшествующую.
- Lead Time. У каждой задачи есть фиксированное время между ее созданием и закрытием, которого необходимо придерживаться.
- 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. Где то в приложении есть баг. При использовании ручного тестирования поиск проблемы может занять не один день, затем проблему нужно будет исправить и вновь протестировать. При автотестировании мы запускаем регрессоное тестирование и в течение пары часов получаем полный отчет, в котором отражено точное местоположение бага.
Автор: SimbirSoft
