Автор: Ашутош Мишра (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 человек, говорит о полезности этого инструмента для работы.

Оригинальная публикация

Меня зовут Михаил Палыга, я инженер в Блоке обеспечения и контроля качества выпуска изменений ПО в РСХБ‑Интех. Разработчик я начинающий, в компании работаю около года, плюс 6 лет обучения в профильном вузе. В данной статье хочу рассказать, как мы в нашем проекте проводим проверки данных в наших тестах.

Мы занимаемся разработкой автотестов для АБС ЦФТ‑Банк — автоматизированной банковской системы (АБС), разработанной ООО «Центр финансовых технологий». Это ядро IT‑экосистемы банка. Тесты состоят из трех этапов: формирование условий, воздействие и проверка результата. Кстати, о том как и каким инструментом мы подбираем тестовые данные, мы писали ранее в этой статье, а об особенностях перехода с Oracle на PostgreSQL мы писали тут.

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

Далее в статье я опишу, как со временем менялся наш подход к проведению проверок данных и как менялись сами классы проверок. А чтобы было чуть проще и интересней — займемся тестированием чего‑нибудь из вселенной Звездных Войн. Например, протестируем имперский бронированный транспортный вездеход AT‑AT.

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

Введение

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

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

Чит-лист — это шпаргалка по выбранной теме, что не забыть проверить. Берете чит-лист как основу, адаптируете под свой проект, и готово!

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

Если в приложении есть возможность открыть одну и ту же форму несколько раз — это обязательно надо проверить:

• Веб — открыть форму в нескольких вкладках браузера.

• Десктоп — там тоже иногда можно открыть в отдельной вкладке форму. Или запустить приложение несколько раз (имитируя разных пользователей).

• Мобилки — открыть с разных устройств.

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

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

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

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

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

Оригинальная публикация

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

Меня зовут Елизавета Андреева. Я инженер по автоматизации тестирования в ОК.Tech. Мы с коллегами в ОК разработали и внедрили автогенерацию API‑тестов, благодаря которой мы сокращаем ручную работу и время на написание однотипных автотестов, оставляем QA‑инженерам для покрытия только кейсы на бизнес логику. И в этой статье (которая станет первой в серии из двух частей) я начну рассказ о том, как мы реализовали наш генератор и каких результатов нам удалось достичь.

Автор: Ноэми Феррера (Noemi Ferrera)
Оригинал статьи
Перевод: Ольга Алифанова

Ранее я упоминала, что специально использую UI, дабы обозначить, что он должен находиться на вершине тест-пирамиды, в то время как в других случаях вершина называется E2E. Чувствую, надо подробнее это объяснить.

UI – это пользовательский интерфейс. UI-тестирование относится к тестированию, выполняемому через UI.

E2E – это end-to-end тестирование. Это тесты, которые выполняются от входной точки в приложения до выхода из него.

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

Однако они отличаются важными нюансами.

Оригинальная публикация

Всем привет! Я старший преподаватель направления функционального тестирования в «ЛАНИТ Экспертиза». К нам в штат приходят люди из разных профессий и с разным уровнем знаний. Поэтому в компании организованы курсы обучения практикам тестирования, которые уже стали базовыми. Одной из них является тестирование с помощью API запросов, или, как его еще называют, тестирование API. И сегодня для тех, кто этим занимается, я постараюсь доступным языком рассказать, как использовать этот формат для описания тестовых данных, подключаемых к прогонам коллекций в Postman.