Советы из Meta

• Качество, а не количество тестов
• Баланс
• Пирамида в Meta
• Мороженое
• Ручное тестирование — не главное
• Вред UI-тестов
• Песочные часы
• Вопросы и ответы

Дмитрий Винник, Engineering Manager в Meta, на конференции Testμ рассказал о QA-процессах в Mеtа. Он подчеркнул, что фокус его выступления не ограничивается крупными организациями; те же принципы могут быть применимы и к небольшим компаниям.

Качество, а не количество тестов

Во первых, важно качество, а не количество, когда речь идет о тестах. Этот принцип работает в таких технологических гигантах, как Mеtа, где важно убедиться, что каждый тест гарантированно улучшает качество софта. 

Любые организации, независимо от их размера, сталкиваются с проблемами, связанными с повышением требований к качеству. Здесь применима метафора «маленькие дети — маленькие проблемы, большие дети — большие проблемы». Незначительные проблемы в маленьких организациях могут стать серьезными, если компания растет.

Баланс

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

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

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

Пирамида 

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

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

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

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

Речь идет не о том, чтобы иметь много одних тестов и мало других. Речь идет о правильном сочетании модульных, интеграционных и сквозных тестов. Такой подход помогает достичь того что называют в Meta «эффективным софтом».

Проблема мороженого

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

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

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

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

Дмитрий рекомендует книгу Thе Pragmatic Programmеr — Explore It — Elisabeth Hendrickson. Эта книга содержит весьма ценную информацию, в том числе о тестировании и повышении качества программных продуктов.

Ручное тестирование — не главное

Ручное тестирование не должно быть главным. Причины следующие: 

• Ручное тестирование требует от человека специальных знаний, что делает процесс трудоемким и дорогостоящим, особенно для крупных и сложных программных систем. Эта трудоемкая работа может замедлить цикл разработки.
• Ручное тестирование может не охватывать все возможные сценарии событий из-за человеческих ограничений. Тестировщики могут непреднамеренно упускать из виду некоторые кейсы, или не предвидеть специфические действия пользователей. 
• На ручное тестирование может повлиять предвзятость тестера, его опыт или ожидания. Субъективность может привести к неверным результатам и пропуску дефектов, которые автотесты выявили бы нормально.
• Выполнение множества одинаковых ручных тестов может быть утомительным и увеличивает риск ошибок. Автотесты помогают точно и последовательно решать сложные задачи.
• По мере роста сложности продукта полагаться на ручное тестирование становится непрактичным. Это может привести к пробелам и снижению способности поддерживать темп. 
• Зависимость от ручного тестирования может привести к увеличению затрат и задержкам проекта из-за длительного цикла тестирования, особенно в крупных проектах.

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

Вред UI-тестов

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

Более того, увеличение количества UI-тестов приводит к таким проблемам, как избыточность и дублирование усилий различных команд. Существует ошибочное мнение, что большое количество UI-тестов обеспечивает высокое покрытие. На самом деле оно просто замедляет цикл обратной связи для разработчиков.

Следует внимательно относиться к растущим затратам на обслуживание, связанным с большим количеством UI-тестов.

Песочные часы

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

Необходимо активно привлекать разработчиков к работе над тестовым кодом и тестировщиков к работе над продакшен-кодом, поощряя сотрудничество между командами. 

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

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

Может быть полезным наличие в команде специального человека — Test Champion. В его обязанности входит постоянное редактирование тестов, для поддержания стандартов качества тестового кода. Общая цель — устранить разрыв между инженерами и тестерами, поощряя совместную ответственность за тесты и формируя культуру сотрудничества.

Тестирование — важнейший компонент петли фидбека, а не просто поиск дефектов.

Вопросы и ответы

• Вопрос: Могли бы вы привести пример того, как подход Meta к тестированию адаптируется к потребностям проекта, сохраняя при этом стандарты качества? 

Дмитрий: Существуют совершенно разные подходы к работе крупных организаций. Организации обычно придерживаются структурированного подхода, начиная с того, что я бы назвал «буткемпом».

Независимо от команды, в которую вы вступаете, обычно существует начальная процедура вхождения в должность, которая напоминает буткемп. Например, в Mеta эта подготовка может длиться несколько недель, в течение которых вы посещаете занятия, лекции, семинары и другие обучающие мероприятия. Цель этого этапа — ознакомить вас с продуктами, инструментами и практикой кодирования. Это включает изучение языков программирования, таких как Rust, Swift, Objеctivе-C, и принятие стиля кодирования, которого придерживается команда.

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

Например, если вы работаете с Java, вы можете придерживаться стиля кодирования Googlе в качестве базового. Это гарантирует, что, несмотря на некоторую гибкость в командах, сохраняется единообразие в стиле, например отступы и структура кода.

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

• Вопрос: Как подход Meta к тестированию справляется с различными девайсами, платформами и сетевыми условиями? 

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

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

• Вопрос: Насколько сложно работать автономно в команде в Meta? Много ли бюрократических проволочек приходится проходить, чтобы добиться результата? 

Дмитрий: В большой организации обязанности могут меняться в зависимости от контекста. Большое внимание уделяется автономии и межфункциональному сотрудничеству. 

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

• Вопрос: Встречались ли вам руководители проектов, которых было очень сложно заставить принять эти идеи/принципы?

Дмитрий: Разрешение конфликтов в коллективе, особенно при разногласиях с менеджером по продукту или высшим руководством, подразумевает сохранение объективного подхода. Важно доверять инсайтам менеджера. 

• Вопрос: Не могли бы вы рассказать о том, как развивается стратегия тестирования Meta по мере роста компании, оставаясь при этом Agile? 

Дмитрий: В контексте таких организаций, как Mеta, и их эволюции в сторону Agilе-методологий и быстрых циклов, маловероятно, что такие крупные компании как Meta когда-либо вернутся к практикам Waterfall.

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

Сосредоточьтесь на тестах, которые проверяют важные юзкейсы, а не погружайтесь в еdgе casеs.

Lambdatest

Видео на Ютюбе

Инструменты разработчиков в Meta: