Все крупные компании сейчас пытаются строить огромные централизованные хранилища данных. Или же ещё более огромные кластерные Data Lakes (как правило, на хадупе). Но мне не известно ни одного примера успешного построения такой платформы данных. Везде это боль и страдание как для тех, кто строит платформу данных, так и для пользователей. В статье ниже автор (Жамак Дегани) предлагает совершенно новый подход к построению платформы данных. Это архитектура платформы данных четвертого поколения, которая называется Data Mesh. Оригинальная статья на английском весьма объёмна и откровенно тяжело читается. Перевод так же получился немаленьким и текст не очень прост: длинные предложения, суховатая лексика. Я не стал переформулировать мысли автора, дабы сохранить точность формулировок. Но я крайне рекомендую таки продраться через этот непростой текст и ознакомиться со статьёй. Для тех, кто занимается данными, это будет очень полезно и весьма интересно.

Евгений Черный

Привет! Меня зовут Сергей, я бэкенд разработчик команды SEO в Банки.ру.
В этой статье хочу описать свое знакомство с техникой Trace Based Testing (TBT): 

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

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

Здравствуйте. Сейчас я применив GEOINT (геопространственная разведка) попытаюсь найти офис Павла Дурова в Объединённых Арабских Эмиратах.

Вы IT-специалист и решили сменить место работы. Что обычно делают в таких случаях айтишники? Ходят по собеседованиям, работают над ошибками в случае отказов — и всё по новой до тех пор, пока не будет получен подходящий оффер. Многие ли из айтишников оценивают надёжность будущего работодателя во время поисков? При планировании профсоюзных кампаний мы проводим исследование работодателей с использованием множества источников и методик. Эта статья была написана с целью помочь специалистам любого уровня, от интернов до архитекторов, ведь никто не застрахован от проблем на работе. Мы поделимся опытом и надеемся, что он поможет вам не нарваться на недобросовестного работодателя.

Привет, меня зовут Елена Рукавичникова, я Head of QA  и преподаватель курса “Функциональное тестирование ПО” в IT Academy. Свыше 7 лет я погружена в мир тестирования, принимая участие в более чем 20 увлекательных проектах.

Когда-то я выступала на конференции с данной темой и решила поделиться ею с вами.

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

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

Привет! Я Ольга Лобанова, руководитель отдела качества в AGIMA. Моя главная задача на любом проекте — сделать процесс тестирования прозрачным и измеримым. Поэтому мы в компании уделяем много внимания построению инфраструктуры тестирования. В этой статье объясню, почему это важно, а заодно поделюсь нашими подходами — думаю, коллеги оценят. Интересно будет тестировщикам, руководителям проектов, техническим директорам и нашим заказчикам. Welcome.

Привет, Хабр!

Я решил посвятить свою первую статью SQL. Вопросы, рассмотренные ниже мне задавали на собеседованиях на позицию python-разработчика. Естественно отвечать правильно получалось не всегда, а если точнее то чаще не правильно, однако проведя N часов в рефлексии я составил перечень ответов, которыми пользуюсь до сих пор.

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

Если ваша система использует БД и время от времени нужны тестовые записи, или если вы делаете insert-ы с несколькими наборами значений values, то изложенное ниже может пригодиться.

Искать или создавать тестовые записи?

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

Как же их получить? Первая мысль - найти среди уже имеющихся. Но, чем больше условий, тем больше проблем при поиске.

Допустим, нашли. Разработчику и тестировщику нужно много вариантов набора данных. Можно взять несколько записей и их update-ить, но не помешает ли это кому-то ещё? Не грохнется ли часть данных по какой-нибудь причине? А что будет с этими записями через несколько месяцев, когда понадобится что-то перепроверить? На практике не раз сталкивался с худшими ответами на подобные вопросы. Как же этого избежать?

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

Машинное обучение держится на трёх основных столпах:

1. Съездить в соседнюю страну и приобрести SIM-карту (например, в Польше она стоит 5 злотых у оператора Play24, без абонентской платы, и многократно пригодится в будущем, так что это полезная инвестиция).
   
2. Купить «одноразовую» виртуальную симку на одном из полулегальных сервисов, чтобы получить SMS (без гарантии, потому что эту симку тысячи раз перепродают).
   
3. Воспользоваться сторонним фронтендом, который даёт доступ к ChatGPT из России без VPN и СМС.

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

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

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

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

Привет, Хабр! Меня зовут Ира, я SRE в команде Samokat.tech. В этом посте хочу поделиться подходом в тестировании, которым мы пользуемся сами. Если вам при подготовке тестов часто приходится писать похожие друг на друга как две капли воды заглушки (или, как их ещё называют, «моки»), а затем заботиться о том, чтобы их развернуть, то вам может понравиться наше решение. Освободившись от части рутинных забот, вы можете уделить больше времени чему-то более важному.

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

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

Сложно представить тестировщика в роли доброго самаритянина, раздающего коллегам свои заглушки. Его к этому вряд ли что-то мотивирует, да и работы у него всегда прилично. Некогда отвлекаться! Так, давайте разгрузим немного нашего трудягу.

Если бы мне задали такой вопрос, то я не смог бы на него правильно ответить. Ведь начинал я с ручного тестирования, а сейчас мы департаментом раскатываем на весь банк гигантский «дашборд», который привязан буквально ко всем данным компании, и позволяет оценить качество работы любой команды. Меня зовут Иван Боклач, я руководитель направления развития экспертизы QA в Центре Координации и Повышении эффективности разработки в Альфа-Банк. Я занимаюсь развитием новых технологий, метриками, стандартизацией и автоматизацией процессов.

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

Всем привет! Я QA Engineer и недавно открыл для себя ChatGPT и хочу открыть этот мир другим тестировщикам. Эта статья не руководство к применению и каких-то суперлайфхаков здесь не будет. Цель этой статьи в том, чтобы показать огромные возможности нейросетей в помощи нам, тестировщикам, в работе. Надеюсь что кто-то, прочитав это, хоть немного сможет облегчить себе составление тест-кейсов, написание документации или написание автотестов. Примеров с написанием кода здесь по минимуму, так как таких материалов уже много.

За последние несколько лет на рынке появилось множество школ, обещающих вход в IT без профильного образования и золотые горы «без регистрации и смс». Все, что для этого нужно – пройти 2-3х месячный курс, на котором тебе расскажут все про тестирование, научат автоматизации тестирования, помогут с составлением резюме, портфолио, и подготовят к прохождению собеседования.

И вот на рынке появляются сотни, если не тысячи резюме вчерашних выпускников курсов, с одинаковыми резюме, одинаковыми заявленными скиллами, инструментами. Кто-то даже с опытом работы в IT.

Так как же понять, кто из кандидатов действительно хорош?

Привет всем, я, Надежда Дудник, главный инженер по тестированию в СБЕРе, а ещё ментор по тестированию ПО.

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

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

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

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

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

При выполнении каждого запроса API нам необходимо и важно проверить:

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

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

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

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