Google News
logo
Automation Testing Interview Questions
Automation is any action that can reduce human efforts. Automation testing is a software testing strategy in which a tester programmatically runs the tests using a tool or a framework instead of manually going through the test cases and executing them one by one.
 
The primary goal of automated testing is to save time, effort, and money on repetitive tests that don’t change frequently.
UI tests : Ensure that the software uses a consistent user experience and no visual or graphical elements on the screen are broken.

Unit tests :
These are written by software developers and test a unit of code in isolation.

Integration tests : These test how well different software components work with each other.

Regression tests : Verify that the new code didn't break any existing functionality.

Performance tests : Ensure that the software won't crash and perform reasonably under heavy load or stringent conditions.
Automation testing is useful in the following scenarios :
 
* Regression testing : In case of a bug fix or new module implementation, we have to make sure that the already implemented or unchanged functionality is not affected. In this case, we end up running the regression test case multiple times.
 
For Example : After each change request or bug fix, after each iteration in case of incremental development approach, etc.
 
* Non-functional Testing : Testing the non-functional aspects of an application.
 
For Example : Load testing or performance testing, etc are very difficult for humans to track and analyze.
 
* Complex calculation checks or test scenarios that are prone to human errors.
 
* Repeated execution of the same tests : Sometimes, we have to run the same set of test case for a different set of data or after each build release or on multiple hardware, software or combination of both.
 
Automating the test cases in the above scenarios helps in achieving the speed of testing and minimizing human errors.
Automation in preferred in following some cases :
 
* Repetitive Tasks
* Smoke and Sanity Tests
* Test with multiple data set
* Regression test cases

Usually, the decision is based on the ROI (Return on Investment)
One should not automate in following cases

* When the Application Under Test changes frequently
* One time test cases
* Adhoc – Random testing
In the automation process, steps involved are :
 
* Selecting the Test tool
* Define scope of automation
* Planning, design, and development
* Test execution
* Maintenance
An automated test script is basically a short program which is written in a programming language to perform a set of instructions on an application. This is done to verify if the application is as per the requirements or not. When you run the script, it gives the test results as pass or fail based on if the application is working as per the expectations or not.
A test automation framework is a set of universal guidelines and rules used to produce beneficial results of the test automation activity. The automation framework brings together function libraries, test data sources, object details, and other reusable modules and methods. Automation framework makes testing consistent. Some of the guidelines are as follows :
 
* Rules for writing test cases
* Coding guidelines for creating test scripts
* Input test data templates
* Object repository management
* Log configuration
* Test result and reporting usage
Using automation framework available a lot of benefits like as :
 
* The framework enables consistency in testing. It provides a universal standard for testers to achieve the specific goals of their automated tests.

* Automation frameworks, when designed and implemented correctly, they deliver frequent and stable automated test code

* With a proper framework, the code is easier to maintain and reuse

* Even with limited knowledge of how the test case is set up, a tester can depend on the framework to refer to simple statements and implement the test cases with ease.
Linear Scripting Framework : It is a basic level test automation framework which is in the form of ‘Record and Playback’ but in a linear fashion. This type of framework is mostly used to test small sized applications.
 
Data-Driven Framework : It is used to create test automation scripts by passing different sets of test data. The test data which includes input, expected output and a result field are stored in files like CSV files, excel files, text files, XML files etc.
 
Modular Testing Framework : Here the testers divide the application into multiple small modules and create test scripts individually. These individual test scripts are combined to make larger test scripts by using a master script to achieve the required scenarios.
 
Keyword Driven Framework : In this framework, testers use a table format to define keywords or action words for each method. Based on the keywords specified in the excel sheet test, scripting is done and tests are executed.
 
Hybrid Testing Framework : As the name suggests, this framework is the combination of two or more frameworks mentioned above. It attempts to leverage the strengths and benefits of other frameworks based on tester’s requirements.
* Saves time and money. Automation testing is faster in execution.

* Reusability of code. Create one time and execute multiple times with less or no maintenance.

* Easy reporting. It generates automatic reports after test execution.

* Easy for compatibility testing. It enables parallel execution in the combination of different OS and browser environments.

* Low-cost maintenance. It is cheaper compared to manual testing in a long run.

* Automated testing is more reliable.

* It is mostly used for regression testing. Supports execution of repeated test cases.

* Minimal manual intervention. Test scripts can be run unattended.

* Maximum coverage. It helps to increase the test coverage.

* Automated testing is more powerful and versatile. Automation tools allow us to integrate with Cross Browser Testing Tools, Jenkins, Github etc.,
Manual Testing Automated Testing
A human executes the test cases one by one, without any software assistance. Tests are executed by a testing tool or framework, without human assistance.
Useful for non-repeatable tests that involve human ingenuity, participation, and domain experience. Useful for repeatable tests where the software feature under test doesn’t change frequently.
Good for accessibility and usability testing, as the tester can test the software from an end-user’s perspective. Good for testing regression issues to make sure that the software didn’t break after introducing new changes.
Can be slow and time-consuming, and subject to human errors and misjudgment. Since it’s run by a computer, automated tests are fast and free from errors, given that we are testing the right thing.
It’s possible to test the software in a randomized manner, also known as exploratory testing.  Exploratory testing is not possible in automated testing. 
UI problems and inconsistencies are easily spotted by a human tester. Unless it’s programmed for that, the automated testing cannot discover and report the UI problems.
It’s very difficult, rather impossible to test the software under extreme load to conduct performance testing. Performance testing can be easily done with automation testing. 
The tester doesn’t need prior programming knowledge.  To write automated tests, the tester needs to have prior programming knowledge. 
100% automation would be difficult to achieve because there would be many edge test cases and some cases that are executed seldom. Automating these cases which are not executed that often will not add value to the automated suite.
During planning phase of automation things which must be taken in concern are
 
* Selection the “right” Automation tool
* Selection Automation Framework if any
* List of In scope and out of scope items for automation
* Test Environment Setup
* Preparing Grant Chart of Project timelines for test script development & execution.
* Identify Test Deliverables
Advantages :
* Automation testing is faster in execution
* 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 does not require human intervention. Test scripts can be run unattended
* It helps to increase the test coverage

Disadvantages :
* 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, fonts, color
* 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
It’s not possible to automate CAPTCHA or ReCAPTCHA.
 
* CAPTCHA stands for Completely Automated Public Turing test to tell Computers and Humans Apart. The reason for creating a CAPTCHA is to control bots.
 
* If someone is capable of automating CAPTCHA then it means that the CAPTCHA is not able to tell computers and humans apart. So the idea behind CAPTCHA is failed.
 
* If someone is able to automate CAPTCHA then it’s not a CAPTCHA.
To automate an application which uses CAPTCHA, you have to consult your development team to provide a workaround.
 
* To keep the CAPTCHA static in your test environment
* To disable the CAPTCHA in your test environment
* By making CAPTCHA static in your test environment helps you to automate CAPTCHA by providing one specific value as a CAPTCHA on every run.
It depends on Test case scenario complexity and length. I did automate 2-5 test scenarios per day when the complexity is limited. Sometimes just 1 or fewer test scenarios in a day when the complexity is high.
Some of the good coding practices are :
 
* Naming standards should follow
* Comments should be added
* Place reusable functions in a separate file
* Avoid duplicate code
* Add appropriate assertions
The mapping criteria for successful automation testing are :
 
* Defect Detection Ratio
* Automation execution time 
* Time saved to release the product
* The decrease in Labour employed
* The decrease in overall costs
Browser automation is the technique of programmatically launching a web application in a browser and automatically executing various actions, just as a regular user would. Browser testing gives you the speed and efficiency that would be impossible for a human tester. Protractor, Cypress, and Selenium are some of the popular tools used in-browser testing.
 
Some of the activities performed in browser automation are as follows :
 
* Navigate to the application URL and make sure it launches
* Test the various links on the web page and ensure they are not broken. 
* Keep a record of the broken links on the page.
* Perform load and performance testing on your web application.

Launch multiple instances of the browsers with different test users and ensure that concurrent actions work as expected.
With web applications, you don’t know in advance which browsers your users will use. Hence, it’s crucial to test the web application or the website on multiple major browsers running on different operating systems.
 
Cross-browser testing is a type of browser automation testing where the tester verifies if the web application will work smoothly on different browsers. Some of the popular browsers include Google Chrome, Mozilla Firefox, Internet Explorer, Safari, etc. 

The goal of the cross-browser testing is to launch the application on various browsers running on different operating systems, e.g. Windows, Mac OS, Linux, etc., and verify that the application works as expected. The tester looks for the design/rendering issues, the functionality of the application, and device-specific functionality.
 
Though it can be typically, sophisticated tools exist that allow the testers to automate cross-browser testing. Some examples include Selenium Box, BrowserStack, Browsershots, LambdaTest, etc.
With web applications, you can’t guarantee the browsers/platforms/devices your users might use to access your software. Some users could be using Google Chrome on their Android phones, some might use Firefox on a Windows desktop machine, or others could use Safari on their Macbooks.
 
Cross-browser testing ensures that your web application works as expected on different versions of popular browsers on multiple platforms and devices. It ensures that the users get the same experience and features irrespective of which browser they use. It helps to reach a wide range of users, allows the users to switch browsers and devices, and still get the same user experience, increasing customer satisfaction and building a loyal user base.
Today as we are moving to the Agile mode, testing is not limited to the UI layer. Early feedback is imperial for an agile project. If we concentrate only on the UI layer, we are actually waiting until the UI is developed and available to test.
 
Rather we can test even before the UI is actually developed. We can directly test the APIs or the methods using tools like Cucumber and FitNesse.
 
In this way, we are giving the feedback much early and are testing even before the UI is developed. Following this approach will help us to test only the GUI aspect of small cosmetic changes or some validations on the UI and will help the developers by giving more time to fix the bugs.
The major hurdle for testers is to learn programming/coding when they want to automate. Since testers do not code, adapting to coding is a bit challenging for testers.
 
We can overcome it by :
 
* Collaborating with developers when automating.
* Considering that automation is the responsibility of the whole team and not only of the testers.
* Giving a dedicated time and focus on automation.
* Getting proper management support.

You can save these automation testing interview questions as a pdf and print for further reading.
Important modules of an Automation testing framework are :
 
Test Assertion Tool : This tool will provide assert statements for testing the expected values in the application under test. For Example. TestNG, Junit, etc.

Data Setup : Each test case needs to take the user data either from the database or from a file or embedded in the test script. Frameworks data module should take care of the data intake for test scripts and the global variables.

Build Management Tool : Framework needs to be built and deployed for the use of creating test scripts.

Continuous integration tool : With CICD (Continuous Integration and Continuous Development) in place, continuous integration tool is required for integrating and deploying the changes done in the framework at each iteration.

Reporting tool : A reporting tool is required to generate a readable report after the test cases are executed for a better view of the steps, results, and failures.

Logging tool : The logging tool in framework helps in better debugging of the error and bugs.
(i) Selenium : Selenium is a test framework for web application automation testing. It supports multiple browsers and is OS independent. Selenium also supports various programming languages like Java, C#, PHP, Ruby, and Perl, etc.
 
Selenium is an open-source set of libraries which can be used to develop additional test frameworks or test scripts for testing web-based applications.
 
(ii) UFT : Unified Functional Testing is a licensed tool for functional testing. It provides a wide range of features like APIs, web services, etc and also supports multiple platforms like desktops, web, and mobile. UFT scripts are written in visual basic scripting language.
 
(iii) Appium : Appium is an open-source mobile application testing tool. It is used to automate testing on cross-platform, native, hybrid and web-based mobile applications. Appium automates any mobile application from any language with full access to APIs and DBs from the test code.
 
Appium is based on the client-server architecture and has evolved from selenium.
 
(iv) Cucumber : Cucumber is an open-source behavior-driven development tool. It is used for web-based application automation testing and supports languages like ruby, java, scala, groovy, etc. Cucumber reads executable specification written in plain text and tests the application under test for those specifications.
 
For cucumber to understand the scenarios in plain text, we have to follow some basic syntax rules which are known as Gherkin.
 
(v) TestComplete : TestComplete is a licensed automated UI testing tool to test the application across different platforms like desktops, web, mobile, etc. It provides flexibility to record a test case on one browser and run it on multiple browsers and thus supports cross browsers testing.
 
TestComplete has inbuilt object recognition algorithm which uniquely identifies an object and stores it in the repository.
Automation testing is useful for regression, smoke or sanity testing. All these types of testing in the traditional waterfall model happen at the end of the cycle and sometimes if there are not many enhancements to the application, we might not even have to do regression testing.
 
Whereas, in agile methodology, every iteration requires executing the regression test case as some new functionalities is added.
 
Also, the regression suite itself keeps growing after each sprint as the functional test cases of the current sprint module need to be added to the regression suite for the next sprint.
 
Thus, Automation testing in agile methodology is very useful and helps in achieving maximum test coverage in less time of the sprint.
In this framework, the test cases are developed from modular scripts by combining them in the modular testing framework. Each of the test cases uses a driver script that uses a data file as in the data-driven framework and a keyword-based action file.
 
Advantages :
* Modular and easy to maintain.
* Less coding can take care of more test cases.
* One test case can be executed with multiple sets of data.

Disadvantages :
* Complex to read, maintain and enhance.
Assuming that the automation tool and framework is already in place of the test environment.
 
To test the basic “Login” functionality :
 
* Understand the project requirement : Login functionality will have a username textbox, a password textbox, and a login button.

* Identify the Test scenarios : For login functionality, the possible test scenarios are:
* Blank username and password
* Invalid username and password
* A valid username and invalid password
* Valid username and password

* Prepare a Data input file with the data corresponding to each scenario.

* Launch the tool from the program.

* Identify the username field, password field, and the login button.

* For each test scenario, get the data from the data file and enter into the corresponding fields. Program click on the login button after entering the data.

* Validate the error message for negative scenarios and the success message for positive scenarios in the test script with the help of assertions.

*
Run the test suite and generate the report.
Software is never done. The developers are constantly adding new features, functions, fixing bugs, and so on. There is a chance that all this new code might break the existing functionality that was working.
 
Users dislike using a product that is broken after they download and install a new release. They expect a consistent and reliable experience from the software, no matter which version they are using. They also expect that previously working features will keep on working and won't break in the future.
 
Regression testing is a testing technique where a tester makes sure that the new features didn't break any existing functionality. Its goal is to ensure that previously developed and tested functionality still works after adding new code. When a tester performs the regression testing automatically using testing frameworks and tools, it's known as automated regression testing.
 
In automated regression testing, a tester runs the suite of regression tests after each new release of the software. If the tests pass, then the tester continues with other types of testing. However, if it fails, then there is no point in further proceeding with tests until the developers fix the broken regression tests. Hence, they also act as a time-saver for the tester and ensure quality in software before shipping it.
Martin Fowler first proposed the concept of the test automation pyramid in 2012. It’s a technique to think about how you should use different types of test automation to get the maximum value out of them. 
 
The main idea behind the test pyramid is to have many unit tests and a few broad tests for the GUI.
Pyramid
GUI testing is very brittle. User interfaces are constantly changing. An enhancement to the software easily breaks up many tests, which need to be updated, causing additional work for the team. Testing the UI is slow and results in increased build times. You can perform it on a few machines on which you have the license for the GUI testing tool.
 
Hence, the test pyramid argues that you should have more automated unit tests than through the traditional UI-automation tests. It also has an intermediate layer of service tests that can provide many benefits of end-to-end UI tests without the complexities of dealing with the UI frameworks.
Some of the Test Assets and Extensions of QTP are :
 
* Results .xml
* Test batch runner .mtb
* Recovery scenario .qrs
* Local object repository .mtr
* Test file .mts
* Shared object repository .tsr
* Function library .qfl
As a team is supposed to be a single unit responsible for shipping a quality software system, it’s a team’s responsibility to write, execute, and manage test scripts. That means the developers and the QA should collaborate and use each other’s skills to perform automation testing effectively.
 
Each team has a different skill set. Some have more technical testers, some have quality-focused developers, and some have testers who came from development backgrounds and vice versa. Hence it’s not a good idea to pigeonhole automated testing to a particular department. Instead, collaboration and working together is the key to a successful automated testing strategy.
Automation testing is mostly a black box testing as we just program the steps that a manual tester performs for application under test without knowing the low-level design or code of the application.
 
Sometimes, automated test scripts need access to the database details that are used in the application under test or some more coding details and thus can be a type of white-box testing.
 
Thus automated testing can be both black or white box type of testing depending on the scenarios in which automation is performed.
Sikuli is a tool that uses “Visual Image Match” method to automate graphical user interface. All the web elements in Sikuli should be taken as an image and stored inside the project.
 
Sikuli is comprised of
 
* Sikuli Script
* Visual Scripting API for Jython
* Sikuli IDE

Practical uses of Sikuli is that
 
* It can be used to automate flash websites or objects
* It can automate window based application and anything you see on screen without using internal API support
* It provides simple API
* It can be easily linked with tools like Selenium
* Desktop application can be automated
* Sikuli offers extensive support to automate flash objects
* To automate desktop, it uses powerful “Visual Match” and Flash objects
* It can work on any technology-.NET, Java,
Automation testing isn’t a replacement for manual testing. No matter how good automated tests are, you cannot automate everything. Manual tests play an important role in software development and come in handy whenever you have a case where you cannot use automation. Automated and manual testing each have their own strengths and weaknesses. Manual testing helps us to understand the entire problem and explore other angles of tests with more flexibility. On the other hand, automated testing helps save time in the long run by accomplishing a large number of surface level tests in a short time.
Documentation plays a very important role in Test Automation. All the methods and procedures that you employ should be documented so that they are repeatable. Test specifications, designs, configurations, code changes, automation plan, test cases listed for automation, bug reports, user manuals should all be documented.
Ad hoc testing : Here testing is done without preparation and writing test cases. During ad hoc testing, a QA specialist randomly tests the functionality of the system; his aim is to be creative, “break” the system and discover flaws.

Exploratory testing : During exploratory testing, a QA specialist tests a product like an explorer, relying on his personal experience. After getting the idea of a product’s functionality, a tester designs test cases which he uses to further test the product. In exploratory testing, the tester needs to rely on his personal experience and design test cases in the testing process.

User interface testing : Here, a QA specialist validates the properties and states of interface elements. Also, they make sure that design elements in the interface match elements in the final layout.
The aim of data-driven automation testing is to simplify the testing process involving complex and huge data sets. In Data Driven Testing the test data includes input, expected output, and a result field. These fields are listed in files like CSV files, excel files, text files, XML files etc. These files are then fed to automation tool for execution, which in turn compares the expected and actual data. Then the obtained results are documented in the result field.
Modular : The framework should be adaptable to change.

Reusable : The commonly used methods or utilities should be kept in a common file which is easily accessible to all the scripts.

Consistent :
 The test suite should be written in a consistent format by following the coding practices.

Independent :
 The test scripts should be written in such a way that they are independent of each other.

Logging :
 It is good to have implemented the logging feature in the framework.

Reporting :
 Once the scripting is done, we can have the results and reports sent via email.

Integration :
 Automation framework should be such that it is easy to integrate with other applications
In TestNG, testing is based on Junit, but it designed to overcomes the limitations of JUnit. Some advantages of TestNG over Junit are :
 
* Annotations are easier to understand in TestNG
* In TestNG, test cases can be grouped easily
* TestNG supports parallel testing unlike in JUnit
Some of the risks involved with automation testing are :
 
* It demands killed resources with some knowledge about programming and the ability to adapt easily to the new technologies
 
* The initial cost for automation is too high
 
* If the user interface has ever-changing requirements, then automation testing will be problematic
 
* If the application that is being tested is not stable, you might encounter a lot of errors you might encounter a lot of errors
Irrespective of the choice of your automation tools like SilkTest, QTP, Selenium or any other test tool you can follow the following rules
 
Web UI testing :
* Have a unique name for every web page.
* Follow uniform naming scheme for similar objects.
* No two objects should have the same name.
* Every image should have an ALT attribute set.
* Dynamic content must have a proper name, ID or XPath.
* Data tables should have specific names.
* Cross-browser stability.

Web service layer (Rest/Soap) testing :
* API Request/Response verification.
* API error code testing.
* Web service XSD validation.
* Cross-server validation.