Test Automation Basics

One of the standard issues every test manager faces, is to have a proof of what is tested and what is not. If I have 300- 400 test cases, I am in full control. But if I have 5000 odd test cases how do I know that the 3617^th test case is executed or not ? I trust my testers. Imagine I need to test 200 test cases in 3 different browsers, it multiplies my effort. I can not have 3 testers to do it in three different browsers, nevertheless it must be done. When I need some testing to be done on some critical builds, I do not know, on that day my tester gets illness. He does not turn up to work! My client is waiting to get the status. Oh, what a mess!

4 to 6 weeks from the day of first test execution cycle, my testers get bored of the test cases. Their eyes are not as sharp as before. They feel tired. But they want salary revision! One of my testers claim that he has done 80 test cases since morning I am more than 100% sure that he could not have done that much. How can I be assured of some one did it or did not do it?

The one best answer is automation. Instead of manually executing the test cases, do the testing using a tool. This can solve all the above mentioned problems. Tool never gets tired, tools never get bored, they do not ask salary revisions, they are fast, they do not apply leave and they are consistent!

Before doing any automation test, we must carry out a small proof of concept (POC) or a feasibility study of automation tool on our application. This may take from 4 hours to 8 hours. But this can solve a lot of issues that will be faced  by the team at a later time.

When it comes to test automation, a tester becomes a developer of automated test scripts. This means, the tester generates code using the tool to test the application. There are a variety of tools available in the market. QTP by HP, SilkTest by Borland, Rational Functional Tester by IBM, TestComplete by SmartBear, Selenium, Ranorex etc. are a few to name. Some tools work only on browser based web apps, some work on only rich/thick clients app and some work on both. But all these tools use the UI of the application to run tests. The human tester uses the UI to carry out functional tests and these tools do the same. Instead of human doing a click, the tool clicks on a button, instead of human typing, the tool mimics the key strokes.  

The following are the most common features that almost all tools share.

1. Recording (Capture test steps)
2. Replaying  (Playback test steps)
3. Object Identification (knowing the forms and fields attributes on screen)
4. Data Driven Test (use same steps with different data sets)
5. Check points (Verification points, compare the actual results to expected results)
6. Scripting (use a programming language to add intelligence to test scripts)
7. File and Database handling (if results are stored on disk)
8. Exception handling (recovery path when test script itself fails)

You need to think of test automation if you say Yes to one or more of the following points.

1. The number of test cases for my product is large and I have many regression rounds
2. My application is a product and not just a 4 months project
3. My product needs to be tested on multiple environments for compatibility
4. My product is being used by 1000s of customers and we cannot have a single regression issue
5. I test my product very frequently, almost everyday
6. My team costs me more and more and project bleeds for profitability

In the coming sections, we will discuss more about each of the automation features, in detail.