Breakpoints
When a programmer creates code they can add what is known as a breakpoint. A breakpoint is a point in the program where the code will stop executing.
For example, if the programmer amended the logic error in the trace table example they may wish to trigger a break point at line 5 in the algorithm. Breakpoints are often identified with symbols such as a circle or arrow:
Line
The example above is shown in reference language but the circle beside line 5 is shown to exemplify the creation of a breakpoint. The breakpoint would force the algorithm to stop running each time the loop reaches line 5.
When a breakpoint is set and triggered the program will display the value of the variables at that point only. This would allow the programmer to check that the value of the total variable updates correctly if the algorithm is altered to accept 1.57.
In large programs it is not uncommon to use a trace table prior to setting breakpoints. A trace table will highlight the fact that the value is not as it should be and the programmer can then set breakpoints to check specific parts of the program without having to trace each variable all of the time.
Watchpoints
Where a breakpoint is triggered at a specific point in the execution of code, a watchpoint is concerned with changes in the value of specific variables. For example, you could create a watchpoint on a variable called score and apply a condition to the watchpoint that stops execution when the value of score changes to ten. This would allow you to check that the value changes at the point in the execution that you expect it to.
You can also use watchpoints in conjunction with breakpoints to look at the value of only specific variables when a breakpoint is triggered.
Documentation during testing
It is common practice for programmers and testers to track testing using internal documentation. In order to inform maintenance at a later date, a test history is a useful item of documentation.
This test history would include the original test plan as well as specific documents such as test case documentation which would provide specific information on the features, procedures, functions and modules that have been tested.
This sort of rigorous documentation can save resources at a later date but can also delay the development of software. Rapid application methodologies would place less emphasis on this form of documentation than the traditional waterfall approach to software development.