Tech Notes Documentation
Insights, tutorials, and deep-dives into QA automation and software engineering.
Understanding In-Depth SDLC & STLC Synchronization in Quality Engineering
In modern software creation, product quality does not happen by accident. Quality is the result of close collaboration between the development team (SDLC - Software Development Life Cycle) and the testing team (STLC - Software Testing Life Cycle) working side-by-side from day one.
📌 Work Context: Traditional (Waterfall) vs. Modern (Agile)
Before discussing how to test, it is essential to understand the two most common ways tech companies work:
- Waterfall (The Old Way): Work flows sequentially like a waterfall. Design is finished, coding happens, and only when the app is completely built is it handed over to QA for testing. The downside: if there are major flaws, they are found too late and cost a fortune to fix.
- Agile (The Modern Way): Work is done in short, iterative cycles called Sprints (usually 2 weeks). Planning, coding, and testing happen continuously within every single cycle.
1. How Builders and Testers Work Together
Here is a simple look at how testing (STLC) aligns perfectly with the application building process (SDLC) at every step:
📊 SDLC & STLC Synchronization Flow
2. The Testing Phases (ISTQB Standard)
As a mature industry standard, QA teams have strict rules on when a job can start (Entry Criteria) and when it is considered done (Exit Criteria).
| Testing Phase (STLC) | Entry Criteria | Exit Criteria | Deliverables (Documents) |
|---|---|---|---|
| 1. Test Planning | Initial project documents are available. | Schedules, targets, and task delegations are approved. | Test Plan Document. |
| 2. Test Analysis (Risk Analysis) |
Test Plan is approved and requirements are clear. | QA understands which parts are most vulnerable. | List of Test Conditions (Features to check). |
| 3. Test Design & Implementation (Preparation) |
Risk analysis is complete. | Step-by-step scenarios are written, test data and environments are ready. | Test Cases & Automation Scripts (if any). |
| 4. Test Execution (Actual Testing) |
The app is usable and the server environment is ready. | All features are tested, and bugs are reported to developers. | Defect/Bug Reports. |
| 5. Test Completion (Report Card) |
Testing is done and no critical bugs are ignored. | Everyone agrees the app is safe to launch. | Test Summary Report (Release Readiness). |
3. Real-World STLC Application (Case Study: Sprint 1 - Adding & Editing Contact Features)
To give you a better picture, let's look at how a QA team executes STLC phases within a single 2-week Sprint focusing on two core features: Adding Contact and Editing Contact. Testing plans strictly cover this specific sprint, adapting dynamically in future sprints as requirements evolve:
- 1. Test Planning (Days 1-2): The QA Lead analyzes requirements for the Adding Contact and Editing Contact features for Sprint 1 (2 weeks). A targeted test plan is defined specifically for this sprint, setting timeline goals and testing tools (Jira for tracking and Playwright / Postman for automation). (Deliverable: Approved Sprint 1 Test Plan).
- 2. Test Analysis (Days 2-3): The QA team dissects the Add and Edit contact flows to identify critical edge cases: "What happens if a contact is added without a name?", "What if letters are typed into phone fields?", or "What if connection drops while saving an edit?". (Deliverable: List of Sprint 1 test conditions).
- 3. Test Design & Implementation (Days 3-5): QA drafts positive and negative Test Cases for both features (e.g., successful contact creation, email/phone validation, cancel edit actions). Simultaneously, the QA Engineer prepares automated Page Object Model scripts in Playwright. (Deliverable: Ready Test Cases & Automation Scripts).
- 4. Test Execution (Days 6-9): Once developers deploy the Add & Edit Contact features to the staging environment, QA runs manual and automated tests. A bug is identified: "Phone number field in Edit Contact fails character length validation". QA logs a ticket in Jira. (Deliverable: Jira Bug Reports & Execution Results).
- 5. Test Completion (Day 10): Developers fix the bug and QA re-tests alongside a brief regression suite. QA concludes Sprint 1 by issuing a Sprint Test Summary Report confirming the Add & Edit Contact features are stable and ready for release before moving to the next sprint. (Deliverable: Final Sprint 1 Test Summary Report).
4. Testing Style Comparison: Waterfall vs Agile
STLC execution varies significantly depending on the team's work style. Here is a direct comparison between traditional Waterfall and modern Agile testing execution:
| Differences | The Old Way (Waterfall STLC) | The Modern Way (Agile STLC) |
|---|---|---|
| When does QA Start? | Starts late, only after developers have completely finished writing the code. | Starts on Day One, actively participating in meetings and checking designs. |
| Testing Cycle | Checked all at once in a massive phase near the end. Highly time-consuming. | Checked continuously in short, iterative cycles (typically every 2 weeks). |
| Automation Robots | Usually done manually at the end. Automation scripts are built late. | Automation is built in parallel and runs instantly when new code arrives. |
| Bug Handling | Bugs are found late. Fixing them is very expensive and delays the launch. | Bugs are caught and fixed immediately within the same week (Instant Feedback). |
5. Testing Early (Shift-Left Testing)
The biggest and most expensive mistake in software development is involving QA only after the app is finished. In a proper workflow, QA works from day one (Shift-Left). QA reads the client's requirements to find confusing rules or risks long before a programmer types their first line of code. The core principle is Preventing the illness is better than curing it (Defect Prevention).
6. The Benefits of Working Side-by-Side
In a fast-paced Agile workflow, the teamwork between builders (SDLC) and testers (STLC) looks like this:
- Planning Together (Test Planning): Formulated during the initial design meeting. QA helps define the workload so testing targets are realistic.
- Prepping While Waiting (Test Design): Built while developers are typing code. QA actively writes the testing scenarios and builds automation robots.
- Fast Feedback Loop (Test Execution): Active the moment the app is ready. If QA finds a bug, it is reported and re-tested in the very same day or week.
Conclusion
Aligning the builders (SDLC) and the testers (STLC) is like building a house with an inspector checking every brick layer, rather than waiting for the house to be fully built before inspecting it. This disciplined approach is proven to reduce bug fixing costs by up to 70%, speed up product launches, and guarantee the app's stability (Enterprise-grade quality).