Software Development Concepts practice questions

Logging

Why it fails: Logging writes messages to a log file, not breakpoints.

Unit testing

Why it fails: Unit testing is automated testing, not a debugging technique.

Code review

Why it fails: Code review is a manual inspection by peers.

Daily scrum

Why it fails: The daily scrum inspects progress toward the sprint goal and adapts the plan, but it produces no increment for stakeholders to inspect, so it does not deliver the product feedback the stem seeks. It is tempting because it is a genuine Scrum event held every working day, yet its inspection is internal to the developers.

Product backlog grooming

Why it fails: Product backlog grooming is a continuous refinement activity, not one of Scrum's five formal events, so it is not scheduled as an inspection opportunity. It is tempting because refinement does gather input on upcoming items, but the framework's feedback events are the sprint review, retrospective, daily scrum and sprint planning.

Sprint planning

Why it fails: Sprint planning produces the sprint goal and selected backlog items, but inspection of an increment requires something built to inspect; no working product exists yet at this point. It is tempting because planning is a formal Scrum event, yet feedback events require an increment, which Sprint review and Sprint retrospective provide.

Unit testing

Why it fails: Unit testing tests individual components, not the entire system or regression.

Integration testing

Why it fails: Integration testing checks interactions between components, not the full system.

User acceptance testing

Why it fails: UAT is performed by users, not typically by the development team for regression.

Smoke testing

Why it fails: Smoke testing is a preliminary test to check basic functionality, not a comprehensive type.

Alpha testing

Why it fails: Alpha testing is a type of acceptance testing, not typically categorized with unit/integration/system.

Spiral

Why it fails: Spiral repeats risk-driven iterations through planning, risk analysis, engineering, and evaluation, so requirements can still evolve between loops. It tempts as a structured lifecycle model, but the stem's one-pass sequential phases with frozen requirements describe Waterfall.

Scrum

Why it fails: Scrum is iterative and incremental, with requirements refined each sprint, so it cannot describe fixed sequential phases with locked requirements. It is tempting because Scrum also structures work into time-boxed increments, but those increments repeat rather than progress once through requirements, design, implementation, testing and deployment.

Agile

Why it fails: Agile delivers work in short iterative increments with evolving requirements, the opposite of fixed sequential phases. It tempts because it dominates modern practise, but the stem's rigid waterfall-style phases and resistance to change describe Waterfall, not Agile.

Waterfall

Why it fails: Waterfall runs sequential phases — requirements, design, build, test — with a single delivery at the end, so it has no two-week timebox, no daily standup and no per-iteration stakeholder demo. It is tempting because it suits fixed-scope projects with stable requirements and contractual milestones, where change is controlled rather than welcomed.

V-Model

Why it fails: The V-Model pairs each development stage with a corresponding test level in a linear sequence, delivering once at the end rather than in two-week increments with daily standups. It is tempting because it fits safety-critical or regulated work needing documented verification at every stage, where traceability matters more than iterative feedback.

Kanban

Why it fails: Kanban visualises workflow and limits work in progress on a continuous flow; it prescribes no fixed two-week iteration, no effort-based selection of a committed set, and no end-of-iteration demo. It is tempting because it suits support or maintenance teams handling unpredictable arrival of work items where continuous delivery beats timeboxing.

Pseudocode

Why it fails: Pseudocode is an informal, human-readable notation for expressing logic, not the procedure itself. It is tempting because the steps resemble pseudocode's plain-language style, but pseudocode is a way of writing an algorithm down, not the algorithm being described.

Flowchart

Why it fails: A flowchart is a diagrammatic representation using symbols and arrows, not a textual step-by-step procedure. It is tempting because the steps could be drawn as a flowchart, but a flowchart is a visual notation for an algorithm, not the algorithm itself.

Data structure

Why it fails: A data structure is a way of organising and storing data, such as an array or linked list, not a sequence of steps. It is tempting because the array being sorted is itself a data structure, but the described compare-and-swap procedure is an algorithm.

Pseudocode

Why it fails: Pseudocode expresses logic in structured natural-language statements, not in standardised graphical symbols, so it cannot supply decision diamonds or process rectangles. It is tempting because it does capture conditions and actions precisely, but the question explicitly requires a visual representation using those flowchart symbols.

Data flow diagram

Why it fails: A data flow diagram models how data moves between external entities, processes and data stores; it has no decision diamonds or process rectangles for branching logic. It is tempting because it does depict processes, but flowchart notation is the standardised tool for representing conditions and actions such as membership tests and discount application.

UML class diagram

Why it fails: A UML class diagram depicts classes, attributes, methods and their static relationships such as inheritance and association; it cannot express sequential conditions or actions. It is tempting because UML is a recognised modelling standard, but activity or flowchart notation is what represents decision diamonds and process rectangles for eligibility logic.

Array

Why it fails: An array indexes elements by numeric position, so retrieving a grade by student name requires a linear search rather than direct lookup. It is tempting because arrays suit ordered lists traversed sequentially, such as storing marks in roll-number order where positional access suffices.

Queue

Why it fails: A queue enforces first-in-first-out ordering, exposing only the head and tail, so no mechanism retrieves a grade by student name. It is tempting because queues correctly model ordered processing, such as print jobs or packet buffers awaiting sequential handling.

Stack

Why it fails: A stack only exposes the most recently pushed element, so retrieving a grade by student name requires popping entries until the match is found. It is tempting because stacks store collections, and one would be correct when the requirement is last-in-first-out processing such as undo operations.

Integration testing

Why it fails: Integration testing exercises interactions and data flow between two or more combined units, so it requires the very dependencies the stem says are isolated. It is tempting because it sits between unit and system testing, and would be correct when verifying that interfaces between modules pass data correctly.

User acceptance testing

Why it fails: User acceptance testing confirms the delivered system meets business needs and is performed by end users against real-world scenarios, not by a tester checking function return values in isolation. It is tempting as the final sign-off gate, and would be correct when validating fitness for purpose before go-live.

System testing

Why it fails: System testing validates the complete, integrated application against end-to-end requirements, so it cannot isolate individual functions. It is tempting because it is the final verification stage before release, and would be correct when confirming that whole workflows behave as specified across all modules together.

Integration testing

Why it fails: Integration testing verifies interactions between combined modules or services, not that previously working features still function after a change. It tempts because deployed applications involve component interfaces, but the stem describes re-running old test cases, which defines regression testing.

Smoke testing

Why it fails: Smoke testing verifies that a build's core functions work before deeper testing, so it confirms stability rather than re-checking previously passing cases. Regression testing is the correct type here, re-running old test cases after changes to catch unintended side effects. Smoke testing would be the right choice on a fresh build before committing to full test execution.

Acceptance testing

Why it fails: Acceptance testing validates that the system meets business and user requirements for release, not that prior functionality survived changes. It tempts because it occurs around deployment, but the described goal — catching unintended side effects — is regression testing's purpose.

Implementation

Why it fails: Implementation is the coding, configuration and deployment of the solution, occurring after design is complete. It is tempting because project plans are executed here, but the stem places the phase before design and coding, so no build activity has started.

Analysis

Why it fails: Analysis covers feasibility studies, requirements gathering and functional specification, but the stem's scope definition and project plan belong to planning, which precedes analysis. Analysis is tempting because it also handles requirements, yet it produces the specification rather than the schedule and boundaries.

Design

Why it fails: Design translates approved requirements into architecture, interfaces and data models, so it follows the requirements and planning work described. It is tempting as the next logical step, but the stem explicitly states the phase occurs before any design begins, ruling it out.

Committing

Why it fails: Committing records staged changes into the local repository history; it does not combine one branch into another. It is tempting because commits precede integration. Committing would be the correct answer if the question asked how to save changes to the current branch.

Forking

Why it fails: Forking copies an entire repository, typically server-side, into a separate project under another owner; it does not integrate a feature branch into main. It is tempting because forks also create divergent lines. Forking would be correct when contributing to a project you lack write access to.

Branching

Why it fails: Branching creates a divergent line of development from an existing commit; it does not merge changes back into the main branch. It is tempting because the stem describes creating a branch. Branching would be correct if the question asked how to isolate work on a new feature.

GraphQL API

Why it fails: GraphQL exposes a single endpoint where clients specify query fields, rather than a fixed REST-style resource returning JSON for a simple HTTP GET. It is tempting because it also returns JSON, and it would be correct when the client needs to request precisely selected fields across related datasets.

WebSocket

Why it fails: WebSocket provides a persistent, full-duplex connection after an HTTP upgrade handshake, not the request-response JSON retrieval described, and it has no API-key header authentication model. It is tempting because it also runs over HTTP, and it would be correct for live streaming updates such as real-time weather push notifications.

SOAP API

Why it fails: SOAP exchanges XML envelopes over HTTP with a WSDL contract, so it does not return JSON payloads as described. It is tempting because it is also a web service accessed over HTTP, and it would be correct for enterprise systems requiring WS-Security and formal schema-defined messaging.

Scrum Master

Why it fails: The Scrum Master coaches the team on Scrum, removes impediments and facilitates events, but does not prioritise the Product Backlog. It is tempting because the Scrum Master safeguards the process, yet ordering backlog items to maximise value is the Product Owner's accountability, not a facilitation or coaching duty.

Development Team

Why it fails: The Development Team self-organises to deliver the Sprint Backlog, but does not order the Product Backlog; that accountability sits with the Product Owner. It is tempting because developers understand technical value and dependencies, yet Scrum assigns backlog prioritisation solely to the Product Owner to maximise product value.

Stakeholder

Why it fails: Stakeholders provide feedback and requirements but hold no backlog authority in Scrum; ordering the Product Backlog is the Product Owner's accountability. It is tempting because stakeholders represent business value, yet they influence priorities only through the Product Owner, who alone ensures the team works on the highest-value items.

Sequential phases (requirements→design→implementation)

Why it fails: Sequential requirements-to-design-to-implementation phases describe waterfall's linear lifecycle, where each stage completes before the next begins. That model is genuinely appropriate for stable, well-understood requirements with heavy compliance gates. Agile instead delivers working increments iteratively, revisiting requirements, design and code each sprint.

Fixed scope defined at the start

Why it fails: Agile deliberately welcomes changing requirements throughout delivery, so scope is continuously reprioritised rather than frozen. Fixed upfront scope is genuinely appropriate for plan-driven waterfall contracts with firm regulatory or contractual baselines. Agile instead fixes time and cost per iteration while allowing scope to flex.

Comprehensive documentation at each phase

Why it fails: Agile values working software over comprehensive documentation, producing documentation only where it adds value rather than at every phase. Phase-gated documentation is genuinely appropriate for safety-critical or audited waterfall projects. Agile instead favours lightweight artefacts, continuous feedback and just-enough up-front specification.

Define a class named Calculator

Why it fails: Pseudocode is language-agnostic and typically avoids class definitions.

Execute SQL query to retrieve numbers from database

Why it fails: Pseudocode focuses on logic, not database queries.

Maintenance

Why it fails: Maintenance is an SDLC phase occurring after deployment, not a testing level; testing levels are defined by scope, from unit through acceptance. It is tempting because regression testing happens during maintenance, and would be correct if the question asked which phase follows implementation.

Code review

Why it fails: Code review is a static inspection activity performed by peers, not a level of testing such as unit, integration, system or acceptance. It is tempting because it finds defects early in the SDLC, and would be correct if the question asked about verification techniques rather than testing levels.

Deployment

Why it fails: Deployment is the SDLC phase that releases software into production, not a testing level defined by scope. It is tempting because acceptance testing often precedes it, and would be correct if the question asked which phase follows system testing in the lifecycle.

Spiral

Why it fails: Spiral suits large, high-risk projects needing repeated risk analysis across evolutionary releases; here requirements are already well-understood, so its risk-driven iterations add overhead without benefit. It is tempting because it handles changing scope, but this project has fixed scope and budget, which a predictive waterfall approach fits.

Scrum

Why it fails: Scrum delivers value through short sprints that welcome changing requirements, so it does not match a fixed-scope, fixed-budget project with requirements already understood. It is tempting because it is the dominant Agile framework, and would be correct where priorities shift frequently and scope is deliberately emergent.

Agile

Why it fails: Agile embraces evolving requirements and iterative delivery, which conflicts with this project's fixed scope and fully understood requirements. It is tempting because Agile is widely adopted for app development, and would be correct where customer needs are unclear or expected to change during delivery.

API

Why it fails: An API is an interface contract letting software components exchange requests and responses; the pseudocode contains no endpoints, calls or data exchange, only iteration and comparison. APIs suit integrating separate services, whereas this logic is an algorithm — a finite sequence of steps producing the maximum value.

Data structure

Why it fails: A data structure is a way of organising data, such as an array, list or tree; the list here is merely input, and the pseudocode describes the procedure operating on it, not the structure itself. Data structures suit choosing storage with particular access characteristics, not expressing a step-by-step computation.

Flowchart

Why it fails: A flowchart is a diagrammatic notation using standard symbols to depict process flow; this text is pseudocode, a written algorithmic description, not a visual diagram. Flowcharts suit communicating or documenting process logic graphically, whereas the question asks which programming concept the written steps represent — an algorithm.