Как соответствовать тестированию в Scrum-спринтах и ​​как писать пользовательские истории в Scrum

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

1. В спринте, скажем, 5 историй, когда вы выпускаете для тестирования? Является ли это, как только история завершена разработчиком, или после того, как все истории завершены, но до окончания спринта, дающего тесту необходимое время для тестирования.
2. Если БА пишет пользовательские истории, что должно быть подробно. Традиционно для написания спецификации со всеми макетами, поведением, текстом и т. Д. Требуется много времени. Я предполагаю, что мой вопрос заключается в том, как писать истории, которые можно реализовать и проверить.
3. Наша тестовая команда не техническая. Насколько важно иметь автоматическое тестирование пользовательского интерфейса для Scrum. Пользовательский интерфейс основан на WPF.

У меня есть солидный опыт разработки с использованием гибких методов (TDD, проверки кода, рефакторинг и т. Д.), Но новичок в scrum.

редактировать: под итерациями я подразумеваю, что если есть 100 требований, мы можем перейти к тестированию после завершения 30, 35, 35 требований, а не ждать, пока все 100 требований будут выполнены.

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

Ваши разработчики должны написать свои собственные тесты, отдельно от этой другой команды. Вы должны относиться к этой другой «тестовой» команде как к своим клиентам.

В спринте ... когда вы выпускаете для тестирования?

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

Я предполагаю, что мой вопрос заключается в том, как писать истории, которые можно реализовать и проверить.

Это зависит от команды к команде. БА является частью команды разработчиков. Вы должны работать над этим как команда (BA плюс разработчики), чтобы получить правильное количество деталей. Это командная попытка получить правильную информацию от BA для остальной части команды.

Насколько важно иметь автоматическое тестирование пользовательского интерфейса для Scrum.

Essential. Полностью необходим для любой разработки пользовательского интерфейса. Разработчики должны сделать все тестирование самостоятельно, прежде чем оно будет передано «команде тестирования». Если есть пользовательский интерфейс, они должны его проверить. Если пользовательского интерфейса нет, автоматическое тестирование пользовательского интерфейса не требуется. Требуется тестирование, и пользовательский интерфейс должен быть протестирован. Автоматизированное тестирование является наилучшей практикой.

Нижняя линия. Отдельная «тестовая» команда и бакалавр, который пишет каждую мелочь, не являются оптимальной организацией для Scrum. Scrum означает, что вы должны переосмыслить свою организацию, а также свои процессы.

Большинство ответов, которые я собираюсь дать, относятся к гибкому методу разработки программного обеспечения по сравнению с методом итеративного водопада. Scrum просто является популярной Agile-реализацией.

1. В типичном Scrum нет отдельной фазы тестирования, потому что формальное тестирование должно проводиться на протяжении всего спринта. Когда разработчик заканчивает User Story, ресурс QA уже должен подготовить свои тестовые примеры и начать тестирование в этот момент. Если их тесты пройдены успешно, они принимают пользовательскую историю и переходят к следующей. Как только все пользовательские истории будут завершены и приняты, спринт закончен, и вы начинаете следующий. Все это, конечно, зависит от непрерывной интеграции, поэтому изменения в разработке сразу же становятся доступны для QA. Дальнейшее развитие должно следовать руководствам TDD, чтобы регрессивное тестирование было максимально быстрым и безболезненным.

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

3. Автоматическое тестирование пользовательского интерфейса может быть хорошей вещью, но я лично чувствую, что больше усилий по методам TDD и 100% охвату модульных тестов всей бизнес-логики важнее. Большинство групп разработчиков программного обеспечения не могут достичь 100% покрытия Business Logic, поэтому, на мой взгляд, автоматическое тестирование пользовательского интерфейса было бы пустой тратой драгоценного времени, которое можно было бы использовать для написания большего количества модульных тестов для BL. На мой взгляд, это не роскошь, а необходимость.

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

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

2. Это одна из самых больших трудностей в Scrum IMO. Вы должны найти правильное количество спецификаций, необходимых для получения реализуемой, тестируемой пользовательской истории. Слишком большой предварительный анализ, документация и спецификация приведут к жесткому плану, который неизбежно окажется неверным в течение спринта. И наоборот, пользовательская история, которая не была четко определена и выражена Владельцем продукта, приведет к насыщенной пропускной способности связи между разработчиками и ПО во время Спринта и задержит разработку, в то время как ПО принимает решения о пользовательских историях на полпути через спринт. ,

   В нашем случае мы определили правильное количество деталей для пользовательской истории: 1 / описание в форме «как ... я хочу ... так ...» и 2 / серия принятия критерии. Мы редко делаем макеты пользовательского интерфейса заранее, это может произойти во время планирования спринта, но это больше эскизов, которые впоследствии отбрасываются.

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

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

Возьмите свой 5-этажный пример спринта. Если ваши команды привыкли писать код для всех 5 историй, а затем тестировать все 5 историй, тогда размер пакета составляет 5 историй. Разрежь это пополам. В следующем спринте сначала поработайте над тремя наиболее актуальными историями, подготовив их к тестированию как можно раньше. Поскольку тестеры тестируют эти 3 истории, остальные могут подготовить оставшиеся 2 истории к тестированию. Это вызовет некоторые растущие боли. Измените, как вы работаете, чтобы сделать это более удобным.

Например, все больше людей будут работать над каждой историей вместе, поэтому попробуйте больше спаривания и посмотрите, поможет ли это вам работать более стабильно. Или, возможно, тестеры найдут проблемы в истории 2, которые отвлекают некоторых программистов, когда они пытаются работать над историей 5, поэтому предложите программистам и тестировщикам в следующем спринте обсудить ранее, как протестировать одну из историй в «первой партии» "так что программисты с меньшей вероятностью допустят ошибку, которую тестировщик может легко поймать с помощью теста.

Может потребоваться несколько спринтов, чтобы решить большие проблемы, связанные с тестировщиками, тестирующими небольшую партию историй, в то время как программисты работают над следующей партией историй. Как только это станет удобным, снова уменьшите размер партии пополам. И опять. Через год или около того, команда будет удобно тестировать истории, так как программисты считают, что они с ними покончили и, вероятно, на этом пути будут совершать меньше ошибок. Каждая история будет сделана раньше.

Конечно, на этом этапе теперь вы можете делать то же самое с партиями, которые команда получает от владельцев продукта или которые она отправляет в операционную организацию. И так далее. На этом этапе вы можете решить, "сколько деталей должны писать БА для историй?" проблема.

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

Я надеюсь, что это поможет вам.

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

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

Для каждой большой пользовательской истории она должна быть разбита на множество подзадач, а когда подзадачи полностью выполнены разработчиком, они должны быть немедленно переданы в QC для тестирования. Дефект должен быть исправлен после завершения тестирования для этих подзадач.

Если БА пишет пользовательские истории, что должно быть подробно. Традиционно для написания спецификации со всеми макетами, поведением, текстом и т. Д. Требуется много времени. Я предполагаю, что мой вопрос заключается в том, как писать истории, которые можно реализовать и проверить.

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

Наша тестовая команда не техническая. Насколько важно иметь автоматическое тестирование пользовательского интерфейса для Scrum. Пользовательский интерфейс основан на WPF

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