Автор: Хуссем Маатали (Houssem Maatali)
Оригинал статьи
Перевод: Ольга Алифанова

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

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

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

Что такое Redis?

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

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

Автор: Ник Караманиолас (Nick Karamaniolas)
Оригинал статьи
Перевод: Ольга Алифанова

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

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

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

Автор: Джулиан Харти (Julian Harty)
Оригинал статьи
Перевод: Ольга Алифанова

Контекст

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

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

Автор: Ольга Назина (Киселева)

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

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

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

Автор: Ашутош Мишра (Ashutosh Mishra)
Оригинал статьи
Перевод: Ольга Алифанова

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

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

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

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

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

Автор: Джулиан Харти (Julian Harty)
Оригинал статьи
Перевод: Ольга Алифанова

Введение

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

Автор: Леонид Хусидман (Leonid Khudisman)
Оригинал статьи
Перевод: Ольга Алифанова

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

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

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

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

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

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

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

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

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

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

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