Baseline a Script

Once you've decided what you're testing, you should baseline a script as mentioned above, using Robot's record-and-playback feature to do as much of it as you can. This is the feature I use the most, at the start of nearly every new project. It's the fastest way to baseline what I'm doing, and it gives me most of the information I'll need about the application I'm testing.

Using the record-and-playback feature may be tricky, though, depending upon the language in which your application-under-test was written. A full list of the programming languages it supports can be found in the user documentation for the test suite you're using. I've worked with the record-and-playback feature in Java and C++ and find that it works well for most standard objects, and it does a good job on Web pages, but it may have problems when processing custom controls. I don't know of any software groups that use only standard controls, so you may run into this kind of problem, too.

Remember that developer you were sure to include in your group? Now is when she or he can be most useful. The developer needs to interface with your development team and, if necessary, Rational Technical Support to work out a solution to scripting your custom controls. More often than not, it will simply mean adding a property along with custom SQA Basic code to one of the libraries in your Rational project.

Look for Ways to Modularize Your Script

Now that you have your baseline script, grab a good software architect - or your team of testers and a large whiteboard. Start looking through the code in the script for repetitive SQA function calls, sets of function calls, or other common actions. What you're doing is looking for ways you can modularize your script.

Ideally, you want to optimize your script so that maintenance is as easy as possible. I've found that I've never regretted spending too much time developing a powerful and robust script, and I've often kicked myself for taking shortcuts in development. A script will cost you more to maintain than it will to create, unless you develop the script just as you would the software it's testing. Do it right the first time and reap the rewards in all of the following iterations of the project.

After you've planned out what modularization you can do, implement it using the SQA Basic libraries. Create as many different libraries as necessary. More than likely, you'll carry these over to following projects, and they'll evolve and change as you do this. I always find it helpful to wrap as many SQA Basic functions as I reasonably can. (To wrap an SQA Basic function is to create a library function that calls the SQA Basic function.) This comes in handy when you need to work around a bug later on down the road.

Document Everything

Document why you designed things the way you did. Document what each library does, and what each function in it does. All of this documentation is useful as training material or for future reference, and it helps you keep track of lessons learned. I document as much as time allows. Sometimes I get it all, and sometimes I can't document anything. I've never regretted documenting any information, but on more than a few occasions I have regretted not having any clue about how something worked or why I made a certain decision on a project I'd been away from for a couple of months. Sometimes documentation is the only thing that can save project scripts that no one has worked on in a while.

Use Datapools

Last but not least, use datapools in your testing. Effective and cost-efficient automated testing is data-driven. Keith Zambelich's whitepaper "Totally Data-Driven Automated Testing" is a must-read for anyone doing automated testing. Data-driven testing simply means that your test cases and test scripts are built around the data that will be entered into the application-under-test at runtime. That data is stored by some method and can be accessed by some key used in your scripts.

What this means in terms of the Rational tools is that you'll create datapools using TestManager (be sure you learn how to do this when you go through the tutorial or when you attend a Rational seminar) and your Robot scripts will then contain links to these datapools. At runtime your scripts, using keys designated when you created the datapools, will access the datapools and populate the application-under-test using the data found there.

This method offers the greatest flexibility when it comes to developing workarounds for bugs and performing maintenance, and it allows for the fastest development of large sets of test cases. After your first few projects, you may choose to use some method other than datapools, such as Excel or a database. When you're starting out, though, TestManager's datapools are the easiest and fastest tool you'll have available. They're simple to use and understand, and they give you the power to create data-driven tests right out of the box.

A Review of the Road Map

Even if you follow all the steps above, you'll still struggle the first time you attempt automated testing. Just remember to follow this road map and you should survive:

• Only use TestManager and Robot.
• Have at least one real programmer in your testing-automation group.
• Develop standards for your team.
• Figure out and document what you're testing, and keep it simple.
• Use Robot's record-and-playback feature to baseline your scripts.
• Modularize and build reusability into your scripts. Write wrappers around most functions and put them in libraries. Call wrapped functions whenever possible.
• Document everything you're doing to the greatest detail as time allows.
• Use a data-driven testing technique (a.k.a. datapools).

Remember, the way you automate your testing will change as you include more of the Rational tools, get more experience with them, and read about more complex and innovative ways of using them. TestManager and Robot should be your biggest investment if you develop traditional desktop software. If you develop real-time or embedded applications, you'll quickly move away from these tools. If you do more performance testing or Web testing, your focus will shift as you include the other tools in your Rational Suite. But regardless of what kind of automated testing you do, TestManager will likely be included, and Robot is useful more often than not.

References

• "Totally Data-Driven Automated Testing" by Keith Zambelich (Automated Testing Specialists Web site)