суббота, 1 октября 2011 г.

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

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


Излишняя концентрация на регрессионных тестах? Зачем?
Да, именно регрессионных тестах. Не в том смысле что "тесты которые показывают что качество стало хуже", а в смысле что "любые повторяемые из раза в раз тесты". Или еще хуже - "повторение 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 тестировании составление модели это чуть ли не самая затратная часть).

5 комментариев:

  1. Хыхы, я потом спрошу у тебя про наш случай

    ОтветитьУдалить
  2. Автоматизируем регрессионные тесты и радуемся получаемым результатам. Не все правда, а только те, которые "автоматизируемы"...
    Насчет дублирования Unit-тестов не совсем понял. Юнит-тестам свои цели , время и место в цикле разработки.. Регрессионным тестам функциональности(автоматическим или ручным) - свое. Более того, в динамично развивающихся продуктах никак нельзя ни без unit ни без регресса тестирования уже имеющейся ранее функциональности...

    ОтветитьУдалить
  3. Автоматизируемо в принципе все. Были бы время и деньги. Минимальный набор простых и быстрых тестов с элементарными оракулами как правило более чем достаточен. Дальше от специфики проекта зависит.
    Про дублирование unit test'ов все просто. Например писать кучу тестов которые заполняют форму и жмакают кнопочку submit как правило не имеет смысла, т.к. на уровне кода/апи эти случаи покрываются куда проще и делают все то же самое куда быстрее. Аналогично с валидаторами полей. Аналогично с загрузкой картинок. Не всегда, но как правило.

    В регрессионных тестах ничего плохого нет, если без фанатизма. Просто вспоминаем про 6-15% и думаем насколько пропорциональные усилия мы прилагаем. В том числе и в плане автоматизации. Ведь автоматизация регрессионных тестов это далеко не единственная возможная задача автоматизации тестирования в принципе.
    Опять же - плохие регрессионные тесты могут быть как ручными. Избыточные проверки вида "проверим каждый баг который когда-либо случался" это плохие регрессионные тесты. Жесткие сценарные тесты в регрессии кроме как автоматические change detector'ы как правило тоже не оправданы. А вот набор тестов для быстрого обнаружения ухудшения качества вполне ок.

    Опять же - регресс продукта это неприятно. Но те проблемы которые могут быть обнаружены тестами которые мы никогда не выполняли не менее неприятны

    ОтветитьУдалить
  4. Да-да, вот только по опыту очень сложно объяснить клиенту/менеджеру, что писать автоматические тесты на длинную цепочку операций с UI - нецелесообразно и затратно. "Selenium чё," - говорят в ответ - "значит квалификации недостаточно"

    ОтветитьУдалить
  5. Можно переубеждать, а можно просто взять денежку и сделать чего просят. Первое сложно, второе некрасиво (зато почти mortgage driven development).

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

    ОтветитьУдалить