Skip to the page
Year 11 · ICT · Summer 2 · After the exams

Build and show

ProjectPresent ▶

What this lesson covers

7.3 Development and testing

Cambridge IGCSE ICT 0417 · Topic 7: The systems life cycle · Paper 1

7.6 Evaluation

Cambridge IGCSE ICT 0417 · Topic 7: The systems life cycle · Paper 1

You will learn to

  • Test the finished project and record the results.
  • Evaluate the project against your success list and your audience's needs.
  • Demonstrate the project to the class and explain one problem you solved.

Success criteria

  • I can show which lines of my success list are met, and which are not.
  • I can name one improvement I would make with more time.
  • I can present my project and answer one question about it.
The syllabus points for these sections
  • Explain why a system must be tested before it is used.
  • Describe testing of modules, functions and the whole system.
  • Complete a test plan with test data, expected outcome, actual outcome and remedial action.
  • Choose normal, abnormal and extreme test data.
  • Explain the use of live data.
  • Evaluate a system for efficiency, ease of use and appropriateness.
  • Compare the final system with the original user requirements.
  • Use user feedback to identify limitations and improvements.

Key words

Say each word, then read what it means. Every one is in the glossary too.

Questionnaire
A set of written questions given to many people to collect their views.
System specification
A list of the hardware and software the new system needs.
Field
One item of data in a record, such as Surname.
Validation
An automatic computer check that data is sensible and allowed.
Check digit
An extra digit calculated from the other digits, used to detect input errors.
Data capture form
A paper or on-screen form used to collect data.
Test plan
A table listing each test, its data, the expected and actual outcomes and any remedial action.
Normal data
Sensible data that should be accepted.
Abnormal data
Data that should be rejected, such as out of range or the wrong type.
Extreme data
Data at the limits of the allowed range, which should be accepted.
Live data
Real data from the organisation, used to test the system with known results.
Remedial action
What was done to fix a test that failed.
Evaluation
Judging the finished system against the original requirements after it has been used.

The explanation

Read it here, or open the study page below to go one step at a time with things to try.

7.3 Development and testing

Why test, and the test strategy

Development means building the system: creating the file structures, forms, validation and reports.

Testing checks that the system works as the design says, and that it handles mistakes without crashing.

A test strategy decides what is tested and in what order: each module (a separate part), then each function (one task, such as 'record a loan'), then the whole system working together.

e.g.Example
Library system modules: member records, book records, loans, reports. Test the loans module alone first. Then test the function 'return a book'. Then test the whole system: a new member borrows a book, returns it late, and appears on the overdue report.
?Why?

Testing small parts first makes errors easy to find. If the whole system fails at once, the fault could be anywhere.

Types of test data

Normal data is sensible data that the system should accept.

Abnormal data is data that should be rejected: outside the range or the wrong type. Some books call it erroneous data.

Extreme data is data at the very limits of what is allowed. It should be accepted.

Computer Science 0478 also uses boundary data: the limit value and the value immediately beyond it. ICT 0417 asks for normal, abnormal and extreme.

Field ruleNormalExtremeAbnormal
Exam mark 0 to 10056, 730, 100101, −5, 'sixty'
Year group 7 to 139, 117, 136, 14, 'ten'
Loan length 1 to 21 days141, 210, 22, 3.5
e.g.Example
Try the toy with the range 1 to 100. Classify 50, 1, 100, 0, 101 and 'abc'. Notice that 1 and 100 are extreme and accepted. 0 and 101 are rejected. ICT calls them abnormal. The toy labels them boundary, the Computer Science term for the value just outside the range.
!Watch out

Extreme data is accepted. Students often think extreme means 'too big'. Too big is abnormal.

There is something to try for this step in the IGCSE library.

The test plan

A test plan is a table written before testing. Each row is one test.

The first columns are: what is being tested, the test data and the type of data.

Then come the expected outcome (what should happen), the actual outcome (what did happen) and the remedial action (what was done to fix a failure).

If the actual outcome matches the expected outcome, the test passes. If not, the system is fixed and the test is run again.

TestTest dataTypeExpected outcomeActual outcomeRemedial action
Mark field range 0 to 10056NormalAcceptedAcceptedNone needed
Mark field range 0 to 1000ExtremeAcceptedAcceptedNone needed
Mark field range 0 to 100100ExtremeAcceptedRejected with errorChanged rule from <100 to <=100, retested: accepted
Mark field range 0 to 100101AbnormalRejected, error message 'Mark must be 0 to 100'Rejected, message shownNone needed
Mark field range 0 to 100sixtyAbnormalRejected, error message 'Enter a number'Accepted and savedAdded type check, retested: rejected
Surname presence check(left blank)AbnormalRejected, 'Surname is required'Rejected, message shownNone needed
?Why?

Writing the expected outcome before testing stops the tester accepting whatever happens. The test plan also becomes evidence in the technical documentation.

Live data

Live data is real data from the organisation, such as last month's actual library loans.

After testing with made-up test data, the system is tested with live data whose results are already known from the old system.

If the new system gives the same results as the old one, it is working correctly with real-world data.

e.g.Example
The library enters last October's 1,240 real loans. The old card system recorded 63 overdue books. The new system's overdue report should also show 63.
!Watch out

Live data contains real personal data, so it must be kept secure during testing.

7.6 Evaluation

What evaluation checks

Evaluation happens after the system has been in use for a while. It asks: does the new system do the job well?

Efficiency: is it faster or cheaper than the old system? Does it use fewer resources?

Ease of use: can staff use it with little training? Do they make fewer mistakes?

Appropriateness: is it the right solution for this organisation and its problems?

e.g.Example
Library evaluation after one term: A loan now takes 12 seconds (requirement: under 30 seconds). Met. Overdue books fell from 63 a month to 18. Improvement. Two librarians find the reports menu confusing. Ease-of-use problem.

How it is done and what comes next

The analyst compares the final system with the original user requirements from the analysis stage, one by one.

The analyst gathers user feedback by interviews and questionnaires, and compares results from the test plan.

Any limitations found are listed, with improvements to fix them. This may start the life cycle again.

?Why?

The requirements written in analysis are the yardstick. Without them, there is no fair way to say whether the system succeeded.

!Watch out

Evaluation is not testing. Testing happens before the system goes live. Evaluation happens after it has been used for real.

Saved on this device.