Automation Testing

We know that every project has three important aspects such as Quality, Cost & Time. The objective of any project is to get a high-quality output while controlling the cost and the time required for completing the project.

What is Automation Testing?

If a software can do anything then, why can’t a software test a software?

Does this statement sound logical to you?

If yes, then congratulations, you are now thinking about Test Automation, which is the center point that we are going to discuss in this series of informative tutorials.

Imagine yourself n the first day at your job as an SQA. You are presented with an application to be tested. It’s an ERP application containing 100s of forms and thousands of reports. You begin your exploratory testing by opening a form which contains around 50 different fields.

You try to enter random data in this form which took around 20 minutes. Then you press submit. Wolla!! An error message is shown which looks like an unhandled exception. You become very happy. You proudly note down the steps and report the bug in your bug management system. Great effort, you feel really confident and energetic. You continue the testing until the day ends and find some more bugs. “Amazing first day”, you thought.

Now comes the next day, the developer has fixed the issue and releases a new version of the build. You test the same form with the same steps and you found that the bug is fixed. You mark it fixed. Great effort. You have contributed to the quality of the product by identifying that bug and as this bug is fixed, the quality is improved.

Now comes the third day, a developer has again released a newer version. Now you again have to test that form to make sure that no regression issue is found. Same 20 minutes. Now you feel a little bored.

Now imagine 1 month from now on, newer versions are constantly releasing and on every release, you have to test this lengthy form plus 100 of other forms like this, just to make sure that no regression is there.

Now you feel angry. You feel tired. You begin to skip steps. You fill around only 50% of the total fields. Your accuracy is not the same, your energy is not the same and definitely, your steps are not the same.

And one day, the client reports the same bug in the same form. You feel pathetic. You feel unconfident now. You think you are not competent enough. Managers are questioning your ability.

Regression issues are the most painful issues. We are humans. And we cannot do the same thing with the same energy, speed and accuracy every day. This is what machines do. This is what automation is required for, in order to repeat the same steps with the same speed, accuracy and energy as they were repeated the first time.

Whenever such a situation arises, you should automate your test case. Test automation is your friend. It will help you to focus on new functionality while taking care of the regressions. With automation, you can fill that form in less than 3 minutes.

The script will fill all the fields and tell you the result along with screenshots. In case of failure, it can pinpoint the location where the test case failed, thus helping you to reproduce it with ease.

Difference between Manual Testing & Automation Testing (Automation Testing Vs Manual Testing)?

Let’s see the difference between Automation and Manual Testing.

Automation Testing Vs. Manual Testing:

Automated Testing Pros and Cons

Advantages of automated testing

• Automation is faster in execution then manual testing

• It is cheaper compared to manual testing in the long run

• Automated testing is more reliable

• Automated testing is more powerful and versatile

• It is mostly used for regression testing

• It is reusable because the automation process can be recorded

• Automation does not require human intervention. Test scripts can be run unattended

• It helps to increase the test coverage

Disadvantages of Automated Testing

• It is recommended only for stable products

• Automation testing is expensive initially

• Most of the automation tools are expensive

• It has some limitations such as handling captcha, getting visual aspects of UI such as fonts, colour, sizes etc.,

• Huge maintenance in case of repeated changes in the requirements

Not all the tools support all kinds of testing. Such as windows, web, mobility, performance/load testing

When to use Automation Testing?

We do Automation testing in the following areas:

1. Regression Testing

Repeated testing of an already tested program, after modification, to discover any defects introduced or uncovered as a result of the changes in the software being tested or in another related or unrelated software components. So, regression testing is best suitable for automated testing because of frequent code changes and it is beyond the human capacity to execute tests in a timely manner.

2. Load Testing

It is to verify that the system/application can handle the expected number of transactions and to verify the system/application behaviour under both normal and peak load conditions. Automated testing is also the best way to complete the testing efficiently when it comes to load testing. It is best suited for automation testing.

3. Performance Testing

This type of testing determines or validates the speed, scalability, and/or stability characteristics of the system or application under test. Performance is concerned with achieving response times, throughput, and resource-utilization levels that meet the performance objectives for the project or product. It is best suited for automation testing.

The tests which can be done through automated or manual approach:

1. Integration Testing

Integration Testing is the process of testing the interface between the two software units. Integration testing is done by multiple approaches such as Big Bang Approach, Top-Down Approach, Bottom-Up Approach, and the Hybrid Integration approach.

2. System Testing

Testing the fully integrated application to evaluate the system’s compliance with its specified requirements is called System Testing AKA End to End testing. Verifying the completed system to ensure that the application works as intended or not.

3. Unit Testing

Unit Testing is also called Module Testing or Component Testing. It is done to check whether the individual unit or module of the source code is working properly. It is done by the developers in the developer’s environment.

4. Acceptance Testing

It is also known as pre-production testing.  This is done by the end-users along with the testers to validate the functionality of the application. After successful acceptance testing. Formal testing conducted to determine whether an application is developed as per the requirement. It allows the customer to accept or reject the application. Types of acceptance testing are Alpha, Beta & Gamma.

Automation – A Cost-effective Method for Regression Testing

Automation costs are really higher initially. It includes the cost of the tool, then the cost of the automation testing resource and his/her training.

But when the scripts are ready, they can be executed hundreds of times repeatedly with the same accuracy and rather quickly. This will save many hours of manual testing. So the cost gradually decreases, and ultimately it becomes a cost-effective method for Regression testing.

Scenarios which require Automation

The above scenario is not the only case when you will need automation testing. There are several situations, which cannot be tested manually.

For Example,

1. Comparing two images pixel by pixel.

2. Comparing two spreadsheets containing thousands of rows and columns.

3. Testing an application under the load of 100,000 users.

4. Performance Benchmarks.

5. Testing the application on different browsers and on different operating systems in parallel.

These situations require and should be, tested by tools.

So, when to automate?

This is an era of agile methodology in SDLC, where the development and testing will go almost in parallel and it is very difficult to decide when to automate.

Consider the following situations before stepping into automation

• The product may be in its primitive stages, when the product does not even have a UI, at these stages we must have a clear thought on what we want to automate. The following points should be remembered.

• Tests should not be obsolete.

• As the product evolves it should be easy to pick on the scripts and add on to it.

• It is very important to not get carried away and ensure that the scripts are easy to debug.

• Do not attempt UI automation at the very initial stages as UI is subjected to frequent changes, thereby will lead to scripts failing. As far as possible opt for API level/Non UI level automation until the product stabilizes. API automation is easy to fix and debug.

How to Decide Best Automation Cases:

Automation is an integral part of a testing cycle and it is very important to decide what we want to achieve with automation before we decide to automate.

The benefits that automation seem to provide are very attractive, but at the same time, an ill-organized automation suite can spoil the entire game. Testers may end up debugging and fixing the scripts most of the time resulting in loss of testing time.

This series explains you about how an automation suite can be made efficient enough to pick up the right tests cases and yield the right results with the automation scripts that we have.

Also, I have covered the answers to questions like When to automate,  What to automate, What not to automate and How to strategize automation.

Right Tests for Automation

The best way to tackle this problem is to quickly come up with an “Automation Strategy” that suits our product.

The idea is to group the test cases so that each group will give us a different kind of result. The Illustration given below shows how we could group our similar test cases, depending on the product/solution that we are testing.

Let us now dive deep and understand what each group can help us to achieve:

#1) Make a test suite of all the basic functionality Positive tests. This suite should be automated, and when this suite is run against any build, results are shown immediately. Any script failing in this suite leads to S1 or S2 defect, and that build specific can be disqualified. So we have saved a lot of time here.

As an additional step, we can add this automated test suite as a part of BVT (Build verification tests) and check the QA automation scripts into the product building process. So when the build is ready testers can check for the automation test results, and decide if the build is suitable or not for installation and further testing process.

This clearly achieves the goals of automation which are:

• Reduce testing effort.

• Find Bugs at earlier stages.

#2) Next, we have a group of End to End tests.

Under large solutions, testing an end to end functionality holds the key, especially during the critical stages of the project. We should have a few automation scripts that touch upon the end to end solution tests as well. When this suite is run, the result should indicate whether the product as a whole is working as it is expected or not.

The Automation test suite should be indicated if any of the integration pieces are broken. This suite need not cover each and every small feature/functionality of the solution but it should cover the working of the product as a whole. Whenever we have an alpha or a beta or any other intermediate releases, then such scripts come in handy and give some level of confidence to the customer.

To understand better let’s assume that we are testing an online shopping portal, as part of the end to end tests we should be covering only the key steps involved.

As Given Below:

• User login.

• Browse and select items.

• Payment Option – this covers the front end tests.

• Backend order management (involves communicating with multiple integrated partners, checking stock, emailing the user etc) – this will help the testing integration of individual pieces and also the crux of product.

So when one such script is run it gives a confidence that the solution as a whole is working fine.

#3) The third set is the Feature/Functionality based tests.

For example, We may have the functionality to browse and select a file, so when we automate this we can automate cases to include the selection of different types of files, sizes of files etc, so that feature testing is done. When there are any changes/additions to that functionality this suite can serve as a Regression suite.

#4) Next on the list would be UI based tests. We can have another suite that will test purely UI based functionalities like pagination, text box character limitation, calendar button, drop downs, graphs, images and many such UI only centric features. Failure of these scripts is usually not very critical unless the UI is completely down or certain pages are not appearing as expected!

#5) We can have yet another set of tests that are simple but very laborious to be carried out manually. Tedious but simple tests are the ideal automation candidates, for example entering details of 1000 customers into the database has a simple functionality but extremely tedious to be carried out manually, such tests should be automated. If not, they mostly end up getting ignored and not tested.

What NOT to Automate?

Given below are few tests which should not be automated.

#1) Negative tests/Failover tests

We should not attempt on automating negative or failover tests, as for these tests the testers need to think analytically and negative tests are not really straightforward to give a pass or fail result which can help us.

Negative tests will need a lot of manual intervention to simulate an actual disaster recovery kind of scenario. Just to exemplify we are testing features like web services reliability – to generalize it here the main aim of such tests would be to cause deliberate failures and see how well the product manages to be reliable.

Simulating the above failures are not straightforward, it can involve injecting some stubs or use some tools in between and automation is not the best way to go here.

#2) Ad hoc tests

These tests may not really be relevant to a product at all times and this may even be something that the tester could think of at that stage of project initiation, and also the effort to automate an ad-hoc test has to be validated against the criticality of the feature that the tests touch upon.

For example, A tester who is testing a feature which deals with compression/encryption of data might have done intense ad-hoc tests with the variety of data, file types, file sizes, corrupt data, a combination of data, using different algorithms, across several platforms etc.

When we plan for automation we may want to prioritize and not do exhaustive automation of all the ad hoc tests for that feature alone, and end up with a little time for automating the other key features.

#3) Tests with massive pre-setup

There are tests that require some enormous pre-requisites.

For example, We may have a product that integrates with a 3rd party software for some of the functions, as product integrates with any messaging queue system which requires installation on a system, setting up of queues, creating queues etc.

The 3rd party software could be anything and the setup may be complex in nature and if such scripts are automated then these will forever be dependent on the function/setup of that 3rd party software.

Pre-requisite include:

At present things may look simple and clean as both side setups are being done and all is fine. We have seen on numerous occasions that when a project enters the maintenance phase the project is moved to another team, and they end up debugging such scripts where the actual test is very simple but the script fails due to a 3rd party software problem.

The above is just an example, in general, keep an eye on tests that have laborious pre setups for a simple test that follows.

Simple Example of Test Automation

When you are testing a software (on the web or desktop), you normally use a mouse and keyboard to perform your steps. Automation tool mimics those same steps by using scripting or a programming language.

For Example, if you are testing a calculator and the test case is that you have to add two numbers and see the result. The script will perform the same steps by making use of your mouse and keyboard.

The example is shown below.

Manual Test Case Steps:

1. Launch Calculator

2. Press 2

3. Press +

4. Press 3

5. Press =

6. The screen should display 5.

7. Close Calculator.

Automation Script:

The above script is just a duplication of your manual steps. The script is easy to create and easy to understand as well.

What are Assertions?

The second last line of the script needs some more explanation.

Assert.AreEqual(“5”, txtResult.DisplayText,”Calculator is not showing 5);

In every test case, we have some expected or predicted result at the end. In the above script, we have an expectation that “5” should be shown on the screen. The actual outcome is the result that is displayed on the screen. In every test case, we compare the expected outcome with the actual outcome.

Same goes for automation testing as well. The only difference here is, when we do that comparison in test automation, then it is called something else in every tool.

Some tools call it as “Assertion”, some call it as “checkpoint” and some call it as “validation”. But basically, this is just a comparison. If this comparison fails, for E.g. a screen is showing 15 instead of 5 then this assertion/checkpoint/validation fails and your test case is marked as failed.

When a test case is failing due to an assertion then that means you have detected a bug through test automation. You must report it to your bug management system just like you normally do in manual testing.

In the above script, we have performed an assertion in the second last line. 5 is the expected outcome, txtResult. DisplayText is the actual outcome and if they are not equal, we will be shown a message that “Calculator is not showing 5”.

Automation Testing Tools

Some of the popular automation testing tools

• HP QTP(Quick Test Professional)/UFT(Unified Functional Testing)

• Selenium

• LoadRunner

• IBM Rational Functional Tester

• SilkTest

• TestComplete

• WinRunner

• WATIR