что такое регресс в разработке
Что такое регрессионное тестирование?
Регрессионное тестирование — задача, с которой сталкивается каждый тестировщик. Ведь любой предмет после изменений в одном месте может начать ломаться в месте, где раньше работал исправно. То же самое касается и ПО, которое мы тестируем. В этой статье мы чуть-чуть подробнее рассмотрим этот вид тестирования и разберём готовую стратегию, которая поможет сэкономить время, и поддержать качество на нужном уровне.
Что это такое?
Для начала разберём 2 понятия:
Перепроверка (Retest, Defect Validation) — Процесс перепроверки упавших (failed) тестов, связанных с исправленным багом.
Регрессионное тестирование (Regression testing) — Тестирование уже протестированной программы,
проводящееся после модификации для уверенности в том, что процесс модификации не внес
или не активизировал ошибки в областях, не подвергавшихся изменениям. Проводится после
изменений в коде программного продукта или его окружении.
В чём разница?
Оба вида тестирования выполняются после любых изменений в коде продукта или его окружении.
Regression testing проверят ранее пройденные успешно тесты со статусом Passed c целью удостовериться, что изменения не поломали ранее рабочий функционал.
А зачем это делать?
Так получилось, что любое изменение в коде или окружении нашего приложения может вызвать совсем неожиданные последствия.
Нашу систему можно представить как сказку о репке.
И вот мы захотели убрать из истории собачку Жучку, чтобы сэкономить количество текста в сказке.
Как фикс, мы убрали её в моменте, где внучка позвала Жучку.
И вот оказалось, что дальше наша история ломается:
Так и получается регрессия, когда наш продукт из-за каких-то небольших изменений может очень серьёзно поломаться иногда даже в очень неожиданных местах.
Какие изменения могут повлечь за собой регрессию?
Изменения в коде:
Изменения в окружении:
В идеале, мы должны проводить регрессионное тестирование на каждой новой сборке либо раз в итерацию. Как правило, этот процесс отнимает очень много времени и заставляет грустить многих тестировщиков. Ведь каждый раз нужно проходить одни и те же действия, что делает работу крайне рутинной.
Поэтому регрессионные тесты являются одним из первых кандидатов на автоматизацию.
Как проводить регрессионное тестирование?
Время — это одно из главных наших ограничений.
Поэтому в зависимости от времени мы делаем либо полную регрессию (Complete regression), либо частичную (Partial Regression).
С полной регрессией, думаю, вопросов быть не должно. Мы просто выполняем все тесты, которые у нас есть.
А вот с частичной регрессией всё куда интереснее.
Как выбрать достаточное количество тест-кейсов из общего числа? Не будем же мы брать наугад?
Это, наверное, один из самых важных вопросов в тестировании.
Попробуем на него ответить.
Для выбора тестов мы будем опираться на 2 фактора:
Исходя из наличия времени, берём по одному пункту из каждого фактора в порядке значимости и выбираем тесты, которые им соответствуют.
Например, мы «кровь из носа» должны зарелизиться к определённой дате и у нас очень мало времени на регрессионное тестирование.
В таком случае, мы возьмём тесты, которые проверяют часто используемый функционал и места, где были изменения.
Если времени чуть больше, то берём ещё и часть нечасто используемого функционала и совмещаем с тестами из пункта 2 в Likelihood.
Таким образом, со стратегией регрессионного тестирования можно экспериментировать, добиваясь наилучшего для себя результата с доступными ресурсами.
Подытожим:
Retest — перепроверяет упавшие тесты после исправления дефектов.
Regression testing — проверяет ранее положительно пройденные тесты после любых изменений в коде, либо окружении приложения.
Retest & Regression testing нужно делать как можно чаще. Желательно на каждой сборке либо в каждой итерации.
Noveo
Оптимизация регрессионного тестирования в гибкой разработке
Спасибо тестировщику Noveo Анастасии за рубрику переводов о тестировании!
Регрессионное тестирование часто становится проблемным вопросом для менеджеров Agile-проектов. Этот вид тестирования несет в себе две основных трудности:
Чтобы решить эти проблемы, опытные продавцы услуг по тестированию ПО и QA-специалисты придерживаются определенных сбалансированных стратегий. Давайте исследуем некоторые из них.
Регрессионное тестирование в гибких проектах: как оптимизировать?
Существует три наиболее распространенных пути оптимизации регрессионного тестирования в гибкой разработке:
У каждого из них есть плюсы и минусы.
Двухуровневый подход
В соответствии с этим подходом команда тестировщиков делит регрессионные тесты на два цикла:
Тем не менее, этот подход не так прост, как кажется. Чтобы всё прошло успешно, требуется непрерывная коммуникация внутри команды. Общаясь с разработчиками, тестировщики получают полное представление о том, что было сделано в течение итерации, и обоснованно выбирают необходимый тип регрессионного тестирования. Еще один пункт, который следует учесть, это время, прошедшее с момента последней полной регрессии. Это может помочь в установлении графика регулярного полного регрессионного тестирования и проведении ряда тестов вне зависимости от изменений, которые были внесены в ходе итерации. Это поможет команде избежать утомительной полной регрессии после каждого спринта и сохранить приложение относительно “чистым” от багов в любой момент.
Приоритизация тестов: подход на основе оценки рисков
Согласно рискоориентированному подходу, команда тестировщиков выбирает тест-кейсы, покрывающие области приложения, в которые были внесены изменения в последних итерациях, и сортирует их по приоритету. Таким образом, время и силы на регрессию сокращаются.
В течение всего проекта подход, основанный на оценке рисков, может быть применен ко всему набору регрессионных тестов в гибком проекте. Тестировщики делят все тесты на три категории:
Таким образом, расстановка приоритетов помогает снизить время и усилия, затраченные на регрессионное тестирование, без ущерба качеству продукта. Однако этот подход может стать причиной некоторых проблем, так как команда тестировщиков ограничивается их собственными задачами и не видит всей картины. К счастью, есть еще одна стратегия, которая полностью соотносится с особенностями гибких проектов.
Приоритизация тестов: коллективный подход
Этот подход позволяет членам команды привнести свои знания и уникальный взгляд в регрессионное тестирование. В течение спринта команда разрабатывает т.н. “доску регрессии”, покрывающую все задачи, выполненные каждым ее членом. Каждый может внести небольшие изменения, основываясь на собственном опыте. Например, разработчик понимает, что недавно добавленная фича могла повлиять на профиль пользователя, и добавляет эту информацию на доску. Когда приходит время регрессионного тестирования, команда обращается к доске и распределяет время в соответствии с информацией на ней. Используя этот подход, команда применяет свои уникальные знания для формирования комплекта регрессионных проверок, что делает этот тип тестирования более эффективным и менее затратным по времени.
Кроме обоснованности и удобства, подходы с приоритизацией требуют внимания, так как они могут привести к техническим недоработкам, подрывающим реализацию проекта.
Осторожно: технические недоработки
Технические недостатки в гибкой разработке указывают на то, что нужно особенно постараться, чтобы закончить все незавершенные задачи, накопленные за спринт/спринты/жизненный цикл проекта. Как правило, недоработки возникают, когда команда решает починить баг “как-нибудь позже”. Иногда это имеет смысл: например, когда команда откладывает тестирование безопасности до момента, пока система не заработает более стабильно, возникает техническая недоработка. Но это обоснованный тактический шаг, продиктованный грамотным тайм-менеджментом.
Проблемы появляются, когда эти недостатки выходят из-под контроля. Дисциплинированная гибкая поставка (Disciplined Agile delivery, DAD) — фреймворк, который предлагает широкий диапазон шагов по эффективной работе с техническими недоработками. Удивительно, но постоянное гибкое регрессионное тестирование — один из них. Это возвращает нас к началу.
Итак, возможно ли оптимизировать гибкое регрессионное тестирование и в то же время контролировать техническую часть? Ответ на этот вопрос — автоматизация регрессионного тестирования, наша третья стратегия.
Автоматизированный подход
Автоматизированное регрессионное тестирование в гибкой среде — лучший способ разобраться с проблемами, которыми окружена регрессия. Автоматизация сокращает время на тестирование с дней до часов и избавляет инженера-тестировщика от утомительного прохождения одного теста снова и снова. Тем не менее, нужно с осторожностью подходить к внедрению регрессионных автотестов в гибкую разработку.
Правильно подобранный момент — первое, что нужно учесть при планировании автоматизации регрессионного тестирования. Лучше всего вводить автоматизацию на том этапе, когда проект уже достиг определенного уровня зрелости, и все главные изменения уже были внесены. На ранних итерациях в большинстве проектов происходят изменения в интерфейсе, пользовательских сценариях или логике, что увеличивает трудозатраты на тестирование (и ручное, и автоматизированное).
К тому же, автотесты, какими бы хорошими они ни были, не будут актуальными всегда. В гибкой разработке необходимо, чтобы наборы автоматизированных регрессионных тестов полностью отражали изменения и обновления в функциях приложения. Необходимо пересматривать тест-комплекты после каждого крупного релиза и удалять устаревшие кейсы, которые больше не помогают обеспечивать качество продукта.
Тем не менее, ручное тестирование должно сосуществовать даже с лучшими комплектами автотестов. Ручное регрессионное тестирование всегда проводится в первую очередь, так как автоматизированные тест-кейсы основываются на повторяющихся сценариях, которые стабильно выявляли баги в предыдущих итерациях. Эксперты рекомендуют проверять результаты регрессионных автотестов с помощью быстрого ручного смоук-тестирования, чтобы заблаговременно обнаружить ошибочные результаты.
Ориентированность на коммуникацию
Чтобы оптимизировать гибкое регрессионное тестирование, команде тестировщиков следует установить непрерывную коммуникацию с другими членами команды:
Это общепринятый фундамент для всех трех стратегий оптимизации регрессионного тестирования.
Подытоживая сказанное
Регрессионное тестирование в гибкой разработке напоминает горькую таблетку: неприятно, но необходимо для обеспечения качества продукта. К счастью, у команд тестировщиков Noveo в гибкой разработке есть множество стратегий, которые можно применить для оптимизации регрессии. Самые популярные из них — это двухуровневый подход, приоритизация тестов и автоматизация регрессии.
Команды обычно выбирают тот подход, что больше подходит им с точки зрения масштаба проекта, временных рамок, количества запланированных релизов и т.д. Тем не менее, у всех подходов есть общая основа — непрерывная коммуникация.
Если вы нашли ошибку, пожалуйста, выделите фрагмент текста и нажмите Ctrl+Enter.
Регресс в технологиях
Автор: Михаил Хазин
Опубликовано в N10(613) от 23.03.2009
Михаил Хазин
РЕГРЕСС ПОШЕЛ
Когда в конце 1990-х годов авторы теории кризиса вели сложные разговоры на тему «чем сердце успокоится», они страшно мучились из-за того, что не могли понять, какие именно процессы определяют базовое движение экономики в нынешней ситуации. На ум лезла и инфляция, и кредиты, и много чего еще: желающие могут сами поломать голову. Но, в конце концов, выработался некоторый консенсус, который состоял в том, что ключевым механизмом, определяющим развитие современных геоэкономических процессов, является мировое разделение труда.
Суть этой позиции (авторство которой принадлежит, быть может, наиболее выдающемуся экономисту современности Олегу Григорьеву) состоит в том, что технологическо.
Автор: Михаил Хазин
Опубликовано в N10(613) от 23.03.2009
Михаил Хазин
РЕГРЕСС ПОШЕЛ
Когда в конце 1990-х годов авторы теории кризиса вели сложные разговоры на тему «чем сердце успокоится», они страшно мучились из-за того, что не могли понять, какие именно процессы определяют базовое движение экономики в нынешней ситуации. На ум лезла и инфляция, и кредиты, и много чего еще: желающие могут сами поломать голову. Но, в конце концов, выработался некоторый консенсус, который состоял в том, что ключевым механизмом, определяющим развитие современных геоэкономических процессов, является мировое разделение труда.
Суть этой позиции (авторство которой принадлежит, быть может, наиболее выдающемуся экономисту современности Олегу Григорьеву) состоит в том, что технологическое развитие (которое в рамке парадигмы научно-технического прогресса сложилось еще в конце XVIII века) требует постоянного углубления процессов разделения труда, которые, в свою очередь, нуждаются в постоянном расширении рынков сбыта; в противном случае они не дают прироста производительности труда. Таким образом, последние 200—250 лет развитие мировой экономики происходило путем конкуренции все увеличивающихся зон «технологической самодостаточности» со своей «рыночной периферией» у каждой. Как и следует ожидать, на этой периферии происходили процессы унификации — технологической, культурной, юридической, политической и так далее. Иными словами, каждая такая зона становилась центром глобализации.
Но и специфика технологического развития выстраивалась под эти процессы: технологии развивались так, что для максимальной своей эффективности (и даже более того, просто для эффективности) они требовали увеличения рынков сбыта по сравнению со своими предшествующими аналогами.
Всего таких технологических центров в полном объеме, то есть со своими зонами глобализации, сложилось пять. Самая первая, британская, и четыре успешных проекта «догоняющего развития» — в хронологическом порядке: Германия, США, Япония и, наконец, СССР. Был еще проект неудачный, точнее, сознательно свернутый — Китай конца ХХ века, который последователи Мао Цзэдуна и Дэн Сяопина перевели из «догоняющего» формата во встраивание в систему единственного оставшегося мирового технологического центра.
Отметим, что повторить этот подвиг сегодня не под силу никому: процессы разделения труда зашли так далеко, что для того, чтобы окупиться, современные технологии требуют рынков сбыта в масштабе всей планеты. Но именно это обстоятельство и стало главной причиной начавшегося кризиса. Дело в том, что, как только технологические центры сталкивались с невозможностью дальнейшего расширения (а это происходило в истории до нынешнего момента как минимум дважды — в конце XIX века и в 70-е годы ХХ века), то они неминуемо обрушивались в кризис, причиной которого являлось падение эффективности капитала, который в нашей стране метко окрестили универсальным словом «застой». Начался он и сейчас — но если два предыдущих случая давали хотя бы теоретические возможности расширения за счет разрушения других центров, то сегодня это невозможно физически.
Дополнило проблему то, что после поражения (к сожалению для нас, так и не оформленного) в экономической войне с СССР, США в начале 1980-х годов начали политику «рейганомики», экономический смысл которой состоял в усилении нагрузки на имеющиеся рынки сбыта, уж коли расширение их на тот момент было невозможно. И это усиление, выраженное в мощном стимулировании спроса, сегодня дает о себе знать.
Но современные технологии окупаются только при очень крупных масштабах сбыта продукции. А значит, значительная их часть станет в посткризисных условиях нерентабельной, причем какие именно, сейчас сказать достаточно сложно, потому как соответствующих исследований никто не проводил. Но общая суть процесса останется: второе десятилетие XXI века (дай бог, чтобы на нем процесс и остановился) станет периодом сильного технологического регресса.
Это крайне неприятный и мрачный вывод (граждане нашей страны хорошо помнят, как мрачно и печально все это выглядит на практике), но, рассуждая о том, что ждет мир после окончания острой стадии кризиса, этот процесс не только нельзя игнорировать, его придется все время ставить во главу угла. В противном случае все попытки что-то сделать будут напоминать попытки поддержать российское производство легковых автомобилей: без радикальной смены модели менеджмента все будет ограничиваться повышением цен на продукцию АвтоВАЗа и ростом издержек. Старая модель управления в новых условиях работать не будет.
Александр Александров про тренды и технологии тестирования, про влияние Covid19 на рынок QA
Онлайн-тренинги
Что пишут в блогах (EN)
Blogposts:
Разделы портала
Про инструменты
Автор: Майкл Болтон (MichaelBolton)
Оригинал статьи
Перевод: Ольга Алифанова
Тестировщик из «Agile»-команды жалуется на объем регрессионного тестирования, который, по его словам, должен выполняться в конце каждого скрипта.
Почему ряд компаний, разрабатывающих ПО, так зациклен на регрессионном тестировании? Нет, не почему они это делают (это может быть разумным), а почему они зациклены на нем. У меня есть теория на этот счет.
Очевидно, что любое изменение в продукте или системе несет риск проблем, которые могут в какой-то степени ухудшить качество. Это регресс – откат назад к предположительно менее продвинутому состоянию. Регресс – антоним прогресса.
Изменения несут риск регресса, поэтому разумно сосредоточить часть тестирования на этом риске. Но разве тестирование – это безотказный, надежный способ решить вопрос с риском регресса?
Безотказный? Нет. Тестирование, безусловно, помогает находить баги, чтобы баги были признаны и исправлены. Но неважно, насколько тщательно тестирование и насколько рано оно стартует – тестирование тоже может пропустить баги. Поэтому давайте помнить о том, что самый легкий для нахождения баг – это тот, кому вообще не дали вылупиться, а следующий по простоте – тот, который уничтожен до того, как он зарылся в массу кода.
Неважно, насколько опытное и мощное у вас тестирование – до какой-то степени нахождение бага зависит от удачи. Имея дело с риском регресса, не стоит оставлять все на откуп шанса – лучше начать с меньшего количества багов, чтобы снизить нашу зависимость от удачи. Следовательно, неплохая идея – чтобы вносящие изменения люди избегали багов, работая осторожно и дисциплинированно.
Дисциплина, говорит Чемберс, это «1. Тренировка, рассчитанная на развитие самоконтроля и упорядоченный образ жизни, 2. Состояние самоконтроля, приобретенное путем такой тренировки». Идея самоконтроля предполагает идею агентности, которая очень важна для исследовательской работы – которая, в свою очередь, важна для инженерной работы.
В зависимости от продукта, проекта, предпочтений конкретного разработчика и команды разработки, что можно увидеть и услышать, когда они дисциплинированно работают? Попробуйте сделать паузу и вспомнить ситуацию, когда лично вы наблюдали, как люди работают, с вашей точки зрения, дисциплинированно.
Как выглядит ваш список? Вот что время от времени слышал и видел я, наблюдая за работой, которую я считаю дисциплинированной:
Все эти идеи и практики я видел вживую – люди применяли их, чтобы быть в курсе всего происходящего в разработке. Большая часть (или все) применялись разработчиками в тандеме с теми, кто работает близко к ним (некоторые из них могут быть тестировщиками, а некоторые нет).
Каждый элемент списка повышает дисциплину процесса разработки. Каждый из них представляет из себя что-то из подразумеваемого говорящими о некоем «встроенном качестве». Это эвристики, а не правила. Никто не занимается абсолютно всем из перечисленного. Уверен, что вы делали много такого, что в списке отсутствует. Заметьте также, что каждый элемент списка может демонстрировать дисциплину в одном контексте, а ее полное отсутствие – в другом.
Дисциплина не обязана быть тяжкой, бюрократичной, или вообще что-то замедлять. Неформальные действия могут поддерживать дисциплину и помочь выяснить, где ее надо применить. Помните, что согласно Чемберсу дисциплина – это «самоконтроль с целью достижения упорядоченного образа жизни». «Самоконтроль» подразумевает, что дисциплина идет изнутри, а не навязана извне.
Некоторые формы дисциплины могут поначалу казаться медленными, но аккуратное вождение тоже кажется медленным тем, кто привык кататься агрессивно. Когда мы ведем машину, мы почти всегда едем медленнее, чем могли бы ехать. Более быстрое вождение приведет к тому, что мы опоздаем – или вообще не приедем.
Некоторая связанная с дисциплиной деятельность представляет из себя какую-либо форму тестирования, а некоторая – нет. Однако процессы создания продукта очень отличаются от процесса работы с продуктом. Баги, особенно связанные с работой, могут сбежать даже от очень дисциплинированных разработчиков. Следовательно, имеет смысл располагать разными видами тестирования – тестированием продукта в ходе разработки, и тестированием работы с готовым продуктом.
Поэтому, когда билды уже доступны, возможно, разумно периодически тестировать поглубже, и часть этого тестирования будет сосредоточена на потенциальных, разумно предсказуемых нежелательных эффектах и побочных эффектах изменения – на риске регресса. Такое регрессионное тестирование куда лучше сфокусировано, когда продукт аккуратно построен и уже в какой-то степени протестирован.
Глубокое тестирование не нужно каждому билду, да и не должно быть нужным. Во множестве случаев это просто невозможно. Тестирование с целью поиска скрытых, редких, неочевидных, плавающих, внезапных багов занимает время – и это время прервет или замедлит разработку. Подготовка данных и инструментов для глубокого тестирования тоже может занять много времени. В системах со сложными взаимодействиями проблемы возникают в интерфейсах между тем, что по отдельности отлично работало. Проработка этих взаимодействий и их изучение с целью поиска проблем может занять много времени. Это время стоит того, когда под вопросом безопасность, здоровье или финансы. Если команда дисциплинирована, то выгода от глубокого тестирования билда превосходит риск пропуска нескольких хорошо проконтролированных билдов.
Глубокому тестированию может помочь критическая дистанция – когда тестирование проводится людьми, находящимися на некоторой критической и даже социальной дистанции от людей, вносящих изменения. Риск тут будет большим решающим фактором – включая риск регресса.
И вот в чем подвох – во множестве организаций люди не санкционируют, не поощряют и не делают дисциплинированную работу, или же они внедряют дисциплину поверхностно, выбирая одну или две вещи из вышеперечисленного, игнорируя все прочее. В таких компаниях целью разработчиков кажется создание кода, а вовсе не создание работающего кода.
Но, возможно, из-за подсознательной боязни риска регресса менеджеры (и зачастую тестировщики) стремятся выполнить неимоверное количество дорогостоящей работы: они сидят за клавиатурой и повторяют все-все-все заскриптованные тест-процедуры, которые выполнялись ранее, как можно быстрее. Если спросить, а зачем, они часто отвечают «потому что разработчики понятия не имеют, что могло затронуть это изменение». Затем некоторые из них начинают превращать эти процедуры в автоматизированные процедуры, и они получают еще один недисциплинированный проект по разработке, и еще один кошмар для поддержки. И их заваливает работой все больше и больше.
Если кто-то чувствует, что не справляется – это знак, что, возможно, происходит нечто такое, с чем справиться нельзя.
Если разработчики действительно понятия не имеют, на что влияет изменение – это проблема, с которой компания должна поработать. Это похоже на принцип «не надо пытаться автоматизировать процесс, который вы не понимаете» – работая с чем-то важным, не надо бежать менять его, пока и если у вас нет достаточно хорошего представления о масштабах, эффекте и рисках изменения и о том, как с ними управляться.
А тут возникает проблема тестировщиков. Тестировщики не проектируют, не пишут и не исправляют код. Многие не обладают значительным опытом программирования, а те немногие, кто в этом разбирается, почти никогда не писали продакшн-код. Тестировщики не управляют проектом, и немногие из них бывали на месте проектных менеджеров. Тестировщики не управляют разработчиками. В связи с этим неправильно, с моей точки зрения, указывать разработчикам и менеджерам, как им выполнять свою работу. Тестировщики не могут и не должны навязывать или настаивать на дисциплине.
Однако для тестировщиков довольно разумно сообщать о проблемах с продуктом. Разумно выявлять паттерны проблем, связанные с определенными областями покрытия или критериями качества. Разумно сообщать о паттернах проблем, связанных с регрессом.
Не менее разумно сообщать о том, на что потрачено время тестирования. Если большую часть этого времени занимает исследование и отчетность о поверхностных багах, то тест-покрытие продукта будет недостаточно тщательным – разработчики и менеджеры должны об этом знать. Если проработка и поддержка автоматизированных проверок мешает тестировщикам получить критичный опыт работы с продуктом, об этом надо говорить – эта работа помешает тестировщикам глубоко изучить продукт и проводить новые эксперименты. То, что замедляет и усложняет тестирование, позволяет глубоким и, возможно, более опасным багам прятаться и выживать.
Поэтому тестировщики должны уметь анализировать и описывать состояние продукта, состояние тестирования, и его качество – включая проблемы, угрожающие чему-то из этой тройки. По ощущениям, менеджеры и разработчики зачастую не в курсе проблем с просевшей дисциплиной. Тестировщики не должны пытаться управлять проектом, но они могут пролить свет на проблемы.
Навязчивая идея регресс-тестирования – это намек на то, что в процессе что-то не так. Конечно, некоторое тестирование после внедрения изменений – неплохая идея. Но намного дешевле тестировать после изменения, когда люди тестировали во время изменения.
Дисциплина – это эвристика для снижения риска регресса и нужды в регрессионном тестировании. Когда люди применяют дисциплину, эффекты изменения известны лучше, код становится чище, обратная связь – быстрее, а риски – ниже, и глубокое тестирование может сосредоточиться на риске быстрее, дешевле и глубже, помогая найти значимые скрытые проблемы.