Text preview & study summary

Software Development Life Cycle SDLC

A free sample of 5 questions from this quiz, shown in full with answer choices and explanations. No interactivity — everything is visible on this page for study and review.

Want to test your knowledge? Launch the Interactive Exam Simulator

Question 1

Which of the following are core phases typically found across most SDLC models? *(Select ALL that apply)*

Answer choices

  • A. Requirements/Planning (Correct)

  • B. Design (Correct)

  • C. Marketing and Sales

  • D. Implementation (Coding) (Correct)

  • E. Testing/Quality Assurance (Correct)

Explanation

While specific SDLC models vary in structure, most include these core phases: (A) Requirements/Planning — defining what needs to be built; (B) Design — architecture and system design; (D) Implementation — actual coding; (E) Testing/QA — verifying functionality. Most models also include Deployment and Maintenance phases. Marketing/Sales (C) and HR onboarding (F) are business functions, not SDLC phases — though they may happen in parallel with software projects.

Question 2

In Scrum, the team member responsible for maximizing the value of the product by managing and prioritizing the Product Backlog is called the [[blank1]] [[blank2]].

Explanation

The Product Owner (PO) is a key Scrum role responsible for: defining and prioritizing the Product Backlog, writing user stories and acceptance criteria, acting as the voice of the customer/business, and accepting or rejecting completed work. The PO bridges the gap between the development team and business stakeholders. The other two primary Scrum roles are the Scrum Master (facilitator) and the Development Team.

Question 3

Which of the following are recognized types of software testing? *(Select ALL that apply)*

Answer choices

  • A. Unit testing (Correct)

  • B. Integration testing (Correct)

  • C. Regression testing (Correct)

  • D. Penetration testing (Correct)

  • E. Marketing testing

Explanation

Software testing types: Unit testing — tests individual functions/modules in isolation; Integration testing — tests how modules work together; Regression testing — verifies that new changes haven't broken existing functionality; Penetration testing — simulates attacks to find security vulnerabilities; UAT — end users verify the system meets requirements before release. "Marketing testing" (A/B testing) is a business concept, not a software QA methodology.

Question 4

What is the "Definition of Done" (DoD) in Scrum?

Answer choices

  • A. The project completion date agreed upon by the client

  • B. A formal checklist or shared understanding of all criteria that must be met for a user story or sprint to be considered complete (Correct)

  • C. A document listing the minimum viable features required for product launch

  • D. The Scrum Master's approval signature on completed sprint work

Explanation

The Definition of Done (DoD) is a shared agreement among the Scrum team about what "done" means for any piece of work. It might include: code written, unit tests passing, code reviewed and merged, integration tests passing, documentation updated, and product owner acceptance. The DoD ensures consistency and quality — preventing "mostly done" work from being called complete. It is created by the team and evolves over time. Without a DoD, teams have inconsistent quality standards and accumulate technical debt.

Question 5

**Statement:** A "use case" in software development describes a specific way a user interacts with the system to achieve a goal, typically written from the user's perspective.

Answer choices

  • A. True (Correct)

  • B. False

Explanation

A use case describes a sequence of interactions between a user (actor) and the system to accomplish a specific goal. For example: "Use Case: Withdraw Cash from ATM — Actor: Bank Customer — Main Flow: 1) Insert card, 2) Enter PIN, 3) Select 'Withdraw', 4) Enter amount, 5) Receive cash." Use cases were popularized by Ivar Jacobson and are part of UML (Unified Modeling Language). They are especially common in requirements gathering for complex systems.