Автор: Джеймс Бах (James Bach)
Оригинал статьи
Перевод: Ольга Алифанова

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

1. Вместо пирамиды ситуация моделируется как концентрические сферы, потому что "внешняя" поверхность сложной системы обычно имеет больший значимый масштаб.
2. Основана на определенном сферическом объекте по имени "Земля", знакомом всем, потому что мы живем на его дружелюбной, гостеприимной поверхности.
3. Иллюстрируется при помощи перевернутой пирамиды, дабы сделать акцент на том, что наше внимание и беспокойство в основном связаны с поверхностью продукта, "где живут люди". Еще это сделано с целью обозначить контраст с пирамидальной формы Пирамиды Тест-Автоматизации, предполагающей, что пользовательский опыт заслуживает минимального внимания.
4. В аналогию встроены как статические, так и динамические элементы (данные, а не только код).
5. Модель признает, что мы, скорее всего, не сможем (или не будем) напрямую тестировать самые низшие уровни нашей технологии (то есть Chrome, Node.js или Android OS). Вообще-то нас поощряют доверять этим уровням, потому что мы мало что можем с ними сделать.
6. Геофизическая аналогия используется для более интуитивно понятного объяснения, почему хорошая инструментальная стратегия позволяет получить доступ к продукту и протестировать его на подпочвенном уровне – что необязательно означает "на уровень ниже платформ, на которые мы полагаемся".

Хорошие аналогии требуют глубоких размышлений

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

Использовать семантически необоснованные символы для коммуникаций, конечно, можно (по форме буквы W и М полностью противоположны, однако всем наплевать на то, что то, что эти буквы представляют собой – не противоположности). Однако это в лучшем случае слабая форма коммуникации. Более сильные формы получаются при использовании символов, которые позволяют полезным образом размышлять об обсуждаемой проблеме.

Модель круглой земли пытается добиться именно этого. Думая о технологии, как о концентрических сферах, вы понимаете, что объем возможностей – объем состояний продукта – имеет склонность резко возрастать с каждым слоем. Конечно, это необязательно так, потому что множество сложностей может быть отрезано от верхних уровней нижними уровнями. Однако это реальная и ощутимая опасность для каждого нового слоя, который вы добавляете к стеку своих технологий. Пример этого риска в действии – это недавнее открытие, что HTML-емейлы берут верх над безопасностью PGP-емейлов. Упс. Чем больше у вас свистелок, дуделок и слоев, тем более вероятно, что какой-то уровень абстракции будет критически дырявым. Один из примеров дырявой абстракции – это концепция "твердой земли", которая буквально и фигурально протечет, когда из земли польется горячая лава. Программное обеспечение строится на понятиях, которые еще более абстрактны, и в целом более склонны протечь, чем твердая земля.

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

Примечание: если вы хотите поразмыслить, из чего состоит хорошая аналогия, то у Майкла Болтона есть хорошая статья на эту тему (внимание – он называет это метафорой, но я считаю, что он говорит об аналогиях).

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

В нижней части оригинальной пирамиды находятся юнит-тесты. В нижней части модели круглой земли находится фреймворк приложения, его операционное окружение и окружение разработки – иными словами, Платформа, Которую Мы Не Тестируем. Возможно, ее тестирует кто-то другой, а может, и нет. Однако мы этого не знаем и, скорее всего, даже не думаем об этом. Как-то раз я написал код на Ассемблере, чтобы разрабатывать игры в 16 384 байтах памяти. Мне нужно было управлять каждым байтом. Эти времена прошли. Теперь я пишу на Perl и не задумываюсь о памяти. Как по мне, теперь этим заняты волшебные эльфы.

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

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

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

[Hinds, P. J. (1999). The curse of expertise: The effects of expertise and debiasing methods on prediction of novice performance. Journal of Experimental Psychology: Applied, 5(2), 205–221. doi:10.1037/1076-898x.5.2.205]

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

Модель круглой земли напоминает нам о данных

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

Модель круглой земли напоминает нам о тестируемости

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

Эпиграммы

• Качество на верхнем уровне требует качества на нижнем уровне.
• Качество на верхнем уровне снижает зависимость от дорогого высокоуровневого тестирования.
• Дешевое низкоуровневое тестирование снижает зависимость от дорогого высокоуровневого тестирования.
• Риск растет по направлению к пользователю.