Testing & Evaluation

This is a test plan carried out by the programming developers and is known as alpha testing.

When clients / users test the software this is known as beta testing.

The idea is that software cannot realistically be tested with just three or four items of test data. To properly test the program, you must test thoroughly for each of the functional requirements.

Your comprehensive plan could include:

• Test every process that is listed in the functional requirements (with various inputs)

  • That the output of the process  is correct

  • That data is passed into the process correctly

  • That data is passed out (if applicable) of the process correctly

• The program produces the overall output you expected

• The program reads from/writes to files correctly

• The program runs in a reasonable period of time

• The program has a reasonable user interface

Syntax

• When there is a spelling mistake in your code or a mistake in the structure of a loop or IF statement. This type of error is spotted by the translator and will not allow your program to run without being fixed.

Logic

• When the code is grammatically correct and will run without crashing, but it will not do what it is supposed to and produced incorrect results.

Execution/Run-Time

• This error causes the program to crash once it has been translated and is running. Typical run-time errors include dividing by zero and trying to use an array value that doesn’t exist (loop 11 times for an array of 10 items)

Debugging is the process of removing errors.

There are four debugging techniques that you will need to use and explain:

• Dry run

• Trace table

• Breakpoint

• Watchpoint

• 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 variable

The trace table is another pencil-and-paper technique, where you create a table with all the (relevant) variables. You track each line of the program (or iterations of a loop), to see how the variables change over time.

• 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.

For Higher, fitness for purpose, efficient use of coding constructs and robustness carry over from National 5. There are two new measures of evaluation: maintainability and usability.

Fitness for purpose, efficiency and robustness were all covered at National 5.

Fitness for purpose

• Meets the specification (including all functional requirements) as set out during the analysis phase.

Efficient use of coding constructs

• The program code should make efficient use of hardware resources ie processor, memory.

• Code should be written efficiently, making the best use of the programmer's time.

• Good practice:

  • Use arrays instead of multiple variables.

  • Use fixed loops instead of repeating the same code.

  • Use nested if statements (else if) instead of individual if statements.

  • Use complex conditions (and/or) instead of multiple simple conditions.

Robustness

• Programs should cope with unexpected inputs and not crash unexpectedly.

• Error reporting should be clear and meaningful.

• Usability is the degree of ease with which a program can be used to achieve goals.

• Programs should be designed to ensure that the user does not encounter difficulties when using them.

• It should be as easy to learn to use a program as possible.

• The user can be further supported with help, tutorials and FAQs.

• User tasks should be completed in as few steps as possible.

• Feedback is important - errors should be clear and easy to understand.

• Customisable settings can change the layout and options for different levels of user eg novice, advanced.

• Using modular code means that sub-programs can be developed and tested independently.

• Meaningful variable names and sub-program identifiers make it easier to read and understand code.

• Internal commentary can be used to explain the purpose of code blocks.

• Indentation and whitespace make program code easier to read.