Вспомните февраль 2020 года.

Если вы тогда внимательно следили за новостями, то могли заметить редкие разговоры о каком-то вирусе, распространяющемся где-то за океаном.

Но будем честны, большинство из нас не особенно вслушивалось. Рынки росли, дети ходили в школу, мы ужинали в ресторанах, пожимали руки, строили планы поездок. Скажи вам кто-нибудь, что закупает впрок бумажные полотенца, – вы бы решили, что человек просто пересидел в каком-нибудь странном уголке интернета.

А потом – буквально за какие‑то три недели — мир перевернулся. Офисы закрылись, дети вернулись домой, и жизнь сложилась в новую реальность, в которую вы бы не поверили, опиши вы её себе всего месяцем раньше.

Мне кажется, сейчас мы находимся в стадии «да это всё раздуто» — но речь идёт о чём‑то куда, куда более масштабном, чем COVID.

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

Потому что честная версия звучит так, будто я сошёл с ума. И какое-то время я убеждал себя, что этого достаточно, чтобы держать настоящую картину при себе. Но разрыв между тем, что я говорю, и тем, что происходит на самом деле, стал слишком велик. Люди, которые мне небезразличны, заслуживают услышать, что надвигается – даже если это звучит безумно.

Не в смысле “когда-нибудь стоит об этом поговорить”. А в смысле: это происходит прямо сейчас, и мне нужно, чтобы вы это поняли.

Ещё недавно инвестиции в AI означали рост цен на акции, и это работало как рефлекс. Но теперь рефлекс сломан.

Знаете ли вы, что такое рынок AI? Это неконтролируемая аномалия, распространяющаяся внутри американской экономики.

Аналитики утверждают, что этот «рынок» — не то, что мы привыкли думать. Он мутировал в крупнейший финансовый пузырь в истории. А финансовые пузыри всегда заканчиваются одинаково — лопаются и рушатся.

Обычные люди, инвесторы-любители и техно-энтузиасты не обязаны всё это осознавать. Но финансовые эксперты уже бьют тревогу. Они видят закономерность.

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

Но предупреждающие знаки появились ещё раньше. В июне 2024 года Goldman Sachs поставил под вопрос окупаемость огромных инвестиций в AI. В отчёте отмечалось, что несмотря на сотни миллиардов долларов, вливающихся в индустрию, нет доказательств ROI и никаких чётких признаков революционного скачка производительности. Большинство вариантов использования AI оставались постепенными, а не трансформационными.

Позже McKinsey & Company опубликовала свой годовой отчёт о состоянии AI за 2024–2025 годы. Документ отмечал, что, несмотря на широкое внедрение технологии, только относительно небольшая доля компаний получала от неё измеримую экономическую выгоду. Разрыв между объёмом инвестиций и реальной отдачей оставался далёким от приемлемого.

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

Apidog позиционирует себя как универсальная платформа для работы с API: проектирование, тестирование, mock-сервер, документация. Всё в одном флаконе. Звучит как маркетинг, но интерфейс выглядел приятно, в общем решил сам проверить на практике.

Пройдём полный цикл: от создания проекта до запуска тестов. Со скриншотами и личными впечатлениями.

Туториал по работе с логами в Kibana для начинающих специалистов по тестированию ПО.

У Kibana имеется свой язык запросов KQL (Kibana Query Language) - официальный источник. С помощью этого языка можно составлять запросы, которые помогают отфильтровывать и найти необходимую информацию.

Подключение к Kibana для просмотра логов.

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

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

Сегодня доступно множество инструментов: Selenium, Playwright, Cypress и другие. Каждый имеет свои преимущества. Но в подавляющем большинстве наших проектов мы используем Selenium. Расскажу, почему мы сделали такой выбор.

Цель автоматизации — экономия

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

Автотесты выполняют эти проверки быстрее и точнее. С экономической точки зрения, однократные инвестиции в разработку автотестов, как правило, окупаются за счет экономии на многократных ручных проверках.

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

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

Требования клиентов и гибкость технологий

Как IT-компания, мы сталкиваемся с разными требованиями заказчиков. Клиенты часто просят использовать определенный язык программирования, чтобы их команды могли поддерживать тесты. Например, если бекэнд написан на C#, то и автотесты предпочтительнее на нем.

Тестирование — это не просто поиск ошибок. Это способ убедиться, что продукт действительно работает так, как должен, и делает жизнь пользователей проще, а не сложнее. Хорошее тестирование начинается задолго до первого нажатия кнопки “Run tests” — с понимания логики продукта, требований и рисков.

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

Вопросы для джунов QA-инженеров часто повторяются, куда бы вы ни устраивались. То же с тестовыми заданиями и даже загадками на логику. Но почему интервью с работодателями так трудно дается новичкам?

Привет, Хабр! Меня зовут Кристина, я QA-инженер в госкомпании и экс-ревьюер курса «Инженер по тестированию» в Яндекс Практикуме. За все время в профессии я прошла 10 собеседований, по итогам которых получила 3 оффера. В этом материале расскажу новичкам, к чему готовиться и почему ваша главная задача — не выучить ответы, а победить волнение.

Собеседование —  один из самых важных и волнительных этапов для любого специалиста. Независимо от опыта, возраста или других индивидуальных особенностей, каждый из нас так или иначе переживает за результат, но всё же надеется успешно пройти все этапы интервью. Безусловно, самым серьёзным из них является технический блок. Именно здесь у интервьюера больше всего возможностей вас «помучить» :)

Особенно остро это ощущают специалисты из направления QA/SDET, ведь информации действительно очень много. Но не переживайте: SimbirSoft спешит на помощь!

Меня зовут Кирилл, я SDET-специалист в компании SimbirSoft. В этой статье я собрал список вопросов, на которые обязательно стоит обратить внимание при подготовке — как начинающим специалистам, так и закалённым «воинам» в области обеспечения качества — QA Manual, QA Automation и SDET — вне зависимости от грейда.

• XML — используется в SOAP (всегда) и REST-запросах (реже);
• JSON — используется в REST-запросах.

См также:
Что такое API — общее знакомство с API
Что такое JSON — второй популярный формат
Введение в SOAP и REST: что это и с чем едят — видео про разницу между SOAP и REST.

JSON (англ. JavaScript Object Notation) — текстовый формат обмена данными, основанный на JavaScript. Но при этом формат независим от JS и может использоваться в любом языке программирования.

JSON используется в REST API. По крайней мере, тестировщик скорее всего столкнется с ним именно там.

И если в SOAP API возможен только формат XML, REST поддерживает как XML, так и JSON. Разработчики предпочитают JSON — он легче читается человеком и меньше весит.

Всем привет. Наверняка каждый, кто так или иначе связан с IT сферой, слышал модную аббревиатуру CI/CD. Везде мы слышим про необходимость ее использования, преимущества автоматизации процессов и т.д.

В вакансиях все чаще требуется опыт работы с одним из инструментов в этой инфраструктуре – Jenkins, Travis, AWS, Gitlab CI/CD.

⚠️Я предлагаю вам посмотреть на этот процесс, глазами простого разработчика. Чем ему может помочь автоматизация. Что в конечно итоге скрывается под этой аббревиатурой, и как уже начать получать дивиденды в своей ежедневной рабочей практике.

Первые шаги

Мы рассмотрим внедрение инструментов автоматизации в приложение, построенное на базе React. В целом разберем именно основные подходы и моменты, на которые стоит обратить внимание в самом начале.

В целом, это будет актуально для любого стека.
Чаще всего я использую для хранения кодовой базы и групповой работе над проектами Gitlab. Очень кстати, что эта площадка предоставляет инструментарий CI/CD.

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

Мне не хватало именно взгляда на основные шаги – что, зачем и как мы делаем. А уже потом реализации практических задач.

CI – continuous integration

Что же скрывается за термином "непрерывной интеграция". Когда мы работаем над созданием программного продукта – в одиночку, или в рамках команды, мы стараемся добавить в наш проект, несколько строк кода. Новый функционал, исправление или доработки. Суть не особо важна. В конечно счете – либо появляется новый код, либо появляются изменения в старом. И нам нужно убедиться, что эти новые изменения, не содержат ошибок, которые могут вызвать проблемы или неработоспособность приложения. ⛔️

Доброго времени суток, дорогой читатель. В данной статье я постараюсь рассказать об одном из самых популярных (на сегодняшний день) способов авторизации в различных клиент-серверных приложениях - токен авторизации. А рассматривать мы его будем на примере самой популярной реализации - JSON Web Token или JWT.

Проектирование и работа с REST-сервисами стали повседневными задачами для многих аналитиков. Однако мы часто встречаемся на работе с различными или даже противоречащими друг другу трактовками таких понятий, как REST, RESTful-сервис, RESTAPI.

Сегодня мы разберём, какие принципы вложил в парадигму REST её автор и как они могут помочь нам при проектировании систем.

Выясним, почему существует терминологическая путаница вокруг REST и как нам научиться лучше понимать коллег.

Поговорим о том, как связаны HTTP и REST. А также почему REST противопоставляют SOAP.

HTTP-запросы: структура, методы, строка статуса и коды состояния

Цель: написать небольшую статью, максимально понятным языком,
которая дает представление о протоколе http и объясняет структуру http запросов и ответов сервера.

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

Заголовок: HTTP-запроса: Структура, методы, статусная строка и коды состояния.

Добро пожаловать!

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

Во время технических презентаций нашей технологии – платформы быстрой разработки Jmix – мы, как правило, доходим до вопроса архитектуры создаваемых приложений и часто встречаем грусть в глазах разработчиков, когда сообщаем, что создаваемое приложение имеет монолитную архитектуру. Удивительно, но случается, что команды разработки приложений на Delphi или Oraсle EBS непременно заинтересованы в реализации микросервисной архитектуры, отождествляя ее с чем-то очень современным и самым продвинутым. К счастью, хайп вокруг микросервисов постепенно начал замещаться новой информационной повесткой о необходимости рационального использования ресурсов и выбора типа архитектуры приложений на основе компетенций команд разработчиков и масштабов создаваемого решения. В Jmix есть все необходимое, чтобы создавать современные корпоративные информационные системы в рекордные сроки и с минимальными затратами. Мы понимаем, что монолитная архитектура приложений Jmix не может закрыть все кейсы, но мы верим, что для каждой задачи есть подходящий инструмент. Прочитайте перевод статьи из блога Camunda, возможно, она поможет понять какой тип архитектуры подходит для вашего проекта, чтобы сэкономить время, деньги и нервы.

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