Автор: Виктор Славчев (Viktor Slavchev).

Оригинал статьи

Перевод: Ольга Алифанова.

Этот ретроспективный урок автоматизации посвящен ее моделям. Когда мы говорим "модель" или "смоделировать", мы обычно имеем в виду "трехмерное представление персоны или вещи или структуры, обычно имеющее меньший в сравнении с оригиналом масштаб" (случайное определение из Google, к счастью, верное).

Говоря о моделировании автоматизации, мы подразумеваем представление структуры автоматизированных проверок, которые мы проводим, и их распределение по разным слоям.

Модели автоматизации: тест-пирамида

"Тест-пирамида" Мартина Фаулера – это то, без чего не обходится практически любая конференция, посвященная автоматизации или тестированию. Вообще-то изначально она была придумана Майком Коном в книге "Преуспевай с Agile", которую тоже приписывают Фаулеру. Вы неоднократно встретите различные изображения этой пирамиды, увидите ее в форме конуса, воронки, с облаками наверху, и т. д.

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

Мои скромные уроки о пирамиде

Тест-пирамида провоцирует одну из "священных войн" в тестировании, и я прилично рискую, говоря о ней. Очевидные комментарии к пирамиде – она повсеместно распространена, она проста, и всем понятна. Но именно из-за своей простоты она открыта для множества субъективных интерпретаций.

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

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

Хорошее

Что хорошо в пирамиде, так это то, что ее легко продемонстрировать, и легко понять.

Она отлично подходит для демонстрации того, что автоматизировать можно не только на уровне интерфейса. Аминь!

Она также хороша для объяснения подходов к автоматизации тем, кто не владеет технической стороной тестирования и разработки – например, менеджерам проекта, продакт-оунерам, менеджменту, и т. д.

Плохое

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

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

Джеймс Бах говорил о том же самым, представляя свою эвристику "Круглой Земли". Рекомендую ознакомиться с его слайдами.

Скрытые измерения пирамиды

Мартин Фаулер намекал на них в его представленной выше модели: у пирамиды есть ряд скрытых измерений, о которых мы зачастую забываем. Некоторые из них достаточно прямолинейны, и все из них зеркальны (как перевернутая пирамида), но для меня они проясняют то, почему люди иногда делают безумные вещи – например, концентрируются исключительно на UI-проверках.

Перевернутая пирамида сложности проверок и временных затрат

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

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

Итак, встает резонный вопрос – почему, учитывая все сказанное, кто-то все еще сходит с ума и пишет тесты для UI и только UI? И вот ответ:

Перевернутая пирамида видимости отказов

Веская причина автоматизировать на уровне интерфейса заключается в том, что такие тесты дают нам глубочайшее понимание, как проблема влияет на наших пользователей. Подумайте об этом. У вас есть упавший юнит-тест – ожидалось 4, а вы получили 0. Отлично, мы нашли баг, но насколько он значим для пользователя? Программа зависнет? Выдаст ошибку? Пустую страницу, стек-трейс? Мы без понятия, мы можем только гадать. Поэтому имеет смысл вкладываться в UI и API-тесты: чем ближе мы к клиенту, тем лучше мы понимаем глубину и реальные последствия проблемы. Конечно, у такого бонуса есть цена.

Я много размышлял о пирамиде, но чуть ранее я уже говорил, что не считаю ее "пирамидой тестирования", только "пирамидой автоматизации". Почему же?

Это вообще не пирамида

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

Вот кривоватая, созданная мною схема. Наслаждайтесь.

Я называю ее айсбергом, потому что зачастую вижу, что люди обсуждают только видимые части – проверки, слои, внедрение, инструменты, практики…

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

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

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

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

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