Think Like a Tester

When I first started learning Java, I was fairly perplexed by the parentheses found after every method.  Sometimes they were empty, and sometimes they had values in them, and I didn’t understand why.  Plus, in the declaration of a method, there was a variable mentioned before the method name, and I didn’t know why that was there.  I’ve found it’s easiest to think about parameters and methods in terms of input and output.   Here’s an example:

output Square (input) {

}

The green output describes what kind of result you are going to return from the method.  The green input describes what kind of input I put into the method.  This method is going to take a number, square it, and return the result of the squaring.  I would like the input number to be an integer, so I will declare that here:

output Square (int input) {

}

The word “input” is what I’m calling the variable that I’m going to pass into the method.  Because I know that if I square an integer, I will get an integer as a result, I’m going to declare that the output will be an integer:

int Square (int input) {

}

Note that I don’t need to create a variable name for the output when I’m declaring the method.  Now let’s add in the steps for the method:

int Square (int input) {

int output = input * input;
return output;

}

So what this function does is take the variable called input, squares it, sets it to equal an int variable called output, and then returns the output.

It’s also possible to have more than one input parameter:

String Square (int input, String name) {

int output = input * input;
String result = “Hi ” + name + “!  Your result is ” + ” output;
return result;

}

This is a little more confusing, so I will explain it in more detail.  The first line of the method is taking the input variable and squaring it, and setting it to a variable called output, just as it did before.  But in the second line we’re creating a String.  The characters in between the quote marks are entered into the string.  These are concatenated (added) with our int output and the String name that we entered in the parameters, using plus signs to add the characters:

“Hi ” + name + “!  Your result is ” + ” output

So if I called the function like this:

Square(2, Kristin);

The result String would be set to:

Hi Kristin!  Your result is 4

Then if my main program wanted to output the result, I would use the instruction:

System.out.println (result);

And my result would be printed to the console.

Now, what about methods that don’t pass in any parameters?  It would seem as if parameters would be needed to run a method, but they aren’t.  Here’s an example:

void MyParameterlessMethod () {

System.out.println (“I can print something out without even passing in a parameter!”);

}

All this method is going to do is run the print instruction inside, which doesn’t need any parameter. You may have noticed the void before my method name.  This says that the method isn’t going to return anything to the main program.

Is it possible to have a method that doesn’t pass in any parameters, but still returns something? Sure!

int MyParameterlessMethod () {

int result = 4;
return result;

}

This method assigns the number 4 to the variable called result, and then returns it to the main program.

In my next post, I will discuss setting up Eclipse and writing a simple program.

Another thing I struggled with when learning Java was what the difference was between a Class, an Object, and a Method.  Through personal experience and web searches, I have come up with this explanation:

A class is the basic building block in Java.  It consists of variables and methods.  Here’s an example:

public class Cat {  //this is the class

//these are the variables in the Cat class
String name;
int age;
int weight;
String color;

//these are the methods in the Cat class
public void eat() {
}

public void sleep() {
}

public void meow() {
}

}

A variable is a little bit of memory that stores a value to be used in a program.  A String is a bit of text, like “Hello!” or “rainbow”.  In the Cat class, the String variables we have are name (the name of the cat), and color (the color of the cat).  An int is an integer, like 7 or 13.  In the Cat class, the int variables we have are age (the age of the cat) and weight (the weight of the cat).

An Object is an instance of a class.  If we want our program to create and use a cat, we need to create a Cat object:

public void main() {  //this is the main method of our program

//this is where we create the new Cat Object
Cat Fluffy = new Cat;  //Fluffy is the variable name given to the Cat Object

}

A method is a task or group of tasks.  If you are familiar with mathematical functions, you might want to think of a method as a function.  In the Cat class, the methods are eat(), sleep(), and meow().  The parentheses after the method name indicate what kind of parameter will be passed into the method.  In this case, eat(), sleep(), and meow() do not require a parameter.  In the next blog post I will give some examples of methods with parameters and how they work.

Java is one of the most commonly used programming languages, and it works well with Webdriver and JQuery, which we will be using in our automated tests.  Java is an Object-Oriented Programming (OOP) Language.  You may have had exposure to OOP languages in the past, but if not, the concept may seem a little foreign at first.  Having grown up before OOP, I had a particularly tough time with it.  I hope that the explanation below will make it easier on you!

Think about the tasks that you do when you get ready in the morning.  You might: exercise, shower, and get dressed.  If you were writing a program, or class, to tell a robot to do these things, you would probably write a little subroutine, or method, for each task.  For example:

public class getReady {  //this is the class

exercise();  //this calls the exercise method
shower();
getDressed();

public void exercise() {  //this is the exercise method
pushups;
situps;
squats;
}

public void shower() {  //this is the shower method
get in shower;
lather;
rinse;
repeat;
}

public void getDressed() { //this is the get dressed method
put on shirt;
put on pants;
put on shoes;
}

}

Now consider your friend, who exercises and showers at night instead of in the morning.  His nighttime routine is: exercise, shower, put on pajamas.  If you were programming a robot to do your friend’s nighttime activities, it might look like this:

public class getReadyForBed {  //this is the class

exercise();
shower();
putOnPajamas();  //this calls the put on pajamas method

public void exercise() {
pushups;
situps;
squats;
}

public void shower() {
get in shower;
lather;
rinse;
repeat;
}

public void putOnPajamas() {  //this is the put on pajamas method
put on pajama top;
put on pajama bottoms;
}

}

Notice that the two classes have two methods that are exactly the same.  Why not share the code instead of copying and pasting it into each class?  That way if you ever need to make a change to your exercise method, you will only have to change it once.  Let’s make a base class that contains all the methods we might need:

public class Ready {    //this is our base class

public void exercise() {
pushups;
situps;
squats;
}

public void shower() {
get in shower;
lather;
rinse;
repeat;
}

public void getDressed() {
put on shirt;
put on pants;
put on shoes;
}

public void putOnPajamas() {
put on pajama top;
put on pajama bottoms;
}

}

Now, we can change our two programs to call upon the existing methods instead of copying and pasting them:

public class getReady extends Ready {  //this is your routine

exercise();
shower();
getDressed();

public class getReadyForBed extends Ready {  //this is your friend’s routine

exercise();
shower();
putOnPajamas();

The first step in automation success is knowing when to automate and when not to automate.  Here are some guidelines:

• DO automate repetitive tasks.

Recently I needed to add over 600 records to our application in order to fully test a feature.  Rather than add just a few records to partially test it, I created a simple test that would add as many records as I specified.  Another great thing to automate is a feature with a number of different permutations.

• DON’T automate brand-new features.

Yes, you will probably want to automate the feature eventually, but not the instant it’s coded.  A good QA tester will spend a lot of time doing manual, exploratory testing to make sure that she fully understands the feature and knows its limitations.

• DO automate basic smoke-level tests.

I like to think of smoke-level tests as tests that we would be really embarrassed by if they failed in the field.  One company where I worked had a search feature broken for weeks, and no one noticed because we hadn’t run a test on it.  Unfortunately, the bug was pushed out to production and seen by customers.  Automating these tests and running them at every build or early in the morning can help catch major problems quickly.

For many of you, your initial answer to the question “Why automate?” may be “Because management wants me to.”  This is, of course, a valid reason.  But after you have a few automated tests written, you will discover other, more important reasons:

• It saves you time.

At first it will seem as if automation is a huge time-sink, because it will take several weeks to get your automation system up and running.  But once it’s in place, it will save you valuable testing time.  As I am writing this blog, all of my automated smoke tests are running.  Even without looking at our application, I will know if something went wrong with the build this morning.

• It frees you from some repetitive tasks.

We have a search form in our application that has four editable fields: Last Name, Company, Email, and Phone Number.  In order to test this feature well, I would need to test with every possible permutation: just one field at a time, two fields at a time, three fields at a time, and finally four fields at a time.  This adds up to fifteen searches.  It’s rather tedious to do this every time I need to test the search function.  But my automated test is happy to run through these fifteen searches, as many times as I tell it to.

• It helps you to think more critically about your testing.

This blog is aimed at Software QA Engineers who know nothing about test automation.  I was just like you six months ago.  After much trial and error, I have successfully automated many tests, and I would like to share what I learned with you and hopefully save you some time and trouble!

In the next few weeks I will be covering:

• Why automate?
• When to use automated tests and when to use manual tests
• Introduction to Java
• Setting up Eclipse
• Setting up JUnit
• Introduction to WebDriver
• Setting up Maven
• Simple Maven commands
• Setting up Sauce
• Setting up Bamboo
• Creating your Base Test
• Introduction to JQuery
• Troubleshooting navigation issues