Содержание
Правообладатель, услышав эту плохую новость, созывает экстренное собрание и предлагает отложить автоматизацию тестирования, чтобы гарантировать, что команда выполнит свои обязательства по спринту. Это регрессионная спираль смерти — с каждой итерацией все сложнее и сложнее адекватно регрессировать существующее приложение. Производительность команды схлопывается, так как бремя тестирования предыдущей работы занимает все большую и большую часть общего объема усилий.
P1 – Высокий (High) – требуется исправить в первую очередь; P2 – Средний (Medium) – требуется исправить во вторую очередь, когда нет дефектов с высоким приоритетом; P3 – Низкий (Low) – исправляется в последнюю очередь, когда все дефекты с более высоким приоритетом уже исправлены.
Оставленная без контроля, начальная скорость команды замедлится, а затем остановится, так как каждое новое изменение требует существенного и постоянно растущего набора предыдущих историй, которые также должны быть проверены. Тестовая документация очень важна и разрабатывается для каждого проекта индивидуально. Стандартизация процесса разработки позволяет быстро разрабатывать документацию для разноплановых проектов. Дизайн тестовых планов, тестовые сценарии, программы и методики испытаний в соответствии с ГОСТ, тестовые сценарии для проведения приемо-сдаточных испытаний, протоколы тестирования могут быть разработаны для любого проекта на любой стадии разработки ПО в течение нескольких недель. Помимо всего выше приведённого следует не забывать добавлять новые кейсы для тестирования нового функционала.
Автоматическая рассылка результатов тестирования заинтересованным лицам не позволит пропустить важные дефекты ПО. Обращаем Ваше внимание, что после внедрения проекта автоматизированного тестирования необходимо регулярно поддерживать автоматизированные тесты в рабочем состоянии. Нельзя отрицать тот факт, что при изменении приложения оно становится менее качественным. Тем не менее, при каждом изменении приложения тестировщики должны выполнять регрессионное тестирование, чтобы убедиться в стабильности старых компонентов и модулей. Так как 70% жизненного цикла приложения составляют изменения, улучшения и добавления нового функционала, то и регрессионное тестирование является важнейшим этапом. Оставляя любое количество регрессии на трудоемкое, ручное тестирование, вы встаете на скользкую дорожку, которая может быстро привести к регрессионной спирали смерти.
Хорошо составленные тестовые сьюты помогут отлавливать наибольшее количестов багов при регрессии. Регрессионные тестовые сьюты должны быть легко поддерживаемыми и оптимизируемыми, что может быть достигнуто мониторингом изменений в тестовых кейсах. В дополнение к этому чётко отлаженный процесс будет гарантировать, что только необходимые и полезные тест кейсы попадут в итоговые тестовые сьюты. Регрессионное тестирование – не обязательный, но рекомендуемый этап. Он позволяет убедиться в том, что после компиляции исходных текстов PostgreSQL работает так, как ожидается. В процессе тестирования проверяются как стандартные операции SQL, так и расширенные возможности PostgreSQL.
Давайте перейдем ко второй концепции — что Agile Delivery поощряет небольшую, инкрементную доставку. Если бы необходимо было регрессировать приложение каждые шесть месяцев, стоимость регрессионного тестирования, даже медленного ручного, не была бы ощутимой. Фактически, именно так мы раньше и поставляли программное обеспечение до перехода к Agile разработке — у нас был бы план регрессионного тестирования, и каждые шесть месяцев мы выполняли этот план перед релизом. Это часто занимало дни или недели, но в рамках шестимесячного цикла релиза это было не слишком обременительно. Я оказался именно в такой ситуации и обнаружил, что фраза «регрессионная спираль смерти» является хорошим иллюстрированием нескольких концепций тестирования и полезна для информирования правообладателей о рисках неадекватной автоматизации тестирования.
С помощью анализа количества найденных багов и их критичности можно отобрать полезные тестовые кейсы и составить наиболее эффективные сьюты. Периодически тестовые сьюты должны обновляться, чтобы в них были только актуальные кейсы. Также следует разделять сьюты на категории, что более удобно для поддержки и прохождения. Вы работаете QA в небольшой команде разработчиков; сегодня утро четверга второй недели вашего двухнедельного спринта. У вашей команды еще несколько историй в разработке, которые должны быть утверждены к утру пятницы, чтобы быть готовыми к демонстрации днем.
Это непростая задача, и разработчики программного обеспечения разработали стратегии, подходы, шаблоны и методы, чтобы сделать процесс создания сложных систем немного проще, менее рискованным и более предсказуемым. Эти стратегии помогают гарантировать, что изменения, сделанные здесь в программном обеспечении, будут иметь ожидаемые эффекты именно здесь, и не будут иметь неожиданных последствий в других местах. Прежде чем мы перейдем к регрессионной спирали смерти, мы должны понять идею регрессионного нейролингвистическое программирование тестирования, и в частности, что тестирование фичи — это больше, чем просто тестирование фичи. Регрессионное тестирование – цикл тестирования, который производится при внесении изменений на фазе системного тестирования или сопровождения продукта. Главная проблема регрессионного тестирования – выбор между полным и частичным перетестированием и пополнение тестовых наборов. При частичном перетестировании контролируются только те части проекта, которые связаны с измененными компонентами.
На ГМП это пути, содержащие измененные узлы, и, как правило, это методы и классы, лежащие выше модифицированных по уровню, но содержащие их в своем контексте. Регрессионными могут быть как функциональные, так и нефункциональные тесты. Автоматизация тестирования существует во многих формах — модульные тесты, API-тесты, тесты компонентов, интеграционные тесты, тесты E2E, визуальные регрессионные тесты пользовательского интерфейса и т. Неважно, кто их пишет или как они взаимодействуют с приложением, все автоматизированные тесты помогают проверить существующую функциональность и обеспечить уверенность в том, что предыдущая работа не была нарушена, что значительно снижает бремя ручной регрессии. Держу пари, что эта история, к сожалению, знакома многим из вас. Контекст или причина не имеют значения, мы неизбежно оказываемся в ситуациях, когда нас заставляют откладывать, сокращать или просто пропускать автоматизацию тестирования.
К сожалению, любая незаконченная автоматизация, независимо от того, насколько она мала, обязательно увеличивает нагрузку регрессии в будущих спринтах. Правообладатели или люди, не имеющие опыта разработки, часто упускают риск внесения критических изменений за пределами функции в разработке и необходимости регрессионного тестирования. Я даже слышал, как говорят, что тестирование функции — это просто проверка перечисленных критериев приемлемости этой функции(!!!). К сожалению, игнорирование или недооценка реальной цены регрессии является ключевым фактором для входа в регрессионную спираль смерти.
Если вы тестируете и автоматизируете историю, что произойдет, если из-за нехватки времени мы согласимся с правообладателем и признаем историю законченной с неполной автоматизацией? Некоторое количество бремени регрессии передается на следующую итерацию, которая затем потребляет даже больше времени на тестирование в последующем спринте. Это дает еще меньше времени для автоматизации в этой итерации, в результате чего автоматизируется еще меньше тестов, еще больше спихивая ее в будущее и т. Чрезвычайно важно в случае регулярных доработок ПО проводить регрессионное тестирование системы, что позволяет исключить потери функционала системы.
Автоматизация — это единственное, что может смягчить удушающее бремя регрессии и избежать резкого падения скорости разработки. Каждый раз, когда история завершена, она не только должна быть проверена, но и все ранее завершенные истории должны, в некоторой степени, быть проверены повторно. Ручная регрессия не может масштабироваться с увеличенной скоростью доставки Agile. Предположим, у нас есть недавно созданная Agile-команда, которая только начинает свою первую итерацию разработки (спринт). На первой итерации (или некоторой начальной продолжительности в потоковой модели) у нас может быть три истории для тестирования.
Регрессионные тесты не всегда выявляют все возможные ошибки. Проблемы иногда возникают из-за несогласованности параметров локального контекста (например, часовых поясов) или специфики оборудования (скажем, результатов операций с плавающей точкой). При разработке приложений PostgreSQL обязательно проводите собственное тестирование. «ОК», — говорит скрам мастер, — «как насчет…», и вы точно знаете, что будет дальше. «…как насчет того, чтобы мы передвинули автоматизацию на следующий спринт? » Автоматизация, стоящая непосредственно перед отметкой «выполнено», заложенная в историю и всегда занимающая часть оцененного времени, выталкивается в будущее.
Я твердо убежден в том, что без полной автоматизации тестирования не может быть здоровой Agile Delivery. Полная автоматизация историй с набором средств автоматизации, охватывающим все виды тестов (модуль, компонент, интеграция, пользовательский интерфейс и т. д.), абсолютно необходима для поддержания скорости доставки на протяжении всего жизненного цикла. Любое предложение о послаблении этого требования для каждой истории следует отвергать и объяснять, что это такое — краткосрочное отвлечение для создания восприятия успеха, в то же время ставящее под угрозу долгосрочные цели развития. Зачастую правообладатели или менеджеры утверждают, что автоматизацию тестирования следует полностью игнорировать, перенаправив 100% усилий по тестированию будущих спринтов на ручную регрессию. Гораздо чаще команды вынуждены принимать истории с частичной или достаточно хорошей автоматизацией. Выполнение этого требования все еще передает некоторый процент от общей стоимости регрессии в будущие спринты на ручное неавтоматическое тестирование.
«Мне это тоже не нравится…», — говорит ваш скрам-мастер, видя выражение вашего лица, — «…но сейчас наша скорость на виду, это очень важно, поскольку мы приближаемся к этому гигантскому майлстоуну — мы просто не можем не добить наши стори поинты». Отдел тестирования компании БСС – это слаженно работающая команда молодых специалистов. Инженеры по тестированию с опытом работы свыше 8 лет, большой опыт работы с зарубежными заказчиками, опыт работы в многонациональных командах. Наши сотрудники имеют сертификаты международного уровня ISTQB.
Вы, вероятно, можете уложиться в это время с тестированием, но успеть с автоматизацией будет нереально. Для сохранения и увеличения эффективности регрессионных тестовых сьютов их необходимо оптимизировать. Давайте рассмотрим простой гипотетический набор спринтов, чтобы прояснить, насколько быстро стоимость регрессии может отягощать скорость команды.
В данном виде тестирования акцент делается на тестировании новой функциональности, появившейся в конкретном выпуске программного продукта. Ещё один замечательный способ для поддержания эффективности регрессионного тестирования, чтобы иметь хороший механизм мониторинга функций, которые разрабатываются, и тестов, которые добавляются для того, чтобы проверить работоспособность этих функций. Это должно быть последовательным процессом, чтобы всегда можно было получить список реализованных фич и их покрытие тестами.
Очевидно, что это слишком упрощенная модель, поскольку она предполагает, что усилия, необходимые для регрессии ранее завершенной истории, эквивалентны проверке новой истории. Конечно, не все должно быть полностью регрессировано, и тестировать что-либо всегда легче во второй раз. Однако стоимость регрессии не равна нулю, и для сложного программного обеспечения она может A/B-тестирование приближаться к первоначальной стоимости тестирования. Попытка итеративной доставки без него — это все равно, что отправиться в дальнюю дорогу, но отказаться от остановок, потому что остановки замедляют вас. Топливо — фундаментальная часть автомобильного путешествия (на данный момент), так же, как автоматизация тестирования — фундаментальная часть Agile Delivery.
Наиболее объективные результаты тестирования можно получить при выполнении работ по проверке качества ПО независимой командой тестировщиков. Мы можем выполнить разовый регрессионный тестовый цикл для Вашего продукта по готовой документации, либо разработать тестовый план и проверить качество программного продукта. Периодическая очистка старых тестов является ещё одним большим подходом в поддержании в актуальном состоянии наборов тестовых сьютов для регрессии. При этом удаляемые тесты должны быть проанализированы на предмет пригодности к другому сьюту. Удаляться должны наименее критичные кейсы и кейсы, которые написаны для тестирования старого или неактуального состояния и поведения какого-либо метода или части системы.
Использование небольших отдельных историй может создать ложное чувство изоляции между изменениями кода в разных историях, подрывая при этом регрессионное тестирование. Да, пользовательские истории независимы, но под этими историями находится тот же взаимосвязанный код и тот же риск внесения непреднамеренных изменений. Неважно, насколько четко вы разделяете свои истории или насколько хорошо вы определяете критерии приемлемости, регрессионное тестирование так же необходимо в Agile-разработке, как и при разработке одной большой функции в каскадном процессе. Автоматизированное тестирование поможет уменьшить временные затраты на выполнение тестов. Мы поможем Вам выбрать способ автоматизации тестов, автоматизировать существующие тесты, либо разработать случаи использования и автоматизировать их для Вашей системы. Наличие автоматизированных тестов позволяет проводить тестирование функционала так часто, как Вы хотите, в тот момент, когда Вы пожелаете, независимо от наличия свободных инженеров по тестированию.
Регрессионное тестирование выполняется командой gmake check. Agile Delivery отходит от использования больших функций, определенных (даже более крупными) документами спецификаций, к пользовательским программист ios историям, каждая из которых представляет собой небольшую часть общего объема работ. Истории Agile независимо разрабатываются, тестируются, ревьюятся и утверждаются.
Как правило, для регрессионного тестирования используются тест кейсы, написанные на ранних стадиях разработки и тестирования. Это дает гарантию того, что изменения в новой версии приложения не повредили уже существующую функциональность. Рекомендуется делать автоматизацию регрессионных тестов, для ускорения последующего процесса тестирования и обнаружения дефектов на ранних стадиях разработки программного обеспечения.
Файлы, упоминаемые в листинге 2.9 (regression.diffs и regression.out), размещаются в подкаталоге src/test/regress каталога исходных текстов. Если исходные тексты PostgreSQL размещаются в каталоге /usr/local/src, то файлы результатов регрессионных тестов будут находиться в каталоге /usr/local/src/postgresql-[ версия ]/src/ test/regress. Утро четверга перед демонстрационным днем, и у вашей команды в разработке еще несколько историй. Разработчики заканчивают, и код должен быть готов к тестированию очень скоро.
К сожалению, важность автоматизации в Agile Delivery и последствия ее отсрочки уходят из виду многих правообладателей, специалистов по планированию, менеджеров и т. Для них автоматизация тестирования кажется требованием, которое в общем неплохо было бы иметь, но которым можно пренебречь, когда поджимают дедлайны. На утреннем стендапе разработчики говорят, что они уже вот-вот заканчивают. Вы знаете, что они пишут модульные и компонентные тесты в рамках процесса разработки, и вы уже выполнили с ними несколько прогонов фич, так что вы уверены, что получите качественный код. Тем не менее, в дополнение к тестированию истории, вам все равно придется завершать автоматизацией UI и API, проверять некоторые нефункциональные требования и провести специфическое тестирование работоспособности… И один день — это не так много времени на все это.
Автор: Александр Петров
Kadaka tee 177A,
Tel: +372 530 31181
Tel: +372 677 5662
info@drumsticks.ee
Restoran Kadaka teel
E-R 11-22
L-P 12-22
Pärnu Mnt. 36,
Tallinn
Tel: +372 591 90940
Tel: +372 600 8202
info@drumsticks.ee
Drumsticks Xpress
E-P 10-21
