Some types of syntax testing may appear to be very helpful while resolving a certain task, and some, on the contrary, may become an obstacle to getting desirable results. There is, however, the other side of the coin. Bad programs types tend to contain the largest number of errors, and therefore, syntax testing should be used in this case.
Formal structure. Some command languages, such as UNIX, have a formal structure. Instead of hundreds of special commands, the language has a relatively small number of command segments, which, if compiled in accordance with special rules, can produce the desired effect. On the other hand, operating systems like MS-DOS, which structure is not formal enough, nevertheless, have some of these structural characteristics, for example, the redirection and pipelining abilities.
For command languages that have an explicit formal structure, it is usually enough to check the segments and the rules for their layout, rather than checking the entire set of possible commands. This is especially important for dirty syntax testing, which, as a rule, is not very productive when checking command languages with a formal structure. If the programming language has a formal structure, then it is easy to find a complete, detailed specification for all commands, often compiled in a metalanguage equivalent to BNF. Therefore, although the tests are easy to design, they are not very effective. Clear testing, surely, is less expensive and executing it takes less time.
Command languages without formal structure or with the structure that has appeared during the compilation process are, as a rule, good objects for dirty syntax testing (and often contain lots of errors). The most notorious example of this language is dBASE-11 / III / IV, the database programming language for PCs. Macro Command languages for PCs often also have these unpleasant features. Specialized languages, often constructed without a proper understanding of what language is actually made, are usually difficult to investigate, since the documentation for the commands in these languages (and especially for clever exceptions) is extremely scarce. The lack of structure makes it difficult to automate the test development process, and the automatic dirty test generator produces many incorrect test options. The undoubted advantage of such systems, containing command languages having no structure, is their easiness to be broken.
High-performing quality assurance organizations, like ours, help people develop an effective qa and testing strategy to achieve each objective through our efforts and assessments that concentrate on aligning processes, procedures, tools and people to ensure standardized and flexible processes.