Dynamic Automated Testing

DYNAMIC AUTOMATED TESTING

When testing we often have to perform the same operation a good number of times within the same iteration or even within the whole cycle of testing. To avoid this routine work, someone smart has invented automated testing tools.

Now we just “write it” while automated tests do the rest of the job pressing buttons, entering data, checking the data consistency and sometimes even recording bugs into the error tracking system. Things become easier, and we have more leisure for working out intricate scenarios and creating test data to increase the amount of automated test cases.

Actually, it’s not that simple, because the process requires some additional automation within the framework of each separately taken project depending on test types and the requirements to be met. It is called the automated generation of test cases and test data.

Here is an example of the algorithm of a more or less universal test generator developed on the simplest principles:

  1. In the process of testing we use certain data we have created applying certain requirements.
  2. Each requirement can be conditionally divided into several sub-requirements:
  • Value
  • Format
  • Acceptable symbols
  1. The generation of the sub-requirements is based on the simplest rules, which can be programmed.

Thus we can conclude that if generation requirements can be programmed, consequently test data generation can be automated. We can develop a single generator and continue applying it in future to all the data bearing in mind they can be generated only provided they meet the requirements above. The only thing the tester should do is to describe the test data requirements.

Here is a more illustrative example:

Field: Date of birth

Requirements:

  • Value: date
  • Format: day/month/year
  • Only digital symbols and “.” are acceptable

Additional requirements: any date between 1908 and 2008

With the acceptable value interval as a requirement, we can easily select positive and negative test cases applying the boundary value verification rules:

Positive, if the boundaries are included: the left boundary, the right boundary and a value inside the interval

Positive if the boundaries are NOT included: values inside the interval

Negative if the boundaries are included: a boundary value lower than the left boundary, a boundary value higher than the right boundary

Negative if the boundaries are NOT included: the left boundary, the right boundary

The generation principle is the same for all the types of values meeting boundary conditions (a whole number, a number with the decimal point, the date). It means that positive and negative test case values are generated dynamically when performing the test execution.

Thereafter the tester applies additional format and requirements for acceptable symbols and gets a number of data sets meeting the above-listed requirements.

Similar value generation rules may be applied to line data depending on the line length, which is a particular case of boundary conditions with a fixed permanently included left boundary:

  • A line including 25 symbols is a line with a length from 0 to 25 symbols.

When generating a line containing a number of symbols within a certain line length we apply the same rules as when generating a line meeting the requirements or boundary conditions.

That’s how we get to a fundamentally new level of test automation: Dynamic Automated Testing, where test cases are generated directly during the test execution.

 

Leave a Reply

Your email address will not be published. Required fields are marked *