Testing & Debugging

• Systematic: Something that is done in a systematic way is done according to a fixed plan, in a thorough and efficient way. Systematic testing means that the testing follows a logical, sensible order
• Comprehensive: Something that is comprehensive includes everything that is needed or relevant. Comprehensive testing ensure that all parts of the program are tested to ensure that they can deal with normal, extreme and exceptional data.
• Comprehensive: Something that is comprehensive includes everything that is needed or relevant. Comprehensive testing ensure that all parts of the program are tested to ensure that they can deal with normal, extreme and exceptional data.
• Component: the components of a program are the modules (functions and procedures) that make up the full program.
• In systematic testing, the program is tested in a logical, sensible order. To demonstrate systematic testing, the test data plan should test each input in turn that they are asked for by the program, including

  any validation by testing each input using normal, extreme and exceptional data. It is worth testing each component (function or procedure) as it is implemented to ensure that it works as

  expected and returns any values to the top level program. This can be as simple as calling the component then printing the values returned to make sure they match the expected values.
• If testing is systematic, then it is highly likely to be comprehensive, but it is worth checking that every variable has been tested completely for all possible errors. It is not always possible to test every single

  value that a program should accept, but comprehensive testing ensure that any boundaries in the program have been fully probed using normal, extreme and exceptional data.
• Breakpoints - When developing software, it is useful to be able to pause the program at any given stage and inspect the

  contents of variables and arrays, to ensure that they contain the expected values. One simple way of doing this is to use a simple print ( ) command to display the contents of variables at sensible points in

  the program. However, it can then be time consuming to remove them once the development is complete.
• Watchpoints - When developing a solution, there may be specific variables that the developer wants to monitor, to

  ensure that the contents are changing as expected. A watchpoint can be set on a specific variable that

  will pause the program running if the contents of that variable change, allowing the developer to inspect

  the contents of the variable to ensure that it now holds the expected value. Unfortunately, the standard Python IDLE does not support the use of Watchpoints, so these have to be simulated through the use of multiple, well planned print ( ) commands.
• A dry run of the program involved the programmer acting as the computer and carrying out each step in the program, as stated, by hand. This is normally done quite informally, but will likely use a pencil and piece of paper to record the expected result at the end of each line of code. It is highly unlikely that the client will want to see evidence of dry runs, as they happen regularly and informally. For short

  programs, it is often useful to print the code and examine it by hand.
• Trace tables are a paper based step up from Dry runs, in that they more formally record what each line of code is doing, in turn. Although time consuming, trace tables can be used to determine exactly where a program is no longer giving the expected values and hence really narrow down on the error to be fixed.
• A dry run of the program involved the programmer acting as the computer and carrying out each step in the program, as stated, by hand. This is normally done quite informally, but will likely use a pencil and piece of paper to record the expected result at the end of each line of code. It is highly unlikely that the client will want to see evidence of dry runs, as they happen regularly and informally. For short programs, it is often useful to print the code and examine it by hand.
• • Programmers can add breakpoints to their program code.
  • When the program reaches a breakpoint it will stop.
  • The programmer is able to see the values held in variables at that point.
  • Breakpoints assist the programmer in identifying logic errors.
• • A watchpoint is a breakpoint assigned to a variable.
  • The program will stop running when the value of the variable changes.
  • The programmer can then examine the value stored in the variable.
• • A dry run involves the programmer working through the program on paper, following the logic of the code line by line.
  • A dry run can therefore be useful in identifying logic errors.
  • When carrying out a dry run, the programmer might use a trace table to keep track of the data stored in individual variables.
• Reasons for software testing:

  • identify errors
  • show that all functional requirements are met
  • ensure efficient and maintainable code

  A comprehensive test plan will test:

  • normal data
  • extreme data
  • exceptional data