TSQA 2022: Кодекс и стратегия автоматизации тестирования

В марте старший руководитель Abstracta Матиас Форнара и я имели возможность выступить на конференции Triangle Software Quality Association(TSQA) 2022.

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

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

Как оптимизировать качество вашей стратегии автоматизации тестирования и кода

Избегайте дублирования и переделок

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

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

Отличие тестов пользовательского интерфейса от сквозных тестов

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

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

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

Инструменты с открытым исходным кодом обычно можно получить бесплатно в том смысле, что не нужно платить за лицензию или подписку. Однако это не означает, что они приходят бесплатно. Как [Катя Аронова упомянула в этом выпуске подкаста Quality Sense] (https://abstracta.us/blog/podcast/quality-sense-podcast-katya-aronov/), «инструменты с открытым исходным кодом не бесплатны, если учесть все расходы, которые подразумеваются». В отличие от коммерческих инструментов, инструменты с открытым исходным кодом не предлагают обслуживания, тестовой инфраструктуры или технической поддержки, что оставляет интеграцию в руках тестировщиков. Это приводит к более высоким кривым обучения, для которых требуются опытные тестировщики и гораздо больше ресурсов, выделяемых для подготовки фреймворков и создания функций, которые уже есть в коммерческих инструментах.

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

Относитесь к своему тестовому коду так же хорошо, как и к рабочему коду

Тестирование является важным аспектом жизненного цикла разработки программного обеспечения, и поэтому необходимо, чтобы к тестовому коду относились так же серьезно, как и к производственному коду. Несмотря на то, что тестовый код не передается в производство, он по-прежнему является важным ресурсом документации, и он должен быть как можно более удобным в сопровождении и читабельным. Как упоминала [Энджи Джонс] (https://angiejones.tech/) в этом [руководстве по проведению проверок кода автоматизации тестирования] (https://applitools.com/blog/guide-to-test-automation-code-reviews/ ), «тестовый код — это то, что используется для определения качества вашего функционального кода, поэтому очень важно, чтобы он был тщательно разработан».

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

Проанализируйте свой код с помощью инструмента статического анализа кода

[SonarQube] (https://abstracta.us/blog/tools/code-analysis-part-2-analyzing-code-sonarqube/) — это платформа с открытым исходным кодом, которая выполняет автоматические проверки для оценки качества и безопасности кода. Использование этого или любого другого инструмента контроля качества помогает оптимизировать качество тестового кода, выявляя среди прочего уязвимости, ошибки и дублирование кода. Это также помогает тестировщикам улучшать свои навыки кодирования, обеспечивая постоянную обратную связь, но, что наиболее важно, это сохраняет технический долг видимый и простой в использовании.

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

За последние пару лет [инструменты тестирования с низким кодом] (https://abstracta.us/blog/software-testing/low-code-for-test-automation/) становятся все более популярными и важным аспектом тестирования. автоматизация. Однако, несмотря на то, что эти инструменты чрезвычайно полезны для повторяющихся и трудоемких задач тестирования, они не заменяют традиционные методы тестирования, а скорее являются идеальным дополнением, которое может помочь командам оптимизировать свою стратегию тестирования.

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

Создайте совместную команду

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

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

Расширьте взаимодействие вашей команды с помощью BDD

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

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

Включите в свою команду разные уровни старшинства

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

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

Несколько вопросов аудитории

• Что такое СУХОЕ, ВЛАЖНОЕ и ВЛАЖНОЕ?

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

Принципы программирования, такие как DRY (Не повторяйтесь), DAMP (Описательные и осмысленные фразы) и WET (Писать все дважды), являются примерами различных методов кодирования, которые могут применяться по-разному в зависимости от случая.

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

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

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

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

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

• Как определить, какие тестовые случаи подходят для автоматизации?

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

Длительные и сложные тесты

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

Повторяющиеся задачи

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

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

• Каковы ваши рекомендации по внедрению предотвращения тестирования?

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

• Качественные ворота обычно вызывают много споров. Как вы позволяете каждой команде работать в своем темпе?

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

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

• Что вы рекомендуете для автоматизированного тестирования, основанного на тестовых данных?

Есть много инструментов, которые позволяют нам получать подходящие данные для наших тестов. Google Analytics, например, предлагает информацию о том, какие страницы нуждаются в большем тестовом покрытии, а Test Data Manager предоставляет данные маскирование, подмножество и создание синтетических данных.

• Зачем нам нужно отделять ручное тестирование от автоматизации? Вы не можете автоматизировать, не прибегая при этом к «ручному» тестированию.

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

• Включили ли вы какие-либо подходы для понимания охвата вашей автоматизации тестирования?

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

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

Следите за нами в [Linkedin] (https://www.linkedin.com/company/abstracta/), [Twitter] (https://twitter.com/AbstractaUS), [Instagram] (https://www. instagram.com/we_are_abstracta/) и Facebook, чтобы стать частью нашего сообщества!

Эта история была впервые опубликована [здесь] (https://abstracta.us/blog/test-automation/tsqa-2022-recap-improving-test-automation-code-and-strategy/)