Спасибо, что поделилась! Лично мне было интересно прочитать о твоем опыте, т.к. сам когда-то учился и несколько лет преподавал тестирование в одном IT университете :)) Успехов в работе. + тебе в карму и в рейтинг !
Есть несколько вариантов использования нейронок через VSCode расширения - тот же KiloCode, например. Пользуюсь сам им давно - супер вариант. GPT бесплатный давно проигрывает Gemini от Google и Qwen. Так что пересмотрите выбор нейронок для решения подобных задач.
Так уже существует огромное количество IDE систем на подобие Cursor или CLI-агенты на подобие Gemini -CLI или Qwen-CLI с которыми все это делать гораздо удобнее.
Здравствуйте! Я старался дать максимально развернутый ответ. Видимо перестарался. Сказывается академическое прошлое :)) https://scholar.google.com/citations?user=_ibB59AAAAAJ&hl=ru До 2021 года активно занимался научной деятельностью, а в 2022 уже ушел в IT на графиках видно.
Спасибо за такой честный и жизненный комментарий! Вы указали на реальное больное место: на собеседовании любая компания – продавец, а кандидат – покупатель. И, конечно, продавец будет показывать свой товар с лучшей стороны.
Считаю, что Вы абсолютно правы как минимум в двух ключевых вещах:
Никто не признается в хаосе. Фразы «у нас тут бардак, процессы только на бумаге, а менеджмент некомпетентен» вы никогда не услышите.
Сотрудники могут искренне не осознавать проблем. Человек, работающий внутри системы, привыкает к её недостаткам и может считать их нормой.
Именно поэтому цель вопросов из статьи – не получить простой ответ «да/нет», а вскрыть второй слой и научиться «читать между строк». Это не аудит, а скорее диагностика по косвенным признакам.
Как превратить общий вопрос в острый инструмент:
Вместо: «У вас есть процессы?» Стоит спросить: «Можете рассказать на примере последней реализованной фичи, как она прошла путь от идеи до продакшена? В какой момент подключился QA, какие были трудности, как принималось решение о релизе?»
Такой вопрос вынуждает рассказывать историю, а не ставить галочку. И в этой истории вы услышите всё: реальную роль QA, наличие тестов, взаимодействие в команде, отношение к проблемам.
Вместо: «Вы используете метрики качества?» Спросите: «Какой инцидент на проде за последний квартал был самым болезненным? Как вы его разбирали и какие системные выводы сделали, чтобы такое не повторилось?»
Ответ на этот вопрос покажет больше, чем любые слова о метриках. Вы увидите, есть ли в команде культура анализа (RCA, post-mortem) или просто «починили и забыли».
Главное — не что вы спрашиваете, а как вы слушаете ответ:
Кто отвечает? Техлид, который «в полях», даст конкретику. HR или менеджер, далекий от процессов, будет говорить общими фразами.
Насколько уверенно и детально звучит ответ? Если человек «плавает» в деталях, скорее всего, процесс либо отсутствует, либо работает не так, как на бумаге.
Есть ли противоречия? Спросите на разных этапах интервью один и тот же вопрос (в разной формулировке) разным людям. Расхождения в ответах – лучший индикатор проблем.
Ваш скепсис абсолютно оправдан. Ни одно собеседование не даст 100% гарантии. Но умение задавать глубокие, открытые вопросы и анализировать ответы на них – это тот самый фильтр, который помогает отсеять большинство «шляп» еще на подлете.
Благодарю еще раз, что поделились своим опытом. Он очень ценен и отлично дополняет статью!
Manual QA не заменит никогда от слова совсем. Автоматизаторов не сможет пока заменить тоже. Тут про разработчиков кричат, что ИИ заменит. Сократит время написания тест-кейсов, разработки тестовой документации, разработки тестовой стратегии и др. Но про полную замену речи нет пока даже близко. То что их нужно будет меньше в связи со сокращением трудозатрат это факт, но не более того.
Добрый день! Огромное спасибо за ваши вопросы, замечания и дополнения! Это очень ценно для меня и многих читателей Хабра.
Отвечу на каждый ваш вопрос по порядку. 1.1. Зачем нужен скрипт, если есть нативное переключение окружений?
Ответ: Вы совершенно правы: для простого переключения базового URL (baseUrl) или одного-двух параметров между стендами стандартный механизм окружений Postman — это самый правильный и предпочтительный способ. В этом случае скрипт действительно будет избыточным.
Однако, предложенный в статье скрипт решает более сложные, "нестандартные" задачи, которые часто возникают в реальных проектах:
Централизация сложной логики: Представьте, что в зависимости от окружения (dev, stage) у вас должны меняться не только URL, но и набор API-ключей, ID пользователей для тестов, и даже включаться или выключаться определенные feature flags. Скрипт на уровне коллекции позволяет собрать всю эту логику в одном месте. Это делает коллекцию более читаемой и самодокументируемой. Новый человек в команде сразу видит всю логику конфигурации, а не ищет переменные по разным окружениям.
Производные и дефолтные значения: Скрипт позволяет задавать значения по умолчанию. Например, если переменная environment не задана, он автоматически выберет dev, предотвращая случайные запросы на prod. Также он позволяет создавать производные переменные: например, reportsUrl может быть динамически сформирован как {{baseUrl}}/reports.
1.2. О связи с цитатой из ISTQB
Здесь я также должен с вами полностью согласиться. Вы абсолютно точно интерпретировали посыл ISTQB: стандарт говорит о качестве самого тестового стенда — его данных, конфигурации, производительности, которые должны быть максимально приближены к production.
Здесь я имел в виду, что наличие надежного механизма для переключения между этими стендами является необходимым шагом для выполнения этого принципа. То есть, скрипт — это инструмент, который помогает обеспечить работу на правильно подготовленном окружении, но он, конечно, не заменяет собой процесс подготовки этого окружения. Ваше уточнение абсолютно корректно и помогает правильно расставить акценты. Думаю стоит удалить это предложение из статьи, чтобы не вводить никого в заблуждение или вызывать лишние вопросы. 2.1. Почему бы не сохранять данные сразу в правильном формате?
В идеальном мире, где мы полностью контролируем все данные, так и следовало бы поступать. Однако, сценарий в статье отражает очень частую реальную ситуацию, когда тестировщик работает с данными, которые приходят извне в "неудобном" для него формате.
Как вы правильно заметили, скрипт №10 описывает именно такой случай. Откуда может взяться такая строка, как "123,456,789"? В "примере ихз практики" к этому скрипту как раз и дан ответ:
"Была ситуация, когда API возвращало список ID связанных объектов в виде строки, разделенной точкой с запятой. Для получения детальной информации по каждому из этих объектов нужно было отправлять отдельные запросы..."
Здесь тестировщик не контролирует формат ответа. Он получает "как есть" и вынужден с этим работать. Post-request скрипт одного запроса сохраняет эту строку в переменную, а pre-request скрипт следующего запроса разбирает ее для дальнейшего использования. Это и есть основная и самая частая причина существования таких скриптов-парсеров.
2.2. Почему environment, а не collection?
Здесь вы абсолютно правы, в большинстве случаев такая переменная, как productIds, должна храниться на уровне коллекции (collection variable).
Переменная коллекции используется для данных, которые относятся ко всей коллекции в целом и не меняются от стенда к стенду (например, userId для тестового сценария, productIds для проверки конкретного набора товаров).
Переменная окружения используется для данных, которые различаются между dev, stage и prod (URL, пароли, API-ключи).
Сохранение productIds в переменной окружения было бы оправдано только в одном специфическом случае: если набор продуктов, которые мы тестируем, должен быть разным для каждого окружения. В общем же случае, вы правы, переменная коллекции — более подходящее место. Спасибо за важное уточнение!
3 Не нашел примера про отправку запроса на эндпойнт, отличный от проверяемого, для получения данных в пререквесте с использованием pm.sendRequest()"
Ответ:
Вы указали на очень полезный сценарий, которого действительно не хватало в первоначальном списке. Благодарю, что обратили на это внимание! Этот паттерн является одним из самых мощных в Postman, так как позволяет создавать полноценные интеграционные сценарии. В статье этот прием используется в скрипте для получения токена, но его можно применять и для получения любых других тестовых данных.
Этот подход незаменим, когда для выполнения основного запроса (например, создание заказа) нам нужны данные, которые нужно сперва получить из другого эндпоинта (например, ID клиента или актуальный promoCode).
Вот как мог бы выглядеть такой скрипт:
Пример: Получение ID клиента перед созданием заказа
Предположим, для создания заказа (POST /orders) нам нужен customerId. Мы можем получить его из эндпоинта GET /customers.
Pre-request скрипт для запроса POST /orders:
JavaScript
// Проверяем, есть ли у нас уже ID клиента, чтобы не делать лишних запросов
if (!pm.collectionVariables.get("customerId")) {
console.log("ID клиента не найден, запрашиваю...");
pm.sendRequest({
url: '{{baseUrl}}/customers?limit=1', // Запрашиваем первого попавшегося клиента
method: 'GET',
header: {
'Authorization': 'Bearer {{accessToken}}'
}
}, function (err, response) {
if (err || response.code !== 200) {
console.error("Не удалось получить клиента:", err || response.status);
} else {
const customer = response.json()[0]; // Берем первый объект из массива
if (customer && customer.id) {
pm.collectionVariables.set("customerId", customer.id);
console.log(`ID клиента ${customer.id} получен и сохранен.`);
}
}
});
} else {
console.log(`Используется существующий ID клиента: ${pm.collectionVariables.get("customerId")}`);
}
После выполнения этого скрипта, в теле основного запроса POST /orders мы можем смело использовать переменную {{customerId}}.
Это хороший пример для дополнения статьи или для будущих материалов. Еще раз спасибо за ценное предложение!
Еще за благодарю вас за ценные замечания, вопросы и дополнения! Успехов вам! Если остались еще вопросы, задавайте: с радостью постараюсь ответить.
А а мне наоборот кажется, что так удобно. Каждый выберет себе тот скрипт который ему нужен. Конкретно в этой ситуации по-моему оптимальное решение. Хотя и вы тоже правы, ну я не умею якорные ссылки делать.
Cursor, Windsurf Мой опыт использования нейросетей показывает более качественные результаты во всех описанных примерах. Здесь важно использовать самые мощные модели, которые доступны в основном в платных версиях. Создавать заранее умного ассистента помощника для решение каждой конкретной задачи, проводить Его обучение на определённых шаблонах, примерах. Показывай агенту каким вы хотите видеть отчёт каким вы видите хотите бак-репорт каким вы хотите видеть тест-кейс и так далее. Что касается написания кода, то тут сразу видно что автор не использовал Cursor, Windsurf и др инструменты, который шикарно справляется с данными задачами. В общем для меня статья неоднозначна. С одной стороны я согласен NDA и некоторыми выводами, с другой стороны, нейронки способные сегодня на большее, чем описано в этой статье.
Спасибо, что поделилась! Лично мне было интересно прочитать о твоем опыте, т.к. сам когда-то учился и несколько лет преподавал тестирование в одном IT университете :)) Успехов в работе. + тебе в карму и в рейтинг !
Сервис добавлен в подборку. Огромное спасибо за рекомендацию еще одного достойного тренажера!
Огромное спасибо за рекомендацию! Обязательно добавлю его в список тренажёров, если это действительно работающий инструмент!
Замечательно, ваша рекомендация только усилит эту подборку!
3 из 4 работающих песочниц добавил в раздел песочницы! Еще раз спасибо за подсказку!
О, благодарю за комментарии! Спасибо, огромное, что поделились ссылками! Завтра посмотрю эти песочницы и добавлю в подборку.
Есть несколько вариантов использования нейронок через VSCode расширения - тот же KiloCode, например. Пользуюсь сам им давно - супер вариант. GPT бесплатный давно проигрывает Gemini от Google и Qwen. Так что пересмотрите выбор нейронок для решения подобных задач.
Так уже существует огромное количество IDE систем на подобие Cursor или CLI-агенты на подобие Gemini -CLI или Qwen-CLI с которыми все это делать гораздо удобнее.
Здравствуйте! Я старался дать максимально развернутый ответ. Видимо перестарался. Сказывается академическое прошлое :)) https://scholar.google.com/citations?user=_ibB59AAAAAJ&hl=ru До 2021 года активно занимался научной деятельностью, а в 2022 уже ушел в IT на графиках видно.
Спасибо за такой честный и жизненный комментарий! Вы указали на реальное больное место: на собеседовании любая компания – продавец, а кандидат – покупатель. И, конечно, продавец будет показывать свой товар с лучшей стороны.
Считаю, что Вы абсолютно правы как минимум в двух ключевых вещах:
Никто не признается в хаосе. Фразы «у нас тут бардак, процессы только на бумаге, а менеджмент некомпетентен» вы никогда не услышите.
Сотрудники могут искренне не осознавать проблем. Человек, работающий внутри системы, привыкает к её недостаткам и может считать их нормой.
Именно поэтому цель вопросов из статьи – не получить простой ответ «да/нет», а вскрыть второй слой и научиться «читать между строк». Это не аудит, а скорее диагностика по косвенным признакам.
Как превратить общий вопрос в острый инструмент:
Вместо: «У вас есть процессы?» Стоит спросить : «Можете рассказать на примере последней реализованной фичи, как она прошла путь от идеи до продакшена? В какой момент подключился QA, какие были трудности, как принималось решение о релизе?»
Такой вопрос вынуждает рассказывать историю, а не ставить галочку. И в этой истории вы услышите всё: реальную роль QA, наличие тестов, взаимодействие в команде, отношение к проблемам.
Вместо: «Вы используете метрики качества?» Спросите: «Какой инцидент на проде за последний квартал был самым болезненным? Как вы его разбирали и какие системные выводы сделали, чтобы такое не повторилось?»
Ответ на этот вопрос покажет больше, чем любые слова о метриках. Вы увидите, есть ли в команде культура анализа (RCA, post-mortem) или просто «починили и забыли».
Главное — не что вы спрашиваете, а как вы слушаете ответ:
Кто отвечает? Техлид, который «в полях», даст конкретику. HR или менеджер, далекий от процессов, будет говорить общими фразами.
Насколько уверенно и детально звучит ответ? Если человек «плавает» в деталях, скорее всего, процесс либо отсутствует, либо работает не так, как на бумаге.
Есть ли противоречия? Спросите на разных этапах интервью один и тот же вопрос (в разной формулировке) разным людям. Расхождения в ответах – лучший индикатор проблем.
Ваш скепсис абсолютно оправдан. Ни одно собеседование не даст 100% гарантии. Но умение задавать глубокие, открытые вопросы и анализировать ответы на них – это тот самый фильтр, который помогает отсеять большинство «шляп» еще на подлете.
Благодарю еще раз, что поделились своим опытом. Он очень ценен и отлично дополняет статью!
Желаю вам успехов и развития !
Супер! Очень рад, что мой труд помогает начинающим QA развиваться в выбранной профессии
Да, интересно, что взяли в работу? Какая модель и на каком железе покорилась?
Manual QA не заменит никогда от слова совсем. Автоматизаторов не сможет пока заменить тоже. Тут про разработчиков кричат, что ИИ заменит. Сократит время написания тест-кейсов, разработки тестовой документации, разработки тестовой стратегии и др. Но про полную замену речи нет пока даже близко. То что их нужно будет меньше в связи со сокращением трудозатрат это факт, но не более того.
Спасибо за поддержку! Этот материал-реальный кладезь полезной практической информации. В ближайшее время планируем выпустить следующую часть
Пожалуйста! очень рад, что нашли для себя что-то полезно
Добрый день! Огромное спасибо за ваши вопросы, замечания и дополнения! Это очень ценно для меня и многих читателей Хабра.
Отвечу на каждый ваш вопрос по порядку.
1.1. Зачем нужен скрипт, если есть нативное переключение окружений?
Ответ:
Вы совершенно правы: для простого переключения базового URL (
baseUrl) или одного-двух параметров между стендами стандартный механизм окружений Postman — это самый правильный и предпочтительный способ. В этом случае скрипт действительно будет избыточным.Однако, предложенный в статье скрипт решает более сложные, "нестандартные" задачи, которые часто возникают в реальных проектах:
Централизация сложной логики: Представьте, что в зависимости от окружения (
dev,stage) у вас должны меняться не только URL, но и набор API-ключей, ID пользователей для тестов, и даже включаться или выключаться определенныеfeature flags. Скрипт на уровне коллекции позволяет собрать всю эту логику в одном месте. Это делает коллекцию более читаемой и самодокументируемой. Новый человек в команде сразу видит всю логику конфигурации, а не ищет переменные по разным окружениям.Производные и дефолтные значения: Скрипт позволяет задавать значения по умолчанию. Например, если переменная
environmentне задана, он автоматически выберетdev, предотвращая случайные запросы наprod. Также он позволяет создавать производные переменные: например,reportsUrlможет быть динамически сформирован как{{baseUrl}}/reports.1.2. О связи с цитатой из ISTQB
Здесь я также должен с вами полностью согласиться. Вы абсолютно точно интерпретировали посыл ISTQB: стандарт говорит о качестве самого тестового стенда — его данных, конфигурации, производительности, которые должны быть максимально приближены к production.
Здесь я имел в виду, что наличие надежного механизма для переключения между этими стендами является необходимым шагом для выполнения этого принципа. То есть, скрипт — это инструмент, который помогает обеспечить работу на правильно подготовленном окружении, но он, конечно, не заменяет собой процесс подготовки этого окружения. Ваше уточнение абсолютно корректно и помогает правильно расставить акценты. Думаю стоит удалить это предложение из статьи, чтобы не вводить никого в заблуждение или вызывать лишние вопросы.
2.1. Почему бы не сохранять данные сразу в правильном формате?
В идеальном мире, где мы полностью контролируем все данные, так и следовало бы поступать. Однако, сценарий в статье отражает очень частую реальную ситуацию, когда тестировщик работает с данными, которые приходят извне в "неудобном" для него формате.
Как вы правильно заметили, скрипт №10 описывает именно такой случай. Откуда может взяться такая строка, как
"123,456,789"? В "примере ихз практики" к этому скрипту как раз и дан ответ:Здесь тестировщик не контролирует формат ответа. Он получает "как есть" и вынужден с этим работать. Post-request скрипт одного запроса сохраняет эту строку в переменную, а pre-request скрипт следующего запроса разбирает ее для дальнейшего использования. Это и есть основная и самая частая причина существования таких скриптов-парсеров.
2.2. Почему
environment, а неcollection?Здесь вы абсолютно правы, в большинстве случаев такая переменная, как
productIds, должна храниться на уровне коллекции (collection variable).Переменная коллекции используется для данных, которые относятся ко всей коллекции в целом и не меняются от стенда к стенду (например,
userIdдля тестового сценария,productIdsдля проверки конкретного набора товаров).Переменная окружения используется для данных, которые различаются между
dev,stageиprod(URL, пароли, API-ключи).Сохранение
productIdsв переменной окружения было бы оправдано только в одном специфическом случае: если набор продуктов, которые мы тестируем, должен быть разным для каждого окружения. В общем же случае, вы правы, переменная коллекции — более подходящее место. Спасибо за важное уточнение!3 Не нашел примера про отправку запроса на эндпойнт, отличный от проверяемого, для получения данных в пререквесте с использованием
pm.sendRequest()"Ответ:
Вы указали на очень полезный сценарий, которого действительно не хватало в первоначальном списке. Благодарю, что обратили на это внимание! Этот паттерн является одним из самых мощных в Postman, так как позволяет создавать полноценные интеграционные сценарии. В статье этот прием используется в скрипте для получения токена, но его можно применять и для получения любых других тестовых данных.
Этот подход незаменим, когда для выполнения основного запроса (например, создание заказа) нам нужны данные, которые нужно сперва получить из другого эндпоинта (например, ID клиента или актуальный
promoCode).Вот как мог бы выглядеть такой скрипт:
Пример: Получение ID клиента перед созданием заказа
Предположим, для создания заказа (
POST /orders) нам нуженcustomerId. Мы можем получить его из эндпоинтаGET /customers.Pre-request скрипт для запроса
POST /orders:JavaScript
После выполнения этого скрипта, в теле основного запроса
POST /ordersмы можем смело использовать переменную{{customerId}}.Это хороший пример для дополнения статьи или для будущих материалов. Еще раз спасибо за ценное предложение!
Еще за благодарю вас за ценные замечания, вопросы и дополнения! Успехов вам! Если остались еще вопросы, задавайте: с радостью постараюсь ответить.
С автотестами согласен, но ручники их не пишут, а в Postman как-то нужно находить выход. Так что это полезные скрипты в данном контексте.
А а мне наоборот кажется, что так удобно. Каждый выберет себе тот скрипт который ему нужен. Конкретно в этой ситуации по-моему оптимальное решение. Хотя и вы тоже правы, ну я не умею якорные ссылки делать.
Cursor, Windsurf Мой опыт использования нейросетей показывает более качественные результаты во всех описанных примерах. Здесь важно использовать самые мощные модели, которые доступны в основном в платных версиях. Создавать заранее умного ассистента помощника для решение каждой конкретной задачи, проводить Его обучение на определённых шаблонах, примерах. Показывай агенту каким вы хотите видеть отчёт каким вы видите хотите бак-репорт каким вы хотите видеть тест-кейс и так далее. Что касается написания кода, то тут сразу видно что автор не использовал Cursor, Windsurf и др инструменты, который шикарно справляется с данными задачами. В общем для меня статья неоднозначна. С одной стороны я согласен NDA и некоторыми выводами, с другой стороны, нейронки способные сегодня на большее, чем описано в этой статье.