Автор: Ник Караманиолас (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. Я решила поделиться этой информаций со всем сообществом!

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

Автор: Наталья Баранова, Аурига

В предыдущей части статьи мы рассмотрели общие подходы к тестированию PDF и познакомились с тем, как библиотеки pdfminer и PDFQuery помогают нам получать детальную информацию об объектах. Достаточно ли нам этой информации? Далеко не всегда. В этой статье мы расскажем о решении некоторых интересных технических проблем.

Автор: Наталья Баранова, Аурига

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