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

[Anya_Nika]

Всем привет!
Может ли кто-нибудь объяснить разницу между maintenance и regression testing, а также сравнение re-testing и maintenance testing в зависимости от стадии разработки.
Правильно ли мое понимание:
-до официального релиза (на всех этапах тестирования), в случае нахождения дефекта и после его исправления, проводится re-testing исправленной части софта и regression (проверка, что изменения не повредили уже существующую, работающую функциональность).
- после релиза, тестирование всех изменений (! в т.ч. исправление дефектов) определяется как maintenance testing, после которого также проводится regression testing.
Т.е. в случае использования водопадной модели разработки разница между re-testing и maintenance testing определяется только тем был релиз или нет, тогда как regression ничем не отличается.
А если мы используем гибкие методологии? Все понятия работают также после выпуска каждого билда?

[astenix]

Вы думу думаете правильно, но в терминологии еще не разобрались, поэтому вам дума подкидывает каких-то монстрообразных монстриков. Сейчас это выглядит как "Я могу чай заваривать из пакетика. А могу и из сухих веточек. А что будет если я буду использовать не гибкие, а жидкие методологии заваривания чая? Разницы никакой! В чем же разница?" Оно вам надо?

 

Ответьте мне поскорее:

1. Что такое maintenance само по себе?
2. Что такое regress в принципе?

[astenix]

Яна?

[Anya_Nika]

Спасибо за ответ.
В принципе, maintenance = поддержка/сопровождение, а regression = возвращение к прежним этапам, т.е. тестируем то, что уже тестировали.

[Anya_Nika]

Путаница возникла при прочтении ISTQB Foundation, где re-testing определяется как повторное выполнение теста, чтоб убедиться, что дефект был действительно устранен. А maintenance, как тестирование изменений (причиной которых, также, могли быть дефекты)...
Да, вы все верно говорите. Нет у меня достаточного понимания.

[astenix]

Уже сдались, что ли?

[Anya_Nika]

Конечно же нет!

[astenix]

С regression путаница приходит из нескольких источников:

1. Термин не объясняется по-сути, а описывается по внешним признакам, вроде "Регрешн — это когда мы заново всё тестируем". Это приемлемо [для детей], но так же тупо, как "Машина — это когда я еду на работу, и мне удобно в ней сидеть". Это не объяснение. Это описание того, что ребенок видит какой-то феномен, не понимая, как и почему оно работает.
2. Сленговость и упрощение произношения. Вместо "Регрессионное тестирование" произносим "Регрешн" (и даже невероятное "делаем регрешн"!), и дальше пытаемся понять, что такое регрешн, а не регресс, и запутались.
3. Кроме термина регресс еще есть термин регрессия — сам по себе термин неоднозначный. Это бывает и в психологии, и в финансовой аналитике, и это разные феномены ВААПЩЕ.

Ок. В википедии правильно указана суть термина "Регрессионное тестирование" (англ. regression testing, от лат. regressio — движение назад), но дальнейшее объяснение недостаточно адекватно. Дитячее оно.

 

Есть объяснение попроще:

 

регресс — обратная сторона прогресса.

 

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

 

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

 

Однако увеличение функциональности приносит и увеличение взаимосвязей между функциями.

 

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

 

Римляне (которые древние) развивали экономику за счет увеличения количества рабов и присвоения новых территорий. В принципе, нормальная стратегия, с прогрессом, с ништяками. Вон, после захвата Дакии, римские граждане пять лет налоги не платили, бо награбленное в походе золото выправило бюджет всей империи. Но чем больше присоединяется земель, тем дальше от Рима уходят римские солдаты для установления конституц демократ правильного порядка, и тем больше рабов приезжают на гастроли в центр империи. И нате вам сицилийские восстания. И нате вам Спартак. И надо солдат туда-сюда возить, чтобы восстания гасить. А если солдаты в Риме, то бунты начинаются на окраинах...

 

Чтобы убедиться в том, что в существующей системе не начинается регресс, полезно иногда проводить ее полное тестирование.

 

И уж тем более логично перетестировать всё, что можно, если в систему были внесены какие-то существенные изменения.

 

Со стороны это выглядит как "Внесли новый функционал — обязательно перетестировываем всё!" Словно тестировщики в сотый раз прогоняют уже существующие тесты, вот и всё.

 

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

 

Поэтому регрессионное тестирование — нескончаемый кошмар, вообще-то... И выяснение "не наступил ли регресс" (внимание, не путать с "не наступила ли регрессия") — постоянная задача, которую также необходимо решать в контексте maintenance testing.

 

А это что за зверёныш? Есть достаточно адекватное определение майнтенанса из ISTQB:

 

Сопровождение (maintenance): Модификация программного продукта после его поставки с целью исправления дефектов, улучшения производительности или других характеристик или для адаптации продукта к изменившемуся окружению. [IEEE 1219]

 

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

 

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

 

Если вкратце ответить на ваш изначальный вопрос, то регрешн и майнтенанс в зависимости от стадии разработки проводятся по-разному. В начале проекта в этом нет необходимости ВООБЩЕ. Чем дальше в лес, тем больше регрешна, и уже почти постоянный майнтенанс.

 

Так понятно?

[Anya_Nika]

Спасибо за примеры - натолкнули на мысль.
Перечитала еще раз все определения в istqb, нарисовала майндмапу и все стало ясно :).
Maintenance и regression понятия не взаимоисключающие, как я думала изначально.

[astenix]

Гуд.