By Angel G. Terrera
As systems grow, the generation of manual test cases is a task that becomes more difficult and more expensive. Therefore, it is especially important to use techniques for test case automation from previously selected best candidates if we want to meet market standards and deliver on time.
When selecting candidate test cases for automation, two different stages of software testing areas should be identified:
-
- An area that hasn’t yet begun to automate their testing efforts.
-
An area that has implemented automation projects and intends to walk the path of continuous improvement.
These two different stages reflect the maturity of the area that selects possible candidates for test case automation.
For areas of type A, a range of possibilities is available:
- Identify and recognize the candidate casuistry from certain defined criteria.
- Register the candidate casuistry in a tool for further monitoring, control, and update.
- Manage the execution of the generated scripts on the basis of the selected candidates scenarios or integrate them with other tools that can run them.
Areas of type B encounter another range of possibilities. They should recognize from the already automated processes those test scenarios that, according to their characteristic or outcome, should begin to be “separated” as best candidates for continuous performance improvement.
Here are some factors that should be considered when selecting candidates for automation, depending on the type of scenario that has to be tested:
-
- Automation Tool: The tool must be able to withstand the technology on which the application was built.
- Time available for testing: Automating from scratch takes twice the time than making the script for manual testing.
- Frequency of use of the application: Before carrying on automation efforts we should know if the application will be used constantly, sporadically, or just once.
- Complexity of the application: If the application is fairly complicated we will have to evaluate certain candidates cases because the initial effort for automation is too high.
- Stability and Variability version: We should consider automation if we have a stable version of updates, without underestimating its variability.
- 100% Automation: Will depend on how much human intervention the test scenario possesses.
- Main flow: Identify, recognize, evaluate the main scenarios and their respective priority conditions (critical, important, urgent) that align the main business rules.
- Avoid automating everything: The most common mistake is trying to automate all test cases. Automation scripts should be a support for manual testing and not a replacement of it.
- Evaluate combination III and VII: It refers to test cases linked to the core of the application that can be built at the beginning of the project and which can then be used in the rest of the development cycle.
- Cost associated with automating test case: Assessing its complexity to decide whether to continue with the process of automation or go back to manual testing.
- Maintenance Project: Identify the history incident as a source of information.
- Think about the audience: Who will read and use the selected test cases?
- Types of Tests: Consider particular scenarios of certain types of Test Cases (UAT, Regression, Smoke).
- ROI: Return on Investment (ROI) for the business that each script has, specific to each company.
-
Number of steps and verification: The complexity is given by the number of steps (actions) and checkpoints (expected results) each of them has.
However, much will have to do with the type of project since the course of treatment is not the same for traditional (cascade) or agile projects.
Some positions related to assessing the best candidates state:
- Scenarios that cannot fail under any circumstances.
- Features that, if they were missing, would have a negative impact on the customer.
- The selection begins with cases that cover the main functionalities.
- Cases with average complexity of business; for example, not being too expensive to automate.
From the basis of this article, I will go a little deeper in the next one and explain more concrete situations.
Reference:
Content generated on the basis of the comments written by the members of the group TESTING & QA on LinkedIn.
Angel G. Terrera is the Founder of TestingBaires.com, a website dedicated to the promotion of software testing.
webmaster@testingbaires.com | www.testingbaires.com
https://www.facebook.com/testingbaires
https://twitter.com/testingbaires
ISTQB Certified Tester
No.12-CTFL-27832-HA
