Дилемма 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, зависит от вашей организации.

В большинстве реальных ситуаций Agile останавливается при доставке в QA / UAT или как там его называют.

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

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

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

Это становится хуже для серьезного программного продукта. Документация должна быть проверена и опубликована. Маркетинговые брошюры должны быть изменены. Продавцам нужно сказать, что они продают (нелегкая задача!) И т. Д. И т. Д. Вы действительно не хотите заниматься этим чаще, чем раз в год.

Очень краткосрочное решение - дать QA дополнительный период времени после вашей итерации, чтобы завершить тестирование. то есть. Если у вас есть двухнедельная итерация, не выпускайте ее до 3-й недели. В любом случае, QA не будет ничего проверять на следующей итерации, в течение первой недели.

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

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

Купите копию « Непрерывной доставки» Джеза Хамбла , прочитайте ее, от корки до корки, раздайте по команде. Вдохновите всех. Тогда реализуй все, что можешь из него.

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

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

Я знаю, о чем ты думаешь: у нас нет времени на все это. Позвольте мне сказать вам, вы делаете. Если вы перегружаете QA, вы развертываете слишком много за одну итерацию. Так что не надо. Если вы уже не перегружаете их, спросите, почему у них еще нет автоматизированных тестовых пакетов. Вы скоро будете.

Делайте все это с полной видимостью для бизнеса. Оцените ниже и добавьте часть этой работы в итерацию. Или, что еще лучше, разбить его на истории и заставить их расставить приоритеты, наряду со всем остальным.

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

Получив непрерывную доставку, вы можете начать сокращать время, затрачиваемое QA в конце итерации. Все заинтересованы в том, чтобы как можно скорее вернуть итерации параллельно. Может быть, у вас будет один день в конце итерации, где вам нужно заполнить время. Я уже ответил, что делать с этим в другом месте .

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

Кажется, есть проблема с тем, как вы решили, что именно составляет work for release N.

По какой-то странной причине (я могу только догадываться, что есть какое-то неправильное понимание конкретных рецептов Agile), вы каким-то образом решили, что гибкий подход требует, чтобы все усилия команды QA были включены в итерацию.

• ^{Если бы это было действительно так, я думаю, что популярность Agile не была бы даже близка к тому, что мы видим сейчас. Я не могу представить себе множество проектов, которые могли бы «пережить» обязательную синхронизацию итераций команды разработчиков с циклами тестирования QA.}

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

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

• ^{Например, первая «единица измерения» обозначается отдельным этапом, когда кандидатская сборка передается тестировщикам, а дальнейшие этапы соответствуют изменениям, включенным в циклы тестирования, выполняемые QA и т. Д.}

Также обратите внимание, что способ определения, который вы определяете work for release N, не форсируется рабочим процессом QA. Из того, что вы описываете, вещи выглядят так, как будто они имеют собственный (и довольно разумный) график.

Учитывая выше, более реалистичный способ определения рабочих единиц в вашем случае может быть следующим:

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 «... у нас есть обязательные процессы и инструменты управления , как эти лица (мы предпочитаем термин„ресурсы“) Взаимодействовать» .

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

нужно быть гибким в отношении самого применения гибких принципов. Я имею в виду, если требования проекта не являются гибкими (стабильными или изменяются медленно), то зачем? Однажды я наблюдал, как топ-менеджмент заставлял Scrum работать в проектах, без которых все было хорошо. Какая трата это было. Не только не было улучшений в их доставке, но, что еще хуже, разработчики и тестировщики были недовольны.

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

Отпускаемый релиз я вижу. Гектометр Хммм. Подумайте о том, чтобы добавитьв свой Agile коктейльодин или два снимка Lean . Я имею в виду, что если это не является потребностью клиента / рынка, то это будет означать лишь пустую трату (тестирование) ресурсов.

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

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