Wednesday, April 17, 2013

Introduction to Java: Passing Parameters

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.


Monday, April 15, 2013

Introduction to Java: Definitions

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

}

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.



Tuesday, April 9, 2013

Introduction to Java: Object-Oriented Programming

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();

}

See how much space this saves?  There are other reasons why OOP is a good idea, but the main thing to understand, in my opinion, is that OOP saves you from having to copy and paste code.






Wednesday, April 3, 2013

When to Automate

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.


  • DON'T automate fragile features or works in progress.
There may be a feature of your company's software that seems to break every time someone looks at it funny.  Automating tests of this feature practically guarantees that the tests will fail daily.  Similarly, a feature that is still in progress will have many changes that will cause you to make frequent code changes in your tests.  It's better to keep testing the feature manually and reporting bugs on it until it becomes more stable.


  • DO automate things users will do every day.
What is the primary function of your software?  What is the typical path that a user will take when using your software?  This is the kind of thing that should be automated.   Rather than running through this manual path every morning at 9 AM, you can set your automated test to do it at 8 AM and you'll know right away if there is a problem.  


  • DON'T automate weird edge cases.
There will always be bugs in software, but some will be more likely to be seen by users than others.  You may be fascinated by the bug that is caused by going to a specific sequence of pages, entering non-UTF-8 characters, and then clicking the Back button three times in a row, but since it's very unlikely that an end-user will do this, it's not worth your time to design an automated test for it.

Monday, April 1, 2013

Why Automate?

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.
When I'm manually testing, I tend to follow a written plan and add in a few ad hoc tests as well.  But when I'm writing an automated test, I need to think about why I'm running the test.  The test engine will not be exploring, so I'm going to need to tell it to do something very specific.  What are the minimum steps required to ensure that the feature works?  Will I need to vary those steps for broader coverage, and what will be the most efficient way to do that?

  • It helps you to understand your development team.
Before I started writing automated tests, I knew a bit about coding from my college courses, but I'd never had real hands-on experience.  Using an IDE and writing in Java helped me have more sympathy for what developers go through in order to code, and it also taught me how programs are structured and how the build process works.  This has helped me become a better tester.


The path to learning automation won't be easy, but it will teach you important skills, streamline your testing process, help you understand the development life-cycle, and improve your thinking about your tests.

The Power of Pretesting

Having been in the software testing business for a few years now, I've become accustomed to various types of testing: Acceptance Testing...