QCAA Digital Solutions common mistakes
QCAA Digital Solutions · Understand the traps and how to avoid them.
When asked to describe how data flows through a system, the candidate lists components (input, process, storage, output) as labels without stating what data moves, in what form, and between which components.
Textbook diagrams present components as boxes, so candidates memorise the box names and treat the diagram as the answer rather than reading it as a description of movement and transformation.
What to do instead
Rehearse a fixed sentence pattern for every flow: 'X sends [specific data, with type/format] to Y, which converts it to [new form] before storing it in Z.' Practise on three systems (a school attendance app, an online store, a weather station) until naming the data, not the box, becomes automatic.
In structured English or pseudocode questions, the candidate writes valid-looking code but omits initialisation of accumulators and counters, or places the update inside the wrong loop level.
Candidates pattern-match on familiar code shapes from class tasks and skip desk-checking, so off-by-one and uninitialised-variable errors survive into the answer.
What to do instead
After writing any algorithm, run a desk check with a small concrete dataset (three records, one of them an edge case such as zero or a duplicate) and write the variable values in a trace table beside the code. Set accumulators to zero and counters to zero explicitly before the loop, and confirm the update line is inside the loop that repeats.
When asked to evaluate a proposed solution or compare alternatives, the candidate describes what the solution does instead of judging it against stated criteria, and gives no recommendation.
Candidates conflate 'describe' and 'evaluate' command words, and they fear committing to a judgement in case it is wrong.
What to do instead
Before writing, extract the criteria from the stimulus (cost, usability, security, scalability, time to develop) and structure the response as a table: criterion, evidence from the scenario, judgement. Finish with one explicit recommendation sentence naming the preferred option and the strongest reason.
In a relational database question, the candidate draws tables with repeating groups or stores the same fact in several rows, then cannot explain why an update anomaly occurs.
Candidates design tables around the appearance of a report or spreadsheet rather than around entities and their relationships, so normalisation is applied as a ritual rather than as a fix.
What to do instead
Start every design by listing entities as nouns and relationships as verbs, assign a primary key to each entity, then check each non-key attribute depends on the whole key. Test the design by writing one insert, one update and one delete and asking whether each touches exactly one row; if not, split the table.
Queries are written with the join condition in the WHERE clause of an implicit join, or with the wrong aggregate scope, producing duplicated rows or totals that are silently wrong.
Candidates learn query syntax from single-table examples and never see how a missing or misplaced join condition multiplies rows, so the error is invisible without testing.
What to do instead
Always use explicit JOIN ... ON syntax, and after writing a query predict the row count before running it. If the prediction and result differ, inspect the join keys first. When using GROUP BY, list every non-aggregated selected column in the GROUP BY clause and verify with a COUNT(*) check.
When describing a low-fidelity prototype or user interface, the candidate lists features (a button, a menu) but does not link each design choice to a usability principle or to a specific user need from the scenario.
Candidates treat prototype questions as creative drawing tasks and answer with aesthetics rather than justified design decisions.
What to do instead
For each element, write one sentence of the form 'I included [element] because [user need or principle such as consistency, feedback, error prevention, accessibility contrast].' Aim for at least three justified elements and one acknowledged trade-off.
In a data-driven or visualisation question, the candidate chooses a chart type by preference (for example a pie chart for eight categories) and omits axis labels, units or the source of the data.
Candidates focus on making the output look attractive and have not internalised the mapping between data type and appropriate representation.
What to do instead
Apply a decision rule before choosing: comparison across categories uses a bar chart; trend over time uses a line chart; parts of a whole uses a pie chart only with few categories. Then check every chart has a title, labelled axes with units, and a stated data source.
When asked about security or privacy, the candidate names a control (encryption, hashing, access levels) without saying what threat it mitigates, where in the system it applies, or what residual risk remains.
Controls are learned as vocabulary lists, so candidates cannot connect a control to a threat model or to a specific data flow in the scenario.
What to do instead
Use a threat-control-residual structure: 'Threat: [specific attack on specific data]. Control: [mechanism] applied at [point in the system]. Residual risk: [what is still exposed and how it is monitored].' Practise on passwords, payment data and personal records.
In the project folio, the candidate reports what they built and what tools they used, but provides no evidence of testing against the initial success criteria, and no record of changes made in response to feedback.
Candidates treat the folio as a diary of effort and assume the working product demonstrates quality, so evaluation and iteration are written last and thinly.
What to do instead
Maintain an evaluation table from the start: criterion, test performed, actual result, pass or fail, action taken. Capture at least two genuine iterations with before-and-after evidence and a sentence on what the feedback changed. Write the evaluation section against the criteria, not against the features.
On extended-response questions, the candidate writes a general essay about technology and does not reference the specific stimulus, data or scenario constraints provided, so the response cannot reach the higher descriptor.
Under time pressure, candidates default to pre-prepared general content and skip the planning step that would anchor the answer in the provided context.
What to do instead
Spend the first two minutes extracting and numbering the constraints and stakeholders named in the stimulus, then write one paragraph per constraint using named details from it. Before finishing, check that every paragraph contains at least one specific reference to the stimulus.