In the article below you will find information about automated software testing and related techniques.

What should be automated?

Asking: «What should be automated?», try to start by answering another question: «Is it necessary to perform automated testing in this project?» If your answer is «YES», make a plan of automated test development based on the requirements to be met by the test object.

We will not go into details describing how to automate this or that particular function, just provide below a list of the cases where automation is appropriate.

Therefore, automated testing is applied to:

1. Hardly accessible parts of the system (back-end processes, file logging, database recordings).
2. Routine operations like data search (when filling in multiple fields forms). Here you can automate the procedure of filling in the fields and their validation after saving.
3. Validation messages. Here you can automate the procedure of filling in the fields of the form by submitting incorrect data and checking if they are validated or not.
4. Long end-to-end scripts
5. Data validation requiring accurate mathematical calculations
6. Data search validation and many other things depending on the requirements to the system you test and the testing tool you choose.

How to choose the automated testing tool

The choice of the tool often depends on the test object and the requirements to be met by the test scripts, as testing tools cannot support all the existing application development technologies. In other words, the tool is selected by means of trial and error. As a result, sometimes developers may select several testing tools. For example, GUI is tested using Mercury WinRunner, back-end processes are tested with the help of “java-based test tools” or other tools.

Three levels of test automation

Conditionally you can divide the application to be tested into three levels:

• Unit Tests Layer
• Functional Tests Layer (Non-UI)
• GUI Tests Layer

To ensure the better quality of the product it is recommended to automate all the three levels. Let’s consider now the test automation strategy based on the three-level model more in detail:

Unit Test Layer Level

At this level, automated tests are Unit Tests, written by the developers. Here it is also possible to write code verification tests provided that the developers are skilled enough to cope with the task. This kind of tests alongside with other newly developed bug fixing tests will allow you to avoid many serious problems.

Functional Test Layer (Non-UI) Level

As a rule, not all the business logics of the application can be tested through the GUI layer. There are applications implemented the way their business logics is hidden. That is why the developers can open the access to the functional layer to the testers who therefore will be able to work with the business logics of the application directly, instead of reaching it through the user interface.

GUI Test Layer Level

The outer layer stands herein for the user interface automated as described, applying the above-mentioned tools. At the level in question, it is possible to test not only the user interface but also the business layer, performing special operations in order to activate the business logics of the application. From my point of view, end-to-end tests of the kind are more efficient than simple testing of the business layer, because the business layer is tested by means of imitating the actions of the end user.

Automated Test Architecture

Take the main fields of the test case (the precondition, steps and the postcondition) and introduce them into the test script.

As a result, we obtain the rule stating that each script must contain:

• a precondition
• a number of steps
• a postcondition

Here are the main functions of the script:

1. Precondition

• Initialization of the application (open the main page, log in and move to the part of the application you want to work with, preparing the system for the test)
• Initialization of the test data

2. Steps

• Test
• Test result data recording. Saving the reasons explaining why the test was successful or failed is obligatory

3. Postcondition

• Application operation was successfully completed

It is recommended to develop an overall test performance library analyzing errors and exceptional situations, for example:

• PreConditionException
• TestCaseException
• PostConditionException

If you follow the recommendations above, by the end of the test you will collect a library of errors and exceptions analysis and build a general directory structure and general script architecture.

Strategy of Application of Automated Tests

To ensure the better quality of the product, we recommend the following approach:

1. Tests should be written by «skilled professionals», automation testers. Written tests are submitted to the manual testing team, which launches them daily and analyzes the results. Therefore, automated tests are tested themselves becoming more viable and error-resistant.
2. Written and debugged tests can be also submitted to the developers, when it is necessary to debug a new version.
3. It is recommended that the developers perform and run daily all the written tests at all the three levels. Having made sure that the new version meets all the necessary quality requirements, they can proceed and install the version at the QA platform.

Test writing and the approach to the automated testing depends on the process of development of the application. As for us, we can suggest the following scheme divided into phases and based on RUP (Rational Unified Process):

Inception phase: selection of the automation testing tool

Elaboration phase: writing tests for the main architecture (later on they will be used as Build Verification Tests)

Construction phase: includes critical functionality, regression verification, end-to-end scripts. The automation becomes more detailed.

Transition phase: tests are prepared to be submitted to the customer (if necessary)

File structure of test scripts and scenarios

To avoid problems when using and supporting the tool, as well as problems with test scripts and scenarios, it is recommended to accept the in-house standard of directory structure (packages) and code development (for java tests, the java code convention) alongside with general architecture of development of scripts and scenarios.

We would recommend developing the following file structure:

Project/

• bin – startup files folder
• lib – third-party libraries folder
• conf – test parameters and properties folder
• src – test source code folder
• results – test run results folder

Take note that a similar slightly modified structure will be appropriate whatever the tool you select and use.

Example: the organization of the file structure for HP tests performed on (Mercury) WinRunner:

Project/

• API – an equivalent of /lib
• Scripts – an equivalent of /src
• GUI
• Tables
• Files

Folders GUI, Tables & Files make part of the folder /conf

We hope that in this blog article you have found what you were looking for.