Scrum отстаивает целостный командный подход , в том смысле, что каждый член команды должен принимать участие в каждом проекте. Команда Scrum самоорганизуется с учетом результатов проекта. Принятие решений остается за командой, в результате чего соответствующие действия предпринимаются в нужное время без каких-либо задержек. Этот подход также способствует правильному использованию командного таланта, а не ограничивается одним видом деятельности. Тестировщики также участвуют во всех мероприятиях по проектированию и разработке, делясь своим опытом в тестировании.
Вся команда работает вместе над стратегией тестирования, планированием теста, спецификацией теста, выполнением теста, оценкой теста и отчетом о результатах теста.
Совместное создание пользовательских историй
Тестеры участвуют в создании пользовательских историй. Тестеры вносят свои идеи о возможном поведении системы. Это помогает клиенту и / или конечному пользователю понять систему в реальной среде и, таким образом, получить четкое представление о том, чего они на самом деле хотят в качестве результата. Это приводит к более быстрому замораживанию требований, а также снижает вероятность изменения требований в дальнейшем.
Тестеры также предлагают критерии приемки для каждого согласованного заказчиком сценария.
Тестировщики способствуют созданию тестируемых пользовательских историй.
Планирование релиза
Планирование релиза выполняется для всего проекта. Тем не менее, среда Scrum включает в себя итеративное принятие решений, поскольку в ходе выполнения спринтов будет получено больше информации. Следовательно, сеанс Планирования релиза в начале проекта не должен производить детальный план релиза для всего проекта. Он может постоянно обновляться по мере поступления соответствующей информации.
Каждый конец спринта не должен иметь релиза. Выпуск может быть после группы спринтов. Основным критерием выпуска является предоставление бизнес-ценности для клиента. Команда выбирает длину спринта с планированием релиза в качестве входных данных.
Планирование релиза является основой тестового подхода и плана тестирования для релиза. Тестеры оценивают усилия по тестированию и планируют тестирование для релиза. Когда планы выпуска меняются, тестировщики должны обрабатывать изменения, получать адекватную основу для тестирования, учитывая более широкий контекст выпуска. Тестеры также обеспечивают усилия по тестированию, которые требуются в конце всех спринтов.
Спринт Планирование
Планирование спринта выполняется в начале каждого спринта. Журнал ожидания спринта создается из пользовательских историй, выбранных из журнала продукта для реализации в данном конкретном спринте.
Тестеры должны —
- Определить тестируемость пользовательских историй, выбранных для спринта
- Создать приемочные тесты
- Определить тестовые уровни
- Определить автоматизацию тестирования
Тестеры обновляют план тестирования с оценками усилий и продолжительности тестирования в спринте. Это обеспечивает выделение времени для необходимого тестирования во время спринтов во времени, а также подотчетность усилий по тестированию.
Тестовый анализ
Когда начинается спринт, когда разработчики продолжают анализ историй для проектирования и реализации, тестировщики выполняют анализ тестов для историй в журнале спринтов. Тестер создает необходимые тестовые случаи — как ручные, так и автоматические тесты.
тестирование
Все члены команды Scrum должны участвовать в тестировании.
-
Разработчики выполняют модульные тесты при разработке кода для пользовательских историй. Модульные тесты создаются в каждом спринте до написания кода. Модульные тестовые случаи получены из проектных спецификаций низкого уровня.
-
Тестеры выполняют функциональные и нефункциональные функции пользовательских историй.
-
Специалисты по тестированию наставляют других членов команды Scrum с их опытом в тестировании, так что вся команда будет нести коллективную ответственность за качество продукта.
-
В конце спринта клиент и / или конечные пользователи проводят приемочное тестирование пользователя и предоставляют обратную связь команде разработчиков. Это формирует как вход к следующему спринту.
-
Результаты испытаний собраны и поддерживаются.
Разработчики выполняют модульные тесты при разработке кода для пользовательских историй. Модульные тесты создаются в каждом спринте до написания кода. Модульные тестовые случаи получены из проектных спецификаций низкого уровня.
Тестеры выполняют функциональные и нефункциональные функции пользовательских историй.
Специалисты по тестированию наставляют других членов команды Scrum с их опытом в тестировании, так что вся команда будет нести коллективную ответственность за качество продукта.
В конце спринта клиент и / или конечные пользователи проводят приемочное тестирование пользователя и предоставляют обратную связь команде разработчиков. Это формирует как вход к следующему спринту.
Результаты испытаний собраны и поддерживаются.
Автоматизация тестирования
Автоматизация тестирования имеет большое значение в командах Scrum. Тестировщики посвящают время созданию, выполнению, мониторингу и сопровождению автоматизированных тестов и результатов. Поскольку изменения могут происходить в любое время в scrum-проектах, тестировщики должны приспособиться к тестированию измененных функций, а также к регрессионному тестированию. Автоматизированное тестирование облегчает управление процессом тестирования, связанным с изменениями. Автоматизированные тесты на всех уровнях способствуют достижению непрерывной интеграции. Автоматизированные тесты выполняются намного быстрее, чем ручные, без каких-либо дополнительных усилий.
Ручное тестирование больше фокусируется на предварительном тестировании, уязвимости продукта, прогнозировании дефектов.
Автоматизация тестовой деятельности
Автоматизация процессов тестирования снижает нагрузку на повторную работу и приводит к экономии средств. автоматизировать
- Генерация тестовых данных
- Загрузка тестовых данных
- Построить развертывание в тестовой среде
- Управление тестовой средой
- Сравнение вывода данных
Регрессионное тестирование
В спринте тестеры тестируют код, новый / измененный в этом спринте. Тем не менее, тестеры также должны убедиться, что код, разработанный и протестированный в более ранних спринтах, также работает вместе с новым кодом. Следовательно, регрессионному тестированию уделяется большое внимание. Автоматические регрессионные тесты выполняются в непрерывной интеграции.
Управление конфигурацией
В проектах Scrum используется система управления конфигурацией, в которой используются автоматизированные структуры сборки и тестирования. Это позволяет многократно выполнять статический анализ и модульные тесты, когда новый код проверяется в Системе управления конфигурацией. Он также управляет непрерывной интеграцией нового кода с системой. Автоматические регрессионные тесты выполняются во время непрерывной интеграции.
Ручные тестовые случаи, автоматические тесты, тестовые данные, планы тестирования, стратегия тестирования и другие артефакты тестирования должны контролироваться версией и требовать соответствующих разрешений на доступ. Это может быть достигнуто путем поддержки артефактов тестирования в системе управления конфигурацией.
Методы гибкого тестирования
Тестеры в Scrum Team могут следовать следующим Agile практикам —
-
Соединение — два члена команды сидят вместе и работают вместе. Два человека могут быть двумя тестерами или одним тестером и одним разработчиком.
-
Инкрементальный дизайн теста — тестовые случаи разрабатываются по мере постепенного развития спринта и добавления пользовательских историй.
Соединение — два члена команды сидят вместе и работают вместе. Два человека могут быть двумя тестерами или одним тестером и одним разработчиком.
Инкрементальный дизайн теста — тестовые случаи разрабатываются по мере постепенного развития спринта и добавления пользовательских историй.
Agile Metrics
Во время разработки программного обеспечения сбор и анализ метрик помогают улучшить процесс и, таким образом, повысить производительность, качество результатов и удовлетворенность клиентов. В разработке на основе Scrum это возможно, и тестировщики должны обращать внимание на те метрики, которые им необходимы.
Для разработки Scrum предлагается несколько метрик. Значимые показатели —
-
Соотношение успешных спринтов — (количество успешных спринтов / общее количество спринтов) * 100 . Успешный спринт — это тот, в котором команда может выполнить свои обязательства.
-
Скорость — Скорость команды основана на количестве очков истории, полученных командой во время спринта. Очки истории — это мера Пользовательских историй, подсчитанных во время оценки.
-
Фактор фокуса — (скорость / работоспособность команды) / 100 . Фактор фокуса — это процент усилий команды, который приводит к законченным историям.
-
Точность оценки — (Расчетное усилие / Фактическое усилие) / 100 . Точность оценки — это способность команды точно оценивать усилия.
-
Спринт Burndown — работа (в пунктах истории или в часах), которая остается против. Работа, которая должна оставаться в идеале (согласно оценке).
-
Если это больше, то это означает, что команда взяла на себя больше работы, чем они могут сделать.
-
Если оно меньше, значит, команда не оценила точно.
-
-
Количество дефектов — количество дефектов в спринте. Количество дефектов — это количество дефектов в программном обеспечении по сравнению с отставанием.
-
Серьезность Дефектов — Дефекты могут быть классифицированы как незначительные, основные и критические по степени их серьезности. Тестеры могут определять категоризацию.
Соотношение успешных спринтов — (количество успешных спринтов / общее количество спринтов) * 100 . Успешный спринт — это тот, в котором команда может выполнить свои обязательства.
Скорость — Скорость команды основана на количестве очков истории, полученных командой во время спринта. Очки истории — это мера Пользовательских историй, подсчитанных во время оценки.
Фактор фокуса — (скорость / работоспособность команды) / 100 . Фактор фокуса — это процент усилий команды, который приводит к законченным историям.
Точность оценки — (Расчетное усилие / Фактическое усилие) / 100 . Точность оценки — это способность команды точно оценивать усилия.
Спринт Burndown — работа (в пунктах истории или в часах), которая остается против. Работа, которая должна оставаться в идеале (согласно оценке).
Если это больше, то это означает, что команда взяла на себя больше работы, чем они могут сделать.
Если оно меньше, значит, команда не оценила точно.
Количество дефектов — количество дефектов в спринте. Количество дефектов — это количество дефектов в программном обеспечении по сравнению с отставанием.
Серьезность Дефектов — Дефекты могут быть классифицированы как незначительные, основные и критические по степени их серьезности. Тестеры могут определять категоризацию.
Спринт Ретроспективы
В Ретроспективе Спринта будут участвовать все члены команды. Они делятся —