какую тестовую документацию как правило используют при проведении регрессионного тестирования
Регрессионное Тестирование (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 инженеров.
Поэтому в следующий раз хорошенько подумай, перед тем, как “автоматизировать все”.
И помни, что работа любого специалиста должна быть направлена на повышение эффективности работы и качества продуктов компании, а не на увеличение ее финансовых затрат!
Псс.. Несколько инструментов тестировщика, которые точно помогут тебе стать более эффективными, без автоматизации)
Резюме
В статье мы детально ознакомились с одним из типов тестирования, связанного с изменениями, а именно регрессионным тестированием.
Мы узнали что это такое, зачем оно необходимо, какие у него «плюсы» и «минусы», и что нам “готовит” автоматизация таких тест-кейсов.
Если у тебя есть вопросы / предложения / замечания — пиши нам!)
Если тебе интересна эта тема, и ты хочешь получать актуальную информацию о тестировании — подписывайся на наш Телеграм канал, там интересно: статьи, тесты, опросы, нет спама! 🙂
Регрессионное тестирование на Scrum-проектах: руководство по проведению
Согласно отчету The State of Agile Report («О развитии методологии Agile»), 95% опрошенных компаний разрабатывают программное обеспечение по Agile.
Во-первых, гибкая методология позволяет выпускать качественный продукт быстрее конкурентов за счет тестирования в каждом спринте. Во-вторых, с ее помощью можно легко внести изменения в ПО благодаря тесной коммуникации между заказчиком и участниками проекта.
При этом тесты регрессии остаются одними из наиболее частых проверок перед релизом новой функциональности. Как выполнять их эффективно, особенно если время на тестирование ограничено всего одним спринтом, зачастую составляющим 2 недели? Что делать, если нужно внести изменения в функциональность продукта на поздней стадии спринта?
В этой статье мы ответим на эти вопросы, а также расскажем о том, как проводить регрессионное тестирование на Scrum-проектах и уверенно преодолевать возникающие сложности.
Регрессионное тестирование в Scrum-среде
Регрессионные проверки играют одну из ключевых ролей в тестировании полного цикла и помогают добиваться следующих целей:
повышать общее качество и стабильность ПО благодаря снижению вероятности критических ошибок при его использовании и многократному уменьшению числа дефектов к моменту релиза;
ускорять доставку решения на рынок, уменьшая время прогона тестов за счет автоматизации;
сокращать расходы на подготовку продукта к релизу с помощью раннего обнаружения дефектов и применения автоматизации.
На Scrum-проектах регрессионные проверки особенно важны, поскольку помогают командам сконцентрироваться на новой функциональности, обеспечив при этом корректную и непрерывную работу ПО с каждым новым инкрементом продукта.
Таким образом, QA-специалисты могут быть уверены в том, что доработки никак не повлияли на уже существующую функциональность.
Топ-5 распространенных проблем и способы их преоделения
При проведении регрессионного тестирования на Scrum-проектах важно сфокусироваться на двух аспектах.
Первый ― определить функциональность, затронутую изменениями в коде. Если это неочевидно, необходимо проверять всю функциональность и соответственно раньше начинать тестирование в спринте, чтобы уложиться в сроки. Однако если можно безошибочно установить затронутые изменениями модули, работа станет более таргетированной, что сократит время на QA.
Второй ― выбрать проверки, которые можно автоматизировать. Важно помнить, что использовать автоматизацию уместно не во всех случаях. Особенно это касается GUI-проверок, где малейшие правки в дизайне приложения приводит к пересмотру тест-кейса с нуля.
Автоматизированные проверки подойдут для более стабильной функциональности, которая изменяется редко. А при нехватке времени поможет проактивный подход. Например, разработчики, инженеры по автоматизированному и функциональному тестированию работают над новой функциональностью в параллели и покрывают всё автоматизированными тестами в ходе одного спринта.
Но даже при должном понимании влияния изменившихся функций на приложение в целом и объема автоматизации, Scrum-команды могут столкнуться с рядом сложностей. Давайте перечислим их и рассмотрим, как можно решить.
Возрастающий объем регрессии
На крупных проектах с каждым новым спринтом объем регрессионного тестирования может увеличиваться. Чтобы эффективно им управлять, важно пересматривать тест-кейсы и удалять устаревшие. Делать это стоит по возможности и в зависимости от частоты вмешательства в релизы. Кроме того, это первый звонок, что уже можно и нужно внедрять автоматизацию.
Недостаточная коммуникация между участниками проекта
Специалистам по тестированию, бизнес-аналитикам, разработчикам и руководителям проекта стоит непрерывно взаимодействовать друг с другом. Так они смогут лучше понять объем работ и обеспечить эффективность процесса, начиная с подготовки тестовой документации и заканчивая пониманием того, какая функциональность больше не нуждается в регрессионном тестировании.
Поддержка тестовых сценариев
С увеличением числа тест-кейсов, будь то автоматизированные или функциональные, их поддержка усложняется. Чтобы минимизировать их обслуживание, важно больше коммуницировать с бизнес-аналитиками, которые знают взаимосвязи в бизнес-логике продукта и могут выявить несоответствия в тест-кейсах в случае внесения изменений.
Частые доработки функциональности
Смоделируем ситуацию: на проекте возникли непредвиденные и объемные изменения в требованиях к функциональности продукта. Еще и в конце спринта. Что делать? Да, сроки имеют значение, но важно позаботиться о качестве и оценить, сколько времени займет перезапуск тестов с учетом входной информации, чтобы расширить спринт и перенести дату релиза.
Ложноположительные результаты тестов
Причина может заключаться в некорректной разработке автоматизированного тест-кейса. Исключить подобную вероятность поможет валидация инженером по функциональному тестированию, который проходит тест-кейс по шагам и проверяет соответствие ожидаемому результату. Кроме того, в спринтах стоит закладывать время на интуитивное (ad hoc) и исследовательское (exploratory) тестирование, чтобы максимально расширить тестовое покрытие.
Тестируем регрессию на Scrum-проекте: о чем важно помнить
Для эффективного проведения регрессионного тестирования на гибких проектах важно приступать к созданию тестовой документации еще в самом начале разработки и в дальнейшем непрерывно обновлять ее в зависимости от входящих требований.
Что еще нужно учитывать? Предлагаем рассмотреть 5 шагов, от которых напрямую зависит результативность регрессионного тестирования.
1. Подготовить план тестирования
Этот этап включает в себя подбор необходимых тест-кейсов, их дальнейшее улучшение и доработку, оценку времени создания и выполнения регрессионных тестов, валидации дефектов и разработки финального отчета. Важно также определить тест-кейсы, которые в дальнейшем можно будет автоматизировать. Кроме того, на начальном этапе работ при взаимодействии с разработчиками проводится анализ того, какие модули могут быть затронуты изменениями, чтобы уделить этим областям больше внимания при тестировании.
2. Создать доску регрессии
Все задачи, над которыми работают QA-инженеры Scrum-команды, располагаются на доске в порядке сверху вниз по приоритетности в зависимости от возможных рисков, важности для клиента и ряда других факторов. Переставляя элементы на доске, команда всегда будет понимать актуальность задач и сможет планировать свое время так, чтобы укладываться в сроки.
3. Анализировать отчеты о дефектах
Так QA-команда сможет получить подробную информацию о проведении регрессионных тестов: причины их невыполнения, шаги тест-кейса, на которых произошла ошибка, снимки экрана. Все это поможет быстрее выявить проблему и устранить ее.
4. Добавить исследовательское тестирование
С его помощью инженеры по тестированию по-новому взглянут на проект, расширят тестовое покрытие и обнаружат дефекты, которые могли бы оказать сильное влияние на конечного пользователя разрабатываемого продукта.
5. Настроить модель коммуникации на проекте
Например, непрерывное взаимодействие специалистов по тестированию с владельцами продуктов способствует своевременному отслеживанию изменений в требованиях. В то время как коммуникация QA-инженеров с разработчиками ― получению информации о внесенных в ходе итерации изменениях.
Заключение
Регрессионное тестирование позволяет минимизировать риски сбоев в работе программного продукта после внесения изменений.
В ходе регрессионного тестирования на Scrum-проектах команды сталкиваются с рядом сложностей, которые можно решить благодаря:
обеспечению непрерывной коммуникации между участниками проекта;
поддержке документации в актуальном состоянии;
расширению спринта в случае внесения изменений в функциональность перед релизом;
валидации автоматизированных тест-кейсов.
Чтобы эффективно организовать процесс тестирования, важно:
создать план выполнения регрессии;
использовать доску регрессии;
тщательнее работать над ошибками;
не забывать о преимуществах исследовательского тестирования;
обеспечить открытое взаимодействие между участниками проекта на всех уровнях.
Подобный подход поможет гарантировать качество и стабильность ПО, несмотря на непрерывные доработки, и обеспечить слаженную работу Scrum-команд.
Автоматизированный подход к регрессионному тестированию
Здравствуйте, дорогие читатели. Сегодняшний материал мы хотели бы приурочить к запуску курса «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».