In this special summer edition of PLATO Panel Talks, host Mike Hrycyk invites members of the PLATO community to share the automation, testing, and AI tools making the biggest impact in their day-to-day work. From established favourites to emerging AI-powered solutions, this episode features four experts showcasing what’s currently in their toolbox:
- Arash Taheri (Central 1) explains how Postman has evolved beyond API testing into a platform for collaboration, automation, documentation, and quality engineering.
- DJ Sicoli-Khull (PLATO) highlights the value of developer-focused quality tools including Ruff, Black, and SonarQube, and how static analysis helps teams improve code quality before issues reach production.
- Karthi Vasudevan (PLATO) explores Jira Rovo, Atlassian’s AI-powered assistant, and shares practical ways testers and test managers can use it for defect triage, coverage analysis, onboarding, and daily QA visibility.
- Bing Wu (TransLink) discusses an internally developed AI-assisted test case generator and offers a thoughtful perspective on how organizations can adopt AI responsibly, sustainably, and with human judgment at the centre.
Whether you’re looking to strengthen your automation strategy, streamline testing workflows, or better understand how AI is reshaping QA, this episode is packed with ideas to help you build a smarter testing toolbox.
Can’t use the player?
Listen to this episode on Spotify (opens in a new tab)
This option provides a more reliable playback experience on mobile devices.
Episode Transcript
Mike Hrycyk (00:00):
Welcome back to PLATO Panel Talks. I’m your host, Mike Hrycyk. For this episode, it’s summer, so we thought we’d do something just a little bit fun and also a little bit helpful.
One of the truths about QA is that we’re always looking for, creating, or modifying the standard usage flows of existing tools for our own particular uses to make our lives and the lives of our teams a little easier. One of the things that we should try to do as we find these nifty tools and workarounds is to share them with our testing communities. If it makes my life easier, why wouldn’t I try to have it make your life easier too?
So for this podcast, what we did is put the call out to some of the friends of PLATO Panel Talks and ask people to come out and tell us about their new workaround. A collection of tools that our PLATO community thinks are worth adding to your testing and development toolkit.
We’ve got four guests joining us, each with a favorite tool to share. And with that, I’m going to hand things over to our first guest, Arash Taheri, who you may remember from our episode this spring on DevOps, Automation, and AI. That makes him the perfect person to kick things off by telling us about Postman.
Arash Taheri (01:05):
Hello everyone. My name is Arash Taheri. I am the Director of Quality Assurance and Quality Engineering at Central One. So, at Central One, my responsibility is to lead teams that are responsible for delivering high quality and high reliability across critical financial systems and digital services. So, pretty much all the product and services that are shipped to production, all of them come to my team as the final gatekeeper to assess the quality.
Now, for today’s discussion, if I had to choose one testing tool that has had the biggest impact on my team, it would be Postman. Obviously, all QA professionals use a variety of tools depending on the organization and industry they work in, but Postman, I find, is such a critical tool to enable a lot of activities. Now, most people know Postman as an API testing tool, but I think that’s kind of underselling it just because, in my opinion, Postman is a platform that empowers and enables faster development, higher quality, and better collaboration across teams.
(02:08):
Now, if I were to talk about some of the main benefits that I have personally experienced in my teams in different organizations that I’ve been a part of, first and almost the most important one is the fact that it improves speed. So teams can quickly test APIs without writing large amounts of code. What might take hours using custom scripts can often be done in minutes when you’re using Postman. As a matter of fact, teams can start testing the APIs without having the need for a front-end application because, obviously, front-end takes much longer. It involves UX design teams as well as web development teams, app development teams as well. Whereas if you’re just testing APIs, it doesn’t require any of that. You can start testing your APIs purely using Postman.
(02:53):
So, the second benefit is that it enables shift left testing. Obviously, this is no longer a buzzword when we say shift left. Teams across key organizations are very familiar with it, but what I mean by shift left testing using Postman is that testing starts earlier in the software development lifecycle, which kind of allows issues to be found when they’re cheaper and faster to fix. For example, in my team, when we deal with both front-end and back-end applications, as soon as an API is implemented and the code is merged into the main branch, it comes to deploy to the QA environment. My team can jump on it and start quickly testing it. It shifts the testing activities earlier in the game, which helps teams to find issues faster, reduce costs, and improve efficiency.
(03:36):
Third reason is that it supports, obviously, automation. What I mean by that is that people who know Postman, people who are familiar with Postman, said they are aware of the Postman collections, which means that a collection of Postman tests can be integrated directly into the CI/CD pipeline and empowers every development life cycle to be automatically validated, which basically turns into reducing risk and increasing confidence.
(04:01):
Another reason that actually I have been very much appreciative of Postman is it kind of brings a higher level of collaboration across various stakeholders. So, what I mean by that is think about the technology team or scrum team. It involves developers, QAs, BAs (business analysts), product owners, and front-end masters. They can all kind of work together from the same API collections and documentation. Everyone basically has a shared understanding of how a service should behave. So, it’s not only a test tool, but also a collaboration tool. An added benefit is that it straightens the quality and reliability. Obviously, teams test positive scenarios, negative scenarios, and error handling scenarios. It can also take care of security validations, performance checks, and data integrity, which in turn assists the technology team and QA teams to uncover issues before customers actually experience them.
(04:51):
The last benefit that I can talk about – obviously, this doesn’t summarize all of it if it’s Postman, but the last one is you can look at it as living documentation. I’m sure a lot of people across technology organizations share a common challenge, which is keeping documentation current, especially in Agile. Do you follow the Agile Manifesto? It kind of relies more on documentation and more on working software. Again, one big challenge across technology organizations is to keep up with the documentation. But with Postman, the API definition, we can talk about sample requests, automated tests, and expected responses – all of them can live together in one single place. That kind of makes onboarding new team members significantly easier.
(05:35):
So again, why should people be interested in Postman? Because it doesn’t matter what kind of application you build– front-end, back-end– APIs are everywhere when you think about it. Regardless of what your product is. It could be a web application which involves a web interface, but it requires an API in the backend. If it’s a mobile app, regardless of being an iOS or Android app, it requires an API layer to drive all the functionalities.
So, APIs are everywhere. And as a matter of fact, if you’re building banking applications in mobile apps, cloud applications, AI solutions, e-commerce systems, APIs are kind of the backbone that connect everything together. And what Postman does is that it gives the organizations a way to deliver software faster, increase the quality or improve the quality, automate test scenarios, and document services. And when you think about it, it kind of fosters stronger collaboration across the various stakeholders in every technology team. Personally, for me, Postman, when I think about it, isn’t just a testing tool. I can think about it as a quality accelerator, a collaboration platform, or an enabler of modern software delivery.
Mike Hrycyk (06:44):
Thanks, Arash. That was great. You know, Postman’s been around for a while, but I like that they keep changing and evolving to continue being a great tool. So, having you talk about it today was really cool.
Our next guest might also sound familiar. DJ was also a panelist on that DevOps, Automation, and AI episode, and now he’s here to add another tool to our collection.
DJ Sicoli-Khull (07:06):
Hi, I’m DJ Sicoli-Khull. I am a Senior Automation Engineer at PLATO. Today, I wouldn’t mind talking about some of my favourite automation tools, dealing with one aspect of development linting where a lot of folks don’t tend to focus on too much, but I find it adds a great impact to the whole automation lifecycle and development lifecycle. One of a couple of tools I like to talk about is Ruff. It’s a newer tool that I found out about. It’s a Python linter that checks your code for issues before it even reaches code review. So, it catches things like unused imports, unreachable code, variables that aren’t being used, and even suggests modern Python improvements. The biggest advantage to this is speed. It’s incredibly fast, so developers are much more likely to run it regularly. Also has an auto-fix feature, which can save time by correcting many issues automatically. For example, if you left an import statement in a code that you forgot about, you could use ruff–fix. It goes ahead and automatically changes it for you.
(08:03):
The next tool is Black, an automatic code formatter. There’s going to be a lot of discussions on the tabs versus spacing. This kind of eliminates that. It automatically formats your code, line length, spacing, indentation, all during code reviews. It just creates a standard across the team. Black formats everything consistently with a single command. Everyone’s code looks the same, which makes pull requests easier to read.
(08:28):
So, the third tool I like to talk about is SonarQube. This tool gets the most value. There is a paid version of this tool and a free version. You could do it on-prem or in the cloud as well. Most projects I’ve worked on, it was on-prem. The reason why I like this tool, unlike Ruff and Black, is that it focuses on a deeper static analysis of the code. It identifies code smells, duplicate code, potential bugs, security vulnerabilities, and measures things like code coverage and tech debt. So, once it runs its analysis, it’ll say, like, “Oh, for a tech debt, it should take you one day to resolve it.” On the automation framework side of things, this is valuable because they tend to grow over time, and SonarQube helps identify when helper methods are becoming too complex. For example, duplicate Selenium or API code should be refactored or when quality starts to decline. Instead of waiting for problems to surface months later, teams can address them earlier.
Mike Hrycyk (09:20):
So, I’ve got familiarity with SonarQube. Are any of these three tools making claims that they’re leveraging AI as part of their delivery?
DJ Sicoli-Khull (09:29):
I haven’t really looked too much up to date with the growing focus on AI. I know in the past, SonarQube has been focused around the rule sets that have been defined in it, and that’s kind of the structure it follows. So, a team can configure the rule sets and all that. I’m sure there’s possibilities of integrating AI into it, but I just haven’t seen any or read anywhere where SonarQube has been tending to go towards AI use. I know Rough and Black; it’s a simple Python package that they use, and it’s lightweight and quick. So, I don’t think there’s integration there in terms of AI.
Mike Hrycyk (10:07):
So, the second question, DJ, is when we did SonarQube – and this is years ago, maybe it was 10 years ago. When we first did it, we did a pretty casual set of criteria that we were going to track because that’s a variable that you get to set in SonarQube. And we came back with 136,000 hits that were problematic. And so, is that something you’re seeing? Or how do you deal with that?
DJ Sicoli-Khull (10:29):
It can be overwhelming. Typically in the past, what helps is setting coding standards way before you even push towards using it. For example, I ensure we use SOLID principles, and we use clean code methodologies. In our development lifecycle, if you’re in Python, you can use PEP 8 as a coding structure. In a simple sense, like you mentioned there, if it’s tens of thousands of smells, it can be overwhelming at first, but if you break it off into chunks – so on some of the projects I’ve done in the past, we take that and use it as. So if a developer goes in and makes a change to the file that has 30 to 40 code smells, if they’re in there and touch it, then it makes more sense for them to just go ahead and refactor that code since they’re in there and kind of start that process. So, eventually over time you will chip away at it, but we also look at the severity of the issues it finds, and the highest ones get dealt with first. You’ll still have some low-hanging ones, which over time will get picked up.
Mike Hrycyk (11:28):
Thanks, DJ. I don’t think we pay enough attention as QAs to static analysis tools. Better code produces better code. So, I think it’s great that you talked about it. Next up, we’re welcoming a first-time contributor to the podcast. Karthi is here to introduce us to a tool every tester is familiar with and how an AI integration is taking things up a notch. I’m pretty sure that this will be in everyone’s toolbox before very long.
Karthi Vasudevan (11:53):
Hi, I’m Karthi, working for PLATO as a Senior Consultant. Today I’m going to talk about my favourite AI tool for testing that is available in the market right now, which is Jira’s Rovo. Have you ever noticed the Ask Rovo button at the top right corner in Jira? It is that one.
So, let me paint a picture for you. Imagine your next standup: you haven’t opened a single report, but you already know every backlog to test, every new critical bug, every ticket that’s gone stale. As a test manager, that’s not a dashboard you buy. It’s a Rovo agent you build in an afternoon with no code. And here’s the difference that matters. A dashboard shows you the numbers. This agent tells you what they mean and hands you the next action. Rovo’s probably already in your toolbox if you’re on a paid Jira Cloud plan.
(12:41):
So, what I would do with it as a test manager? The first thing I will do is the daily QA brief. Build a custom agent in Rovo Studio, no code, that surfaces blocked tests, new critical bugs and stale tickets every morning. This is the one that changes your team. Second, sprint and coverage visibility. Ask Rovo Chat to summarize test execution status or pull open defects tied to a sprint. It reasons across Jira and Confluence, so you stop stitching reports by hand. Third, do a miniature defect triage. Ask it to find related or duplicate issues before your team logs a new one. It cuts backlog noise fast. Fourth, requirement-to-test traceability. Point it at a Confluence requirements page and ask what’s covered and what’s missing. A solid first-pass gap check before planning. Fifth, onboarding. Surprised? Yeah, it helps with onboarding. A new tester joins. Rovo explains your project’s jargon and history. This reduces ramp time a lot.
One honest caveat. Rovo orchestrates and surfaces. It won’t design your test for you. You need to have a human on the test strategy.
(13:55):
So, how does a chatbot know your blocked test and your stale tickets? It’s because of the Teamwork Graph, Atlassian’s data intelligence layer. It is a living map of how your org actually works. It doesn’t just store your tickets and pages as separate records. It stores the relationship between them. It knows Bug X relates to requirement Z, which relates to Roadmap B, which is owned by Person Y. Billions of those objects and relationships across Jira, Confluence, Jira Service Management, Bitbucket, and 75+ tools. Everything Rovo does is grounded in that graph. Atlassian says that grounding made answers 44% more accurate using nearly half the tokens. It maps context before the AI reasons. So, Rovo shows up like a teammate, not a cold chatbot. And data keeps its original permission, so people see only what they are already allowed to do.
(14:58):
On top of the graph, set four things. Search, chat, agents, and studio. Search is free. Chat is also free. Agent and studio are going to cost you credits. And the newest piece, the fifth one, is a Rovo MCP server. So, you can pipe that graph context into your own stack if you’re building any tools. So, lead with the graph, four capabilities on top. And for us, it’s a visibility and triage layer, not a test design brand. Turn it on, build a daily brief agent this week and see what sticks.
Mike Hrycyk (15:31):
That’s great, Karthi. Two things. So, number one, I would never have thought about using Rovo for aiding and onboarding. Having the ability to grab your jargon from your project and give that to me. That’s amazing. I love that. But one question I’m going to ask: the thing that flagged for me in fear is that we put a lot of client-specific information or your organization-specific information into your test cases and stuff. Rovo is learning from your test assets. Does this mean we should be afraid about the data that we have in our test cases that Rovo might use, and it’s going wider to a wider audience?
Karthi Vasudevan (16:09):
No, it is secure. It is all mapped based on the organization structure, how the JIRA administrator has done the setup, and it allows only people to see the information they’re allowed to see. Say you are a test lead with restricted access; then you’ll be able to see details only of those things. You’ll not be able to see what a director is saying. So, the visibility differs over there.
Mike Hrycyk (16:34):
Thanks, Karthi. That was great. I really like thinking about how AI integrates into the tools we already have and makes them better. And last but not least, we’ve got something you won’t find on the shelf at your local software store. I’m excited to hear how Bing is bringing AI into his own toolbox and how his knowledge can benefit all of our own automation toolboxes.
Bing Wu (16:54):
Hello everyone. My name’s Bing. My name is easy to remember. Bing.com, the search engine. I’m a software QA Manager at TransLink in Vancouver. I have spent nearly 28 years in software development, testing, leading QA teams across different industries, including semiconductors, telecommunications, enterprise software development, gaming software, and, right now, public transportation as well. So, today, one of our biggest questions where I spend my time recently is about what kind of a tool we’re supposed to use in the AI age. So, AI’s impact is already with us, but how will AI reshape our QA teams? How we’re going to work is still a question mark.
(17:35):
When people ask me about what is my favourite testing tool is today, they usually expect me to probably name a very specific product, kind of a QA tool. And that is kind of a very difficult choice because there are so many impressive AI-assisted testing tools already on the market. Some of them, they say you can create all the test code without writing a single line of script. Some will say we can offer intelligent test scenario discovery and self-healing automation, cross-browser coverage, and even generate the test directly from the requirements. Yeah, there are so many awesome tools outside there already.
(18:12):
So, those AI capabilities and the features are very exciting. But for me, I will say the most interesting question is not just to say which AI testing tool is my favourite. I will say the more important question for me is what is the new opportunities that AI and AI tools create for QA? And how should it change the way we work in the near future?
(18:37):
In this case, I will say my favourite testing tool today is our internally developed AI-assisted test case generator. We created it as a pilot, not because we believe we need to build everything ourselves, but more because we want to learn, we want to explore the AI and its capabilities. We want to have a better understanding and explore, as well, how AI can support our QA activities. And again, practical experience before we decide whether a commercial solution product might be the best choice for us or any other product is going to be our favourite one.
(19:13):
The test case generator is just, I will say, an entry-level starting point. What really matters is how it fits into the way we deliver quality today. And when I evaluate our AI testing solution with its functionality and features, I always ask a few questions to my team and to myself. Does it fit into our existing QA workflow and our software application delivery process? Does it keep human judgment and accountability always in control? Can it securely use our approved knowledge, our QA standards and templates all the time? Does it deliver measurable improvements in quality and efficiency? And does it help us to build a scalable and sustainable QA operating model? I will say the last one is always the most important one as well.
(20:04):
All those questions are important because a successful AI solution is about much more than just the requests that go in and the outcome – just the display in front of us, which is the large language model. They need a lot of other feature functionality and capability around it to support it and make it successful, including the trusted knowledge sources, integration with our existing tools and the process we are using, the governance model, the security controls, measurements, and very clear human accountability. So, this tool, the AI-assisted Test Case Generator, has become a practical way for us to explore those areas and those features and the capability. The objective isn’t simply to generate a test case faster. It’s to learn how AI can support quality in our real life, in our real enterprise environment, to understand what change is needed for our process and our skills and the way of our working in the near future.
(21:06):
So, on the other way, I will say I don’t believe organizations should really adopt AI simply because everyone else is already doing it or because they are afraid of falling behind. As quality leaders, we need to understand our workflow, identify the capabilities we want to improve, and find our pain point and adopt AI in a way that is safe, measurable, and sustainable. Again, I will say when I think about what is my favourite tool, the testing tool today, I don’t just think about the product itself. I think about the new opportunities behind it. The tools just our starting point. The AI-assisted QA operating model, I will say, is my destination. AI can generate, recommend, and assist us, but QA professionals must always have a chance to review, decide, and remain accountable for quality.
Mike Hrycyk (22:00):
Thanks, Bing. That was great. I really appreciate that you’re giving us some guide rails and ideas about how you can add AI to your toolbox and use it yourself.
From API testing and code quality to developer tooling and AI, today’s guests have given us a pretty good reminder that there’s no one-size-fits-all approach to automation. Sometimes the right tool is something you’ve been using for years, tweaked to fit the new normal; sometimes it’s something brand new; and sometimes it’s something you build yourself because nothing else fits as well. Thanks to Arash, DJ, Karthi, and Bing for sharing what’s in their toolboxes with us. Thank you, our listeners, for tuning in.
And if you’ve got an automation tool you can’t live without, let us know. Maybe it’ll make its way into our next toolbox episode. You can find us @PLATOTesting on LinkedIn or Facebook and on our website. You can find links to all of our social media in the episode description. If you’re enjoying listening to our technology-focused podcast, we’d love it if you could rate and review PLATO Panel Talks on whatever platform you’re listening on.