Регрессионный рай и ад

Да, я знаю, что я про это уже писал. Теперь попробуем разобраться в проблеме получше.

Что такое регрессия, я думаю знает каждый, кто занимается тестированием.

Набор регрессионных тестов у многих тоже наполняется по стандартному сценарию:

1. Написали и провели тесты для новой функциональности
2. Сохранили все это добро где-нибудь
3. Может быть нашли баги, написали тест для проверки фикса и тоже куда-то сохранили
4. Как только что-то изменилось - повторили первые три пункта.

Вот такой бесконечный цикл.

Так как эта раковая опухоль имеет свойство бесконтрольно расти (выше, собственно, приведен алгоритм бесконтрольного роста), то иногда добавляется еще вот такой пункт:

• Автоматизировать столько регрессионных тестов сколько сможем

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

Почему так? Ну, например, потому что страшный сон тестировщика, когда над нами стоит разгневанное высокое начальство и говорит: "Это работало, а теперь не работает. Почему вы это не протестировали? Вы же должны заниматься регресионными тестами!". А он же проверил все места где случались изменения! Сделал умно и правильно! И случилась какая-то мистика и сломалось там, где не должно было ломаться!
И бедный тестировщик такой:

И просыпается.

И бедный тестировщик заводит старую шарманку, и начинает проверять вообще все. Ведь там есть риски!

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

Еще из неприятного - старые баги. Т.е. был когда-то баг, его починили, а он опять появился. В самых клинических случаях доходим до разработки через баги: "Баг №1 починен, но баг №2 опять проявился... Баг №2 починен, но почему-то опять появился баг №1...". И так до бесконечности, пока кто-нибудь не поймет, что в текущей реализации требования, породившие оба бага, взаимоисключающие. Если система очень сложная, то на это может уйти очень много времени. Но как риск такая "разработка через баги" как правило не рассмаривается. А зря.

Бывают еще фантомные баги. Или баги-ниндзя, как я их называю. Они прячутся в потаенных глубинах кода, которые не всегда реально используются, или за другими багами. Через "черный ящик" такие баги, как правило, ловить очень сложно, а порой и вовсе невозможно.

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

Риски солидные, бороть их хочется.

Как бороть?

Во-первых, риски принято предотвращать:

• Для новых багов можно проводить ревью требований, приводящих к изменениям, и самих изменений. Если все будет делаться аккуратно, то ничего не сломается. Еще можно попытаться вникнуть вместе с разработчиками в то, что происходит. Попытаться помочь им осознать риски от того или иного решения. По мне, так это очень помогает уменьшить количество проблем в итоговом коде.
• Старые баги, как правило, постоянно проявляются потому, что у приложения образовались свои минные поля, изменения на которых череповаты. Очевидные минные поля разработчики, как правило, сами прекрасно знают. Не очень очевидные можно находить через попытки отследить шаблоны в появлении старых багов. Обнаружение и локализация этих минных полей тестировщиком поможет остальной команде (или менеджеру) заниматься хоть каким-то менеджментом рисков. Если они/он не желают с этими рисками справляться, то остается только молиться и брести в слепую по минному полю. Иногда работает. Рефакторинг, как средство разминирования, сильно помогает сократить количетсво (если не свести к нулю) старых багов. Часто, правда, почему-то предпочитают убивать кучу времени на регулярную починку симптомов, т.е. старых багов, чем заниматься рефакторингом. Но это обычная организационная близорукость, когда менеджер/команда не способны оценивать проблемы в долгосрочной перспективе.
• Ниндзя-баги предотвращать сложнее. Это, например, статический анализ для обнаружения мертвых или полу-мертвых кусков кода. Ну и предыдущие два пункта, как средства борьбы за стабилизацию тестируемого приложения, т.к. баги прятавшиеся за другими багами могут рассосаться сами по себе или расползтись по старым/новым багам.
• Просто факапы лечатся просто люлями, например, ликвидацией технического долга. Т.е. удаление старых и плохих инструментов, выстраивание инфраструктуры и так далее. Все это нужно для того, чтобы сократить возможность исполнителей стрелять себе в ноги. Деплой руками с сорцов, и деплой через тот же deployinator это две большие разницы.

Как видно, во многом вопросы предотвращения проблем это вопросы процесса. Грубо говоря: "чем здоровее процесс - тем меньше проблем".

Во-вторых, мы можем проверять, что все работает как раньше:

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

Вот она силища регрессионных тестов! Панацея!

В-третьих, можно попытаться доказать, что ничего не работает.

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

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

Теперь у нас есть:

1. В общих чертах риски, связанные с тем, что что-то изменили. Не бесформенная паранойя вида "всечтоугодноможетсломаться!", а мало-мальски оформленные риски.
2. Стратегии для того чтобы эти риски бороть (предотвращать/проверять, что все как раньше/искать баги).
3. Регрессионное тестирование, как повторение одних и тех же тестов раз за разом.

И как же регрессионное тестирование может помочь справиться с этими рисками?

Предотвратить? Не думаю. Регрессионные тесты работают с тем, что уже есть. Т.е. в плане предотвращения рисков тут полный провал.

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

Найти новые баги? Это второе больное место регрессионного тестирования, как стратегии:

1. Для начала можно ознакомиться с работой Брайана Марика "How Many Bugs Do Regression Tests. Find?". Или у Болтона посмотреть, цифры примерно те же. В плане нахождения багов регрессионное тестирование не очень эффективно. Тесты уже по меньшей мере один раз прогонялись и большая часть багов, которые можно было обнаружить, скорее всего обнаружена и починена. Дальнейшее повторение много новых багов не найдет, а времени скушает порядочно, если проводить после каждого изменения. На этом можно закончить, но...
2. При этом стоит помнить, что тестирование само по себе это сплошная проблема выборки. У нас бесконечный набор возможных тестов, и конечное время. Чем больше времени мы тратим на регрессионные тесты, тем меньше времени у нас на то, чтобы проводить другие тесты. А учитывая, что набор регрессионных тестов со временем совсем не сконен уменьшаться - времени на другие тесты будет все меньше и меньше. Нет, мы, конечно, можем нанять еще людей, но проблему это не решит.
3. Автоматизация может не спасти. Автоматические тесты могут оказаться сильно сложнее и дороже ручных, в плане разработки и поддержки. Помимо этого, они совсем тупые.  Они находят только то, что сказано, тогда как человек может заметить что-то еще. В этом плане выхлоп от автоматических тестов в контексте нахождения новых багов плохой (как правило, больше находится багов в процессе написания автоматических тестов, чем через год-два их существования).
4. Повторный прогон тестов на проверку фиксов багов во многом абсурден. Если баг починили и мы проверили, то все хорошо. Если старый фикс никуда не делся и никто его не менял и не трогал, то с чего бы этому багу опять появляться?
5. Старые тесты пропускают старые баги. Тот самый "парадокс пестицида". Прогон регрессионных тестов руками тут слабо помогает. Старый добрый баг, пропущенный давным давно, может хорошенько вырасти и отожраться. Новые баги, кстати, тоже скорее всего не найдет, т.к. тесты разработаны под одну среду, которая много раз потом изменится.

Т.е. само по себе регрессионное тестирование с проблемами регрессионных же рисков справляется плохо (с другими рисками еще хуже).

И!..

Ответ на самый главный вопрос!

"Как правильно бороться с регрессионными рисками?"

Никак.

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

Проблема в том, что это все сказочная страна. Реальность - редкая сука.

Редко когда можно постоянно заниматься рефакторингом.

Далеко не каждое изменение можно и нужно ревьювить.

Инструменты статического анализа генерят кучу левого шума, и этот хлам нужно разгребать.

Не везде есть возможность обвесить все что можно хорошими, годными юнит-тестами. Да и с автоматизацией местами, мягко говоря, не сахар.

...

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

Что это значит для тестировщика?

Это значит, что нужно работать над тем, чтобы не возникало неприятных сюрпризов типа "Это работало, а теперь не работает. Почему вы это не протестировали? Вы же должны заниматься [*(&%*^%$##@%&*] тестами!".

Нужно чтобы менеджмент понимал, чем занимается тестирование, и какие у их подхода есть риски/проблемы. Чтобы он понимал как это можно лечить, и принимал решения о том, насколько это оправдано для проекта. Нужно чтобы тестовая стратегия не шла вразрез с направлением движения проекта, а двигалась вместе с ним. 

Каждый должен понимать свой маневр. Каждый должен понимать куда движется армия. И только в этом случае мы можем говорить, что стратегия тестирования оправдана. Даже если со стороны она выглядит совсем сумасшедшей, контекст многое может оправдать.

ЗЫ: Маленький конспект для Сирожы - регрессионное тестирование в вакууме полнейший мусор. Как калькированный процесс - еще и пустая трата времени в проекте. Как осмысленный и тщательно продуманный процесс - может быть оправдано контектом. Надо спорить и обсуждать.