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

Ответ 1

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

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

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

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

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

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

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

Ответ 2

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

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

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

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

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

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

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

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

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

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

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

Удачи!

Ответ 3

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

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

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

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

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

Ответ 4

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

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

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

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

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

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

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

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

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

Ответ 5

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

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

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

Ответ 6

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

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

• QA слышится и не отводится, чтобы его спрашивали: "Как вы собираетесь это проверить?" после того, как Devs сказали свою часть (менталитет водопада).

• Он позволяет QA предлагать идеи для тестирования, которые в то же время проверяют проверяемость критериев приемлемости, пока присутствует Истина/ПО (я сказал, что для них важно присутствовать на совещании по планированию 't I?!), чтобы заполнить любые пробелы в понимании.

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

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

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

• Они должны быть готовы к тому, чтобы их идеи для тестирования были опрошены Devs and Truth/PO и достигли компромисса; отношение "полиции КК" не будет вымываться в Agile-команде.

• Задачи QA должны иметь сложный баланс не слишком подробный или слишком общий (задачи могут быть записаны на карточке, чтобы идти на "плату радиатора" и обсуждаться на ежедневных встречах в стойке - их нужно перемещать от "в процессе" до "завершено" ВО ВРЕМЯ Итерации).

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

• Практически необходимо автоматизировать ваши тесты и иметь эти письменные и "неудачные" в течение первых двух-трех дней итерации или, по крайней мере, совместить с ними, когда у разработчиков есть готовый код. Затем вы можете запустить тест/ы и посмотреть, пройдут ли они, как ожидалось (надлежащий QD TDD). Так вы избегаете мини-водопада в конце итераций. Вы должны действительно продемонстрировать тест для Devs до или когда они начнут кодирование, чтобы они знали, к чему стремиться.

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

Что касается пункта 2 выше, посвященного задачам, я попытался создать задачи с размером от 1/2 часа до 2 часов, каждый из которых соответствует демонстрационной части работы, например. Msgstr "Добавить проверку неправильного пароля для автоматического тестирования - 2 часа". Хотя это помогает мне организовать мою работу, она была подвергнута критике со стороны других членов команды за то, что она слишком детализирована и имеет эффект, когда меня бросает вызов нескольким задачам, чтобы завершить с самого начала или вообще не в состоянии перенести какие-либо задачи вообще, потому что Я еще не добрался до них. Люди действительно хотят видеть постоянный прогресс в повседневной борьбе, поэтому более полезно создавать задачи за полдня или на 1 день (но вы можете сохранить свой собственный список "микро-заданий" для завершения из более крупных задач, которые вы используете для КОММУНИКАЦИИ общего прогресса на стенде).

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

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

Ответ 7

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

Ответ 8

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

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

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

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

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

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

Ответ 9

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

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

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

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

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

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

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

Вы также можете найти эти советы по сглаживанию сжигания скриптов.

Ответ 10

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

Ответ 11

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

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

Ответ 12

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

Ответ 13

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

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

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

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

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