Автоматическое тестирование по сравнению с обычным, источник

Стартап Antithesis Operations LLC создан разработчиками известной системы FoundationDB. Они говорят, что между двумя продуктами много общего: «Когда в 2010 году мы взялись за создание масштабируемой, отказоустойчивой распределённой базы данных с ACID-транзакциями, большинство людей не думали, что такое возможно. Вот и сейчас многие не верят в полную автоматизацию тестирования».

Сейчас они уверены, что произвели революцию в разработке программного обеспечения. Они сделали полностью автономную и детерминированную систему автоматического тестирования. Внедрение системы в их собственной компании ускорило разработку в 50 раз, потому что программисты теперь думают только о коде и не боятся ошибок. 100% багов выявляется автоматически. Вручную писать тесты не надо, никаких тестировщиков, SDET и QA. Двое-трое программистов выполняют работу за 100−150 человек. Настоящая сказка!

▍ Теория ограничений. Всё хотят автоматизировать

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

Так вот, среди менеджеров в IT-индустрии бытует мнение, что тестирование, поиск и исправление багов — то самое «ключевое ограничение» в полном цикле разработки, деплоя и поддержки ПО. На первый взгляд это действительно так. Многие разработчики вынуждены бóльшую часть времени тратить не на написание нового кода, а на обслуживание старого, включая поиск и устранение багов.

К сожалению, некорректное применение теории ограничений иногда приводит к гиперреакции со стороны «эффективных менеджеров». Они пытаются максимально снизить затраты на тестирование и деплой. А как это сделать? Правильно, за счёт максимальной автоматизации. Поэтому сейчас со всех стороны мы слышим о новых перспективных методах автоматизации тестирования, развёртывания, поиска багов, а также всех остальных операций DevOps. Это одна из актуальных тем в IT-индустрии — автоматизировать всё, что возможно.

Раньше в «экстремистской» компании Meta вообще отсутствовали роли QA или SDET (Software Development Engineer in Test), хотя сейчас вроде появились. Но всё равно у экстремистов тестирование максимально автоматизировано, полагается на фидбек от пользователей, программы bug bounty и Development-Driven Approach в стиле TDD, когда тесты пишут сами разработчики. При этом от разработчиков ждут невероятной скорости, не обращая внимания на ошибки. Воспоминания от бывшего сотрудника (приведено фрагментарно):

1. Все новые сотрудники должны настроить среду разработки в первый день и выпустить публичный коммит на второй день. Это безумно быстро по сравнению с большинством компаний, где от новичков не ожидают коммитов две-три недели.
   
2. Мы праздновали, когда кто-то впервые что-то сломал. Это становилось публичным событием через рассылку поздравлений всему инженерному составу. Важно избавиться от чувства стыда, связанного с ошибкой. Скорость неизбежно влечёт за собой ошибки —и единственной непростительной ошибкой считается задержка.
   
3. Мы просили прощения, но никогда не просили разрешения. Любой может залезть в любую часть кодовой базы, чтобы исправить ошибку или добавить функцию. Да, это может привести к новым ошибкам. Но это приемлемый компромисс. Никогда не было никаких упрёков по поводу того, кто внёс ошибку, из-за которой сайт упал. Только героическая история, насколько героически действовала команда по исправлению бага. Этот важная часть менталитета «полного владения», когда каждый считается причастным ко всей кодовой базе целиком.
   
4. Мы отмечаем и продвигаем самых производительных разработчиков, а не тех, кто решил самые сложные или интересные проблемы. То есть количество важнее качества.
   
5. Особое внимание уделяется процессам и процедурам восстановления после сбоев: это тестирование, работа группы реагирования (Incident Response Review), NOC-центров (для постоянного мониторинга) и инструментов в целом. Этим занимается команда TechOps. Поскольку культура изначально допускает ошибки, то восстановление после сбоев — приоритетная задача.

Разработчики-экстремисты в офисе Meta*, источник

Интересно ещё, что в Meta принципиально не используют систему контроля версий Git, и вообще работа с монорепозиторием организована довольно нестандартно.

В Microsoft после 2015 года подход к тестированию сильно изменили. Вместо end-to-end-тестов преимущественно стали использоваться юнит-тесты:





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

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

Это напоминает, как миллионеры Кремниевой долины ограничивают экранное время у своих детей и отправляют их в дорогие частные школы, где запрещено использование смартфонов и ноутбуков. То есть массовый продукт создаётся для плебса, для толпы, для повышения продаж и красивых цифр KPI, исключительно ради прибыли. Результаты этого мы видим в отупении интерфейсов и ожирении программ, которые набиваются ненужным функционалом просто чтобы имитировать бурную деятельность и оправдать выпуск никому не нужных новых версий. Куча простейших багов никого не удивляет, потому что продукт по-настоящему не тестировался перед выпуском на все возможные нестандартные ситуации. Разработчик проверяет только happy path для реализованной функции — и удовлетворяется этим.



Общий упадок престижа и неуважение к специальности QA Engineer болезненно воспринимается людьми, отдавшими этой профессии многие годы своей жизни и карьеры. А теперь начальство хочет максимально всё автоматизировать, свести к минимуму человеческое участие и всех уволить. Поиск багов по сути перекладывают на пользователей (это синоним фразы «мы выпускаем мусор и нас это устраивает»).

Но сокращение отдела QA — одна из худших ошибок, которые можно допустить в компании. Вот некоторые возможные последствия от такого сокращения:

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

В конце концов, ведь «QA» обозначает «обеспечение качества». Кто-то должен за это отвечать. Эти люди лучше всех в компании понимают работу продукта с точки зрения пользователя. Они болеют за качество и с печалью смотрят на быстрых менеджеров, которые под лозунгом «Move fast and break things» гонят разработчиков вперёд, не думая о том, как разгребать последствия. Такие товарищи продвигаются по карьерной лестнице. Начальство премирует за цинизм и равнодушие. Чем меньше думаешь о людях, а больше о KPI — тем успешнее карьера.

Тем временем попытки автоматизировать тестирование продолжаются с новой силой…

▍ Antithesis

Платформа Antithesis от создателей FoundationDB — это система полностью автономного детерминированного тестирования. Она непрерывно ищет баги софта в симулированной среде, где все проблемы идеально воспроизводятся, что позволяет отлаживать самые сложные проблемы.

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

Стартап Antithesis без особой огласки вёл разработку в течение пяти лет — а сейчас объявил о первых результатах. Разработка получилась настолько многообещающая, что создатели уже заключили контракт с компанией Palantir (которая сотрудничает со спецслужбами США в задачах дата-майнинга и аналитики). Они пока не могут рассказать о системе во всех подробностях. Только обрисовать общие детали.


Юнит-тесты и автоматизированное тестирование Antithesis, источник

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

void test1() {
    a();
}

void test2() {
    b();
}

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

void test3() {
    a();
    b();
}

void test4() {
    b();
    a();
}

Но и этого недостаточно. А что, если в какой-то функции утечка памяти, которая проявится при десяти-, сто-, тысячекратном повторении? И система тестов разрастается до бесконечного размера:

void test37411() {
    b();
    a();
    a();
    a();
    a();
    b();
    a();
    ...etc.
}

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

Базовый подход Antithesis — использовать случайные значения. Например, следующий код в итоге сгенерирует все комбинации двух функций размером до сотни:

void choose_function() {
    return antithesis.random.choose([a,b]);
}

void test() {
    for (int i = 0; i<100; i++) {
        func = choose_function();
        func();
    }
}

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

Платформа Antithesis ускоряет процесс, используя специальные инструменты покрытия кода, вероятностные утверждения в стиле иногда x < 1) и другие формы обратной связи для выбора путей исполнения кода.

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


Как работает Antithesis, источник

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

Каждый раз, когда разработчики добавляют новый код, Antithesis запускает его и ищет проблемы. В процессе искусственно создаются сбои (например, повторные сетевые попытки, зависания потоков или перезагрузки узлов) и анализируется поведение ПО. Когда Antithesis замечает интересное или редкое поведение, он делает копию состояния системы и исследует множество возможных вариантов развития событий, начиная с этой точки. Любой путь, который увеличивает покрытие кода или выдаёт редкие сообщения журнала, исследуется более интенсивно. Такое ветвление происходит много тысяч раз в каждом тестовом прогоне.

Среда моделирования Antithesis полностью детерминирована, поэтому все обнаруженные проблемы всегда можно воспроизвести. Это означает, что не существует нестабильных тестов, а «странные загадки» в продакшне можно обнаружить и диагностировать. Записывается не только момент возникновения проблемы, но и каждый момент, предшествующий её появлению. Всё можно воспроизвести даже спустя недели или месяцы после выполнения теста.

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



Изначально система автоматического тестирования Antithesis была написана авторами для поиска багов в коде FoundationDB. Когда они нашли все существующие ошибки в СУБД, то поняли, что этот инструмент найдёт и любые новые ошибки. И вообще, любые ошибки в чём угодно. «После такого [открытия] программирование кажется совершенно другим, — пишет Уилл Уилсон, разработчик системы и директор стартапа. — За всю свою карьеру мне довелось делать это всего несколько раз, и сложно передать это ощущение словами. Это как стать наполовину киборгом или надеть реактивный ранец, что-то в таком роде».

«Ты пишешь код, а потом спрашиваешь у компьютера, правильный ли он. Если нет, то пробуешь снова. Можете ли вы представить себе джинна или оракула, который всегда предупреждает вас, если вы где-то ошиблись? Ближайшее сравнение — это как некоторые говорят о программировании на Haskell или Rust, когда после получаса раздумий компилятор соглашается что-то скомпилировать, и вы можете быть уверены, что там на 100% нет определённого типа ошибок. Но есть предел тому, что может сказать компилятор. Я люблю мощную систему типов, но это не то же самое, что реально запустить ваше программное обеспечение в тысячах и тысячах безумных ситуаций, о которых вы и не мечтали.

Как только в FoundationDB мы достигли показателя в ноль ошибок и уверенности, что любые новые ошибки будут немедленно найдены — мы вошли в это благословенное состояние и полетели. Программирование в таком состоянии похоже на жизнь в окружении силового поля, которое защищает вас от любого вреда. Внезапно вы чувствуете, что можете рисковать. Мы делали безумные вещи. Удалили все наши забагованные зависимости (включая Zookeeper) и за очень короткое время написали собственную реализацию Paxos вообще без ошибок. Переписали всю подсистему обработки транзакций в СУБД, чтобы сделать её более быстрой и масштабируемой — совершенно безумный проект на удивление оказался успешным. И да, в нём тоже не было ошибок. Вся эта сложная система тестирования должна была повысить надёжность СУБД, но поразительно, что самый важный эффект оказался другим. Самый большой эффект заключался в том, что производительность нашей крошечной команды инженеров выросла в 50 раз.

В 2015 году компания Apple приобрела FoundationDB, начала использовать её как «основу своей облачной инфраструктуры», а спустя несколько лет открыла исходники. Примерно тогда у основателей возникла идея сделать из системы автоматического тестирования новый продукт — и новый стартап.

По заявлению разработчиков, внедрение автоматизированных тестов у них ускорило разработку в 50 раз. Конечно, это чисто субъективная оценка от авторов. Спустя некоторое время все желающие смогут проверить достоверность такой оценки, когда (и если) облачный сервис Antithesis запустят для всех. Если это правда, то разработчики наконец-то смогут сосредоточиться на любимом деле — на коде, а не поиске багов и написании тестов. Компании смогут на порядок ускорить разработку и сократить издержки, уволив последних QA-инженеров.



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

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

P. S. Сейчас облачный сервис Antithesis предлагается по цене $2 в час за CPU для «элитных» клиентов, но в будущем обещают доступные тарифы для малого бизнеса и бесплатный тариф для опенсорса.

*Meta запрещена в РФ как экстремистская организация.

Telegram-канал со скидками, розыгрышами призов и новостями IT ?