5 ценных советов о том, как предотвратить наиболее распространенные ошибки при автоматизации тестирования

Хотели ли вы когда-нибудь сделать автоматизацию тестирования легкой? Быстро обнаруживать и устранять проблемы без бесконечной отладки или обслуживания скриптов? Да, я тоже. Это мечта каждого QA-профессионала, но давайте посмотрим правде в глаза — обычно это всего лишь мечта.

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

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

О спикере

Пол Гриззаффи, старший главный архитектор автоматизации

Будучи старшим главным архитектором автоматизации, Пол Гриззаффи увлечен предоставлением технологических решений для организаций по тестированию, QE и QA. Его экспертиза включает в себя оценку автоматизации, внедрение и деятельность, приносящую пользу более широкому сообществу тестирования. Опытный основной докладчик и писатель, Пол выступал как на местных, так и на национальных конференциях и встречах. Он является членом отраслевого консультативного совета Центра передовых исследований по тестированию программного обеспечения и обеспечению качества (STQA) в Техасском университете в Далласе, где он часто выступает в качестве приглашенного лектора.

Вы можете следить за Полом наLinkedIn, Х, и егоблог.

Что является продуктом автоматизации тестирования?

Автоматизация — это программное обеспечение, будь то запись и воспроизведение, перетаскивание, сгенерированное ИИ или код, написанный на JavaScript, C#, Python или любом другом языке. Это все программное обеспечение. Как только мы понимаем, что программное обеспечение выполняет для нас задачи, мы осознаем, что само программное обеспечение является продуктом.

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

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

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

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

# 1. Следуйте трем «способностям» для автоматизации тестирования

Чтобы автоматизация была ценной, она должна обеспечивать ценность.

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

Доступный. Доступность кажется очевидной, однако Пол столкнулся с клиентом, чья инициатива по автоматизации тестирования провалилась отчасти из-за того, что отчетность и ведение журнала были недоступны. «Что я имею в виду под «недоступно»? Журналы хранились в месте, недоступном для тех, кому они были нужны. Хотя это может показаться тривиальным с такими инструментами, как Jenkins или Azure DevOps, обеспечение того, чтобы все знали, где находятся журналы, и имели необходимые лицензии и авторизацию для доступа к ним, имеет важное значение. Без этого журналы становятся бесполезными, потому что с ними нельзя работать», — пояснил Пол Гриззаффи.

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

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

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

# 2. Доверьтесь автоматизации тестирования

Журналы — это ваш мост между тем, что делает для вас машина, и тем, что вы обычно делаете вручную. Поэтому доверие необходимо. Если вы не доверяете своей автоматизации, вы все равно можете ее запустить, но, скорее всего, вы будете перепроверять многие вещи, повторно запуская некоторые задачи вручную. Это снижает ценность вашей автоматизации, поскольку если вам придется переделывать задачи, которые должна была выполнять автоматизация, ее ценность будет скомпрометирована. Таким образом, вам необходимо иметь определенный уровень доверия — подход «доверяй, но проверяй». Периодический аудит вашей автоматизации гарантирует, что она работает так, как и ожидалось. Без доверия ценность автоматизации уменьшается.

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

1. Видимость. Видимость — это главный способ завоевать доверие. Поймите, что делает автоматизация, сделав код и журналы доступными. Включите в журналы достаточно подробностей, чтобы точно знать, какие действия выполняет автоматизация. Например, журналы должны показывать такие действия, как «Я нажал это», «Я отправил это сообщение», «Я получил этот ответ» и другую соответствующую информацию. Таким образом, если что-то покажется вам странным, вы сможете просмотреть журналы, чтобы определить, виновата ли автоматизация или ваши предположения неверны.
2. Прозрачность в журналах. Журналы должны четко показывать, что произошло, а что нет. Если чего-то нет в журнале, возможно, этого не произошло, что является еще одним аспектом доверия. Прозрачность имеет решающее значение, потому что без доверия не будет никакой ценности. Если вы не доверяете автоматизации, вы не будете полагаться на нее, что приведет к тому, что вам придется переделывать задачи вручную. Это сводит на нет смысл инвестирования времени, усилий и денег в создание автоматизации в первую очередь.

# 3. Сокращение затрат за счет правильной регистрации

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

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

Таким образом, правильная ведение лесозаготовок может сократить затраты за счет:

Улучшение обнаружения проблем: Быстрое определение того, что пошло не так.

Минимизация времени отладки: Сокращение времени, затрачиваемого на выявление и устранение проблем.

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

# 4. Применяйте «хорошие журналы»

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

Итак, как выглядят хорошие бревна?

Достаточно информации:

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

Фильтруемый:

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

Руководство по отладке:

Журналы должны показывать, что было сделано и каков был ожидаемый результат. Например, «Я отправил 12 и ожидал 4, но получил 3». Это дает подсказки, с чего начать отладку, например, ошибка в расчетах или проблема связи с третьей стороной.

Значимая и практическая информация:

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

Визуальные журналы:

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

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

Пол дает дополнительные пояснения относительно того, как выглядят «хорошие» журналы:

«Я музыкальный парень, и, конечно, копий «Bark at the Moon» Оззи никогда не бывает слишком много». Представьте, что я хочу купить «Bark at the Moon» снова, но транзакция не удалась. Что-то в моем тестовом скрипте привело к сбою функции добавления в корзину. Представьте себе журналы, в которых просто указано: «Не удалось добавить «Bark at the Moon» в корзину». Хотя это и полезно, но больше подробностей было бы полезно».

Например, если вы получите снимок экрана вместе с журналом, вы можете увидеть, что кнопка «добавить в корзину» отсутствует. Если ее не видно, вам нужно больше подробностей. Более глубокий журнал может показывать: «Не удалось найти кнопку „добавить в корзину“ при попытке нажать ее». Это говорит вам, что тест пытался нажать кнопку, но инструмент не смог ее найти. Почему? Конкретный веб-элемент с определенным идентификатором не был найден.

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

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

Рекомендации для практиков по работе с журналами:

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

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

Убедитесь, что журналы являются полными и содержательными.Журналы должны предоставлять информацию, на которую можно ссылаться. Например, «Ожидалось 4, но получено 3» — это информация, на которую можно ссылаться. Избегайте журналов, требующих обращения к внешним источникам для понимания проблемы.

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

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

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

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

# 5. Найдите идеальный инструмент для автоматизации тестирования

«Однажды на конференции один из поставщиков задал вопрос, который застал меня врасплох: «Чего бы вы хотели, если бы разрабатывали инструмент автоматизации тестирования?» Это был вопрос, наводящий на размышления, на который я в то время не подготовил полноценного доклада. Однако с годами мои мысли о том, чего я хочу и что мне нужно от такого инструмента, особенно в плане ведения журнала, значительно изменились», — вспоминает Пол.

Итак, как выглядит идеальный инструмент автоматизации тестирования для такого профессионала высокого уровня, как Пол Гриззаффи?

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

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

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

Выносы

• Помните, в этой среде, если вы относитесь к автоматизации как к программному обеспечению, как и должно быть, информация становится продуктом. Мы должны создавать журналы, которые предоставляют информацию в том виде, который является уместным, усвояемым и пригодным для использования.
• При работе с журналами и отчетами помните о трех «возможностях» (доступность, применимость и понятность).
• Рассмотрите возможность сокращения времени обратной связи: как быстро можно предпринять действия по этим журналам, чтобы понять, что происходит? Сокращение времени обратной связи сократит время устранения проблем и снизит издержки упущенных возможностей.
• Доверие абсолютно необходимо. Если вы не доверяете своей автоматизации, вы не будете использовать ее эффективно, и она не будет эффективна для вас. Соответствующие журналы могут помочь построить доверие, поскольку они предоставляют четкий след хлебных крошек о том, что скрипты и инструменты сделали или не сделали.