Skip to main content

30 Days of Postman - for Testers!

 


https://www.pexels.com/photo/white-and-brown-cat-lying-beside-a-laptop-and-toys-5468268/

 

Working with developer- focused tools can be a challenge for some testers: we may know what the words mean, but haven't used those skills recently enough to make the tasks simple. Or we may not have ever used them, other than at a quick glance to make sure that what we are getting matches what it should be sending. And some give results that require us to go find another team member to help interpret the results.

Being a more-independent tester has always been one of my goals - being able to use the tools that are common in the team, and be able to do at least basic tasks that support my tests with them. Our team used Postman for many of the API tasks that we had, so exploring this tool was a natural fit. There are alternatives it there, both graphical and command line, so feel free to explore! The items that you can do, and tools that help you in other ways , such as Swagger,make API testing not only a chance to explore, but for me served a a way to connect with the team on a different level. Most of them enjoyed teaching, so this was good chance to learn.

I admit - some of the terms and activities may not be as familiar to testers as they are to the development team - this is also a chance to make sure we are using the same terms for activities. Unless you have used either Node or some flavor of JavaScript in your learning, this may slow you down. But that's okay- learning this tool at your own pace without needed to be worried about a deadline may help you learn more - and give you time to set up some scripts that will not only help you, but those in the future that may need them, and quickly.

Working with your developers, once you have tried a few times, is a way to build trust and learning in the team. The skills that this exercise brings can include that you are trying to understand what they experience, as well as the fact that you can be even more valuable to the team. Getting these scripts set up will save everyone time in the future, and make it easier for the next person.

You may be lucky enough to have someone on your team that is skilled with Postman - make sure both of you count this time someplace! It may only be a few minutes a week that you will need, but the fact that their is another person that is skilled will leave them a bit more free time - and you can gain experience in where the tool is used in your organization.

And if you happen to be the only one who uses it? Then you can share this at a lunch and learn, or with your manager - and show the benefit of having these skills. They YOU get to teach: there is no faster way to cement your learning that making sure you have correct answers to questions.


Popular posts from this blog

Drop-down values for injection

cover_image: https://www.pexels.com/photo/flat-lay-photography-of-gold-iphone-on-opened-notebook-beside-pen-583847/ canonical_url:  --- Photo by Jessica Lewis 🦋 thepaintedsquare   Learning in public is grand, and when you have a team that is willing to help with something that seems simple, but you fall into overthink for the wrong items, it can really help to type out your thoughts, actions, and what the program does to frustrate you. And in this case, getting a value I could see in the debugger was the issue The automation needs to check for page elements – and the drop-down selector triggers potentially different elements. Plus, depending on the user logged in, there may well be different options available in that drop-down. Then, I can get the options available for the user on the drop down, get their values, cycle through them, and verify each set of elements on the page. My test account for this has four options on the drop-down, so I budgeted a couple of hours to get ...

Redefining my Role

Confession: I am a nice person. I'm the one that will check on people - and be concerned if someone is acting off. Or donate money to make sure the potluck I can't attend has everything it needs. This has had an effect on my career: I was less willing to point out 'in public' errors in the code or things that just felt off to me while testing. And this stopped me from being the best tester I could be. Trying to be kind to someone that was having a rough patch, or simply not wanting to expose them to a potential attack was both me trying to get things correct, but care for them. I've decided to embrace this aspect of myself, and shift my focus. Being 'nice' to the product, or company must include being the voice for both end users and the team. Finding things that will be difficult for them, confusing, or flat-out wrong is a major part of my job. And this was also one reason I don't 'delight', at first, when something doesn't work as expected:...