Дилема QA проти ітерацій

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

Ми розуміємо QA як додатковий біт перевірки до певної збірки (кандидата на випуск) до того, як ця збірка буде розгорнута для клієнта. Сенс у тому, щоб уникнути того, що одне зловмисне скоєння шкоди цілому випуску. Оскільки ви ніколи не знаєте, що це таке, QA доводиться чекати, поки всі функції / зобов’язання щодо випуску знаходяться в зборі. (Жодні відомі останні слова "Це були лише крихітні зміни".)

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

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

Без використання ітерацій це не проблема, оскільки ми можемо перекривати роботу для випусків N і N + 1. Однак, наскільки я розумію, це не сумісне з підходами на основі ітерації, як Scrum або XP. Вони вимагають, щоб ітерація була звільнена в кінці, при цьому всі зусилля для тестування повинні бути включені в ітерацію.

Я вважаю, що це обов'язково призводить до одного з таких небажаних результатів:

(A) Розробники простоюють в кінці ітерації, оскільки QA потребує часу для перевірки кандидата на випуск, і робота з виправлення помилок не повністю затримує розробників.

(B) QA починає працювати вже до того, як кандидат першого випуску буде готовий. Саме це в основному рекомендується на Stack Exchange. Але це не те, що моя компанія розуміє як QA, оскільки немає жодного тестованого кандидата на випуск. І «крихітна зміна», яка все порушує, все ще може бути внесена непомітно.

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

Чи є вихід із цієї дилеми?

Ми розуміємо QA як додатковий біт перевірки до певної збірки (кандидата на випуск) до того, як ця збірка буде розгорнута для клієнта.

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

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

У більшості реальних життєвих ситуацій спритна зупинка при доставці до QA / UAT або як би там не було.

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

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

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

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

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

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

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

Купіть копію безперервної доставки Jez Humble , прочитайте її, обкладинка на обкладинку, передайте її команді. Надихайте всіх. Тоді реалізуйте все, що від цього можете.

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

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

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

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

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

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

Без використання ітерацій це не проблема, оскільки ми можемо перекривати роботу для випусків N і N + 1.

Здається, проблема з тим, як ви вирішили, що саме є work for release N.

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

• ^{Якби це було дійсно так, я думаю, що Agile популярність не була б навіть близькою до тієї, що ми бачимо зараз. Я не уявляю багатьох проектів, які могли б "пережити" обов'язкове синхронізація ітерацій команди розробників із тестовими циклами якості.}

Нижче є трохи більше про спритність, але спочатку давайте розберемося work for release N...

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

• ^{Наприклад, перший "блок" позначається чіткою віхою, коли збірка кандидата передається тестерам, а подальші основні етапи відповідають змінам, які беруть участь у тестових циклах, проведених QA тощо.}

Зауважте також, що спосіб, який ви визначаєте, work for release Nтакож не вимушений робочим потоком із забезпечення якості. З того, що ви описуєте, речі виглядають так, що вони мають свій (і досить розумний) графік.

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

1. Діяльність з розробки до моменту передачі збору до QA
   Release Candidate N
2. Заходи з розробки, пов'язані з першим циклом тестування якості
   Release Candidate N patch 1
3. Діяльність з розробки, що стосується другого циклу контролю якості
   Release Candidate N patch 2
4. тощо, до остаточної збірки

Вище є ваші робочі підрозділи, незалежно від того, чи займаєтесь ви Agile чи ще.

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

Однак, наскільки я розумію, це не сумісне з підходами на основі ітерації, як Scrum або XP. Вони вимагають, щоб ітерація була звільнена в кінці, при цьому всі зусилля для тестування повинні бути включені в ітерацію.

Вище розуміння сумісності з Agile виглядає принципово неправильно, і ось чому ...

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

З цього погляду, дотримуючись певного "фіксованого" робочого процесу та ігноруючи, зручно це чи не просто суперечить духу Agile. Рабськи слідуючи «процедуру» призводить до практики порочить так красномовно Half-Arsed Agile Manifesto «... у нас є обов'язкові процеси і інструменти управління , як ці особи (ми вважаємо за краще термін" ресурси ") Взаємодіяти» .

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

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

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

Колірний випуск я бачу. Гм. Хммм. Спробуйте додати постріл або два Lean в свою моторний коктейль. Я маю на увазі, якщо це не потреба клієнта / ринку, то це означатиме лише марнотратство (тестування) ресурсів.

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

• ^{dev: так, це виглядає досить добре, щоб перейти до тестерів; QA: так, це виглядає досить добре для випадку, якщо потрібні подальші перевірки на судноплавство - подібні речі. Команда (dev + QA) задоволена, ось і все.}