Чому керівництво Scrum каже, що немає тестерів?

Я читав посібник з Scrum з scrum.org, і він говорить:

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

У прямому перекладі це означає, що немає тестерів, що бентежить. Як вони можуть це запропонувати?

Це означає, що або:

1. Тестери інтегровані в інструменти побудови команди розробників, щоб допомогти розробникам пройти тестування та тестування.

   або:

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

Будь-який із цих засобів означає, що немає необхідності в окремій групі тестування.

У прямому перекладі це означає, що немає тестерів, що бентежить ... Як вони можуть це запропонувати?

Так, це так саме те , що вони пропонують. Іншими словами - розробники - тестери, а тестери - розробники.

Ідея полягає у сприянні власності та якості коду .

Це не означає, що код не перевіряється, але те, що люди, які беруть участь у його написанні, є тими, хто бере участь у його тестуванні, - немає розподілу обов'язків.

Проблема, з якою намагається вирішити цей підхід, - це занадто поширене розмежування між розробниками та тестерами, де розробники напишуть код і "перекидають його через стіну" іншій команді, а потім він повертається вперед і назад, затримуючи проект і виробляючи підстандартне програмне забезпечення.

Основна частина цього полягає в тому, що відповідальність кодера полягає у створенні коду, який працює і заповнює вимогу. Для цього потрібен певний спосіб мислення - "Код, який я пишу, робить те, що належить робити".

Змішати обов'язки кодера означає, що кодеру зараз потрібно вводити інші набори мислення для інших видів діяльності, однак, як кодер, важко неможливо, щоб повністю розлучитися з цим настроєм.

Відповідальність тестера полягає в пошуку помилок і місцях, де функціональність відхиляється від необхідної функціональності. Для цього потрібна думка "Код порушений, і я дізнаюся як".

Так само бізнес-аналітик намагається визначити вимоги, які клієнт насправді задає. Це вимагає іншого мислення: "програма не працює таким чином, але повинна".

Для того, щоб кодер працював у будь-якому іншому потенціалі, існує обґрунтована ймовірність того, що настрій розуму вступить у конфлікт і кодер виконає підпункт:

• Coder / QA - "Код працює ідеально, і я вже закодований, щоб обробляти всі можливі способи, я думаю, що це може зламати його".
• Coder / BA - «Код повинен працювати так, як я хочу, і це були б акуратні речі, які слід додати до них, про які клієнт не думав.

Це не означає, що кожен кодер сприйнятливий до цих проблем (я зустрічав деякі дуже обдаровані типи кодерів / QA ... хоча не для коду, який вони написали).

Це стосується і команди розвитку. Поєднання обов'язків та пов'язаних з ними думок цих обов'язків для команди розробників ставить під загрозу кінцевий продукт (код).

Там сказано, що не існує підрозділу, присвяченого тестуванню. Це не означає, що жодних тестів не робиться. Це означає лише, що члени команди будуть робити власне тестування та часто перевіряти код / ​​функції інших людей. Я не такий знайомий з методологією scrum, але я піду на кінцівку і скажу, що клієнт також може бути залучений до тестування.

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

Замість того, щоб дозволити людям завантажувати роботу з якістю програмного забезпечення на когось іншого і ігнорувати її, це змушує всіх постійно думати про код, який вони пишуть з точки зору якості, тому це гарна ідея.

Це твердження, як правило, намагається уникати роботи силосів. Однією з частин рішення цього є такі практики, як - Тестовий керований розвиток - Програмно парне програмування - Запросити витягнення - Автоматизація тестування та подібне, що всі роблять тестування невід'ємною частиною процесу розробки, а не те, що робиться ізольовано або на стороні, або 'після'.

Крім того, в Посібнику з Scrum дуже обмежено розмовляють про ролі. Насправді вони говорять про Команду розвитку. Що вони означають, що вам потрібна сильна крос-функціональна команда. Це означає, що залежно від того, що потрібно для ваших проектів, вам потрібен цілий спектр навичок, таких як UX, BA, QA / Tester, Ops, Coder тощо тощо, але чи це один чи багато людей, що їх охоплюють, насправді не має значення.

Команди, з якими я працюю, безумовно, виконують роль QA, як і у нас DevOps. Але всі вони теж Devs, тільки зі спеціалізацією в цих областях. Хитрість насправді полягає в тому, щоб не потрапляти в силоси і працювати ізольовано.

Це не обов'язково означає, що немає тестерів. Можливо, команда Scrum присвятила себе тестерам, а може не зробити.

Для мене, що означає це твердження про Scrum, це те, що ви повинні думати про весь трубопровід доставки як про одну команду. Бути частиною однієї команди пропонує кілька речей:

1. Існує єдина оцінка щодо історії / помилки / завдання. Немає оцінки розробок і тестової оцінки.
2. Команда не оцінює історію і бере на себе зобов’язання без тестера.
3. Якщо щось піде не так, це не більше вини тестера, ніж вини розробника. В цьому винна команда .
4. Команді ніколи не потрібно позичати, запитувати або просити тестерів.
5. Тестування є частиною визначення зробленого. Неперевірена робота - це незавершена робота.
6. Розробники повинні розглянути можливість перевірки, коли вони розробляють свій код.

Якщо вони працюють разом однією командою, то команда досягає успіху разом і провалюється разом. Я був у дуже успішній команді Scrum, яка мала кілька тестерів. Тестери були присутніми під час усіх стадій, догляду за доглядом, планування тощо. Якби не було зрозуміло, як перевірити історію, команда не взяла б на себе зобов’язання. Ми завжди розмовляли з нашими тестерами при оцінці.

Потенційні ознаки, які ви насправді не можете ставитись до тестерів як до складу групи з доставки, навіть якщо ви вважаєте, що це зробите:

1. Тестери мають "QA standup" (так, я це бачив).
2. Тестери мають окрему структуру управління.
3. Ви маєте перевагу із забезпечення якості.
4. Ви сильно покладаєтесь на тести наскрізь.
5. На тести пишуть наступний спринт.
6. Більшість тестувань відбувається в останній день спринту.

Це суб'єктивні і не обов'язково помилкові. Вони, правда, червоні прапори.

З урахуванням цього, цілком можливо створити команду Scrum без того, хто має призначену роль тестера. Це теж може працювати добре. Особливо, якщо ви автоматизуєте тестування. TDD теж допомагає.