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

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

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

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

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

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

   или:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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