вторник, 22 января 2013 г.

Обзор 1. Размышления о регрессионном тестировании от Майкла Болтона, или "все могло быть гораздо хуже".

Открываю серию постов-обзоров, постов-конспектов по очень полезным материалам по тестированию, которые, на мой взгляд, просто НУЖНО просмотреть-прочитать-прочувствовать и много других "про-" начинающему и не очень тестировщику.

Начну с темы, которая сейчас наиболее для меня актуальна - регрессионное тестирование. Автор - Майкл Болтон. Лекция "Things Could Get Worse: Ideas About Regression Testing" и презентация.



Почему регрессионное тестирование важно? 

С ростом проекта мы получаем рост сложности, функционала, числа тест-кейсов, которые нам необходимо будет запускать каждый раз. Растет объем регрессионного тестирования, проверок и тестирования, которые нам будет необходимо выполнять (в чем разница между тестированием и проверкой - "testing vs checking" - здесь). Времени на регрессионное тестирование не увеличивается, а если и увеличивается, то незначительно, недостаточно, чтобы выполнить его в том всевозрастающем с каждой итерацией объеме, котором нам нужно. А ошибки в регрессионном тестировании и обходятся "дороже", и иногда не настолько очевидны из-за сложности продукта.

Что же делать, как правильно распределить усилия на этом этапе?
Давайте посмотрим, что нам советует Майкл Болтон (далее ниже синим шрифтом - выдержки из лекции Майкла Болтона, черным стандартным - мои комментарии).

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

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

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

Тестирование против проверки (Проверка - процесс подтверждения, верификации и валидации. Тестирование - процесс поиска новой информации, это исследование, открытие, изучение).

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

Вместо того, чтобы думать, прошел тест или нет (Pass или Fail), опытные тестировщики задают вопрос "Есть ли здесь (в этом функционале) проблема?"

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

Если в регрессионном тестировании вы выделите недостаточно времени на проверки, это может привести к тому, что
- риски будут не обнаружены
- проблемы будут не обнаружены
- программа будет недостаточно изучена

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

"Тестирование важнее проверок" (дословно - "Testing Dominates checking") (c) Майкл Болтон

Проверки - это "пестициды", а тестирование - это нестандартные ходы. Пока не изобретено универсального пестицида от всех багов (а будет ли оно вообще изобретено?), тестирование просто необходимо, и без него не обойтись.

Функциональность - должна быть проверена. Производительность, масштабируемость, надежность, инсталляция - может быть проверена. Удобство использования, безопасность, совместимость, поддерживаемость, тестирумость - должна быть протестирована.

Выводы для себя: учимся писать автотесты для проверки и большего покрытия проверками функционала. То, что должно быть протестировано, нужно изучать и приобретать практику в изучении (удобство использования, безопасность).

Риск регрессионной зависимости - самый большой проектный риск? Нет, только в 6-15% случаях (опрос тест менеджеров).
Риск регрессионной зависимости - эмоциональный страх.

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

Способы снижения риска регрессионной зависимости в Agile:  разработка через тесты (Test Driven Development), модульные тесты (Unit Tests), парное тестирование, непрерывная интеграция (Continious Integration), контроль сборок и версий (Version and Build Control).

Оставим эту тему для отдельного озбора, вместе с ролью QA в Aglie-команде.

Даже самый лучший вратарь пропускает "неберущиеся" мячи. Даже самый лучший вратарь не спасет вас, если у вас слабая защита.

Тренируйте защиту, внедряйте проверки, и тренируйтесь сами как вратарь - "ближний угол вратаря", "20 копеек - это всегда обидно" и другие базовые навыки.

Как выбрать то, что нужно протестировать в регрессионном тестировании. Карен Джонсон, эвристика RCRCRC + автоматизированные проверки в регрессионном тестировании, Майкл Келли.

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

Стратегические идеи во время регрессионного тестирования (по клику начинается просмотр видео со слайда презентации).

На чем важно сфокусироваться, выполняя ту или иную активность. На этом месте можно вставить притчу о трех каменотесах. В тестировании то же самое: то, как вы воспринимаете свою работу, так вы ее и выполняете.

На этом все. Спасибо за внимание, и успехов вам в регрессионном тетсировании!