Home

Автор: Джеспер Оттосен (Jesper Ottosen)
Оригинал статьи
Перевод: Ольга Алифанова

В классических тест-техниках и подходах тестирование – редкий ресурс. Из-за временных и финансовых ограничений всегда требовалось учитывать риски, чтобы свести концы с концами. Теперь у нас есть инструменты и подходы, увеличивающие доходность тестирования за счет большего количества тестов и их частого и более раннего прогона.

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

• Приоритет MoScoW у тест-кейсов (Must-Should-Could-Would – должны прогнать, хотелось бы прогнать, сможем прогнать, прогоним). Однако когда менеджмент считает, что всего 20% тест-кейсов обязательны, бизнес просто требует больше тестов, пока не достигается требуемый уровень покрытия.
• Попарная комбинаторика и классы эквивалентности могут помочь снизить количество тестов, но, как правило, фокусируются на низкоуровневых полях ввода и форматах, а не на бизнес-задачах.
• Обсуждения, входит ли этот тест в регресс, в интеграционный набор, или во что-то еще. Иногда регресс-тесты значат больше, чем тесты новой функциональности. Иногда интеграционные и приемочные тесты кажутся одним и тем же – зачем тогда тестировать дважды? Бизнесу нужны не красивые слова, а результаты, неважно, под каким именем.

Подсчет тестов – это…

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

…и камни тоже пересекаются.

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

Фильтрация от всех возможных чисел к исчисляемому и финальному набору.

Старые издержки тестирования

Вышеописанная фильтрация исходит из посылки, что каждый подсчитанный тест имеет высокую цену, и, аналогично, что подготовка и прогон каждого теста дорого стоят. Средняя стоимость создания формального тест-кейса может легко достигать 3 часов и 1 часа на прогон – возможно, с 50% шансом на повторный прогон или дефект. Итого при 100 кейсах простая модель издержек будет такова: как минимум 450 часов, или 3 часа на тест, включая необходимость повторного прогона в 50% случаев.

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

Новый взгляд на доходность

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

• Read the Accelerate Book
• Many Bits under the Bridge
• Characteristics Change
• Could Modern Testing work in the enterprise

Теперь у каждого проекта будет свое соотношение автоматизированных тестов, но для простоты предположим, что 75% тестов могут быть автоматизированы или поддержаны инструментами так, что их прогон фактически ничего не стоит. К примеру, он прогоняется как часть непрерывного тестирования в CI/CD, и для этого не нужны ни руки, ни глаза.

Подготовка тестов все еще занимает время – допустим, те же три часа. Итак, 25 тестов без автоматизации все равно требуют 112,5 часов – но автоматизация (оставшиеся 75 тестов), чей прогон бесплатен, требует только 225 часов подготовки. Даже в этой простой модели издержек они снижены на 25% (с 450 часов до 337), включая повторный прогон 50% тестов.

Современный подход стремится сделать тесты изобильными и распространенными, а не редкостью (См. "Теорию ограничений" про узкие места). Если использовать выгоды CI/CD и полнокомандный подход к качеству, то согласно исследованию Accelerate будет наблюдаться корреляция с выгодой для бизнеса.

Так как прогон автотестов дешев, их можно запускать "по запросу". Давайте прогонять 25% ежедневно – регресс ли это? Может быть, какая нам разница. Предположим, мы прогоняем 25% случайных тестов в день в течение двух недель – это 250 тестов. Мы повысили количество прогонов тест-набора и количество прогонов каждого теста. С этим подходом наши затраты в 225 часов на подготовку тестов использовались при 250 прогонах, и мы в итоге потратили на прогон меньше часа.

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

Обсудить в форуме