There is a reason for each automated case. The argument may be to create sets of build verification tests to define the stability of the generic build. Sets of tests can consist of cases created in order to compose acceptance-level test sets or comprehensive test passes. But it is important to have a rational explanation of why you decided to do the specific test automated.
There are some general reasons for creating automated tests:
- If a specific action or set of actions are repeated oftentimes, it makes sense to automate them.
- If a specific case is of sufficiently high value, it is rationally to automate it.
- Often, performance and stability tests should be automated to improve their evaluations and characteristics.
- Frequently, application programming interface (API) is a starting point of automation because it is usually the first performed part of the new project.
- Automated testing can also be used to run massive arrays of input data, while their manual execution takes much time. For instance, consider a situation when you need to take all of the problematic situations, as well as their combinations, and enter all of them into every input field in order to verify the presence of script errors and to check expected outputs. This check can be performed only once, but a quick script that passes through all input data and check output can be more effective for solving this problem.
Before thinking about automation for your project, think about what platform the user is likely to use for your application. This information plays a huge role in the selection of automation tools for your application. Determine what languages are provided for your product and is it possible to add new ones to this list in the future. Some packages or tools may not support certain code pages, can have limitations in supporting languages of Far East countries, Double Byte Character Sets and Unicode.