Part 3: Architecture, Testing & Defects

1. System Architecture: HLD vs. LLD

During the design phase, requirements are translated into technical architectural plans. This is divided into two distinct engineering steps.

 [ Software Requirement Specification (SRS) ]
                     │
                     ▼
 [ High-Level Design (HLD) ] ───> Macro Architecture (System View)
                     │
                     ▼
 [ Low-Level Design (LLD) ]  ───> Micro Architecture (Component/Code View)

• High-Level Design (HLD) / System Architecture:

• Focus: The structural overview of the entire application. It defines the macro-architecture.

• Components: System topology, database choices (SQL vs. NoSQL), monolithic vs. microservices architectural styles, third-party platform integrations, and high-level data flow diagrams.

• Audience: Chief Architects, Project Managers, and Tech Leads.

• Low-Level Design (LLD) / Detailed Design:

• Focus: The internal technical blueprint of individual components. It details how the code will be written.

• Components: Class diagrams, object relationships, database table schemas with precise data types, specific design patterns (e.g., Singleton, Factory), internal algorithm logic, pseudocode, and detailed API endpoint specs.

• Audience: Software Developers and QA Engineers.

---

2. Software Configuration Management (SCM) & Technical Debt

Software Configuration Management (SCM)

A systemic process to track, control, and manage changes made to software artifacts (source code, documentation, environment configurations) over time. It guarantees auditability, baseline control, and environment repeatability.

• Build vs. Release: A Build is an internal compile of executable code handed over from development to testing (e.g., Build v1.4.2-beta). A Release is a formally verified, stable build that has passed all testing gates and is deployed directly to end-users/production.

Technical Debt

A metaphor representing the future cost of choosing an easy, fast technical solution today over a better, more robust architectural approach that takes longer to build.

• Managing Technical Debt: It is rarely possible to keep debt at zero. Healthy development teams log technical debt items directly into the Product Backlog and dedicate a fixed percentage (e.g., 10–20%) of every sprint’s capacity to refactoring and paying down architectural debt before it slows down feature delivery.

---

3. The Software Testing Life Cycle (STLC)

Testing is not a single action; it is a systematic life cycle that runs in parallel with development.

[ Test Planning ] ➔ [ Test Design ] ➔ [ Environment Setup ] ➔ [ Test Execution ] ➔ [ Test Closure ]

Test Plan vs. Test Strategy

• Test Strategy: A high-level, static corporate document defined at the organizational or project level. It outlines the overall testing philosophy, standards, tools, and test levels (e.g., “All projects in this business unit will maintain 80% unit test coverage”).
• Test Plan: A dynamic, practical project document derived from the Test Strategy. It describes the specific scope, objectives, resources, schedule, risks, and test cases allocated to a particular release.

Test Case vs. Test Scenario vs. Test Script

• Test Scenario: A high-level definition of what to test (e.g., “Verify user checkout with a credit card”).
• Test Case: A detailed document containing explicit steps, preconditions, inputs, and expected results (e.g., “Step 3: Enter an expired card expiration date. Expected Result: Display an error message reading ‘Card Expired’”).
• Test Script: A programmatic script (written in code like Python, Java, or JavaScript via tools like Selenium, Playwright, or Cypress) that automates the execution of a test case.

---

4. The Levels and Types of Testing

Interviews heavily quiz candidates on their ability to structure testing layers and match specific testing types to production risks.

The Levels of Testing (Bottom-Up)

1. Unit Testing: Testing individual isolated code blocks (methods, classes, functions) using mock data. Usually owned by developers.
2. Integration Testing: Testing the interactions and communication channels between combined modules or subsystems.
3. System Testing: Testing the fully integrated, end-to-end software application as a whole to evaluate compliance with the SRS.
4. User Acceptance Testing (UAT): Final validation phase executed by end-users or clients in a dedicated environment to confirm the product matches operational expectations before production release.

---

Key Testing Types Comparison Matrix

Testing Type	Core Focus / Objective	Verification Method
Verification vs. Validation	Static code/doc analysis vs. Executing software.	Reviews, walkthroughs vs. Running test cases.
White Box vs. Black Box	Internal code paths and logic vs. External functional behaviors.	Code reviews, unit tests vs. Input/Output assertions.
Smoke vs. Sanity Testing	Testing core stability on a new build vs. Deep testing of fixed bugs.	Quick broad verification vs. Narrow focused verification.
Regression vs. Retesting	Confirming changes didn’t break old features vs. Rerunning failed tests.	Comprehensive impact tests vs. Retesting the exact fix.
Load vs. Stress Testing	System performance under expected peak load vs. Finding the absolute breaking point.	Simulating high traffic vs. Pushing beyond design limits.
Alpha vs. Beta Testing	internal testing in controlled environments vs. External user testing.	In-house QA testing vs. Real-world target audience testing.

---

5. Defect Management: Bug, Defect, Error, and Failure

Understanding how tracking metrics work keeps production issues from slipping through the cracks.

• The Continuum: An Error is a human mistake made by a developer (e.g., a typo or logical miscalculation in code). When compiled, this error creates a Bug or Defect inside the codebase. If that bug is executed during runtime, it causes the system to experience a Failure (unacceptable real-world behavior).

Severity vs. Priority

• Severity: The objective technical impact of a defect on the system’s operational ability. Set by QA.
• Priority: The business urgency to fix the defect based on schedule, market impact, or client needs. Set by the Product Owner/Project Manager.

High Severity / Low Priority ──> The app crashes if a user clicks a obscure link deep in the footer.
Low Severity / High Priority ──> The company logo on the homepage is misspelled or upside down.

---

6. Verification vs Validation

• Verification: static — checking documents, design, and code against requirements (“Are we building the product right?”). Reviews, walkthroughs, inspections, static analysis.
• Validation: dynamic — executing the system to confirm it meets user needs (“Are we building the right product?”). Testing the actual software.
• Mnemonics: Verification = “did we do things right?”; Validation = “did we do the right things?” (V-model aligns each dev phase with a test phase).

7. Black-Box, White-Box & Grey-Box Testing

	Black-box	White-box	Grey-box
Knows code?	No (tests functionality)	Yes (tests internal logic)	Partial
Focus	Requirements/behavior	Code paths, branches, coverage	Design + behavior
Examples	Functional, UAT, BVA, EP	Statement/branch coverage, unit	Integration, web security

• Black-box — tests what the system does from the user’s view (no knowledge of internals).
• White-box — tests how it works, examining internal logic and ensuring code paths execute (coverage).
• Grey-box — a blend (knows architecture/database, not full code); common in integration and security testing.

8. Test Design Techniques (Cheat Sheet)

These are the “how do you actually design test cases” answers:

• Equivalence Partitioning (EP): divide inputs into groups where each member behaves the same; test one representative per group. For “age 18–60 valid”: one valid (30) + two invalid (below 18, above 60) cases.
• Boundary Value Analysis (BVA): test values at and just around the edges of partitions — the most error-prone spots. For 18–60: test 17, 18, 59, 60, 61.
• Decision Table: for combinations of conditions → expected actions; ensures every condition combination is covered (e.g., login: valid/invalid user × valid/invalid password).
• State Transition: model the system’s states and the transitions/events between them (e.g., order: new → confirmed → shipped → delivered).
• Error Guessing: experienced testers anticipate likely mistakes and target them (empty input, divide-by-zero, boundary off-by-one).
• Pairwise Testing: test all pairs of input values to reduce the combinatorial explosion of combinations.

Rule of thumb: EP cuts redundant tests; BVA catches edge bugs; decision tables guarantee condition coverage; state transition models behavioral flows.

9. The Defect (Bug) Lifecycle

A defect moves through controlled states:

New → Open/Assigned → Fixed → Verified/Retest → Closed
                 ↕ (Reopened if the fix fails)

• New — tester logs it with steps, expected vs actual, severity/priority.
• Open/Assigned — triaged to a developer.
• Fixed — developer resolves it (may pass through In Progress, Deferred, Rejected/Not a Bug, Duplicate).
• Retest/Verified — tester re-runs the original test case.
• Closed — confirmed fixed; or Reopened → back to Open if it persists.

Severity (impact — set by QA) vs Priority (urgency — set by PO/PM): a cosmetic typo on the homepage can be low severity but high priority if it blocks a client demo.