How will automation testing be different at all Software Testing Level?

Question

I have a few doubts about Automation Testing at each testing level, These question is being asked in an interview.

Test Level:-
1. Unit Testing 
2. Integration Testing
3. System Testing 
4. User Acceptance Testing

Here I have a few questions like:-

Q-1. Is Automation Testing possible at every level of the testing?  
Q-2. How will Automation Testing be different at all Software Testing Level? 
Q-3. What are the benefits of the Automation Testing at each level?

Please help me to deal with these questions.

Answer 1

Yes, there are options to automate all the levels of testing you refer to here.

Unit, Integration, and System testing can all be automated as part of the build process. In fact I'd be worried if automatic unit testing wasn't part of the build as a fundamental element. Integration and System testing are both open to automation (and preferably are) - use of API tests for example. All three of these levels should ideally be part of the standard development of the system, there are multiple tools and frameworks for this.

User acceptance testing can have a degree of automation - automated UI tests are entirely possible, using Selenium for example, however there is a big caveat on this one. Too heavy reliance on automated UI tests risks a product that meets all the business requirements on paper, but is a total PITA to use. I've seen LinkedIn as being quoted as a good example of this.

For everything up to UI testing, everything should be as automated as possible (with just code reviews/pair programming used as a non-automated form of checking/testing). At the UI level, a limited number of automated tests are useful for regression testing, but not for testing of new features or looking at useability and UX elements of the product.

Answer 2

These are really good questions.Here are my thoughts on it.

Automation testing can be done at every level, starting right from the requirements phase and all the way till the user acceptance and deployment phase. This is especially true in the current era of DevOps. DevOps has helped software development teams and operation teams to better collaborate, thereby ensuring there is constant automation and monitoring throughout the software development lifecycle (SDLC), which includes infrastructure management as well.

You may ask, how is this going to influence automation testing? The answer: Everything we do as part of testing is going to change. The changes I foresee include:

• A need to start automation right at the beginning of the SDLC and ensure nearly all test cases are automated
• All the QA tasks would need to be aligned to ensure a smooth CI/CD cycle
• A high level of collaboration would be needed to ensure there is continuous monitoring in the production environment All the QA environments would need to be standardized
• The testing mindset changes from “completed testing on this module” to “What are the business risks that have been mitigated in the release candidate?”

The key to all the above changes is automation. DevOps and automation go hand in hand—without one, the other won’t work. This is where smart people and tools can help in bringing shorter and more dependable release cycles.

As you can see Automation Testing is not only about writing code. There are various facets to test automation and writing code is only one aspect of it.

I have worked in companies where-

• In Unit Testing Level, We have automated unit tests that kicks off every time a code is checked into the branch to ensure the newly implemented features do not break existing features.This helps to find out issues like memory leaks, stale code, code vulnerabilities, buffer overflow issues apart from just ensuring whether the new code is working
• In Integration/System Testing level, we have our UI tests which run through different scenarios of our application. Usually this consists of Smoke Tests to ensure the major functionalities of the application is still workin, Regression Tests which ensure other features of the application is not affected by the new feature and also have feature level tests to ensure the new feature which is implement is working properly.

The Smoke Tests are usually run after every code check in. The regression tests are run once on a daily basis (usually at night), the feature level tests are run continuously till the story is deemed complete. After which, we push that to be part of our smoke or regression tests. It depends on the project and team

Apart from this we may also have API level tests which run in parallel to ensure the application is working as expected underneath the GUI as well

• In User Acceptance Testing, usually the Smoke Tests are run again and in parallel some high level manual testing is done as well

All these becomes more relevant as teams are trying to release faster by implementing seamless CI/CD pipeline. For this we need automation as well.

-Raj

Answer 3

Have a look at Microservice testing by M.Fowler. It is valid for non Microservice architecture too and gives good idea about different layers of testing.