Автор: Баз Дейкстра (Bas Dijkstra)
Оригинал статьи
Перевод: Ольга Алифанова

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

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

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

Обратите внимание, что всякий раз, когда я использую слово «тест» в оставшейся части этой статьи, я имею в виду автоматизированный тест / проверку, которая подтверждает или опровергает ожидания относительно поведения нашего продукта. Не думаю, что эта модель так же хорошо применима к исследовательскому тестированию (но буду рад, если меня опровергнут).

Зачем нужна другая модель?

Несмотря на то, что пирамида автоматизации тестирования всё ещё полезна в определённых контекстах, в ней, на мой взгляд, отсутствует несколько важных моментов:

• Уровни и их границы: я иногда шучу, что если попросить у пяти разработчиков определение модульного теста, получишь как минимум шесть разных ответов. Люди и команды используют разные определения того, что такое модульный / интеграционный / E2E тест, и где заканчивается один и начинается другой. Это часто приводит к путанице и бесконечным спорам о том, что будет (или нет) модульным тестом, а я предпочёл бы сохранить энергию для более важных обсуждений.
• Сама модель: в пирамиде полностью отсутствует представление ценности теста. Да-да, я знаю, это всего лишь модель, и все модели неверны. Однако о том, сколько вообще нужно тестировать, какая часть этого тестирования должна быть автоматизирована, какая часть этой автоматизации должна быть на уровне модульных / интеграционных / E2E тестов и каким должно быть количество покрытия строк / ветвей / методов / требований, говорят очень много – но крайне мало разговаривают о ценности наших тестов. Я думаю, нам нужна модель, которая это хотя бы учитывает.
• Разговоры о модели и ее использование: как я уже сказал, о форме модели и о том, что она говорит о соотношении модульных, интеграционных и E2E тестов, говорят очень много. И знаете что? Меня это не особенно волнует. Мне неинтересно, как именно выглядят ваши соотношения — будь то пирамида (ну, на самом деле треугольник), песочные часы, рожок мороженого или какая-то другая форма. Всё это допустимо, пока ваши тесты эффективны и ценны. Другими словами, я думаю, что есть более удачные способы вести разговор о ваших тестах и о ценности, которую они дают, и нам нужна модель, которая это позволяет.

Итак, что же взамен?

Моя нынешняя ментальная модель (классификации) тестов

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

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

С учётом этих двух вещей сейчас моя ментальная модель для бесед об автоматизированных тестах выглядит так:

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

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

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

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

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

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

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

Используйте квадрант автоматизации тестирования для оценки вашей текущей ситуации

Если вы решите воспользоваться этой моделью, сперва я рекомендую разместить ваши тесты где-то в одном из квадрантов. Конечно, точное место будет различаться для разных типов тестов и даже для отдельных тестов. В этом, если спросите меня, и есть преимущество модели: её можно применять как ко всему набору тестов, так и к отдельным видам тестов и даже к отдельным тест-кейсам.

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

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

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

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

Проиллюстрируем вышесказанное картинкой:

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

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

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

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

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

• Собирать данные о нестабильных тестах, пытаться найти первопричину их нестабильности и устранять проблемы
• Тестировать ваши тесты, например, используя техники вроде мутационного тестирования, чтобы выявить потенциальные ложноотрицательные результаты и повысить эффективность набора тестов – например, в области граничных значений
• Улучшить отчётность набора тестов, чтобы сделать более понятным то, что именно произошло в случае сбоя.

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

Эта статья — лишь первое знакомство с моделью квадранта автоматизации тестирования, и здесь ещё есть много такого, что предстоит разобрать. Тем не менее, я с большим нетерпением жду вашей обратной связи и комментариев.

Тем временем я работаю не только над статьей с реальными примерами, но и над совершенно новым докладом об этой модели, который планирую представить на мероприятиях, митапах и конференциях в 2025 году. Возможно, и на вашей конференции тоже?

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