Введение

Если вы автоматизируете на Java или Kotlin, вы не могли не слышать о Gradle. Одни его хвалят за скорость и гибкость, другие ругают за сложность конфигурации. Что же это за инструмент и почему всё больше проектов переходят на него с Maven? В этой статье мы разберем Gradle, чтобы вы могли уверенно использовать его в своих проектах для автоматизации тестирования, а так же спокойно ответить на вопросы на собеседовании.

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

Привет! Я Максим Кузьмин, старший инженер по автоматизации в команде Т-Путешествий. Строю и развиваю процессы автоматизации и разрабатываю инструменты тестирования.

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

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

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

Если коллеги заметят какие-то неточности или важные дополнения — буду благодарен за комментарии.

Автор:

Аутентификация – как правило, первое препятствие при настройке автоматизации тестирования. В зависимости от сложности используемого метода аутентификации эта задача может оказаться весьма трудоёмкой. Давайте начнём с простого примера последовательности входа в систему.

Автор:

В последнее время я экспериментирую с Vitest — фреймворком для тестирования JavaScript- и TypeScript-приложений. Я начал работать с этим инструментом недавно и был приятно удивлён его возможностями.

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

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

Автор:

Зачем тестировать в Kubernetes?

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

Веб-приложение запускается, как отдельная K8S (Kubernetes) копия для каждой клиентской компании, на отдельном кластере K8S, где ресурсы этой конкретной копии сгруппированы в пространства. UI-тесты автоматически запускаются перед крупными обновлениями версий веб-приложения, а также сразу после, чтобы проверить, что обновление не повредило работе приложения. Это было достигнуто через контейнеризацию кода UI-тестов в образ Docker, его отправку в репозиторий организации и использование задачи K8S для деплоя тестов в конкретном пространстве копии перед обновлением и сразу после него.

Образ Docker, разворачивающийся на сотнях ресурсов, должен быть легким, поэтому тесты запускались в окружении Linux. Запуск в Linux без поддержки дисплея означал, что тесты не могли открыть обычны браузер и вынуждены были использовать режим без графического интерфейса. Вся разработка и тестирование в компании проводятся в Chrome, и поэтому я, естественно, использовал ChromeDriver для запуска настройки Chromium в деплое контейнера. Сервер, отслеживающий расписание обновлений, использовался для запуска тестов в конкретной копии веб-приложения, а тесты возвращали на сервер JSON-отчет о результатах.

Автор:

Введение

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

Теперь, когда ИИ-инструменты широко распространяются, начинают появляться и инструменты тестирования доступности на основе ИИ.

Как правило, они делятся на три категории:

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

Эти инструменты, особенно те, которые просто правят все за вас, выглядят прекрасной идеей! Но решат ли они все проблемы? К сожалению, нет. Помогут ли они? Да, в правильных условиях и в разумном масштабе.

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

Автор:

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

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

Автор:

Что такое Redis?

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

Redis расшифровывается, как Remote Dictionary Server. Проект зародился, когда Сальваторе Санфилиппо, исходно разрабатывавший Redis, пытался улучшить масштабируемость своего итальянского стартапа. Сейчас Redis отвечает менее чем за миллисекунду, что позволяет получать миллионы запросов в секунду для приложений реального времени – игр, рекламы, финансов, здравоохранения и интернета вещей. Redis – популярный вариант для кэширования, управления сессиями, игр, рейтинговых таблиц, аналитики в режиме реального времени, геопространственных технологий, попутных поездок, чатов, стриминга и pub/sub (https://aws.amazon.com/redis/).

Автор:

Решение проблем и автоматизация задач в нескольких проектах: наша общая QA-библиотека

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

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

Автор:

Контекст

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

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

Чтобы понимать, какие запросы можно отправлять в GraphQL API и что можно получить в ответе, нужно уметь читать его схему. Это как WSDL в SOAP API — описание всех доступных методов.

Да, программы типа Postman или Apollo сами считывают схему и показывают вам всё в красивом виде — просто ходи да «натыкивай» запросы. Но если само API ещё в разработке, чтение схемы поможет понять, что вас ожидает.

Поэтому в этой статье я расскажу, что такое Schema GraphQL API и как её читать.

Автор:

Забавный факт: создатель инструмента назвал своего щенка Бруно. В компании Бруно сейчас занимает должность директора по радости!

Хотите попробовать что-то новенькое?

Привет, тестировщики и другие энтузиасты ПО! Слышали ли вы о новом клиенте API, Bruno? Возможно, это именно то, что вам нужно. Его пользовательская база растет по экспоненте, и он может похвастать постоянно растущим количеством звезд на GitHub.

Если вкратце: Bruno – это клиент API с открытым исходным кодом и лицензией MIT. Его можно использовать для работы с REST и GraphQL API. И он привлекает все больше внимания команд разработки и технической прессы – Thoughtworks Technology Radar рассказал о Bruno в апреле 2024 после того, как ряд их команд начал пользоваться этим инструментом.

Мне кажется, что инструменты для разработки и тестирования API стали гораздо сложнее, чем предполагали их изначальные создатели. Давным-давно, когда эти инструменты только появились на рынке и в коллекциях ПО с открытым исходным кодом, они были просто клиентами API. Теперь это end-to-end платформы для создания, поддержки и документации API. Объединение нескольких возможностей в одном инструменте может быть полезным, но многих потенциальных пользователей этих инструментов отпугивают перемещения в облако и необходимость регистрации. И основатели Bruno предложили рынку свою идею. Bruno пользуются как разработчики, так и тестировщики, а пользовательская база, превышающая 100000 человек, говорит о полезности этого инструмента для работы.

Автор:

Введение

Нам нужно было протестировать производительность мультирегиональных кластеров Kafka. Мы в итоге применяли pepper-box для большинства задач. Вначале нам нужно было понять, а затем использовать и улучшить возможности pepper-box. Ниже – обзор наших действий, связанных с работой с pepper-box. Мы опубликовали наш код и связанные с ним материалы на GitHub, и детали можно увидеть тут: https://github.com/commercetest/pepper-box

Автор

Где должен жить код тестов проекта? Старый, как мир, спор

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

В этой статье изложены аргументы обеих сторон, а также плюсы и минусы каждого подхода. Она предлагает гибридное решение на основании опыта автора и обсуждений с командой разработки. Статья делает акцент на важности «культуры качества» и роли адвокатов качества, которую играют инженеры по обеспечению качества. Также будет обсуждаться внедрение прекоммитных хуков и использование тегов в pytest для создания быстрой петли обратной связи и повышения эффективности непрерывной интеграции и поставки/разработки (CI/CD). В заключении говорится о том, что для улучшения QA-практик необходимы масштабные исследования.

Автор:

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

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

В этой статье мы разберемся, что такое перехват API, и как успешно им воспользоваться, тестируя пользовательский интерфейс при помощи Cypress.

Автор: Сватика Визань (Swathika Visagn)
Оригинал статьи
Перевод: Ольга Алифанова

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

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

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