Automation in Testing: What is the best approach?

When you have to run regression testing on the same application many times, or when you are making small enhancements to the application and you, as a Test Manager, want to ensure that existing functionalities are not broken, you automate the application/solution so that the test cases can be repeated over and over again.

So is automation supposed to replace manual testing? The answer is both Yes and No.

How each organization uses automation depends on the application and what sort of coverage is required. When a project/development solution transitions through SDLC (Software Development Life Cycle) process, it is likely to have significant number of defects. This is where manual and exploratory testing are undertaken. As testing progresses, there is a likelihood that some of the solution may change as further clarifications are sought from business on defects raised by the test team. So it will take some time before a solution is considered stable. It is only at that point that automation process can be kicked off. So from that perspective, automation testing will not replace manual testing. Rather automation testing is kicked off only after solution/code has become stable.

There are two key elements required for automation: (1) Automation Tool (2) Automation environment or a lab.

When considering an automation tool, ensure that it aligns with the long term tool strategy of the organization. A Test Manager will look rather foolish if he procures a tool that is abandoned within the next 12-18 months because of non-alignment with the long term strategy.

Plan for a test automation lab, preferably using virtual machines. Upper management loves these type of initiatives as this demonstrates to the high up that the organization is working towards a strategic plan. Ensure that the lab is scalable and you c an easily extend it as automation footprint increases.

As automation footprint starts to mature and we have more confidence in the automation regression, automation effort can be moved to the left of the SDLC process. This is where automation can replace manual testing to some degree. For example, a project is initiated that will make changes to an existing application. Assuming that the application is already automated, we can make changes to the automation scripts as per the new business/functional requirements. This will allow the changes to be implemented in the scripts as soon as the Business Requirements Document (BRD) is made available. As such, we can run and therefore identify all if not majority of the defects via the automation run, even before formal SIT (System Integration Testing) kicks off. There will be some manual testing involved, but at this stage in SDLC, it is expected to be complimenting automation regression, not replace the complete run.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.