Here’s a short tutorial post showing how you can fire off a message to your Slack channel when using Postman’s low/no code feature Flows. The good news is this is really easy, and you don’t need to know how to code to do this.
3. select the workspace you want to post a message to
4. On the newly created app, select incoming Webhooks on left hand menu
5. Toggle Activation to ON
6. Click Add New Webhook to Workspace
7. Select Channel to post messages to. Copy cURL request.
8. Open Postman, click Import button
9. In Raw tab, paste the cURL request from Slack copied in step 7
10. Save request in a new collection (e.g. “Slack API)
11. Create a dynamic variable for request body message text AND webhook token (optional). Save variables in new Slack API environment.
12. Send the POST request. Confirm Slack message received (yay!) Save example in Postman.
13. Open your Flow. You can now add a Send Request Block for the POST Slack Message request, adding in a variable for the message you wish to send. Remember to add to the reject output of a conditional block if you only want to send if something has failed.
Et voila! Your message will now be posted into Slack should the condition fail to be met.
Julia’s talk included the following slide, which detailed 6 important high level scenarios to consider when performing API tests. I thought it might be good to show examples of how, you can execute tests in all 6 areas using Postman Flows.
Scenario #1 Schema Testing
As JSON parsing seems to be done on a field by field basis in Flows, it doesn’t currently seem possible to extract the entire schema from the response body in order to compare it with a stored value (correct me if I’m wrong folks!). However, if you want a visualisation that your schema test stored within the tests tab of your request has worked, then here is a good way to do that.
Scenario #2 Security Testing
You can use the create data block to add different data sets to run against a request. I walk through a very aesthetically pleasing example here. 😻
Scenario #3: Workflow Testing
As highlighted by Julia Pottinger at the Ministry of Testing’s amazing Testbash UK 2022, testing an end to end workflow through API calls is often essential. Think about it logically, how do you know if a delete call has worked if you don’t then check the data isn’t then available? Using Flows to test workflows is a major use case for this Postman feature, because you can see exactly what’s happening. Here is an example workflow test using Postman Flows.
Scenario #4: Negative Testing
Here I cover 2 different but connected scenarios:- 1. You want to verify the status code and message (e.g. 400 Bad Request) 2. You want to verify a string within the error response (e.g. “the length must be 3-18 characters”
An added bonus is generating test data within Flows using both lists and records, which although might not be ideal for large test data sets, would be very handy for smaller ones such as testing what happens if 3 different invalid inputs are entered for the same request.
Scenario #5: Performance Testing
So we know that scaled and in-depth performance testing is one of the few things that Postman isn’t really built for. Although Flows is no exception to that, if its cheap and cheerful performance testing you’re after (say, executing the same scenario 10 times and checking the response time is under a certain threshold) then that is absolutely doable.
Scenario #6: Positive Testing
Last but certainly not least – time for the happy path! 🙌
In this example, I show how it is possible to execute 6 endpoints at the same time, and apply the same conditional logic to all of them to check:- * status code is 200 * response body value is correct (“status: UP”)
This gives a really clear indicator when running a health check against several different API’s at the same time. Which is one of the huge benefits of using Flows.
And that’s it! I hope that structuring this post around Julia’s essential test scenario’s made sense to you, and that you were inspired to try Postman Flows next time you are looking to test your API.
TL:DR – see below section for a list of useful resources to begin learning more about Application Programming Interface (API) testing.
Today I got a message from Coders Guild software testing graduate Alexander Olakunle, who I have to say I found to be a very dedicated and driven person, who has worked incredibly hard on the course and landed his first testing job with Ordinance Survey (congrats again Alexander!). He asks:-
During the short training course, we cover API testing, but only from a high, theoretical level.
I thought it might be helpful to others (that means you!) to list some excellent, beginner-friendly resources to try out if you’re in a similar position to Alexander.
If you like seeing how different people tackle the same problem, I’d definitely recommend taking a look at the Test.Bash(online) talks from the Ministry of Testing. 4 different sets of people answered the same challenge, and gave demo’s on how they did it – so many useful tidbits of practical insight there.
Dave Westerveld has created a great book (published by Pakt) called “API Testing and Development with Postman” which serves as a fantastic introductory book for API testing (don’t let the development bit of the title put you off!).
If you complete that course, you can then go on to do my Test Automation Course API Test Automation with Postman, particularly if you’ll be using the Postman tool for your testing efforts. If REST Assured is something you’ll be using, Bas Djikstra has a TAU course on that too.
Mark Winteringham – Not a lot of people know this 😉 but Mark is gearing up to publish the final version of his incredible book Testing Web APIs. Its got loads of practical exercises in, so if you enjoy working through those you will get so much out of reading this book.
Of course, its well worth doing your own research, and I’d love to hear if you have found other resources elsewhere that you’ve benefitted from – drop me a comment and let me know, that way I could learn something new too!
For the last two months, I have been working as interim QA Relations at Mailinator. It isn’t often in our careers that we’re able to have a risk free go at trying something new. But wanting a bit of a gap from leaving my full time testing role to starting my next one, this opportunity was one I had to grasp.
Would I like to do QA/Dev Rel type stuff in future? Was it what I expected it to be? Would I recommend it to others? Read on to find out my honest opinions…
What did QA Rel look like?
Despite being almost 20 years old, Mailinator had never had a QA Rel before. Therefore, this was a great opportunity to evolve and learn from each other as we went along. Alongside weekly meetings with both the wider company and individual 1:1’s with the CEO, I was given a lot of free reign and some loose guidance along the following lines:-
Get access to social logins and regularly post interesting stuff
Learn more about the product itself
Write a blog post or two for the site
Give your professional insight as a tester on how to improve the service
Having a team that were enthusiastic and super keen to hear the views of a tester (their key customer) gave me confidence to give my opinion on a lot more areas than I first thought I would. The following things give a flavour of the key activities I got involved in:-
Social Media Stuff
What I did
Tweeted and Posted on LinkedIn and Twitter most days of the week
Polled users to find out what freebies they prefer
Created 6 tutorial video’s for an Essential Guide blog post
Penned 4 further blog posts
Learned how to use Yoast to improve a posts Readability and SEO scoring
What I learned
Creating a blog for a company is a different ballgame to creating one for yourself. I thought this would be the easiest part of the role, but it was one of the hardest. I learned to give myself plenty of time both to write the initial draft of the blog, improve the copy using the plugin Yoast to get good SEO, accessibility and readability scores. I also took the extra time to insist on getting all posts reviewed by the team. The feedback definitely helped make the blogs better quality and avoid a few clangers!
Also – people really do not like to follow companies on Twitter and LinkedIn. I found it much harder to get “engagement” through the Mailinator account than when I posted as myself.
What I did
Created a Trello board of new bugs, customer insight and recommendations
This wasn’t part of the brief, but it is actually impossible to spot something that could be better and not feel compelled to be a part of making that happen. My Trello board was shared with the team, and included a lot of annotated screenshots (I use Techsmith’s Snagit – a paid tool but worth every penny).
What I learned
Not everybody loves Trello! There were a few bugs that made their way through the system and were reported by users that I had on the Trello board beforehand. I guess the lesson there is to find better ways to highlight important bugs and find a way to communicate that works for the whole team.
Reviewing Existing, Revealing New Features
What I did
Created Mailinator’s first public API in Postman, including a “run in Postman” button to easily get up and running.
Gave insight and feedback on a new pricing strategy and other features
Completed a competitor analysis
Created a document identifying 10 ways the company could improve that I debriefed with the CEO
What I learned
This was mostly stuff I hadn’t done before, so trying out new things and getting positive feedback was really rewarding. Sometimes its worth pushing yourself – as long as you’re not BS-ing about your experience beforehand, everything is a learning curve!
Also, at my leaving meeting the lovely CEO Paul said that having someone on board the team that was so enthusiastic about the product being a sounding board for new features meant that there was stuff now baked in to Mailinator that otherwise wouldn’t have been. That’s something I didn’t see coming, but a nice impact.
Also, I love Postman. Tell me something I don’t know. 😉
Working with 3rd Parties
What I did
Lined up guest bloggers to continue to provide content in the coming months
Coffee with Simon Tomes, community boss at MoT, to talk all things community and ask advice
Asked the community for a recommendation and brought on an amazing Tech Writer to improve documentation
Liaised with Ministry of Testing Marketing, Sales and Community peeps to understand how they could help Mailinator to improve their interactions with the testing community
Arranged for Mailinator to Sponsor a MoT event
Liaised with the community and Postman DevRel Sean to further improve the public API collection
Worked with the lovely Himanshu at cloud based cross browser testing provider LambdaTest on exploring a possible integration. This involved investigating LambdaTest’s capabilities, asking others in the community what they thought of LambdaTest, and doing a proof of concept to understand how any integration would work. Have to say I was pleasantly surprised by what this platform could do and how positive others were about it – so much so that I used it to do a tech test when applying for a new role.
What I learned
I learned that speaking to other people and forming genuine and positive relationships can be done, and was much easier for me than I thought it would be. (trumpet well and truly blown there Beth!) I made sure at the start of the assignment with Mailinator that QA Rel was not going to be another word for Sales – an area which I’d be terrible at and which they 100% agreed with – and I definitely think that is an important principle to stick to.
At least 2 of the above 3rd parties have reached out to me to ask if I’d be interested in doing further work for their organisation, so this feels like something I did a pretty good job at.
What did I do?
Getting before and after data on our social media activity wasn’t part of the role, but I felt like it should be. If for no other reason than to measure my own success.
Increased number of Twitter Followers by 112%
Increased number of LinkedIn Followers by 554%
Increased visitor metrics to Linkedin page by up to 850% (average 200%)
We aren’t talking about huge numbers here – for example we crossed the 1000 followers mark on Twitter a few days before I left. But given Mailinator had been on Twitter for 12 years, I think this was a pretty good milestone!
What did I learn?
I learned that all of this stuff isn’t really about numbers. I’d sooner have one meaningful conversation with someone than 100 likes to a post. But, over time, they do give trends and they do tell a story. Focus on the macro side of things.
Would you recommend QA/Dev Rel?
In much the same way that since home schooling last year has made me appreciate the teaching profession in a whole new light, I now feel the same way about Developer / QA Relations.
Dipping my toe into this stuff for, lets face it, a very short amount of time, has really made me realise what bloody hard work this stuff is! There is a world of difference between doing this stuff for yourself, and being paid to do it for someone else. It takes a lot more energy than you’d think, even for small stuff like writing a tweet in just the right way.
I think I enjoy talking about products, tools and companies that I genuinely am already passionate about – and Mailinator 100% fitted that category. This made things so much easier, because I didn’t have to fake authenticity.
Would I recommend it? I think perhaps as a side hustle its a fun thing to do. And I’ve met some mega people that I’ll definitely be staying in touch with and hopefully will help out in future. I hope for myself and other testers, I have done a good job at persuading the Mailinator team of the importance of decent swag. But it absolutely made me realise that I missed testing too much, and after working in QA for 15 years, that’s definitely where I want to be. I’m so lucky I had the chance to try this out, and am so grateful to the incredible team at Mailinator for helping make it such a blast.
I start my next adventure tomorrow, with Ada Health, as a Senior Quality Engineer.
I’m all about the stories, so if you’re reading this because this type of thing is something you’re considering, please get in touch via the contact form or LinkedIn and tell me your tale!
I’m now going to publish this post with no review, second opinion or Yoast. So its back to mediocre blog posts I’m afraid folks, but I think for me, that’s exactly how I like it 😉.
I’m very *very* excited to finally be able to say it out loud. As you may have heard, I’ve now left my previous role as Staff Quality and Test Engineer at Smoothwall.
I’m genuinely thrilled to announce that for the next 2 months I’m going to be helping the team at Michigan based email testing specialists Mailinator as their QA Relations advocate. 🎉
I’ve known CEO Paul for awhile and when I mentioned I was taking a few months off he reached out to see if we could work together – and there was no way I was going to turn this opportunity down. ✨
I’ve since met the Mailinator team and can confirm they’re a lovey bunch, their product is legit amazing (I couldn’t back it in all good conscience if it wasn’t) and I’m itching to get stuck in!
Who are Mailinator?
I’m going to be writing a lot more about Mailinator over the coming weeks, but here are some of the systems features I’ll hopefully get to show off.
Ever got stuck needing to automate a signup process that asks you to click a confirmation link sent via email? Or maybe your end to end tests fail because you’re asked for 2FA verification when logging in and you can’t automate that? Or how about testing the SMS messages your system sends? If so, I’m here to show you how Mailinator can help to fix those problems.
So many things to talk about, just hope I have time to do it before I plan on returning to the world of testing in March.
So yeah, if you can’t tell, I’m just a tad excited about this particular gig. Please reach out to me on Twitter or LI if you want to hear more – note I’m not a sales person, my job is to start conversations and share my knowledge. Let the adventure begin!
However, I think when we’re learning, it’s good to have examples we can refer to – that’s always the shortcut I use to get inspired anyway! Postman have put a lot of time into creating some amazing Flows content for their Learner Centre, so I’d recommend starting there. However, there isn’t yet much QA/Testing specific stuff, so here are some working examples I created to help get those creative juices flowing. Note these are all basic Flows that may form part of a larger Flow should you wish to do something more advanced.
*Updated March 2023* If you want to loop through a response and apply a rule to it then you can find an example picture below. Here I define a list of names, and using a FOR loop take each name, do something with it in the Evaluate block (combine a string + the name) then output that response to a Send Request block. I have asked OpenAI to generate a poem about a tester, and output this to the log, and also an output block.
There are also Repeat blocks, which are handy if you want to re-run something a set number of times, or a Collect block, if you want to catch all of the output data as one homogenous chunk before you pass it through the flow. A bit of decision logic can be found using the IF block.
Flow #3: Take Inputs From Multiple APIs
This example shows how you can take requests running against two different environments from two different collections and perform a Check on them both to output to a terminal (in the GA Flows you could use the Evaluate and Log blocks. Another cool feature of Flows is the ability to send multiple API requests in parallel, so if you want to fire off multiple requests at the same time, just have the Start block connect to as many Send Request blocks as you need.
Flow #4: Passing Data Between Requests (descoped)
From version 9.5.0, you can use the Create Durables block to complete the task of passing data between requests – as long as you have created an example API request first! By adding the token as a durable type, the generated value can be persisted throughout the Flow. Note – this has now been replaced by the Create and Get Variable blocks (see Flow #1)
Flow #5: Generating a visual Output block
I’m hopeful that one day the test summary block will make a reappearance. However, the brand new Output block is a brilliant way to visualise the data that’s hiding in those API responses. Images, charts, even YouTube video’s can all be shown (I’m kinda thinking of it like a Datadog dashboard but at API level only).
TL:DR – below is a post I wrote when leaving my last role as Staff Quality & Test Engineer. In a very strong market with lots of people reaching out to work with me, this helped me to put my finger on exactly *what* I wanted to get from my next role, and meant I didn’t persue opportunities that weren’t the right fit for me. It also meant I could privately share this with recruiters or hiring managers when they asked “So, what is it that you’re looking for?” – Having an answer to this question in advanced definitely paid off. Feel free to use this template or create your own when contemplating your next career move. 👍
Inspired by Elisabeth Fiennes’ wonderfully written article all about QA recruitment, I decided I would take her advice and use this space to tell you, potential new boss, what I am looking for in my next role. This is written in the hopes it will help you make a quick assessment as to whether I am someone who you could see yourself working with. If I’m not, no harm done, and no time wasted. If you like what you hear, you know where I am!
What have I done so far?
I’ve been testing for 15 years now. I’ve been a contractor, consultant and permie, and I’ve enjoyed them all. I’ve worked for some of the biggest companies in the world, and some of the smallest. I’ve also worked with some incredible people. But I have to be honest, despite successful delivery, repeat work, glowing recommendations and even poaching requests from clients, I’ve suffered from imposter syndrome at them all.
The pandemic was a huge leap forward for me in terms of what I have pushed myself to achieve outside of work. I’m so proud to be a Test Automation University instructor, as well as to have helped many people more locally land their first testing role following the Coders Guild bootcamp I helped to create and deliver, including designing and delivering a full day workshop on API testing.
I like helping people, but I also like to be helped myself, and there is so much still to learn – you never really master everything I know, but I want my growth curve to be steeper than it is currently.
Within work I’ve been promoted to the only Staff Quality and Test Engineer in my company, I’ve persuaded my company to hire and taken responsibility for successfully onboarding an ex-bootcamp learner as their first ever Junior QA. I’ve rewritten a training programme delivered through the Web app I currently work on, which has certified over 25,000 teachers, dinner ladies and school bus drivers up and down the UK. And lots of other things I’d love to discuss over a nice friendly interview chat. <nudge nudge >
What are my career goals?
I really want to grow my technical skills. I know everyone says that, but I feel that I’ve done as much as I can to grow them on my own and I need to work in an environment that actively supports me to improve areas such as API exploratory testing, Shift left and right practices, non-functional, DevOps, code reviews, accessibility, security, automation etc etc. I learn best by sitting down next to someone approachable and kind, getting feedback on my work and measuring progress. I want to be confident in my technical ability.
My ultimate goal would be to continue to pay forward the skills I’ve learned in some way by teaching them to others in a training/coaching capacity (alongside my day job in QA). My mum has recently retired from a lifetime of teaching, which is a passion that I’ve inherited from her. As my YouTube channel, podcasts and various community bits and pieces show, I’m a sharer by nature, and when I am confident in my knowledge of something it gives me a huge kick to be able to help others master it too.
I want to speak at my first international face to face testing conference and I think I am on a good trajectory to making this happen.
I want to achieve something meaningful. I like being able to say I’ve made a difference.
What kind of company culture do I enjoy best?
Here’s a wee list, I expect my next company will have or be working towards most, but probably not all of the following:-
A quality culture which enjoys finding out new things, experimenting and promoting quality. A team of people who want to do the right thing.
An experienced and technically gifted individual or set of people who can coach me. I want to seriously assess and improve my technical skills with hands on code reviews, pairing and training – if your workplace can’t commit to 1 or 2 hours a week to support me in this effort, then it has to be a hard no from me.
Vision – A leader with a vision I can align with. I’ve been most successful and found work most enjoyable when I can hook onto the vision of a leader and focus my energy on implementing what they want. I’m great for bouncing ideas off of, but really I’m a completer finisher rather than a big picture person.
Remote – Hybrid working is the model for me – I am happy to work towards being fully remote, or 1-2 day per week in the office (within West Yorkshire). If a monthly in person is required, I can stretch to Manchester, York, London or Newcastle. If its quarterly, I can travel anywhere in the UK and once or twice a year I can travel anywhere in the world. I can drive if necessary but I also live close to train and bus options.
Flexibility – I currently work 4 days a week, the 5th day being a flexible choice. I am very flexible to the companies needs, and often work evenings or have early starts in order to get the job done (as well as the occasional weekend). I’m focused on delivery rather than presenteeism and would expect my workplace to share the same values.
I hope you are still reading at this point, and think my expectations are realistic. I hope there are plenty of companies out there who can meet them. Fingers crossed you are one!
In return, you will get a motivated, enthusiastic and passionate quality professional who will put business needs in front of ego. Someone who is a proud, committed and connected member of the global testing community. Someone who will always aim to help your team and company gel, improve and ultimately succeed.
Takeaway #1: Postman isn’t just for ad hoc manual testing anymore
Whilst a lot of people do still use Postman for ad hoc/exploratory testing – and as Amber Race’s seminal Test Automation University course shows, it is brilliant for that – its now clear that automating API’s isn’t seen as an edge case or extreme thing anymore. Among all respondents, 11% of time was spent on automation, but amongst Quality Engineers it was a whopping 31%. This also adds weight to the assumption that testers are responsible for automated testing in the majority of organisations, something which the other reports (mentioned above) seem to back up.
There is clearly an issue here which is tech-wide, and bigger than one company to fix. But in fairness, I think Postman do a great job at encouraging female voices to be heard, and I look forward to seeing how they seek to chip away at this imbalance in future. (*whispers* It’s actually my next career ambition to present f2f at a non-UK conference, maybe Postman Galaxy would be a good way to pop that particular cherry? 🧐#justPuttinThatOutToTheUniverse)
Takeaway #3: Remote Working Isn’t Going Anywhere
This is one of those responses that asks more questions than it answers – I’m intrigued! It’s really interesting to me, because with 26000 replies its probably one of the most accurate bellwethers we have for tech as a whole in relation to this issue – most companies have API’s now, so its safe to assume the companies we work for fall into these categories.
I guess I would have liked to reverse the question to find out if the respondents expected to go into the office every day or at least one or more days per week (as opposed to working from home during that time). There is a big difference between being fully remote and going into the office 4 out of 5 days. It wasn’t the focus of the survey, but I’d also love to know how keen the respondents were to go into the office/work from home – my personal experience is that the younger (and often more inexperienced) folks prefer the occasional office day as its easier for them to pick up things, but its a jump to assume that’s what these Gen Z-ers thought.
I’d recommend taking a squiz through the survey yourself – it is super easy to absorb (props to whoever put those graphics together). Its pretty clear that API’s aren’t going anywhere, are truly a global thing, and that Postman is by far the most popular tool in the market.
According to the recent Mabl state of devOps report, Selenium is the tool of choice for the overwhelming majority of survey respondents using a functional testing tool:-
If you already have Selenium and are wondering how easy it is to upgrade – the answer is, pretty easy really. Don’t be scared of it. It makes sure you’re using the latest code, plus there are a bunch of cool new features in this version for you to try, so upgrading makes sense.
That being said, I wanted to point out a few things that caught me out while attempting to upgrade from Java Selenium 3.1.14 to 4.0 today.
Where are the best instructions on how to upgrade?
One thing that perhaps is obvious to people who play with this stuff all day but wasn’t to me, was the missing reference to pom.xml. Perhaps because other setups use a different filename to hold their Selenium dependencies the articles weren’t explicit, but as a Maven user, in order to upgrade to Selenium 4.0 you need to go to the pom.xml and find the Selenium Java dependency and update the version like this:-
After you save this file, you may see some errors. These are visible in Eclipse as problems, or will appear if you run “mvn clean compile” from cmd line from the same folder as your pom.xml.
The selenium instructions include some more detail on this if you get stuck, but my errors were all to do with Desired Capabilities. From what I understand, this is essentially deprecated in Selenium 4, because it isn’t W3C compliant.
To fix this, we need to use browser specific Options instead.
I had to replace all instances in my code that referred to the previous DesiredCapabilities. Once this happened and I saved the file, everything went red. 🤯🤯🤯
I panicked. I thought I’d broken EVERYTHING. I sought advice from a more experienced automation guru than me at this point, and the fix was simple.
To fix this, you simply needed to run a command to update the Maven Project. In Eclipse, the keyboard shortcut for this is Alt+F5 (although I’m guessing the cmd line “mvn clean compile” does the same thing.)
Hurrah! That was all it took! Selenium 4.0 is now enabled 😊.
I’m sure these instructions won’t be applicable to everyone, but if they have helped you at all then that’s cool.