О вреде и пользе регрессионных тестов

Беседами в твитторах навеяно.

Излишняя концентрация на регрессионных тестах? Зачем?

Да, именно регрессионных тестах. Не в том смысле что "тесты которые показывают что качество стало хуже", а в смысле что "любые повторяемые из раза в раз тесты". Или еще хуже - "повторение steps to reproduce всех когда-либо найденных багов". Для некоторых это реально идеал тестирования, я не шучу (листать тут до слов "Идеальный тестировщик это серверная стойка забитая соответствующим железом", например + сочное видео в качестве бонуса).

Тут очень хочется процитировать статистику которую часто любит упоминать Болтон (например тут):

До появления Agile Manifesto группа опытных тест-менеджеров сообщили что регрессионные проблемы происходят примерно из 6-15% обнаруженных проблем.

Ну и оттуда же:

• Если мы видим пожар
• Каждый отдельный огонек не является "самой большой проблемой"
• Возможно нам было бы интересно узнать о проблемах постройки или о поджигателях
• Если мы видим систематически повторяющийся регрессионный шаблон
• Проваленные тесты не являются "самой большой проблемой"
• Возможно нас интересует благоприятная среда для этих регрессий

Ну и еще уже из твитторов:

Что программисты делают такого, что поломка работающего кода является самой большой проблемой для проекта? 

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

(ответ на вариант про "повторение steps to reproduce всех когда-либо найденных багов"): Из-за такого сорта глупостей нам нужно снимать ботинки в аэропорту. Только самые тупые баги используют одну и ту же стратегию для того чтобы избежать обнаружения.

Если уж у программистов все настолько плохо, что им нужен тотальный контроль на выходе на работающем коде, то может не стоит тратить деньги на этот тотальный контроль, а поменять то что внутри консерватории? TDD? Unit-test'ы наконец начать писать? Continous Integration? Хорошие логи для отличного обнаружения проблем? Отличные "ручки" для мониторинга работы приложения? Чаще и лучше привлекать своих клиентов к процессу разработки? Это все не новые вещи. Это все уже давно и весьма обширно освещается практически любыми деятелями от Agile.

Зато собеседования, опросы коллег, да и просто попытки заглянуть на профессиональные ресурсы демонстрируют нам, что первое, что пытаются автоматизировать это, как правило, регрессионные тесты. Все. На высоком уровне абстракции типа GUI. А еще классно было бы каждый когда-либо найденный баг тоже на автоматические проверки поставить (еще один эпичный пример). Наличие того что перечислено абзацем выше при этом совсем не обязательно. При этом стоит помнить что тестовые оракулы для высокоуровневых тестов как правило сложные и не прозрачные чисто логически, порой весьма трудозатратны в реализации и очень узкоприменимы. Стоит ли это недешевое дублирование Unit test'ов того? Покажет ли оно достаточно информации в случае сбоя, чтобы можно было быстро диагностировать проблему? Не думаю.

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

ЗЫ: В качестве бонуса про model-based тестирование уже - Томми Такала и Мико Катара из Техноголического Университета Тампере применяя свой model-based-testing софт для BBC News виджета на Андроиде сообщили следующие цифры - 2/3 обнаруженных этим методом проблем были обнаружены в процессе составления модели, а еще 1/3 после прогона этих тестов. Это не повод не заниматься этим в принципе, но повод составить модель даже если у вас нет ПО или ресурсов на полноценную автоматизацию (да, я знаю что в model-based тестировании составление модели это чуть ли не самая затратная часть).