Welcome to episode 4 of of our Whiteboard Friday series, Building a Test Automation Strategy: Options for Test Design and Execution. In last week’s episode, we covered your options for automating client application testing. This week, we’ll discuss your options for test design and execution.
Watch the Video
In this episode, you will learn:
- Different types of automated test designs
- Where to execute your automation
- Tips for maintaining clean environments
Here’s the full transcript:
Hey, everyone. Welcome back to Whiteboard Friday. This is Ryan Yackel with you here again. We’re gonna continue our series around building out a test automation strategy. And today, we’re gonna be talking about things related to your test design, and also how to actually go about executing these automated tests.
So, first thing we’re gonna talk about, looking at some of the design patterns that really are incorporated around building out your test automation scripts, and also people refer to those as your automated test designs, test cases, all the same thing, really. Looking at kind of how to go about doing those designs.
How to Use Page Object Model
The first one is looking at from a page object model. What this means is that you have all these objects on your page. Well, what you wanna do is make sure they are readable, and make sure they’re maintainable in the future if you need to reuse these, or let’s say for example, something changes on this particular page. So, what this does is it allows you to group all of these objects into a class, so that if you need to change, or add something to that class in the future, let’s say a script updates, or changes, all you have to do is update that class, and it’s gonna cascade across those different objects.
Using Data Driven Tests
So, a lot of you will use this also in tandem with these other two design patterns, which is getting into data-driven, and also keyword-driven. So, data-driven really refers to all the data that you’re running a part of your test automations. So, if you think about running an automated test case that runs through a validation form on your screen, right? Well, you’ve gotta have all these different business type testing that go on, depending on what data goes into that, but you may use that same script over and over again. So, what you wanna do is be able to inject data, a part of that automation, and be able to reuse that test case over, and over, and over again. Also getting into test data is the fact that really, what you’re doing is, you’re not…you could be using test data, or you could be using more production like data, so even the type of data that goes into your test automation is very important. So, what this does is it allows you to data drive your test, but without them being hard coded onto the test script. So, what really happens is that you’ll have your data living outside of your test scripts, and what you can do is call that data into the objects that’s inserting that data, or where in the lines of code where the data actually goes in. So, it’s a little bit more of a set up if you need to actually go about doing this. For your test automation engineers, it gets it a little more complex. However, it’s really good for the repeatability for those test automation scripts, so that you can just kinda inject data as you’re going across, right?
And again, I mentioned this a little bit earlier, but sometimes, it’s easy enough to do, even if you just wanna dump this into an Excel file, right? So, there’s other tools out there that can house the data for you. Pull on that data, maybe through an API, and run that automation in your scripts. But, you can also just pull it from one system, put it in an Excel file, and then point to that data when you’re actually running the scripts.
Looking at Keyword Driven Tests
The next part is looking at it from a keyword driven. So, keyword driven, what it does is that it adds keywords to one of the objects that are on that particular page. So, this gives another abstraction layer that really ties into the page object model. Lots of people are using the keyword driven design pattern because it’s easier for less technical testers to actually find… “Okay. Here are the keywords I need to add into my test case to actually then run it, right? That refers back to the objects that are on the page.” So, it’s a really good way to do that. Think about a login page, think about giving access to that form page, being able to say, “Okay. And for this set of objects I wanna interact with, here are the keywords.” It’s another abstraction layer for you just to easily add that into a test script, and maintain it going forward.
The next part is talking about…okay, well, let’s say we have designing going on. Well, last week, we talked about what kind of programming language, or framework you have. You’re kinda building out those tests as well, based off this design. The next part is like where are you actually gonna execute these tests, right? So, three ways really that we’re seeing this is really looking at one is, you’re gonna run these tests, right?
Executing Tests on a Local Test Machine
Probably, first time you do that on your local machine, your local desktop, your local P.C. that you have, right? So, that means you’re setting up. You have Maven on your machine, possibly. You’ve got a build tool that’s possibly kicking these tests off. You’re running these automated scripts, and then you could also be merging those automated scripts into a virgin control system, right? Kind of down the road. Again, looking at a kind of local test machines really, just for more of that, a quick running, quick validation of what’s going on your local machine, right?
Executing on Dedicated Test Machines
The next part is looking at, you know, more dedicated test machines. This really gets into test environments, right? So if you have, let’s say a lot of your tests need to run on a Windows OS, and then you just got a certain browser. We’re even certain version of your application. Well, on that machine, you’ve got all that environment set up, right? And with newer technology nowadays, you know, using tools like Docker to really spin up, and tear down test machines in clean environments. But, we’re moving more towards this to really scale all the test automation that goes on, and able to have clean environments when they’re actually about ready to run these.
So again, I talked about Docker, but how that works really, is that you could have an environment spun up on a machine, clean environment. If you’ve got the new build of the code on there, the tests are running, you’ve got that validation coming back to it, right? And then, when that’s done, you can tear down that machine so you’re not wasting, you know, a lot of the resources around there, right? So that’s really getting to dedicated procedures.
Executing with a 3rd Party
The other part is looking at maybe as a third party, right? To actually do all of the execution, right? This just gets into, again, this can be expensive. It could be, depending on how much you actually run your automated tests, but this is really looking at third party to really help out with doing this automation across maybe multiple virtual machines, multiple virtual environments, possibly, in the cloud to do all of these. So, a lot of our customers are using or leveraging AWS to do a lot of their test automation on these particular cloud environments. That’s another option for you to go about doing this for you to actually run these, and execute these, to really scale out that test automation strategy.
We get a lot of feedback on it. It’s really looking at, you know, how do I take selenium grid, for example, and be able to run that in the cloud, right? So, it’s another way to go and think about, you know, what ways can you take your framework, your keyword-driven framework, your data-driven framework? How can you then elevate that into an environment where you can run that repeatedly in the cloud, or even on, you know, dedicated servers you may have behind your own firewall, to really get the results back in clean environments, based off of new builds of your code. So again, quick look at kind of the designing aspects, and also kind of where to execute your automation. And next week, we’ll talk more about this, around about how to build out your test automation strategy. Hope you’ll come back to see us, and look forward to seeing you soon.