Гибкое тестирование - Scrum

Сторонники Scrum Whole Team Approachв том смысле, что каждый член команды должен принимать участие в каждой проектной деятельности. Scrum-команда самоорганизуется и подотчетна результатам проекта. Принятие решений остается за командой, в результате чего соответствующие действия предпринимаются в нужное время без каких-либо задержек. Этот подход также поощряет правильное использование командного таланта вместо того, чтобы ограничиваться одним видом деятельности. Тестировщики также участвуют во всех проектах и ​​разработках, внося свой вклад в тестирование.

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

Совместное создание пользовательской истории

Тестировщики участвуют в создании пользовательской истории. Тестировщики делятся своими идеями о возможном поведении системы. Это помогает заказчику и / или конечному пользователю понять систему в реальной среде и, таким образом, получить ясность в отношении того, что на самом деле они хотят в качестве результата. Это приводит к более быстрому замораживанию требований, а также снижает вероятность изменения требований в дальнейшем.

Тестировщики также разрабатывают критерии приемки для каждого сценария, согласованного с заказчиком.

Тестировщики вносят свой вклад в создание тестируемых пользовательских историй.

Планирование выпуска

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

У каждого спринт-энда не обязательно должен быть релиз. Релиз может быть после группы спринтов. Основным критерием выпуска является предоставление клиенту ценности для бизнеса. Команда принимает решение о продолжительности спринта с учетом планирования выпуска.

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

Планирование спринта

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

Тестеры должны -

• Определите тестируемость пользовательских историй, выбранных для спринта.
• Создать приемочные испытания
• Определите уровни тестирования
• Определить автоматизацию тестирования

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

Тестовый анализ

Когда начинается спринт, когда разработчики проводят анализ историй для проектирования и реализации, тестировщики выполняют анализ тестов для историй в бэклоге спринта. Тестировщик создает необходимые тестовые случаи - как ручные, так и автоматические тесты.

Тестирование

В тестировании должны участвовать все члены команды Scrum.

• Разработчики выполняют модульные тесты по мере разработки кода для пользовательских историй. Модульные тесты создаются в каждом спринте до написания кода. Примеры модульных тестов получены из проектных спецификаций низкого уровня.

• Тестировщики выполняют функциональные и нефункциональные функции пользовательских историй.

• Тестировщики наставляют других членов команды схватки, используя свой опыт в тестировании, так что вся команда будет нести коллективную ответственность за качество продукта.

• В конце спринта заказчик и / или конечные пользователи проводят приемочное тестирование пользователей и предоставляют обратную связь команде scrum. Это формирует входные данные для следующего спринта.

• Результаты тестов собираются и сохраняются.

Автоматизация тестирования

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

Ручное тестирование больше ориентировано на исследовательское тестирование, уязвимость продукта, прогнозирование дефектов.

Автоматизация тестовой деятельности

Автоматизация действий по тестированию снижает нагрузку на повторяющуюся работу и приводит к экономии затрат. Автоматизировать

• Генерация тестовых данных
• Загрузка тестовых данных
• Встраивайте развертывание в тестовую среду
• Управление тестовой средой
• Сравнение вывода данных

Регрессионное тестирование

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

Управление конфигурацией

В проектах Scrum используется система управления конфигурацией, в которой используются автоматизированные среды сборки и тестирования. Это позволяет многократно запускать статический анализ и модульные тесты по мере того, как новый код проверяется в системе управления конфигурацией. Он также управляет непрерывной интеграцией нового кода в систему. Автоматические регрессионные тесты запускаются во время непрерывной интеграции.

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

Практики гибкого тестирования

Тестировщики в Scrum-команде могут следовать следующим методам Agile:

• Pairing- Два члена команды сидят вместе и работают вместе. Эти два человека могут быть двумя тестировщиками или одним тестером и одним разработчиком.

• Incremental Test Design - Тестовые наборы разрабатываются по мере постепенного продвижения спринтов и добавления пользовательских историй.

Метрики Agile

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

Для разработки Scrum предлагается несколько метрик. Важные метрики -

• Ratio of Successful Sprints - (Number of successful Sprints / Total number of Sprints) * 100. Успешный спринт - это тот, в котором Команда может выполнить свои обязательства.

• Velocity- Скорость команды зависит от количества очков истории, заработанных командой во время спринта. Story Points - это количество пользовательских историй, подсчитываемых во время оценки.

• Focus Factor - (Velocity / Team’s Work Capacity) / 100. Фактор фокусировки - это процент усилий команды, которые приводят к созданию законченных историй.

• Estimation Accuracy - (Estimated effort / Actual effort) / 100. Точность оценки - это способность команды точно оценить усилия.

• Sprint Burndown- Работа (в сюжетных точках или в часах), оставшаяся против. Работа, которая должна оставаться в идеале (согласно оценке).

  • Если больше, то это означает, что Команда взяла на себя больше Работы, чем она может сделать.

  • Если меньше, это означает, что Группа не сделала точной оценки.

• Defect Count- Количество дефектов в Спринте. Количество дефектов - это количество дефектов в программном обеспечении по сравнению с невыполненным.

• Severity of Defects- Дефекты можно разделить на незначительные, серьезные и критические по степени серьезности. Тестировщики могут определять категоризацию.

Ретроспективы спринта

В ретроспективе спринта примут участие все члены команды. Они делятся -

• То, что прошло хорошо
• Metrics
• Возможности для улучшений
• Действия, которые необходимо применить