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

15

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

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

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

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

softveda
источник
4
We have a waterfall/iterative SDLC.Уточните это. Водопад, по определению, является последовательным процессом, а не повторяющимся. Хотя есть модифицированные водопады (такие как модель сашими или водопад с подпроектами), все они последовательны. Вы пытаетесь перейти к итерационным процессам из вашего текущего последовательного процесса?
Томас Оуэнс
1
@Pratik, как у тебя все получилось? Удалось ли вам в итоге лучше сотрудничать с командой QA?
флоп

Ответы:

11

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

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

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

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

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

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

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

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


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

С. Лотт
источник
6
After you're development team is done, you release it to other teams for "testing" or "deployment" or whatever else happens in the organization. Чем это отличается от повторяющегося водопада? В этом случае спринт - это просто очень короткая итерация Waterfall. Этот тип поражает одну из самых сильных сторон Agile и Scrum IMO: все BA, Developers и QA работают в одной команде, и все они вместе владеют спринтом, который выпускают. Это разрушает барьеры, которые возникают в проектах.
maple_shaft
4
Можете ли вы объяснить, почему автоматизированное тестирование пользовательского интерфейса имеет важное значение? Scrum - это структура управления проектами, которая не диктует никаких технических приемов. Единственные ссылки на тестирование, которые я могу найти в отношении Scrum, это то, что Scrum Team - это многофункциональная команда. Хотя я бы предпочел автоматическое тестирование, Scrum не требует ни автоматического тестирования, ни тестирования вообще, хотя прохождение тестов должно быть частью определения «Готово». Это просто говорит о том, что любое тестирование проводится командой. Суть в том, что вы правы - текущая организационная структура не подходит для Scrum.
Томас Оуэнс
2
Вопрос, скопированный прямо из оригинального поста, подчеркивает: «Насколько важно иметь автоматическое тестирование пользовательского интерфейса для Scrum ». Для Scrum это совсем не важно.
Томас Оуэнс
2
Формулировка в вашем ответе говорит о том, что автоматическое тестирование пользовательского интерфейса является частью процесса Scrum, а это не так. Но это не значит, что команда разработчиков не должна делать ничего хорошего для улучшения качества. Я согласен, что это плохо сформулированный вопрос, но следует проводить различие между «требуется ли это для Scrum» и «должно ли завершение автоматического тестирования пользовательского интерфейса быть частью моего определения« готово для истории »». В конечном счете, ответ не меняется, но становится более понятным, почему это требуется.
Томас Оуэнс
9
Essential. Completely required.необходимо изменить, чтобы отразить, что это не является "необходимым" или "полностью необходимым" в рамках процесса Scrum. Прямо сейчас, неосведомленный читатель прочитает этот ответ и сделает вывод, что если вы не выполняете автоматическое тестирование пользовательского интерфейса, вы не выполняете Scrum. Это неверный вывод, но вполне понятный, учитывая формулировку этого ответа. Существует четкое различие между «чем-то, что вы должны делать» и «чем-то обязательным».
Томас Оуэнс
9

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

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

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

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

maple_shaft
источник
Подлинный вопрос относительно 1: если QA тестирует каждую пользовательскую историю, как только она будет сделана, затем переходит к следующей, как вы проверяете, что последняя история в рамках одного и того же спринта не сломала (возможно, тонкими способами) одну из Пользовательские истории, которые уже были проверены? Этакая «регрессия в одном и том же спринте». Я говорю о ручном контроле качества, а не о автоматических тестовых наборах, конечно.
Андрес Ф.
@AndresF. Если после процесса TDD вместе с CI, то при регистрации нарушается существующая функциональность, модульные тесты не пройдут, и люди будут уведомлены. Конечно, это эффективно только в том случае, если имеется 100% тестовое покрытие бизнес-логики, однако простые проблемы с логикой, средой или интеграцией, а также логика представления могут потенциально иметь дефекты, вносимые в разработку новых пользовательских историй, которые остаются незатронутыми. Автоматическое тестирование пользовательского интерфейса, предложенное С.Лоттом, проходит долгий путь, чтобы поймать большинство из них, но, в конечном счете, только быстрое тестирование дыма должно выявить эти проблемы. продолжение ...
maple_shaft
... продолжение. Если вы обнаружите, что это повторяющаяся проблема, то у вас могут быть более глубокие недостатки проектирования или проблемы, которые следует устранить, такие как тесная связь и низкая согласованность, которые делают ваш код особенно хрупким.
maple_shaft
@maple_shaft: Это легко сказать, но QA не нравится выпуск в середине их тестирования. Также мы часто проверяем сборку CI, но релиз выполняется только по требованию. Текущая команда тестирования не в состоянии написать автоматический тест пользовательского интерфейса. Они делают чисто ручное тестирование. Это было бы трудно для меня изменить.
софтведа
@Pratik Я понимаю, как трудно поверить мне. Я знаю боль. Возможно, вы можете расширить спринт, но иметь три или четыре релиза для тестовой среды на спринт? Таким образом, команда тестирования может уйти на целый день в середине тестового примера и быть уверенным, что среда не изменилась за одну ночь.
maple_shaft
4
  1. В Scrum вы должны производить потенциально возможный программный прирост в конце каждого спринта. В результате Scrum продвигает концепцию целой команды или кросс-функциональной команды, в которой каждый навык, необходимый для выполнения данной пользовательской истории, должен присутствовать в команде.

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

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

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

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

guillaume31
источник
2

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

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

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

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

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

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

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

JB Rainsberger
источник
0

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

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

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

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

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

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

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

Danh
источник