So you want to create automated tests

Are you doing manual testing and want to break into automated testing? Are you doing something completely different and want to get a job in automated testing?

One of the problems of getting into a new field is finding someone to give you the time to learn. If you are working on a team of manual testers they often hire someone else to write automated tests. As they write the automated tests there are less and less things you need to test but how does this get you closer to being an automated tester?

The answer is that as the automated test suite grows they will need more people on that team to help maintain and create automated tests. But what if they decide to hire someone new and let you go? Why wouldn't they do that? The truth of the matter is, if you are a good employee they won't WANT to let you go unless necessary. You need to make it unnecessary. You need to learn to become an automated tester.

Another scenario is that everyone is manually testing the project and there is absolutely no plans to do test automation. Maybe the manager tried test automation and it was a huge failure. What would happen if you could automate things and it was a big success? How do you think your manager would feel about you? Pretty good I suspect.

So how do you do it? Set something up at home and start playing. The most important thing is understanding WHY. If you do something and it works but you don't know WHY then when if fails you won't be able to fix it because you never knew why it worked before and doesn't now.

What will you need?

1. An automated test language
2. A development environment
3. Source control
4. Something to test
5. Knowledge of what to test

I'll cover everything but the last point here. What test cases you need, how to create them is a whole set of blog entries.

First, you need to know what automated test language you are going to use. You could use SQA Basic... if you had a few thousand dollars. This is the language used for IBM/Rational Test Studio. If you can afford this then you have the development environment as well.

I suspect you are looking for something FREE. Best thing to do is use open source tools. A good starting point for this is http://sourceforge.net/. There are hundreds if not thousands of projects here. Some haven't been active for years and some are used by companies today. You can search the job ads to see what tools they are hiring for. If they are hiring for say Selenium then there is a good chance that your company could use Selenium as well.

Different open source test automation tools will use different languages. It is usually best to pick a language that is already a programming language. For example, Selenium can be used with Java, Ruby, Perl, C#, etc. or Watir is only Ruby and Watij is only Java.

If you search for "automation" you'll get 720 projects. If you search for "test automation" you'll get everything with test, automation and test automation. It actually gives you thousands of projects. You can also try to browse the projects using the "Find Software" link. From there go to Development, Testing but you'll still get 1782 projects. Finally, use the Filter button to narrow things down. You can keep adding filters. So for me, I'd want Language 'Java', Operating System 'OS X'. This gets me down to 17 projects. From there I'd scan them by hand. You might also want to filter for Development Status. Go for Production/Stable or Mature. You don't want to be dealing with bugs in the test tool while trying to find bugs in your application.

If you are going into automated testing for a web site I can tell you that Watij, WatiR, Selenium are very popular choices right now.

Once you have done some research and know which automated test tool you want to learn you'll need a development environment. If you select C# you are probably looking at buying Microsoft Visual Studio however there are cut down, FREE, versions on the Microsoft website. You just need to hunt for them.

If you select a tool which uses Java, Ruby or Perl you had a wide variety of development environments to select from. I'm currently using Java. I've always like NetBeans but more companies want people with Eclipse knowledge, so I'l using Eclipse.

A good development environment is essentially an editor, project management and a debugger. A project manager to organize all the files, an editor to create the files and a debugger to maintain the files.

Next is source control. What is source control? If you have done any programming you have probably done this:

• Create a small program
• Add some features to it
• Find a problem
• Try to fix it
• Try something else
• Try something else
• Try something else
• Realize you are missing a semicolon, or quote or something simple

Now you are trying to remember all the "try something else" things you did so you can get back to the original code before you made it worse. Ideally, you want to get back to before all the 'try something else' then fix the 'something simple'.

Next time, you write a small program, run it and it works. Let's say the file is called MyProg.java. Before you try to add some more features you copy the file. So now you have MyProg.java and a backup called MyProg1.java. After a few days you have everything from MyProg1.java to MyProg47.java.

You add another feature and it totally breaks the program. You do a lot of "try something" only to realize it was a simple fix. Now you can throw away MyProg.java, rename MyProg47.java to MyProg.java and do the simple fix.

You have created a very primitive source control system. There are much better server/client systems like CVS or Subversion. The way they work is you create a repository (a folder on your computer somewhere or on another computer). When you create a file, like MyProg.java, you add it to the repository. Now you have a back up in the repository. Every time you make a change you can add the change to the repository. At anytime, you can get a list of all the versions in the repository, you can add notes when you save the file and later look up the notes. The best part is you can tag a point in time. If you create 500 files and complete version 1.0 today, file 1 might be version 173, file 2 might be version 37, file 3 might version 1, file 4 might be version 28838, etc. you 'tag' all the files as VER1.0. Two months from now someone wants to add a patch to version 1.0. You have made changes to many files. You can ask source control for all versions tagged with VER1.0. It will restore the system to just like it is today. This way I can have one project for current and one project for past projects. Current project is new features, past project is bug fixing.

If you are using a Mac OS X computer you have CVS built in. You can also download Subversion (SVN) and install it. These source control systems are open source so you don't have to pay for them. CVS was very good but SVN is newer and used by more new projects.

So go out and find Subversion. Download it and create a repository. There are tutorials on it out there so I'll leave that as an exercise for you to do on your own.

The final thing is something to test. Pick a simple web site and start automating it. If you have access to your test environment from work, you could start testing it right now. Otherwise, start automating something like http://www.google.com/