Як встановити тестування в спринтах Scrum та як писати історії користувачів у Scrum


15

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

  1. У спринті зі скажімо 5 історій, коли ви відпустите на тестування? Це як тільки історія завершена розробником або після того, як всі історії завершені, але до закінчення спринту, що дає тест, необхідний час для тестування.
  2. Якщо БА пише розповіді користувачів, яка повинна бути деталь. Традиційно потрібен тривалий час, щоб написати специфікацію з усіма макетами, поведінкою, текстом тощо, які потрібно допрацювати. Я думаю, моє питання полягає в тому, як писати історії, які можна реалізувати і перевірити.
  3. Наша тестова група - нетехнічна. Наскільки важливо автоматизоване тестування інтерфейсу для Scrum. Інтерфейс базується на WPF.

У мене є солідний досвід розробки з використанням гнучких методів (TDD, огляди коду, рефакторинг тощо), але новим для розгляду.

редагувати: Ітераціями я маю на увазі, що якщо є 100 вимог, ми можемо випустити на тестування, коли ми закінчили 30, 35, 35 вимог, а не чекати, поки всі 100 вимог будуть виконані.


4
We have a waterfall/iterative SDLC.Детальніше про це. Водоспад за визначенням є послідовним процесом, а не ітераційним. Хоча існують модифіковані водоспади (такі як модель сашімі або водоспад з підпроектами), всі вони є послідовними. Чи намагаєтесь ви рухатися до ітеративних процесів із поточного послідовного процесу?
Томас Оуенс

1
@Pratik, як у вас все склалося? Чи вдалося вам краще співпрацювати з командою QA?
флюп

Відповіді:


11

Якщо тестування є окремим від розробки, у вас є дві окремі команди scrum. Дуже погано мати одну роботу в іншій.

Ваші розробники повинні написати власні тести, окремо від цієї команди. Ви повинні ставитися до цієї іншої "тестової" команди як до своїх клієнтів.

У спринті ... коли ви відпустите на тестування?

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

Я думаю, моє питання полягає в тому, як писати історії, які можна реалізувати і перевірити.

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

Наскільки важливо автоматизоване тестування інтерфейсу для Scrum.

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


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


6
After you're development team is done, you release it to other teams for "testing" or "deployment" or whatever else happens in the organization. Чим це відрізняється від Ітеративного водоспаду? У цьому випадку спринт - це дійсно коротка ітерація водоспаду. Цей тип поразки є однією з найбільших сильних сторін Agile та Scrum IMO, що всі BA, Developers та QA разом в одній команді, і всі вони спільно володіють спринтом, який вони випускають. Це руйнує бар'єри, які виникають у проектах.
maple_shaft

4
Чи можете ви детальніше пояснити, чому автоматичне тестування інтерфейсу є важливим? Scrum - це система управління проектами, яка не диктує жодних технічних практик. Єдине посилання на тестування, яке я можу знайти стосовно Scrum, що команда Scrum - це багатофункціональна команда. Хоча я віддаю перевагу автоматизованому тестуванню, Scrum не вимагає ні автоматизованого тестування, ні тестування взагалі, хоча проходження тестів повинно бути частиною визначення «Готово». Це просто говорить, що будь-яке тестування, яке робиться, робиться командою. Підсумок правильний - поточна організаційна структура недостатньо підходить до Scrum.
Томас Оуенс

2
Питання, скопійоване прямо з оригіналу публікації, наголос додав: "Наскільки важливо автоматизоване тестування інтерфейсу для Scrum ". Для Scrum це зовсім не важливо.
Томас Оуенс

2
Формулювання у вашій відповіді звучить так, що автоматичне тестування інтерфейсу є частиною процесу Scrum, і це не так. Але це не означає, що це не дуже добре, що має зробити команда розробників для підвищення якості. Я погоджуюсь, що це питання мало сформульоване, але слід розрізняти "чи це потрібно для Scrum" і "чи повинен завершення автоматизованого тестування інтерфейсу бути частиною мого визначення зробленого для історії". Зрештою, відповідь не змінюється, але стає більш зрозумілим, чому вона потрібна.
Томас Оуенс

9
Essential. Completely required.потрібно змінити, щоб відобразити, що це не є "суттєвим" або "повністю необхідним" рамками процесу Scrum. Зараз неінформований читач прочитає цю відповідь і зробить висновок, що якщо ви не виконуєте автоматичне тестування інтерфейсу, ви не виконуєте Scrum. Це хибний висновок, але цілком зрозумілий з огляду на формулювання цієї відповіді. Існує чітке розмежування між "чимось, що ти повинен зробити", і "чимось, що має наказ".
Томас Оуенс

9

Більшість відповідей, які я збираюся дати, стосуються Agile методу розробки програмного забезпечення проти методу Iterative Waterfall. Scrum просто трапляється популярною реалізацією Agile.

  1. У типовому Scrum немає окремої фази тестування, оскільки формальне тестування повинно відбуватися протягом усього спринту. Оскільки розробник закінчує користувацьку історію, ресурс якості повинен вже підготувати свої тестові випадки та розпочати тестування з цього моменту. Якщо їхні тестові справи пройдуть, вони приймають історію користувача та переходять до наступної. Після завершення та прийняття всіх історій користувачів тоді спринт закінчується, і ви починаєте наступну. Це, звичайно, залежить від постійної інтеграції, тому зміни розвитку одразу доступні для QA. Подальший розвиток повинен слідувати рекомендаціям TDD, щоб забезпечити тест регресії максимально швидко і безболісно.

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

  3. Автоматизоване тестування користувальницького інтерфейсу може бути хорошою справою, але я особисто вважаю, що більше зусиль щодо методів TDD та 100% тестового покриття всіх бізнес-логік важливіше. Більшість команд з розробки програмного забезпечення не можуть досягти 100% покриття Business Logic, тому, на мою думку, автоматизоване тестування інтерфейсу було б марною витратою дорогого часу, який можна було б використати для написання більшої кількості тестів для BL. На мою думку, це розкіш, а не потреба.


Справжнє запитання, що стосується 1: якщо QA перевіряє кожну історію користувача, як тільки вона робиться, а потім переходить до наступної, як ви перевіряєте, чи остання історія в межах одного спринту не зламана (можливо, тонко) Історії користувачів, які вже були протестовані? Своєрідна "регресія в межах одного спринту". Я, звичайно, говорю про ручний КЯ, а не про автоматизовані тестові набори.
Андрес Ф.

@AndresF. Якщо слідувати процесу TDD разом із CI, то якщо реєстрація порушить існуючі функціональні можливості, тестові одиниці не вдасться, і люди отримають сповіщення. Звичайно, це ефективно лише за умови 100% тестового висвітлення ділової логіки, однак прості проблеми з логікою, оточенням або інтеграцією та логікою презентації все-таки потенційно можуть мати дефекти, внесені в розробку нових історій користувачів, які не можуть бути сприйняті. Автоматизоване тестування користувальницького інтерфейсу, як запропонував С.Лотт, проходить довгий шлях, щоб наздогнати більшість із них, але в кінцевому рахунку, трохи більше, ніж швидкий тест на дим повинен вирішити ці проблеми. продовження ...
maple_shaft

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

@maple_shaft: Це легко сказати, але QA не любить випуск у середині їх тестування. Також ми часто перевіряємо створення CI, але випуск робиться лише на вимогу. Поточна тестова команда не здатна написати автоматичний тест на інтерфейс користувача. Вони роблять виключно ручне тестування. Це мені було б важко змінити.
софтведа

@Pratik Я розумію, як важко мені повірити. Я знаю біль. Можливо, ви можете розширити спринт, але мати три-чотири випуски до тестового середовища за спринт? Таким чином тестувальна група може залишити на день посеред тестового випадку і бути впевненою, що оточення не змінилося протягом ночі.
maple_shaft

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

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

  2. Це одна з найбільших труднощів в Scrum IMO. Ви повинні знайти потрібну кількість специфікацій, необхідних для отримання реалізованої, перевіреної історії користувача. Занадто багато попереднього аналізу, документації та специфікацій призведе до жорсткого плану, який неминуче виявиться неправильним протягом курсу спринту. І навпаки, історія користувача, яка не була чітко визначена та виражена власником продукту, призведе до насиченої пропускної здатності зв'язку між розробниками та PO під час спринту та затримки в розробці, тоді як PO приймає рішення про історії користувачів на півдорозі спринту. .

    У нашому випадку ми визначили, що потрібна кількість деталей для історії користувача повинна бути 1 / описом у вигляді "як ... я хочу ... так що ..." і 2 / серія прийняття критерії. Ми рідко робимо макети інтерфейсу користувача заздалегідь, це може статися під час планування спринтів, але це більше ескізи, які згодом відкидаються.

  3. На мій досвід, автоматичне тестування користувальницького інтерфейсу надзвичайно трудомістке та надзвичайно крихке. Існують способи зробити це в WPF, але я ретельно розмірковував би на підтримку таких тестів з перевагами, перш ніж йти цим шляхом.


2

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

Візьміть свій 5-поверховий приклад спринту. Якщо ваші команди звикли писати код на всі 5 історій, то тестуючи всі 5 історій, то розмір партії - 5 історій. Розріжте це навпіл. У наступному спринті працюйте спочатку над 3 найактуальнішими історіями, готуючи їх до тестування як можна раніше. Оскільки тестери тестують ці 3 історії, решта може підготувати решту 2-х історій. Це викличе певні зростаючі болі. Змініть, як ви працюєте, щоб зробити це більш комфортним.

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

Може знадобитися кілька спринтів, щоб вирішити великі проблеми, пов'язані з тестуванням тестування невеликої партії історій, тоді як програмісти працюють над наступною партією історій. Як тільки вам стане зручно, знову розріжте розмір партії навпіл. І знову. Протягом року команда буде комфортно перевіряти історії, оскільки програмісти вважають, що вони закінчили з ними і, ймовірно, роблять менше помилок по дорозі. Кожна історія буде зроблена раніше.

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

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

Я сподіваюся, що вам це допоможе.


0

Просто хочете поділитися досвідом, як показано нижче, сподівайтеся, що це вам корисно.

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

Для кожної великої історії користувача вона має бути розбита на багато підзадач, і коли підзадачі повністю виконані розробником, їх слід негайно відпустити в QC для тестування. Дефект слід виправити після тестування для тих, хто закінчує тестування підзадач.

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

У програмі Scrum розповіді користувачів повинні бути в будь-якому форматі до тих пір, поки розмови навколо цих історій відбуваються і не очікуються, що вони будуть завершеними або статичними. Невелика історія, яка називається просто історією користувача, - це добре зрозуміла і може бути реалізована в спринті. Пріоритет історії може базуватися на рентабельності інвестицій (ROI), вартості бізнесу або будь-якому іншому, що користувач погоджується. Це діяльність PO.

Наша тестова група - нетехнічна. Наскільки важливо автоматизоване тестування інтерфейсу для Scrum. Інтерфейс базується на WPF

Застосування тестування автоматизації в Scrum - досить складна діяльність. Оскільки всі функції реалізовані неповно і не дуже стабільні, щоб дозволити QC реалізувати тестовий випадок якимсь інструментом автоматичного тестування. Це слід робити для спринту під назвою: регресія.

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.