♪
При этом можно, естественно, провести фулл регресс. Это когда вы берете все кейсы для вашего приложения и по ним ходите. В таком случае, конечно, вероятность найти ошибки - больше, но это очень, очень дорого
Это ж сколько времени...
Size: a a a
2020 May 18
♪
Рациональность такого часто == 0
АБ
Рациональность такого часто == 0
Нет, почему? есть огромное количество высокорисковых отраслей, где это оправдано
АБ
медицина, авиастроение и космос, например
АБ
из более близкого - прошивки автомобилей и атомные станции :) там стоимость бага на проде сильно выше)
♪
Тут не спорю. Я о обычних вебах
♪
Мобайлах
АБ
Ну, если есть время (и деньги) - чего б и нет?)
Любой маленький проект с этого начинает, в начале это недорого. Задумываться обычно начинают, когда кейсов >500
Любой маленький проект с этого начинает, в начале это недорого. Задумываться обычно начинают, когда кейсов >500
D
А если мажорные релизы раз в год, фулл регресс оправдан?
♪
Ну, если есть время (и деньги) - чего б и нет?)
Любой маленький проект с этого начинает, в начале это недорого. Задумываться обычно начинают, когда кейсов >500
Любой маленький проект с этого начинает, в начале это недорого. Задумываться обычно начинают, когда кейсов >500
Я не работал в маленьких... Тут соглашусь.
АБ
А если мажорные релизы раз в год, фулл регресс оправдан?
Если он занимает 3 месяца - нет, если 1 - да
D
Ну, стараемся за 1, получается за 2)
♪
Если есть время - можно делать. Если нет его, и надо на вчера - это бред
АБ
Ну, стараемся за 1, получается за 2)
Это еще по-божески :)
AS
Более того, тестирование после обновления ОС - это, скорее, тестирование совместимости окружения, а не регресс.
Регрессионное тестирование предполагает, что какие-то изменения в билде приложения могли затронуть другие области в билде приложения, и чтобы исключить возможность ошибок в этих областях - проводится регресс.
Регрессионное тестирование предполагает, что какие-то изменения в билде приложения могли затронуть другие области в билде приложения, и чтобы исключить возможность ошибок в этих областях - проводится регресс.
То есть в данном случае это Compatibility testing с вытекающими проверками работы основного функционала, если требуется необходимое и достаточное тестирование.
АБ
То есть в данном случае это Compatibility testing с вытекающими проверками работы основного функционала, если требуется необходимое и достаточное тестирование.
Скорее да
AS
Скорее да
Благодарю
YP
Кто подскажет: является ли регрессионное тестирование достаточным для проверки функционала после обновления ОС?
Как-то странно поставлен вопрос, нужно понимать какова цель регрессивного тестирования, его целью является экспертиза того что старые области работают согласно спецификации/ожиданиям после внесения изменений, обновление ОС подразумевает исправление, изменения и добавление новых функциональностей и их реализации... значит что регрессия не тестирует ничего нового, а только дает возможность понять работают ли области на которые не должны были влиять изменения...
AS
Как-то странно поставлен вопрос, нужно понимать какова цель регрессивного тестирования, его целью является экспертиза того что старые области работают согласно спецификации/ожиданиям после внесения изменений, обновление ОС подразумевает исправление, изменения и добавление новых функциональностей и их реализации... значит что регрессия не тестирует ничего нового, а только дает возможность понять работают ли области на которые не должны были влиять изменения...
В целом, так и есть. Задача проверить работают ли старые модули программы на новой ОС со всеми обновлениями.
YP
А писать новые тесты кто будет ?)