Коллеги, подскажите. Насколько я понимаю по всем гибким методологиям предполагается,

что тестирование делается как финальная часть реализации инкрементных изменений. Т.е. в рамках спринта делается множество мелких циклов анализ-реализация-тестирование. Все верно?

Если так, то какой объем тестирования предполагается? Если confirmation, то как проверяются регрессии? А если confirmation + smoke/regression, то это занимает много времени. Да и все равно тестирование не полное. Когда делать полное? Как его привязывать к юзер сторисам и надо ли?

Всё определяется вашим DoD. Как вам надо, так вы и делаете, универсального рецепта нет.

Ну предположим по DoD выполняется минимальное тестирование. А как тогда планировать регрессионное тестирование? Или если оно не вошло в DoD, то его не надо проводить?

А что для вас "Done"? Вы поставляет клиентам продукт без регрессии? Если да, то зачем она вам в принципе? Если нет, почему она не в DoD?

Ок, позиция ясна, спасибо)

На здоровье, обращайтесь.

Не очень понимаю вопросы. Но регрессионные тесты по науке вешают на автотесты.

Ну, по науке-то понятно. Но вот у нас пока не повешены :( Работаем над этим. Но пока их нет как-то надо жить

Окей. И в чем вопрос?

Стоит ли включать ручной прогон регрессионников в DoD и прогонять его на каждую фичу или нет? Если нет, то когда их гонять и как это вписывается в гибки методологии?

Если мы говорим про гибкие методологии, то про регрессионные тесты, как и про многие говорится, что используйте инженерные практики. Т.е. автотесты, девопс, разработку через тестирование и прочее. Если говорить про практику - правильно комментировали - договориться в DoD, как вы работаете с релизами и регрессионным тестированием. Практика, которую я выстраивал в своей команде - фича тестирование + день/два на регрессионное. Т.е. в течение спринта для каждой задачи делаешь ответвление, и отдельно тестируется каждая задача, без регрессионных тесов. За день-два до окончания собирается общая и тестируется все, с учетом регрессионных. Но я ушел раньше, чем внедрили такой подход.

В целом звучит неплохо, спасибо за идею

Гибкие методологии никак это четко не предписывают (ну кроме сейфа, пожалуй). Всем важно, чтобы в конце получался инкремент, которым может пользоваться юзер. И если у вас даже без тестирования это получится - да вперёд. Есть, конечно, сложные производства, где после изменений нужно проводить регресс во множестве зависимых систем, или где цена ошибки слишком высока. Короче, где на регресс уходит больше 2 недель :) тогда это выносят за пределы дода (да простят меня все), и делают уже в отдельном цикле

LeSS еще. XP. Может что-то еще :)

А разве они предписывают, когда делать регресс?

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

Ну на самом деле да. Автотесты делаются для удешевления регрессионных тестов. Их можно гонять хоть каждый коммит.

Я бы на вашем месте: - забила на спринты и просто померяла бы, а сколько времени линейно по факту тратится на производство - измерения бы дали цифры, а где много времени тратится. Может это регресс, а могут быть сюрпризы. Это можно назвать узким звеном - расшивала бы узкое звено, в случае с тестами это автоматизация, повышение качества кода, ci/cd, риск-модели и тп

Я не про то. Разве лесс или хр прямо пишут, как обращаться с автотестами?

Кхе... интересное заявление

Это мое железное убеждение. Говорю как обладатель сертификации PSM II.

Ох е мое. Давайте не будем этим меряться, пожалуйста (погуглите в ли хотя бы, прежде чем меряться)

Я не меряюсь. Уверен, у Вас PSM III или еще что получше :)

В целом идея здравая, но сложно искать узкое место, когда все в перемешку делается) Сначала месяц кодирования, потом месяц тестирования. При чем по факту получается, что скоуп тестирования ограничен только длительностью

Ну я бы тогда вообще задала философский вопрос: а в чем проблема-то? :) Если такие циклы, то вряд-ли скорость. Формализация процесса? Управление тем, что есть?

У нас тайм ту маркет был под пол года Разрабатываешь сейчас, тестируешь через 3-5 месяцев Так что у вас еще не самый запущенный случай

Формализация процесса с целью получения адекватной возможности прогнозирования сроков и оптимизации процессов. Чтобы как раз можно было найти узкое звено, если оно есть

Тогда гляньте на statik как инструмент такое сделать

Тебя сейчас затянут в темный мир Канбана. Не ведись. Scrum - лучший фреймворк :)

Попробуйте сделать месячный спринт - 2 недели кодирование, 2 недели тестирование, что бы формально попасть в ограничение Скрама. Хотя с другой стороны можно расчехлить традиционный вопрос "Что бы что?" Ускорение TTM в два раза даст ли какие-то бенефиты? У вас вообще есть обратная связь? Только честно

Это ж водопад получается...

Если бы программированием и тестированием занимались одни люди - такое возможно. А если разные - тогда в твоей модели получается, команда работает в пол силы. Первые две недели работают одни, во вторые - другие.

Как верно написали выше, в текущей реализации плюс в том, что нет простоя. Пока тестят старую версию - разрабатывают новую. Для контекста поясню примерно устройство проекта: у компании есть свой продукт, который она развивает. Потом приходят заказчики и продукт под них адаптируют и интегрируют. Проекты портировани и интеграции чаще всего вообще водопадом делаются. Но параллельно происходит развитие core части продукта. Новые фичи, которые потом можно продавать заказчикам, рефакторинги для оптимизации процесса портирования и т.п. И вот эта core часть не имеет конечных требований, а развивается месячными циклами с постоянно корректирующимся роадмапом

А это другой вопрос. Сейчас ведь тоже самое? P.S. я когда-то работал по такой модели. Когда тестировщики тестируют, ми обычно занимались разгребанием техдолга, внутренние задачи то есть. Они шли уже в следующий релиз. Неплохо кстати было, я бы сказал техдолг менеджился нормально. Главное что бы не завелся эффективный менеджер с предложениями загрузить всех на 100% фичами=) Тогда вам и Скрам не поможет

Не совсем то же самое :)

Понял, что дал контекст, но не ответил на вопросы. Сокращение TTM вряд ли даст такие уж ощутимые бенефиты. Обратная связь зачастую косвенная. Т.е. у нас у самих появляется понимание, что мы уменьшаем время на портирование и интеграцию

Ну смотрите, раз у вас требования известны "наперед", то есть до выпуска релиза X и анализа обратной свзяи есть требования релиз X+1, то предположу, что это у вас достаточное оптимальная модель и так. Что можно делать - инвестировать в автоматизацию тестирования. Если нет бюджета, то система находится в локальном оптиуме=) По крайней мере организационно. Стоит таки наверное спросить - а какую мы проблему тут решаем?

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

Не очень понял, в чем мессейдж. 2 рабочие модели я изложил. Внедрение автотестирования и фича-тестирование + ускоренное регресс.

Не в чем конкретном, просто ответил на вопросы. За идеи спасибо!

Я всегда рекомендую начать с DORA метрик. Уменишить lead time - почти всегда хорошая идея. Только обычно это упирается в архитектуру / билды / тесты и лежит мне инструментария, досупного скрам-мастеру

Пару дней назад писали, по исследованиям Майкрософта, львиную долю времени разработчики тратят не на разработку, а на устранение блокеров. Один из ключевых блокеров для разработчиков является ограниченный умственный ресурс. Или творческий ресурс. Когда разработчик (не только программист) плотно находится в контексте задачи - он может решить ее на порядок быстрее, чем когда контекстов несколько. Просто потому что переключение контекстов - крайне тяжелая и долгая операция для мозга. Частично этот феномен описал Джордж Миллер, подсчитав количество объектов, которые человек может держать в кратковременной памяти. Сила Scrum не в коротком T2M, хотя это тоже. Сила в том, что на коротком промежутке времени вся команда концентрируется на очень ограниченном круге задач - и за счет этого производительность повышается в разы.

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

Не совсем Если говорить про классический поток, который есть в сервисных командах - контекст растягивается. Ты получаешь аналитику не в реальном времени, а хз через сколько дней после написания. Ты обращаешься с уточняющими вопросами - а аналитик и/или заказчик сам не помнит, чем там нужно было. Тестирование твоей задачи тоже хрен знает, когда будет. И когда у тестера возникнут вопросы - ты тоже не вспомнишь. А не дай бог найдут ошибку - запаришься возвращаться к задаче. Канбан как не-Scrum отлично работает, где задачи простые, однотипные. Тогда ты не испытываешь проблем с переключением контекста - все предельно понятно.

Ну в этом смысле да. Хотя внедрение скрама скорее всего не решит, а подсветит проблему очень долгого lead time, приводящего к болезненным context switcham. А решив проблему можно и канбан опять.. Если команду из вашего примера посадить в скрам, у них там наверняка будет опять же месячные спринты и так далее

Семь бед - один Канбан Я понял )

Да не, не обязательно. Спринты must - have имхо, а скрам опционален имхо. Спринты создают операционный ритм и оптимизируют сложность. Даже если вы работаете по канбану - итерации (они так там называются) полезная штука

В истинном Agile для софта, XP, тестирование идёт вначале. Это значит что качество может быть превосходным или максимально превосходным. То есть в идеале нужно 100% покрытие автотестами.

В XP модульные тесты возведены в ранг абсолюта

В моей команде, когда регрессионные автотесты начали бегать больше часа, разделили их на две части. Назовем «ядро» и все остальное. Ядро запускают сразу разработчики после того как на тестовый стенд залили свой код. И они же правят эти автотесты, если они сломались. То есть что делает эта пачка автотестов знает практически каждый в команде. И если они не проходят, то может сам понять не привлекая тестировщиков что это ошибка в коде или что автотест нужно править, потому что изменена работа core функционала. Вот такой «ограниченный» тишейп и регресс, чтобы не ждать тестировщиков когда они его запустят, когда огромный пакет автотестов пройдет, тестировщики разберут результаты прогона и насыпят ошибок. Что нужно будет переключить контекст (от следующей задачи) и разобраться в том что насыпали.

Так сложность не в том, что автотесты выполняются долго. А в том, что их нет :)

Это на будущее) когда будет впечатление, что близкое к 100% покрытие автотестами теперь стало проблемой))

Что-т ты мало на будущее замахнулся. Расскажи лучше, что делать Дмитрию, когда он станет президентом )

сам прочти сообщение с чего все обсуждение началось) Коллеги, подскажите. Насколько я понимаю по всем гибким методологиям предполагается, что тестирование делается как финальная часть реализации инкрементных изменений. Т.е. в рамках спринта делается множество мелких циклов анализ-реализация-тестирование. Все верно? Если так, то какой объем тестирования предполагается? Если confirmation, то как проверяются регрессии? А если confirmation + smoke/regression, то это занимает много времени. Да и все равно тестирование не полное. Когда делать полное? Как его привязывать к юзер сторисам и надо ли?

Так там ручное. А ты про автотесты

Хорошо, тогда уточню. Если регрессия ручная и занимает много времени - ее нужно автоматизировать (автотесты). Если уже регрессия на автотестах занимает много времени, то разделить ее в соответствии с важностью то что проверяется. Оставить то, что может пробежать примерно за 10 минут, пока разработчик себе чай\кофе наливает.

Ага, кстати да. Изначально XP и был Agile. Потом появилась армия консультантов, продающих Скрам. На так плох скрам, как консалтинговая индустрия, да простят меня присутствующие. Ведь в чем суть проблемы - человека нанимают скрам мастером на фултайм. Работу его померить крайне сложно. Ну он и создает имитацию деятельности. Рассчет capacity по тысяче различных формул и так далее

А ты был скрам-мастером?

Да, но не фултайм.

То есть всего один раз и не на фул-тайм, верно понял?

Что значит «один раз». Пять лет практикую, есть сертификат. И есть гигантская разница между процессами, которые построила сама команда (они обычно минимальные, потому что все равно эти предсказания не работают). И «консультантаским»

Вопрос #2: тоже занимался имитацией деятельности или делал что-то полезное для команды и организации?

Конечно имитацией, что вы :)

Вопросов больше нет. Спасибо за честные и смелые ответы. На мой взгляд, вы на правильном скрам пути (познании его). Эмпирицизм наше все.

А как мы эмпирически поняли, что скрам работает?

Подход называется Шу-Ха-Ри. Если нет возможности увидеть работу Скрам фреймворка на реальном продукте, то это моделируется на других деятельностях \ играх. (Типа Лего Скрам) Где нужно освоить уровень «Шу». А с «Ха» вы встретитесь в жизни, когда то что есть нужно привести к «Шу», а потом отбросить и сделать еще лучше «Ри».

шу-ха-ри в 2023 упоминать стыдно:) Ладно еще году в 2014, тогда это на всех конференциях говорили. Это же тупо hard-sale техника скрама.

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