Automated Testing

Previously I worked on an IT company who adapted automated testing for their QA system. Once, I involved in writing a framework and setting up the environment for the automated testing. At that time I searched on the Google how people are usually doing it to gain a maximum productivity and scalability, and amazingly I can't found even one. I'm sure that there's some books which cover this issue, but anyway I managed to find a way to do that. And until now I don't know yet whether it's the best way or not but until now they haven't complain about anything.

Implementing automated testing would be something which can be helpful and reducing error rate, but at the same time it required more effort for setting up for the first time and maintenance in the future. Hence, it's not something which is generally used by everyone.

Simply said, don't plan to use automated testing unless you are sure that:

• the product is a GUI application
  
• the product's lifetime will last for more than 2 years,
• the product will require frequent releases ex: every 2 months,
• the company have a QA team,
• hmm... only that I can think of

There are some commercial or opensource softwares you can use for automated testing such as:

• Quick Test
• Test Complete
• Abbot (open source)
  
• iMacros
• IBM Rational Funtional Test (very expensive)
  
• get more on Wikipedia's List of GUI testing tools
  

Generally most of the softwares support various types of programming languages. What you have to do is to compile that software you're intended to test by including something called: "open application library". The intention of the library is to make the components property on the GUI forms become visible to the testing tool. For a web application, this compilation isn't needed because the HTML codes already have all of the properties.

What you'll have to do for setting up a testing environment for automation are:

1. Writing code for the automated test framework
   
2. Writing test cases
3. Setting up scenarios to fit test cases, including testing databases
   
4. Translating scenarios to automated testing codes
   
5. Writing scripts for doing a set of scenarios (one button test)
   

For number one, may I suggest that someone would never make an automation code by "recording" only because recording usually "mark" a GUI component by remembering its (x, y) position absolute to monitor screen. Later when the components' position change, or the automation being ran in a different monitor resolution, the code won't work anymore.

What I mean for number one is some code that will read some sort of text files, or xml files, or derived classes, and later interpreting them as the actions of:

• click button "A"
• insert "ABCD" in the text box "B"
• choose "EFG" in the combo box "C"
• click on a cell in the n'th row and n'th column of table "D"
  
• compare whether an error message popped up or not
• write error logs for every failed comparison

It's better to have the core read text files or xml files because later you can migrate to another testing tools without having to re-write all of the test cases. What you have to do is only to re-write mere the framework.

Framework absolutely has to be done by a programmer, because QAs mostly don't expert in writing codes and designing frameworks. While writing test cases and translate them into automated test scenarios are fully QA's job. One button test is optional, since it can be done manually by a QA to perform an automated session by a little effort only.

And database, you always have to have a set of blank database. So you can later compose a series of sequential scenarios and apply it to the blank database. And to start a new automated test session, database will be reverted back to the blank database condition.