TTCN is a programming language used for testing of communication protocols and web services. A TTCN test suite consists of many test cases written in the TTCN programming language. Until version 2 the language was written in tables and called Tree and Tabular Combined Notation. Reading and editing this language required special TTCN editors. Beginning with version 3 TTCN was renamed to Testing and Test Control Notation. It is now closer to current programming languages and can be edited with traditional editors. TTCN-3 is more flexible than TTCN-2 in that it can be used for protocol testing as well as testing traditional software.
All versions of TTCN need dedicated compilers or interpreters for execution.
TTCN is widely used, for example; ETSI, ITU for the testing of telecommunication protocols. Conformance test cases of ETSI standards like ISDN, DECT, GSM, EDGE, 3G, DSRC have also been written in TTCN. Recently it has also been used for testing various protocol standards e.g. Bluetooth, IP.
Execution of those test cases against products (e.g. phones, mobile phones, service enablers or network elements) is used to verify that the protocol implementation in those products meet the requirements defined by telecommunication standards.
TTCN is often combined with ASN.1.
- TTCN-1: Standardized in 1992 by ISO and CCITT as ISO/IEC 9646-3 and CCITT X.292 for Open Systems Interconnection (OSI) conformance testing methodology and framework.
- TTCN-2: Standardized in 1998 by ISO and ITU, adding concurrency and multiple modules support to TTCN-1.
- TTCN-3: Written by ETSI and standardized in 2000 by ITU under reference Z.140. It aimed at being a more generic testing language than TTCN-2. In 2007 the recommendation moved from Z.140 to Z.160.
Conformance testing means a test execution against a well-defined test case, e.g. a test written in TTCN. Plug-tests, also called interoperability testing, are test cases executed with a client - server model; e.g. Mail-Client against Mail-server, phone against network, Bluetooth headset against Bluetooth phone. Plug-tests are e.g. often executed at so-called unplug-tests.
Conformance-tests and plug-tests complement each other. If properly done, interoperability errors found with plug-tests should lead to definition of new conformance test cases that cover the failed test.