How to use these questions
There is no single international software engineering exam format or syllabus. These questions use a common single-best-answer style and cover core concepts; check your course or examination body's syllabus for the topics and question types you need. For each question, choose the best option before reading the explanation. Then note whether you knew the principle, recognised it from the wording, or guessed. A correct answer reached by guessing is still a topic to revisit.
The set moves from requirements through design and testing to delivery and security. MySummaries can turn a candidate's own material into a question set; the first item looks like this:
A team is building an online appointment system. Which requirement is most directly testable as written?
The cancellation requirement defines an observable action and a precise time boundary, so a test can check the outcome at and around 24 hours. The strongest distractor is 'respond quickly': it sounds measurable, but without a response-time target, workload and measurement point, it is ambiguous.
A strong requirement states an observable outcome and enough conditions to verify it. When you review your own requirements, look for terms such as easy, fast and intuitive: they need measurable acceptance criteria before they can be tested consistently.
Requirements and design
Question 2 checks whether you can distinguish what a system does from a constraint on how well or under what conditions it does it.
Which is a non-functional requirement for a library lending system?
Availability describes a quality constraint on the service rather than a user operation, so it is non-functional. The strongest distractor is the search option: search may be complex, but it states a capability the system must provide, making it functional.
The percentage is meaningful only when its measurement period and exclusions are defined. In a real specification, clarify how planned maintenance, partial outages and the measurement source are treated; otherwise two parties may calculate availability differently.
Question 3 tests cohesion and coupling, two principles used to reason about maintainable module boundaries.
A developer is splitting a large service into modules. Which design change most directly improves modularity?
A focused responsibility increases cohesion, while fewer dependencies reduce coupling. Together these make a module easier to understand and change independently. The strongest distractor is placing everything in one module: it may reduce file count, but it combines unrelated responsibilities and makes change impact harder to contain.
When examining a proposed design, ask whether a change to one responsibility forces edits across unrelated parts. A low file count is not a useful design goal by itself; clear boundaries and controlled dependencies matter more.
Testing and continuous integration
Question 4 tests the difference between a test double that supplies indirect input and one that records or checks an indirect output.
A unit test exercises an order service that reads exchange rates from an external provider. The test supplies a fixed exchange rate without calling the provider. What is this test double doing?
A stub returns controlled data to the code under test, making the test repeatable without the external service. The strongest distractor is a spy: a spy records interactions, which could be useful in the same test, but the described role is providing the exchange-rate response.
Use controlled dependencies when the test is meant to isolate the service's decision-making. Also retain tests against real integrations where appropriate: a stub cannot reveal that the external provider's actual interface or behaviour has changed.
Question 5 checks what regression testing is intended to establish after a change.
A developer changes the tax calculation in a checkout system. What is the main purpose of running regression tests?
Regression tests check whether a change has unintentionally damaged existing behaviour. The strongest distractor is proving the implementation has no defects: a passing test suite provides evidence about the cases tested, not proof that all defects are absent.
Regression tests should include the changed calculation and nearby behaviour that could be affected, such as rounding, refunds or boundary values. The exact cases depend on the rules the system is meant to implement; tests cannot determine whether a business rule is correct unless that rule has been established separately.
Question 6 tests a practical response to a failed continuous integration build.
A shared continuous integration pipeline fails immediately after a change is merged. What is the best first response?
A failed shared build signals that the integrated code may be broken or that a check needs investigation. Finding the cause promptly limits uncertainty for the whole team. The strongest distractor is relying on the author's computer: a local success does not explain or resolve a failure in the shared environment.
A useful team practice is to keep the main branch in a known state and make build failures visible to the people who can act on them. If investigation shows the check itself is faulty, fix or quarantine it transparently rather than silently treating the failure as a pass.
Estimation, change and security
Question 7 tests what relative estimation with story points is meant to communicate.
A team estimates a backlog item at 8 story points. Which interpretation is most appropriate?
Story points are a team's relative measure, often reflecting effort, complexity and uncertainty; they are not a universal time unit. The strongest distractor is eight hours, because teams may use past delivery data to plan, but a point value does not itself convert directly to hours.
Point scales are useful only in the context of the team that created them. Avoid comparing point totals between teams or using a single estimate as a delivery guarantee. For planning, use the team's own historical throughput alongside uncertainty and dependencies.
Question 8 checks how to handle a change request without losing traceability.
A stakeholder asks for an additional export format after development has started. What should the team do first?
A change should be understood and prioritised with its impact visible, then reflected in the agreed work and plan if accepted. The strongest distractor is rejecting all late changes: uncontrolled changes are risky, but a blanket refusal ignores legitimate new information and business value.
The assessment should include effects on scope, existing commitments, design, testing and any dependent work. A team can then make an explicit trade-off rather than letting an apparently small request enter the product unnoticed.
Question 9 tests the role of acceptance criteria in making a user story verifiable.
A story says, 'As a customer, I want to reset my password so that I can regain access.' What would make its acceptance criteria most useful?
Observable outcomes let the team and tester agree what counts as satisfying the story, including important boundary and error cases. The strongest distractor is repeating the story: it restates intent but does not define how to verify the behaviour.
Good criteria should be specific enough to guide implementation and testing without dictating unnecessary internal design. Consider the normal path, invalid input, expiry and security-sensitive behaviour, then confirm that the criteria match the product's requirements.
Question 10 checks a fundamental access-control principle.
A reporting service needs read-only access to customer records. Which permission design follows the principle of least privilege?
Least privilege means granting only the access needed for the service's stated task, limited to the relevant data and operations. The strongest distractor is administrator access for convenience: it adds unnecessary capability and increases the harm possible if the service or its credentials are compromised.
Apply the same reasoning to human accounts, service credentials and test environments. Review access when responsibilities change, and avoid treating a written instruction not to use excess permissions as a substitute for restricting those permissions.
Review what you missed
After answering, group errors by concept rather than by question number. A wrong answer about test doubles suggests revisiting test isolation; confusion about availability points to requirements and measurement; choosing administrator access indicates a need to review access-control principles. For each error, write one corrected rule and one example that would help you recognise the principle in a different scenario.
A short review of recurring weak areas might look like this:
Use the lowest-scoring area to choose what to study next, but check that the number of attempts is meaningful: a percentage based on one question is weak evidence. Turn a repeated mistake into a concise prompt that tests the rule, not the wording of this particular question.
A reminder from a repeated missed mark could be phrased like this:
You lost this mark twice: what does a stub provide to the code under test, and how does that differ from a spy?
How MySummaries helps
Build a revision board from your software engineering notes, then use it to generate practice questions and review cards from the areas you missed. Open MySummaries to work from your own material.