что такое регрессионные баги и как автоматические тесты помогают их решать
Вручную или автоматически: Пара слов о тестировании приложений
Автоматизированное тестирование — это одна из самых обсуждаемых тем среди инженеров по контролю качества. Новые системы тестирования программного обеспечения появляются постоянно, и каждый новый фреймворк получает титул лучшего.
Однако автоматизированное тестирование основывается на предположении, что программа используется так, как это задумали разработчики. Если полагаться только на автоматические тесты, то вскоре в коде появятся ошибки, и в то же время вы получите слабое представление о качестве интерфейса приложения.
Что касается ручного тестирования, то ему уделяют всё меньше внимания, поскольку такой процесс изнуряет сотрудников, а на роль исполнителя подойдет только специалист с особым складом ума. Однако «ручные» тесты отнюдь не уступают автоматизированным. Дело здесь в том, что подходы обладают разными областями применимости, поэтому сегодня мы рассмотрим некоторые достоинства и недостатки каждого решения.
Автоматизированное тестирование
По мнению Сары Фитжи (Sarah Fittje), инженера контроля качества в компании Project A Ventures, если тест подразумевает выполнение большого числа повторяющихся задач, то его имеет смысл автоматизировать. Классический пример — регрессионное тестирование, позволяющее обнаружить серьёзные баги, поэтому его важно регулярно проводить в полном объеме до запуска конечного продукта (кстати, если вам интересно, можете почитать руководство для QA-специалистов от Сары, его вы можете найти по ссылке).
При этом не стоит думать, что настройка автоматических тестов позволит серьезно сэкономить. Написание и поддержка написанных скриптов требует определенных навыков в области QA, которыми обладают не все тестировщики, следовательно, компании придется платить своим специалистам больше (однако штат тестировщиков все же удастся сократить).
Также стоит отметить, что достаточно сложно внедрять автоматизированные тесты для большого приложения с большим функционалом – так вы рискуете потерять видение общей картины и не сможете покрыть тестами весь функционал. Однако настраивая систему автоматизированного тестирования с первых дней проекта, вы получаете возможность ускорить циклы контроля качества и наладить последовательную проверку работы приложения.
Однако важно понимать, что автоматизированное тестирование не сможет помочь в определении недостатков внешнего вида интерфейса и качества взаимодействия пользователя с продуктом. Рассмотрим направления для применения автоматизации:
Тестирование графического интерфейса
Этот тип тестирования нацелен на проверку front-end-части приложения. Без помощи автоматизации очень трудно учесть все возможные комбинации взаимодействия пользователя с интерфейсом в веб-браузерах, мобильных устройствах и прочих системах (важно понимать, что такой тест не сможет оценить UX, как было отмечено выше).
Регрессионное тестирование
С помощью этого типа тестирования разработчики находят баги, вызванные улучшениями функций приложения. Под давлением частых обновлений разработчикам приходится трудиться в бешеном ритме и иногда идти на компромиссы, чем непременно пользуются баги, «закрадываясь» в код программного обеспечения. Вручную отследить недочеты каждого релиза достаточно проблематично.
Функциональное тестирование
Это тестирование для проверки выполнения функциональных требований, то есть работает ли приложение в соответствии с ожиданиями. Определяется, насколько точно реализуются задуманные функции, проводится анализ на соответствие стандартам, оценивается защищённость решения. На повторение функционального тестирования уходит много времени, даже при небольшом изменении в приложении, поэтому выполнять все действия «руками» может быть накладно.
Ручное тестирование
Автоматизированное тестирование помогает добиться высокого качества, но на данный момент оно ещё не заменило ручные тесты полностью. Это связано с тем, что пользователи могут совершать абсолютно неожиданные действия, которые сложно учесть в автоматических тестах.
Пока пользователь привыкает к приложению, он способен ошибаться, не завершать нужные шаги, вводить неожиданные значения и так далее. Пользователи знают гораздо меньше о вашем продукте, но в итоге именно они будут им пользоваться. Поэтому клиентское одобрение — самый ценный индикатор качества интерфейса.
Когда для оценки работы программы ключевую роль начинают играть поведенческие особенности человека и интуиция, то стоит обратить внимание на ручное тестирование — здесь важнее поставить себя на место пользователя. Тестировщик может подходить творчески к процессу проверки функциональности: придумывать неожиданные идеи, имитировать необычные варианты использования — это помогает раскрыть критические ошибки, которые «не заметит» автоматизированное тестирование.
Пара юзкейсов ручного тестирования:
Юзабилити-тестирование
Это тестирование служит для проверки удобства использования приложения с точки зрения пользователя. Такую расплывчатую по своим целям задачу компьютер решить не может — машине нужны четкие формулировки.
Ad hoc тестирование
Разовое тестирование, направленное на проверку одного аспекта программы. Для такого типа тестирования нет формально определённых правил, оно проводится импровизационно — тестировщик может использовать любые доступные средства для поиска багов. Фактически ad hoc тесты – это попытка «угадать» возможную ошибку.
Комбинированный вариант
Как мы отметили выше, разные типы тестирования обладают разными сферами применимости. Автоматические тесты не заменят ручные, но они могут быть использованы для экономии рабочего времени при отработке больших однообразных наборов действий. Ручное же тестирование выполняется долго, но без него не обойтись, если вы хотите добиться высокого качества продукта. На данный момент только комбинация этих подходов способна обеспечить высокие стандарты по отношению к функциональности и удобству использования продукта.
В качестве примера такого подхода Сара Фитжи приводит процесс тестирования онлайн-магазина natue, когда после успешного внедрения новых функций в тестовом проекте, QA-команда запускала автоматизированное регрессионное тестирование.
«Пока выполнялась автоматизированная проверка, мы одновременно проводили ручное тестирование новых функций, учитывая промежуточные результаты регрессионного теста, – рассказывает Сара. – Если во время ручного или автоматизированного тестирования обнаруживались баги, то они исправлялись, а тесты запускались заново». Если же все проходило успешно, то команда Сары повторяла проверку уже перед самим запуском финальной версии.
Еще один пример приводит Стивен Аллен (Steven Allen), инженер компании TestGrid.io. Он говорит, что в iOS полноценное автоматизированное тестирование долгое время было недоступно. Несколько лет назад Apple начали выпускать инструменты для автоматизации, но они пока что не совершенны. Поэтому использовать только средства автоматизации не получается – приходится прибегать к ручному тестированию.
Разработчики автоматизируют тесты, чтобы работать эффективнее и успевать больше, но нельзя описать скриптами все возможные варианты использования приложения и учесть все ошибки. Некоторые вещи очень легко пропустить – например, если на экране входа появилось лишнее поле ввода пользовательского имени, но при этом всё остальное работает правильно.
«Очень сложно написать идеальный код для автоматических тестов, – говорит Джозеф Миллар (Joseph Millar), специалист отдела контроля качества компании Lucid Software. – Если разработчик допустит ошибку в скриптах, он рискует пропустить большой пласт ошибок, тогда как при ручном тестировании эти недочеты, скорее всего, будут обнаружены. Поэтому так важно использовать оба метода при разработке приложений. Один для экономии времени, второй для «шлифовки».
Noveo
Оптимизация регрессионного тестирования в гибкой разработке
Спасибо тестировщику Noveo Анастасии за рубрику переводов о тестировании!
Регрессионное тестирование часто становится проблемным вопросом для менеджеров Agile-проектов. Этот вид тестирования несет в себе две основных трудности:
Чтобы решить эти проблемы, опытные продавцы услуг по тестированию ПО и QA-специалисты придерживаются определенных сбалансированных стратегий. Давайте исследуем некоторые из них.
Регрессионное тестирование в гибких проектах: как оптимизировать?
Существует три наиболее распространенных пути оптимизации регрессионного тестирования в гибкой разработке:
У каждого из них есть плюсы и минусы.
Двухуровневый подход
В соответствии с этим подходом команда тестировщиков делит регрессионные тесты на два цикла:
Тем не менее, этот подход не так прост, как кажется. Чтобы всё прошло успешно, требуется непрерывная коммуникация внутри команды. Общаясь с разработчиками, тестировщики получают полное представление о том, что было сделано в течение итерации, и обоснованно выбирают необходимый тип регрессионного тестирования. Еще один пункт, который следует учесть, это время, прошедшее с момента последней полной регрессии. Это может помочь в установлении графика регулярного полного регрессионного тестирования и проведении ряда тестов вне зависимости от изменений, которые были внесены в ходе итерации. Это поможет команде избежать утомительной полной регрессии после каждого спринта и сохранить приложение относительно “чистым” от багов в любой момент.
Приоритизация тестов: подход на основе оценки рисков
Согласно рискоориентированному подходу, команда тестировщиков выбирает тест-кейсы, покрывающие области приложения, в которые были внесены изменения в последних итерациях, и сортирует их по приоритету. Таким образом, время и силы на регрессию сокращаются.
В течение всего проекта подход, основанный на оценке рисков, может быть применен ко всему набору регрессионных тестов в гибком проекте. Тестировщики делят все тесты на три категории:
Таким образом, расстановка приоритетов помогает снизить время и усилия, затраченные на регрессионное тестирование, без ущерба качеству продукта. Однако этот подход может стать причиной некоторых проблем, так как команда тестировщиков ограничивается их собственными задачами и не видит всей картины. К счастью, есть еще одна стратегия, которая полностью соотносится с особенностями гибких проектов.
Приоритизация тестов: коллективный подход
Этот подход позволяет членам команды привнести свои знания и уникальный взгляд в регрессионное тестирование. В течение спринта команда разрабатывает т.н. “доску регрессии”, покрывающую все задачи, выполненные каждым ее членом. Каждый может внести небольшие изменения, основываясь на собственном опыте. Например, разработчик понимает, что недавно добавленная фича могла повлиять на профиль пользователя, и добавляет эту информацию на доску. Когда приходит время регрессионного тестирования, команда обращается к доске и распределяет время в соответствии с информацией на ней. Используя этот подход, команда применяет свои уникальные знания для формирования комплекта регрессионных проверок, что делает этот тип тестирования более эффективным и менее затратным по времени.
Кроме обоснованности и удобства, подходы с приоритизацией требуют внимания, так как они могут привести к техническим недоработкам, подрывающим реализацию проекта.
Осторожно: технические недоработки
Технические недостатки в гибкой разработке указывают на то, что нужно особенно постараться, чтобы закончить все незавершенные задачи, накопленные за спринт/спринты/жизненный цикл проекта. Как правило, недоработки возникают, когда команда решает починить баг “как-нибудь позже”. Иногда это имеет смысл: например, когда команда откладывает тестирование безопасности до момента, пока система не заработает более стабильно, возникает техническая недоработка. Но это обоснованный тактический шаг, продиктованный грамотным тайм-менеджментом.
Проблемы появляются, когда эти недостатки выходят из-под контроля. Дисциплинированная гибкая поставка (Disciplined Agile delivery, DAD) — фреймворк, который предлагает широкий диапазон шагов по эффективной работе с техническими недоработками. Удивительно, но постоянное гибкое регрессионное тестирование — один из них. Это возвращает нас к началу.
Итак, возможно ли оптимизировать гибкое регрессионное тестирование и в то же время контролировать техническую часть? Ответ на этот вопрос — автоматизация регрессионного тестирования, наша третья стратегия.
Автоматизированный подход
Автоматизированное регрессионное тестирование в гибкой среде — лучший способ разобраться с проблемами, которыми окружена регрессия. Автоматизация сокращает время на тестирование с дней до часов и избавляет инженера-тестировщика от утомительного прохождения одного теста снова и снова. Тем не менее, нужно с осторожностью подходить к внедрению регрессионных автотестов в гибкую разработку.
Правильно подобранный момент — первое, что нужно учесть при планировании автоматизации регрессионного тестирования. Лучше всего вводить автоматизацию на том этапе, когда проект уже достиг определенного уровня зрелости, и все главные изменения уже были внесены. На ранних итерациях в большинстве проектов происходят изменения в интерфейсе, пользовательских сценариях или логике, что увеличивает трудозатраты на тестирование (и ручное, и автоматизированное).
К тому же, автотесты, какими бы хорошими они ни были, не будут актуальными всегда. В гибкой разработке необходимо, чтобы наборы автоматизированных регрессионных тестов полностью отражали изменения и обновления в функциях приложения. Необходимо пересматривать тест-комплекты после каждого крупного релиза и удалять устаревшие кейсы, которые больше не помогают обеспечивать качество продукта.
Тем не менее, ручное тестирование должно сосуществовать даже с лучшими комплектами автотестов. Ручное регрессионное тестирование всегда проводится в первую очередь, так как автоматизированные тест-кейсы основываются на повторяющихся сценариях, которые стабильно выявляли баги в предыдущих итерациях. Эксперты рекомендуют проверять результаты регрессионных автотестов с помощью быстрого ручного смоук-тестирования, чтобы заблаговременно обнаружить ошибочные результаты.
Ориентированность на коммуникацию
Чтобы оптимизировать гибкое регрессионное тестирование, команде тестировщиков следует установить непрерывную коммуникацию с другими членами команды:
Это общепринятый фундамент для всех трех стратегий оптимизации регрессионного тестирования.
Подытоживая сказанное
Регрессионное тестирование в гибкой разработке напоминает горькую таблетку: неприятно, но необходимо для обеспечения качества продукта. К счастью, у команд тестировщиков Noveo в гибкой разработке есть множество стратегий, которые можно применить для оптимизации регрессии. Самые популярные из них — это двухуровневый подход, приоритизация тестов и автоматизация регрессии.
Команды обычно выбирают тот подход, что больше подходит им с точки зрения масштаба проекта, временных рамок, количества запланированных релизов и т.д. Тем не менее, у всех подходов есть общая основа — непрерывная коммуникация.
Если вы нашли ошибку, пожалуйста, выделите фрагмент текста и нажмите Ctrl+Enter.
Регрессионное тестирование — это что, где и зачем оно используется?
Регрессионное тестирование — это дополнительный способ проверить программу, которая раньше уже прошла удачное тестирование. Регрессионное тестирование проводят в том случае, когда в уже протестированной программе были выполнены какие-либо изменения или исправления ошибок. Его цель — выявить и удостовериться, что внесенные в программ у изменения никак не коснулись тех частей программ, которые остались без изменений.
Регрессионное тестирование
Когда проводят регрессионное тестирование
Преимущества и недостатки регрессионного тестирования
В качестве преимуществ можно отметить:
В качестве недостатков можно отметить:
Заключение
Регрессионное тестирование — это дополнительный гарант качества вашего программного продукта. Основная масса подобных тестов проходит «вручную», потому что, как ни странно, очень часто автоматизация регрессионного тестирования приводит к дополнительным финансовым затратам. В итоге получается, что проводить такие тесты дешевле руками молодых тестировщиков, чем автоматизированными решениями профессионалов тестирования.
Мы будем очень благодарны
если под понравившемся материалом Вы нажмёте одну из кнопок социальных сетей и поделитесь с друзьями.
Автоматизированный подход к регрессионному тестированию
Здравствуйте, дорогие читатели. Сегодняшний материал мы хотели бы приурочить к запуску курса «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».