Key term
CCEA A-Level Software Systems Development CL4
Software and the Development Environment
Topic overviewSystems software and application softwareThe operating system and file managementSource code filesBinary, object and executable filesCompilers, interpreters and the build processXML files and structured dataUtility software and managing files on diskThe integrated development environmentObject oriented development platformsOpen source software and licensing
Defining Data: Types, Variables and Classes
Topic overviewPrimitive types and their storageReference types, objects and nullDeclaring variables, scope and lifetimeType casting and conversionArithmetic operators and expressionsRelational and logical operatorsOperator precedence and evaluation orderObjects as occurrences of a classAbstract, base and inherited classesAttributes and the properties of a classStatic variables in a classInterfaces and class reusability
Program Control Structures
Topic overviewSequence and the order of executionMethods and passing control between themSelection with IF and IF ELSENested IF and multi-way selectionThe switch statementCount-controlled repetition with FORConditional repetition with WHILE and DO WHILENested loops and tracing iterationsBreaking out of loops and avoiding infinite loopsChoosing and evaluating control structures
Objects, Classes and Data Structures
Topic overviewConstructors and creating objectsMethods, parameters and return valuesEncapsulation and access modifiersGetters, setters and validating an object's stateInheritance and the base classOverriding methods and run-time polymorphismOverloading methodsChoosing and organising data structuresStrings and string handlingStatic arrays of simple typesArrays of objects
Exception Handling and Managing Input and Output
Topic overviewWhy errors have to be trappedTypes of error and how an exception is raisedThe try and catch blockCatching more than one kind of exceptionThe finally block and releasing resourcesThrowing exceptions and writing an exception classChecked and unchecked exceptionsReading and validating input from the command lineControlling screen outputText filesBinary filesObject files and serialisation
Testing an Object Oriented Application
Topic overviewWhy an object oriented application must be testedChoosing test data: normal, boundary and erroneousWriting a test plan for a classTesting a class method by methodTesting constructors and object stateTesting inheritance and overridden methodsTesting error handling pathsDry runs and trace tablesTest harnesses, drivers and stubsRecording and interpreting test resultsEvaluating a test plan and re-testing
Graphical User Interface Objects and Events
Topic overviewGraphical user interfaces and console programsForms and their common propertiesLabels, text boxes and text areasButtons, check boxes and radio buttonsLists, combo boxes and other selection controlsProperties, methods and events of a GUI objectContainers, panels and laying out a formThe event loop and the event queueEvent handlers and registering a listenerThe event object and reading it inside a handlerButton, mouse and keyboard triggers
Multiple Forms and Linking to Files
Topic overviewWhy an application needs more than one formCreating, showing, hiding and closing a formModal and modeless formsPassing data between formsMenus, menu items and shortcutsToolbars and navigation buttonsDesigning navigation for a multi form applicationReading and writing text filesBinary files and streamsObject serialisation and object filesChoosing between text, binary and object files
Designing, Testing and Evaluating an Event Driven Application
Topic overviewStoryboards and what they showBuilding a storyboard from user requirementsPrototyping and refining a designError trapping in an event driven applicationUsing try and catch inside an event handlerValidating what a user types into a controlDesigning a test strategy for an event driven applicationTest plans and choosing test dataTesting the paths a user takes through an interfaceDocumenting and interpreting test resultsEvaluating an application against its requirementsEvaluating features, functionality and usability
Reasons for Systems Development and Systems Methodologies
Topic overviewWhy organisations initiate systems developmentAnalysis and design principles for business solutionsRoles in development and the place of the userThe purpose of a methodology and how methodologies evolvedThe waterfall modelIterative, incremental and spiral developmentRapid application developmentThe dynamic systems development methodScrumExtreme programmingPrototyping in the development processUML modelling and simple diagrams
Managing Projects
Topic overviewThe purpose of project managementProject management concepts and the project life cycleRoles and responsibilities in project managementResources needed to develop a projectEstimating effort, duration and costGantt charts and the scheduleMilestones and checkpointsNetwork diagrams and PERTFinding the critical pathFloat and how it is usedMonitoring and controlling progressManaging risk and change
Testing Strategies
Topic overviewWhy testing matters throughout the development cycleTesting at the design stageProgram and unit testingIntegration testingSystem testingWhite box testingBlack box testingNormal, boundary and erroneous test dataUser acceptance, alpha and beta testingThe personnel involved in testingWhat a test plan containsBuilding a test plan for a scenario
Database Concepts and Entity Relationship Modelling
Topic overviewWhat a database is and why one is usedDatabase terminology: fields, records and keysThe relational modelThe hierarchical modelThe network modelEntities and attributes in an ER modelRelationships and their degreeBuilding an ER model for a problemFrom ER model to a working designComparing the three database models
Normalisation and Structured Query Language
Topic overviewWhy data is normalisedUn-normalised data and repeating groupsFirst normal formSecond normal formThird normal formWorking a full normalisation throughThe advantages and limits of normalisationThe principles of SQLSQL commands for defining and changing dataSQL statements for retrieving dataJoining tables and grouping results
Project Management and the Systems Approach in Practice
Topic overviewBreaking a development into tasks and deliverablesEstimating durations, effort and dependenciesDocumenting the plan as a Gantt chartWorking out the critical path and floatMilestones, reviews and user sign-off pointsPlanning people, resources and skillsBuilding a plan capable of reflecting changeRecording progress against the planUpdating the plan to reflect slippageRecording change requests and versions of the planEvaluating different approaches to a business problemSelecting and justifying a specific approach
Defining Requirements and Documenting the Design
Topic overviewEliciting requirements from the userWriting functional requirementsWriting non-functional requirementsSpecifying the software and hardware the solution needsProducing and agreeing the user requirements specificationDesigning the data model and the tablesDesigning the inputs, the screens and the navigationDesigning the outputs and the reportsDocumenting the processes and the logic of the solutionTesting the design against the desired user outcomesPresenting the design and the solution using appropriate media
Building a Desktop Solution with a Database
Topic overviewApplying relational techniques to a real solutionChoosing the database and the development toolConnecting the application to the databaseData adaptorsData setsData commands and parameterised queriesBinding the database to the interfaceMultiple forms and navigationSaving changes and protecting the dataTesting and documenting the built solution
Testing and Evaluating the Solution
Topic overviewPlanning the testing of the finished solutionChoosing test data: normal, boundary and erroneousTesting validation and error handlingTesting the database and its queriesTesting the user interface and the navigationTesting the whole solution and testing with the userDocumenting test outcomes as evidenceDiagnosing failures and retestingEvaluating the test proceduresEvaluating the solution against the user requirementsEvaluating delivery against the project planEvaluating your own performance on the development
Testing and Evaluating the Solution
- 12 subtopics
- 36 things to know
- A2 Unit 2
What Testing and Evaluating the Solution covers
Testing and Evaluating the Solution is examined in Unit A2 2, Implementing Solutions — an internally assessed portfolio. It covers planning the testing of the finished solution, choosing test data: normal, boundary and erroneous, testing validation and error handling, testing the database and its queries, testing the user interface and the navigation, testing the whole solution and testing with the user, documenting test outcomes as evidence, Diagnosing failures and retesting, evaluating the test procedures, evaluating the solution against the user requirements, evaluating delivery against the project plan and evaluating your own performance on the development.
Where it is assessed
A2 Unit 2
Implementing Solutions — an internally assessed portfolio.
Check the CCEA specification ↗The 12 subtopics
Each one has its own page.
- Planning the testing of the finished solutionWhat a testing procedure for a finished solution sets out, order in which the parts of a solution are tested and six columns a table of planned tests should contain.Open →
- Choosing test data: normal, boundary and erroneousNormal test data, boundary test data and erroneous test data.Open →
- Testing validation and error handlingConfirming each rule refuses what it should and accepts what it should, that the message names the field and the problem, and that a refused entry leaves the user's data on screen.Open →
- Testing the database and its queriesChecking each query returns the rows expected against data whose answer is known, that reports total correctly, that integrity rules fire, and that performance holds at the real volume.Open →
- Testing the user interface and the navigationWhat is tested on every control of every form, what is tested when a form is resized and what is tested about closing the solution down.Open →
- Testing the whole solution and testing with the userWhat is checked during system testing of a completed solution, user acceptance testing and recorded from an acceptance test besides pass or fail.Open →
- Documenting test outcomes as evidenceTest log, what is recorded for a test that passes and evidence that should accompany a documented test outcome.Open →
- Diagnosing failures and retestingFirst step when a test fails, what a breakpoint is used for while debugging and what must be done once a correction has been made.Open →
- Evaluating the test proceduresWhat it means to evaluate the test procedures and improvement to testing is worth naming in an evaluation.Open →
- Evaluating the solution against the user requirementsWhat a critical evaluation of a solution involves, three verdicts a requirement can receive in an evaluation and evidence that supports a claim that a requirement was met.Open →
- Evaluating delivery against the project planComparing what was delivered with what was scheduled, where the estimates were wrong and why, what was dropped or deferred, and what the variance says for the next plan.Open →
- Evaluating your own performance on the developmentJudging how the work was planned, decided and communicated rather than what the product does, identifying what would be done differently, and supporting the judgement with evidence from the project.Open →
What you need to know
Answer each one before you reveal it.
Your recallNot started
Key term
Why must the user take part in testing, and what should they be given to work with?
Key term
How is a query on a range of dates tested?
Process
State what a testing procedure for a finished solution sets out.
Key term
Name the three kinds of test data every field should be tested with.
Key term
Why is every validation rule given a test of its own?
Key term
State what is tested on every control of every form.
Key term
State the first step when a test fails.
Evaluation
Explain what it means to evaluate the test procedures.
Key term
Explain what a critical evaluation of a solution involves.
Key term
Explain what evaluating the development against the project plan involves.
Key term
State what an evaluation of personal performance covers.
Key term
Why is the testing planned before the solution is finished?
Key term
Define normal test data.
Key term
How is a presence check tested?
Key term
Name the four operations that must be tested against every table.
Key term
How is navigation tested in a solution built from several forms?
Key term
State what is checked during system testing of a completed solution.
Key term
Define a test log.
Key term
Why must a fault be reproducible before it is corrected?
Key term
Which question does an evaluation of the testing begin with?
Key term
Which document does the evaluation of the solution refer to first?
Key term
Which figure shows most clearly whether the plan was realistic?
Key term
Why must an evaluation of personal performance be supported by evidence?
Key term
State the order in which the parts of a solution are tested.
Key term
Define boundary test data.
Key term
How is a range check on a numeric field tested?
Key term
How is it confirmed that a record has genuinely been stored?
Key term
Why is the route back tested as well as the route forward?
Key term
What does integration testing look for that module testing cannot?
Key term
State what is recorded for a test that passes.
Key term
How does a developer narrow down where a fault lies?
Key term
How is the coverage of the testing measured?
Key term
How is the evaluation structured so that nothing is missed?
Key term
How should slippage be reported in an evaluation?
Key term
Give one piece of evidence for a claim of good time management.
Take Testing and Evaluating the Solution further
The same content, four other ways.
Commonly confused
Pairs that lose marks when they are blurred together.
Normal data vs Extreme data
Normal data: a value expected in everyday use. Extreme data: a valid value at the very edge of the accepted range.
Critical evaluation vs Description
Critical evaluation: reaching a judgement with evidence and naming shortcomings. Description: setting out only what exists.
Questions from this topic
Each one with the model answer underneath.
- 1
State what a testing procedure for a finished solution sets out.
Model answer
A testing procedure sets out what will be tested, in what order, with what data, by whom, and what result is expected.
- 2
Why is the testing planned before the solution is finished?
Model answer
Tests written from the requirements cannot be bent to fit the code, and planning early makes sure time is set aside for them.
- 3
State the order in which the parts of a solution are tested.
Model answer
Individual modules are tested first, then modules joined together, then the whole solution, and finally the solution with the user.
- 4
Name the six columns a table of planned tests should contain.
Model answer
The table gives the test number, its purpose, the data used, the expected result, the actual result and a pass or fail decision.
- 5
Why does every planned test carry a number?
Model answer
The number links the test to its evidence, to the requirement it checks, and to any retest run after a fault is corrected.
- 6
How are the tests derived from the user requirements?
Model answer
Each numbered requirement generates at least one test, so a requirement with no test has never been shown to work.
What is inside Levo
Six ways to work the same material.
Testing and Evaluating the Solution revision questions
- What does Testing and Evaluating the Solution cover in CCEA A-Level Software Systems Development?
- 12 subtopics: planning the testing of the finished solution, choosing test data: normal, boundary and erroneous, testing validation and error handling, testing the database and its queries, testing the user interface and the navigation, testing the whole solution and testing with the user, documenting test outcomes as evidence, diagnosing failures and retesting, evaluating the test procedures, evaluating the solution against the user requirements, evaluating delivery against the project plan and evaluating your own performance on the development. Each one has its own page with questions and model answers.
- How is Testing and Evaluating the Solution organised?
- By the CCEA CL4 specification, subtopic by subtopic, so it matches the order you are taught it in.
Every question in Testing and Evaluating the Solution, on a schedule.
Attempt a question from memory, write the correct version, then attempt it again. Levo records the jump between your first attempt and your last, and brings each question back on the day you are due to forget it.
Or £46 a year, about £3.83 a month. Cancel anytime.