Episode Description
Welcome to another episode of Automation Explanation, an Agile Thought Podcast, where you will learn about quality through automated testing and its place in modern software development.
This week, your hosts, Antwan Maddox and Greg Burdick are talking about the crucial value of Automation Strategy; they dive deep into its history and origins, as well as explain its role in regard to Testing and the significance of the whole Development Team to be included in the process. Antwan and Greg also discuss the types of testing approaches that are used to leverage Automation and the patterns to avoid.
Key Takeaways
Test Automation Engineers or Quality Automation Engineers?
In order to be in alignment with ISTQB® Certification, the formerly called Quality Automation Engineers are now referred to as Test Automation Engineers.
It’s a unification of terminology.
Why is Automation Strategy important?
“If you fail to plan, you are planning to fail.” Benjamin Franklin
A plan of execution is needed to assure effectiveness and efficiency.
The history of Automation Strategy, where does it come from?
It comes from experience in the past.
As Automation progressed, some of the technology around Automation had to change.
The Automation Strategy is owned by the entire Development Team.
What is the significance of Quality?
Automation Strategy explained:
The Automation Strategy defines the who, what, when, where, and how of Test Automation.
It is a plan that is agreed upon and understood by the entire Development Team for creating and maintaining Automation Test to help ensure higher ROI, increase coverage and availability, and faster time to market, in a way that is repeatable.
Collaboration and response to change are two key pillars of Agile that sustain the Automation Strategy.
Automation was not designed to catch bugs; it happens to catch them since it is set in a repeatable path.
What should be included in Automation Strategy?
First, you need to understand your why, what is your goal? That will help you establish the technique, the tools, and the process in building Automation, and the technology that is going to be used to support those goals, as well as help you determine who are the members that need to be on the Team to support that Automation.
It will help you define what additional technologies are going to be needed and the environments you are planning to run against.
What types of testing approaches are used to leverage Automation?
The Shifting Left approach is a great way to Test Application components.
Test Automation solutions need to be embedded in the application.
It is a way of preventing risk quickly.
Model-Based Testing.
Contract Testing.
The Team is in alignment with the continuous Test Maturity Model, it is a whole team approach.
Models for success: Which organizations are modeling the right way of doing Automation Tests for success?
Google understands Automation.
It is only possible when the whole organization has been educated on Automation, they are all supportive, and know their roles in regard to Automation.
Agile does not mean to move fast, that is why Quality is important.
Patterns to avoid.
It is hard to bridge Manual Testing and Automation; a really mature team approach is needed.
Quality Engineers must focus over the long haul on the prevention of production-based risk; features that are being delivered must be tested to make sure they work.
Transcript [This transcript is auto-generated and may not be completely accurate in its depiction of the English language or rules of grammar.]
Intro [00:07]:
Welcome to automation explanation, an agile thought podcast, exploring quality through automated testing and its vital place in modern software development. And now here are your hosts, Antwan Maddox and Greg Burdick.
Greg Burdick [00:24]:
Well, welcome to automation explanation. This is Greg Burdick speaking. I’m a senior quality engineer or what we’re calling test automation engineers now, um, in accordance with the software development, uh, quality Antwan can fill on that. And Antwan Maddox is here as well. He’s my boss and he is the quality engineering director and, uh, Antwan, why are we calling? Uh, well, you’re switching to, uh, test automation, engineers. What is that for? What does that, um, stand for?
Antwan Maddox [01:04]:
So it’s, uh, test automation engineer. Um, so it’s good. We’re switching that, switching to that because of the fact that, uh, we want to be in an alignment with, uh, the ISQ TB certification that’s out there, uh, formally, uh, we used to be a quality or, or quality engineers, right. But that term has been, you know, that role, you know, convention naming, you know, has been kind of bounced around throughout the industry. Uh, and sometimes you have quality engineers that are really just manual testers. Then you also have, you know, quality engineers, those that actually write automation, scripts or automation tests. Right. Uh, and so, you know, it just makes more sense for us to be in line with like the, the industry standard certification, um, uh, process out there that is the ISQ TB and at the same token, it just makes more sense. They call it test automation, engineers. We should probably call it the same thing too as well.
Greg Burdick [01:58]:
Well, there’s no argument for me, I’m all for clarity and, uh, unification of terminology. So, well, we’re here to talk about automation strategy. And so why, why is automation strategy important? What’s the significance of automation strategy?
Antwan Maddox [02:19]:
Um, well I think the significance is that, you know, I think Benjamin said, it said it best, you know, um, if you fail to plan, you’re planning to fail. Right? A lot of times I see, um, you know, on specific client engagements or, uh, different organizations, they St try to start automation. Um, and that’s because they, you know, they they’ve seen some something out there whether via YouTube or social media, how automation is supposed to solve certain things, right. Yeah. Faster or approach to testing, uh, that can eliminate, you know, manual testers and stuff like that by having more automation and stuff like that. But, you know, when they start trying to implement automation, they, they find out that there, there really is no plan, you know, um, on how to do it effectively and, and efficiently. Right. And so that’s the reason why, you know, uh, I think for, for, before you have to go, before you go into anything, you have to have a plan. You can’t just build a house without having some sort of foundation, you know, some sort of scaffold of a prototype. You have to have a, an actual plan first before you start building something or less, you know, you’re gonna have some gaps, um, in your process towards building that house that, you know, sh you know, should have been essentially put in place and you’re gonna fail, you know? So that’s the reason why, like
Greg Burdick [03:32]:
Having a blueprint, having a blueprint, build it on paper first, think it through and, uh, having a plan of execution then. Right.
Antwan Maddox [03:41]:
Exactly. Exactly.
Greg Burdick [03:43]:
Okay. All right. So let’s start off, maybe let talk about, uh, where did this idea of having automation strategy come from, uh, your deep in the history of this industry? And at what point did you gain a greater appreciation for automation strategy? Where does it come from?
Antwan Maddox [04:04]:
Yeah, uh, I think it stems from experience, you know, um, in the past, like in, in our last podcast, we talked about the background history of automation and, and how there was this initial high, but at as applications or application technology progressed, some of the technology surrounding automation had to had to change, you know, to kind of meet the demand, you know, and it fell a little bit of hard times in meeting some of those needs, um, that has led to all these different types of commercial vendors out there that are building tools, you know, even open source teams that are building tools to compete in delivering tools in the market to solve those problems, right. In terms of automation, uh, I believe that is what you see today, you know, but the, the caveat here is that, you know, that well, the new newer tools is not, not a bad thing.
Antwan Maddox [04:55]:
Having new tools is not a bad thing. Innovation is not a bad thing. I just think there’s this theme in the industry that the tool is going to, you know, help you create a strategy or help you drive this strategy. You know, I keep saying, and I think in the last podcast, I said, you know, um, I just do not think that the tool should, should be driving the strategy, your strategy should drive the use of the tool with that being said, let’s, uh, let’s kind of dive in, you know, I think it’s very important for us to kind of discuss what happens if you don’t have a test automation strategy. Um, uh,
Greg Burdick [05:28]:
So I can speak a little bit about that. I mean, I’ve been on a lot of contracts, uh, over the last couple years, and pretty much the, the status quo in most of those contracts has been, well, we’re just gonna drop in a resource and the automation strategy is going to emerge. It’s either the tool driven and, or, um, you know, the quality engineer or the test automation, engineer’s job to sub allow the automation strategy to emerge, um, with really little or no input, uh, from the rest of the development team. And that’s been my experience and there’s some pain and frustration, um, that, you know, permeates the project team when that happens. Um, it’s not altogether clear, um, who owns automation strategy? Where does it come from? How does it come into existence?
Antwan Maddox [06:35]:
Right. Yeah. So it’s very important. You know, that we understand that the automation strategy is owned by the actual team, the whole entire development team. And the reason why that is, is because there needs to be a contract among team members, you know, on how the strategy is supposed to be, you know, formulated, right. How, what is the strategy for automation? You know, a lot of times what I see on these different client engagements or projects is that there’s this notion that quality engineers are the only one that can build the strategy. The only ones that actually own the strategy. When in reality, if you don’t share that strategy with your teams, you know, and it’s not solving, you know, anything, you know, that’s gonna yield the value to the team, then that’s a problem, right? The whole team, you know, needs to be aware of the strategy and that’s because they need to be able to realize the value of that. They need to understand the value of, you know, that the, the actual design approach, the, the, the process, you know, um, and how you plan on building these scripts, you know, how these scripts are gonna be leveraged. They need to understand the value behind that everyone needs to be, or have full vested interest into the actual strategy itself.
Greg Burdick [07:43]:
I SA I, I totally agree. And I’ve, it really gets to be like down to the philosophy of, uh, quality. And that is, you know, like who cares about quality and, um, what is the significance of quality itself? Is it just a process we go through because that’s part of our software development life cycle, or does it have a tangible benefit to all the people on the project team, in assuring them that the deployments are gonna be successful and lowering the anxiety and stress around deployments? Um, those are all important things not to be overlooked in that are super important when it comes to developing and considering an automation strategy.
Antwan Maddox [08:36]:
Mm-hmm <affirmative> absolutely.
Greg Burdick [08:37]:
Okay. All right. And so, um, on a practical level, I mean, you and I have probably a pretty good idea of what automation strategy is, but what would, how would you describe an automation strategy?
Antwan Maddox [08:56]:
Yeah, yeah. So an automation strategy in short is, is what defines the, who the, what the win, where, and how of cuz automation. But, you know, in layman’s terms, I could think of it as a plan that is agreed to by and understood by the entire development team, you know, for creating and maintaining automation tests to help ensure, you know, a higher ROI increase coverage and reliability and faster time to market in a way that is repeatable. Right? So let me highlight a few things. Um, when I, with that, all that being said, you know, number one is a team agreed upon contract on how and what should be automated or how it should be done. Right? Number two, its purpose is in support of creation and main in maintenance of ensuring adequate coverage yielding an ROI, right? And then number three is purpose, you know, is, is also towards faster time to market, right?
Antwan Maddox [09:53]:
And it’s all coincides with the two pillars of, of agile. There’s, there’s like at least four pillars of agile, right. You know, two of them have to do with collaboration and the other one has to do with response to change right now, if the team is not agreeing upon the strategy right there, you know, your collaboration is out of sync. And also your response to change is also add outta sync too, as well. Right? So you, you, your, your strategy is very important and you should define how you are going to go about doing automation. Who’s going to be writing it and maintaining those scripts and when and where you’re going to be leveraging it.
Greg Burdick [10:27]:
So, another thing that came to mind when you were talking about that is, um, you know, the idea of, and this has been proven over and over again, the importance of catching bugs and defects and things like that, uh, earlier in the development process. And, you know, a test automated strategy obviously, um, is only gonna help with that. You know, having a plan, having an organized approach to quality, to test automation is only going to help with that. So I just wanted to mention
Antwan Maddox [11:11]:
That. And, and I, I wanna add to that, you know, a lot of times there’s like you, like, you’re just mentioning right now, there’s this big notion that automation’s supposed to catch or is designed to catch bugs. No automation was never designed to catch bugs. It happens to catch bugs, cuz you’re testing a repeatable path. But, but, but think of it this way, you know, if you have a subscript that you, that you have to automate and you’re automating those scripts and a bug is found outside of that path or outside of those test cases, that that you’re automating, then how is it that automation is supposed to catch outta a bug? You didn’t script it. Right. You know? And so how it’s gonna catch that. And so that, that’s what I’m saying is that automation is, is designed to test a repeatable path. And if that, and if something in that path breaks, then a bug is found a defect is found that a job of the quality engineer, you know, the actual development team overall is to help discern what, what are areas of volatility? You know, what present business risk, right. And if you can kind of, you know, block, you know, uh, you know, uh, the application from, uh, having those come production, then that’s gonna give you your, your better right there. Right. If you can kind of like re catch those ahead of time, that that’s great. Right. But it’s all centered on basically, you know, what you’re testing and how you’re testing it. Right.
Greg Burdick [12:26]:
Oh, that’s beautiful. All right. So next, uh, the next question is what should be included in an automation strategy? So we’ve heard you say it should be an agreement and a contract, and maybe that’s in the form of a, like a service level agreement perhaps. So I’m kind of getting back to what exactly is a test of automation strategy. Is it a document? Is it an SLA? Is it something else? And then what should be included in an automation strategy?
Antwan Maddox [12:56]:
So, um, the, you know, the first thing that needs to be done is that you need to identify your, why, you know, you have to understand your why for automation. In other words, what is the goal for automation? You know, once you have a goal documented for automation and you and you, and you can zero on zero in on that particular thing, right. You know, those goals can actually stem from, you know, by the way, you know, whether, whether your goal is closing out the sprint with test automation in place or reducing regression time, or handling lots of data inputs and repetitive tasks better, or transitioning from waterfall, or as you transition from waterfall to, to, to agile. And you want to have continuous testing, C I C D you know, these are all different goals that, that, that could be formulated by having a conversation conversation with the actual business, right?
Antwan Maddox [13:41]:
Understanding the organizational needs. Um, considering all these things, you know, that is gonna help you to determine the tools that you’re gonna need, the technique that needs to be followed the process, you know, um, and in building automation, the members on the team and technologies that are gonna be used, you know, to support those goals, right? So number one is defining the goal, right? And then that’s gonna help you flesh out like the tools that correlate with your application on how you want to actually run, build your, your automation scripts. It’s gonna help you determine what members you need on your team to help support automation. You know, um, it’s also gonna help you determine like what additional technologies you’re gonna need, right. Um, and the environments you’re planning on running against and how you’re planning on actually running these against different environments, all that is being fleshed out. Once you identify the goal, and there are things in place that can be, can be leveraged to help build that plan. Like, I think there are tons of tools out there that can help you like a mind mapping tool that walks you through basically, you know, all the different sections on, on, on documenting the actual strategy from the goal all the way to how you planning on running these scripts.
Greg Burdick [14:58]:
So is it fair to say that it, you know, automation strategy is part of, uh, project team’s definition of done, but it actually goes well beyond the definition of done.
Antwan Maddox [15:10]:
Oh, of course it actually begins at the very beginning too, like in the feasibility study, you know, once you’re actually on the project, it’s very important. Like I said, in, in, in the earlier podcast, it’s very important that, uh, quality engineers understand they’re the full landscape of the application, right. Um, the, the, the, the whole entire AR uh, application architecture, and they’re already talking to other members, whether it be DevOps and developers or technical architects to help, you know, come up with a strategy. So,
Greg Burdick [15:37]:
Yeah. And that’s, uh, you know, um, falls into the category of shifting left too, doesn’t it? I mean, yes, yes. Where, you know, we’re trying to move as much upstream or shifting left as possible just to make deployment more regular, more, um, more, less stressful, um, in that like that, right. You, you wanna get the requirements as early as possible and do as much planning with as much lead time as possible, but that’s the topic for another day shifting left. So what types of testing approaches have you seen being used to leverage automation? What’s, what’s worked out there.
Antwan Maddox [16:25]:
Well, shifting left is a big thing nowadays, right? That, I mean, you just hit, hit the, hit on the nail there, you know, um, there’s this whole, uh, industry drive on getting test automation, engineers and shifting left, right. Uh, previously it’s always been, you know, you, you have your test engineers developing these tests, you know, isolated from the application development, but I believe there’s a bigger need now where test automation, scripts or test automated solutions need to be fully, you know, almost enveloped or embedded in the application, uh, uh, solution that way, you know, it also aids in maintenance because if you actually have scripts out there that have fully integrated into the application, you know, a solution, um, the developers can help you maintain these tests too, as well as they make changes to the, to the UI or to whatever, you know, maybe an API or whatever they can use your scripts to, to validate whether that is breaking your, your tests, you know, into flesh out other issues.
Antwan Maddox [17:25]:
Right. Um, and then as they discover those issues, they can actually maintain or help you maintain and update those tests. Right. So there is a bigger need to kind of shift, you know, towards, you know, towards, you know, shift, shift shift left there. Um, there’s also like component testing approach, which also is a shift left approach in which, by your you’re, you know, leveraging a lot of these Java frameworks out there that are very lightweight to help you test, you know, application components. Um, there’s, BDV, you know, where it helps you kind of facilitate in sprint automation, because now with a mature team approach to automation, uh, your team is working together in helping build automation across several different features, you know, as you deliver it AC um, across the sprints. Right. Um, and so everyone is, is, is, uh, has vested interest in what stories get automated, every single sprint, right?
Antwan Maddox [18:17]:
And everyone’s, everyone’s on the same page. Uh, the last three have to do with like, uh, you know, uh, a more mature approach, I believe in automating, um, which has to do with risk based strategy, you know, where you whereby you automate use case scenarios, instead of automating small little minute features, you’re automating use case scenarios and things that are gonna be critical to prevent, you know, production based risk. Right. Um, and, and a part of that approach is if, you know, I could ask this question when it comes to the risk based approach. If I had to run a smoke test spending like 15 minutes, what tests should I include in my run? Because again, when it comes to the risk based approach, you know, that’s part of a definition of continuous continuous testing, whereby you’re saying that you want to be able to prevent production based risk as rapidly as possible.
Antwan Maddox [19:09]:
So there’s no more about, there’s no more thing. There’s no more this thing about these huge monolithic UI tests that are running on the pipeline anymore. It’s it’s now, okay. How can we, how can we, how can we prevent risk quickly? How can we provide feedback to these risks quickly? Right. So now you’re talking about, okay, well, my automation scripts are gonna be time, time sensitive, right. And I need to be able to provide enough feedback, you know, on assessing risk as rapidly as possible. You know, so there’s that as the last, the second to the last approach, um, is model based testing whereby your, your, your tests are being built off of, you know, the, the models of an application, like you’re modeling the application. And as you’re modeling the application, you’re building tests off of those models. And the last of course is contract testing, which I am excited about because right there, you know, everything now, nowadays is going microservice oriented, right?
Antwan Maddox [20:04]:
Like you have several different scrum teams, you know, working together, building their own, like I, you know, um, their own standalone components and stuff like that, that, that eventually will get integrated together to make one application. Right. But they’re operating, you know, independently of each other, right. You may have scrum team, a scrum team, B both building microservices, but guess what, they, they will talk to each other, but they are being developed in isolation or independently of each other. And they get deployed independently of each other too, as well. Right. Well, how do you handle that? You can’t do full end to end or integration test that way. You know, that’s very expensive, right? Well, with contract testing, it allows you to be able to assess, you know, um, the contract that a particular service component has with another. Right. So there’s more details on that a little bit later, but these are some of the strategies that I see so far.
Greg Burdick [20:56]:
Yeah. Those are great. Um, you know, some of these applications are, you know, very widespread and, um, wide reaching and it’s impossible to, you know, kind of cover the entire thing without kind of having a means of, you know, breaking it up and, um, using those contracts, like you’re saying one other thing that it kind of came to mind while you were talking was, and this is, I think is particularly true here in America, is the idea if a little is good, then more is better, right. This brute force approach to ensuring quality. And I think the strategy that you’re talking about is really helps to identify priorities, kind of the KPIs of, um, the application. What do we need to exercise to ensure, uh, that we’re comfortable with the quality that the, the deployment is gonna be fine? And we can all relax a little more, uh, as things are promoted,
Antwan Maddox [22:08]:
Right? Yeah. Yeah. I’ve been a part of projects whereby I, you know, I’ve seen scenarios where, you know, the clients or, you know, the business wants to automate everything. Right. But not every single thing is gonna be of, of, of huge value. Right. You know, certain things are of lower priority or lower value than others. Right. I, I think, again, it goes back to what are, how do we go about preventing production based risks, right. Certainly like a, a button turning green, is that a huge risk, you know, come production, right? Mm-hmm <affirmative>, if it doesn’t turn green, right. But if I can’t, if I can’t, uh, process an order on an application, then that’s a problem because that is one of my use cases, right? So we have to, you have to be able to identify how are the users gonna be using this system? What are the high level use case scenarios or business workflows that are gonna exercise to be able to be able to accomplish a goal? And if they can’t do that, then that’s a major problem.
Greg Burdick [23:02]:
I agreed that’s only gonna help. And, um, but these are obviously big questions for project teams, organizations, you know, these are, have a legacy of being compartmentalized, siloed, uh, work teams, you know, work roles. And you’re talking about blurring the lines between those right, where, uh, test automation, engineers are working alongside, along with actual developers. And we’re departing from the manual testing paradigm into something all together, different. Right. Does that sound about right?
Antwan Maddox [23:48]:
Yeah. Somewhat. So, so I would say this is that, you know, what I’m talking about is a fully integrated team, um, that involves not only just QA, but also like test automation, engineers, right. Where everyone’s talking to each other, everyone is, is focused towards quality. It’s not just like developers working on developing, you know, features or whatever, but again, they’re developing features that are gonna be testable and automatable. Right. So they, they have quality in mind in terms of testing in automation, in automatability, right. They’re sharing content with each other. Right. If I, if a developer changes in API or whatever. Right. You know, um, and that, and that, that deduction of that is attached to the actual story. Right. Or changes a UI, you know, component, you know, then they, there, everyone’s aware of that. Right. Uh, I’m talking about basically, you know, a team that is in alignment with the continuous test maturity model and, and that’s a model out there.
Antwan Maddox [24:43]:
And we’ll talk about this a little bit later, but that’s a model out there that, you know, kind of stems from the software capability, maturity model, whereby there are certain, it, it is used to be able to gauge what level of maturity the organization is, or the, the project team is in actually leveraging automation and actually, you know, um, um, implementing automation and it’s a whole team approach, right? It’s not just like the QE is doing QE work and developers doing Q Q uh, developer work. It is a fully integrated team dedicated towards not only developing features, but also continuous testing.
Greg Burdick [25:18]:
All right. So let’s, uh, let’s see if we can identify some models for success. Um, nobody has complete insight into, you know, the market or whatever, but just with our layperson’s knowledge of the it industry and business, um, in north America, what, what organizations like, are you aware of that are really doing automation well that have a model for success. Did anything come to mind?
Antwan Maddox [25:54]:
Um, I mean, Google definitely has a, a, um, they have a very strong model for success because they, they, they understand automation. I really, I think it boils down to this right here is that the organization itself has to be reeducated or educated on automation. Right. You just can’t just watch something out there and expect that to be the answer. Right. They have to really understand automation. Right. I don’t think, you know, uh, the, the org, I don’t think a lot of orgs out there actually truly understand automation, how it’s, how it’s supposed to be leveraged. All they know is that when they hear automation, they have these programmatic tests that are gonna be catching bugs. Right. But more mature organizations are more mature. Organizations are, are those that actually are operating along some sort of model that is gonna yield success. And that is a continuous testing maturity model, whereby you know, developers, DevOps, testers, test automation, engineers, even the product owners and business team are dedicated towards supporting automation. And they know what their roles are in all of that. Right. And they’re all talking together to help, you know, uh, uh, bridge those gaps. So,
Greg Burdick [27:14]:
So when you say that, what I’m also hearing, I mean, would you say, you say organizations don’t really understand automation does that also kind of apply to quality? Like they don’t have a full appreciation for automation and they don’t, they know that quality is necessary, but maybe they don’t know exactly why. I mean, how important is that?
Antwan Maddox [27:36]:
I think they understand why, but they don’t understand the effort it takes. They, they don’t, they don’t recognize quality as a, uh, not only a practice, but an actual art, right. Quality is an actual art. So is test automation engineering there they’re both arts, just like development is an art. Right. You know, uh, there, there are certain things, there are certain principles in place, you know, that yield success. And so all, I hear a lot of times from a quality standpoint from, you know, this, this being a, a, a, you know, an organization or a business, uh, uh, the business team is saying, just, just test my stuff, just test it, test it. What does that mean? Right. You know, there’s, there’s so many different facets to test something, right. Mm-hmm, <affirmative>, um, and it really truly isn’t art. And so, you know, I know that we’re all about like, you know, uh, quickly and efficiently testing things and stuff like that, you know, but I really feel as though, like automation, you know, even though it’s great.
Antwan Maddox [28:34]:
Um, and, and it’s good to have, and you need to actually have it because that’s just more, the more of the modern way to be able to prevent risk. Um, I don’t ever see automation truly replacing, you know, quality analysts or manual testers, because again, there’s an art to it. You know, there’s an art to things. There’s certain things that, that, that can be done from a Manchester side that, that maybe an automation engineer can I do when scripting something. Right. Mm-hmm, <affirmative>, you know, so, you know, it is an art and that’s what needs to be understood.
Greg Burdick [29:02]:
So the metaphor that I’m thinking of, and we use this earlier, right. If you wouldn’t, you wouldn’t build a house without a firm foundation, or you wouldn’t start building a house without a blueprint. Right. But, you know, imagine building a house and really focusing on velocity and throughput only to find out at some point later down the line that it doesn’t pass code, right. Having to deconstruct something to only to, you know, make it so that it can, you know, pass code inspection. And I think that kind of is a good, um, analogy to automation to testing. Right? You need that feedback early in the process, or as you’re working, so that you’re assured that things are gonna work later in the process, we are going to be able to pass inspection. We are gonna be able to deploy. We are gonna be able to pro promote from a lower environment to a higher environment. And we’re not gonna be afraid of having a Del of bugs coming at us and having fundamental integration problems, things like that.
Antwan Maddox [30:09]:
Mm-hmm <affirmative>. Yeah. I think, I think a lot of times we have this, you know, when we talk about agile, right. There’s this thing that, you know, and it’s this misconception that there’s, there’s this license to, to be, to operate fast, this license to kill. Right. You know, we, we agile, you know, let’s, let’s move fast, you know? Yeah. We can move fast. Right. But when you’re moving fast and you know, this, like, you know, when you, when you do anything fast, you know, especially faster than, than, than what you’re used to doing, or what is, what is common to do, uh, you run the risk of skipping things or missing things or whatever, right. That’s why quality, you know, is important from, from a manual testing standpoint, as well, from an automation standpoint, you know, quality needs to be important to this fast delivery that we call agile, right.
Antwan Maddox [30:50]:
Or this efficient delivery, or this continuous delivery we call, you know, that’s part of the agile process. Right. And so, you know, it is very important. You, you know, why do we involve a, a foreman in a project manager and in all these different like roles when it comes to building a house, right. They’re, they’re essential. Right. And even though we were, we’re building this, we may have, like, I love these shows out there, this like build a house in a hundred days or whatever. Right. You know, there are certain people, you know, or certain people that play certain roles in making sure that that is supported. Right. And that may involve people, you know, uh, search cards, different roles that do certain things to, to make sure that that goes successful. Right. But even though you’re building a house quickly, you have certain people in place that have that, that, that, that are skilled in certain certain disciplines to make sure that the foundation is in good, in good, in good, in good shape, uh, that there, you know, there’s, there’s no other issues when you, as you are building this house. So it’s very important that, you know, each role, you know, is, is, is vital in making sure that you can deliver, you know, um, an application, um, in an, in an agile way. Right. It’s very important, you know, and that’s why quality is, has to be in the center of, of, of all, anything to do with agile.
Greg Burdick [32:04]:
Yeah. It reminds me of that, the old proverb, right. If you wanna go fast, go alone, but if you want to go far go together, software’s not assembled by any single person or team. Now it’s a, you know, it’s a substantial collaboration between many different teams, many different specialties, right. And yes, it’s like relocating a village. We are going to go together towards this thing called deployment and eventual release to the customer. And, you know, we haven’t even talked about, I mean, Canary build and stuff like that, where we wanna be able to, you know, we’re researching how our customers respond to this, you know, design and, you know, this arrangement of, um, you know, webpages and whatnot. Yeah, absolutely. I mean, it’s things are not getting any less complex. Let’s just say that
Antwan Maddox [33:00]:
<laugh>
Greg Burdick [33:02]:
Okay. So let’s, um, talk about Antipas to avoid how about that. And I’m gonna start off with the first one that says, this has been, my experience is that, well, a project team or a project manager, a hiring manager would say, well, we just need the right or a top shelf ASTE quality engineer, test automation, engineer, come onto this project, and then we’ll get some traction. That’s an adding pattern in my, anything. Any thoughts on that?
Antwan Maddox [33:35]:
Yeah. So there’s two types to that coin. You know, sometimes what they might be saying is that we don’t even need like a QA person. We just need a, an aesthetic, you know, fully functional aesthetic that can actually build these automation scripts and that doesn’t, we have seen it, that, that doesn’t really work. Right. You know, um, you know, you can’t, you, it’s hard to bridge the two different disciplines of manual testing and automation. It’s hard to do that. Right. Um, you have to have a really, you know, mature team approach and a mature adoption to that, you know, and what I mean by that is that, you know, when it comes to, you know, your development team and how you deliver features and, you know, across the different sprints, you know, you have a mature approach on how you assess a velocity. Right. And so when you have a mature approach to do that, you’re, you’re, you’re embedding or you’re accounting for not only just the testing of these features that are coming in and you’re delivering them on time for, for them to be tested, but also you’re also baking in the time it takes to actually automate some of this stuff.
Antwan Maddox [34:33]:
Right. Um, so yeah, and just having an <inaudible> is not gonna solve all your problems. Right. Yeah.
Greg Burdick [34:40]:
And I think too, I mean, the idea of let let’s automate what the manual testers are already doing, that doesn’t really qualify as an automation strategy. Agree.
Antwan Maddox [34:54]:
Nope. Agree. No, it’s a duplication of effort. That’s what you’re doing. Yeah. Right. <laugh> uh, the, the, I think the, the manual test should be focusing on, you know, short term deliverables, like, you know, testing what’s in the sprint. Yeah. They have the regression test too, as well. Right. Uh, but we should be focused on the long, over the long haul in preventing production based risk. And I keep saying that over and over again, cause it’s very important. It’s very important that quality engineers are focused towards long term prevention of production based risk. Let the manual focus on basically, uh, making sure that features that are being delivered in the sprint are tested and are, are, are, are validated and make sure they work because those features are, are necessary for us to, to, to leverage, to automate, you know, along this, this, this use case path. Right. But over the long haul, you know, the disciplines, you know, they’re different, you know, testers focus on in sprint deliverables, you know, and regression across, you know, features that were delivered in prior sprints or whatever. Right. And there’s, there’s, there’s a science to that too as well. But then the, the test test automation, engineers focus on preventing production based risk.
Greg Burdick [36:02]:
Yeah. Here’s another one Antwan let’s um, let me get your, um, response to this automation strategy is secondary to just getting our feet wet with automation. We need something to build on automation. Strategy is secondary to just getting started with automation. We don’t need a strategy right now. We just need to start somewhere. We know we need automation. Let’s just start with something we can build on that and worry about strategy later. What do you think of that? Yeah.
Antwan Maddox [36:32]:
Yeah. That’s, that’s, that’s really a bad thing because now you run the risk of, of, of, you know, not adding any business value long term. Right. And then you also run the risk of, you know, you also run the risk of, you know, using the right the wrong test automation technology too, as well. You know, because now you’re just, you’re just trying to move ahead, trying to move ahead, but you’re not thinking about the bigger picture here, right? Um, there’s, there’s a vision for automation for first and foremost, that that needs to be in place. Right. And that vision needs to be mapped to some sort of VI business value. Right. And if you’re just, you’re just starting automation or whatever, you can, it’s easy for you to start, like, you know, leveraging a tool that doesn’t even, even, you know, doesn’t even like, it doesn’t even correlate with your actual application.
Antwan Maddox [37:23]:
Right. Mm-hmm <affirmative>, you know, and then also like you’re just automating stuff, automating stuff that before, you know, it, you know, you’re automating things that are not gonna be a business value. There needs to be a plan in place, no matter what, right. Cause then you’re gonna run the risk of, you know, your automation project being canceled because it’s not hitting those ROIs. It’s not providing any sort of business value. You’re not catching, you know, volatile risks areas in the application, you know? Um, you’re not testing certain things the way the business would want you to test them. You know? So again, it’s, it’s a contract that is put in place by the development team on how automation should be done. And everyone agrees with it. There’s no like flying under the radar here. There’s no. Oh, why didn’t we automate that? You know, everyone understands the strategy.
Greg Burdick [38:09]:
So that’s a great segue to this next point of, you know, when you say not adding business value, you know, at what point, how frequently does do those, the return on investment from automation need to be reevaluated to prevent. And I’ve seen this, the idea of like, well, we’re too, we’re too invested in our tool set in the training of our, our quality people, whether that’s, you know, QA and test automation, engineers together to really change our, whatever it is, automation strategy, uh, to, to deviate from that. Um, and the idea of like, we’re gonna have to abandon throw away all this code, however many months or years worth of work. It was to kind of build that up. That’s a, that’s a substantial decision, right? I mean, what do you say to that? Right.
Antwan Maddox [39:08]:
Well, the, if the automation team is fully embedded into the, the actual scrum team or development team, right? These conversations are actually taking place every single time they actually come to planning. Right. Um, they they’re, they’re not only just talking about like what they plan on delivering from a future standpoint, but, but, you know, is, is what is the strategy that we currently have in place? Is that going to meet the need? And the goal for automation, we have this overarching goal, you know, that has been set by the business or by the development team. Um, and so we are always gonna be reassessing that, you know, is our approach right now, going to yield the best ROI to meet that specific business goal or need, right. We’re doing this every single time we have it be coming to sprint. And the moment that it, that we get off track, we, we, we, everyone is involved in determining what should be done next.
Antwan Maddox [39:58]:
Right. Um, so that’s very important. You don’t wanna wait until like, you know, I’ve seen this before where, you know, we had like, I think 20, I think we had, I think about, about 10 or 12 sprints before we actually had a production release. Right. And we were automating all these different things, the way that we had envisioned we were gonna automate it. And then all of a sudden it comes to find out that, oh yeah. Well, now that we’ve done that, you know, we go in a different direction now. Um, and so, um, yeah, and, and that’s because the quality engineer team, you know, or te automation engineer team, wasn’t talking to the business. Right. And that’s why the business is very important. Right. Um, and so, and as well as the development team, so this stuff is being reassessed, every single sprint, you know, again, the key here is to make sure that everyone is involved in an automation process.
Greg Burdick [40:46]:
So what about, uh, if you go into some of you, I haven’t, this is not widespread. In fact, this is most developers I’ve found have been very interested in quality assurance and are all about it, but there are pockets where, you know, you might go in into an organization or a dev shop and say, well, our developers are not concerned about quality. That’s what we have a QA department for. We have a whole, you know, competency center around quality assurance to make sure quality is. And, um, is that an antiquated thought? Is that kind of a retro, uh, perspective? Would you say
Antwan Maddox [41:23]:
That is a big issue that I’ve seen among organizations. Right. But I think they’re getting better at that now, you know, the, the development team is slowly adopting, you know, the whole automation stuff, you know, especially now that, you know, this is part of modern delivery now, right. You know, you know, with modern delivery, you have to have continuous testing right. In the past, you know, um, those that are familiar with waterfall, you know, um, and are slowly transitioning to agile, you know, you you’ll have that. Right. But as they, uh, establish a cadence in, in, in, in working on an agile team, they, they, they, they, they they’ve slowly begin to understand the need for, you know, continuous testing and how automation needs to be a part of the process. That’s why there’s a bigger need for that right now. That’s why, when you look at the, the full landscape of it, automation, automation, automation is a big, huge thing. Right. Cause everyone is starting to realize it now.
Greg Burdick [42:13]:
Yeah. Well, that’s it automation, the demand for automation is not shrinking it’s growing. And the internet of things is only going to increase pressure on that. And the mm-hmm <affirmative> importance of getting to market, um, and being efficient with your resources. Um, you know, um, project teams, you know, you can’t, you can’t throw away time, you can’t throw away, um, people’s effort, um, you know, without consequence or with, with the, you, can’t be careless about that. You need to be, uh, you need to have an automation strategy. And I guess that’s what I’m kind of trying to wrap up with is, you know, we started this, uh, talk off with, you know, what is the significance of, um, automation strategy and how would you sum it up Antwan
Antwan Maddox [43:11]:
The significance of automation strategy to make sure that everyone is in alignment with the, with how the, what the, when and where, and how, and, and the, who is gonna do automation, right. Everyone’s in alignment with that, right. And if you don’t have that, you’re going, you know, you, you, you run the risk of failure, right? So everyone needs to be on the same page in terms of how automation needs to be leveraged, where automation needs to be leveraged when, and what is being scripted. And who’s gonna be maintain, maintaining, maintaining these scripts.
Greg Burdick [43:42]:
Yeah. I’m thinking too, like, it’s, it’s not just important to do it, how you do it is important and what you’re doing is important. Um, and I’d also say this too. I mean, it goes beyond the conversation of, um, technical efficiency and a project harmony and things like that. I mean, people are using software. People are, there’s a large number of people involved in producing software. And if you have a good automation strategy, the stress involved with the deployment is almost certainly going to be lower than it would be without an automation strategy and the ease in which you are putting together software. And you’re assured of it’s construction one step at a time. That’s only gonna make the process of building that software easier, better, and more fun, uh, for everyone.
Antwan Maddox [44:50]:
And I would say if I had to summarize, you know, the, the reason behind automation strategy, just to now that I’m thinking about it now is that, um, it sets expectations.
Greg Burdick [45:01]:
Yeah.
Antwan Maddox [45:02]:
That’s the key thing. There, it sets expectations. So
Greg Burdick [45:07]:
It, and it communicates too, right. Results are significant when you have those results that can be shared with the team. It it’s good communication. People can move forward with confidence. This is working, this is a good design. This is gonna work. And we move towards deployment with confidence and lower stress.
Antwan Maddox [45:30]:
Yep. And, and then all of that, like you said, I think you kept saying KPIs right. A while back. Yeah. You know, it helps you, if you have a strategy in place and everyone agrees upon it, you can measure that value. Yeah. Right. So, yeah.
Greg Burdick [45:42]:
So yes. Thanks for listening everyone. It’s been a good talk. Uh, I’m Greg Burdick, test automation engineer at agile thought. And, uh, I’m my partner is Antwan. Maddox Antwan. You wanna sign off?
Antwan Maddox [45:58]:
No, it’s a pleasure doing this podcast. We’ll be many more. And, uh, yeah, I will see you on the next session.
Greg Burdick [46:05]:
So this has been automation explanation with, uh, Greg Antwan, Maddox. If you have any questions, please post them in the chat below. We’ll try to address any questions in upcoming episodes also. Don’t, um, don’t be afraid to check out some of the thoughts, other podcasts. We have some others related to, um, data science and artificial intelligence. Um, so check those out as well. Thanks everyone.
Outro [46:41]:
You for listening to automation, explanation, an agile thought podcast tune in next time for more about test automation, engineering, its benefits, and how to optimize it. The views opinions and information expressed in this podcast are solely those of the hosts and the guests, and do not necessarily represent those of agile thought. Get the show notes and other helpful tips for this episode and other episodes, agile thought.com/podcast.
Want to Learn More or Get in Touch?
Share These Tweets!
“The tools shouldn’t be driving the strategy, your strategy should be driving the use of the tool.” — Antwan Maddox
“The Automation Strategy is owned by the entire Development Team, everyone needs to have interest in the strategy itself.” — Antwan Maddox
“Quality Engineers must focus over the long haul on prevention of production-based risk” — Antwan Maddox
