Implementing Postman in API monitoring
At Nmbrs, every year we set a general theme for what we want that year to be about; and this year, as our CEO says, ‘it’s quality time, baby’! Everything we do this year has to take into account quality; we’re really delving into the way we work, our technology and our processes to ensure that it’s of the utmost quality. In turn, we know we’ll have happy employees and customers.
One such project that shines a light on how we’ve focused more on quality is in monitoring and testing our API. As our API is used by a lot of customers and integration partners, we want to make sure it’s working properly and equip ourselves with the right tools to monitor performance.
My role in implementing Postman
When I started at Nmbrs back in September 2018 as a QA, I already harboured an ambition to become a PO. I expressed this to my coach and when the opportunity opened up they offered me the position to become a PO for a different squad than the one I was in. Why did I want the job? I really wanted to be part of the decision-making process, and create more of an impact from what I was doing. Luckily, at Nmbrs, the team is always open to providing opportunities for its employees.
When I joined the new squad, the testing of the API was carried out locally — it was basic, manual and outdated. Our testing was not organised or structured, and this meant that after the updates, we didn’t know if the API integration was working effectively.
We were also migrating from our on-premise servers to Microsoft Azure, and this shift towards the cloud created a lot of instability on APIs — this can have an impact on any company, including ours — so we needed to fix it immediately.
After carrying out some research, I realised that Postman could save us time and also help us to reduce the number of performance issues we had during the migration process. In addition, we would more easily be able to share the tests in real-time, so that our colleagues could understand if there had been any issues, and what these were.
The process of implementing Postman
After evaluating two of the most promising API testing tools, I took the initiative to trial Postman. This required me to download Postman and add some API requests into the platform. The initial implementation wasn’t difficult; since we have a SOAP API, I configured it accordingly and started to create collections.
I then shared it with the team and we decided that this was the tool we were looking for. This was because we were able to share all of the changes made to the tests in real-time and monitor the results consistently.
When requesting the license to Nmbrs, they were very open and keen to support the team in the decision to go with Postman. It was great to come up with a better solution and have the company backing up the team’s decision.
We took around two months to add all of the critical tests we wanted and configure the variables in a way which would enable us to make the tests generic. That means we can execute them pointing to our test, sandbox and live environments.
Since the implementation, we have a lot more confidence that the API was really working as it should. Keeping up-to-date is now a lot easier too; every time we do any kind of maintenance work in any request — for example, if there’s a bug — we would add it to the Postman platform.
We’ll continue increasing the coverage of Postman so that we have even more confidence in the API than we do today.
Lessons learned
Both testing and monitoring are crucial in being able to make our API reliable. In turn, our service works for our customers who remain satisfied and loyal to our company. It means that we know if something is going wrong and can act far more swiftly. If we have instability on one of the calls, we keep a very close eye on it and create a lot of alerts so that if anything unexpected happens we can act on it before the customer even complains. In other words, by monitoring our API with Postman, our product and customer experience have improved significantly.
We’ve also learnt that getting a fresh pair of eyes on a situation can be invaluable. As the developers were taking care of the API monitoring prior to me joining the squad, I helped to provide a new perspective and to take a step back and think about ways that our API integration could be improved through monitoring and testing. Often, teams can get accustomed to working in a certain way, by exchanging new ideas and gaining input from people with different skillsets, squads can actually improve the way they operate without a great deal of effort.
Nmbrs has been key to this; I’ve been able to switch from a job where I felt like I had a lot of repetitive tasks, to one where I can progress in my career, with a range of different work and a lot of new challenges. In addition, I’ve welcomed the ability to mix with various different colleagues on this. Crucially, as I had envisaged from the get-go, being a PO has enabled me to make my mark at the company, and I’ve been able to work on a project that is providing value throughout the business.
What’s more, we’ve stuck to our theme of focusing on quality; by implementing Postman for API monitoring, we’re able to continue to provide a quality service.
If you want to know more about us, follow us on LinkedIn, Twitter, Facebook and Instagram! You can also check open vacancies here.
About Gabriela
As Product Owner of Squad Integrations at Nmbrs, Gabriela makes sure that the integration partners can easily connect via the Nmbrs Public API and guarantees a seamless experience for users. Originally from Brazil and living in The Netherlands for the past two years, Gabriela has a computer science background and previous work experience as a QA Engineer.
