Ben Weese

Testing with Postman: Getting Started

I am writing a Postman Series to show the full extent of what a software tester can do with this tool. I spent a year learning and cultivating my Postman knowledge because at the time I wanted to show my company what I could bring to the table. I would like to think I became an expert on the subject but have seen many people downplay what postman is capable of via testing.

While we no longer use Postman, a lot of the excuses I have seen people use as reasons not to use Postman have mostly been something they didn’t know Postman could do. Postman is more capable than what most might think for automation and is not just a manual or codeless tool.

For those wondering we switched to Rest-Assured so we could store passwords in environmental variables instead of in the code for security reasons.

What is an API and why am I testing it?

Wikipedia defines an API as “An application programming interface (API) is a connection between computers or between computer programs.” Most will use it as a communication between a browser and a database stored elsewhere. Behind the prettiness that is this blog there is a lot of APIs that run. GETs, POST, PUTs, DELETEs, and many other quick calls that pull data.

Even when entering in the web address above and hitting enter, an API is calling a get and pulling down the HTML, CSS, and Javascript for the browser. When coding you want to write lots of integration test which are also known as API test. This test the communication between the website and the database. Input wrong data and the site errors. So you want your test to make sure the site doesn’t break when taking in the right or wrong inputs.

Testing Basics

So to get started with postman you will need your API url and whether it is a GET, POST, PUT, DELETE or various other method. Your Developer should give you documentation on what the endpoint is and how it should behave. This is not always the case but you can write some basic test.

Let’s use the good old Star Wars API for our first setup.Postman with 2 testWe add the URL to Postman and then a cool thing we can then add is 2 test already pre-written for us with a simple click.

This checks that the status code that comes back is a 200 which means success! For negative test cases you can replace the 200 with a 400 or what ever code you need.COPYCOPY

pm.test("Status code is 200", function () {

This checks that the API responded back in 200ms which is the standard time we wish the API to respond in. Sadly this test failed.COPYCOPY

pm.test("Response time is less than 200ms", function () {

Note I took out the ;’s cause they are unnecessary.

There you have written your first test.

Running Your Test

You can run each API call individually but the real power is creating a collection of calls that can then run in order. You basically create a folder of your calls and they will run one right after another when you run the collection. Later we will go over how we can run our collection in CLI with Newman.

Learning Links

From Manual to Automation

Return of QA Hipster

I started my QA Journey back in 2013 and it has been a crazy ride to get to where I am today. As unique as my story might be there are many out there who started on a similar path. Sometimes breaking into tech is just finding that one job and moving up from there. I have seen many people in reddit and through out the web looking to get into QA, so I thought I would tell my story and give some pointers on the way.

Growing Up the Son of a Programmer

I grew up an elder Millennial in the boom of the internet. My dad was a computer programmer and former accountant. He always questioned purchases and saving money but he never questioned buying me my own computer. I was on a computer since the time of Windows 3.1 playing great games such as Battle Chess and Prince of Persia. Computers came easy to me like a fish to water.

When I graduated High School I went off to college to study Software Engineering. This plan did not work out as I lost loved ones during that time and sunk into a depression after 3 and a half years away from home. I later finished my degree in Management Information Systems.

The 2008 Fall of Tech

When I returned home and was trying to find work 2008 hit. This was as the tech industry had a huge lay off. More qualified people then me were out of jobs and I had to find work elsewhere. I ended up working in group homes because I had experience with autism having an autistic brother. The times were hard but I got by. During this time I started dating my wife and we got married.

Getting Back in the Game

When we both were looking for work her brother got me an interview at a Tech Startup. The company was a little old to be a true startup but it had the culture. I started off as Tier 1 support for the software then moved to Tier 2. The entire time I was working support I was also helping out in finding bugs and testing the software. After a year I moved into QA and began my career in a field I now love.

The software there was written for Macs and was not web based. They kept wanting me to get into automation since I could code but the issue at the time was that the software was not built for it. There was no tags in place, and making the software work for that would have been an major undertaking. Eventually we started building a web based approach. From there I was able to add automation with Java, Selenium, Cucumber, Serenity, and Postman. I spent a year working on automation before I was later recruited to the company I work for now.

I should note that when I was working as a manual tester, I was always looking to improve myself and read many blogs. I even started one of my own that had 1000 followers called QA Hipster. Eventually I had to give up on the blog as life took many turns but I am hoping to return to the blogosphere with this blog.

Moving to Automation

My current job was the hardest most technical interview I have ever been to. They grilled me harder then any other job and unlike the many QA they found before me I passed. I was hired for more then double my previous salary showing me how little I meant to the company I was at previously. They already had 1 very accomplished QA Engineer on the team who had been Automating as long as I had been in QA. He however was mostly frontend and I had backend automation experience from my year building my own testing framework. Luckily before I joined the team had decided to use Postman and I was familiar with it. I will be making more post on Postman as time allows, even though we have moved onto a different framework.

I took to automating the backend and read many articles so I could become the best I could be. Over the year I wrote thousands of backend test as well as manually testing the front end. The following year the other QA and I trained each other and now we are both good at Frontend and backend automation. I will say that working with someone who learns as fast as you and has the knowledge really helps.

Find someone that you can grow with, and you will become an unbeatable team. Remember though that just cause you are Automating now does not mean you stop manual testing. Half of automation is manually testing what you are about to automate. Exploratory testing is also a big thing, Users will always find new ways to break the software so try to find those new ways first.

How Do You Start?

For those looking to learn automation please visit: Test Automation University

It was founded by Applitools and has so many great classes for teaching automation for free. If you are wanting to add automation to your current stack, or learn to on your own I highly recommend it. If you don’t know where to start I would start with the Web UI Python Path as Python is now the #1 language instead of Java.

Common Sense, is a Super Power!

​This week the Ministry of Testing Bloggers club has decided on “What’s the non-technical skill that every tester should have, but most don’t seem to?”

Being a tester move have a very technical mind. A lot of time with intelligent technical people they lack basic common sense. I have seen mountains made out of mole hills, useless tickets, and tickets that no one will ever fix. The button is 2 pixels off… ain’t nobody got time for that. A new feature has some bugs do to a weird workflow. Ok we can fix it but we don’t need to hold shipping to beta when there is a work around and most people will not use that workflow. Plus a new feature is not breaking current functionality. Take some time to think before standing up for that bug. Yes there are bugs that need standing up for and by golly you do it but make sure it is worth it and not a waste of everyones time. Use Common sense when judging the bug. 

Take a Look, It’s in a Book

This week the Ministry of Testing Bloggers Club is tackling “What non-testing focussed book do you wish you’d been given on your first day testing.”

I have been working in the realm of manual testing for years. Over that time I have been given a lot of lead way and have been able to do more then our average tester. This is because I took a lot of programing courses in University.  Being able to look at the code and understand what is going on and understanding why something breaks has helped me loads in testing.

It allows me to find new tools, learn coding for fixing minor bugs or just figuring out a little more then the manual tester. I think all QA should have some basic understanding of Object oriented programing. Not only does it help you become a better tester your developers listen to you more. 

So when you have time learn some coding. This Head First book about Java is great but you can also try Codecademy.

To QA or Not to QA That Is the Question

This sprint for the Ministry of Testing Bloggers Club the topic was “Critic some widely known/accepted concept in the testing community” Being that I have never really been a full fledged member of a testing community I don’t know what they widely accept.

The one thing for years it was thought that testers were not needed, the clients could test the software and give feedback as soon as it was released. That caused a lot of issues with calling clients to tell them things have gone horribly wrong. Then the age of manual testers came and all was well, but as software evolves so does Testing. The age of automated testing has been happening everywhere. 

A belief that has also been spreading in bigger companies is that they can just patch it so feel free to release it to the customer. We can fix it when they complain as patches are so readily available. This is very prevalent in the gaming community to the point where sometimes you have to pay to fix a bug. 

With automated testing growing some think that the manual tester is a dinosaur no longer needed and all they need it automation. Robots then rule the world and order is obtained. Automation can not test everything, the human brain is more complex and is needed for full testing. Automation is a great tool for repetitive and simple test.

What is really needed is a good balance of automation and manual testing. Automation does basic test leaving manual testing to be more in dept.

Give Yourself Time to Learn and Grow


Well, I am back after 2 years off, and I have a lot of new stuff to blog about. I have recently joined the Ministry of Testing’s Blogger’s Club, a group dedicated to blogging about testing by providing topics, blogging together on general topics, and being the motivation we all need. I hope with their support and adding 2 more years of testing under my belt, I can create a better blog for everyone.

​​​​The first topic is “a technical tip every tester should know” so I went with give yourself time to learn and grow as a tester. Something this blog supported in the past and will continue to support in the future.

I have worked for a company manual testing for 5 years now. In this time there has been little to no growth in our QA department. Just retesting the same parts of the software over and over. Waiting for when a new feature can be tested to pull you away from the monotonous test you run through on a daily basis. If our QA begins looking for other jobs, they realize that our company is behind the times, as manual testers, are coming to an end. Manual tests are now only a part of what most QA do in this modern world. A lot of our employees hunger to grow, have something they can achieve, and while others like where they are and don’t want change. 

However, I have been fortunate my company has allowed me to learn and try other things, becoming a better tester. They allowed me to do this because I have a coding background and the tenacity to ask. So they trusted me run new tools, fix minor bugs, and become the one everyone goes to when they need help. Still most of what I did was manual testing with a sprinkling of extra fun tools. I was still stagnating at as tester in my community when all other companies in my location are moving to include automated testing. 

Something then happened that changed everything. Our company got some new management which listened to our employees. They allowed our developers to launch a new plan for our software taking us into the future. With these changes they asked if QA could begin automated testing with the new project. So all those years building the trust they put me to learning and researching Serenity, Cucumber, Selenium and Postman. I then get to teach the others in my department. The company is finally moving forward with a plan one Developer had for years for our software, and what I been proposing for years is finally coming to the our company.

The drawback with learning and growing in such a short time is growing pains as my head explodes with knowledge and headaches. It would be nice for every company to allow a day of learning similar to what Google has done in the past and has become a growing part of Agile culture. Don’t stagnate you’re learning or try to do it all at once because it all of a sudden becomes relevant.

Learning new things in your industry helps you become better at your job. It gives you more responsibilities, makes you feel valued as a team member. When you learn and grow, the company learns and grows with you. 

It was Gandhi who said, “Be the change you want to see in the world.” 

Be the change you want to see in your company. Sometimes it takes patience to move forward. Sometimes it takes only one person to believe in your idea. When you learn and grow as a tester, you learn and grow as a person. 

Google is your best friend when it comes to learning and researching. Bookmark links and document everything you learn so you can return to it later. Documenting helps you to not forget what you learned and allows you to share your newfound knowledge with others. When you document and share you become an expert because it helps your brain retain the knowledge you have learned better. 

My last Post

I worked on this site and blogging about testing for 10 months and it was great to see it grow and to see everyone reading and responding to what I had to offer. This was a great learning experience and I would not give it away for anything in the whole world. The reason I took a break was in September my Best friend of 26 years died in a tragic motor cycle accident and it rocked me. I was unable to continue with some of my projects and they suffered for it. I am now looking at this new year with fresh eyes.

This site will continue to be up for another 325 days before it will cease to exist. Please fill free to go over all the knowledge I put into this site and feel free to contact me on Twitter or through the site.

Thanks so much for reading my blog.

Taking a break

Lately I have had some things happen in my personal life that I have not been able to keep up with all my side projects. I will be back up running as soon as I can and may even be next week. But this week I am taking a break to let my personal issues cool down.

Remember everything is a test and your job is pass it or find a workaround.


Requirement Analysis

Finding the requirements for the software can be hard but a tester has to know when the software breaks and what it takes to run the software. If the tester runs at minimum requirements and it breaks then the requirements are wrong. Some times it is up to the developers what it runs on, some times upper management, and sometimes a tester runs several test. This will also have to be well analyzed and documented. You will also have to take into consideration your market and what kind of computer they have. If it takes to expensive of a computer you loose your market.

Requirements Analysis

  • Eliciting requirements:(e.g. the project charter or definition), business process documentation, and stakeholder interviews. This is sometimes also called requirements gathering.
  • Analyzing requirements: determining whether the stated requirements are clear, complete, consistent and unambiguous, and resolving any apparent conflicts.
  • Recording requirements: Requirements may be documented in various forms, usually including a summary list and may include natural-language documents, use cases, user stories, or process specifications.

Remember there is several things besides the software and the customers who effect requirements. Such as Architecture what other programs are you using Java, squeal? Is the structure meeting the requirements? the design? the behavior? Allocated?

Remember to take all this into consideration and many more when setting your software requirements.