Automation QA Interview Questions

Making the jump from a Manual and into a Technical QA role can be difficult and challenging. Here are some potential automation QA interview questions which you may be asked during an interview.

Automation QA Interview Questions

What are the core positive features of an Automation Framework?

Building an automation framework can become a dangerious journey if key features are not considered before putting pen to paper. Before buliding a framework, some of the most important factors to consider include:

  • Speed
  • Maintenance
  • Modular
  • Debug / Error
  • Configurable

It is important that you are able to run all your tests quickly. Some solutions include running tests in parallel or running tests against different browsers.

Being able to maintain a framework can mean the difference between extending it or removing it. If it becomes difficult to maintain a framework, it then has the potential to become an overhead instead of adding value.

Switching out technologies and replacing them in a framework provides the flexibility to update frameworks more easily. For instance, being able to switch out testing libraries makes a framework more stable. Other examples include being able to change reporting of results.

Debug / Error
A automation framework is next to useless if you are not able to debug the code or tell what the errors are if a test fails. It help debug, writing clean and understandable code helps. Writing meaningful assertions also helps to identify sources for failed tests.

A given test becomes more versatile if it is possible to run a given test against different environments. However, the control of where the test run’s should not be governed in the test itself. Being able to change the test run location, the host to talk to etc via configurations helps to configure tests. This also can helps to scale an automation framework.

Can you name any disadvantages to E2E Automation Testing?

E2E Automation testing is great to check functionality. It is however poor in the following areas:

  • UI changes
  • Exploratory Cases

UI Changes
An automated test will not be able to test to see that the color of a button is correct, the placement of a field is correct, animations are correct etc. Features such as this can not be tested through traditional E2E Automate.

Exploratory Cases
This is a given, an automated test will only run the scenario which you have written. This means that it will not be able to explore your application and randomly test scenarios. This is where Manual Testing plays a big part. I mention this as there are a number of people who assume automated tests are the replacements to Manual testing.

How do you decide what manual test to automate?

The answer to this can be simple. A manual test becomes a candidate for automation when:

  • It does not have any external dependencies
  • It needs to run very often

Is Automation a replacements for Manual Testing?

No. An automated test simply replaces a scenario which would have been executed manually. An automated test however does not have the ability to explore an application and find bugs outside of automated scenarios. For this reason, automated tests are not a replacement for manual testing.

What tests should not be automated?

Here is a list of tests which should not be automated:

  • Test’s which only run once
  • UI based tests to check for colors, element placements, element size etc

How do you mark the success of an Automated test?

In order to mark an automated test as success, you can apply the following metrics:

  • High success rate of passing (95%+), low failure rate
  • Captured valid bugs