2. SDLC & QA's Role in It

The Software Development Life Cycle (SDLC) is a structured process used by development teams to design, develop, test, and deploy software applications. It provides a systematic framework that helps ensure high-quality software delivery.

📌 QA is embedded throughout SDLC to prevent defects, ensure standards, and validate outcomes.

The Software Development Life Cycle (SDLC) is a methodical process that guides teams through software development. The main stages include designing, developing, testing, and finally deploying software applications. By following SDLC, teams can systematically manage their work, ensuring that every aspect of the software meets quality and performance standards. Quality Assurance (QA) plays a critical role in this cycle, integrated throughout to minimize errors and uphold quality.

Think of SDLC like a recipe for baking a cake. Each step, from mixing ingredients to baking and cooling, must be carefully followed to ensure the cake turns out well. Similarly, each phase of SDLC must be executed properly to create effective software, and just like a chef might taste the batter along the way, QA checks for issues during each stage.

1. Waterfall Model

Definition: A linear, step-by-step model where each phase must be completed before the next begins.

Phase Description

• Requirements: Gather and document all requirements
• Design: Define system architecture and design
• Development: Build the software
• Testing: QA team tests the software
• Deployment: Release to production
• Maintenance: Fix issues and make minor enhancements

QA Role in Waterfall: ● QA is usually involved after development, making early defect prevention difficult. ● Requirements and test plans are finalized upfront.

Pros: ● Easy to manage, well-documented Cons: ● Inflexible to changes, late QA involvement

The Waterfall Model is a traditional approach to software development where each phase must be completed before proceeding to the next one. This structure makes it easy to manage and document the process. However, the downside is that if changes are needed after a phase is completed, it can be complicated to go back, especially since QA typically does not get involved until the testing phase, which can lead to discovering defects late in the process.

Imagine building a house using the Waterfall Model. First, you lay the foundation (requirements), then build the walls (design), and finally add the roof (development). If you realize later, after the house is built, that you wanted more windows, it’s expensive and difficult to make those changes. Similarly, in software, late-stage discoveries of issues can be costly and time-consuming.

2. Agile Model

Definition: An iterative and incremental model where development is broken into sprints (usually 1–4 weeks), promoting flexibility, collaboration, and continuous delivery.

Sprint Description Activity

• Sprint Planning: Define user stories and sprint goals
• Development & QA: Dev and QA work in parallel during the sprint
• Daily Stand-up: Share progress and blockers
• Sprint Review: Demonstrate completed features
• Retrospective: Reflect on what went well and what can improve

QA Role in Agile: ● QA is involved from the beginning of each sprint ● Writes test cases alongside user stories ● Performs continuous testing (manual or automated) ● Participates in backlog grooming, reviews, and retrospectives

Pros: ● Early and continuous QA involvement ● Faster feedback, better defect prevention Cons: ● Requires high collaboration and adaptability

The Agile Model promotes a flexible and collaborative approach to software development. Work is done in short cycles, or sprints, allowing teams to adapt to changes quickly. QA is integrated throughout the process, starting from sprint planning, which helps catch defects early and improve quality. While Agile allows for faster responses to changes, it also demands that team members collaborate closely and be willing to adjust their plans frequently.

Think of Agile like a team of cooks in a restaurant who continuously prepare a menu item, allowing for immediate adjustments based on customer feedback. If they realize a dish is too salty while it's being served, they can quickly modify it. Similarly, Agile teams can make iterative improvements to the software based on feedback received during and after each sprint.

SDLC Phase QA Responsibilities

• Requirement Analysis: Review requirements for clarity, testability; identify potential gaps or risks
• Design: Review design documents; define test strategy; participate in test planning
• Development: Prepare test cases/scripts in parallel; collaborate with devs for early feedback
• Testing: Execute test cases (manual/automated); log defects; perform regression, functional tests
• Deployment: Perform sanity/smoke testing in staging/production; validate configurations
• Maintenance: Verify fixes, conduct regression tests, handle change requests

In each phase of the SDLC, QA has specific responsibilities. Starting from Requirement Analysis, QA ensures that requirements are clear and testable. During Design, they contribute to strategy and planning. In Development, they prepare tests while collaborating with developers, and in Testing, they execute and log defects. The process continues into Deployment, where sanity tests ensure everything works as intended, followed by Maintenance, where QA functions to verify fixes and handle new requests.

Picture QA in SDLC phases like a proofreader for a book. In the initial writing (Requirements), they check if the plot is clear and makes sense. As the book progresses through various drafts (Design and Development), the proofreader is involved in suggesting revisions. Finally, during the final edit (Testing and Deployment), they identify typos or inconsistencies before the book goes to print. This iterative involvement helps create a well-polished end product.

1. Day 1 – Sprint Planning → QA understands upcoming stories and starts writing test cases.

2. Day 2–7 – Development + Testing → QA begins testing completed components (continuous testing).

3. Day 8 – Sprint Review → QA confirms all stories meet acceptance criteria.

4. Day 9 – Retrospective → QA gives feedback on test coverage, bugs found, or process gaps.

In an Agile sprint, QA is actively involved from start to finish. On Day 1, during Sprint Planning, they familiarize themselves with upcoming features and start creating test cases. As development continues (Days 2-7), they perform continuous testing of completed features to ensure quality. By Day 8, they review whether the features meet all acceptance criteria during the Sprint Review. Finally, in the Retrospective on Day 9, they reflect on the process and provide valuable feedback to improve future sprints.

Think of this process as preparing for a school project in a group. On Day 1, everyone discusses their roles and outlines what they'll work on (Sprint Planning). Throughout the week, you check in on each other’s progress and help where needed (Development + Testing). At the end, you present your completed project (Sprint Review) and reflect on what went well and what could improve for the next project (Retrospective). This collaborative approach ensures that everyone contributes to making the project better.

Factor Waterfall Agile

• QA Involvement: Late (after development) Early and continuous
• Documentation: Heavy upfront Just-in-time, evolving
• Flexibility: Low High
• Feedback Loop: Long Fast
• Defect Detection: Late-stage Early-stage

Comparing Agile and Waterfall from a QA perspective highlights their key differences. In Waterfall, QA gets involved after the development phase, making it difficult to catch defects early. Documentation tends to focus on upfront requirements, leading to low flexibility and long feedback cycles. In contrast, Agile involves QA from day one. This promotes continuous collaboration, evolving documentation, and a quicker response to changes, allowing for early defect detection.

Consider planning a long road trip. Waterfall would be like mapping the entire route before you leave, making adjustments only if you encounter problems later. Agile is akin to having a GPS that updates your route continuously, allowing you to change direction based on traffic or new destinations as you travel. This adaptability in Agile leads to better preparedness and a smoother journey, just as early QA involvement leads to fewer issues later in development.

● QA is not just a phase — it’s a continuous practice across SDLC. ● In Waterfall, QA validates after development. ● In Agile, QA is embedded from day one in every sprint. ● Effective QA ensures that every phase contributes to a quality product.

"In modern SDLCs like Agile, QA is no longer a gatekeeper — it is a collaborative partner in delivering value."

The summary emphasizes that QA is integral to all phases of the SDLC rather than being a discrete step. In a Waterfall approach, QA typically checks for issues only after development is complete, while in Agile, QA is involved from the outset, significantly enhancing the overall quality of the software. This collaborative approach to QA enables teams to deliver better products more efficiently and effectively.

Think of QA's evolving role like a team sport. In traditional games, some players only participate in certain phases of the game, while in modern teams, every player is involved throughout, making sure the whole team plays together effectively. Just as a collaborative team can adapt and respond more quickly during a game, QA’s involvement from the start allows software projects to adjust and improve continually.

--