Спираль Смерти Регрессии

Перевод статьи был подготовлен до начала курса.

«Автоматизация тестирования на JavaScript»

История, которая может показаться вам до жути знакомой:

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

Ваши планы на вечер четверга начинают таять на глазах.

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

И одного дня на все это не так уж и много.

.

С тестированием, наверное, можно уложиться в это время, но с помощью автоматизации сделать это будет нереально.

Вы делитесь этой плохой новостью со Скрам-мастером.

"ХОРОШО" , говорит Скрам-мастер, "Как насчет…" , и ты точно знаешь, что будет дальше.

«.

как насчет того, чтобы перенести автоматизацию на следующий спринтЭ» Автоматизация, наступающая непосредственно перед отметкой «готово», встроенная в историю и всегда отнимающая часть расчетного времени, отодвигается в будущее.

Снова.

"Мне это тоже не нравится…" , — говорит ваш Скрам-мастер, видя выражение вашего лица, «.

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

"Я понимаю" «», — отвечаете вы с улыбкой, чтобы продемонстрировать, что вы командный игрок, а также стремитесь сделать так, чтобы команда выглядела так, будто у нее все хорошо.

Конец истории

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

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

На время.

сроки выполнения.

Я оказался именно в такой ситуации и нашел фразу «спираль смерти регрессии» хорошей иллюстрацией нескольких концепций тестирования и полезной для информирования заинтересованных сторон о рисках неадекватной автоматизации тестирования.

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

Регрессионное тестирование

Программное обеспечение — это, по сути, строки кода, написанные в разное время разными людьми.

Иногда код пишут годами люди, которые никогда не встречаются.

И весь этот код должен работать вместе.

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

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

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

.

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

Изменения, которые нарушают ранее работающий код, называются регрессиями, и существует целая категория тестирования, посвященная обнаружению таких типов дефектов: регрессионное тестирование.

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

Таким образом, наивно рассматривать тестирование как просто тестирование исключительно новой функции.

Тестирование функции требует значительного объема тестирования внутри и вокруг нее — в связанных или просто областях приложения с высоким риском — и все потому, что мы должны предполагать, что могут возникнуть непредвиденные побочные эффекты.

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

Я даже слышал, что тестирование функции — это просто проверка перечисленных критериев приемки этой функции (!!!).

К сожалению, игнорирование или недооценка истинной стоимости регрессии является ключевым фактором в вхождении в смертельную спираль регрессии.

Agile-доставка и бремя регресса

Во-первых, Agile Delivery делит функции на небольшие отдельные пользовательские истории.

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

Все формы и гибриды Agile, Scrum, Kanban, SAFE, LeSS, ScrumBan и т. д. используют эти концепции по-своему.

Давайте посмотрим на каждого в отдельности.

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

Agile-истории независимо разрабатываются, тестируются, проверяются и утверждаются.

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

Да, пользовательские истории независимы, но под этими историями лежит один и тот же взаимосвязанный код и одинаковый риск внесения непреднамеренных изменений.

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

История 13 была реализована и протестирована.

Есть ли нам о чем беспокоиться? / НЕТ! Изменения в коде могли повлиять на другие истории (как связанные, так и не связанные с этой историей) Это ключевой момент для понимания спирали смерти регрессии: изменения в одной истории или добавление новой истории могут по-прежнему негативно влиять на поведение любой другой истории.

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

Необходимость регрессионного тестирования для выявления этих воздействий не изменилась.

Давайте перейдем ко второй концепции: Agile Delivery поощряет небольшие, поэтапные поставки.

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

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

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

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

Теперь регресс может потребоваться каждые две недели или даже несколько раз в неделю.

Это огромный сдвиг со времен доставки водопада.

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

Допустим, у нас есть недавно сформированная Agile-команда, которая только начинает свою первую итерацию разработки (спринт).

На первой итерации (или некоторой начальной продолжительности в потоковой модели) у нас может быть три истории для тестирования.

Тестировать эти истории довольно просто — мы просто тестируем эти три истории.

Во второй итерации мы добавляем две дополнительные истории.

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

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

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

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

Конечно, не все нужно полностью регрессировать, и тестировать что-то во второй раз всегда проще.

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

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

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

или лет. Каждый раз, когда история завершена, не только она должна быть проверена, но и все ранее завершенные истории должны быть в некоторой степени перепроверены.

Ручная регрессия не может масштабироваться с увеличением скорости Agile-доставки.

Это смертельная спираль регрессии: с каждой итерацией становится все труднее и труднее адекватно регрессировать существующее приложение.

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

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

Автоматизация в гибкой доставке

К счастью, мы знаем, что это не так — мы знаем, что можем использовать программное обеспечение для автоматической проверки ранее выполненных тестов, используя, как вы уже догадались, автоматизацию тестирования! Автоматизация тестирования бывает разных форм — модульные тесты, тесты API, компонентные тесты, интеграционные тесты, E2E-тесты, регрессионные тесты визуального пользовательского интерфейса и т. д. Неважно, кто их пишет или как они взаимодействуют с приложением, все автоматизированные тесты помогают проверить существующие функциональные возможности и обеспечивают уверенность в том, что предыдущая работа не была нарушена, что значительно снижает бремя ручного регресса.

Важно понимать, что автоматизация тестирования не ускоряет первоначальное тестирование.

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

Автоматизация — это процесс разработки, который требует размышлений и опыта, как и все остальное! Автоматизация не тестирует это просто запрограммированная проверка того, что уже было проверено.

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

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

Автоматизация — единственное, что может облегчить удушающее бремя регресса и избежать резкого снижения скорости разработки.

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

Гораздо чаще команды вынуждены принимать истории с частичной или достаточно хорошей автоматизацией.

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

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

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

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

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

Я твердо верю, что без полной автоматизации тестирования не может быть здоровой Agile-доставки.

Полная автоматизация истории с набором инструментов автоматизации, охватывающих все типы тестов (модульные, компонентные, интеграционные, UI и т. д.), абсолютно необходима для поддержания скорости доставки на протяжении всего жизненного цикла.

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

Не говоря уже о здравомыслии.

Спираль смерти

Сегодня утро четверга перед демо-днем, и у вашей команды в разработке еще несколько историй.

Разработчики заканчивают работу, и очень скоро код должен быть готов к тестированию.

Однако времени осталось не так уж и много.

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

Вы собираетесь протестовать, но тут вмешивается ваш Скрам-мастер: «Мы не можем этого сделать! Это первый шаг к спирали смерти!» «Автоматизация всегда является частью определения готовности» , добавляет разработчик, «это часть продукта, как код, ориентированный на клиента» .

«Вы хотите, чтобы мы добились успеха или просто кажусь, что добились успехаЭ» То, что говорит ваш бизнес-аналитик, вызывает у вас улыбку.

Вы решаете отменить собеседование на следующей неделе.

Слова благодарности

Самое раннее использование этого термина, которое я могу найти, находится в «Тестирование экстремального программирования» (2002) Лиза Криспин и Тип Хаус.

Еще несколько ссылок можно найти с помощью быстрого поиска в Google: http://ivory.idyll.org/blog/software-quality-death-spiral.html (2008) https://xebia.com/blog/regression-testing-with-an-agile-mindset (2010)

• Этика Обмена Файлами

  19 Oct, 24

• Capitan — Умный Список Покупок С Навигацией По Магазинам И Уведомлениями От Членов Семьи

  19 Oct, 24

• Задачи Технического Директора На Собеседовании

  19 Oct, 24

• Живые Тюрьмы Arkane Studios

  19 Oct, 24

• Проект Mars One – 12 Месяцев 2013 Г.

  19 Oct, 24

• Playstation Plus: Дополнительная Обязательная Услуга

  19 Oct, 24

• Ос И Веб-Сервер — Вместе Веселее

  19 Oct, 24

• Новый Dell Xps 13: Как Уменьшить 13-Дюймовый Ноутбук Для Деловых Целей?

  19 Oct, 24

• Открытый Исходный Код Для (Почти) Всего

  19 Oct, 24

• Подлинность Ваших Видео Теперь Неоспорима Благодаря Prover

  19 Oct, 24