Сообщений в теме: 19

[chaikova]

Ну естественно, не включая момент, если багов не было обнаружено...что очень странно :))))

В каком случае не проводят регрессионное тестирование ? Отсутствие времени, денег, людей?

 

[SHINNOK]

Обычно, если на него не остаётся времени, т.е. проект уже надо сдавать заказчику. Это, кстати, справедливо и для фич с низким приоритетом. 

[Vasiliy]

Ну естественно, не включая момент, если багов не было обнаружено...что очень странно :))))

А почему вы считаете, что если не было багов, то не надо проводить регрессионное тестирование?

[chaikova]

 

Ну естественно, не включая момент, если багов не было обнаружено...что очень странно :))))

А почему вы считаете, что если не было багов, то не надо проводить регрессионное тестирование?

 

Если не нашли багов => не меняли функционал. Но если функционал меняли , то тестировать конечно надо. 

[kirill_222]

Как вариант:
1. Так поставлен процесс разработки. Допустим есть некая библиотека и ответственность за ее тестирование валится на группу тестирования потребителя данной библиотеки.
2. Когда оно вредно. К примеру мертвый проект в котором нужно поддержать некое изменение законодательства. Разрушения локальны, а общее регрессионное тестирование приведет к появлению новых не привнесенных, не критичных ошибок, с которыми потребитель жил годами

[Vasiliy]

Если не нашли багов => не меняли функционал.

Очень спорное утверждение!

Может вы плохо искали?)

[Drag]

Согласна с Vasiliy
Вообще регрессионное тестирование можно проводить именно для того, чтобы найти то, что ранее не находили, даже если есть и автотесты, и кейсы, и функционал не трогали. 
 

А по хорошему ответ на ваш вопрос должен звучать так: "потому что на него забили"

[Vasiliy]

Как вариант:

2. Когда оно вредно. К примеру мертвый проект в котором нужно поддержать некое изменение законодательства. Разрушения локальны, а общее регрессионное тестирование приведет к появлению новых не привнесенных, не критичных ошибок, с которыми потребитель жил годами

Проект, в котором нужно что-то поддерживать не может быть мертвым. Это будет проект на поддержке, тестирование в котором так же необходимо. Ну только если нет задачи минимизировать все и вся.

Тестирование не приводит к появлению ошибок, оно их обнаруживает. А что с ними делать - это уже вопрос к ЛПРу.

 

P.S.

Сталкивался как раз с описанной ситуацией. Проект на поддержке и там небольшое изменение. Функционал проверили и внутренний заказчик решил выпустить до регресса. В итоге пользователи получили серьезную ошибку, потому что была еще верхнеуровневая логика, которая использовала проверенную нами функцию, но по-другому. Вот эта логика и сломалась.

А по нашим процессам мы ее проверяем только в регрессе, потому что напрямую она не завязана с измененным функционалом (ну или у отдела тестирования не было таких знаний).

[kirill_222]

Проект, в котором нужно что-то поддерживать не может быть мертвым. Это будет проект на поддержке, тестирование в котором так же необходимо. Ну только если нет задачи минимизировать все и вся.

 

 

Тестирование не приводит к появлению ошибок, оно их обнаруживает. А что с ними делать - это уже вопрос к ЛПРу.

 

P.S.

Сталкивался как раз с описанной ситуацией. Проект на поддержке и там небольшое изменение. Функционал проверили и внутренний заказчик решил выпустить до регресса. В итоге пользователи получили серьезную ошибку, потому что была еще верхнеуровневая логика, которая использовала проверенную нами функцию, но по-другому. Вот эта логика и сломалась.

А по нашим процессам мы ее проверяем только в регрессе, потому что напрямую она не завязана с измененным функционалом (ну или у отдела тестирования не было таких знаний).

 

Вообщем то вы правильно описали, но в моем случае есть специфика.
Мой проект достался мне в наследство. Тестировался ранее исключительно паком позитивных автотестов, причем сам проект второплановый и писался, что называется... При первом знакомстве в первом же справочнике обнаружил 4 ошибки, которые естественно оказались непривнесенными и существовали несколько лет.
Проверка обновления и интеграционное тестирование занимает трудодень. Регрессия основных элементов - 10.
При этом основной продукт прямой конкурент данного и задачи его тестирования в абсолютном приоритете.
За 2 года выпустил его 6 или 7 раз. Да. один раз словили критическую ошибку, вызванную вышеуказанным пунктом 1. Ее поправили и за день перевыпустились.

 

[SALar]

Регрессионное тестирование можно не проводить по разным поводам. Основное, на что нужно смотреть это потери организации из-за выхода из строя ПО.

 

Пример 1 (выдуманный). Все кассы торговой сети "Перекресток" обслуживаются из единого центра (почти наверняка это не так, но вы ж понимаетет, что это пример). Ошибка в ПО приводит к невозможности обслуживания покупателей. Каждый час простоя - это огромные убытки. А если софт будет неработоспособен хотя бы неделю, то это может привести к разорению компании. Регрессионное тестирование желательно.

 

Пример 2. Внутренняя система учета тикетов истользуемая исключительно и только сотрудниками IT департамента для разработки новых бизнес приложений. Естественно, у всех разработчиков постоянно что-то зудит и система постоянно допиливается (разработчиков, вообще, хлебом не корми, только дай подопиливать систему для управления проектом). Если эта система ляжет... Ну и что? Можно и неделю без нее прожить. А можно поднять из бекапа недельной давности. Чуть - чуть информации потеряется, но ее легко и дешево можно восстановить. Регрессионное тестирование крайне НЕ желательно.

 

Коберн вот в этой книге http://www.ozon.ru/c...il/id/19730649/ выделяет 4 уровня критичности. Вот по ним и классифицируйте.

--------------------------------------

Следующий важный фактор - хрупкость кода. Мы часто не делали регрессии именно потому, что вероятность поломать соседний модуль очень мала.

 

Пример 3. Бухгалер просит сделать некий аналитический отчет. Поскольку  код отчета изолирован от остального кода, то регрессионное тестирование крайне НЕ желательно.

[BadMF]

вопрос экономической целесообразности.

[chaikova]

 

Если не нашли багов => не меняли функционал.

Очень спорное утверждение!

Может вы плохо искали?)

 

Неверное суждение с точки зрения основных принципов тестирования:)

НО речь сейчас не об этом, а именно о необходимости проведения регрессионного тестирования....

[chaikova]

Получается, что регрессия необходима....Практически всегда ( не берем во внимание малоприоритетные фичи)...

Но вот возможность проводить такой вид тестирования имеется не всегда...прям замкнутый круг :)

[SALar]

Получается, что регрессия необходима....Практически всегда ( не берем во внимание малоприоритетные фичи)...

 

Исходя из моего опыта все точно наоборот. Регрессионное тестирование почти всегда не нужно.

[ch_ip]

Получается, что регрессия необходима....Практически всегда ( не берем во внимание малоприоритетные фичи)...
Но вот возможность проводить такой вид тестирования имеется не всегда...прям замкнутый круг :)

Регрессия необходима практически всегда, когда нет выстроенного процесса разработки, и поэтому всем страшно, что при изменениях в одном месте отвалится что-то в совершенно непредсказуемом другом. Когда такое бывает?

• Плохая архитектура приложения,
• нет юнит-тестов,
• нет или слабая аналитика по влиянию изменения требований на другие модули программы,
• высокая связность модулей,
• высокая связность кода,
• нет интеграционных автоматических тестов, которые запускаются при сборке или хотя бы раз в день,
• нет ежедневных сборок и постоянного отслеживания вновь появившихся проблем,
• тестировщики не общаются с разработчиками и не обсуждают риски,
• тестировщики плохо представляют архитектуру продукта и внутренние взаимосвязи.

Если хотя бы половина из этого для проекта верна, то да, регрессия необходима всегда, т.к. никто не может предсказать последствия изменений и какие есть риски от конкретных изменений.
При грамотно выстроенном процессе тестирования, когда есть юнит и интеграционные тесты, запускающиеся при каждом изменении + функциональные тесты, которые запускаются каждую ночь на новых сборках, нужна минимальная регрессия, а в каких-то случаях можно обойтись и без нее. Плюс даже в тех случаях, когда она есть, необходимо периодически пересматривать, действительно ли нужен все тот же комплект проверок и думать, как оптимизировать.
В блоге у Оли Киселевой есть хорошая статья о том, как мы уже оптимизировали нашу регрессию — "Всегда ли нужна ручная регрессия? Жизнь_боль как двигатель прогресса"
+ сейчас мы думаем над тем, как полностью сделать ее автоматической и сократить затраты на весь цикл регрессионного тестирования до 4-6 часов одного человека в релиз (при это сама автоматическая регрессия, выполняемая роботом, может занимать до 2-3 дней). Стоит учесть, что наш продукт часто является критичным в цепочке основных бизнес-процессов Заказчика, поэтому мы не можем позволить себе пропустить ошибки, из-за которых система встанет (высокие финансовые риски для наших Заказчиков и репутационные риски для нас самих)

[chaikova]

 

Получается, что регрессия необходима....Практически всегда ( не берем во внимание малоприоритетные фичи)...
Но вот возможность проводить такой вид тестирования имеется не всегда...прям замкнутый круг :)

Регрессия необходима практически всегда, когда нет выстроенного процесса разработки, и поэтому всем страшно, что при изменениях в одном месте отвалится что-то в совершенно непредсказуемом другом. Когда такое бывает?

• Плохая архитектура приложения,
• нет юнит-тестов,
• нет или слабая аналитика по влиянию изменения требований на другие модули программы,
• высокая связность модулей,
• высокая связность кода,
• нет интеграционных автоматических тестов, которые запускаются при сборке или хотя бы раз в день,
• нет ежедневных сборок и постоянного отслеживания вновь появившихся проблем,
• тестировщики не общаются с разработчиками и не обсуждают риски,
• тестировщики плохо представляют архитектуру продукта и внутренние взаимосвязи.

Если хотя бы половина из этого для проекта верна, то да, регрессия необходима всегда, т.к. никто не может предсказать последствия изменений и какие есть риски от конкретных изменений.
При грамотно выстроенном процессе тестирования, когда есть юнит и интеграционные тесты, запускающиеся при каждом изменении + функциональные тесты, которые запускаются каждую ночь на новых сборках, нужна минимальная регрессия, а в каких-то случаях можно обойтись и без нее. Плюс даже в тех случаях, когда она есть, необходимо периодически пересматривать, действительно ли нужен все тот же комплект проверок и думать, как оптимизировать.
В блоге у Оли Киселевой есть хорошая статья о том, как мы уже оптимизировали нашу регрессию — "Всегда ли нужна ручная регрессия? Жизнь_боль как двигатель прогресса"
+ сейчас мы думаем над тем, как полностью сделать ее автоматической и сократить затраты на весь цикл регрессионного тестирования до 4-6 часов одного человека в релиз (при это сама автоматическая регрессия, выполняемая роботом, может занимать до 2-3 дней). Стоит учесть, что наш продукт часто является критичным в цепочке основных бизнес-процессов Заказчика, поэтому мы не можем позволить себе пропустить ошибки, из-за которых система встанет (высокие финансовые риски для наших Заказчиков и репутационные риски для нас самих)

 

Спасибо за столь полный ответ! 

[SALar]

Павел, вы ж если не ошибаюсь работаете с MDM. А оно, если не настроены кеши MDM в "mission critical" приложениях (что плохо, но встречается) само становится "mission critical". Так что у вас регрессия желательна. Ну, и еще у вас критичного функционала мало. Его вполне можно гонять на регулярной основе и даже, при желании автоматизировать.

 

Есть такое когнитивное искажение "обобщение на одном примере". Ваш пример, скорее, исключение из правил. Так получилось, что я знаком с типичным набором корпоративных приложений. Разрабатывал, тестировал, аналитику писал. Регрессия нужна дай бог для 5% приложений. Для большинства же она просто прямые потери.

 

регрессия необходима всегда, т.к. никто не может предсказать последствия изменений и какие есть риски от конкретных изменений.

 

И че? Ну упало. Поднимем из бэкапа. Ну посчиталось НДС неправильно. Заметили - поправили. Не выкатывайте релизы в отчетный период и будет вам Щастье, с большой буквы "Щ".

[ch_ip]

Павел, вы ж если не ошибаюсь работаете с MDM. А оно, если не настроены кеши MDM в "mission critical" приложениях (что плохо, но встречается) само становится "mission critical". Так что у вас регрессия желательна. Ну, и еще у вас критичного функционала мало. Его вполне можно гонять на регулярной основе и даже, при желании автоматизировать.

Верно, да. Многое автоматизировано и, надеюсь, к концу года удастся перейти на полностью автоматическую регрессию.
 

Есть такое когнитивное искажение "обобщение на одном примере". Ваш пример, скорее, исключение из правил. Так получилось, что я знаком с типичным набором корпоративных приложений. Разрабатывал, тестировал, аналитику писал. Регрессия нужна дай бог для 5% приложений. Для большинства же она просто прямые потери.
 

регрессия необходима всегда, т.к. никто не может предсказать последствия изменений и какие есть риски от конкретных изменений.

И че? Ну упало. Поднимем из бэкапа. Ну посчиталось НДС неправильно. Заметили - поправили. Не выкатывайте релизы в отчетный период и будет вам Щастье, с большой буквы "Щ".

Поднятие из бэкапа весьма неприятная процедура + потеря информации за промежуток простоя системы. А в тему неправильно посчиталось - мне довелось работать год в айтишной поддержке банка и выкатку нового функционала без регрессии (не успели, т.к. изменения нужны были четко к дате, когда там законодательство в очередной раз поменялось) я на всю жизнь запомнил — двое суток круглосуточной работы трех человек по откату неверных начислений, по которым сдается ежедневная отчетность.
Да, согласен есть отчеты и аналитика, для которой не страшно, если упало или неверно посчиталось (и это вовремя заметили), но как-то мне больше приходилось работать в тех сферах, где падение системы или неверные расчеты несут существенные риски:

• Программы для обработки результатов химических анализов (наука)
• Платы для круглосуточного Аудио-видео наблюдения
• Управление финансовыми портфелями в DB (кажется, единственное, где регрессия была лишней)
• Система для организации онлайн-видео с выборов (тоже можно было уменьшить регрессию, возможно соберусь как-нибудь рассказать про проект)
  
  

и я бы не сказал, что у нас везде был хороший процесс разработки. Я сейчас понимаю, что изменив процесс, можно было бы добиться существенного уменьшения затрат на регрессию и можно было бы применить более правильную автоматизацию, начав снизу (с кода), а не с пользовательского интерфейса. Но при этом понимаю, откуда росли ноги у убежденности в необходимости регрессии среди менеджмента и программистов - реально могло отвалиться что угодно и где угодно и никто не хотел принимать на себя такие риски - гораздо проще было заплатить за регрессию, хотя полезный выхлоп и эффективность такого решения была низка.

Не спорю, что есть огромное количество приложений, которые можно выпускать без регрессии, или с минимальной регрессией просто правильно оценив приоритеты и риски.

[slavakuharenkov]

А когда нужно проводить регрессионное тестирование? Перед релизом или после каждого баг-фикса?

[Vad1m198]

А когда нужно проводить регрессионное тестирование? Перед релизом или после каждого баг-фикса?

Если Вы успеваете проводить регрессионное тестирование после каждого баг-фикса, и нет более приоритетных задач (например, тестирование новых фич), то можно после каждого баг-фикса.