- By Shoaib Khan 23-Jan-2023
- 354
Automation is an integral part of a testing cycle and it is very important to decide what we want to achieve with automation before we decide to automate.
How to Decide Best Automation Cases?
Automation is an integral part of a testing cycle and it is very important to decide what we want to achieve with automation before we decide to automate.
The benefits that automation seems to provide are very attractive, but at the same time, an ill-organized automation suite can spoil the entire game. Testers may end up debugging and fixing the scripts most of the time resulting in a loss of testing time.
This series explains how an automation suite can be made efficient enough to pick up the right test cases and yield the right results with the automation scripts that we have.
Also, I have covered the answers to questions like When to automate, What to automate, What not to automate, and How to strategize automation.
Right Tests for Automation:
The best way to tackle this problem is to quickly come up with an “Automation Strategy” that suits our product.
The idea is to group the test cases so that each group will give us a different kind of result. The Illustration given below shows how we could group our similar test cases, depending on the product/solution that we are testing.
#1) Make a test suite of all the basic functionality Positive tests. This suite should be automated, and when this suite is run against any build, results are shown immediately. Any script failing in this suite leads to S1 or S2 defects, and that build specifically can be disqualified. So we have saved a lot of time here.
As an additional step, we can add this automated test suite as a part of BVT (Build verification tests) and check the QA automation scripts into the product-building process. So when the build is ready testers can check for the automation test results, and decide if the build is suitable or not for installation and further testing process.
This clearly achieves the goals of automation which are:
- Reduce testing effort.
- Find Bugs at earlier stages.
#2) Next, we have a group of End to End tests.
Under large solutions, testing an end-to-end functionality holds the key, especially during the critical stages of the project. We should have a few automation scripts that touch upon the end-to-end solution tests as well. When this suite is run, the result should indicate whether the product as a whole is working as it is expected or not.
The Automation test suite should be indicated if any of the integration pieces are broken. This suite need not cover each and every small feature/functionality of the solution but it should cover the working of the product as a whole. Whenever we have an alpha or a beta or any other intermediate releases, then such scripts come in handy and give some level of confidence to the customer.
To understand better let’s assume that we are testing an online shopping portal, as part of the end-to-end tests we should be covering only the key steps involved.
As Given Below:
- User login.
- Browse and select items.
- Payment Option – this covers the front-end tests.
- Backend order management (involves communicating with multiple integrated partners, checking stock, emailing the user etc) – this will help the testing integration of individual pieces and also the crux of the product.
So when one such script is run it gives confidence that the solution as a whole is working fine.!
#3) The third set is the Feature/Functionality based tests.
For example, We may have the functionality to browse and select a file, so when we automate this we can automate cases to include the selection of different types of files, sizes of files, etc, so that feature testing is done. When there are any changes/additions to that functionality this suite can serve as a Regression suite.
#4) Next on the list would be UI-based tests. We can have another suite that will test purely UI-based functionalities like pagination, text box character limitation, calendar button, drop downs, graphs, images, and many such UI-only centric features. Failure of these scripts is usually not very critical unless the UI is completely down or certain pages are not appearing as expected!
#5) We can have yet another set of tests that are simple but very laborious to be carried out manually. Tedious but simple tests are the ideal automation candidates, for example entering details of 1000 customers into the database has a simple functionality but is extremely tedious to be carried out manually, such tests should be automated. If not, they mostly end up getting ignored and not tested.
