Кодування та тестування в одному спринті

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

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

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

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

Я впевнений, що я не перший чоловік, який мав цю дилему.

Раніше я робив конвеєр: у поточному спринті тестова група тестує функції, реалізовані під час попереднього спринту. На моїй нинішній роботі прем'єр-міністр називає цей підхід "водоспадом", і як такий - неприйнятний.

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

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

Ви можете зробити багато речей:

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

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

• Співпраця між тестером та розробниками - ще одна ключова частина успіху. У моєму попередньому проекті, коли США, який закінчив розробник, QA людина робила "тестування пари" з розробником (може бути вручну, можна запустити кілька автоматизованих, а ще краще, обох), це працює досить добре.

Основна проблема полягає в тому, що у вас є програмісти, які кодують, але не тестують, і тестери, які перевіряють, але не кодують.

Вирішіть цю проблему, і у вас цього не буде, і, мабуть, більш ефективна команда.

Один із способів, який працював для мене в минулому, - запропонувати кодерам і тестерам з’єднати розповіді з чітким завданням - викласти повністю перевірену історію. Разом з цим я стерв усі форми мислення "dev complete": жодних "dev complete" стовпців на дошці scrum / kanban / trello, жодного ставлення кодерів "dev done".

Що сталося:

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

• Тестування було виконано набагато менше, оскільки тестери були піддані тестуванню модулів та інтеграції, тому вони не повторювали те ж тестування вручну.

• Деякі тестування автоматизовано, коли розробники краще зрозуміли, що потрібно тестерам.

• Деякі люди засмутилися.

• Історії в середньому швидше надходять, оскільки цикл коду-фіксування та тестування став майже миттєвим

Звичайно, це лише мій анекдотичний досвід, але ви, можливо, захочете спробувати це самі.

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

Це проблема спілкування , а не спритна проблема. Застосування спритної методології просто робить це очевидним. Команди силоса - це відомий анти-шаблон управління , тому сприймайте в цьому випадку неадаптованість гнучкості !

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

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

• Під час спринту:

  1. Команда розробляє дизайн нової функції та вплив на фактичну базу коду.

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

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

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

• Після спринту власник продукту оцінює нову функцію, щоб перевірити, чи відповідає вона потребам замовника. Ваша команда з питань якості насправді тут, після закінчення спринту.

Я вважаю, що ваші актуальні проблеми такі:

• Область застосування . Спринт стосується вашої команди, і лише вашої команди, а не вашого фактичного якості, який більше виступає як власник продукту.

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

якщо все або більшість кодування не виконано до кінця спринту?

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

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

Другий варіант - змусити QA управляти спринтом за розробниками, як ненавидить ваш прем'єр. Я також схильний це не любити. Це виключає поняття "випускаючий продукт" в кінці спринту, навіть якщо у вас є процес ескалації ваших релізів. Гірше, що розробники будуть зосереджені на "нових" речах, коли QA звернеться до них із запитаннями або помилками тестування. Devs також більш ймовірно, щоб виправити помилки в цій домовленості. Але я бачив, як він виробляє якісне програмне забезпечення вчасно.

Посібник з Scrum вимагає, щоб команди були крос-функціональними. Усі члени команди вважаються розробниками, незалежно від їх індивідуальної спеціалізації. Особи силоса (кодер, тестер, qa, ux тощо) не допомагають Scrum. Члени команди допомагають один одному, де тільки можуть. Не існує поняття "передача предмета qa".

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

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

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

Тестування та кодування йдуть рука об руку. Ви можете запланувати його модуль за модулем. Після закінчення модуля ви можете поставити його тестерам. Весь цей сценарій також залежить від того, на якій фазі тестування ви працюєте. Модель спіральної SDLC добре виглядає. При цьому одночасне тестування та кодування зручно. Іншим підходом може бути V модель .

Моя відповідь, яка, мабуть, спочатку досить дивна, була б така: ви не знаходите часу для тестування, оскільки ви думаєте, що тестування повинно проводитися на побічні ефекти коду. І під побічним ефектом я маю на увазі термін інформатика :

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

Я запропонував цитату, щоб підкреслити частину "взаємодії із зовнішнім світом": ви хочете, щоб тестування відбувалося в інтерфейсі користувача, оскільки воно друкується на екрані ("[для початку тестування] насправді неможливо, оскільки вам, як правило, потрібен функціонал Інтерфейс користувача для запису або створення автоматизованих тестів з ").

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

Ви повинні відпустити тестування тестування, коли код взаємодіє із зовнішнім світом, тобто він надрукував щось і очікує певного введення. Проблема з побічними ефектами полягає в тому, що вони, по суті, не визнаються. Це мені зоріло, читаючи інтерв'ю з Гвідо ван Россумом, де він сказав, що твердження, що вимикає комп’ютер, може бути доведено, що воно працює лише виконавши його.

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

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

Розглядати інтерфейс як "чужу територію" - це насправді правильна точка зору, оскільки вам не потрібно перевіряти логіку бібліотеки, яка не надана вами, і, можливо, дивно, це реалістична точка зору: чи справді ви очікуєте коли-небудь перевірити, що дзвінок, наприклад, MyWidget.draw()робить те, що ви очікуєте, на рівень одного пікселя?

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