SDLC vs STLC: What Every QA Beginner Needs to Understand

You walk into your first QA job interview in Kathmandu. The interviewer asks: "Can you explain the difference between SDLC and STLC, and how they work together?" You know what SDLC stands for. You know what STLC stands for. But the moment they ask how the two connect inside a real Agile sprint, everything blurs.

This is one of the most common interview questions for QA roles in Nepal, and one of the most poorly explained topics in beginner QA content. Most guides define both terms separately, give you two lists of phases and a comparison table, and stop there. What they skip is the part that actually matters: SDLC and STLC do not run one after the other. They run in parallel. A QA engineer is involved from the first day of a sprint, not after the developers finish building.

If you are building a career in software quality, the QA career guide maps out the full path from beginner to employed in Nepal's IT market.

And if you want to practise these concepts with real tools and live projects, the Quality Assurance course at Skill Shikshya covers SDLC, STLC, Agile workflows, JIRA, Selenium, and Postman in one structured program.

What is SDLC? The Software Development Life Cycle Explained

SDLC stands for Software Development Life Cycle. It is the structured process that takes a software idea from the first business conversation all the way through to a deployed, maintained product. Every software project follows some version of SDLC, whether the team formally documents it or not.

The purpose of the software development life cycle is to give teams a repeatable, predictable framework for building software that meets user requirements, ships on schedule, and stays within budget. Without SDLC, software projects tend to drift: requirements get missed, development overlaps with undefined requirements, and testing happens too late to catch the problems it should have caught earlier.

The output of SDLC is a working software product. SDLC is owned jointly by product managers, architects, developers, and QA engineers. It covers the entire product journey, from the first line of a requirements document to the last maintenance patch years after launch.

The Phases of SDLC

SDLC breaks down into six phases. Each one has a clear goal, a defined output, and a specific role for QA.

Phase 1: Requirement Analysis

Business requirements get gathered from stakeholders and documented. The team asks: what does this software need to do? Who will use it? What problems does it solve?

• Output: Software Requirements Specification (SRS) document
• QA role at this stage: QA reviews requirements for testability and ambiguity before development begins. This is shift-left testing in practice, and it is one of the highest-value things a QA engineer does. Questions raised here cost almost nothing to answer. The same questions raised in production cost days to resolve.

Phase 2: System Design

Architects and senior developers design the system structure: database schemas, APIs, UI architecture, and integration points.

• Output: High-level design document (HLD) and low-level design document (LLD)
• QA role at this stage: QA plans the testing approach based on design specifications and identifies which components will need the most rigorous testing.

Phase 3: Implementation (Coding)

Developers write the actual application code based on the design documents. Unit tests get written alongside the code.

• Output: Source code, unit test results, code review sign-offs
• QA role at this stage: QA writes and prepares detailed test cases in parallel with development, so testing can begin immediately when the first build lands.

Phase 4: Testing

The integrated application gets tested against the original requirements. This is where QA takes full ownership of the process.

• Output: Test execution reports, defect logs, regression results, release sign-off
• QA role at this stage: Full ownership. QA runs functional, regression, API, and performance tests, files bug reports in JIRA, retests fixes, and produces the final release recommendation.

Phase 5: Deployment

The tested and approved build gets released to the production environment where real users access it.

• Output: Live application, deployment documentation, release notes
• QA role at this stage: Post-deployment smoke testing to confirm the production environment behaves identically to the test environment.

Phase 6: Maintenance

Bug fixes, performance improvements, and feature updates happen continuously after launch. Every change carries a risk of breaking something that already works.

• Output: Patches, version updates, updated documentation
• QA role at this stage: Regression testing on every change to confirm existing functionality remains intact. This is where a solid automation suite pays for itself.

SDLC Models Used in Nepal's IT Companies

The large majority of Nepal's IT companies use Agile. This matters because STLC in an Agile team looks very different from STLC in a Waterfall project. In Agile, both cycles compress into 2-week sprints where SDLC and STLC activities happen side by side every single day.

What is STLC? The Software Testing Life Cycle Explained

STLC stands for Software Testing Life Cycle. It is the structured set of phases that covers all testing activities within a software project: planning what to test, designing the test cases, setting up the environment, executing the tests, logging defects, and closing the testing cycle with a formal sign-off.

STLC is a subset of SDLC. It does not replace SDLC or run after it finishes. It sits inside SDLC, specifically handling the quality assurance dimension of the development process. Where SDLC asks "are we building the right software, correctly?", STLC asks "does the software we built actually work the way it should?"

The output of STLC is a tested, validated release with all defects identified, tracked, and resolved. STLC is owned by the QA team. Understanding STLC thoroughly is the foundation of any QA role in Nepal, and one of the topics the what is quality assurance guide covers in detail for beginners.

The 6 Phases of STLC (with Entry and Exit Criteria)

Most beginner guides list the STLC phases without explaining entry and exit criteria. But these criteria are exactly what QA interviewers in Nepal ask about, and they are what make the STLC practical rather than just theoretical.

Phase 1: Requirement Analysis

QA reads through requirements and user stories to identify what is testable, what is ambiguous, and what is missing.

• Entry criteria: Requirements document or user stories available for review
• Exit criteria: Testability analysis complete, questions raised with the business or development team, Requirement Traceability Matrix (RTM) drafted
• Output: RTM, list of testable requirements, list of clarification questions

Phase 2: Test Planning

QA defines the test strategy, scope, approach, tools, timelines, responsibilities, and risk areas.

• Entry criteria: Requirement analysis complete, RTM reviewed and approved
• Exit criteria: Test plan document approved by QA lead and project manager
• Output: Test plan document

Phase 3: Test Case Design and Development

QA writes detailed test cases for every testable requirement, covering happy paths, edge cases, and negative scenarios. Automation scripts get written for test cases that will run repeatedly.

• Entry criteria: Test plan approved, design documents available
• Exit criteria: Test cases reviewed, approved, and baselined. Automation scripts ready for stable features.
• Output: Test case suite, test data, automation scripts in Selenium or Cypress

Phase 4: Test Environment Setup

QA sets up the staging environment where tests will run: servers, databases, browsers, devices, and any third-party mock services.

• Entry criteria: Test cases ready, environment requirements defined
• Exit criteria: Environment configured and stable, smoke test passed to confirm the environment is working
• Output: Configured test environment, environment readiness sign-off

Phase 5: Test Execution

QA executes all planned test cases, records results, and files detailed bug reports for every failure.

• Entry criteria: Test environment ready, all test cases approved, build deployed to the test environment
• Exit criteria: All planned test cases executed, defect reports filed in JIRA, critical and major defects retested and closed
• Output: Test execution report, defect log, retest results

Phase 6: Test Closure

QA produces the final test summary report and formally signs off on whether the build is ready for release.

• Entry criteria: All planned tests executed, all critical defects resolved or formally accepted as known issues
• Exit criteria: Test closure report approved by QA lead, stakeholders, and project manager
• Output: Test summary report, lessons learned document, metrics on defect density and test coverage

SDLC vs STLC: Side-by-Side Comparison

Both cycles cover six phases each, but they serve completely different purposes. Here is how they compare across the dimensions that matter most in a real QA role.

The Key Differences in Plain Terms

• Scope: SDLC covers the entire product journey. STLC covers only the quality and testing dimension inside that journey.
• Ownership: SDLC involves the full team. STLC is owned by QA, though it touches every team member through bug reports, retests, and sign-offs.
• Output: SDLC produces working software. STLC produces confidence that the software actually works the way requirements say it should.
• Timing: STLC starts at the same time as the SDLC requirement phase, not after development finishes. This is the mistake most beginners make when they think of STLC as "the testing that happens after coding."
• Verification vs Validation: SDLC handles both verification (are we building it correctly?) and validation (are we building the right thing?). STLC focuses primarily on validation through test execution and defect management. The types of software testing guide explains how each testing type fits into this verification and validation framework.

How SDLC and STLC Work Together in Practice

This is the section that most blogs skip and most interviews test on. SDLC and STLC are not sequential processes. They are parallel processes that stay in sync throughout the project.

Here is how each SDLC phase maps to a corresponding STLC activity:

The critical insight from Archi's Academy's 2026 SDLC and STLC guide puts it clearly: "STLC doesn't happen after SDLC. It runs alongside it. Test planning starts as soon as requirements are defined. Test cases are written while code is being developed."

This parallel relationship is what makes QA engineers valuable from sprint day one, not just at the end of a development cycle.

SDLC and STLC Inside an Agile Sprint in Nepal

Most Kathmandu IT companies run two-week Agile sprints. Here is how SDLC and STLC actually run in parallel inside a single sprint.

Days 1 to 2: Sprint Planning

• SDLC: Developers pick user stories and plan their implementation approach. The team estimates effort and commits to the sprint scope.
• STLC (Requirement Analysis + Test Planning): QA attends sprint planning, reviews the user stories for testability, raises edge case questions, and begins outlining the test plan for the sprint's scope.

Days 3 to 8: Development

• SDLC: Developers build the features. Code gets reviewed and merged into the development branch.
• STLC (Test Case Design + Environment Setup): QA writes detailed test cases for features in development. The test environment gets configured and verified with a smoke test. Automation scripts get written for stable features from previous sprints.

Days 9 to 12: Testing

• SDLC: The build is code-complete and deployed to the test environment.
• STLC (Test Execution): QA executes all test cases against the new build. Bugs get logged in JIRA with full reproduction steps, severity levels, and screenshots. Developers fix critical and major bugs. QA retests each fix. The automated regression suite runs to confirm no existing features broke.

Days 13 to 14: Sprint Closure

• SDLC: Sprint review (demo to stakeholders), retrospective, and deployment to production.
• STLC (Test Closure): QA runs a post-deployment smoke test to confirm the production environment matches the test environment. The test summary report gets filed. Known issues get documented for the next sprint's backlog.

Understanding the manual vs automation testing split is important here: manual testing handles the new feature work in Days 9 to 12 while automation handles the regression suite that runs continuously in the CI/CD pipeline from Day 3 onwards.

Verification vs Validation in SDLC and STLC

Every QA interview in Nepal eventually asks about verification versus validation. Understanding the difference clearly shows that you understand where quality work happens in SDLC vs STLC.

A Nepal-specific example: A fintech company builds a loan EMI calculator. Verification checks whether the formula in the code matches the formula in the design specification. Validation checks whether a Nepali user applying for a NPR 500,000 loan at 12% annual interest actually gets the correct monthly repayment amount when they use the calculator. Both matter. Verification without validation means the code is technically correct but may solve the wrong problem. Validation without verification means the output might be right today but breaks unpredictably later.

Shift-Left Testing: How Modern Teams Merge SDLC and STLC

Traditional SDLC kept testing at the end. Testing was a gate that either approved or rejected the completed product. This created long feedback cycles: developers would build for weeks, QA would find problems, developers would rebuild, and the whole process repeated.

Shift-left testing moves QA involvement to the earliest possible point in SDLC. QA reviews requirements on Sprint Day 1. Test cases get written while code is still being developed. Automated tests run in the CI/CD pipeline on every code commit.

The IBM Systems Sciences Institute found that fixing a defect in the requirement phase costs one unit of effort. The same defect found in production costs 30 times more to resolve. Shift-left testing dramatically reduces this cost curve by catching problems before they compound.

In Nepal's outsourcing sector, where development teams build products for international clients on tight delivery timelines, shift-left testing is increasingly becoming the standard approach. Tools that make this possible in Kathmandu's IT companies:

• JIRA: links requirements (SDLC artifacts) directly to test cases (STLC artifacts) in one platform
• GitHub Actions: triggers STLC test runs on every SDLC code push automatically
• TestRail: manages the full STLC documentation alongside SDLC sprint tracking

Why Understanding SDLC and STLC Matters for Your QA Career in Nepal

Every QA job listing in Nepal assumes you understand SDLC. Every QA interview tests STLC phases, entry and exit criteria, and how QA fits into Agile sprints. Here is why both matter for where your career goes from here:

• Every fresher QA role in Nepal expects you to know SDLC. It is the framework your entire work sits inside.
• Every QA interview tests STLC phases, entry and exit criteria, and how QA fits into Agile sprints.
• Fresher QA engineers in Nepal earn NPR 25,000 to 50,000 per month.
• Senior QA engineers who design STLC processes from scratch and build automation frameworks earn NPR 120,000 to 221,000 per month, based on Glassdoor Nepal's QA salary data for June 2026
• The gap between those two levels comes down to depth: freshers know what the phases are called, senior engineers know how to apply and adapt them for a specific product and team.
• Companies including Vrit Technologies, F1Soft, Leapfrog Technology, Cotiviti, and eSewa all run Agile cycles. QA engineers who embed STLC into every sprint become indispensable.

For the complete step-by-step plan on building toward a senior QA role in Nepal, the QA career roadmap in Nepal guide maps the full path from manual testing fresher to senior automation engineer.

Conclusion

SDLC is the full journey of building software. STLC is the quality process that runs inside that journey, in parallel with every phase from requirements through to maintenance. The two are not sequential. They are synchronised. Every SDLC phase has a corresponding STLC activity that starts at the same time, not after.

Understanding this relationship is not just useful for passing QA interviews in Nepal. It changes how you work. QA engineers who know how SDLC and STLC connect get involved in requirements before developers start building, catch defects before they get coded in, and build automation suites that give the whole team instant feedback on every code push.

If you want to build this understanding with hands-on labs, real JIRA and Selenium projects, and mentors who work in Nepal's IT companies, the Quality Assurance course at Skill Shikshya  covers everything from SDLC and STLC fundamentals through to Selenium, Postman, API testing, and live project work.