- PVSM.RU - https://www.pvsm.ru -
Все больше и больше набирает обороты использование методологий семейства Agile, так называемых гибких методологий, в сфере IT. К этому семейству, как вы знаете, относятся такие методологии, как Kanban, XP, Scrum и прочие, менее известные методологии.
Напомню в чем смысл каждой из них по версии ISTQB:
Отличительными особенностями Kanban являются:
Отличительными особенностями Scrum являются:
У всех вышеописанных методологий одна цель — быстро доставить до конечного пользователя качественный продукт. Все это — гибкие методологии. Если при использовании водопадной модели процесс тестирования весьма прост и понятен, потому что выполняется последовательно, после завершения активной фазы разработки, то в Scrum все не так легко.
Команда состоит из PO (Product owner), Scrum Master и Developing Team, которая в свою очередь состоит из 1 QA Automation, 1 Backend developer, 1 Frontend developer, 1 UX и 1 верстальщика. Разработка идет итерационно, спринтами по 2 недели. Во время каждого спринта проводится несколько типов встреч:
Процесс выполнения задачи проходит следующим образом:
Что же происходит в начале спринта для автоматизатора тестирования и в конце спринта для разработчика? Ведь казалось бы в начале спринта еще нет выполненных задач, а в конце спринта уже не остается задач, которые не были бы переведены на тестирование. А происходит приблизительно одно и то же, оптимизация кода, рефакторинг, внедрение новых инструментов и тому подобное.
Как пример для автоматизатора — внедрение Allure отчетов, для девелопера — оптимизация работы запросов.
В начале процесса автоматизации тестирования необходимо настроить CI, чтобы проводить регрессионное тестирования автоматически. Цель — свести ручную работу к минимуму. Потому что времени ни на что нет, нужно работать быстро. После этого стоит заняться репозиторием, настроить запуск сборки по Merge request. Если кто-то из разработчиков отправил что то в основную ветку проекта, запускается сборка и по ее результатам можно понять корректны ли внесенные изменения.
Перед тем как приступить к написанию тестов, необходимо разобраться в основной бизнес-идее проекта, чтобы определить области высокого риска на которые обращается внимание в первую очередь. Все таки будем реалистами, полностью покрыть тестами приложение, пусть оно и маленькое, не получится. Сазерленд писал, что на реализацию всего Бэклога никогда нет времени, поэтому он всегда применял к Backlog принцип Парето. Пишем 20% автотестов, покрывающих 80% возможных дефектов.
При написании тестов нужно добиваться максимальной абстракции. Не стоит писать код функции, которую можно будет использовать только при определенных условиях. Намного лучше реализовать ее так, чтобы максимально переиспользовать код, изменяя входные параметры.
Эффективная работа в Scrum невозможна без тесной работы с разработчиком, потому что времени для самостоятельного изучения кода мало. Быстрее и качественнее получится результат, если получать информацию из первых уст. Как реализован тот или иной функционал, что при этом использовалось. Это важно для понимания внутренней структуры.
Автоматизатор, а в Scrum особенно, должен быть технически подкован, чтобы понимать как работает приложение так сказать “под капотом”. Важно уметь быстро и легко переходить с одной технологии на другую. Например, при изменении базы данных, нужно быть готовым изменить способ подключения к ней. Стек технологий должен быть как можно шире.
Scrum предполагает быструю реакцию на изменения, срочное внесение исправлений. Предположим, что пользователи обнаружили некое несоответствие в работе приложения, команда разработки должна как можно быстрее отреагировать и выпустить патч. Для этого важно уметь очень точно локализовать проблему. В этом очень хорошо помогает автотестирование. Допустим у нас есть трехуровневое web-приложение: есть DB, frontend, backend. Где то в приложении есть баг. При использовании ручного тестирования поиск проблемы может занять не один день, затем проблему нужно будет исправить и вновь протестировать. При автотестировании мы запускаем регрессоное тестирование и в течение пары часов получаем полный отчет, в котором отражено точное местоположение бага.
Автор: SimbirSoft
Источник [1]
Сайт-источник PVSM.RU: https://www.pvsm.ru
Путь до страницы источника: https://www.pvsm.ru/testirovanie-veb-prilozhenij/224076
Ссылки в тексте:
[1] Источник: https://habrahabr.ru/post/317916/?utm_source=habrahabr&utm_medium=rss&utm_campaign=best
Нажмите здесь для печати.