Привет, я Дмитрий Желудков, архитектор по эксплуатации, и сегодня я покажу, как собрать приложение в docker на вот этих вот 4 левых пальцах (а как же иначе, у нас же серьёзное исследование).

Jenkins CI позволяет разработчикам автоматизировать создание, тестирование и развёртывание кода. Кроме того, он оттачивает возможности для обработки любой сборки или непрерывной интеграции. Jenkins Jobs фокусируется на непрерывном создании и тестировании кода, чтобы любые внесённые изменения легко интегрировались в сборку. В этой статье мы посмотрим на Jenkins в действии — разберём, как создавать и настраивать Jenkins Jobs. 

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

Если вы работаете в тестировании, то Docker должен быть в вашем ежедневном инструменте так же прочно, как баг-репорт в Jira. Современный QA — это не просто “прокликать” интерфейс. Мы работаем с API, БД, UI-автотестами, моками и целыми микросервисами. А значит, нам нужно уметь быстро разворачивать изолированные и воспроизводимые окружения.

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

В современном мире разработки программного обеспечения роль инженера по тестированию (QA) является критически важной. Однако для начинающих специалистов одним из основных вызовов становится получение необходимого практического опыта. Теоретические знания важны, но именно работа с реальными или специально созданными приложениями и сервисами позволяет по-настоящему освоить профессию, научиться находить дефекты, применять различные техники тестирования и работать с инструментами автоматизации.

Эта статья представляет собой подробный и структурированный гид по тестовым площадкам и полезным ресурсам, собранный специально для начинающих QA-инженеров. Цель гида – помочь новичкам быстро найти подходящие "песочницы" для отработки ключевых навыков и ускорить процесс адаптации в профессии. Материал разбит на 8 разделов для удобства навигации по различным направлениям тестирования.
Раздел 1: Общие площадки для практики
Раздел 2: Тестирование пользовательского интерфейса (UI)
Раздел 3: Ресурсы для подготовки к сертификации
Раздел 4: Тестирование API
Раздел 5: Тестирование безопасности (Security Testing)
Раздел 6: Мобильное тестирование
Раздел 7: Тестирование производительности (Performance Testing)
Раздел 8: Ресурсы для практики автоматизации тестирования

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

Как понять, что API отработало корректно? Как убедиться, что в ответе пришли нужные данные? И как использовать эти данные в следующих шагах, выстраивая сложные тестовые цепочки?

Именно здесь на сцену выходят post-response скрипты. Это код, который выполняется после получения ответа от сервера. Его основная задача – анализ, валидация и обработка полученных данных. Эти скрипты – ваши глаза и уши в мире API-тестирования, позволяющие автоматически проверять всё: от статус-кода до мельчайших деталей в теле JSON.

В этой статье мы рассмотрим 10 самых полезных post-response скриптов, которые превратят ручную проверку ответов в быстрый и надежный автоматизированный процесс. Давайте завершим наш путь к эффективному тестированию API!

Если вы ежедневно работаете с API-тестированием и используете Postman, то наверняка сталкиваетесь с повторяющимися задачами: ручное получение и обновление токенов авторизации, изменение параметров запросов для разных сред разработки, копирование данных из ответов для использования в следующих запросах. Эта рутина отнимает время и силы, а также увеличивает вероятность ошибок. Что если большую часть этих действий можно автоматизировать?

В этой серии из двух статей мы пошагово разберем 10 самых полезных pre-request и 10 post-request скриптов, которые, по моему опыту, являются наиболее востребованными при тестировании API, особенно для начинающих QA инженеров. В этой и следующей статьях выполнено ранжирование этих скриптов по их важности и частоте использования, чтобы вы могли сразу осваивать и применять на практике самые необходимые из них. Каждый из 20 скриптов будет сопровождаться простым, понятным примером кода на JavaScript, готовым к применению, а также примерами из практики.

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

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

Lead QA Ада Ширченко (7+ лет в QA), Senior QA Юлия Самусева (8+ лет в QA) и Middle+ QA Евгений Гусинец (3+ лет в QA)

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

Привет, меня зовут Даша, я работаю тестировщицей клиентского мобильного приложения в компании Ozon.

Сегодня поговорим о снифферах в тестировании мобильных приложений –– программах для перехвата, анализа и модификации трафика. Пожалуй, самый популярный сниффер из тех, о которых мне доводилось слышать — Charles. Про него уже не раз писали на Хабре, есть довольно детальные разборы. Но не Charles-ом единым! 

Привет, Хабр! Статья была ранее опубликована в блоге компании, который сейчас удален. Перевыкладываю, так как считаю, что статья не потеряла актуальность на текущий момент времени.

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

Если повезло, то кандидат знает о необходимости проверки сетевого взаимодействия, но, за редким исключением, его знания ограничены Rewrite или Breakpoints.

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

Привет, Хабр! Меня зовут Евгений Никулин, я – тимлид инженеров эксплуатации в К2 Cloud.

Пару месяцев назад меня позвали на онлайн-митап «Карьера в Линукс» – обсудить, как сейчас всё устроено: какие подходы используют компании, каких специалистов ценят и что помогает соискателям находить общий язык с работодателями.

Решил с вами поделиться самым важным оттуда. Полная запись, если что, есть на канале K2 Cloud Team – там же можно узнать, как мы с 2009 года строим облачную платформу собственной разработки.

Привет! Как и многие в 2025 году, я постоянно работаю с ChatGPT и Gemini: они помогают мне в работе, отвечают на сотни вопросов и просто развлекают. За время работы с ИИ у меня накопилась целая коллекция мини-промптов, которые делают процесс проще, результативнее и даже веселее. Сегодня делюсь с вами.

1. Объединить диски с данными в один массив большого объема, чтобы не приходилось вручную сортировать файлы — что возникает при нескольких дисках (пусть даже при монтировании их в папки).
2. Иметь возможность добавлять/удалять/заменять диски в любой момент без развала массива.
3. Независимость информации на дисках друг от друга — чтобы смерть одного из них не приводила к недоступности остальных.
4. В идеале — какой-то метод хранения одного файла на нескольких дисках. Бэкапы — это хорошо и я их делаю, но лучше, когда к их помощи не приходится прибегать.

Привет! Меня зовут Татьяна Дерягина, я QA-инженер из команды мобильного тестирования в СберМаркете. Моя команда работает дистанционно, находясь в разных городах России. Хочу рассказать, как как мы адаптировались к процессу тестирования, без большого количества реальных девайсов и не потеряли качество продукта.

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

Как внести ясность в такой ситуации? Некуда деваться, пора разбираться, что же там происходит «под капотом» приложения.