Как я понял ретестинг - это проверка на старые баги, после фикса. А регрессионное - это проверка того, что те новые фиксы, фичи, обновления не сделали новые баги. Все верно?
Если так, то как будет осуществляться выбор регрессионных тестов? Например я добавил новую фичу к себе в ПО ( кнопки назад и вперед). Но вдруг мой код задел что-то где-то еще? Но ведь кнопки функционируют как надо. Так как можно будет произвести регрессионное тестирование, зная, что я ввёл новую фичу?
Т.е. откуда я буду знать, что именно должно быть протестировано этим видом теста?
Вопрос про ретестинг и регрессионное тестирование
#1
Отправлено 31 июля 2018 - 11:28
#2
Отправлено 31 июля 2018 - 12:12
Вы добавили кнопки назад-вперед, но кнопка "назад" на самом деле отправляет тоже вперед. Вы завели баг, горе-программист его исправил. Вы снова жмете на кнопку "назад" и проверяете, куда она вас отправляет. Это ретестинг. После этого вы проверяете, что из-за добавления кнопок, например, не поехала верстка страницы, не поменялись другие кнопки (с которыми, возможно, задействованы общие стили и пр.) Это регрессия. Регрессионные тесты выбираются, в первую очередь, по наличию чего-то общего с добавленной фичей. Если добавили новые кнопки - надо просмотреть все остальные кнопки. Если, скажем, в багтрекере каком-нибудь что-то изменили в технологии хранения прикрепленных файлов, не помешает протестировать, например, копирование багов, в том числе с файлами, которые были прикреплены до изменений.
Еще очень хорошо спросить у программистов, какие фичи могут быть задеты этими изменениями (это может быть очень не очевидно).
#3
Отправлено 31 июля 2018 - 14:48
А регрессионное - это проверка того, что те новые фиксы, фичи, обновления не сделали новые баги
Новые баги в старом функционале, не просто новые. Например, у вас был какой-нибудь список, который определенным образом формируется. Поверх него можно осуществлять ещё какие-то сортировки\выборки. Если вы поменяли алгоритм формирования первоначального списка - логично будет проверить все связанные действия.
Т.е. откуда я буду знать, что именно должно быть протестировано этим видом теста?
Платиновый вопрос, в идеале - нужно протестить абсолютно весь старый функционал. В реальном мире - вам нужно максимально выявить интеграционные связи измененного функционала и существовавшего до изменений. Как? Документация( всякие ERD, flowchart, etc), общение с разработкой, аналитиками, опыт на конкретном проекте и составление сьютов на определенные части интеграции. Если есть изменения, которые попадают под 1-2 теста съюта - прогоняете его целиком на регрессе.
#4
Отправлено 31 июля 2018 - 15:13
регрешон, в большинстве случаев, это тестирование тестов, написанных на основе найденных багов. И даёт результат, этот вид тестов, в виде багов, в случае если в команде программистов есть нечистоплотный участник, который делает мержы на "а ну, и так сойдёт". С появлением git данные проблемы с нечистоплотностью, в большинстве случаев, решает система контроля версий.
А у тех кто досих пор работает на SVN, Perforce, или VCS либо очень прямые руки, либо очень хорошие тестировщики =)
для тех кто работает над общими кусками кода в системе контроля версий будет до боли понятно о чём я тут пишу =)
Количество пользователей, читающих эту тему: 0
0 пользователей, 0 гостей, 0 анонимных