Стратегия автоматизации тестов

Замер окупаемости

Разложу тот счёт целиком, потому что он и есть ответ на вопрос «зачем автоматизировать». ROI (return on investment, окупаемость вложений) считается так: экономия минус затраты. Экономия - цена ручного прогона, умноженная на частоту. Затраты - разработка один раз плюс поддержка каждый месяц.

Подставляем 8 часов ручного прогона, 30 часов на разработку, 6 часов поддержки в месяц. Релиз раз в месяц: экономия 8 минус поддержка 6 - остаётся 2 часа в месяц, окупаемость 15 месяцев. Релиз раз в неделю: 32 минус 6 - остаётся 26 часов, окупаемость 1,2 месяца. Релиз каждый день: 154 часа экономии, окупаемость меньше недели. Одни и те же тесты, разница только в частоте прогона.

// И обратный случай: если продукт штормит и поддержка съедает не 20%, а половину (15 часов в месяц), то при релизе раз в неделю окупаемость растягивается с 1,2 до 1,8 месяца. Отсюда правило: чем чаще гоняется и чем стабильнее объект проверки, тем выгоднее автоматизировать. Тест на фичу, которую переписывают каждую неделю, не окупится никогда.

ROI

return on investment: экономия от прогонов минус разработка и поддержка

цена поддержки

часы на починку тестов после изменений продукта, каждый месяц

Что автоматизируют и на каком уровне

Из формулы окупаемости прямо следует, что брать. Многократное и стабильное: регрессионный набор (перепроверка того, что работало раньше), смоук на каждую сборку (быстрая проверка, что приложение вообще живое), проверки договора между сервисами (что один отдаёт ровно то, чего ждёт другой), критичные денежные пути. Разовое, исследовательское и меняющееся каждую неделю остаётся руками.

Второй вопрос - на каком уровне проверять. Я замерял одну и ту же проверку расчёта корзины: прямой вызов функции 1,2 микросекунды, через реальную базу 13,9 микросекунды, через сетевой вызов к серверу 507 микросекунд. Разница в 422 раза, и это ещё без браузера. Отсюда правило: логику проверяем на самом нижнем уровне, где это возможно, а через интерфейс гоняем считанные сценарии целиком.

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

кандидат на автоматизацию

проверка, которая гоняется часто и меняется редко

выбор уровня

логику - функциями, договоры - вызовами, интерфейс - единицы сценариев

Поддержка - главная скрытая статья

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

Автотест - это код, который живёт вместе с продуктом. Значит, ему нужно то же, что коду: чтение коллегой перед вливанием, единый стиль, регулярная чистка и владелец, который его чинит. Скрипт, написанный на коленке и оставленный без хозяина, умирает за квартал - не потому что плохо написан, а потому что продукт уехал вперёд.

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

автотест как код

ревью, стандарты, владелец; иначе умирает за квартал

пустая метрика

число тестов растёт, а решений на нём не принимают

Как отвечать: «Что автоматизировать, а что оставить руками?»

Решаю счётом, а не по ощущению. Экономия от автотеста - это цена ручного прогона, умноженная на частоту, а затраты - разработка один раз плюс поддержка каждый месяц. Считал на живом примере: регресс из сорока кейсов руками занимает восемь часов, автоматизировать их - около тридцати часов, поддержка примерно шесть часов в месяц. При релизе раз в месяц такая автоматизация окупается через пятнадцать месяцев, а при релизе раз в неделю - через полтора. То есть решает частота прогона. Поэтому автоматизирую регресс, смоук на каждую сборку, проверки договоров между сервисами и критичные денежные пути. Оставляю руками исследовательское тестирование, разовые проверки и фичи, которые ещё активно меняются - тест на такую фичу переписывается быстрее, чем окупается. Уровень выбираю по цене: я мерил одну и ту же проверку - прямой вызов функции против вызова через сеть, разница в четыреста с лишним раз. Значит, логику проверяю на нижнем уровне, а через интерфейс гоняю несколько критичных сценариев. И всегда закладываю поддержку в оценку, потому что после редизайна из шести способов найти кнопку у меня выжило два.

Почему это сильный ответ: критерий назван формулой и подкреплён счётом, где ответ меняется от частоты релизов; выбор уровня обоснован замером; поддержка учтена как отдельная статья.

На чём валят

• −Считать окупаемость без поддержки: при релизе раз в месяц она превращает 4 прогона в 15 месяцев.
• −Автоматизировать фичу, которую переписывают еженедельно, - тест не доживёт до окупаемости.
• −Гнать всё через интерфейс: та же проверка стоит в сотни раз дороже и ломается от любого редизайна.
• −Отчитываться количеством автотестов - тысяча, которым не верят, хуже сотни надёжных.
• −Оставить набор без владельца: продукт уезжает вперёд, и за квартал тесты умирают.