Помогите мне понять, как QA работает в Scrum [закрыто]

по-видимому, мы используем методологию разработки Scrum. Вот как это обычно происходит:

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

как scrum должен работать, когда освобождаемые задачи Dev занимают большую часть спринта?

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

(кстати - это лучшее место поставить это или я должен был поставить его в "ответ"?)

указывает задуматься / действовать на:

  • необходимо убедиться, что задачи разработчика как можно меньше (гранулированные).
  • длина спринта должна быть соответствующим образом основана на средней длине задачи (например, спринт с заданиями на 1 неделю должен быть не менее 4 недель)
  • команда (включая QA) должна работать над тем, чтобы стать более точной при оценке.
  • рассмотрите возможность выполнения отдельного QA sprint в параллельно, но если это работает лучше для команды
  • модульное тестирование!

13 ответов


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

Я не говорю, что это легкая проблема для решения, потому что это более распространено, чем что-либо. Но вещи, которые могли бы помочь:

  • рассмотрите QA как членов команды разработчиков и включите их в планирование спринта и оценку больше тесно.

  • 'Releasable Dev tasks' не должен занимать большую часть спринта. Полные рабочие функции должны. Попытайтесь собрать метрики о времени разработки против времени QA для каждого вида задачи и использовать эти метрики при оценке будущих спринтов.

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

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

но в конце концов, неточность оценки-это сложная проблема управления проектами, которую вы найдете в проектах на основе agile или waterfall. Удача.


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

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

Я тест-первый парень. В процессе разработки я сначала строю тесты, чтобы обеспечить соблюдение требований и проектных решений. Как код команда принуждает их? Дело в том, что я пытаюсь сделать здесь, что вы просто не можете "кидать через забор" и ожидайте чего угодно, кроме неудачи. Этот сбой будет либо командой тестирования (не очень хорошо тестируя и, таким образом, позволяя проблемам проскользнуть), либо разработчиками (не создавая продукт, который решает проблему). Я не говорю, что ты должны сначала напишите тесты - я не воинствующий или тест-первый евангелист - но я говорят, что вы должны имейте процесс на месте, чтобы произвести качественный, проверенный, готовый к производству код, когда вы достигнете конца итерации.

Я на месте в этой методологии разработки, которую я называю Тодес Способ. Я годами создавал программное обеспечение для правительства (США) в такой модели. Это не работает хорошо, это стоит больших денег, это производит поздний код, плохой код, и ничего не делает для морального духа. Ты не можешь ничего сделать. топчется на месте, когда вы тратите все свое время на исправление ошибок вы могли бы избежать в первую очередь. Я был совершенно подавлен этой интрижкой.

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

вернуться к планированию...

на моей текущей работе мы делаем Scrum, мы просто не называем это так. Мы не в ярлыки здесь но мы в производить код качества на времени. Все на борту. Мы говорим QA, что мы будем готовы проверить и когда. Если они постучатся на две недели раньше, то смогут поговорить с рукой. Все знают график, все знают, что будет в выпуске, и все знают, что продукт должен работать так, как рекламируется, прежде чем он перейдет в QA. Так что это значит? Вы говорите QA "не беспокойтесь о тестировании XYZ - он сломан и не будет исправлено до выпуска C", и если они пойдут проверять это, вы указываете им на это утверждение и говорите им не тратить свое время. Сурово, возможно, но иногда необходимо. Я не хочу быть грубым, но каждый должен знать "правила" и то, что должно быть проверено и что является "известной проблемой".

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

возможно, вы откусываете больше, чем можно выполнить во время спринта. Возможно, так оно и есть. Зачем ты это делаешь? Работать по графику? Если это так, то именно здесь руководство должно вмешаться и решить проблему. Если ты ... давая QA багги код, ожидайте, что они бросят его обратно. Лучше дать им 3 вещи, которые работают, чем 8 вещей, которые не закончены. Цель состоит в том, чтобы создать некоторый набор функций, которые полностью реализованы на каждой итерации, а не бросать кучу наполовину сделанных вещей.

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

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

удачи!


Мне кажется, что существует проблема распределения ресурсов в сценариях, требующих функционального тестирования QA, чтобы данная функция была "сделана" в спринте. Кажется, никто не обращается к этому в любом обсуждении scrum, связанном с QA, которое я нашел до сих пор, и исходный вопрос здесь почти такой же (по крайней мере, связанный), поэтому я хотел предложить частичный ответ и немного расширить вопрос.

Что касается конкретного исходного вопроса о задачах разработки, выполняющих полный спринт - кажется, что общий совет смягчения этих задач имеет смысл, если функциональное тестирование QA является частью вашего определения "сделано". Учитывая, что, скажем, 4-недельный спринт, если для тестирования нескольких функций от нескольких разработчиков требуется около недели, то кажется, что задачи разработки занимают около 3 недель, а затем неделю задержки тестовых задач, занимающих около 1 недели, - это ответ. QA, конечно, начнется как можно скорее, мы признаем, что из последнего набора поставленных функций там будет отставание около недели. Я понимаю, что мы хотим получить функции QA как можно скорее, чтобы у вас не было этого водопадоподобного сценария в спринте, но реальность такова, что разработка обычно не может получить реальную, стоящую функциональность для QA до 1 до 3 недель в спринте. Конечно, есть кусочки и кусочки здесь и там, но основная часть работы-это 2-3 недели разработки, а затем около недели тестирования.

Так вот проблема распределения ресурсов, и мое расширение вопрос-В приведенном выше сценарии QA имеет время для тестирования запланированных функций спринта (3 недели стоит задач разработки, оставляя последнюю неделю для тестирования функций, поставленных в прошлом). Также предположим, что QA начинает получать некоторые тестируемые функции после 1 недели разработки , но как насчет недели №1 для QA и недели №4 для разработки?

Если функциональное тестирование QA является частью определения "сделано" для функции в спринте, то кажется, что эта неэффективность неизбежна. QA будет в основном простаивать в течение недели #1, а разработка будет в основном простаивать в течение недели #4. Конечно, есть некоторые вещи, которые заполняют это время естественно, как исправление ошибок и проверка, дизайн/план и т. д., но мы по существу scheudling наши ресурсы на 75% емкости.

очевидный ответ, похоже, перекрывает спринты для развития и QA, поскольку реальность такова, что QA всегда отстает от развития в некоторой степени. Последуют демонстрации владельцам продуктов и другим QA sprint, так как мы хотим, чтобы функции были протестированы перед показом. Это, по-видимому, позволяет более эффективно использовать как develoment, так и QA, поскольку у нас нет столько потерянного времени. Предполагая, что мы хотим продолжать разработку и тестирование разработчиков, я не вижу лучшего практического решения. Возможно, я что - то упустил, И я надеюсь, что кто-то может пролить свет на это для меня-иначе кажется, что этот жесткий подход к scrum несовершенен. Спасибо.


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

Если Дев не устанавливает свои собственные цели, вот почему они всегда опаздывают. И это не идеальный способ практиковать Scrum. Это просто инкрементное развитие с большими, обусловленными сроками результатами и без фактической ответственности акционеров со стороны разработчиков.

Если dev они не могут сами ставить перед собой цели, потому что не знают достаточно, тогда они должны быть более вовлечены заранее.

Scrum зависит от четырех основных принципов, изложенных в Agile Манифест.

  1. взаимодействие имеет значение - это означает, что dev, QA, управление проектами и конечные пользователи должны больше говорить и разговаривать друг с другом. Программное обеспечение-это процесс кодирования знаний на тайном языке компьютеров. Чтобы кодировать знания, разработчики должны иметь знание. - "Как ты думаешь, почему мы называем это "кодом"?] Scrum не является методологией" write spec - throw over transom". Это анти - "написать spec-бросок через транец"

  2. рабочее программное обеспечение имеет значение-это означает, что каждый кусок dev откусывает должен привести к работающего релиз. Не набор исправлений ошибок для QA, чтобы бороться с, но рабочее программное обеспечение.

  3. сотрудничество с клиентами -- это означает, что dev должен работать с бизнес-аналитиками, конечные пользователи, владельцы бизнеса, все, кто может помочь им понять, что они строят. Сроки не так важны, как следующая вещь, переданная клиенту. Если клиент нуждается в X, это самая приоритетная вещь для всех. Если в плане проекта говорится построить Y, это нагрузка на malarkey.

  4. реагирование на изменения-это означает, что клиенты могут изменить приоритеты следующих спринтов. Они не могут перестроить спринт в процессе (это безумие) но все следующие спринты являются кандидатами на изменение приоритетов.

Если клиент управляет, то крайние сроки становятся менее искусственными " вехами проекта "и больше" нам нужно сначала X, затем Y, и эта вещь в разделе Z, нам это больше не нужно. Теперь, когда у нас есть W, Z является избыточным."


правила Scrum говорят, что все элементы Sprint должны быть "полностью протестированы, потенциально реализуемые функции" в конце спринта, чтобы считаться завершенными. Спринты всегда заканчиваются вовремя, и команда не получает кредит и не может представить что - либо в обзоре спринта, которое не завершено-и это включает QA.

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

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


говоря как QA, который работал над гибкими проектами в течение 2,5 лет, это действительно сложная проблема, и у меня до сих пор нет всех ответов.

Я работаю в составе "триплета" (два разработчика, которые объединяют программу + Один QA), и я участвую в задании историй и оценке в планировании встреч в начале двухнедельных итераций. Как упоминал Адриан выше, для QAs важно, чтобы их голос был услышан в первоначальном планировании спринта. Это может быть трудно, особенно если вы работаете с разработчиками с очень сильными личностями, однако QAs должен быть напористым в истинном смысле этого слова (т. е. не агрессивным или сильным, но уважительно стремящимся понять правду/PO и разработчиков/технических экспертов, делая себя понятыми). Я выступаю за создание задач QA сначала во время планирования, чтобы стимулировать менталитет, основанный на тестировании - QA, возможно, придется буквально выдвинуть себя, чтобы это было принято. Это противоположно тому, как много людей думают о программном обеспечении разработка работает, но приносит дивиденды по нескольким причинам;

  1. QA услышан и не низведен до вопроса "Итак, как вы собираетесь это проверить?"после того, как разработчики сказали свою часть (менталитет водопада).

  2. Это позволяет QA предлагать идеи для тестирования, которые в то же время проверяют тестируемость критериев принятия, пока присутствует истина/PO (я сказал, что важно, чтобы они присутствовали на совещании по планированию, не так ли?!) к заполнить любые пробелы в понимании.

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

  4. Если шаги 1-3 являются вашей единственной активностью TDD для остальной части итерации, вы все еще делаете в миллион раз лучше, чем сценарий, постулированный Стивом в первом посте; " разработчики мечутся, пытаясь выполнить их задача. Как правило, для выполнения задач требуется большая часть спринта. QA pesters Dev чтобы выпустить что-то, что они могут проверить, Dev, наконец, выбрасывает какой-то багги-код в QA за день или два до окончания спринта и проводит оставшееся время, исправляя ошибки, которые QA находит"

Излишне говорить, что это идет с некоторыми оговорками для QA;

  1. Они должны быть готовы к тому, что их идеи для тестирования будут оспорены разработчиками и Truth/PO и достигнут компромисс; отношение "QA police" не будет мыться в гибкой команде.

  2. задачи QA должны иметь сложный баланс, чтобы не быть ни слишком подробными, ни слишком общими (задачи могут быть написаны на карточке, чтобы перейти на "плату радиатора" и обсуждаться на ежедневных встречах - они должны быть перемещены из "в процессе" в "завершено" во время итерации).

  3. QAs необходимо подготовиться к совещаниям по планированию / оценке. Не ожидайте, что сможете просто появиться и произведите тестовый подход с верхней части головы для невидимых пользовательских историй! Разработчики, похоже, могут это сделать, потому что их задачи часто гораздо более четкие - например, "изменить модуль x для взаимодействия с компонентом z" или "метод рефакторинга y". В качестве QA вы должны быть знакомы с функциональностью, вводимой/изменяемой перед планированием, чтобы вы знали область тестирования и какие методы проектирования тестов вы могли бы применить.

  4. почти необходимо автоматизировать тесты и пусть они будут написаны и "провалятся" в течение первых двух-трех дней итерации или, по крайней мере, соучаствуют, когда разработчики будут готовы к коду. Затем вы можете запустить тест/Ы и посмотреть, проходят ли они так, как ожидалось (правильный QA TDD). Вот как вы избегаете мини-водопада в конце итераций. Вы действительно должны продемонстрировать тест разработчикам до или по мере их начала кодирования, чтобы они знали, к чему стремиться.

  5. Я говорю, что 4 "почти необходимо", потому что то же самое иногда может быть успешно достигнуто с ручными контрольными списками (смею сказать, скриптами!) ожидаемого поведения-ключ должен поделиться этим с разработчиками раньше времени; продолжайте говорить с ними!

Что касается пункта 2 выше по вопросу о задачах, я попытался создать задачи как гранулированные, как 1/2 часа до 2 часов в размере каждого, соответствующего наглядной части работы, например, "добавить проверки на неправильный пароль для автоматического тестирования - 2 часа". Пока это помогает мне организовать мою работу, это было критикуется другими членами команды за то, что они слишком детализированы и оказывают влияние на меня, когда я либо перемещаю несколько задач, чтобы завершить со дня накануне, либо не могу переместить какие-либо задачи вообще, потому что я еще не попал на них. Люди действительно хотят видеть чувство устойчивого прогресса в ежедневных стендах, поэтому более полезно создавать задачи в 1/2-дневных или 1-дневных блоках (но вы можете сохранить свой собственный список "микро-задач" для выполнения больших задач, которые вы используете для Сообщение об общем прогрессе на стенде).

Что касается пунктов 4 и 5 выше; автоматические тесты или ручные контрольные списки, которые вы готовите рано, должны действительно охватывать только счастливые пути или ключевые критерии принятия. Как только они пройдут, Вы можете запланировать дополнительную задачу для заключительного раунда "исследовательского тестирования" к концу итерации, чтобы проверить крайние случаи. То, что разработчики делают в течение этого времени, проблематично, потому что, насколько они обеспокоены, они являются "кодом завершите", если и пока не найдете ошибку. Некоторые гибкие практики выступают за то, чтобы сначала перейти к крайним случаям, хотя это также может быть проблематично, потому что, если у вас закончится время, вы, возможно, не гарантировали, что критерии принятия были доставлены. Это одно из тех точно сбалансированных решений, которое зависит от контекста истории пользователя и вашего опыта в качестве QA!

Как я сказал в начале, у меня все еще нет всех ответов, но надеюсь, что выше приведены некоторые указатели из тяжелого опыта!


похоже, что ваша команда разработчиков не может проводить достаточное тестирование самостоятельно, до выпуска QA. Если все ваши модульные тесты проходят, цикл QA должен быть относительно плавным, нет? Они найдут некоторые ошибки интеграции, но их не должно быть очень много, верно?


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

Если разработчики выпускают багги-код к концу спринта, я бы также посмотрел at:

  • владельцы продуктов действительно держат членов dev ответственными за выполнение своих задач. Это работа PO, и если этого не произойдет, то разработчики ослабнут.
  • разработчики используют любой тип TDD. Если нет, это может очень помочь. Пусть разработчики привыкнут тестировать свой код. У нас есть эта проблема, где я работаю, и моя команда сосредоточена на выполнении TDD в важных областях, чтобы нам не пришлось кто-то другой сделает это позже
  • являются ли задачи / пользовательские истории слишком общими? Wiggle room в задаче поломок заставит разработчиков быть небрежными. Опять же, это проблема по.

одна идея, которую я слышал в прошлом, - использовать QA-человека в качестве scrummaster. Они будут присутствовать на ежедневных стендапах и могут получить представление о том, где находятся разработчики. Они могут решать проблемы с PO (предполагая, что PO может адекватно делать своя работа.)

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

Я тоже чувствую, что у вас есть проблема с владельцем продукта. Они должны быть там, чтобы убедиться, что все едут в правильном направлении. они должны быть уверены, что есть хорошие сотрудничество не только между QA и разработчиками, но и между самими разработчиками.


" как scrum должен работать при выпуске Dev задачи занимают большую часть спринта?"

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

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

если они являются отдельной группой, то это, вероятно, большая часть проблема. Они не будут участвовать в обязательстве команды по завершению задач - и связанных переговорах с владельцем продукта. Я никогда не видел, чтобы гибкая группа преуспевала без их навыков QA в команде. Либо имея разработчиков с большим количеством навыков тестирования / QA - или имея встроенного человека QA или три в команде.

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

Я бы попробовал несколько вещей, если бы это был я:

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

вы также можете найти эти советы о сглаживании scrum burndown полезное.


мы решили эту проблему следующим образом: - Каждый элемент в отставании продукта должен иметь критерии соответствия или критерии принятия, без них мы не начнем спринт - Тестер является частью нашей команды, для каждого элемента отставания продукта он создает тестовые задачи (1 или более, на основе критериев принятия) вместе с оценкой и ссылкой на элемент для тестирования - Во время ежедневного scrum, все задачи, которые закончены помещаются в столбце " для тестирования - Мы никогда не делаем задачи, которые занимают больше 16 часов; задачи, которые оцениваются дольше, разбиваются


разбить задачи на более мелкие задачи.

кроме того, QA может создавать тестовые случаи для Dev для тестирования.


одна идея, которую нужно рассмотреть, - это работа QA на одну итерацию позади основной разработки. Это хорошо работает в нашей среде.


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

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

Так что делает ли тестер два в первую неделю спринта?

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

надеюсь, что это поможет!