Define “Test Automation”
Cross-posted from my blog: http://weirdlyinterested.blogspot.com/2015/09/define-test-automation.html
First thing in the morning, while I am waking up from sleep, my brain begins a conversation. I don’t know who the conversation is with, and the topic seems to range, although often it is either explaining a movie/TV show/game/song, or is a conversation that I want to have with someone but haven’t yet. These conversations are usually pretty clear (probably since my mind is not yet in its usual cluttered state) and lead to most of my best “ah ha!” moments.
A few days ago, someone in line at the office cafeteria (who was in the office from another company for a sort of mini-conference) asked me what I do for a living. When I say “Test Automation” to most normal people, they contort their face in confusion. Suffice it to say, I have mentally earmarked the question to ruminate on in the future.
Also, this week I signed up to volunteer at my son’s school. I did this last year and loved it. They give you a schedule, and for the day, you float from room to room, with each teacher putting you to work with a small group of student son whatever they need you to help with.
So combining those things, I started to think about how I’d explain what I do for a living…
“I do Test Automation, or as I say it, ‘I make stuff do things all by themselves’. I write software that does things just like a user, in order to test other software. So, let me give you an idea of what that’s like.”
“Now, I need a volunteer.” Several kids raise their hands. I choose one from the front row, and wave her up to the front of the room with me.
“What’s your name?”, I ask.
“Allie”, she says.
“Hello Allie”, I say to her with a smile, and then turn to the rest of the class. “Alright, Allie is going to be our test subject, and you all are going to by my Automation Engineers. Now, Allie, stand over there.” Allie moves over to stand near a desk in a row of desks nearby.
“Okay, now engineers, listen up: the objective of this test is to get Allie to the door. In order to do that, we need to come up with an algorithm to get her there. Does anyone know what an algorithm is?”
The class stares silently, slight confused.
“An algorithm is a set of steps to perform an outcome. We need to come up with a set of steps that will get Allie to the door. So, who has an idea of how we could do that? Raise your hands if you do.” I see several children think through this, and a few begin to raise their hands.
I point to a boy in the middle of the room, “She should walk down that row, make a right, and then walk to the door.”
I smile, “Okay, good answer. So let’s talk about what Allie knows. Does anyone know what concrete and abstract concepts are? A concrete concept is something that is real, physical, and existing in time and place. An abstract concept is something that doesn’t exist in reality… an idea. So, Allie here understands concrete concepts, such as the desk, the floor, and the walls. She does not, however, understand many abstract concepts, such as what a ‘row’ of desks is. Let’s say for simplicity, she understands directions such as forward, backward, left, and right. So… for what she doesn’t understand, we need to be more explicit about.”
I pause for a moment, and then ask, “So, let’s try again. He’s got the right idea, how do we break that down into more specific instructions?”
The kids think of a split seconds before I see a couple more hands. I point to another boy mid-line of the room.
“She should walk forward 5 desks, turn right, and then walk past 3 desks.”, the boy answers with a smile.
“Good answer! Miss Allie, when I say go, I want you to do exactly what I tell you to do, okay?” She nods.
“Alright, Allie walk 5 desks forward. Count them out loud as you go and stop after the 5th desk.”
She nods, and walks forward down the row in front of her, counting out as she goes, “1… 2… 3… 4… 5.”
“Allie, turn right now.” She turns right.
“Okay, Allie, walk forward 3 desks, counting them as you go.”
She begins walking, counting “1… 2… 3.”, and stops right in front of the door.
“Awesome Allie, please come back up here. Good job engineers! You have just performed what we call the ‘happy path’. If the shortest, simplest, and most straightforward way to achieve our objective. Now, let’s talk about what happens off the happy path. What if, Allie being here was dependent on the last test that ran, and that test didn’t complete the way that should have?”
“So Allie, move one desk to your right, and one desk forward.” Allie moves to the designated location. “Now Allie, follow the same instructions as before.”
Allie begins to walk up the row, counting desks, but stops at 4. She turns to me confused, “There’s only 4 desks.”
I turn to the class, “Alright engineers, Allie has just reported an exception. She expected 5 desks, and only found 4, and now she has no idea what to do. So, we need one of three things: Either we need a set of instructions that will work wherever Allie is in the room… that would be best, or we need to check our instructions as we give them to ensure they can be followed and do something if they can’t, or we need to check that Allie is where we expect her to be before we do anything and do something if she isn’t.”
“Now, first option is our best option as it means our test can be done any time no matter what the conditions. The second and third options are less desirable because it means that the test can’t be done… which means either some poor person will have to do it by hand, which can be time consuming, or we just don’t have that test, which means we don’t know what will happen if some user does that. So… here is our challenge… we need a set of instructions that will get Allie to the door, no matter where she is in this room.” I motion to Allie for her to come back.
You get where this is going. The challenge is having the students write adaptable, fault-tolerant code. This is a simple example of some of the types of challenges I deal with day-in and day-out; only instead of navigating students through a classroom to a door, I am simulating mouse clicks, key presses, and calling APIs to impersonate user interaction.
Who knows, maybe some day I will get to do this activity with a real class of kids.