12.3 Program testing and maintenance

Syntax error

• The programming language rules have not been followed

• Program will not run

• Eg. Misspelt keywords, brackets do not match

Logic error

• Error in the algorithm/design of the solution

• Program will run

• Program does not behave as expected, doesn’t give expected output

• Eg. wrong arithmetic operator used/wrong loop count

Runtime error

• The program performs an illegal construction/invalid operation

• Program will NOT run

• Eg. divide by zero, endless loop, crash/freeze

Meaning of a program “not containing any syntax errors”

• Program obeys rules/grammar of programming language

• The program will run

• Eg. No misspelt keywords, all brackets match

“Methods of exposing faults in a program”

• Produce a trace table/walk through the code

• Add output statements to allow the code to be tracked

• Monitor variables using a watch window

• Try different test values to see which ones fail

“Examples of syntax errors that cannot be detected from a single line”

• Involves selection

• Involves iteration

• Incorrect block structure (missing keyword eg. ENDFUNCTION)

• Data type errors (assigning integer value to string)

• Identifier used before it is declared

• Incorrect parameter use

“How IDE could be used to help debug a function returning an unexpected value”

• Set a breakpoint to stop the program at a particular point

• Value of variables checked using a watch window

• Single stepping can be used to execute on statement at a time

“Identify type of maintenance and why this type is needed”

• Adaptive

• Change in user requirements/accommodate legislative changes

“Adaptive maintenance and why it is used (implement website browser)”

• Changes in user requirements/changes in legislation

• Changes in available technology to host website

• Eg. new HTML version is available

“Corrective maintenance and why it is used (implement website browser)”

• Program does not operate as expected

• Program contains bugs

• Eg. Passwords not hidden

“Perfective maintenance and why it is used (implement website browser)”

• Improve the performance of the program

• Enhance the program

• Changes made to program after it has been made available to public

• Eg. improve the speed of response

“Describe stub testing”

• Used when program contains modules with errors/incomplete modules

• Dysfunctional modules are replaced by dummy modules

• Dummy modules return a known/expected result to show they’ve been called

• Simple modules are written to replace each of the unfinished modules

• Each simple module will return an expected value / output a message to show it has been called

“Logic error black-box testing - describe”

• Program doesn’t behave as expected

• Does not give expected result

“Run-time error black-box testing - describe”

• The program performs an illegal operation

Dry run testing:

• Manually trace through the code (step-by-step), to predict output and track variables

• Without actually running code on the computer

Walkthrough:

• Step-by-step review of the code with others to identify issues early

White-box testing:

• Tests the internal logic and code structure

• The tester knows how the program works

Black-box testing:

• Tests the inputs and expected outputs without knowing the internal workings

• Provides test data based on program specification without having access to internal code

Integration testing:

• Each module in program is tested individually during development and is debugged as necessary

• Checks the different modules or components work correctly together

• Test combined modules to ensure they work together as expected within the entire software system

• Gradually integrate and test new modules with existing components

Alpha testing:

• Performed in-house by the developers during early testing

Beta testing:

• Testing carried out by a small group of potential users

• Users check that program works as intended and identify any errors present

• Users will provide feedback/suggestions for improvement

• Problems identified are addressed before program is sold

Acceptance testing:

• Final check to ensure the program meets the original client requirements

• Involves customers or end-users that verify if software meets specified requirements

Importance of a test strategy:

• Provide a structured roadmap, outlining goals, scope, methods and resources for testing software

• Ensures systematic and efficient quality assurance, defect detention and software reliability before release

Test plans:

• Ensures expected sequence of operations within the software

• Verifies that provided data meets specified criteria

• Validates accuracy of loop iterations and decision-making processes

• Ensures data is accurately stored in the intended locations

• Validates the accuracy of the system’s output or outcomes

“Describe stub testing”

• Simple modules are written to replace each of the unfinished modules

• Each simple module will return an expected value / output a message to show it has been called

“Logic error black-box testing - describe”

• Program doesn’t behave as expected

• Does not give expected result

“Run-time error black-box testing - describe”

• The program performs an illegal operation

How errors are identified

• Program is checked by creating a trace table, going through program one line at a time

• Records/checks variables as they change

• Error may be indicated when

  • Variable is given an unexpected value

  • Unexpected path through program/faults in logic of program