Comments 4
Спасибо за статью! По ощущением она получилась больше про то как пользоваться Postman нежели как создать там документацию. Во время прочтения, возникло несколько вопросов:
Как вы решаете вопрос поддержки такой "документации" в команде?
Где храните такую документацию?
Множество скриптов в запросах и вские фишечки постмана наводят на вопрос обучения ребят, особенно только пришедших в команду, как вы работаете с этим моментом?
Спасибо за отклик!
Документацию ведет и актуализирует один специалист, в нашем случае аналитик. На эту работу выделяется отдельная задача в спринте.
Выгружаем в GitLab, шарим ссылку на всех заинтересованных лиц.
У нас есть два варианта. Первый — инструкции по использованию коллекций для тех, у кого возникли по этому моменту вопросы. Второй — если нужно какой-то новый скрипт добавить и возникли затруднения, коллеги обращаются с вопросами к тем, у кого опыта в кодинге больше. Например, наш аналитик обращается за помощью к команде разработки или SDET-специалистам.
В чем преимущества по сравнению со сканером?
У меня в практике встречались случаи, когда коллекции были очень объемными и постман обновлял их очень долго.
Описание разницы Swagger и Postman тянет на отдельную статью (например,
здесь https://apidog.com/articles/postman-vs-swagger/#limitations-of-postman-and-swagger).
В целом этот вопрос на каждом проекте решается индивидуально в зависимости от того, кто будет пользоваться инструментом, насколько это удобно, какие фичи нужны конкретно, какие инструменты принято было использовать исторически. Некоторые считают Postman более удобным в использовании и установке, поэтому и выбор даже просто из-за этого фактора может лечь на него.
У нас на проекте более 300 запросов, поделенных на коллекции по продуктам, к которым запросы составлялись, и проблем с прогрузкой не возникало)
Postman как инструмент документации