What to be automated and what to be not

Automation of whole application, product, or process is not possible or one can say it is near to impossible to achieve 100% automation. So it is important to decide which test cases should be automated on High priority.

The main idea of Automating the test is to save the time of manual resources and how to increase the test coverage. So one should determine the test cases which are repeated very often and taking a large amount of data on the same set of actions like login of a screen. There could be any combination of testing the Login screen with a different set of data, which takes very much time for a manual tester. One should not automate the Test cases which take most of the Automation test engineer effort and time and in the future, that test script usage is very less.

One can get the most benefit out of your automated testing efforts by automating:

• Repetitive tests that run for multiple builds.
• Tests that tend to cause human error.
• Tests that require multiple data sets.
• Frequently used functionality that introduces high-risk conditions.
• Tests that are impossible to perform manually.
• Tests that run on several different hardware or software platforms and configurations.
• Tests that take a lot of effort and time when manual testing
When trying to automate the test cases, always try to make the modules independent and focused on an objective. By using this strategy, one can reuse the independent modules to run the test repeatedly

When to be automated:

Testing of a product or application is not sufficient in a single round as developers may change their code due to some previous bug fix or due to new enhancements to the application. In each and every build we need to test the same functionality number of times. A lot of manual effort is involved. To save the time and effort of manual effort, we will automate the test cases.

If we encounter the following question, then it’s the perfect time that we automated the test cases:

What if a programmer then changes the code and introduces a bug? What if I don’t catch that bug because I didn’t rerun the test after the change?

There are some scenarios in which one should think of automating the test:

• Both automation and manual testing are plausible. That’s not always the case. For example, load testing often requires the creation of heavy user workloads. Even if it were possible to arrange for 300 testers to use the product simultaneously, it’s surely not cost-effective. Load tests need to be automated.

What Technology should be used for Automation?

For some Automation tools, they used their own Scripting language like Rational Robot use SQABasic. Nowadays there are so many tools they used in global Scripting languages like RFT use .NET and Java.
Selenium used Ruby, Python, java,.NET, etc.

Choice of Automation tool?

Selecting an automated testing tool is essential for test automation. There are a lot of automated testing tools on the market, and it is important to choose the right automated testing tool that best suits your overall requirements.

Consider these key points when selecting an automated testing tool:

• Support for your platforms and technology. Are you testing .Net, C#, or WPF applications, and on what operating systems?
• Flexibility for testers of all skill levels. Can your QA department write automated test scripts or is there a need for keyword testing?
• Feature-rich but also easy to create automated tests. Does the automated testing tool support record-and-playback test creation as well as manual creation of automated tests; does it include features for implementing checkpoints to verify values, databases, or key functionality of your application?
• Create automated tests that are reusable, maintainable, and resistant to changes in the application’s UI. Will my automated tests break if my UI changes?
• Support for Cross-Platform or cross-OS test support of the tool
• Good Support with the AUT.
• Testing Multi-Language Applications
• Automated Testing Tool: Support for Team Work
• Command-Line and OLE Automation Support
• Integration with Team Systems and Build Software
• Technical Support
• Pricing Policy
• Free Trial Versions

Now once the tool gets selected, the primary focus of the Automation test Engineer is to set up the Automation framework. It should be Tool Independent. One can create an Automation framework in ASP.Net or java. The framework should be user-friendly and independent of AUT. One Automation framework could be used for multiple applications. As in our product Eloquence, we are using ASP.Net for our Automation framework Webpage. This is completely independent of Automation Tool.

I can run my test from the Automation framework Webpage without opening the Testing Tool (RFT in My case).