Использование методологий семейства Agile, так называемых гибких методологий, в ИТ-сфере набирает все больше оборотов.
В это семейство, как известно, входят такие методологии, как Канбан, XP, Scrum и другие менее известные методологии.
Напомню, что означает каждый из них по версии ISTQB:
- Канбан — гибкая методология семейства Agile, основная цель которой — визуализировать поток работы, оптимизировать его и сократить время разработки.
Отличительными особенностями Канбана являются:
- Наличие Канбан-доски — доски, на которой виден статус тех или иных задач, связанных с конкретными видами деятельности, например, находятся ли эти задачи на стадии разработки или тестирования.
- Лимит незавершенной работы.
Это означает, что на каждом этапе на Канбан-доске может быть определенное количество задач.
Брать новое задание на развитие можно только в том случае, если выполнено одно из предыдущих.
Также, если задачи выполнены на одном из этапов, ответственные за этот этап могут пойти помочь выполнить задачи на предыдущем этапе.
- Время выполнения.
Каждая задача имеет фиксированное время между ее созданием и закрытием, которое необходимо соблюдать.
- Наличие Канбан-доски — доски, на которой виден статус тех или иных задач, связанных с конкретными видами деятельности, например, находятся ли эти задачи на стадии разработки или тестирования.
- XP — это гибкая методология семейства Agile, основной целью которой является обеспечение высокой скорости написания кода, а также использование базовых практик программирования в паре, проведение обширного ревью кода, модульное тестирование всего кода, а также достижение простота и ясность кода.
При использовании Scrum часто реализуются основные практики XP.
- Скрам — гибкая методология семейства Agile, совокупность принципов, на которых строится процесс разработки, позволяющая в строго фиксированных и краткосрочных итерациях, называемых спринтами, предоставлять конечному пользователю работающее программное обеспечение с новыми функциями, для которых определен наивысший приоритет.
Отличительными особенностями Scrum являются:
- Инкремент продукта — команда работает в равные промежутки времени, называемые спринтами, в течение которых обязуется разработать, протестировать и ввести в эксплуатацию определенный функционал приложения.
- Product Backlog, Sprint Backlog — функционал приложения разбит на задачи, которые распределены по приоритетам в список и выполняются в соответствии с ним.
- Определение готовности — по завершении работы над функционалом должны быть выполнены заранее утвержденные требования, называемые «Определение готовности».
Требования устанавливаются заранее и обсуждаются всей командой.
- Daily Stand Up Meeting — это ежедневная встреча, основная цель которой — получить ответы от каждого члена команды на 3 вопроса: «Что я делал вчера», «Что я буду делать сегодня» и «Какие трудности у меня возниклиЭ» » Это повышает наглядность всего процесса разработки для всей команды.
- Инкремент продукта — команда работает в равные промежутки времени, называемые спринтами, в течение которых обязуется разработать, протестировать и ввести в эксплуатацию определенный функционал приложения.
Все описанные выше методологии преследуют одну цель — быстро доставить качественный продукт конечному потребителю.
Это все гибкие методологии.
Если при использовании водопадной модели процесс тестирования очень прост и понятен, поскольку выполняется последовательно после завершения активной фазы разработки, то в Scrum все не так просто.
Как здесь устроен Scrum?
Команда состоит из PO (владельца продукта), Scrum Master и команды разработчиков, которая, в свою очередь, состоит из 1 специалиста по автоматизации контроля качества, 1 бэкенд-разработчика, 1 фронтенд-разработчика, 1 UX-разработчика и 1 дизайнера макетов.Разработка идет итеративно, спринтами по 2 недели.
Во время каждого спринта существует несколько типов встреч:
- Планирование — планирование спринта, набор задач на ближайшие 2 недели из Бэклога проекта.
- Уточнение бэклога — анализ Дорожной карты проекта, оценка задач, находящихся в Бэклоге.
- Демо — показ результатов спринта, оценка выполненной работы, принятие решения об успешности спринта.
- Ретро – обсуждение положительных и отрицательных сторон спринта, поиск решений, необходимых для устранения отрицательных сторон.
- Ежедневная встреча — ежедневная встреча с целью увидеть ситуацию по проекту от лица каждого члена команды.
- При планировании задача попадает в Бэклог текущего спринта из Бэклога проекта.
- Затем он переходит в статус «В разработке» на Scrum Board, и разработчики начинают внедрять
- Результат выполнения задачи выгружается в отдельную ветку Feature в git.
- Задача переходит из статуса «В разработке» в статус «В тестировании» на Scrum Board.
- Результат выливается на испытательный стенд и тестируется.
- Реализованы автотесты по выполненным задачам
- После этого написанные автотесты и реализованный функционал отправляются в основную ветку проекта в Git — на разработку.
- Когда все задачи выполнены и покрыты автотестами, они собираются на CI. Если сборка прошла успешно (пройдены все юнит- и автотесты), приложение автоматически выкатывается на внутренний демо-стенд для демо-версии.
- Если результат спринта принят успешно, сборка развертывается на производственный сервер.
И примерно то же самое происходит, оптимизация кода, рефакторинг, внедрение новых инструментов и тому подобное.
Как пример для автоматизатора — реализация отчетов Allure, для разработчика — оптимизация производительности запросов.
Тестирование в Scrum
В начале процесса автоматизации тестирования вам необходимо настроить CI для автоматического выполнения регрессионного тестирования.Целью является сведение ручного труда к минимуму.
Потому что времени ни на что нет, нужно работать быстро.
После этого стоит поработать над репозиторием и настроить сборку для использования мерж-реквеста.
Если кто-то из разработчиков отправил что-то в основную ветку проекта, сборка запускается и по ее результатам можно понять, корректны ли внесенные изменения.
Прежде чем приступить к написанию тестов, необходимо понять основную бизнес-идею проекта, чтобы выявить области повышенного риска, требующие внимания в первую очередь.
Тем не менее, давайте будем реалистами; полностью покрыть тестами приложение, даже небольшое, не получится.
Сазерленд писал, что времени на реализацию всего бэклога никогда не хватает, поэтому он всегда применял к нему принцип Парето.
Мы пишем 20% автотестов, покрывающих 80% возможных дефектов.
При написании тестов нужно добиться максимальной абстракции.
Не следует писать код для функции, которую можно использовать только при определенных условиях.
Гораздо лучше реализовать это таким образом, чтобы можно было максимально повторно использовать код, изменяя входные параметры.
Эффективная работа в Scrum невозможна без тесного взаимодействия с разработчиком, поскольку времени на самостоятельное изучение кода мало.
Вы получите более быстрые и лучшие результаты, если получите информацию из первых рук.
Как был реализован тот или иной функционал, что использовалось.
Это важно для понимания внутренней структуры.
Необходимые качества автоматизатора тестирования
Инженер по автоматизации, особенно в Scrum, должен быть технически подкован, чтобы понимать, как приложение работает «под капотом», так сказать.Важно иметь возможность быстро и легко переключаться с одной технологии на другую.
Например, если вы меняете базу данных, вам нужно быть готовым изменить способ подключения к ней.
Стек технологий должен быть как можно более широким.
Скрам предполагает быструю реакцию на изменения и срочные исправления.
Предположим, что пользователи обнаружили какое-то несоответствие в приложении, команда разработчиков должна как можно быстрее отреагировать и выпустить патч.
Для этого важно уметь очень точно локализовать проблему.
В этом очень помогает автотестирование.
Допустим, у нас есть трехуровневое веб-приложение: есть БД, фронтенд, бэкенд. Где-то в приложении ошибка.
При использовании ручного тестирования поиск проблемы может занять не один день, затем проблему нужно будет исправлять и тестировать заново.
В ходе автотестирования мы запускаем регрессионное тестирование и уже через пару часов получаем полный отчет, в котором указано точное местонахождение ошибки.
Теги: #Тестирование веб-сервисов #Тестирование мобильных приложений #Тестирование ИТ-систем #тестирование программного обеспечения #тестирование веб-приложений #тестирование приложений #автоматическое тестирование
-
Есть Ли Жизнь На Mac? Офис: Часть 2
19 Oct, 24 -
Ssd-Диски На Серверах Баз Данных?
19 Oct, 24 -
Spacex Grasshopper Установил Новый Рекорд
19 Oct, 24 -
Многоязычный Дизайн Приложения
19 Oct, 24
