Tim Velasquez, Werner Enterprises

Thank you for tuning in to today’s full episode of the Breaking Changes podcast. I’m your host and chief evangelist for Postman, Kin Lane. With Breaking Changes, we explore specific topics from the world of APIs, but through the lens of business and engineering leadership. Joining me today, we have Tim Velasquez, software QA manager at Werner Enterprises. Tim completely blew my mind when it comes to the role that QA, or quality assurance, plays as part of the overall API lifecycle, demonstrating how critical they are to moving enterprise organizations forward. Let’s start with the basics: who are you, what do you do?

My name is Tim Velasquez, I’m a software QA manager. I’ve been in QA for about 17 years, since that department space. My overall goal is to provide quality for all of the applications that QA touches that’s delivered to the user, to make sure that there are no issues present, as we all like to call bugs. So I do this over at Werner Enterprises. It’s a logistics company. As you know, if you’re ever on the highway, you see those big blue trucks that say Werner, that’s us. We provide all those goods for you, just to make sure that we can get it delivered. But also, there is demand right now because of our current economy: how can we be able to supply a demand based upon the strain of limitations based on drivers, or based on whatever have you on logistics, or even just the main structure of how the applications apply to the usage to make sure that they can get all the information provided and be able to deliver to who it needs to go to.

Walk me through what QA is like. How does QA in an API world differ from, historically, web applications, mobile applications, stuff like that?

Yeah, that’s a really good question. So technically it’s QA, not Q-A, excuse me.

Yes, no, no, it’s okay.

It’s just part of my job, you know, every day it’s part of making sure that everybody has an understanding of what’s the ask of us and how do we determine what’s being delivered is meeting the business feature. So in a day in the life of a QA, what we do is we want to make sure that, within the user stories that are being presented to us, we are going to go through it, make sure that it meets the definition. Despite the platform, let’s just say this here, we have to be able to understand what’s the ask, how to be able to implement it, and then also are there dependencies that’s being used that we also have to be the first or the second? Because if there’s a second and they’re going ahead of us, we need to stop that to make sure the deliverables. QA is everywhere, not just within the specific standalone component. We’re with scrum masters, we’re with product owners, we’re with architects, we’re with developers, because we have to be able to make sure everybody can be successful once it comes to us, to mitigate any of those defects.

And how does that work with an API? So if you remove those nice front-end UIs that’s been given out to the consumer, just take that away, APIs is really critical. It talks about what is going to be pulled from the database, how’s that going to be manipulated, and then what is the end response, because you have requests and response. And then what that does right there is that we can understand what is the ask, how’s the mapping from the API to the database, what’s the ETL transformation, what’s the business intelligence. APIs are incredibly critical because that’s the bridge from database to the front end, and you can have a phenomenal front end, but if your APIs are not structurally sound, it becomes volatile. And do you understand what I mean by that, Kin?

Yeah, yeah, oh yeah. Chaotic, unknown outcomes in your web, mobile applications, and your integrations.

No, it makes sense. And so one of the great ways that we wanted to utilize Postman here is that Postman, it’s such a robust application that it helps us be able to use it for more than just standardized, this is our testing practices, them, go out, give our definition of done has been met. Let’s expand on that. How can we be able to prevent duplication, and then also how can we prevent scalability exceeding the weight of a user story, but shrinking it down so we can have faster deliverables? Interesting, right? So when the developers make their endpoints and then they structurize how the need is in the ask of a user story, they create that structure, they create how does the endpoint work, parameterizations, client ID, secret ID, the JSON body or XML body, however they’re doing the body. And then what’s the next step there? It’s QA. What we’ve started noticing here in my years of doing API testing is that QA will have to duplicate that process, try to find out what’s the headers, what’s the necessary required fields, what is the endpoint, what’s the method of it, client ID, secret ID, you know, keep listening to what I’m saying here, I’m adding layers, and then that becomes penetration and discovery for us that’s already been created. And so what we did is we made a shared collection using Postman as our library, and we have it to where all those collections are created by the developers, and given that, roles and responsibilities. And then that also helps us to see the discovery of what is their unit testing and their baseline functional testing, which is just negative scenarios. And then for QA, we take that specific endpoint to see, was the test coverage meeting within that user story? We can then inherit that and run with it, and we’d be able to say, okay, I want to create a collection of my APIs that I was going to apply to, let’s say, a customer enrollment, just for the heck of it. So for customer enrollment, we can take all those collections and then put that into its own category. So if I were needed to do a testing, just say this specific feature of core functionality, does it work? We had that test already expanded upon their single endpoint, because it’s already structured and created. Take that to scale, all the different layers I was telling you about earlier, I’ve just drastically reduced it down by a third of the time because it’s already provided.

So it’s a requirement for developers to create the initial collection, so they’re codifying basically the surface area of this API and their understanding of what they built as a collection, and they hand it off to you, but then you might derive specific business scenarios where you iterate on that collection to accommodate specific features and capabilities and business scenarios.

You’re correct. So you talk about test strategies and methodologies. We talked about baseline functional testing and we also talked about unit testing, but for QA we have to expand on that. We have to do end-to-end, we have to do entirely functional testing, as well as, we look at APIs as chain links, right, one for the next. What was the predecessor API done that inherits that certain collection or the certain response headers to apply to the next endpoint, because it might have certain requirements in the background? So what we wanted to do is, how can we make that into a smooth transition, how can we make that strategy from Dev to QA? And so that helped us out being able to come up with that strategy, how to put it into gear and see what’s the next step from that. After we do the end-to-end and the functional testing, what’s the most critical one? And that’s regression.

Yeah, so developers kind of have their blinders on, they don’t have to understand all this context. You’re saying QA’s role is to then bring in all this wider context of how it can actually be applied in a business situation.

Apply it as a way of both positive and negative. We want to find every possible way to break it, that’s our job. Majority over time, break the code. It’s critical because the happy path is already being discovered by the developers. QA’s responsibility is really to act as the competitive company, or in the case of a bad customer, we want to make sure that that bad customer experience doesn’t happen. We also want to make sure that our solid structurization of what’s been implemented into those endpoints to a UI sounds, because if we have a breakage at all in the UI, what’s the next layer of testing? That’s APIs. So we have to give that assurance before we move to production. That’s why API testing is incredibly critical.

So we just made mention about regression testing. Within regression testing, if you have that, it’s going to be deployed, what’s our strategy to make sure that those functionalities being, my, if you make an update, and Kin, you’re going to be the developer at this instance of a description here, you make an update to customer, and then that goes to a customer, you’re being able to be enrolled. Once it comes to me, I want to be able to have it before it goes into my space, my lap. I already have regression that was executed when it got from Dev to QA, and what that does there is that validates for me that all of the core functionality that was not touched was not broken, but everything that’s customer I can now directly work on that, and I can specifically see what you did inside of our shared collection space. So this helps me out with strategy awareness as well as reusability. You’re the one who worked on customer, and you decide to leave, you went to another company, another team, whatever have you. So what happens is, what we’ve seen culturally, is that unfortunately that knowledge goes with that person.

Yeah, so I want to take a moment to think about that. What happens with that knowledge? It’s gone. So how can we be able to capture and keep it? And having those shared workspaces using Postman retains that knowledge for us. But also, here’s the cool thing that we just love about how Postman is utilized here: we can see how it’s being embedded within our company, what are all the endpoints that are prior to it, the before and after, what does that specific endpoint do, by adding those descriptions. So that’s now becoming an overall library at a good health status, and so when the next person comes in, they have that knowledge. We just reduced that time for them to understand what was the ask, what’s the legacy system, how are those APIs being done.

This isn’t normally in the wheelhouse of QA. This is a whole nother dimension of, DevOps wisdom, wisdom building, organizational wisdom, and making sure it’s not blowing out the door every time the windows or the doors open, someone comes in and out.

Agreed. The approach that says DevOps, right, operations and development, operations, those ones that have the need, what is needed for them to be successful inside of the productive world, and then they start creating those epics of those features. If it’s something that’s already been inherited, how can we determine what modifications? So that helps us also be able to project our planning more strategic, more directive, because when you weigh in stories, you have to be able to say what’s the weight that I have to do to make the modifications or add on to it. And let’s put this for both Dev and QA, because they’re both in the same boat in this area here. They have to be able to understand what APIs were used to make sure that, customer, on how it was created, endpoints that are all applied to it, and what is the predecessor endpoint, what’s the next one after that, what’s the structure. That’s the common problem that I see from both sides. And another issue is, when this woman comes into the team for onboarding, we also have to export it out, send it over to them. That makes it truly complex, because you don’t know if that person has the most current version, so then you have a misunderstanding that could occur, and then unfortunately that creates a nuance we want to mitigate. And so having everything as Postman is a library, and I just brought someone on to my team not too long ago, and one of the great things about it is he mentioned, he’s like, can I have the API collection for this specific application? And I was like, well, great news for you, you already have it. When you signed on, we have everything configured for you, you just go download the desktop, go to our domain, everything is there, because our workspace is, how we targeted was not by team structure. I know I’m going a little bit more in depth for you, but let’s stay on track for a moment. So what that did right there is that showed him, I have everything at hand, I don’t have to create my collection, I don’t have to figure out how that’s structurized, it’s already done. I just reduced my scale for onboarding as well.

Yeah, I mean, so single sign-on, they get, they have their employee account, they have their Postman access, it’s all, the topology of Werner is already organized and structured by workspaces, with the artifacts that are needed, the APIs, but also the tests, the collections, the documentation, all the things that go with that, and that whole historical legacy, it’s all right there in the workspace, so they can immediately start searching, go where they need to be to be productive and successful.

It’s true. So let’s talk about this as another way too. If I ever ask you to say, hey, I have another team that’s working on, let’s just say, heck of it, Workday, Workday is going to be applied to what you’re working on by an app because you’ve got to look at your profile information, make sure it’s accurate. Well, in this way, you can use your workspaces again, targeted by application, not by team, because teams come and go. So that makes it easy for you to select that dropdown, find that Workday, go to it, see how the API features are created by collection name, and then you can go inside more deep diving of that specific APIs that you might be dependent on. And so everything is an article for you.

So you’re talking internal and external infrastructure both.

Yeah, so this also helps out with strategy. You have to think of global and also local environment. So remember how we talked about, for unit testing, baseline functional earlier, and we have regression testing and peer functional testing as well. Well, those also require certain parameters based upon those headers, client ID and secret ID, they may not be the same on those environments. And so that’s a great thing of using those different parameters and having them pre-set up based upon that specific application you’re working on, because some are the main, baby, internals, so maybe external, and having that overall architectural and infrastructural ideas of implementing as a housing library. This makes it much more easier for us, for understandability, and that was the main target, make this as a collaboration, not just a single team.

So you’re using the word library pretty regularly here, and it feels like in several forms. And then you mentioned workspace and an organization of your topology by, not by team, you have resource, capability, application. And it sounds like the naming and ordering of your collections and workspaces have some logic applied to it as well.

Yep. So you have to think of, each company has internal and external APIs, especially if they’re using a vendor, and then how do you identify those two? Especially based upon the feature, then that makes it easier for us if we say “customer,” and then if it’s going to be like an internal API, whatever naming convention you provide, I always recommend something pretty small and easy to look at, and then, like an external API, you can say the feature and then “EXT” or whatever have you. But this makes it so this way you know that feature, if it’s internal, and then what is the external, because you can see how those structuralizations are done for those endpoints. And that kind of awareness, just to think about that kind of awareness, makes it to where I have all of the different endpoints and libraries, and when I have to create my testing strategy, I can create my collection and then harvest all those different API endpoints into my own specific collection, how I want to work, and just to validate that the true end-to-end, and that chain is not broken, and then also for me to build out that test scenario, I’ve reduced it, because I don’t have to rebuild those methods, rebuild the endpoint, rebuild anything, it’s already there.

This is a very different painting of the landscape than what I hear from many customers, when it comes, they have a portal somewhere where people publish APIs or docs or anything. This feels more real-time, just keeping the pace at what the actual real-world pace of what’s going on at Werner and the needs, the pace of needs of everyone working across the teams.

It’s true. So let’s talk about this in longevity. Let’s talk about that portal. From what I’ve seen with portals is that it’s a great idea, it starts off strong, it goes for an X amount of time, but then it starts to degrade, then the portal starts to lose the value, and then for me, as a tester, I go in there hoping to find the information I need, especially like what’s the header name, and if it’s not matching what’s current production, I have a mismatch. And is that because the library is not up to date, or is that the business analyst didn’t provide the correct header, or what’s in production does not match the library? So I have so many different possible variables. Do I create a bug on that, do I create a defect, how do I want to structurize that as an issue? But that goes down to integration of that library. So us using Postman, that keeps us viable, keeping that health of it, keeping it up to date, and if there’s any modifications we can be able to see it. But also that comes to accountability. You have your responsibilities to update your description of your Postman’s endpoint, but also QA has their responsibility to discuss the strategy with that. That’s the awareness, right?

So, I’m guessing, from the time an API, I guess in my experience, from the time an API gets developed, code written, and it’s put into production and documentation is published to a portal, any number of things can be lost, or developers, docs folks are busy, they forget things, they leave things out, they don’t have time, or they take shortcuts along the way. So what you’re saying is bringing this closer, because each developer is required to create a collection and hand that off to QA, you’re bringing, I would say, the entire enterprise catalog list of resources and capabilities, the landscape of what an enterprise organization can do, kind of closer to the reality of operations, with QA as the vehicle for that.

Yeah, because QA is the backbone. We have to make sure what’s coming out was part of operations’ ask, as well as the business, as well as the developers building it out. Do they meet? And then we can be able to do the valid as well as the invalid testing with no breakage.

This is interesting because this is like, I’m working on other talks and conversations around APIs as a product, and API product management, and the notion that when you treat it as a product, it’s not about, oh, publicly externally selling it and APIs for sale, it’s, you have a feedback loop associated with it that allows you to iterate on your API. But in many organizations I talked to, QA is this externally facing, this filter, this thing that things go out as they go out the door, and it’s kind of a one-way street. But what you’re describing is you are that feedback loop, you are that in and out, and that critical piece of the roadmap and legacy. Breaking changes, when we get bonus points, we’re saying “breaking changes” here on the show. But it’s like, so you guys are that mechanism, not just that outward-facing quality as it goes out the door.

That’s true. So what we want to do is take you away from an afterthought to the forefront. We want them to be a part of everybody’s definition of done, and help them out and also come up with the strategies, saying, we know that you’re asking for this API, but you have dependencies here based upon this product that your ask can come in, and having them at the forefront. This helps them to advise of any possible concerns. And let’s just say the user story, we don’t want to convert that to a spike to do analysis, we want to prevent spikes being created on any user story, because that’s scale, we want to shrink that as much as possible and prevent spikes being created. And having QA presence at the forefront has really helped out with making sure, if we can get that quality ahead of time instead of at the back end where we will create a mass amount of defects, so that’s what we ended up getting as reward. If we have QA at the front, those defects start to shrink down a little bit more, because the quality work coming through the channel is more at a higher deliverable.

And one of the cool things I’m going to provide here, and shout out to my company, one of the things that we did for an internship program is that I’ll have kids stay with me for six months, teach them different testing strategies. Because, yeah, I’m going to ask you, Kin, and you’re going to tell me a different story or even something similar, but one of the ways that I want to hear from you is your pure thought of, what does QA do, Kin, can you tell me?

Oh, what does QA do? I mean, it ensures the quality of the products and services that this company puts out.

Nice. So what you’ve made for a statement is really true, but it’s at the back end of it. So how can we make it forefront? And so that was where we wanted to teach kids how to become a definition of done, understand what was being asked of that work, be able to take the accountability, say, no, I’ve got a question, I’m concerned, because when future developers come in, they’re a little bit timid to say something that doesn’t make truly sense, so unfortunately that doesn’t meet the quality of code being delivered, so we end up with high defects on them. We don’t want that. So this helps give those kids, within six months with me, to get them ready and up to speed, show them how to do testing on APIs. Because I’ll tell you, the front end’s great, I love it, but APIs are really a great source to validate what’s being done and in between, what’s that bridge from database to UI. And this gives them more awareness on how to meet definition of done for them, and to make sure that their code quality is at a high level with low defects. And once they’re done with me and go to development, we start seeing that their testing strategies are a lot better, we also start seeing how they’re structurizing it using the APIs, and then they’re able to deliver high code compared to someone who’s never gone through a QA internship.

So you’re exposing them to fun API literacy, fundamentals, you’re exposing them, bringing them closer to business needs, objectives, goals, and then putting them into a developer role. Because those are some of the biggest deficiencies you see in development. The old-school notion of, you lock your developers away in a basement, you slide pizza under the door and they do what they do, they don’t have any idea of what’s going on with business, they don’t learn about the latest next thing, JSON APIs or whatever, microservices. And so what you’re talking is, it’s fundamental for them to get this exposure right out of the gate.

It’s true. And what this does here is that gives them the awareness. I keep telling you awareness is critical, collaboration, reducing scale, high-quality code. And what that does is, QA, what we want to do is help bridge those, get you there and get you that awareness, and having that structure, this makes it wonderful. And that makes it to where what you deliver doesn’t have a mathematic defects or brittleness that’s common with what we see within development that’s done in a fast pace. If you can do it right, take the time and structurize it appropriately, work on the iterations, apply that by the platforms, by API, database, then UI, then that makes it, find out how do you want to be able to deliver high code and using it as a central library of how those APIs are structured, and how do you retain that knowledge? That’s incredible, how do you retain it? So that’s why I really express enough about Postman, it does all that for me, and with retaining.

Yeah, that’s an interesting, that retention. I’m a big fan of work at Postman, but the concept of a collection as a unit of value for business, for the enterprise, something that you can describe a single resource or a single capability, or a suite or set of, because workflows and building sequences of API calls, but codifying that as a collection, and then you mentioned putting it into workspaces. But that ability of it to develop wisdom, I can’t come up with a better word right now in the moment, that accumulation of enterprise knowledge, so what’s the relationship with that? That’s the opposite of, or that is legacy, but that’s like a positive notion of the word legacy, rather than what you hear people complaining about, legacy being always a burden and a problem. But you’re talking like this approach, and utilizing Postman and collections and workspaces with this QA approach, is making it a positive version of legacy.

Yes. And so once we have new teams who come up that might have to work on certain products, this allows them to obtain that legacy APIs, how it’s being utilized, how it’s being applied to a team. Because that’s the common thought, like, how can I figure out how the endpoints being done, who has that collection? Hey, Kin, can you send that over to me? Yeah, but I have like last year’s version. Well, who has the latest? Oh, he left. So do you hear the strain? And so that typically is the problem with legacy, is that whoever had that knowledge doesn’t exist there anymore. Provide it into a central source location, this prevents that knowledge from being out the window.

But it’s not just taking that knowledge and putting it in a workspace and retaining it, that knowledge has had that historic relationship with QA, that’s testing the good, the bad, codifying. So your QA in this function is shedding and filtering a lot of what’s known as being the legacy problems, because it’s leaving the errors, the bugs, the deficiencies behind, but then also caring for the knowledge and retaining the knowledge it needs to keep delivering that core service or whatever is being built.

Yeah, you have to think of that as regression. What you’re talking about is regression testing. How can we validate that core functionality did not break with the new feature that was added to it or modified?

Yeah, but you took it with a common theme we see, successful strategies in this last five years, microservices, whatever you call it. People are realizing there’s a very human component aspect of doing these APIs and technology. It’s not just about, hey, we did RESTful API design perfectly, or level four REST, and it dials in. You’re saying, like, we can onboard people immediately, as soon as SSO they have their Postman account, here’s the landscape, and things are organized, you’re immediately productive. You leave, that knowledge isn’t lost, and that’s retained within these workspaces, plus with this QA process evolution marching everything forward. That’s powerful.

Let me expand on that for you real quick before we carry off. The great thing is this: I’m looking for gaps. What are the areas that you may not be very familiar with? So how can I get everybody comfortable in using this single structure and testing tool, as well as their collection library? Training. So what we do is we create training videos, how to use Postman from a very beginner, what does each of these windows do, and then to intermediate, where it says, okay, this is how we can use the authentication, OAuth, or how to use the prerequisites, how to use the test, how to apply that within here, and then go into more advanced, talk about using Newman. And what this helps out is that gives the team all the same baseline and builds them up. So now we have everybody at that new baseline of understandability to use the tool. But to expand on it, now we’re creating smaller, more containerization training video topics. So this way I can harvest based upon your team’s need. Saying, you, if you’re never going to use JMeter, for example, so I’ll never have to worry about trying to hook JMeter using Postman, using Newman. So this will be able to say, all right, I want you to use the fundamentals, I want you to use how is Newman used, how to do the installation, how to use shared collection, branching, and so forth. I’ve now made containerization training videos, and that’s something that we’re working for this next three months. So this way we can help create more of an understandability to use a tool, because the entire time we’ve been talking, Kin, how it’s been beneficial, but how do we get everybody on that same baseline? Because now that’s the roles and responsibilities and expectations.

Yeah, wow, you’re my hero with all that. You’re basically building out, I’m calling it blueprints internally, but we realize creating white papers, large guides worked for an older audience, but I would say it isn’t working as well anymore, and more, I don’t know, snackable video content and modular video content is where we’re switching to right now.

I agree. And if we can make them smaller components, makes it more easier for understanding, because, I mean honestly, watching like an hour of video sometimes just becomes where, way, I just missed this, what happened, where am I? Then you have to go back, try to find it within that whole length, and you, let’s make it more targeted, let’s make it more focused, in fact let’s make it more hyper-focused, so that way it meets the need of the team.

Well, stay tuned, while I put bacon in some of these libraries, these snackable content, into the product, into the workspaces, and then my goal is to make it so you can just maintain your own library of these content and features. We’ll provide the baseline of them, but you can automate and add JMeter in there, and add it for our competitors, and then it’s in line within the workspace as part of the training delivery mechanism. So stay tuned for that.

Yeah, and one of the great things that I like is, when we do automation for API, the complexity of what we’re talking about, creating that collection, having an understanding of those endpoints, putting in, unfortunately even doing API automation, it ends up being taking longer of a skill. Yes, the person can automate, yes, they can do the structuralization, sterilization, destabilization, however have you. But here’s the problem: how do you work those collections that you don’t have awareness to? How do you know what your testing does have the correct coverage needed? So what is a really good way for strategy to me is that we can use both the analytical as well as the engineering aspect of Postman to provide that force to come up with a strategy needed, if we would decide to go into doing API testing in automation fashion. But one of the cool things is that Postman even provides that for us as well.

Yeah, well, that’s, so at some point, maybe not on the podcast, in a different session, Postman has an API, so your workspaces have an API, your collections have an API, and so how do you start automating, configuring, and?

Yeah, yeah.

And so it’s kind of like, you know, like Terraform and Ansible and other things, you see kind of topographical, declarative ways of describing your topology and working with it. But you all have invested all this into your workspace structure. This is your API factory floor, your virtual factory floor that you guys have put all this energy into, and that developer is able to SSO, get their Postman account the first day, and walk into the door of this virtual factory that you’ve all built. Now, once you have workspaces with ops-level collections that can help you automate and configure those workspaces and those collections, and help you see that layer of it, that’s where we see some folks like you that are more further along in their journey getting to.

Yeah. And then, let’s take this into another area, is that one of the strains that I’ve also noticed within UI automation, the most common theme is test data. You’re going to constantly hear that, test data. Yes, there’s other factors too, but let’s focus on this, just the test data, for right now. So one of the cool things that I’ve noticed with using Postman is that I can actually kick off a certain collection to make sure that my automation has test data needed, by using Newman to execute within my pipeline. And I like to call that, create my stage, and then my UI automation that will kick off afterwards based upon the targeting of by tagging. And then what this does, that will guarantee that that automation has test data needed, or the conditions applied to the user. So this way I can guarantee what’s applying to that specific automation will be able to be satisfactory, and ruling out the most common issue, test data.

And then you have a data catalog that is applicable across all of this.

Not all of it. There’s always going to be hiccups with some, based upon if the internal or external, based on who owns the data. But how can we make it to where our data is going to live at that time of automation that can be executed?

Yeah, because nobody likes false positives and false negatives.

Yeah, it’s powerful.

Well, maintaining that catalog of data and then the folks who are injecting it at the pipeline level or the runner level into a collection, and then having a collection strategy and environment strategy, a variable strategy, and a data strategy all coming together at that moment, is where it’s at.

So yeah, that’s going to be our target for this year, that we’d like to get up to, and so we’re making the efforts and coming up with an architectural design, so this way within the pipelines we can have that as a high delivery. Our goal is to try to do whatever we can to make sure that we have the appropriate setup done in that environment for when automation is kicked off.

Yeah, and for any happy or unhappy paths that you may want to take at that point.

Oh yeah, I plan to break it. It’s technically, I mean, that’s the job requirement. Our job is 70% of the time you need to break it, QA must break it, and then we’ll validate everything works on the happy path. And that’s the test strategy that should always be.

Do you, I mean, a developer creates something, and I guess they have a limited scope of what they’re building it for, they may not have the full legacy or the full scope of that service, but do you guys make sure that, you poke at that to make sure it’s honest and true, like, can you add more parameters, can you add headers, can you do things? So I’m guessing you guys really stretch it, push the boundaries.

We do. And I’m also noticing, within the culture within QA, is that there is actually more of a precedence to test on the APIs more than just on the UI right now. We’re starting to see that within the structurizations, just to make sure that the mapping is done appropriately and also the APIs are meeting all the conditions that’s asked within that feature. Because when a UI does break, what’s our next layer that we go to test it? We go to the APIs, we validate everything’s there. So there might be even a structural difference for our own testing strategy, to go with APIs as well right now. Let’s create that collection, was created by application, and then break those down into what are the features we meet, that application. Because right there, that library, that helps create your stage of your testing. You can do a lot just by knowing, especially if you have everything in front of you, and testing everything those apps are capable of doing, and the things those apps aren’t capable of doing.

You’ve got the most, limitations, honest view of the landscape.

Yeah, the limitations, yeah. And what you talk about is having those limitations and understanding where are the areas that we can even focus at, that gives us the gap analysis.

Yeah, I guess it’s the risk assessment. One of my schticks for APIs, I go with a lot of enterprise organizations, go to talk to them about consulting, helping them, and they’ll be like, well, we don’t have any public APIs, we just have microservices, internal, a lot of legacy stuff. And before I go in, I would download their mobile app or go to their web app and then run it through Postman Interceptor, Postman proxy, generate a collection, document it, and then go hit it, and go, well, here’s all your APIs. And so many of them just have a blind spot behind their mobile apps. They see the mobile app, they see the web app, and they don’t see those APIs as being public API. So you’re really just pulling back the stage curtain, letting all the lighting in and going, all right, here’s all of the resources at this layer.

Yeah, so that comes down to understandability too. A lot of times that we’ve seen people, is that they’re more comfortable with like a front-end system, and how can we make them say, it’s fine, let me show you how to create Postman’s collections based upon the specific workspace to do your testing needs? But that’s also that training that we talked about. You’ve got to create that stage, you’ve got to talk about roles and responsibilities for Dev, QA, the expectations within the user stories of the ask, and also having internal training, reviewing what are areas that you can do to help make sure everybody’s on the same level, that baseline. That helps out so much, because you take that human component of understandability, and everybody’s at that same level. So when you get people to learn how to use APIs, like what you’re just talking about, when you provide that collection, then they’ll be like, I know what to do. And it’s okay to be in discomfort, because technically we live in that every day in technology, we always have to be at a discomfort and find that serenity and be able to find what is the ask, how to make it neat. But get that understandability, and also work as a collaborative, that changes your view entirely, not just as a single person, not just as a team person, it’s also as an enterprise level. This is the expectations and this is how we do it well.

Impressive. I mean, I get a lot of customers who are responding and just tell us how to do APIs so we can check the box and be done, because we’re being asked to do APIs. And I’m like, wait, that’s not how it works, you’re always going to be doing APIs. But because of PTSD, the great vulnerability of 2007, the great breaking change of 2011, 12, 13, 14, they have this PTSD and they just don’t want to do APIs, they just want stability.

It’s true. And then we know that as their goal, right, stability. But what are the stepping stones to get there from where they’re at? That’s the roadmap, and then we just talked about that the entire time we’ve been on this call, which is understandability, accountability, training internally, how to validate the ask within the user stories. It always seems to be falling back, right, awareness. You keep using the word awareness.

Yeah, you know how important that is, right? And so what that does, everybody has that fear, and I get it, I totally do, I get it, because I had it as well. But keeping the knowledge, getting everybody at the same level, having work in a collaboration for Dev and QA, that creates such a unique culture, and also we start seeing that expanding with the scrum masters, the product owners, they all have more awareness of what’s happening. And then we talk about UI as a safe net for everybody to use, because they have something to see. Postman created that indirectly, you technically created that, those workspaces targeted by application, that gives me everything I need to see, that helps me out. Plus, how do we categorize it, because of our roles and responsibility of creating those collections for internal, external, I can understand that within the feature. This gives the awareness.

Yeah, well, it reflects what we’re seeing across the board. I have a large retailer, US-based retailer, that had a QA team, they were building collections, and they started building collections for analysts, and the word got out, demand grew, now the team’s dedicated, all they do is build collections and workspaces for analysts, and they come in, here’s the URL, land on it, or the Run in Postman buttons embedded somewhere that they see, they click on it, and all they know is they click the blue button and then download the data set, and that’s all they do with Postman. And another company is like a shipping company, they do the same with their sales department, because they can provide their sales teams with the numbers they need ahead of the dashboards and the other interfaces that their sales team depends on.

Yeah, that’s a really good strategy too. And one of the great things that we hear is that it’s being utilized, structured, and collaborative, and giving the business analysts everything that they need to then provide better user stories, that prevents spikes, no longer have an afterthought, there is everything from the stage forefront. Wow, just because of awareness.

Yeah, so it’s not just QA, not just Dev. Well, this stuff’s hard to see, I mean, it’s hard to see. Everyone wants a digital transformation, but digital is difficult to see and do. And that’s why you keep using awareness, because you can’t achieve awareness unless you can see, find, discover, and get what you need. It’s really important.

But really, the main baseline of everything that we talked about, it’s that collaboration. I will never stop saying it to you, because I have seen such an amazing culture here at my company because of this, and I only think we just scratched the surface. I can’t wait, if we can just do another podcast in the next six months to tell you the differences from then to now.

All right, I’m going to put it in the schedule, let’s do it.

Sounds great.

All right, I really appreciate this time, I know that you are a busy guy, but thank you so much for this. I mean, thanks for being here, thanks for doing this, but you got me thinking in some different ways just as part of this conversation, so I definitely want to talk some more. Yeah, let me just process and simmer, and we can talk some more.

Thanks again to Tim for stopping by. You can find more about Werner Enterprises at werner.com, and you can find Tim on LinkedIn. You can also subscribe to the Breaking Changes podcast at postman.com/events/breaking-changes. I’m your host, Kin Lane, and until next time, cheers.