что такое повторное тестирование
Что такое повторное тестирование
Например, участник является сильным кандидатом, и его приём на работу / повышение важно для HR’а или руководителя.
Назначение перетеста в этом случае дискредитирует процедуру тестирования по двум причинам:
— Тесты не должны сильно коррелировать с оценкой менеджера или какого-либо другого человека (Connolly, Kavanagh & Viswesvaran, 2007). Важный нюанс: инструмент «создаёт» качество, которое он измеряет. Интеллект, измеренный руководителем, и интеллект, измеренный тестом — это не одно и то же качество. То же самое с личностными чертами. Это расхождение и делает тесты ценным инструментом — они рассматривают качество с уникального ракурса (и поэтому добавляют валидности).
— Участник получит преимущество, т.к. сможет улучшить свои результаты в повторном тестировании. Что (а) несправедливо по отношению к другим участникам и (б) снижает объективность оценки.
1. Arendasy, M. E., & Sommer, M. (2013). Quantitative differences in retest effects across different methods used to construct alternate test forms. Intelligence, 41(3), 181–192.
2. Connolly, J. J., Kavanagh, E. J., & Viswesvaran, C. (2007). The convergent validity between self and observer ratings of personality: A meta‐analytic review.International Journal of Selection and Assessment, 15(1), 110-117.
3. McCrae, R. R., & Costa, P. T. (1983). Social desirability scales: More substance than style. Journal of consulting and clinical psychology, 51(6), 882.
4. Hausknecht, J. P., Halpert, J. A., Di Paolo, N. T., & Moriarty Gerrard, M. O. (2007). Retesting in selection: a meta-analysis of coaching and practice effects for tests of cognitive ability. Journal of Applied Psychology, 92(2), 373.
5. Hausknecht, J. P. (2010). Candidate persistence and personality test practice effects: Implications for staffing system management. Personnel Psychology, 63(2), 299–324.
6. Holladay, C. L., David, E., & Johnson, S. K. (2013). Retesting personality in employee selection: implications of the context, sample, and setting. Psychological reports, 112.
6. Kelley, P. L., Jacobs, R. R., & Farr, J. L. (1994). Effects of multiple administrations of the MMPI for employee screening. Personnel Psychology, 47, 575–591.
7. McAdams, D. P., & Olson, B. D. (2010). Personality development: Continuity and change over the life course. Annual review of psychology, 61, 517–542.
8. Ones, D. S., Viswesvaran, C., & Reiss, A. D. (1996). Role of social desirability in personality testing for personnel selection: The red herring. Journal of Applied Psychology, 81(6), 660.
9. Villado, A. J., Randall, J. G., & Zimmer, C. U. (2016). The effect of method characteristics on retest score gains and criterion-related validity. Journal of Business and Psychology, 31(2), 233–248.
10. Walmsley, P. T., & Sackett, P. R. (2013). Factors affecting potential personality retest improvement after initial failure. Human Performance, 26(5), 390–408.
Антирегрессионное тестирование – минимизируйте затраты
Регрессионное тестирование играет важнейшую роль в разработке продукта и считается непростой задачей. С этим трудно не согласиться, когда вы тестируете то, что уже было протестировано, а потом тестируете это снова. Термин «регрессия» ассоциируется у членов команды с большими усилиями. Мы знаем, насколько головоломным и вместе с тем незаменимым может быть регрессионное тестирование для процесса релиза и спрашиваем «Приведет ли невыполненное регрессионное тестирование к неудовлетворительному результату?» и «Нужно ли проводить регрессионное тестирование, если программа без ошибок – это недостижимая цель?» Что ж, ответом будет «Да! Регрессионное тестирование нужно проводить регулярно».
Что подразумевается под регрессионным тестированием?
На этот вопрос можно ответить одной фразой: «Исправляя одну ошибку, вы привносите в приложение несколько новых ошибок». Регрессионное тестирование – это то, что позволяет обеспечить исправление ошибки без побочных эффектов.
Во время тестирования выявляются некоторые ошибки, при этом разработчики проекта проводят быструю отладку. Тестировщики и разработчики проводят регрессионное тестирование, чтобы исправление ошибок не привело к нарушению функционала приложения.
Определение: Регрессионное тестирование определяется как вид тестирования программного обеспечения, которое проводится, чтобы подтвердить, что последнее изменение программы или кода не сказалось отрицательно на существующих возможностях. Это не что иное, как полная или частичная выборка уже исполненных тестовых сценариев, которые исполняются повторно с целью проверить правильность работы существующих функций. Регрессионное тестирование также называется подтверждающим тестированием.
Антирегрессионное тестирование
Сам термин «регрессионное тестирование» в некотором роде неточен. Правильнее было бы назвать тестирование «антирегрессионным», так как мы выполняем тесты, чтобы проверить, что система не регрессировала (то есть в результате внесения изменений в ней не возникло еще больше ошибок). Точнее говоря, цель регрессионного тестирования состоит в том, чтобы убедиться, что изменение или улучшение кода программы или среды не нарушило функциональность и не создало побочных эффектов.
Как правило, компании используют так называемый набор или комплекс регрессионных испытаний. Это набор тестовых сценариев, используемых специально для регрессионного тестирования.
Целесообразно иметь комплекс регрессионного тестирования на каждом уровне проверки. Все тестовые сценарии, содержащиеся в комплексе регрессионного тестирования, должны выполняться всякий раз при создании новой версии программного обеспечения, что делает их идеальными кандидатами для автоматизации.
Почему с регрессионными дефектами трудно иметь дело?
Регрессионные ошибки зачастую неизбежны и требуют исправления до развертывания. Регрессионные ошибки трудно исправить по нескольким причинам.
Увеличение стоимости проекта: Крупная ошибка, найденная во время регрессионного тестирования, может создать значительное препятствие для процесса разработки. В отсутствие тщательного планирования регрессионное тестирование может увеличить стоимость проекта. Разработчики и тестировщики выполняют регрессионное тестирование периодически до тех пор, пока ошибки не будут найдены. Исправление регрессионных дефектов требует от разработчиков и тестировщиков выполнения доработок.
Временные сложности: Время регрессионного тестирования приходит после завершения одного этапа разработки и тестирования. По мере приближения сроков выполнения проекта регрессионное тестирование становится серьезным испытанием для команды. У разработчиков остается очень мало времени на исправление ошибок, а у тестировщиков – на проведение повторных функциональных и регрессионных испытаний.
Замедление процесса управления проектом: Каждая компания использует некоторый процесс, обеспечивающий создание продукта в соответствии с требованиями. При обнаружении значительного дефекта в программном обеспечении этот процесс может быть нарушен. Это негативно скажется на сроках выполнения проекта и развертывания продукта.
Тонкости исправления регрессионных дефектов
С регрессионным тестированием можно прекрасно справляться путем ревью кода, а также автоматизации как можно большего числа функциональных и нефункциональных сценариев. Каждый раз необходимо стараться избегать переделок. Это трудно сделать при совместной работе большого числа участников, однако можно попытаться исключить доработки.
Существенные изменения программы и ошибки – обычные явления в разработке продукта. При необходимости каких-либо доработок необходимо обсудить их на совещании, на котором количество ошибок в регрессионном тестировании сводится к минимуму.
Подтвердите каждую ошибку, выявленную в программе, и обсудите ее с членами команды. Это позволяет лучше понять программу и усовершенствовать продукт.
Сосредоточьтесь на наиболее частых сценариях использования программного приложения вместо того, чтобы пытаться протестировать все сразу. Например, лучше всего начать с регистрации пользователей, входа пользователей или покупок.
В регрессионную проверку следует включать этап исследовательского тестирования, которое помогает обеспечить проведение проверок и работу программного обеспечения в соответствии с пользовательскими ожиданиями.
Сравнение регрессионного тестирования и повторного тестирования
Очень тонкая линия разделяет регрессионное тестирование и повторное тестирование.
Цель регрессионного тестирования – убедиться, что изменения не повлияли на неизмененённую часть. Повторное тестирование проводится для того, чтобы проверить, что тестовые сценарии, не прошедшие во время последнего выполнения, работают после исправления дефектов. Регрессионное тестирование не проводится для исправления конкретных дефектов. Повторное тестирование выполняется на основе исправлений дефектов.
Автоматизация – ключевой фактор регрессионного тестирования, тогда как повторное тестирование невозможно автоматизировать по причине неопределенности. Проверка дефекта проводится только в рамках повторного тестирования.
Когда применяется регрессионное тестирование?
Регрессионное тестирование рекомендуется выполнять при возникновении следующих событий:
Регрессионное тестирование играет большую роль для приложения. Несмотря на некоторые недостатки, регрессионное тестирование выполняется, поскольку ошибки имеются во всех приложениях, но мы должны убедиться, что для пользователя они будут работать стабильно.
В чем разница между регрессионным тестированием и повторным тестированием?
Регрессионное тестирование специально ищет ошибки в функциональности, которая ранее работала и «регрессировала» в нерабочее состояние. Я никогда не слышал, чтобы «повторный тест» использовался, за исключением здравого смысла: повторный тест просто проверяет что-то снова после того, как он был ранее протестирован, и является более общим термином, поскольку повторный тест ничего не говорит о состоянии программного обеспечения до повторное тестирование.
Вы можете повторно протестировать функциональные возможности, которые никогда не работали при повторном тестировании, но вы не можете использовать функции тестирования регрессии, которые никогда не работали должным образом, потому что только функциональность, которая работала ранее, может «регрессировать» в нерабочее состояние.
Эти определения будут варьироваться от одной организации к другой. В тестовых заданиях, которые у меня были, регрессионное тестирование означает тестирование, которое проверяет, что функции, которые раньше работали, все еще работают. В этом контексте регрессия является ошибкой, которая не существовала в более ранней версии продукта. В тестовых заданиях, которые у меня были, регрессионное тестирование происходит после того, как все новые функции были протестированы, хотя время регрессионного тестирования не является существенным для его определения.
Регрессионное тестирование проверяет, не нарушена ли существующая функциональность из-за внедрения новых функций. Например, я хотел бы проверить, не нарушена ли существующая безопасность приложения facebook при реализации его новой функции «X».
Regress означает вернуться к последнему нестабильному или менее развитому состоянию. Когда CHANGE выполняется в части программного обеспечения, мы тестируем приложение, чтобы узнать, какой эффект внесен в приложение CHANGE. Сначала мы проверим исправление, затем посмотрим, в каких областях это изменение произошло, и проверим, работает ли эта область, т. Е. Нет ряби.
Аналогичным образом, когда в приложении происходит изменение, мы должны обновить наши тестовые примеры для регрессионного тестирования: 1: добавьте тестовые примеры в набор тестов, чтобы проверить новые функции 2: Удалите устаревшие тестовые примеры, которые больше не нужны (некоторые старые функции могут быть более доступны после изменения кода) 3: обновление в настоящее время для изменения измененного кода. Например, изменение кода может потребовать некоторой настройки в шагах уже существующих тестовых случаев
Регрессионное тестирование
Регрессионное тестирование – это тесты, которые направлены на поиск дефектов в тех участках приложения, которые уже протестированы. Мы в 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 Федерального закона «Об информации, информационных технологиях и о защите информации».
Регрессионное Тестирование (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 инженеров.
Поэтому в следующий раз хорошенько подумай, перед тем, как “автоматизировать все”.
И помни, что работа любого специалиста должна быть направлена на повышение эффективности работы и качества продуктов компании, а не на увеличение ее финансовых затрат!
Псс.. Несколько инструментов тестировщика, которые точно помогут тебе стать более эффективными, без автоматизации)
Резюме
В статье мы детально ознакомились с одним из типов тестирования, связанного с изменениями, а именно регрессионным тестированием.
Мы узнали что это такое, зачем оно необходимо, какие у него «плюсы» и «минусы», и что нам “готовит” автоматизация таких тест-кейсов.
Если у тебя есть вопросы / предложения / замечания — пиши нам!)
Если тебе интересна эта тема, и ты хочешь получать актуальную информацию о тестировании — подписывайся на наш Телеграм канал, там интересно: статьи, тесты, опросы, нет спама! 🙂