| Key Term |
Definition |
| Syntax Error |
Occur when code statements cannot be understood because they do not follow the rules of the programming language. E.g. misspelling a reserved word. |
| Logic Error |
Mistakes in the design of the code (e.g. incorrect comparison or operator used) that lead to the wrong results or incorrect display. Generally does not produce an error message. |
| Run-Time Error |
Detected while the program is running. The errors, such as overflow and division by 0, are usually made by mistake or when not catering for external effects. |
| Compiler |
Software that translates a code in high-level language into low-level language such as machine code. |
| Type Mismatch |
Occurs when the program attempts to assign, operate or compare a value that is not a compatible data type. E.g. trying to assign a string to an integer variable. |
| Overflow Error |
Occurs during an arithmetic operation when the result of a calculation is too big for the space reserved for the variable. |
| Stack Overflow Error |
Occurs when the stack space reserved for a program or data structure is exceeded. Can occur during recursion. |
| Testing |
Checking the success and reliability of a computer system under a number of different circumstances. Because it is impossible to test every operation that can happen to a system it is important to create a test plan in order to carefully ensure the areas that are most likely to provoke errors are tested. |
| Test Data |
Inputs used during testing and specified in the test plan. |
| Black Box Testing |
Testing by using inputs to ensure that the expected output occurs. Not concerned with how the program works, just that it produces the desired outcome. Failed tests are corrected and re-tested. |
| Valid Data |
Inputs used during testing which the system should be able to process. Checks that the system works under normal conditions. |
| Invalid Data |
Inputs used during testing which the system should reject or create an error message. Checks that the systems validations work correctly. |
| Extreme / Borderline Data |
Inputs used during testing that are on the top or bottom of a range and that the system should process. E.g. if a field has a range validation of between 1 and 8, this would test that both 1 and 8 are accepted. |
| White Box Testing |
Testing the logic of the code in a program. Tests the different routes or path of execution through a program to ensure all conditions work as expected. |
| Alpha Testing |
Testing carried out by a restricted group within the company acting as though they were potential users. |
| Beta Testing |
Program is nearly complete and is released to potential users outside the company to test it in normal operating conditions. |
| Acceptance Testing |
Program is now complete and it is demonstrated to the end user. The purpose is to show that it works correctly and all desired features are implemented. |
| Debugging |
Facilities that enable the programmer to investigate and locate errors in the code |
| Compiler Diagnostics |
Messages generated by the compiler when converting code into executable. |
| Breakpoints |
Stopping the program at a specified point to check on the value of variables or to step through the code one line at a time. |
| Variable Checks |
Lists the contents of variables at specific points in the program. Allows the programmer to compare the contents to what is expected. |
| Dry Runs |
Working through parts of the program manually to locate errors. Particularly useful for run-time errors. |
| Trace Table |
Created when performing a dry run to record the values of variables at different stages. A column is used for the instruction being executed and another for the value of the variables. New line indicates another instructions. |