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

Question

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

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

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

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

(Кстати, это лучшее место для размещения этого, или я должен был поместить это в "ответ"?)

Моменты, над которыми стоит поразмыслить / действовать:

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

Answer 1

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

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

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

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

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

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

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

Answer 2

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

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

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

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

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

Вернемся к планированию...

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

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

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

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

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

Желаю удачи!

Answer 3

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

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

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

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

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

Answer 4

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

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

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

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

1. Взаимодействие имеет значение - это означает, что разработчикам, QA, руководству проектами и конечным пользователям нужно больше общаться друг с другом.Программное обеспечение - это процесс кодирования знаний на тайном языке компьютеров.Чтобы закодировать знания, разработчики должны обладать этими знаниями.[Как вы думаете, почему мы называем это "кодом"?] Scrum - это не методология "написать спецификацию - перебросить через транец".Это ПРОТИВОРЕЧИТ принципу "пиши спецификацию - перебрасывай через транец".

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

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

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

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

Answer 5

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

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

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

Answer 6

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Answer 7

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

Answer 8

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

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

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

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

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

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

Answer 9

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

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

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

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

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

Я бы на твоем месте попробовал кое-что сделать:

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

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

Answer 10

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

Answer 11

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

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

Answer 12

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

Answer 13

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

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

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

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

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