Почему в руководстве Scrum нет тестеров?

14

Я читал Руководство по Скраму с сайта scrum.org, где написано:

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

В буквальном переводе это означает, что нет тестеров, что сбивает с толку. Как они могут предлагать это?

scrum

— Pete2k
источник

4

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

— rwong

3

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

— zzzzBov

25

Это означает, что либо:

Тестеры интегрированы в команду разработчиков - инструменты, помогающие разработчикам как тестировать, так и тестировать.

или:
Команда практикует разработку через тестирование - то есть они пишут автоматизированные тесты, которые проверяют систему.

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

— ChrisF
источник

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

— Maxood

4

@Maxood: Я бы сказал, что TDD определенно не делает ручное тестирование излишним. Если что-то становится проблемой, вы решаете это; Вы не начинаете избегать этого.

— Майкл Боргвардт

@MichaelBorgwardt Очень верно! Но что, если вы обнаружите, что ваш тестер занят модульным тестированием, которое в первую очередь является работой разработчика? Я чувствую, что первый вариант следует использовать только тогда, когда речь идет об оптимизации кода, масштабируемости приложений и т. Д. Что вы скажете?

— Maxood

7

@Maxood: По моему мнению, тестеры не должны касаться модульных тестов. Они должны работать над приемочными тестами в сотрудничестве с разработчиками и нести ответственность за ручное тестирование / тестирование графического интерфейса пользователя. Модульное тестирование находится на уровне, который интересен только разработчикам. Тестовая пирамида ( blogs.agilefaqs.com/2011/02/01/inverting-the-testing-pyramid ) также имеет ответные способности, модульное тестирование = разработчики, приемочное тестирование = общий доступ , тестирование графического интерфейса = тестеры.

— Мартиерт

12

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

Да, это именно то , что они предлагают. Другими словами - разработчики являются тестерами, а тестеры - разработчиками.

Идея состоит в том, чтобы способствовать владению и качеству кода .

Это не означает, что код не тестируется, но что люди, занимающиеся его написанием, участвуют в его тестировании - нет разделения обязанностей.

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

— Одед
источник

2

Я решительный сторонник проверки личности А на то, что разработал человек Б. Что Scrum дает в качестве совета, чтобы избежать ловушек «слепоты собственного кода» (когда вы являетесь разработчиком и тестировщиком функции X, вы не используете код во всех отношениях, потому что знаете, как он кодируется, и считаете, что он должен работать или подсознательно избегать слабых мест)?

— Марьян Венема

1

@MarjanVenema - То, что написал человек A, может быть проверено человеком B, или автоматические тесты могут быть написаны до того, как был написан любой код.

— Одед

5

У всех разработчиков есть QA-слепота, которая никогда не исчезнет. В отрасли произошло то, что люди зашли слишком далеко с «QA vs. Devs» и создали систему «брось через стену», и тут есть обратная реакция. Разработчики и QA преуспевают и терпят неудачу как одна команда, но QA - это роль и навык, отличающийся от кодирования. Программистам необходимо выполнить dev-тестирование, а модульное тестирование является частью QA, но это не вся функция QA. Кроме того, роли QA часто включают создание документации в местах, которые не стали настолько «гибкими», что перестали писать техническую документацию.

— Уоррен Р

6

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

— Джорджио

2

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

— 17 из 26

2

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

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

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

Аналогичным образом, бизнес-аналитик пытается определить требования, которые клиент фактически запрашивает. Это требует другого подхода: «приложение не работает таким образом, но оно должно работать».

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

Кодер / QA - «Код работает отлично, и я уже написал код для обработки всех возможных способов, которые могут привести к поломке».
Coder / BA - «Код должен работать так, как я хочу, и это было бы изящным дополнением, о котором клиент не думал.

Это не означает, что каждый кодер подвержен этим проблемам (я встречал некоторые очень одаренные типы кодеров / QA ... хотя и не для написанного ими кода).

Это распространяется и на команду разработчиков. Смешивание обязанностей и связанных с ними подходов этих обязанностей для команды разработчиков ставит под угрозу конечный продукт (код).

— geocodezip
источник

1

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

— марко-fiset
источник

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

— Робин Грин

1

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

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

— Мэтт Гибсон
источник

1

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

Кроме того, в Scrum Guide очень мало говорится о ролях. На самом деле, они говорят о команде разработчиков. Они имеют в виду, что вам нужна сильная межфункциональная команда. Это означает, что в зависимости от того, что нужно вашим проектам, вам нужен целый ряд навыков, таких как UX, BA, QA / Tester, Ops, Coder и т. Д., И т. Д., Но неважно, является ли это одним или несколькими лицами, которые занимаются этим.

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

— user334514
источник

1

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

Для меня это утверждение о Scrum означает, что вы должны думать обо всем конвейере доставки как о единой команде. Участие в одной команде предполагает несколько вещей:

Существует одна оценка для истории / ошибки / задачи. Нет оценки разработчика и теста.
Команда не оценивает историю и не делает ее без присутствия тестировщика.
Если что-то идет не так, это не более, чем вина разработчика, чем ошибка разработчика. Это вина команды .
Команде никогда не нужно брать, запрашивать или запрашивать тестеров.
Тестирование является частью определения сделано. Непроверенная работа - это незавершенная работа.
Разработчики должны учитывать тестируемость при разработке своего кода.

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

Возможные признаки того, что вы не можете относиться к тестерам как к команде доставки, даже если вы думаете, что это так:

У тестеров есть «QA standup» (да, я видел это).
Тестеры имеют отдельную структуру управления.
У вас есть лидерство по обеспечению качества.
Вы сильно полагаетесь на сквозные тесты.
Тесты пишутся в следующем спринте.
Большинство тестов происходит в последний день спринта.

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

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

— Brandon
источник