Software Engineering / SDLC / Agile MCQ

Explanation

SDLC (Software Development Life Cycle) describes the structured process of planning, creating, testing, and deploying software.

Explanation

Most SDLC models begin with gathering and analyzing requirements to understand what the software needs to do before any design or coding begins.

Explanation

The Waterfall model follows a strict, linear progression through phases, with each phase depending on the completion and sign-off of the previous one — making it simple but inflexible to changing requirements.

Explanation

Agile development breaks work into small, iterative cycles (sprints), allowing teams to adapt to changing requirements and deliver value incrementally, in contrast to the rigid, linear Waterfall approach.

Explanation

Sprints are time-boxed iterations in Scrum during which a team commits to completing a specific set of work, ending with a review and retrospective before the next sprint begins.

Explanation

The Product Owner manages the product backlog, ensuring it reflects business priorities, and works closely with stakeholders and the development team to maximize the value delivered.

Explanation

The Scrum Master is a servant-leader who coaches the team on Scrum practices, facilitates meetings, and helps remove impediments, but does not direct the team's work like a traditional manager.

Explanation

User stories capture requirements in simple, user-focused language, helping teams understand the value behind a feature without prescribing the exact implementation details.

Explanation

The product backlog is a continuously evolving, prioritized list maintained by the Product Owner, representing everything that might be needed in the product.

Explanation

Daily standups (typically 15 minutes) keep the team synchronized, surface blockers early, and promote transparency without requiring lengthy status meetings.

Explanation

Version control systems like Git track every change made to a codebase, enabling collaboration, history tracking, branching for parallel work, and the ability to roll back to earlier states.

Explanation

Requirements specifications capture what stakeholders need from the system, providing a shared understanding that guides design, implementation, and validation throughout development.

Explanation

Functional requirements specify concrete features (e.g., "users can reset their password"), while non-functional requirements specify quality attributes (e.g., "the system must respond within 2 seconds").

Explanation

Testing involves executing a program or system with the intent of finding errors, verifying that it satisfies specified requirements, and assessing overall quality before release.

Explanation

Bugs are deviations between the actual and expected behavior of software, often discovered during testing or use, and tracked through a bug-tracking or issue-tracking system.

Explanation

Good documentation (technical docs, API references, user guides, code comments) reduces onboarding time, aids maintenance, and ensures knowledge isn't lost when team members change.

Explanation

Maintenance is often the longest phase of a software product's life, encompassing corrective fixes, adaptive changes (e.g., for new OS versions), and enhancements based on user feedback.

Explanation

The V-model pairs each development stage (e.g., requirements, design) with a corresponding test stage (e.g., acceptance testing, system testing), emphasizing early test planning alongside development activities.

Explanation

An MVP allows teams to validate assumptions and gather real user feedback quickly, with minimal development investment, before committing to building out a full feature set.

Explanation

Pair programming aims to improve code quality and knowledge sharing through continuous review, with the driver and navigator roles often switching periodically.

Explanation

By integrating and testing code changes frequently (often multiple times a day), CI helps catch integration issues and bugs early, before they compound into larger problems.

Explanation

Continuous delivery keeps the codebase always ready for release (with a manual "go" step), while continuous deployment goes further by automatically pushing every validated change to production without manual intervention.

Explanation

Stakeholders can include customers, end users, project sponsors, managers, and the development team — anyone whose interests should be considered when making project decisions.

Explanation

Use cases capture functional requirements from a user's perspective, describing interactions between actors (users or systems) and the system to accomplish specific goals.

Explanation

Code reviews help catch bugs, enforce coding standards, share knowledge across the team, and improve overall code quality before changes are merged into the main codebase.

Explanation

Technical debt accumulates when shortcuts are taken during development (e.g., skipping tests, hardcoding values); over time, this debt must be "paid down" through refactoring or it can slow future development.

Explanation

Retrospectives foster continuous improvement by giving the team a regular, structured opportunity to discuss their process and identify actionable changes for the next sprint.

Explanation

Unlike Scrum, Kanban doesn't use fixed-length sprints; instead, it focuses on visualizing workflow, limiting work-in-progress (WIP), and continuously delivering work as capacity allows.

Explanation

Refactoring improves the internal structure of code (e.g., renaming variables, extracting functions, removing duplication) while preserving its observable behavior, making future changes easier and safer.

Explanation

Scope creep often results from poorly defined requirements or lack of change control, leading to delays, budget overruns, and reduced quality if not managed properly.

Explanation

Verification is often associated with activities like code reviews and unit testing against specifications, while validation involves checking the final product against actual user needs, often through acceptance testing.

Explanation

Pseudocode helps developers plan and communicate algorithm logic in a readable way without worrying about exact syntax of a specific programming language.

Explanation

Clear acceptance criteria help the development team understand exactly what "done" means for a story and provide a basis for testing whether the implementation meets expectations.

Explanation

Prototypes allow stakeholders to visualize and interact with early versions of a system, helping refine requirements and reduce the risk of building the wrong thing.

Explanation

QA engineers design and execute test cases, report defects, and work closely with developers to ensure the final product meets quality standards.

Explanation

Burndown charts plot remaining work (e.g., story points or hours) over the sprint timeline, helping teams visualize whether they are on track to complete planned work.

Explanation

Distinguishing features from bug fixes helps with release planning, changelog organization, and prioritization, since bug fixes often address user-impacting issues while features add new value.

Explanation

The DRY principle encourages extracting repeated logic into reusable functions, classes, or modules, reducing duplication and making maintenance easier since changes only need to be made in one place.

Explanation

Issue trackers provide visibility into the status of bugs, features, and tasks, supporting prioritization, assignment, and progress tracking across a team.

Explanation

Cross-functional teams reduce handoffs and dependencies on external teams, enabling faster delivery and better collaboration since all necessary skills are present within the team.

Explanation

The Waterfall model's rigid, sequential nature makes it poorly suited to projects where requirements evolve, since changes discovered late often require expensive rework of earlier phases like design or even requirements.

Explanation

Story points abstract away individual differences in speed and allow teams to compare relative effort/complexity between stories, often using scales like Fibonacci numbers, which can lead to more consistent estimation over time through team calibration.

Explanation

By having team members reveal estimates simultaneously (avoiding anchoring bias) and then discussing significant differences, Planning Poker helps surface differing assumptions and leads to more accurate, shared understanding of a story's complexity.

Explanation

Velocity is calculated by summing the story points of completed work in past sprints, and averaging it over several sprints can help teams forecast future capacity for release planning — though it should not be used to compare different teams.

Explanation

A clear DoD (e.g., code reviewed, tests passing, documentation updated) prevents disagreements about whether work is truly complete and helps maintain consistent quality standards across the team.

Explanation

Kanban's explicit WIP limits on each column help identify bottlenecks and maintain a steady flow of work, whereas Scrum organizes work into time-boxed sprints with a committed backlog for that period.

Explanation

Spikes are used to reduce uncertainty — for example, researching a new technology or prototyping an approach — before committing to estimates or implementation for related stories.

Explanation

Epics provide a way to group related user stories under a larger theme or initiative, helping teams and stakeholders understand how individual stories contribute to bigger goals.

Explanation

The red-green-refactor cycle of TDD encourages writing only the code necessary to satisfy tests, which can lead to better-designed, more testable code and a comprehensive automated test suite as a byproduct.

Explanation

These testing levels form a hierarchy of increasing scope — from testing small isolated pieces (units), to verifying interactions between components (integration), to validating the whole system against requirements (system testing).

Explanation

As code evolves, regression tests help catch unintended side effects of changes, ensuring that fixes or new features don't reintroduce previously fixed bugs or break existing functionality.

Explanation

Design patterns (like Singleton, Factory, Observer) capture proven solutions to recurring design problems, providing a shared vocabulary and starting point that developers can adapt to their specific situation.

Explanation

Static analysis tools like linters and security scanners examine code structure and patterns to catch issues early in development, before the code is even run, complementing dynamic testing approaches.

Explanation

Feature flags decouple deployment from release, allowing teams to merge code continuously while controlling when and to whom features are exposed, and providing a quick "kill switch" if issues arise.

Explanation

Code freezes reduce the risk of introducing new, untested issues right before a release, giving QA teams a stable target to validate against.

Explanation

White-box testing (e.g., unit tests examining code paths) leverages internal knowledge to design thorough tests, while black-box testing (e.g., acceptance tests) evaluates the system purely from an external, user-facing perspective.

Explanation

Exploratory testing is particularly useful for finding unexpected issues that scripted tests might miss, as testers use creativity and domain knowledge to probe the application in unscripted ways.

Explanation

Non-functional requirements often drive significant architectural decisions early in a project, since retrofitting scalability or security into a poorly suited architecture can be far more costly than designing for them upfront.

Explanation

By focusing testing effort on areas most likely to fail or that would have the greatest impact if they did, risk-based testing helps teams use limited time and resources more effectively.

Explanation

While useful for identifying gaps in testing, code coverage is a quantity metric, not a quality metric — tests can achieve high coverage while still failing to verify important behaviors or edge cases.

Explanation

RACI matrices help avoid confusion about ownership and decision-making by clearly defining each stakeholder's role in relation to specific tasks or deliverables.

Explanation

The SOLID principles, popularized by Robert C. Martin, provide guidelines aimed at reducing coupling and increasing cohesion in object-oriented designs, making systems easier to extend and maintain over time.

Explanation

Smoke tests act as a quick "sanity check" — if they fail, the build is often rejected immediately without proceeding to more time-consuming detailed testing.

Explanation

Different strategies (e.g., Git Flow with long-lived release/develop branches vs. trunk-based development with frequent merges to a main branch) trade off isolation for integration frequency, impacting how easily CI/CD can be implemented.

Explanation

Load testing helps verify the system meets performance requirements under realistic conditions, while stress testing reveals how the system fails under extreme load and whether it can recover gracefully afterward.

Explanation

While formal inspections (like Fagan inspections) follow strict, documented processes, informal peer/buddy reviews offer a faster, lower-overhead way to catch issues, often used for day-to-day code review on pull requests.

Explanation

UAT provides confidence that the software satisfies business requirements and user expectations from the perspective of those who will actually use it, often serving as a final gate before release.

Explanation

Configuration management ensures that the state of software, infrastructure, and environments is known and reproducible, which is critical for debugging, audits, and reliable deployments.

Explanation

In practice, Agile methods often combine both: building functionality incrementally (one feature at a time) while iterating on the design and implementation of each piece based on feedback.

Explanation

By digging into why an issue truly occurred (e.g., using techniques like the "5 Whys"), teams can implement fixes that prevent recurrence, rather than just patching the immediate symptom.

Explanation

Pair-wise testing dramatically reduces the number of test cases needed compared to exhaustive combinatorial testing, while still catching many defects caused by interactions between pairs of parameters.

Explanation

Understanding stakeholders' needs, priorities, and potential conflicts early helps shape requirements, communication plans, and risk management strategies throughout the project.

Explanation

Early and frequent feedback loops (e.g., sprint reviews, demos, user testing) help catch misunderstandings or changing needs sooner, reducing the cost of correcting course compared to discovering issues at the end of a long project.

Explanation

ADRs help future team members understand why certain architectural choices were made, preventing repeated debates and providing context that might otherwise be lost as team membership changes over time.

Explanation

Automated CI tests provide fast, consistent feedback on known scenarios with every code change, while exploratory testing leverages human intuition to probe for unexpected issues — both play complementary roles in a quality strategy.

Explanation

By accounting for known absences and historical velocity, capacity planning helps teams commit to realistic amounts of work, reducing the risk of over-committing and missing sprint goals.

Explanation

Defects found earlier in the lifecycle (e.g., during design or coding) are generally far cheaper to fix than those discovered late, after release — shift-left testing aims to capture issues as early as possible.

Explanation

While TDD focuses on driving design through unit-level tests written by developers, BDD emphasizes describing behavior in business-readable language, helping bridge communication gaps between technical and non-technical team members.

Explanation

Large stories ("epics") that can't be completed within a sprint are hard to estimate and track; splitting them into smaller vertical slices (each still delivering some user value) improves predictability and flow.

Explanation

Pull requests provide a structured checkpoint for code review, automated CI checks (tests, linting), and discussion before changes are merged, helping maintain code quality and shared understanding across the team.

Explanation

Recognizing that early estimates are inherently uncertain (sometimes by 4x or more in either direction) supports Agile's preference for rolling-wave planning and re-estimation as more is learned, rather than locking in detailed estimates at project inception.

Explanation

This insight underlies approaches like the "Inverse Conway Maneuver," where organizations deliberately restructure teams to encourage a desired architecture (e.g., creating small, autonomous teams to encourage microservices boundaries).

Explanation

Frameworks like SAFe address challenges of scaling Agile to large organizations — coordinating dependencies, aligning multiple teams toward common goals, and providing governance — that aren't addressed by Scrum at the single-team level.

Explanation

A test suite with high code coverage might still fail to actually assert meaningful outcomes; mutation testing reveals this by checking if introduced faults ("mutants") cause test failures — if a mutant survives (tests still pass), it indicates a gap in test effectiveness.

Explanation

This distinction (popularized by Fred Brooks) helps teams focus improvement efforts: while essential complexity (e.g., the inherent complexity of tax calculation rules) must be managed, accidental complexity (e.g., convoluted build processes) is often a target for simplification.

Explanation

Without clear ownership, having many "optional" reviewers can paradoxically reduce review quality, as each person assumes someone else will catch issues — explicit primary-reviewer assignment helps counteract this.

Explanation

This is a key reason velocity is recommended only for forecasting within a single team over time, not for cross-team comparisons or as a performance target — doing so incentivizes gaming the metric rather than improving real delivery.

Explanation

Recognizing that less-experienced estimators may not know what they don't know helps teams structure estimation processes (e.g., group discussions, reference-class forecasting) to surface hidden risks that individuals might overlook.

Explanation

Lead time reflects the customer's perspective (total wait time for a request), while cycle time reflects the team's processing efficiency once work begins — both are useful for identifying different types of delays in a delivery pipeline.

Explanation

By fixing time (sprint length) and cost (team composition) while treating scope as the flexible variable, Agile approaches aim to maintain a sustainable pace and consistent quality, adjusting what gets delivered rather than extending deadlines or adding resources under pressure.

Explanation

From "The Mythical Man-Month," this principle highlights that software development isn't always parallelizable like, say, digging a ditch — new team members add coordination costs that can outweigh their contribution in the short term, especially on already-delayed projects.

Explanation

By proactively testing how systems respond to real failure conditions (rather than only testing "happy path" scenarios), chaos engineering helps teams build more resilient systems and validate recovery procedures, complementing earlier-stage testing like unit and integration tests.

Explanation

DORA (DevOps Research and Assessment) metrics like deployment frequency and change failure rate are often considered leading indicators of organizational performance, providing actionable signals earlier than lagging business outcomes like customer retention.

Explanation

Named after a vine that gradually grows around and eventually replaces a host tree, this pattern reduces the risk of "big bang" rewrites by allowing incremental migration, with the ability to fall back to legacy functionality if issues arise during transition.

Explanation

A blameless culture encourages people to share full details about their actions during an incident (even mistakes) because the goal is systemic improvement, not individual punishment — which ultimately leads to better identification of true root causes and more effective preventive measures.

Explanation

WSJF (used in frameworks like SAFe) helps portfolios sequence work to maximize economic outcomes by favoring items with high cost-of-delay relative to their size — that is, things that are both valuable and quick to deliver get prioritized.

Explanation

By separating "deploying code" from "releasing a feature to users," teams can validate new code in production with limited exposure (e.g., to internal users or a small percentage of traffic) before a full release, significantly reducing the blast radius of potential issues.

Explanation

By clarifying team interaction modes (collaboration, X-as-a-service, facilitating) and team types, the Team Topologies model helps organizations design team structures that reduce unnecessary dependencies and cognitive overload as they scale.

Explanation

Contract testing allows teams to verify API compatibility between services in isolation, providing faster feedback than full end-to-end tests and reducing the tight coordination needed between teams deploying interdependent services.

Explanation

Because trunk-based development relies on frequent integration of small changes, strong CI practices (fast automated tests, feature flags for incomplete work) are essential to maintain a working main branch and quickly catch any regressions introduced by the constant stream of changes.