Regression testing что это
Регрессионное Тестирование (Regression Testing)
Ты хочешь понять, что такое регрессионное тестирование, зачем оно нужно, почему про него говорят все тестировщики и при чем здесь автоматизация?
Тогда ты в правильном месте 🙂
В этой статье отвечаю на самые частые вопросы, связанные с этим типом тестирования.
Как обычно, начинаем с определений.
Что такое регрессионное тестирование?
Регрессионное тестирование (regression testing) это проверки ранее протестированной программы, выполняющиеся после изменения кода программы и/или ее окружения для получения уверенности в том, что новая версия программы не содержит дефектов в областях, не подвергавшихся изменениям.
Regression testing — testing of a previously tested program following modification to ensure that defects have not been introduced or uncovered in unchanged areas of the software, as a result of the changes made. It is performed when the software or its environment is changed. [ISTQB Glossary]
Regression Testing является одним из двух видов тестирования, связанных с изменениями. [ISTQB FL]
Зачем нужно регрессионное тестирование?
Регрессионное тестирование необходимо для получения уверенности, что изменения ПО не коснулись и не сломали другие, не измененные, части ПО.
Здесь возникает вопрос: “Каким образом изменения одной части ПО могут сломать другие?”
Ответ: это загадка природы 🙂
В мире не бывает идеальных вещей и все мы ошибаемся. ПО и программисты — не исключение.
Иногда, непреднамеренно, разработчик делая исправление в коде может повлиять на части приложения, о которых он никогда не слышал и не представлял, что они существуют и связаны каким-то образом.
Особенно часто эта проблема проявляется в проектах с низким уровнем качества кода, плохой архитектурой и большим техническим долгом.
Фредерик Брукс в своей книге «Мифический человеко-месяц» (1975) писал: «Фундаментальная проблема при сопровождении программ состоит в том, что исправление одной ошибки с большой вероятностью (20–50%) влечёт появление новой». [Куликов С., Базовый курс, 3-е издание]
Можно предположить, что в наше время вероятность появления ошибки — значительно меньше 20-50%, так как программы и среда разработки 1975 года сильно отличаются от современных.
Но, тем не менее, даже сегодня вероятность ошибки точно больше 0%.
Поэтому, регрессионное тестирование является ключевым инструментом обеспечения качества и должно использоваться практически на любом проекте.
Когда проводят регрессионное тестирование?
Регрессионное тестирование проводится после изменения кода программы (добавили / удалили / изменили) или изменения рабочего окружения (обновили версию PHP / Node JS / Java / Ubuntu / Windows / MySQL / MongoDB / переехали на новые сервера и т.п.)
Стоит отметить, что регрессионные тесты не нужно проводить после каждого изменения!
Например, вы изменили дату в футере сайта.
Нужно ли нам проходить 350 тест-кейсов и перепроверять весь сайт? — конечно же нет! Вы потратите свое время зря)
Такие исправления можно протестировать за 10 секунд используя самый простой чек-лист или сделав code review.
Если же такие исправления “ложат” / “ломают” сайт — вам срочно нужно задуматься о профессионализме разработчиков, это не нормально!
Или, другой пример. На одном из полей формы изменяется правило валидации: до этого максимальная длина строки равнялась 20 символам, а теперь нужно сделать 16.
Зачем после такой правки перепроверять весь сайт? (Вы не поверите, но существуют компании и команды, который до сих пор этим занимаются…)
Единственное, что нужно проверить — валидацию конкретно этого поля и, возможно, валидацию такого же поля на других формах (если они вообще существуют)
Если после изменения длины одного поля изменились правила валидации всех полей на сайте — поздравляю, у вас большие проблемы с профессионализмом разработчиков.
Вместо того, чтоб постоянно выполнять бесполезные проверки, лучше нанять более профессионального кодера. Через 2 месяца вы начнете экономить кучу денег.
При принятии решения о необходимости повторного тестирования вспоминаем принципы тестирования и задаем себе вопрос: ЧТО нам нужно проверять после этих изменений?
Какие плюсы регрессионного тестирования?
К плюсам можно отнести:
Выполнение повторного тестирования необходимо для анализа и улучшения качества продукта и рабочих процессов, чем, кстати, и занимаются настоящие QA Engineers.
Какие минусы регрессионного тестирования?
К минусам можно отнести:
Пытаясь бороться с описанными выше минусами многие компании автоматизируют регрессионные проверки 🙂
Но, решает ли автоматизация эти проблемы? Или только усугубляет? Давайте разбираться…
Автоматизация и regression testing
Регрессионные тесты выполняются много раз и обычно проходят медленно, поэтому такие тесты — это серьезный кандидат на автоматизацию. [ISTQB FL]
На первый взгляд — выглядит логично. Но давайте посмотрим немного “глубже”.
Предположим, у нас есть небольшой проект и 50 тест-кейсов. Мы, после очередного видео / доклада — “Автоматизируй все!” — решаем их автоматизировать 🙂
Через 2 недели все готово: тесты проходят, все зеленое — класс, у нас авто-тесты, Agile и CI! (в видео сказали, что будет так)
Проходит 2 года. Количество тест-кейсов увеличилось в 20 раз, до 1,000. Иии…
Сравнение теоретического “до” и “после”:
Решили ли мы проблемы, описанные выше? — нет.
Возможно, рутины стало чуть меньше. Но остальное — никуда не пропало + появилось новое:
Теоретически, мы можем уменьшить время прогона, купив более мощные сервера, или подняв кластер (привет новый DevOps), но это сделает затраты еще большими…
И здесь появиться финансовый вопрос — а не дешевле ли нам иметь 5 джунов, которые будут проходить регрессионные тест-кейсы изо дня в день, за те же 100 минут? (Знакомо, да? Мы вернулись туда, откуда начали)
Парадокс автоматизации? Наверное, можно так сказать 🙂
Пытаясь уменьшить затраты — мы сделали их еще больше!
Давайте вспомним, что регрессионные тесты — это серьезный кандидат на автоматизацию.
Поэтому, учитывая все, написанное выше, мы можем предложить решение проблем и сделать следующие выводы:
Все эти проблемы решаются только настоящими специалистами, включая QA лидов, автоматизаторов и DevOps инженеров.
Поэтому в следующий раз хорошенько подумай, перед тем, как “автоматизировать все”.
И помни, что работа любого специалиста должна быть направлена на повышение эффективности работы и качества продуктов компании, а не на увеличение ее финансовых затрат!
Псс.. Несколько инструментов тестировщика, которые точно помогут тебе стать более эффективными, без автоматизации)
Резюме
В статье мы детально ознакомились с одним из типов тестирования, связанного с изменениями, а именно регрессионным тестированием.
Мы узнали что это такое, зачем оно необходимо, какие у него «плюсы» и «минусы», и что нам “готовит” автоматизация таких тест-кейсов.
Если у тебя есть вопросы / предложения / замечания — пиши нам!)
Если тебе интересна эта тема, и ты хочешь получать актуальную информацию о тестировании — подписывайся на наш Телеграм канал, там интересно: статьи, тесты, опросы, нет спама! 🙂
В чём разница Smoke, Sanity, Regression, Re-test и как их различать?
Оригинал. Перевод разбавлен размышлениями и дополнениями автора из своего опыта
О чём это всё
Будучи инженером по тестированию, вы, вероятно, слышали о таких видах тестирования как «дымовое» (smoke), «санитарное тестирование» (sanity), «ре-тест» и регрессионное тестирование. Вполне возможно, многие из этих видов используются вами на ежедневной основе.
В этой статье я хотел бы внести ясность и объяснить разницу между этими видами тестирования и попробовать разобраться, провести границы (хоть и условные) где заканчивается один вид тестирования, и начинается другой.
Для новичков в тестировании (и даже опытных тестировщиков) разделение этих понятий может быть затруднительно. И в самом деле, как отличить где начинается санити-тестирование и заканчивается smoke? Насколько сильно нам надо ограничить проверку части функциональности системы или её компонентов, чтобы назвать это «дымовым» тестированием? Является ли ввод логина/пароля в пользовательскую форму входа на сайт дымовым тестом, или сам факт её появления на странице сайта уже является пройденным тестом?
Строго говоря, вы всё равно сможете проводить тестирование, даже при том что не сможете точно сказать, в чём же разница. Можно даже не задумываться о разграничении, каким именно видом тестирования вы сейчас заняты. Но всё же, чтобы расти над собой в профессиональном смысле, нужно знать что вы делаете, зачем, и насколько правильно вы это делаете.
Ликбез
Ниже приведены краткие определения видов тестирования, которые мы сегодня сравниваем:
Ну а по существу?
Приведу пример разграничения понятий на моём текущем проекте.
Пример: у нас есть веб-сервис с пользовательским интерфейсом и RESTful API. Будучи тестировщиками, мы знаем:
Подведём итог
Надеюсь, что после чтения данной статьи, у вас появится ясность в определении какой вид тестирования вы используете на каком этапе, и в чём разница между этими видами тестирования. Как и было упомянуто вначале, граница между этими понятиями весьма условная и остаётся на ваше усмотрение в рамках проекта.
UPD:
Часто «тестирование согласованности» или «тестированием на вменяемость», называют термином «санитарное тестирование». Думаю что это пошло из-за фонетических свойств английского слова sanity, схожего по звучанию с чем-то «санитарным». Гугл транслейт вносит ясность. В интернете встречаются оба варианта. Относительно данной статьи прошу считать «санитарное» тестирование как «тестирование на согласованность».
Регрессионное тестирование
Из Википедии — свободной энциклопедии
Регрессио́нное тести́рование (англ. regression testing ← лат. regressio «движение назад, возврат, отход») — собирательное название для всех видов тестирования программного обеспечения, направленных на обнаружение ошибок в уже протестированных участках исходного кода. Такие ошибки — когда после внесения изменений в программу перестаёт работать то, что должно было продолжать работать, — называют регрессионными ошибками (англ. regression bugs ).
Регрессионное тестирование (по некоторым [ каким? ] источникам) включает new bug-fix — проверка исправления вновь найденного дефекта, old bug-fix — проверка, что исправленный ранее и верифицированный дефект не воспроизводится в системе снова, а также side-effect — проверка того, что не нарушилась работоспособность работающей ранее функциональности, если её код мог быть затронут при исправлении некоторых дефектов в другой функциональности. Обычно используемые методы регрессионного тестирования включают повторные прогоны предыдущих тестов, а также проверки, не попали ли регрессионные ошибки в очередную версию в результате слияния кода.
Из опыта разработки ПО известно, что повторное появление одних и тех же ошибок — случай достаточно частый. Иногда это происходит из-за слабой техники управления версиями или по причине человеческой ошибки при работе с системой управления версиями. Но настолько же часто решение проблемы бывает «недолго живущим»: после следующего изменения в программе решение перестаёт работать. И наконец, при переписывании какой-либо части кода часто всплывают те же ошибки, что были в предыдущей реализации.
Поэтому считается хорошей практикой при исправлении ошибки создать тест на неё и регулярно прогонять его при последующих изменениях программы. Хотя регрессионное тестирование может быть выполнено и вручную, но чаще всего это делается с помощью специализированных программ, позволяющих выполнять все регрессионные тесты автоматически. В некоторых проектах даже используются инструменты для автоматического прогона регрессионных тестов через заданный интервал времени. Обычно это выполняется после каждой удачной компиляции (в небольших проектах) либо каждую ночь или каждую неделю.
Регрессионное тестирование является неотъемлемой частью экстремального программирования. В этой методологии проектная документация заменяется на расширяемое, повторяемое и автоматизированное тестирование всего программного пакета на каждой стадии процесса разработки программного обеспечения.
Регрессионное тестирование — это что, где и зачем оно используется?
Регрессионное тестирование — это дополнительный способ проверить программу, которая раньше уже прошла удачное тестирование. Регрессионное тестирование проводят в том случае, когда в уже протестированной программе были выполнены какие-либо изменения или исправления ошибок. Его цель — выявить и удостовериться, что внесенные в программ у изменения никак не коснулись тех частей программ, которые остались без изменений.
Регрессионное тестирование
Когда проводят регрессионное тестирование
Преимущества и недостатки регрессионного тестирования
В качестве преимуществ можно отметить:
В качестве недостатков можно отметить:
Заключение
Регрессионное тестирование — это дополнительный гарант качества вашего программного продукта. Основная масса подобных тестов проходит «вручную», потому что, как ни странно, очень часто автоматизация регрессионного тестирования приводит к дополнительным финансовым затратам. В итоге получается, что проводить такие тесты дешевле руками молодых тестировщиков, чем автоматизированными решениями профессионалов тестирования.
Мы будем очень благодарны
если под понравившемся материалом Вы нажмёте одну из кнопок социальных сетей и поделитесь с друзьями.
Автоматизированный подход к регрессионному тестированию
Здравствуйте, дорогие читатели. Сегодняшний материал мы хотели бы приурочить к запуску курса «Python QA Engineer». Предвещая возможные вопросы, предупреждаем, что в статье нет ни слова о Python, но все же мы считаем этот материал полезным для тестировщиков, поэтому и решили поделиться им с вами.
Тестирование каждой мельчайшей детали кода – вещь неосуществимая, поэтому регрессионное тестирование должно осуществлять комплексную проверку и фокусироваться на определенной области во всем ее объеме. Основной целью при этом является уверенность в том, что ни одна регрессионная ошибка не повредит критически важному бизнес-процессу. Именно это усилие и позволяет извлекать выгоду из автоматизации. Автоматизированный подход к тестированию, ориентированный на уменьшение регрессионных ошибок, поможет пройти долгий путь к выстраиванию хороших отношений с клиентами и повышению ценности бренда.
Моя команда отвечает за тестирование приложения для учета, которое использует сложные вычисления и заносит записи бухгалтерской книги в систему учета. Все это представляет из себя рабочий поток, и закрытие книг каждый месяц в нем является самым важным.
С каждым релизом происходят некоторое изменения в расчетах, например, для счета может понадобиться увеличить дебет или кредит, или же имеющееся значение может разделяться между двумя счетами. Такие изменения в комплексном приложении, имеющем множество внутренних и внешних зависимостей, часто приводят к непредсказуемому поведению, в том числе и к ошибкам регрессии, в неожиданных и, казалось бы, никак друг с другом не связанных, местах.
Давайте разберемся с регрессионной ошибкой, ее еще иногда называют критическим инцидентом или проблемой продакшена. Проработав несколько лет в индустрии программного обеспечения, вы понимаете, что регрессионная ошибка просочившаяся на продакшен гораздо важнее неправильно работающей новой функции. Дело в том, что новая функция все еще скрыта, поэтому при ее поломке влияние на бизнес-составляющую оказывается минимальным, тогда как при регрессионной ошибке, пользователь полагается на рабочую функцию и, скорее всего, не имеет резервного варианта рабочей системы.
Регрессионные ошибки вызваны изменениями, которые не были учтены project-менеджером или product owner’ом при приемочных тестах; архитектором, разработчиком во время code review на этапе проектирования или реализации; или же QA-аналитиком и тестировщиком в тестовых кейсах. Все сети безопасности пропустили ошибку и на нее наткнулся пользователь. Если ошибка в недавнем обновлении была выявлена на любом из вышеперечисленных этапов, т.е. командами, заинтересованными сторонами или любым другим звеном, которое присутствует в вашей организации, то ее рассмотрели до релиза или, как минимум, оценили на критичность.
Регрессионные ошибки влекут за собой несколько издержек: срочное исправление, штрафы за потенциальное нарушение соглашения об уровне обслуживания и, самое главное, они наносят ущерб доверию ваших пользователей к вашему продукту. Они могут решить, что новый релиз сломает что-то, что уже работает.
Моей команде стало важно проверять абсолютно все.
Однако хорошо известно, что это невозможно, или по крайней мере слишком дорого и отнимает много времени. Поэтому «тестирование всего» сконцентрировалось на следующих двух вещах: критические бизнес-процессы и уверенность в том, что поведение в основных критических бизнес-процессах будет таким же, как и в последнем релизе, до изменения. В общем, мы хотели убедиться, что в последнем релизе в критическом бизнес-процессе не появилась регрессионная ошибка.
Мы провели оценку наших типичных подходов к автоматизированному тестированию для проверки вычислений и проверку того, что вся логика описана в коде для автоматизации тестирования. Такой подход вызывал классический вопрос: «Кто тестирует код тестировщика?» Если тестовый кейс выполнялся неуспешно, оставалась такая же вероятность, что проблема была в коде тестировщика. Помимо этого, при каждом изменении в приложении тестовый код тоже нуждается в обновлении, а такие изменения случались часто.
Также благодаря автоматизированному тестированию мы убедились, что у нас есть фиксированный набор входов и уже известный набор выходов. Из-за сложности приложения было невозможно было подать все возможные наборы входных данных за раз. Также необходимы были различные наборы данных за конец месяца, квартал, год. Серьезной проблемой было расписание, поскольку, чтобы сгенерировать огромный набор входных данных и соответствующие скрипты, нужно много времени.
Была еще одна переменная: данные пользователя. У нас имелась особая привилегия: мы получали резервные копии пользовательских данных каждый месяц. Качество теста напрямую зависит от данных, используемых для проведения тестирования, а данные с продакшена всегда лучше, чем сгенерированные данные, поэтому наша привилегия была огромным преимуществом, которое мы не хотели упускать.
Выявление и реализация регрессионных тестов
Наш идея заключалась в том, чтобы использовать автоматизированное тестирования, которое нуждается в минимально необходимом обслуживании, и которое укрепляет уверенность заинтересованных сторон в том, что релиз будет надлежащего качества.
Итак, нам нужна была стратегия тестирования для критических бизнес-кейсов, которая гарантировала бы отсутствие регрессионных ошибок и, конечно же, которую мы могли бы быстро применить на практике.
Наш процесс подготовки выглядел так:
Такой подход обеспечивает две идентичные системы с различиями в коде всего в одну версию:
Иметь две системы довольно важно, поскольку это помогает понять, что любая проблема возникает только благодаря последним изменениям кода.
Тесты разделяются, таким образом от стандартного процесса «выполнить действие и получить реакцию» мы переходим к тому, что действия выполняются от одной точки к другой с сохранением рабочего потока, после этого происходит сравнение отчетов об ошибках. Это ключ к выявлению неожиданных ошибок.
Когда тестировщик фокусируется на новой функции или каком-то изменении, тест получается ориентированным конкретно на него, т.е. проверяется уместность конкретного изменения. Регрессионное тестирование отличается тем, что оно должно проверять, что ничего больше не претерпело изменений. Такое различие отражается в сценариях автоматизации. Оно делает сценарии тестирования конкретных функций непригодными для поиска регрессионных ошибок, поэтому здесь необходим другой подход.
Например, если вы работаете с системой управления заказами, вам понадобится скрипт для размещения заказов с множеством входных данных, чтобы размещать заказы на две установленные тестирующие системы (желательно, работающие параллельно), затем вы получаете отчет о заказах за прошедший день и сравниваете в них каждое значение. Затем все заказы подтверждаются или одобряются (это действие), а отчеты, такие как ежедневные подтвержденные заказы, заказы по номенклатуре, отчеты со склада, заказы с каждого перевозчика, тип отгрузки, тип платежа и т.д. будут сравниваться в двух системах. Так продолжается в течение всего рабочего процесса. Вы можете объединять действия, такие как размещение и подтверждение заказов, а затем сравнивать отчеты на отдельных этапах.
Другим примером может служить система управления гостиницей, в которой отдельные действия определяются как критические бизнес-процессы, такие как регистрация заезда, выставление счетов в ресторане и получение инвентаря. За всеми этими процессами будут закреплены свои собственные действия и отчеты. Разница в этой системе, по сравнению с предыдущим примером заключается в том, что наборы тестов могут выполняться параллельно, и нет необходимости завершать шаг, прежде чем начинать следующий.
Сравнение двух отчетов – это момент истины, и он должен быть безупречным, в том смысле, что ни у кого из заинтересованных сторон не должно быть сомнений в его правильности. Разница в отчетах – это настоящая разница.
Для этой операции мы используем интерфейс веб-сервиса. Все отправки отчетов выполняются параллельно на двух системах, в итоге сравнивается пришедший ответ в формате JSON.
Сравнение происходит по трем фронтам:
Такой способ будет работать для XML, XLS, CSV фиксированной ширины или любого другого формата. Нам нужно убедиться, что нет лишних записей, нет отсутствующих записей и все значения записей совпадают.
В этом заключается суть подхода, о котором мы говорим. Все это — информация доступная для чтения в приложении, которая оформляется как отчет или, в некоторых случаях, работающая в качестве интерфейса к другим приложениям.
Успех такого подхода заключается в инструменте сравнения или утилите, которая обрабатывает кейсы, относящиеся к вашему приложению. Вы можете считать себя счастливчиком, если найдете что-то подходящее «из коробки», в противном случае, важно понимать, что инвестиции в такой инструмент стоят того, поскольку они принесут хорошие плоды.
После всех разговоров об автоматизации необходимо вставить ремарку. Поскольку некоторые различия в отчетах ожидаемы, так как они должны быть там в соответствии с требованиями, все результаты также должны быть проанализированы вручную. Должны быть четкие успешные результаты прохождения тестовых кейсов, однако неудачные результаты также должны быть проанализированы и их валидность необходимо подтвердить. Так как мы говорим об ошибках регрессионного тестирования, они должны быть исправлены до релиза. Конечно, присутствуют и некоторые исключения, которые обрабатываются в соответствии с приложением.
Настройка программы
Все приложения разные, и установка и настройка их тоже происходит по-разному. Для подготовки приложения к тестированию могут потребоваться некоторые дополнительные шаги, поэтому их нужно учитывать в нужное время и в нужном месте выполнения тестов. Вот набор типичных шагов:
«Запутать» данные с продакшена, удалив e-mail идентификаторы или другую конфиденциальную информацию, или же заменить ее фиктивными данными;
Получить данные в надлежащем виде для запуска теста;
Адаптировать настройки для QA-среды, например, изменив интеграционные связи.
Единственный момент, о котором стоит помнить, это то, что перечисленные действия должны быть выполнены для обеих установок. Помните, что перед началом выполнения набора тестов, настройки должны быть идентичными.
Нередко действия, отличные от запроса отчета, могут возвращать объект, например, действие, такое как создание или изменение заказа, может вернуть новый объект заказа. В таком случае нужно сравнивать два объекта и не ждать сравнения отчетов. Это может помочь выявить ошибку на ранних этапах в самом корне.
Также рекомендуется разбить весь набор на более мелкие наборы, например, сгруппировав транзакции и связанные с ними отчеты вместе. Наборы можно запускать параллельно, чтобы сэкономить время выполнения. Однако для приложения с характерным рабочим потоком это сработает, только если вы сможете разделить кейсы по вертикали и по горизонтали или наоборот.
Вариации могут начинаться с технологий – JSON, XML или скейлеров (int/string/float), и расширяться до того момента, пока тестируемое приложение и продакшен будут реагировать различными структурами, но все еще соответствовать архитектуре. Например, продакшен-версия может использовать старый JAR файл, который оперирует определенным форматом, а в новой версии JAR файл был обновлен и теперь формат ответа изменился, поэтому их сравнение покажет несоответствия. Для того, чтобы их сравнить надлежащим образом понадобится временный плагин.
Таких ситуаций, вероятно, будет немного. В таких случаях иногда проще подправить дизайн или рассматривать их в контексте обходного пути.
Существует несколько вариантов обработки таких сравнений:
Игнорировать некоторые поля, такие как идентификаторы и даты;
Игнорировать числовые различия менее 0,0001;
Игнорировать чувствительность к регистру;
Структурировать изменения в два ответа.
Улучшение регрессионного тестирования
Регрессионное тестирование должно быть целостным и фокусироваться на целой области. Этот баланс поможет извлечь выгоду из автоматизации. Автоматизированный подход к тестированию поможет уменьшить количество регрессионных ошибок и поможет на пути к хорошим отношениям с клиентами и повышению стоимости бренда.
Теперь, в ритме постоянного движения вперед, наша команда хочет попробовать отказаться от двух идентичных установок системы, которыми мы пользуемся сейчас, и реализовать ту же стратегию на одной установке. Мы хотим сохранить ответы прошлых выполнений и использовать их для сравнения. Поход к тестированию всегда можно улучшить. Пожелайте нам в этом удачи!
Перевод подготовлен специально для студентов курса «Python QA Engineer».