Syntax, together with semantics, belongs to what is often called the validation tests, with which the validity of the input data is tested. This establishes the degree to which the system is proof against invalid, or ‘nonsense’ input that is offered to the system wilfully or otherwise. This test is also used to test the validity of output data.
Validation tests focus on attributes, which should not be confused with data. An input screen or other random interface contains attributes that are (to be) filled with input values. If the sections contain valid values, the system will generally process these and create or change certain data within.
The test basis for the syntactic test consists of the syntactic rules, which specify how a attribute should comply in order to be accepted as valid input/output by the system. These rules actually describe the value domain for the relevant attribute. If a value outside this domain is offered for the attribute, the system should discontinue the processing in a controlled manner – usually with an error message.
Syntactic rules may be established in various documents, but they are normally described in:

  • The ‘data dictionary’ and other data models, in which the characteristics of all the data are described
  • Functional specifications of the relevant function or input screen, containing the specific requirements in respect of the attributes.

The syntactic rules may take a random order and be tested independently of each other.
Usually, in practice, the input screens of data are used to test the syntactic checks. For practical reasons, this is often combined with the coverage type presentation, which tests the layout of the screens.
Overview of attribute checks:

  • Data type
    e.g. numeric, alphabetical, alphanumeric, etc.
  • Field length
    The length of the input field is often limited.Investigate what happens when you attempt to exceed this length. (Press the letter key for a some time.)
  • Input / Output
    There are 3 possibilities here: 
    I: No value is shown, but may be or must be entered
    U: The value is shown, but may not be changed
    UI: A value is shown, and may be changed.
  • Default
    If the attribute is not completed, the system should process the default value.
    If it concerns a UI field (see above), the default value should be shown.
  • Mandatory / Non-mandatory
    A mandatory attribute may not remain empty.
    A non-mandatory attribute may remain empty. In the processing, either the datum is left empty or the default value for this datum is used.
  • Selection mechanism
    A choice has to be made from a number of given possibilities. It is important here whether only one possibility may be chosen or several. This is particularly the case with GUIs (Graphical User Interface), e.g. with:
    ◦ Radio buttons (try to activate several)
    ◦ Check boxes (try to activate several)
    ◦ Drop-down box (try to change the value or make it empty).
  • Domain
    This describes all the valid values for this attribute. It can, in principle, be shown in two ways: ◦ Enumeration For example {M, F, N}.
    ◦ Value range All the values between the given boundaries are permitted. The value boundaries themselves, in particular, should be tested. For example, [0, 100>, where the symbols indicate that the value range is from 0 to 100, including the value 0, but excluding the value 100.
    In practice, the value 0 (zero) can cause problems in input fields. It is advisable to try out the value 0 at every input field. Special characters Is the system proof against special characters, such as quotes, exclusive spaces, question marks, Ctrl characters, etc.?
  • Format For some attributes, specific requirements are set as regards format, e.g.:
    ◦ Date
    Common formats, for example, are YYYYMMDD or DD-MM-YY,
    ◦ Postal Code
    The postal code format in principle varies from country to country. In the Netherlands, the format for this is “1111 AA” (four digits followed by a space and two letters).