Пишешь список требований (текущих и потенциальных) к инструменту, пишешь список потенциальных инструментов (Postman, jest, rest assured, etc.), пишешь список констрейнтов (бесплатный, опенсорсный, codeless, etc.), расставляешь приоритеты для каждого требования и оцениваешь поддержку каждого требования каждым инструментом. Ну и по итогам смотришь на получившуюся матрицу и принимаешь решение, какой инструмент удовлетворяет наибольшему количеству требований и требует наименьших трудозатрат и вписывается в констрейнты

Это если по умному делать. Но можно просто сказать, что постман - нерасширяемое говно и будем использовать %frameworkname%

А всегда ли можно определить список требований к инструменту, если у тебя еще нет этого проекта. Обычно по мере расширения проекта список немного видоизменяется. Ну, конечно, если ваш 3-4-й проект, то, наверное, понятно сразу, но в изначальном посте написано: встает вопрос...

Если разочек что-то проверить-поиграться, то открываю постман. Если сажусь писать тесты, закрываю и забываю про постман, и беру %frameworkname%

В зависимости от первый\не первый проект ты просто тратишь больше времени на ресерч и сбор требований.
Планирование там, роадмап, вот это всё.

Если проект абстрактный, то логичнее взять максимально кастомабельный фреймворк, тот же jest, и прикручивать к нему фичи по мере необходимости. Если изначально взять постман, то может наступить момент, когда окажется, что очередную фичу нельзя имплементировать в постмане (работа с бд, например) и придется всё равно брать %frameworkname% и мигрировать на него всё, что успели написать в постмане

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

Ну кстати для просто поиграться с запросами есть еще REST Client для Visual Studio Code.

PoC на Постмане самое оно. Плюс если вы лелеете надежду вырастить из мануальщика автоматизатора Постман лучший кандидат.

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

К кастомному фреймворку бдд обёртку можно прикрутить, опять же, и удовлетворить этим всех - и девелоперов, и ручников)

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

Добрый вечер) У меня вопрос. Я хочу стать тестировщиком, но не знаю с чего начать, подскажите пожалуйста 🙏
Может можете подсказать по курсам что-нибудь?🙏🙏🙏🙏😩

пойдет для начала

Спасибо всем за развернутые ответы по Postman/${framework}. Ещё такой вопрос: мои разрабы пишут unit тесты под бекенд, - вы проговариваете с разрабом что автоматизировать QA чтобы не перехлёстывать тесты?

Как правило, оно и так не перехлестывается, уровень проверок разный

Но порой я делаю полагаю юнит тесты и нахожу ошибку, - это значит разраб не доработал?  То есть я только автоматизирую e2e, интеграцию с БД, если нужно,- так? То есть например автоматизирую заполнение формы и как заполненные поля идут POST запросом в другой сервис и валидирую правильность выполнения контракта от другого сервиса и как GET’ом можно подтянуть из БД запостенные данные. Типа того?

@qajuniors Там есть закреп с литературой и тем что вам нужно.

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