Что такое повторное тестирование
Антирегрессионное тестирование – минимизируйте затраты
Регрессионное тестирование играет важнейшую роль в разработке продукта и считается непростой задачей. С этим трудно не согласиться, когда вы тестируете то, что уже было протестировано, а потом тестируете это снова. Термин «регрессия» ассоциируется у членов команды с большими усилиями. Мы знаем, насколько головоломным и вместе с тем незаменимым может быть регрессионное тестирование для процесса релиза и спрашиваем «Приведет ли невыполненное регрессионное тестирование к неудовлетворительному результату?» и «Нужно ли проводить регрессионное тестирование, если программа без ошибок – это недостижимая цель?» Что ж, ответом будет «Да! Регрессионное тестирование нужно проводить регулярно».
Что подразумевается под регрессионным тестированием?
На этот вопрос можно ответить одной фразой: «Исправляя одну ошибку, вы привносите в приложение несколько новых ошибок». Регрессионное тестирование – это то, что позволяет обеспечить исправление ошибки без побочных эффектов.
Во время тестирования выявляются некоторые ошибки, при этом разработчики проекта проводят быструю отладку. Тестировщики и разработчики проводят регрессионное тестирование, чтобы исправление ошибок не привело к нарушению функционала приложения.
Определение: Регрессионное тестирование определяется как вид тестирования программного обеспечения, которое проводится, чтобы подтвердить, что последнее изменение программы или кода не сказалось отрицательно на существующих возможностях. Это не что иное, как полная или частичная выборка уже исполненных тестовых сценариев, которые исполняются повторно с целью проверить правильность работы существующих функций. Регрессионное тестирование также называется подтверждающим тестированием.
Антирегрессионное тестирование
Сам термин «регрессионное тестирование» в некотором роде неточен. Правильнее было бы назвать тестирование «антирегрессионным», так как мы выполняем тесты, чтобы проверить, что система не регрессировала (то есть в результате внесения изменений в ней не возникло еще больше ошибок). Точнее говоря, цель регрессионного тестирования состоит в том, чтобы убедиться, что изменение или улучшение кода программы или среды не нарушило функциональность и не создало побочных эффектов.
Как правило, компании используют так называемый набор или комплекс регрессионных испытаний. Это набор тестовых сценариев, используемых специально для регрессионного тестирования.
Целесообразно иметь комплекс регрессионного тестирования на каждом уровне проверки. Все тестовые сценарии, содержащиеся в комплексе регрессионного тестирования, должны выполняться всякий раз при создании новой версии программного обеспечения, что делает их идеальными кандидатами для автоматизации.
Почему с регрессионными дефектами трудно иметь дело?
Регрессионные ошибки зачастую неизбежны и требуют исправления до развертывания. Регрессионные ошибки трудно исправить по нескольким причинам.
Увеличение стоимости проекта: Крупная ошибка, найденная во время регрессионного тестирования, может создать значительное препятствие для процесса разработки. В отсутствие тщательного планирования регрессионное тестирование может увеличить стоимость проекта. Разработчики и тестировщики выполняют регрессионное тестирование периодически до тех пор, пока ошибки не будут найдены. Исправление регрессионных дефектов требует от разработчиков и тестировщиков выполнения доработок.
Временные сложности: Время регрессионного тестирования приходит после завершения одного этапа разработки и тестирования. По мере приближения сроков выполнения проекта регрессионное тестирование становится серьезным испытанием для команды. У разработчиков остается очень мало времени на исправление ошибок, а у тестировщиков – на проведение повторных функциональных и регрессионных испытаний.
Замедление процесса управления проектом: Каждая компания использует некоторый процесс, обеспечивающий создание продукта в соответствии с требованиями. При обнаружении значительного дефекта в программном обеспечении этот процесс может быть нарушен. Это негативно скажется на сроках выполнения проекта и развертывания продукта.
Тонкости исправления регрессионных дефектов
С регрессионным тестированием можно прекрасно справляться путем ревью кода, а также автоматизации как можно большего числа функциональных и нефункциональных сценариев. Каждый раз необходимо стараться избегать переделок. Это трудно сделать при совместной работе большого числа участников, однако можно попытаться исключить доработки.
Существенные изменения программы и ошибки – обычные явления в разработке продукта. При необходимости каких-либо доработок необходимо обсудить их на совещании, на котором количество ошибок в регрессионном тестировании сводится к минимуму.
Подтвердите каждую ошибку, выявленную в программе, и обсудите ее с членами команды. Это позволяет лучше понять программу и усовершенствовать продукт.
Сосредоточьтесь на наиболее частых сценариях использования программного приложения вместо того, чтобы пытаться протестировать все сразу. Например, лучше всего начать с регистрации пользователей, входа пользователей или покупок.
В регрессионную проверку следует включать этап исследовательского тестирования, которое помогает обеспечить проведение проверок и работу программного обеспечения в соответствии с пользовательскими ожиданиями.
Сравнение регрессионного тестирования и повторного тестирования
Очень тонкая линия разделяет регрессионное тестирование и повторное тестирование.
Цель регрессионного тестирования – убедиться, что изменения не повлияли на неизмененённую часть. Повторное тестирование проводится для того, чтобы проверить, что тестовые сценарии, не прошедшие во время последнего выполнения, работают после исправления дефектов. Регрессионное тестирование не проводится для исправления конкретных дефектов. Повторное тестирование выполняется на основе исправлений дефектов.
Автоматизация – ключевой фактор регрессионного тестирования, тогда как повторное тестирование невозможно автоматизировать по причине неопределенности. Проверка дефекта проводится только в рамках повторного тестирования.
Когда применяется регрессионное тестирование?
Регрессионное тестирование рекомендуется выполнять при возникновении следующих событий:
Регрессионное тестирование играет большую роль для приложения. Несмотря на некоторые недостатки, регрессионное тестирование выполняется, поскольку ошибки имеются во всех приложениях, но мы должны убедиться, что для пользователя они будут работать стабильно.
Регрессионное тестирование
Регрессионное тестирование – это тесты, которые направлены на поиск дефектов в тех участках приложения, которые уже протестированы. Мы в Qualitica делаем это не для того, чтобы окончательно убедиться в отсутствии багов, а для поиска и исправления регрессионных ошибок.
Регрессионные ошибки – это те же дефекты с одной лишь разницей: они появляются не при написании программы, а при добавлении в существующий релиз нового участка программы или при исправлении других багов.
Например, вы сделали приложение для онлайн-знакомств, которое подбирает вам пару, ориентируясь на ваши музыкальные вкусы, род деятельности и тип личности. Но затем, уже после тестирования, решили добавить туда возможность свайпать, как в Tinder. В результате какая-то функция прошлой версии продукта может слететь.
Дополнения, изменения и новые функции могут стать причиной появления новых дефектов в уже протестированном продукте. Поэтому тестировщики проводят регрессионное тестирование, чтобы убедиться: исправление дефектов / обновление релиза не создало новых дефектов в уже проверенном коде.
Регрессионное тестирование включает в себя несколько видов тестов:
Их проводят для проверки и исправления обнаруженного дефекта.
Этот тест содержит принципы smoke-тестирования и тестирования сборки: в рамках тестирования верификации версии мы проверяем работоспособность основного функционала программы в каждой новой сборке.
Нужны, чтобы повторно проверить продукт, который уже написан и был протестирован ранее. Регрессионные тесты проводят по уже существующим тест-кейсам, и неважно, нашли ли в ходе их прохождения дефекты или нет.
Их проводят, когда у вас на руках уже есть новый релиз, но нужно проверить, не “ожили” ли дефекты, которые исправляли еще в старом релизе.
Важно: регрессионное тестирование – это не то же самое, что и повторное. Повторное тестирование – это проверка исправлений, внесенных в конкретный модуль или элемент. В этом главное отличие, ведь регрессионное тестирование направлено на поиск дефектов в целом продукте, где влияние исправления на другой компонент системы является основным направлением.
Как проводят регрессионное тестирование
Чтобы вы понимали, как работает регрессионное тестирование и что из себя представляет, расскажу, как его обычно проводят.
Факты – регрессионное тестирование:
На последнем пункте я остановлюсь и расскажу, что это за направления и в чем специфика каждого.
Три ключевых направления в регрессионном тестировании
Регресс – это тестирование трех основных направлений: дефектов, старых проблем и побочных эффектов.
Это поиск проблем, которые официально были устранены, но есть основания считать, что они до сих пор существуют. В этом случае необходимо проверять все действия с определенным объектом в различных комбинациях. Главное здесь – узнать, действительно ли дефект был устранен, и протестировать механизм, с помощью которого он был выявлен.
Это тестирование ошибок, которые возникли вследствие недавнего изменения кода в одной части приложения. Когда такое происходит, другая часть приложения оказывается нерабочей – полностью или частично. Задача тестировщика – определить все проблемные места.
Для этого подключают автоматизированное тестирование ПО, во время которого тестирование основных функций и задач производится автоматически. Это может быть, например, тестирование запуска, инициализации и выполнения, а также анализа и выдачи результатов.
Автоматизированное тестирование проводит технический специалист, который отвечает за создание, отладку и поддержку в рабочем состоянии тест-скриптов, тестовых наборов и инструментария.
Преимущества и недостатки регрессионного тестирования
К преимуществам регрессионного тестирования можно отнести:
Иными словами, регрессионное тестирование гарантирует, что вы выпустите жизнеспособный, качественный и рабочий релиз, а ваш продукт не потеряет в качестве даже тогда, когда вы начнете добавлять в него новые фичи, функции и опции.
У регрессионного тестирования один недостаток – оно не бывает дешевым, потому что требует много ручного труда. Не все можно автоматизировать, поэтому регрессионное тестирование почти гарантирует вам дополнительные расходы.
Однако это почти всегда необходимые расходы: согласно отчёту World Quality Report 2018, в среднем 26% всего IT-бюджета компаний идет на тестирование. При этом 40–70% этих затрат приходится на регрессионное тестирование. Если перевести проценты в реальные деньги, можно понять, почему регрессионное тестирование стоит каждого рубля, заслуживает внимания и требует продуманной стратегии.
Чтобы эффективно обнаружить все проблемные места, устранить их и обеспечить высокое качество цифрового продукта, нужно выбрать правильный подход и собрать сильную команду тестировщиков.
И у меня для вас хорошие новости – в Qualitica уже сейчас работает команда из 50 профессиональных тестировщиков, которые готовы провести вам регрессионное тестирование по всем стандартам качества. Пишите на hello@qualitica.ru, расскажите о вашем продукте, подключайте нашу команду и выпускайте качественные релизы без дефектов.
Правила обработки персональных данных
1. Персональные данные Посетителя обрабатываются в соответствии с ФЗ «О персональных данных» № 152-ФЗ.
2. При отправке формы обратной связи Посетитель предоставляет следующую информацию: имя, контактный номер телефона, адрес электронной почты.
3. Предоставляя свои персональные данные Владельцу сайта, Посетитель соглашается на их обработку Владельцем сайта, в том числе в целях выполнения Владельцем сайта обязательств перед Посетителем.
4. Под обработкой персональных данных понимается любое действие (операция) или совокупность действий (операций), совершаемых с использованием средств автоматизации или без использования таких средств с персональными данными, включая сбор, запись, систематизацию, накопление, хранение, уточнение (обновление, изменение), извлечение, использование, передачу (в том числе передачу третьим лицам, не исключая трансграничную передачу, если необходимость в ней возникла в ходе исполнения обязательств), обезличивание, блокирование, удаление, уничтожение персональных данных.
5. Владелец сайта вправе использовать технологию «cookies». «Cookies» не содержат конфиденциальную информацию. Посетитель настоящим дает согласие на сбор, анализ и использование cookies, в том числе третьими лицами для целей формирования статистики и оптимизации рекламных сообщений.
6.Владелец сайта получает информацию об ip-адресе Посетителя. Данная информация не используется для установления личности посетителя.
7.Владелец сайта вправе осуществлять записи телефонных разговоров с Покупателем. При этом Владелец сайта обязуется: предотвращать попытки несанкционированного доступа к информации, полученной в ходе телефонных переговоров, и/или передачу ее третьим лицам, не имеющим непосредственного отношения к взаимодействию между Владельцем сайта и Посетителем, в соответствии с п. 4 ст. 16 Федерального закона «Об информации, информационных технологиях и о защите информации».
говориМ о тестировании
простым языком
Виды тестирования по целям: тестирование, связанное с изменениями
Именно после таких правок продукт необходимо снова протестировать. Давайте посмотрим, как именно это можно сделать.
Разработчики постоянно вносят изменения в код. И порой эти изменения могут не только принести пользу (например, исправить баг), но и добавить еще больше проблем и багов, причем в самых неожиданных на первых взгляд местах. Тоже самое можно сказать в отношении добавления новых фич в уже работающий продукт. Всегда есть вероятность, что новый код повлияет на уже существующий и добавит в нем новые баги.
Как же проверить все эти внесенные изменения? Давайте разбираться.
Существует несколько видов тестирования, связанного с изменениями:
1. Подтверждающее тестирование (Re-testing)
2. Регрессионное тестирование (Regression Testing)
3. Дымовое тестирование (Smoke Testing)
4. Санитарное тестирование (Sanity Testing)
5. Тестирование сборки (Build Verification Test)
Давайте разберем их более подробно.
Подтверждающее тестирование (Re-testing)
Подтверждающее тестирование направлено на проверку исправления бага. Суть его в том, что после исправление дефекта программное обеспечение может быть протестировано с использованием тестовых сценариев, которые завершились с ошибкой из-за найденного дефекта. То есть на новой версии программного обеспечения должны быть повторно выполнены шаги по воспроизведению сбоев, вызванных дефектом.
Целью подтверждающего тестирования является удостоверение в том, что найденный дефект был исправлен.
Предположим, что мы тестируем сайт. Положили товар в корзину, пробуем увеличить его количество, но ничего не выходит. Далее оформляем баг-репорт и отдаем разработчикам. Они его пофиксили и настает время для подтверждающего тестирование. Нам необходимо убедиться, что дефект пофикшен. Значит, как минимум, нам необходимо проверить, что баг не воспроизводится по тем шагам, которые указаны в баг-репорте. То есть продуем снова увеличить количество позиций товара в корзине и смотрим, увеличивается ли оно или снова нет.
Регрессионное тестирование (Regression Testing)
Код связан между собой и одно исправление может повлечь за собой новые проблемы. Если вернутся к примеру с корзиной, то окажется, что количество стало меняться, а вот цвет товара изменить теперь не получается.
Случилось это из-за того, что «цвет» и «количество» обращались к одному участку кода, который и был поправлен.
Получается, что изменение, внесенное в одну часть кода, будь то исправление или что-либо другое, может случайно повлиять на поведение других частей кода. Такие непреднамеренные побочные эффекты называются регрессиями. А, соответственно, регрессионное тестированиенаправлено на обнаружение таких непреднамеренных побочных эффектов.
Давайте представим это визуально.
Есть продукт. Он состоит из множества различных частей.
В одной из частей был баг и разработчик его исправил. То есть были внесены изменения в одну из частей программы (на рисунке выделено зеленым).
Данные изменения могли тем или иным образом отразиться и на работе других частей продукта. На рисунке выделено красным.
Либо может быть ситуация, когда в продукте появляется новый функционал. И его работа может повлиять на старый.
То есть нам нужно проверить работу старого функционала после исправления старого кода и/или написания нового. В этом и заключается регрессионное тестирование.
Получается, что при подтверждающим тестировании мы проверяем сам баг, а при регрессионным тестирование не вызвало ли исправление бага или написание нового кода каких-либо изменений в других местах.
Дымовое тестирование (Smoke Testing)
Дымовое тестирование — тестирование, проводимое на начальном этапе и, в первую очередь, направленное на проверку готовности разработанного продукта к проведению более расширенного тестирования.
Данный вид тестирования определяет общее состояние качества продукта.
Это короткий цикл тестов, подтверждающий (отрицающий) факт того, что приложение стартует и выполняет свои основные функции. Проверки практически всегда одинаковы и редко претерпевают изменениям. Поэтому целесообразно их автоматизировать.
Вывод о работоспособности основных функций делается на основании результатов поверхностного тестирования наиболее важных модулей приложения на предмет возможности выполнения требуемых задач и наличия быстро находимых критических и блокирующих дефектов. В случае отсутствия таковых дефектов дымовое тестирование объявляется пройденным, и приложение передается для проведения полного цикла тестирования, в противном случае, дымовое тестирование объявляется проваленным, и приложение уходит на доработку.
Данный тип тестирования позволяет на начальном этапе выявить основные быстро находимые критические дефекты.
Санитарное или Санити тестирование (Sanity Testing)
Относится к виду тестирования, которое используется с целью доказательства работоспособности конкретной функции или модуля согласно заявленным техническим требованиям.
Зачастую санитарное тестирование используют для проверки какой либо части программы или приложения в результате внесенных изменений на нее со стороны факторов окружающей среды. Выполнение его обычно происходит в ручном режиме.
Санитарное тестирование ориентировано на глубинное исследование определенной функции, а дымовое — на тестирование большого количества функционала за самые короткие сроки.
Тестирование сборки (Build Verification Test)
Направлено на определение соответствия выпущенной версии критериям качества для начала тестирования. По своим целям является аналогом дымового тестирования, направленного на приемку новой версии в дальнейшее тестирование или эксплуатацию.
Вглубь оно может проникать дальше, в зависимости от требований к качеству выпущенной версии.
Разница
Итак, на сегодняшний момент наши знания о видах тестирования выглядят следующим образом.
В чем разница между регрессионным тестированием и повторным тестированием?
Регрессионное тестирование специально ищет ошибки в функциональности, которая ранее работала и «регрессировала» в нерабочее состояние. Я никогда не слышал, чтобы «повторный тест» использовался, за исключением здравого смысла: повторный тест просто проверяет что-то снова после того, как он был ранее протестирован, и является более общим термином, поскольку повторный тест ничего не говорит о состоянии программного обеспечения до повторное тестирование.
Вы можете повторно протестировать функциональные возможности, которые никогда не работали при повторном тестировании, но вы не можете использовать функции тестирования регрессии, которые никогда не работали должным образом, потому что только функциональность, которая работала ранее, может «регрессировать» в нерабочее состояние.
Эти определения будут варьироваться от одной организации к другой. В тестовых заданиях, которые у меня были, регрессионное тестирование означает тестирование, которое проверяет, что функции, которые раньше работали, все еще работают. В этом контексте регрессия является ошибкой, которая не существовала в более ранней версии продукта. В тестовых заданиях, которые у меня были, регрессионное тестирование происходит после того, как все новые функции были протестированы, хотя время регрессионного тестирования не является существенным для его определения.
Регрессионное тестирование проверяет, не нарушена ли существующая функциональность из-за внедрения новых функций. Например, я хотел бы проверить, не нарушена ли существующая безопасность приложения facebook при реализации его новой функции «X».
Regress означает вернуться к последнему нестабильному или менее развитому состоянию. Когда CHANGE выполняется в части программного обеспечения, мы тестируем приложение, чтобы узнать, какой эффект внесен в приложение CHANGE. Сначала мы проверим исправление, затем посмотрим, в каких областях это изменение произошло, и проверим, работает ли эта область, т. Е. Нет ряби.
Аналогичным образом, когда в приложении происходит изменение, мы должны обновить наши тестовые примеры для регрессионного тестирования: 1: добавьте тестовые примеры в набор тестов, чтобы проверить новые функции 2: Удалите устаревшие тестовые примеры, которые больше не нужны (некоторые старые функции могут быть более доступны после изменения кода) 3: обновление в настоящее время для изменения измененного кода. Например, изменение кода может потребовать некоторой настройки в шагах уже существующих тестовых случаев
Регрессионное Тестирование (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 инженеров.
Поэтому в следующий раз хорошенько подумай, перед тем, как “автоматизировать все”.
И помни, что работа любого специалиста должна быть направлена на повышение эффективности работы и качества продуктов компании, а не на увеличение ее финансовых затрат!
Псс.. Несколько инструментов тестировщика, которые точно помогут тебе стать более эффективными, без автоматизации)
Резюме
В статье мы детально ознакомились с одним из типов тестирования, связанного с изменениями, а именно регрессионным тестированием.
Мы узнали что это такое, зачем оно необходимо, какие у него «плюсы» и «минусы», и что нам “готовит” автоматизация таких тест-кейсов.
Если у тебя есть вопросы / предложения / замечания — пиши нам!)
Если тебе интересна эта тема, и ты хочешь получать актуальную информацию о тестировании — подписывайся на наш Телеграм канал, там интересно: статьи, тесты, опросы, нет спама! 🙂