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

В правилах Толпы говорится, что все объекты Sprint должны быть "полностью протестированы, потенциально реализуемые функции" в конце Sprint, которую будут считать завершенными. Спринты ВСЕГДА заканчиваются вовремя, и Команда не получает кредит и не разрешена ничего представить в обзоре Sprint, который не завершен - и это включает QA.

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

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

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

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

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

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

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

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

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

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

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

я был право, где Вы в этой методологии разработки, которую я называю Смертельный Метод Спирали . Я создавал программное обеспечение для правительства (США) в течение многих лет в такой модели. Это не работает хорошо, это стоит БОЛЬШОГО КОЛИЧЕСТВА денег, это производит последний код, плохой код, и ничего не делает для морального духа. Вы не можете сделать прогресс при расходах всех ошибок исправляющего времени, Вы, возможно, постарались не делать во-первых. Я был абсолютно сбит делом.

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

Назад к планированию...

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

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

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

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

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

Всего наилучшего

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Разделите задачи на меньшие задачи.

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

Хотелось бы надеяться, Вы фиксируете это путем занятия меньшим количеством dev задач в каждом спринте. Который приводит к вопросам: кто цели dev's настроек? Почему Dev не достигает тех целей последовательно?

, Если dev не устанавливает их автоголы, вот почему они всегда опаздывают. И это не идеальный способ практиковать Толпу. Это - просто поэтапная разработка с большими, управляемыми крайним сроком результатами и никакой фактической ответственностью заинтересованной стороны со стороны разработчиков.

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

Толпа зависит от четырех основных принципов, обрисованных в общих чертах в Гибкий вопрос Взаимодействий Манифеста .

1. - который означает dev, QA, управление проектами, и конечные пользователи должны говорить больше и разговор друг с другом. Программное обеспечение является процессом кодирования знания на тайном языке компьютеров. Для кодирования знания у разработчиков должно быть знание. [Почему Вы думаете, что мы называем его "кодом"?] Толпа не является "спецификацией записи - бросают фрамугу" методология. Это анти - "спецификация записи - бросают фрамугу"

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

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

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

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

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