universal-dev-standards 4.2.0 → 5.0.0-beta.10

package/bundled/core/testing-standards.md

@@ -2,2452 +2,216 @@
 
 > **Language**: English | [繁體中文](../locales/zh-TW/core/testing-standards.md)
 
-**Version**: 2.2.0
-**Last Updated**: 2026-01-20
+**Version**: 3.0.0
+**Last Updated**: 2026-01-29
 **Applicability**: All software projects
+**Scope**: universal
+**Industry Standards**: ISTQB CTFL v4.0, ISO/IEC/IEEE 29119
+**References**: [istqb.org](https://istqb.org/)
 
 ---
 
 ## Purpose
 
-This standard defines testing conventions and best practices to ensure software quality through systematic testing at multiple levels.
+This standard defines actionable testing rules and conventions for AI agents and developers. For theoretical foundations, educational content, and detailed examples, see [Testing Theory Knowledge Base](../skills/testing-guide/testing-theory.md).
 
 **Reference Standards**:
 - [ISTQB CTFL v4.0](https://istqb.org/certifications/certified-tester-foundation-level-ctfl-v4-0/)
 - [ISO/IEC/IEEE 29119](https://www.iso.org/standard/81291.html)
-- [SWEBOK v4.0](https://www.computer.org/education/bodies-of-knowledge/software-engineering) - IEEE Computer Society
+- [SWEBOK v4.0](https://www.computer.org/education/bodies-of-knowledge/software-engineering)
 
 ---
 
-## Table of Contents
-
-1. [Testing Fundamentals](#testing-fundamentals) ⭐ NEW
-2. [Testing Framework Selection](#testing-framework-selection)
-3. [Testing Pyramid](#testing-pyramid-default-industry-standard)
-4. [Test Levels](#unit-testing-ut) (UT, IT, ST, E2E)
-5. [Static Testing](#static-testing)
-6. [Test Design Techniques](#test-design-techniques)
-7. [Experience-Based Testing](#experience-based-testing)
-8. [Risk-Based Testing](#risk-based-testing)
-9. [Specialized Testing](#specialized-testing)
-10. [Test-Related Measures](#test-related-measures) ⭐ NEW
-11. [Defect Management](#defect-management)
-12. [Test Process Management](#test-process-management)
-13. [Test Doubles](#test-doubles)
-14. [Test Data Management](#test-data-management)
-15. [Test Environment Isolation](#test-environment-isolation)
-16. [CI/CD Integration](#cicd-integration)
-17. [Best Practices](#best-practices)
-18. [Test Documentation Structure](#test-documentation-structure) ⭐ NEW
+## Glossary
 
----
-
-## Testing Fundamentals
-
-Understanding the theoretical foundations of software testing is essential for effective test design and execution.
-
-**Reference**: SWEBOK v4.0 Chapter 5
-
-### Faults vs Failures
-
-```
-┌─────────────────────────────────────────────────────────────┐
-│              Faults, Errors, and Failures                   │
-├─────────────────────────────────────────────────────────────┤
-│                                                              │
-│  Error (Mistake)                                             │
-│       │                                                      │
-│       ▼ introduced during development                        │
-│  ┌─────────┐                                                 │
-│  │  Fault  │  (Defect/Bug in the code)                      │
-│  └─────────┘                                                 │
-│       │                                                      │
-│       ▼ when executed                                        │
-│  ┌─────────┐                                                 │
-│  │ Failure │  (Observable incorrect behavior)               │
-│  └─────────┘                                                 │
-│                                                              │
-│  Key Points:                                                 │
-│  • A fault may exist without causing a failure              │
-│  • A failure requires a fault to be executed                │
-│  • Multiple faults can cause the same failure               │
-│  • Testing finds failures; debugging finds faults           │
-│                                                              │
-└─────────────────────────────────────────────────────────────┘
-```
-
-### The Oracle Problem
-
-An **oracle** is any mechanism that determines whether observed program behavior is correct. The oracle problem addresses the challenge of knowing expected outcomes.
-
-```
-┌─────────────────────────────────────────────────────────────┐
-│                    Oracle Types                              │
-├─────────────────────────────────────────────────────────────┤
-│                                                              │
-│  Human Oracle                                                │
-│  └── Manual verification by domain expert                   │
-│                                                              │
-│  Specification-Based Oracle                                  │
-│  └── Compare against formal requirements                     │
-│                                                              │
-│  Reference Implementation                                    │
-│  └── Compare against known-correct implementation            │
-│                                                              │
-│  Metamorphic Oracle                                          │
-│  └── Verify relationships between outputs                    │
-│      (e.g., sort(sort(x)) == sort(x))                       │
-│                                                              │
-│  Statistical Oracle                                          │
-│  └── Validate against expected distributions                 │
-│                                                              │
-│  Implicit Oracle                                             │
-│  └── No crash, no exception, no timeout                      │
-│                                                              │
-└─────────────────────────────────────────────────────────────┘
-```
-
-### Theoretical Limitations of Testing
-
-> "Program testing can be used to show the presence of bugs, but never to show their absence." — Edsger W. Dijkstra
-
-```
-┌─────────────────────────────────────────────────────────────┐
-│              Testing Limitations                             │
-├─────────────────────────────────────────────────────────────┤
-│                                                              │
-│  Exhaustive Testing is Impossible                            │
-│  ├── Infinite input domain                                  │
-│  ├── State space explosion                                  │
-│  └── Timing and concurrency variations                      │
-│                                                              │
-│  Infeasible Paths                                            │
-│  ├── Some code paths cannot be executed by any input        │
-│  ├── Dead code may appear reachable in CFG                  │
-│  └── 100% path coverage may be mathematically impossible    │
-│                                                              │
-│  Halting Problem                                             │
-│  └── Cannot algorithmically determine if all tests halt     │
-│                                                              │
-│  Implications:                                               │
-│  • Testing is sampling, not proof                           │
-│  • Risk-based prioritization is essential                   │
-│  • Combine testing with formal methods where critical       │
-│                                                              │
-└─────────────────────────────────────────────────────────────┘
-```
-
-### Testability
-
-Testability measures how easily software can be tested effectively.
-
-| Factor | Description | How to Improve |
-|--------|-------------|----------------|
-| **Controllability** | Ability to set system state for testing | Provide test hooks, dependency injection |
-| **Observability** | Ability to observe test results | Add logging, expose internal state |
-| **Isolability** | Ability to test components independently | Modular design, clear interfaces |
-| **Understandability** | Clarity of expected behavior | Good documentation, clear specifications |
-| **Stability** | Low rate of change | Freeze features before testing phase |
-| **Simplicity** | Low complexity | Reduce cyclomatic complexity |
-
-### Test Adequacy Criteria
-
-Test adequacy criteria answer: "Have we tested enough?"
-
-```
-┌─────────────────────────────────────────────────────────────┐
-│              Test Adequacy Criteria                          │
-├─────────────────────────────────────────────────────────────┤
-│                                                              │
-│  Coverage-Based Criteria                                     │
-│  ├── Statement Coverage: % of statements executed           │
-│  ├── Branch Coverage: % of branches taken                   │
-│  ├── Condition Coverage: % of conditions evaluated          │
-│  └── MC/DC: Modified condition/decision coverage            │
-│                                                              │
-│  Fault-Based Criteria                                        │
-│  ├── Mutation Score: % of mutants killed                    │
-│  └── Fault Seeding: % of seeded faults found                │
-│                                                              │
-│  Requirements-Based Criteria                                 │
-│  └── Requirements Coverage: % of requirements tested         │
-│                                                              │
-│  Risk-Based Criteria                                         │
-│  └── Risk Coverage: % of high-risk items tested             │
-│                                                              │
-│  Stopping Rules:                                             │
-│  • Achieved target coverage level                           │
-│  • Defect discovery rate drops below threshold              │
-│  • Budget/time exhausted (with documented risk)             │
-│                                                              │
-└─────────────────────────────────────────────────────────────┘
-```
-
----
-
-## Testing Framework Selection
-
-Choose a testing framework based on your project needs. This standard supports two approaches:
-
-### Option A: ISTQB Standard Framework
-
-Best for enterprise projects, certification needs, and formal QA processes.
-
-**Reference**: [ISTQB Glossary v4.0](https://glossary.istqb.org)
-
-| Level | Abbreviation | Purpose |
-|-------|--------------|---------|
-| Unit Testing | UT | Verify individual code units |
-| Integration Testing | IT/SIT | Verify component interactions |
-| System Testing | ST | Verify system meets requirements |
-| Acceptance Testing | AT/UAT | Verify system meets business needs |
-
-**When to choose ISTQB**:
-- Enterprise projects with formal QA processes
-- Projects requiring certification or compliance
-- Organizations with dedicated QA teams
-- Projects with strict audit requirements
-
-### Option B: Industry Testing Pyramid
-
-Best for agile development, CI/CD optimization, and rapid iteration.
-
-**Reference**: [Martin Fowler's Testing Pyramid](https://martinfowler.com/bliki/TestPyramid.html), [Google Testing Blog](https://testing.googleblog.com)
-
-| Level | Abbreviation | Ratio | Purpose |
-|-------|--------------|-------|---------|
-| Unit Testing | UT | 70% | Isolated component tests |
-| Integration Testing | IT/SIT* | 20% | Component interaction tests |
-| E2E Testing | E2E | 10% | User workflow tests |
-
-*Note on Integration Testing abbreviation:
-- **IT** (Integration Testing): Common in Agile/DevOps communities
-- **SIT** (System Integration Testing): Common in Enterprise/ISTQB contexts
-- Both terms refer to the same testing level
-
-**When to choose Industry Pyramid**:
-- Agile/Scrum development teams
-- CI/CD focused environments
-- Small to medium projects with rapid iteration
-- DevOps practices
-
----
-
-## Testing Pyramid (Default: Industry Standard)
-
-```
-              ┌─────────┐
-              │   E2E   │  ← 10% (Fewer, slower, expensive)
-             ─┴─────────┴─
-            ┌─────────────┐
-            │    IT/SIT   │  ← 20% (Integration Testing)
-           ─┴─────────────┴─
-          ┌─────────────────┐
-          │       UT        │  ← 70% (Unit Testing - Foundation)
-          └─────────────────┘
-```
-
-### Recommended Ratio (Industry Pyramid)
-
-| Level | Abbreviation | Percentage | Execution Time |
-|-------|--------------|------------|----------------|
-| Unit Testing | UT | 70% | < 10 min total |
-| Integration Testing | IT/SIT | 20% | < 30 min total |
-| E2E Testing | E2E | 10% | < 2 hours total |
-
-### ISTQB 4-Level Structure (Alternative)
-
-| Level | Abbreviation | Performed By | Focus |
-|-------|--------------|--------------|-------|
-| Unit Testing | UT | Developers | Code correctness |
-| Integration Testing | IT/SIT | Developers/QA | Interface contracts |
-| System Testing | ST | QA Team | Requirements verification |
-| Acceptance Testing | AT/UAT | End Users | Business validation |
-
----
-
-## Unit Testing (UT)
-
-### Definition
-
-Tests individual functions, methods, or classes in isolation from external dependencies.
-
-### Characteristics
-
-- **Isolated**: No database, network, or file system access
-- **Fast**: Each test < 100ms
-- **Deterministic**: Same input always produces same output
-
-### Scope
-
-```
-┌─────────────────────────────────────────┐
-│              Unit Under Test            │
-├─────────────────────────────────────────┤
-│  ✅ Single function/method              │
-│  ✅ Single class                        │
-│  ✅ Pure business logic                 │
-│  ✅ Data transformations                │
-│  ✅ Validation rules                    │
-├─────────────────────────────────────────┤
-│  ❌ Database queries                    │
-│  ❌ External API calls                  │
-│  ❌ File I/O operations                 │
-│  ❌ Multi-class interactions            │
-└─────────────────────────────────────────┘
-```
-
-### Naming Convention
-
-**File Naming**:
-```
-[ClassName]Tests.[ext]
-[ClassName].test.[ext]
-[ClassName].spec.[ext]
-
-Examples:
-  UserService.test.ts
-  UserServiceTests.cs
-  user_service_test.py
-  user_service_test.go
-```
-
-**Method Naming**:
-```
-[MethodName]_[Scenario]_[ExpectedResult]
-should_[ExpectedBehavior]_when_[Condition]
-test_[method]_[scenario]_[expected]
-
-Examples:
-  CalculateTotal_WithDiscount_ReturnsDiscountedPrice()
-  should_return_null_when_user_not_found()
-  test_validate_email_invalid_format_returns_false()
-```
-
-### Coverage Guidelines
-
-| Metric | Minimum | Recommended |
-|--------|---------|-------------|
-| Line Coverage | 70% | 85% |
-| Branch Coverage | 60% | 80% |
-| Function Coverage | 80% | 90% |
-
-### Example
-
-```csharp
-// C# Example
-[TestClass]
-public class UserValidatorTests
-{
-    private UserValidator _validator;
-
-    [TestInitialize]
-    public void Setup()
-    {
-        _validator = new UserValidator();
-    }
-
-    [TestMethod]
-    public void ValidateEmail_ValidFormat_ReturnsTrue()
-    {
-        // Arrange
-        var email = "user@example.com";
-
-        // Act
-        var result = _validator.ValidateEmail(email);
-
-        // Assert
-        Assert.IsTrue(result);
-    }
-
-    [TestMethod]
-    public void ValidateEmail_InvalidFormat_ReturnsFalse()
-    {
-        // Arrange
-        var email = "invalid-email";
-
-        // Act
-        var result = _validator.ValidateEmail(email);
-
-        // Assert
-        Assert.IsFalse(result);
-    }
-}
-```
-
-```typescript
-// TypeScript Example
-describe('UserValidator', () => {
-    let validator: UserValidator;
-
-    beforeEach(() => {
-        validator = new UserValidator();
-    });
-
-    describe('validateEmail', () => {
-        it('should return true for valid email format', () => {
-            const result = validator.validateEmail('user@example.com');
-            expect(result).toBe(true);
-        });
-
-        it('should return false for invalid email format', () => {
-            const result = validator.validateEmail('invalid-email');
-            expect(result).toBe(false);
-        });
-    });
-});
-```
-
----
-
-## Integration Testing (IT)
-
-### Definition
-
-Tests interactions between multiple components, modules, or external systems.
-
-### When Integration Tests Are Required
-
-| Scenario | Reason |
-|----------|--------|
-| Query predicates | Mocks cannot verify filter expressions |
-| Entity relationships | Verify foreign key correctness |
-| Composite keys | In-memory DB may differ from real DB |
-| Field mapping | DTO ↔ Entity transformations |
-| Pagination | Row ordering and counting |
-| Transactions | Rollback behavior |
-
-**Decision Rule**:
-If your unit test uses a wildcard matcher (`any()`, `It.IsAny<>`, `Arg.Any<>`)
-for a query/filter parameter, that functionality MUST have an integration test.
-
-### Characteristics
-
-- **Component Integration**: Tests module boundaries
-- **Real Dependencies**: Uses actual databases, APIs (often containerized)
-- **Slower**: Each test typically 1-10 seconds
-
-### Scope
-
-```
-┌─────────────────────────────────────────┐
-│         Integration Test Scope          │
-├─────────────────────────────────────────┤
-│  ✅ Database CRUD operations            │
-│  ✅ Repository + Database               │
-│  ✅ Service + Repository                │
-│  ✅ API endpoint + Service layer        │
-│  ✅ Message queue producers/consumers   │
-│  ✅ Cache read/write operations         │
-├─────────────────────────────────────────┤
-│  ❌ Full user workflows                 │
-│  ❌ Cross-service communication         │
-│  ❌ UI interactions                     │
-└─────────────────────────────────────────┘
-```
-
-### Naming Convention
-
-**File Naming**:
-```
-[ComponentName]IntegrationTests.[ext]
-[ComponentName].integration.test.[ext]
-[ComponentName].itest.[ext]
-
-Examples:
-  UserRepositoryIntegrationTests.cs
-  user-service.integration.test.ts
-  user_repository_itest.py
-```
-
-**Method Naming**:
-```
-[Operation]_[Context]_[ExpectedOutcome]
-
-Examples:
-  CreateUser_WithValidData_PersistsToDatabase()
-  GetUserById_ExistingUser_ReturnsUserFromDatabase()
-  SendMessage_ToQueue_ConsumerReceivesMessage()
-```
-
-### Test Fixtures
-
-```csharp
-// C# Integration Test Example with Test Database
-[TestClass]
-public class UserRepositoryIntegrationTests
-{
-    private TestDbContext _dbContext;
-    private UserRepository _repository;
-
-    [TestInitialize]
-    public async Task Setup()
-    {
-        // Use test database (e.g., SQLite in-memory or Testcontainers)
-        _dbContext = TestDbContextFactory.Create();
-        _repository = new UserRepository(_dbContext);
-        await _dbContext.Database.EnsureCreatedAsync();
-    }
-
-    [TestCleanup]
-    public async Task Cleanup()
-    {
-        await _dbContext.DisposeAsync();
-    }
-
-    [TestMethod]
-    public async Task CreateUser_WithValidData_PersistsToDatabase()
-    {
-        // Arrange
-        var user = new User { Name = "Test User", Email = "test@example.com" };
-
-        // Act
-        await _repository.CreateAsync(user);
-        var savedUser = await _repository.GetByIdAsync(user.Id);
-
-        // Assert
-        Assert.IsNotNull(savedUser);
-        Assert.AreEqual("Test User", savedUser.Name);
-    }
-}
-```
-
----
-
-## System Testing (ST)
-
-### Definition
-
-Tests the complete integrated system to verify it meets specified requirements.
-
-### Characteristics
-
-- **Complete System**: All components deployed and integrated
-- **Requirement-Based**: Tests against functional specifications
-- **Production-Like**: Uses environment similar to production
-
-### Scope
-
-```
-┌─────────────────────────────────────────┐
-│           System Test Scope             │
-├─────────────────────────────────────────┤
-│  ✅ Complete API workflows              │
-│  ✅ Cross-service transactions          │
-│  ✅ Data flow through entire system     │
-│  ✅ Security requirements               │
-│  ✅ Performance under load              │
-│  ✅ Error handling & recovery           │
-│  ✅ Configuration validation            │
-├─────────────────────────────────────────┤
-│  ❌ UI visual testing                   │
-│  ❌ User journey simulations            │
-│  ❌ A/B testing scenarios               │
-└─────────────────────────────────────────┘
-```
-
-### Types of System Tests
-
-| Type | Description |
-|------|-------------|
-| Functional | Verify features work as specified |
-| Performance | Load, stress, scalability testing |
-| Security | Penetration, vulnerability scanning |
-| Reliability | Failover, recovery, stability |
-| Compatibility | Cross-platform, browser compatibility |
-
-### Naming Convention
-
-**File Naming**:
-```
-[Feature]SystemTests.[ext]
-[Feature].system.test.[ext]
-[Feature]_st.[ext]
-
-Examples:
-  OrderProcessingSystemTests.cs
-  authentication.system.test.ts
-  payment_processing_st.py
-```
-
-### Example
-
-```csharp
-// System Test Example: Complete Resource Processing Flow
-// Note: Replace {Resource}, {Item}, {Action} with your domain concepts
-[TestClass]
-public class ResourceProcessingSystemTests
-{
-    private HttpClient _client;
-    private TestEnvironment _env;
-
-    [TestInitialize]
-    public async Task Setup()
-    {
-        _env = await TestEnvironment.CreateAsync();
-        _client = _env.CreateAuthenticatedClient();
-    }
-
-    [TestMethod]
-    public async Task ProcessResource_CompleteFlow_CompletedSuccessfully()
-    {
-        // Arrange: Create test data
-        var item = await _env.CreateTestItem(value: 100);
-        var user = await _env.CreateTestUser();
-
-        // Act: Execute complete processing flow
-        // Step 1: Create request
-        var requestResponse = await _client.PostAsync("/api/requests",
-            new { itemId = item.Id, quantity = 2 });
-        Assert.AreEqual(HttpStatusCode.OK, requestResponse.StatusCode);
-
-        // Step 2: Submit processing
-        var processResponse = await _client.PostAsync("/api/processes",
-            new { requestId = requestResponse.RequestId, userId = user.Id });
-        var process = await processResponse.Content.ReadAsAsync<Process>();
-        Assert.AreEqual(HttpStatusCode.Created, processResponse.StatusCode);
-
-        // Step 3: Confirm completion
-        var confirmResponse = await _client.PostAsync($"/api/processes/{process.Id}/confirm",
-            new { confirmationType = "standard", amount = 200 });
-        Assert.AreEqual(HttpStatusCode.OK, confirmResponse.StatusCode);
-
-        // Assert: Verify final state
-        var finalProcess = await _client.GetAsync($"/api/processes/{process.Id}");
-        var result = await finalProcess.Content.ReadAsAsync<Process>();
-
-        Assert.AreEqual(ProcessStatus.Completed, result.Status);
-        Assert.AreEqual(200, result.TotalAmount);
-        Assert.IsNotNull(result.Confirmation);
-    }
-}
-```
-
----
-
-## End-to-End Testing (E2E)
-
-### Definition
-
-Tests complete user workflows from the user interface through all system layers.
-
-### Characteristics
-
-- **User Perspective**: Simulates real user interactions
-- **Full Stack**: UI → API → Database → External Services
-- **Slowest**: Each test typically 30 seconds to several minutes
-
-### Scope
-
-```
-┌─────────────────────────────────────────┐
-│            E2E Test Scope               │
-├─────────────────────────────────────────┤
-│  ✅ Critical user journeys              │
-│  ✅ Login/Authentication flows          │
-│  ✅ Core business transactions          │
-│  ✅ Cross-browser functionality         │
-│  ✅ Smoke tests for deployments         │
-├─────────────────────────────────────────┤
-│  ❌ Every possible user path            │
-│  ❌ Edge cases (use UT/IT)              │
-│  ❌ Performance benchmarking            │
-└─────────────────────────────────────────┘
-```
-
-### Naming Convention
-
-**File Naming**:
-```
-[UserJourney].e2e.[ext]
-[Feature].e2e.spec.[ext]
-e2e/[feature]/[scenario].[ext]
-
-Examples:
-  user-registration.e2e.ts
-  checkout-flow.e2e.spec.ts
-  e2e/authentication/login.spec.ts
-```
-
-### Example
-
-```typescript
-// Playwright E2E Test Example
-import { test, expect } from '@playwright/test';
-
-test.describe('User Registration Journey', () => {
-    test('should complete registration and login successfully', async ({ page }) => {
-        // Step 1: Navigate to registration page
-        await page.goto('/register');
-
-        // Step 2: Fill registration form
-        await page.fill('[data-testid="email"]', 'newuser@example.com');
-        await page.fill('[data-testid="password"]', 'SecurePass123!');
-        await page.fill('[data-testid="confirm-password"]', 'SecurePass123!');
-        await page.click('[data-testid="register-button"]');
-
-        // Step 3: Verify registration success
-        await expect(page.locator('[data-testid="success-message"]'))
-            .toContainText('Registration successful');
-
-        // Step 4: Login with new account
-        await page.goto('/login');
-        await page.fill('[data-testid="email"]', 'newuser@example.com');
-        await page.fill('[data-testid="password"]', 'SecurePass123!');
-        await page.click('[data-testid="login-button"]');
-
-        // Step 5: Verify login success and dashboard redirect
-        await expect(page).toHaveURL('/dashboard');
-        await expect(page.locator('[data-testid="welcome-message"]'))
-            .toContainText('Welcome, newuser@example.com');
-    });
-});
-```
-
----
-
-## Static Testing
-
-Static testing examines work products (code, documents, requirements) without executing the software. It complements dynamic testing by finding defects earlier in the SDLC.
-
-**Reference**: ISTQB CTFL v4.0 Chapter 3, ISO/IEC/IEEE 29119-4
-
-### Types of Static Testing
-
-```
-┌─────────────────────────────────────────────────────────────┐
-│                    Static Testing Types                      │
-├─────────────────────────────────────────────────────────────┤
-│  Reviews (Manual)                                            │
-│  ├── Informal Review: Ad-hoc, no formal process             │
-│  ├── Walkthrough: Author-led, educational purpose           │
-│  ├── Technical Review: Peer-led, find defects               │
-│  └── Inspection: Formal, metrics-driven, most rigorous      │
-├─────────────────────────────────────────────────────────────┤
-│  Static Analysis (Tool-based)                                │
-│  ├── Code Analysis: Linters, complexity analyzers           │
-│  ├── Security Analysis: SAST tools (SonarQube, Checkmarx)   │
-│  ├── Architecture Analysis: Dependency checks               │
-│  └── Data Flow Analysis: Variable usage patterns            │
-└─────────────────────────────────────────────────────────────┘
-```
-
-### Review Process (ISTQB)
-
-| Phase | Activities |
-|-------|------------|
-| Planning | Define scope, entry criteria, roles |
-| Initiate Review | Distribute work products |
-| Individual Review | Each reviewer examines independently |
-| Issue Communication | Discuss findings in meeting |
-| Fixing & Reporting | Author fixes, metrics collected |
-
-### Static Analysis Tools by Language
-
-| Language | Linting | Security | Complexity |
-|----------|---------|----------|------------|
-| JavaScript/TypeScript | ESLint, Biome | npm audit, Snyk | ESLint complexity rules |
-| Python | Pylint, Ruff, Flake8 | Bandit, Safety | Radon |
-| Java | Checkstyle, PMD | SpotBugs, OWASP DC | JaCoCo |
-| C# | StyleCop, Roslyn | Security Code Scan | NDepend |
-| Go | golangci-lint | gosec | gocyclo |
-
-### When to Use Static Testing
-
-| Work Product | Review Type | Tools |
-|--------------|-------------|-------|
-| Requirements | Inspection, Walkthrough | - |
-| Design Documents | Technical Review | Architecture tools |
-| Code | Technical Review, Tool Analysis | Linters, SAST |
-| Test Plans | Walkthrough | - |
-| User Documentation | Walkthrough | Spell/grammar checkers |
-
-### Code Review Checklist
-
-```
-┌─────────────────────────────────────────────────────────────┐
-│              Code Review Focus Areas                         │
-├─────────────────────────────────────────────────────────────┤
-│  Functionality                                               │
-│  ├── Does the code do what it's supposed to do?             │
-│  ├── Are edge cases handled?                                │
-│  └── Is error handling appropriate?                         │
-├─────────────────────────────────────────────────────────────┤
-│  Maintainability                                             │
-│  ├── Is the code readable and well-organized?               │
-│  ├── Are names meaningful?                                  │
-│  └── Is complexity manageable?                              │
-├─────────────────────────────────────────────────────────────┤
-│  Security                                                    │
-│  ├── Input validation present?                              │
-│  ├── No hardcoded secrets?                                  │
-│  └── SQL injection / XSS prevention?                        │
-├─────────────────────────────────────────────────────────────┤
-│  Performance                                                 │
-│  ├── No obvious inefficiencies?                             │
-│  ├── Resource cleanup (connections, files)?                 │
-│  └── Appropriate data structures?                           │
-└─────────────────────────────────────────────────────────────┘
-```
-
-### Integration with CI/CD
-
-```yaml
-# Example: Static analysis in CI pipeline
-static-analysis:
-  stage: test
-  script:
-    - npm run lint              # Linting
-    - npm run lint:security     # Security analysis
-    - npx sonarqube-scanner     # Quality gates
-  rules:
-    - if: $CI_PIPELINE_SOURCE == "push"
-```
-
----
-
-## Test Design Techniques
-
-Test design techniques are methods for deriving and selecting test cases. ISTQB and ISO/IEC/IEEE 29119 categorize them into three main approaches.
-
-**Reference**: ISTQB CTFL v4.0 Chapter 4, ISO/IEC/IEEE 29119-4
-
-### Technique Categories
-
-```
-┌─────────────────────────────────────────────────────────────┐
-│              Test Design Technique Categories                │
-├─────────────────────────────────────────────────────────────┤
-│  Specification-Based (Black-Box)                             │
-│  └── Derive tests from requirements/specifications          │
-├─────────────────────────────────────────────────────────────┤
-│  Structure-Based (White-Box)                                 │
-│  └── Derive tests from internal code structure              │
-├─────────────────────────────────────────────────────────────┤
-│  Experience-Based                                            │
-│  └── Derive tests from tester knowledge and intuition       │
-└─────────────────────────────────────────────────────────────┘
-```
-
-### Specification-Based Techniques (Black-Box)
-
-#### 1. Equivalence Partitioning (EP)
-
-Divides input data into partitions where all values should be treated the same by the system.
-
-```
-Input: Age (valid range: 18-65)
-
-┌─────────────┬─────────────┬─────────────┐
-│  Invalid    │    Valid    │   Invalid   │
-│   < 18      │   18 - 65   │    > 65     │
-├─────────────┼─────────────┼─────────────┤
-│  Partition 1│  Partition 2│  Partition 3│
-│  Test: 10   │  Test: 30   │  Test: 70   │
-└─────────────┴─────────────┴─────────────┘
-
-Coverage: At least 1 test case per partition
-```
-
-```python
-# Python Example: Equivalence Partitioning
-def test_age_validation():
-    validator = AgeValidator(min_age=18, max_age=65)
-
-    # Partition 1: Below minimum (invalid)
-    assert validator.is_valid(10) == False
-
-    # Partition 2: Valid range
-    assert validator.is_valid(30) == True
-
-    # Partition 3: Above maximum (invalid)
-    assert validator.is_valid(70) == False
-```
-
-#### 2. Boundary Value Analysis (BVA)
-
-Tests at the boundaries of equivalence partitions where defects are most likely.
-
-```
-Input: Quantity (valid range: 1-100)
-
-       0      1      2    ...    99    100    101
-       │      │      │           │      │      │
-       ▼      ▼      ▼           ▼      ▼      ▼
-    Invalid Valid  Valid      Valid  Valid  Invalid
-    (boundary)(boundary)     (boundary)(boundary)
-
-Test Values: 0, 1, 2, 99, 100, 101
-```
-
-```typescript
-// TypeScript Example: Boundary Value Analysis
-describe('Quantity Validation', () => {
-    const validator = new QuantityValidator(1, 100);
-
-    // Lower boundary
-    it('rejects 0 (below minimum)', () => {
-        expect(validator.isValid(0)).toBe(false);
-    });
-
-    it('accepts 1 (minimum boundary)', () => {
-        expect(validator.isValid(1)).toBe(true);
-    });
-
-    it('accepts 2 (above minimum)', () => {
-        expect(validator.isValid(2)).toBe(true);
-    });
-
-    // Upper boundary
-    it('accepts 99 (below maximum)', () => {
-        expect(validator.isValid(99)).toBe(true);
-    });
-
-    it('accepts 100 (maximum boundary)', () => {
-        expect(validator.isValid(100)).toBe(true);
-    });
-
-    it('rejects 101 (above maximum)', () => {
-        expect(validator.isValid(101)).toBe(false);
-    });
-});
-```
-
-#### 3. Decision Table Testing
-
-Captures complex business rules with multiple conditions.
-
-```
-Discount Rules:
-- Premium member: 20% discount
-- Order > $100: 10% discount
-- Both conditions: 25% discount (not cumulative)
-
-┌─────────────────┬──────┬──────┬──────┬──────┐
-│ Conditions      │ TC1  │ TC2  │ TC3  │ TC4  │
-├─────────────────┼──────┼──────┼──────┼──────┤
-│ Premium Member  │  N   │  Y   │  N   │  Y   │
-│ Order > $100    │  N   │  N   │  Y   │  Y   │
-├─────────────────┼──────┼──────┼──────┼──────┤
-│ Actions         │      │      │      │      │
-├─────────────────┼──────┼──────┼──────┼──────┤
-│ Discount %      │  0%  │ 20%  │ 10%  │ 25%  │
-└─────────────────┴──────┴──────┴──────┴──────┘
-```
-
-```csharp
-// C# Example: Decision Table Testing
-[TestClass]
-public class DiscountCalculatorTests
-{
-    private DiscountCalculator _calculator;
-
-    [TestInitialize]
-    public void Setup() => _calculator = new DiscountCalculator();
-
-    [TestMethod]
-    public void Calculate_NotPremium_SmallOrder_NoDiscount()
-    {
-        var result = _calculator.Calculate(isPremium: false, orderAmount: 50);
-        Assert.AreEqual(0, result.DiscountPercent);
-    }
-
-    [TestMethod]
-    public void Calculate_Premium_SmallOrder_20PercentDiscount()
-    {
-        var result = _calculator.Calculate(isPremium: true, orderAmount: 50);
-        Assert.AreEqual(20, result.DiscountPercent);
-    }
-
-    [TestMethod]
-    public void Calculate_NotPremium_LargeOrder_10PercentDiscount()
-    {
-        var result = _calculator.Calculate(isPremium: false, orderAmount: 150);
-        Assert.AreEqual(10, result.DiscountPercent);
-    }
-
-    [TestMethod]
-    public void Calculate_Premium_LargeOrder_25PercentDiscount()
-    {
-        var result = _calculator.Calculate(isPremium: true, orderAmount: 150);
-        Assert.AreEqual(25, result.DiscountPercent);
-    }
-}
-```
-
-#### 4. State Transition Testing
-
-Tests behavior changes based on system states and transitions.
-
-```
-Order State Machine:
-
-  ┌─────────┐    place()    ┌───────────┐   pay()    ┌────────┐
-  │  Draft  │──────────────▶│  Pending  │───────────▶│  Paid  │
-  └─────────┘               └───────────┘            └────────┘
-       │                          │                       │
-       │ cancel()                 │ cancel()              │ ship()
-       ▼                          ▼                       ▼
-  ┌───────────┐             ┌───────────┐           ┌──────────┐
-  │ Cancelled │             │ Cancelled │           │ Shipped  │
-  └───────────┘             └───────────┘           └──────────┘
-
-State Transition Table:
-┌───────────┬─────────┬───────────┬───────────┬───────────┐
-│ Current   │ place() │ pay()     │ ship()    │ cancel()  │
-├───────────┼─────────┼───────────┼───────────┼───────────┤
-│ Draft     │ Pending │ Invalid   │ Invalid   │ Cancelled │
-│ Pending   │ Invalid │ Paid      │ Invalid   │ Cancelled │
-│ Paid      │ Invalid │ Invalid   │ Shipped   │ Invalid   │
-│ Shipped   │ Invalid │ Invalid   │ Invalid   │ Invalid   │
-│ Cancelled │ Invalid │ Invalid   │ Invalid   │ Invalid   │
-└───────────┴─────────┴───────────┴───────────┴───────────┘
-```
-
-```python
-# Python Example: State Transition Testing
-class TestOrderStateMachine:
-    def test_draft_to_pending_on_place(self):
-        order = Order(state="draft")
-        order.place()
-        assert order.state == "pending"
-
-    def test_pending_to_paid_on_pay(self):
-        order = Order(state="pending")
-        order.pay()
-        assert order.state == "paid"
-
-    def test_paid_to_shipped_on_ship(self):
-        order = Order(state="paid")
-        order.ship()
-        assert order.state == "shipped"
-
-    def test_invalid_transition_pay_from_draft(self):
-        order = Order(state="draft")
-        with pytest.raises(InvalidTransitionError):
-            order.pay()
-
-    def test_invalid_transition_cancel_from_shipped(self):
-        order = Order(state="shipped")
-        with pytest.raises(InvalidTransitionError):
-            order.cancel()
-```
-
-#### 5. Use Case Testing
-
-Tests complete user scenarios from start to finish.
-
-```
-Use Case: User Login
-
-Primary Flow:
-1. User enters username
-2. User enters password
-3. User clicks login
-4. System validates credentials
-5. System redirects to dashboard
-
-Alternative Flows:
-A1. Invalid credentials → Show error, remain on login
-A2. Account locked → Show locked message
-A3. Password expired → Redirect to password change
-
-Test Cases:
-- TC1: Valid credentials → Dashboard (Primary)
-- TC2: Invalid password → Error message (A1)
-- TC3: Invalid username → Error message (A1)
-- TC4: Locked account → Locked message (A2)
-- TC5: Expired password → Password change page (A3)
-```
-
-### Structure-Based Techniques (White-Box)
-
-#### 1. Statement Coverage
-
-Ensure every statement is executed at least once.
-
-```
-Code:
-1  function categorize(score) {
-2      let result;
-3      if (score >= 90) {
-4          result = 'A';
-5      } else if (score >= 70) {
-6          result = 'B';
-7      } else {
-8          result = 'C';
-9      }
-10     return result;
-11 }
-
-100% Statement Coverage requires tests:
-- Test 1: score = 95 → executes lines 1-4, 10
-- Test 2: score = 80 → executes lines 1-3, 5-6, 10
-- Test 3: score = 50 → executes lines 1-3, 5, 7-10
-```
-
-#### 2. Branch Coverage
-
-Ensure every branch (decision outcome) is executed.
-
-```
-Code:
-if (a > 0 && b > 0) {
-    doSomething();
-}
-
-Branches:
-- True branch: a > 0 AND b > 0 is true
-- False branch: a > 0 AND b > 0 is false
-
-100% Branch Coverage:
-- Test 1: a = 1, b = 1 → True branch
-- Test 2: a = 0, b = 1 → False branch (or a = 1, b = 0)
-```
-
-#### 3. Condition Coverage
-
-Ensure each condition in a decision is evaluated to both true and false.
-
-```
-Code:
-if (a > 0 && b > 0) { ... }
-
-Conditions: (a > 0), (b > 0)
-
-100% Condition Coverage:
-- Test 1: a = 1, b = 1 → (a > 0) = true, (b > 0) = true
-- Test 2: a = 0, b = 0 → (a > 0) = false, (b > 0) = false
-
-Note: Does not guarantee branch coverage!
-```
-
-#### 4. MC/DC (Modified Condition/Decision Coverage)
-
-Each condition independently affects the decision outcome. Required for safety-critical systems.
-
-```
-Code:
-if (a && b) { ... }
-
-MC/DC Requirements:
-1. Each condition evaluated to true and false
-2. Each condition independently affects outcome
-
-Test Cases:
-- Test 1: a = true,  b = true  → Decision = true
-- Test 2: a = false, b = true  → Decision = false (a changed outcome)
-- Test 3: a = true,  b = false → Decision = false (b changed outcome)
-```
-
-### Additional Specification-Based Techniques
-
-#### 6. Pairwise Testing (Combinatorial Testing)
-
-Tests all possible pairs of input parameter values, reducing test cases while maintaining good coverage.
-
-**Reference**: SWEBOK v4.0 - Input Domain-Based Techniques
-
-```
-Example: Login Form with 3 parameters, each with 3 values
-
-Parameters:
-- Browser: Chrome, Firefox, Safari
-- OS: Windows, macOS, Linux
-- Language: English, Spanish, French
-
-Full Combinatorial: 3 × 3 × 3 = 27 test cases
-Pairwise Coverage: 9 test cases (covers all pairs)
-
-┌──────┬──────────┬─────────┬──────────┐
-│ TC   │ Browser  │ OS      │ Language │
-├──────┼──────────┼─────────┼──────────┤
-│ 1    │ Chrome   │ Windows │ English  │
-│ 2    │ Chrome   │ macOS   │ Spanish  │
-│ 3    │ Chrome   │ Linux   │ French   │
-│ 4    │ Firefox  │ Windows │ Spanish  │
-│ 5    │ Firefox  │ macOS   │ French   │
-│ 6    │ Firefox  │ Linux   │ English  │
-│ 7    │ Safari   │ Windows │ French   │
-│ 8    │ Safari   │ macOS   │ English  │
-│ 9    │ Safari   │ Linux   │ Spanish  │
-└──────┴──────────┴─────────┴──────────┘
-```
-
-**Tools**: PICT (Microsoft), AllPairs, Jenny
-
-```bash
-# Using PICT (Pairwise Independent Combinatorial Testing)
-# Input file: params.txt
-# Browser: Chrome, Firefox, Safari
-# OS: Windows, macOS, Linux
-# Language: English, Spanish, French
-
-pict params.txt > test_cases.txt
-```
-
-#### 7. Data Flow Testing
-
-Tests the flow of data through a program by tracking variable definitions and uses.
-
-**Reference**: SWEBOK v4.0 - Code-Based Techniques
-
-```
-┌─────────────────────────────────────────────────────────────┐
-│              Data Flow Terminology                           │
-├─────────────────────────────────────────────────────────────┤
-│                                                              │
-│  Definition (def): Variable is assigned a value             │
-│  Use (use): Variable's value is accessed                    │
-│  - c-use: Computational use (in calculation)                │
-│  - p-use: Predicate use (in condition)                      │
-│                                                              │
-│  def-use pair: Path from definition to use                  │
-│  def-clear path: No redefinition between def and use        │
-│                                                              │
-│  Example:                                                    │
-│  1: x = 5           ← def(x)                                │
-│  2: y = x + 1       ← c-use(x), def(y)                      │
-│  3: if (x > 0)      ← p-use(x)                              │
-│  4:   z = y * 2     ← c-use(y), def(z)                      │
-│                                                              │
-└─────────────────────────────────────────────────────────────┘
-```
-
-**Coverage Criteria**:
-
-| Criterion | Requirement | Strength |
-|-----------|-------------|----------|
-| All-Defs | Every def reaches at least one use | Weak |
-| All-Uses | Every def-use pair is exercised | Medium |
-| All-DU-Paths | All def-clear paths from def to use | Strong |
-
-```python
-# Python Example: Data Flow Testing
-def calculate_discount(price, quantity, is_member):
-    # def: total
-    total = price * quantity
-
-    # def: discount
-    if is_member:  # p-use: is_member
-        discount = 0.1  # def: discount (path 1)
-    else:
-        discount = 0.0  # def: discount (path 2)
-
-    # c-use: total, discount
-    if total > 100:  # p-use: total
-        discount += 0.05  # c-use: discount, def: discount
-
-    # c-use: total, discount
-    return total * (1 - discount)
-
-# Test cases for All-Uses coverage:
-# TC1: is_member=True, total>100  → exercises def@line4, use@line10
-# TC2: is_member=False, total>100 → exercises def@line6, use@line10
-# TC3: is_member=True, total<=100 → exercises def@line4, use@line12
-# TC4: is_member=False, total<=100 → exercises def@line6, use@line12
-```
-
-### Technique Selection Guide
-
-| Technique | Best For | Test Level |
-|-----------|----------|------------|
-| Equivalence Partitioning | Input validation, ranges | UT, IT |
-| Boundary Value Analysis | Numeric limits, dates | UT, IT |
-| Decision Table | Complex business rules | UT, IT, ST |
-| State Transition | Workflows, status changes | IT, ST |
-| Use Case Testing | User scenarios | ST, E2E |
-| Pairwise Testing | Multi-parameter combinations | IT, ST |
-| Data Flow Testing | Variable lifecycle verification | UT |
-| Statement Coverage | Basic code coverage | UT |
-| Branch Coverage | Decision logic | UT |
-| MC/DC | Safety-critical systems | UT |
-
----
-
-## Experience-Based Testing
-
-Experience-based testing leverages the tester's knowledge, skills, and intuition to design and execute tests. It complements systematic techniques.
-
-**Reference**: ISTQB CTFL v4.0 Section 4.4
-
-### Types of Experience-Based Testing
-
-#### 1. Exploratory Testing
-
-Simultaneous test design, execution, and learning. The tester explores the system without predefined scripts.
-
-```
-┌─────────────────────────────────────────────────────────────┐
-│              Exploratory Testing Session                     │
-├─────────────────────────────────────────────────────────────┤
-│  Charter: "Explore the checkout process focusing on         │
-│            payment failure scenarios"                        │
-├─────────────────────────────────────────────────────────────┤
-│  Time-box: 60 minutes                                        │
-├─────────────────────────────────────────────────────────────┤
-│  Notes:                                                      │
-│  - Tested expired credit card → Got generic error           │
-│  - Tested insufficient funds → Same generic error           │
-│  - Found: No specific error messages for different failures │
-│  - Bug: Retry with same card doesn't clear previous error   │
-├─────────────────────────────────────────────────────────────┤
-│  Bugs Found: 2                                               │
-│  Areas for Further Testing: Error message specificity       │
-└─────────────────────────────────────────────────────────────┘
-```
-
-**Session-Based Test Management (SBTM)**:
-
-| Element | Description |
-|---------|-------------|
-| Charter | Mission statement for the session |
-| Time-box | Fixed duration (typically 60-90 min) |
-| Session Notes | Observations, questions, bugs found |
-| Debrief | Review findings with team |
-
-#### 2. Error Guessing
-
-Anticipate defects based on experience with similar systems or common mistakes.
-
-```
-Common Error Categories to Guess:
-
-┌─────────────────────────────────────────────────────────────┐
-│  Input Errors                                                │
-│  ├── Empty/null inputs                                      │
-│  ├── Very long strings                                      │
-│  ├── Special characters (', ", <, >, &, etc.)              │
-│  ├── Unicode/emoji characters                               │
-│  └── Negative numbers where positive expected               │
-├─────────────────────────────────────────────────────────────┤
-│  Boundary Errors                                             │
-│  ├── Off-by-one errors                                      │
-│  ├── Integer overflow/underflow                             │
-│  ├── Date boundaries (leap years, month ends)               │
-│  └── Array index out of bounds                              │
-├─────────────────────────────────────────────────────────────┤
-│  State Errors                                                │
-│  ├── Operations on deleted records                          │
-│  ├── Concurrent modifications                               │
-│  ├── Session timeout during operation                       │
-│  └── Browser back button after submission                   │
-├─────────────────────────────────────────────────────────────┤
-│  Environment Errors                                          │
-│  ├── Network timeout/disconnection                          │
-│  ├── Low disk space                                         │
-│  ├── Database connection pool exhaustion                    │
-│  └── Time zone differences                                  │
-└─────────────────────────────────────────────────────────────┘
-```
-
-#### 3. Checklist-Based Testing
-
-Use predefined checklists based on experience and standards.
-
-```markdown
-# API Endpoint Testing Checklist
-
-## Authentication & Authorization
-- [ ] Endpoint rejects unauthenticated requests
-- [ ] Endpoint rejects expired tokens
-- [ ] Endpoint enforces role-based access
-- [ ] Different user roles see appropriate data
-
-## Input Validation
-- [ ] Required fields are validated
-- [ ] Data types are enforced
-- [ ] String length limits enforced
-- [ ] Malicious input sanitized (XSS, SQL injection)
-
-## Response Handling
-- [ ] Success responses have correct status codes
-- [ ] Error responses have meaningful messages
-- [ ] Response format matches API documentation
-- [ ] Pagination works correctly
-
-## Performance
-- [ ] Response time under load is acceptable
-- [ ] No N+1 query problems
-- [ ] Large datasets handled gracefully
-```
-
-### When to Use Experience-Based Testing
-
-| Scenario | Recommended Technique |
-|----------|----------------------|
-| New feature exploration | Exploratory Testing |
-| Legacy system with no documentation | Exploratory Testing |
-| Known problematic areas | Error Guessing |
-| Regression testing | Checklist-Based |
-| Time pressure / quick validation | Error Guessing |
-| Compliance verification | Checklist-Based |
-
-### Combining with Systematic Techniques
-
-```
-┌─────────────────────────────────────────────────────────────┐
-│          Optimal Testing Approach                            │
-├─────────────────────────────────────────────────────────────┤
-│                                                              │
-│    Systematic Techniques          Experience-Based           │
-│    (70-80% of effort)            (20-30% of effort)         │
-│                                                              │
-│    ┌──────────────────┐          ┌──────────────────┐       │
-│    │ Equivalence Part.│          │ Exploratory      │       │
-│    │ Boundary Value   │    +     │ Error Guessing   │       │
-│    │ Decision Tables  │          │ Checklists       │       │
-│    └──────────────────┘          └──────────────────┘       │
-│                                                              │
-│    Provides:                     Provides:                   │
-│    - Coverage                    - Edge cases                │
-│    - Repeatability               - Real-world scenarios      │
-│    - Documentation               - Quick feedback            │
-│                                                              │
-└─────────────────────────────────────────────────────────────┘
-```
-
----
-
-## Risk-Based Testing
-
-Risk-based testing prioritizes testing efforts based on the likelihood and impact of potential failures.
-
-**Reference**: ISTQB CTFL v4.0 Section 5.2
-
-### Risk Assessment
-
-#### Risk Formula
-
-```
-Risk Level = Likelihood × Impact
-
-┌─────────────────────────────────────────────────────────────┐
-│                    Risk Matrix                               │
-├─────────────┬───────────────────────────────────────────────┤
-│             │         Impact                                 │
-│ Likelihood  │   Low (1)    Medium (2)    High (3)           │
-├─────────────┼───────────────────────────────────────────────┤
-│ High (3)    │   Medium(3)   High(6)      Critical(9)        │
-│ Medium (2)  │   Low(2)      Medium(4)    High(6)            │
-│ Low (1)     │   Low(1)      Low(2)       Medium(3)          │
-└─────────────┴───────────────────────────────────────────────┘
-```
-
-#### Risk Factors
-
-**Likelihood Factors** (Technical Risk):
-- Complexity of the feature
-- New/unfamiliar technology
-- Code quality metrics
-- Developer experience
-- Frequency of changes
-- Integration complexity
-
-**Impact Factors** (Business Risk):
-- Revenue impact
-- User base affected
-- Regulatory compliance
-- Brand reputation
-- Data security/privacy
-- Operational criticality
-
-### Risk-Based Test Prioritization
-
-```
-Example: E-commerce Application
-
-┌──────────────────────┬─────────┬─────────┬───────┬──────────┐
-│ Feature              │Likelihood│ Impact │ Risk  │ Priority │
-├──────────────────────┼─────────┼─────────┼───────┼──────────┤
-│ Payment Processing   │    2    │    3    │   6   │    1     │
-│ User Authentication  │    2    │    3    │   6   │    2     │
-│ Shopping Cart        │    2    │    2    │   4   │    3     │
-│ Product Search       │    1    │    2    │   2   │    4     │
-│ Product Reviews      │    1    │    1    │   1   │    5     │
-│ Wishlist            │    1    │    1    │   1   │    6     │
-└──────────────────────┴─────────┴─────────┴───────┴──────────┘
-
-Test Effort Allocation:
-- Critical (Risk 6+): 50% of test effort, most thorough coverage
-- Medium (Risk 3-5): 30% of test effort, standard coverage
-- Low (Risk 1-2): 20% of test effort, basic coverage
-```
-
-### Risk-Based Test Planning
-
-```markdown
-# Risk-Based Test Plan Template
-
-## 1. Risk Identification
-List all features/components and their risk factors.
-
-## 2. Risk Analysis
-Calculate risk scores using Likelihood × Impact.
-
-## 3. Test Prioritization
-| Priority | Features | Test Depth |
-|----------|----------|------------|
-| P1 | Payment, Auth | Full coverage, all techniques |
-| P2 | Cart, Checkout | Standard coverage |
-| P3 | Search, Browse | Basic happy path |
-| P4 | Reviews, Wishlist | Minimal, smoke tests |
-
-## 4. Risk Mitigation
-- P1 features: 100% automated tests, manual exploratory
-- P2 features: 80% automated, sample manual tests
-- P3 features: Key scenarios automated
-- P4 features: Basic smoke tests only
-
-## 5. Residual Risk Acceptance
-Document accepted risks for low-priority features.
-```
-
-### Continuous Risk Assessment
-
-```
-┌─────────────────────────────────────────────────────────────┐
-│            Continuous Risk Re-evaluation                     │
-├─────────────────────────────────────────────────────────────┤
-│                                                              │
-│  Sprint Start ──▶ During Sprint ──▶ Sprint End              │
-│       │                │                │                    │
-│       ▼                ▼                ▼                    │
-│  Initial Risk     Update based on:    Review:               │
-│  Assessment       - Defects found     - Actual vs Expected  │
-│                   - Code changes      - Adjust for next     │
-│                   - New requirements    sprint              │
-│                                                              │
-└─────────────────────────────────────────────────────────────┘
-```
+| Abbreviation | Full Term | Description |
+|--------------|-----------|-------------|
+| **UT** | Unit Testing | Testing individual functions/methods in isolation |
+| **IT** | Integration Testing | Testing interactions between components |
+| **ST** | System Testing | Testing the complete integrated system |
+| **AT** | Acceptance Testing | Testing against business acceptance criteria |
+| **E2E** | End-to-End Testing | Testing complete user workflows |
+| **UAT** | User Acceptance Testing | Acceptance testing performed by end users |
+| **SIT** | System Integration Testing | Testing integration of multiple systems |
 
----
-
-## Specialized Testing
-
-Modern software development requires specialized testing types beyond traditional categories.
-
-### Contract Testing
-
-Verifies that services communicate correctly according to agreed contracts. Essential for microservices architectures.
-
-```
-┌─────────────────────────────────────────────────────────────┐
-│              Consumer-Driven Contract Testing                │
-├─────────────────────────────────────────────────────────────┤
-│                                                              │
-│  Consumer                          Provider                  │
-│  (Frontend)                        (API)                     │
-│      │                                │                      │
-│      │  1. Define expectations        │                      │
-│      │─────────────────────────────▶ │                      │
-│      │                                │                      │
-│      │  2. Generate contract          │                      │
-│      │  (Pact file)                   │                      │
-│      │                                │                      │
-│      │  3. Share contract             │                      │
-│      │─────────────────────────────▶ │                      │
-│      │                                │                      │
-│      │                    4. Provider verifies               │
-│      │                       against contract                │
-│      │                                │                      │
-└─────────────────────────────────────────────────────────────┘
-```
-
-**Tools**: Pact, Spring Cloud Contract, Postman
-
-```typescript
-// Consumer Test (Pact.js Example)
-describe('User API Contract', () => {
-    it('returns user by ID', async () => {
-        await provider.addInteraction({
-            state: 'user with ID 123 exists',
-            uponReceiving: 'a request for user 123',
-            withRequest: {
-                method: 'GET',
-                path: '/users/123'
-            },
-            willRespondWith: {
-                status: 200,
-                body: {
-                    id: '123',
-                    name: Matchers.string('John Doe'),
-                    email: Matchers.email()
-                }
-            }
-        });
-
-        const user = await userClient.getUser('123');
-        expect(user.id).toBe('123');
-    });
-});
-```
-
-### Mutation Testing
-
-Evaluates test suite quality by introducing small changes (mutants) to the code and checking if tests detect them.
-
-```
-┌─────────────────────────────────────────────────────────────┐
-│                   Mutation Testing                           │
-├─────────────────────────────────────────────────────────────┤
-│                                                              │
-│  Original Code:        Mutant (change operator):            │
-│  if (a > b)            if (a >= b)    ← Boundary mutant     │
-│  if (a > b)            if (a < b)     ← Negation mutant     │
-│  return a + b;         return a - b;  ← Arithmetic mutant   │
-│  return true;          return false;  ← Return value mutant │
-│                                                              │
-├─────────────────────────────────────────────────────────────┤
-│  Mutation Score = (Killed Mutants / Total Mutants) × 100    │
-│                                                              │
-│  - Killed: Test failed → Good, test detected the change    │
-│  - Survived: Test passed → Bad, test missed the defect     │
-│                                                              │
-│  Target: > 80% mutation score for critical code             │
-└─────────────────────────────────────────────────────────────┘
-```
-
-**Tools**: Stryker (JS/TS), PITest (Java), mutmut (Python)
-
-```bash
-# Run mutation testing with Stryker
-npx stryker run
-
-# Example output:
-# Mutation score: 85.7%
-# Killed: 180  Survived: 30  No coverage: 10
-```
-
-### Chaos Engineering
-
-Proactively tests system resilience by injecting failures in production or staging environments.
-
-```
-┌─────────────────────────────────────────────────────────────┐
-│              Chaos Engineering Principles                    │
-├─────────────────────────────────────────────────────────────┤
-│                                                              │
-│  1. Define "steady state" (normal behavior metrics)         │
-│  2. Hypothesize steady state continues during chaos         │
-│  3. Introduce real-world events:                            │
-│     - Server failures                                        │
-│     - Network latency/partition                              │
-│     - Resource exhaustion                                    │
-│     - Clock skew                                             │
-│  4. Try to disprove the hypothesis                          │
-│  5. Minimize blast radius (start small)                      │
-│                                                              │
-└─────────────────────────────────────────────────────────────┘
-```
-
-**Tools**: Chaos Monkey, Gremlin, Litmus, Chaos Toolkit
-
-```yaml
-# Chaos Toolkit Experiment Example
-title: "Service resilience when database is slow"
-description: "Verify the service degrades gracefully"
-
-steady-state-hypothesis:
-  title: "Service responds within SLA"
-  probes:
-    - name: "service-responds"
-      type: probe
-      provider:
-        type: http
-        url: "http://service/health"
-        timeout: 3
-
-method:
-  - name: "inject-db-latency"
-    type: action
-    provider:
-      type: process
-      path: "tc"
-      arguments: "qdisc add dev eth0 root netem delay 500ms"
-    pauses:
-      after: 30
-
-rollbacks:
-  - name: "remove-latency"
-    type: action
-    provider:
-      type: process
-      path: "tc"
-      arguments: "qdisc del dev eth0 root"
-```
-
-### Property-Based Testing
-
-Generates random test inputs based on properties the code should satisfy.
-
-```python
-# Python Example with Hypothesis
-from hypothesis import given, strategies as st
-
-# Property: Sorting should be idempotent
-@given(st.lists(st.integers()))
-def test_sort_idempotent(xs):
-    sorted_once = sorted(xs)
-    sorted_twice = sorted(sorted_once)
-    assert sorted_once == sorted_twice
-
-# Property: Sorted list should have same elements
-@given(st.lists(st.integers()))
-def test_sort_preserves_elements(xs):
-    sorted_xs = sorted(xs)
-    assert sorted(xs) == sorted(sorted_xs)
-    assert len(xs) == len(sorted_xs)
-
-# Property: JSON encode/decode roundtrip
-@given(st.dictionaries(st.text(), st.integers()))
-def test_json_roundtrip(d):
-    assert json.loads(json.dumps(d)) == d
-```
-
-**Tools**: Hypothesis (Python), fast-check (JS/TS), QuickCheck (Haskell), FsCheck (C#)
-
-### Visual Regression Testing
-
-Detects unintended visual changes in UI components.
-
-```
-┌─────────────────────────────────────────────────────────────┐
-│              Visual Regression Testing                       │
-├─────────────────────────────────────────────────────────────┤
-│                                                              │
-│  1. Capture baseline screenshots                            │
-│  2. Run tests, capture new screenshots                      │
-│  3. Compare pixel-by-pixel or perceptually                  │
-│  4. Flag differences for review                             │
-│                                                              │
-│  ┌─────────────┐   ┌─────────────┐   ┌─────────────┐       │
-│  │  Baseline   │ → │   Current   │ → │    Diff     │       │
-│  │  Screenshot │   │  Screenshot │   │   Report    │       │
-│  └─────────────┘   └─────────────┘   └─────────────┘       │
-│                                                              │
-└─────────────────────────────────────────────────────────────┘
-```
-
-**Tools**: Percy, Chromatic, BackstopJS, Playwright visual comparisons
-
-```typescript
-// Playwright Visual Regression Example
-test('homepage visual regression', async ({ page }) => {
-    await page.goto('/');
-    await expect(page).toHaveScreenshot('homepage.png', {
-        maxDiffPixels: 100  // Allow minor differences
-    });
-});
-
-test('button component visual regression', async ({ page }) => {
-    await page.goto('/components/button');
-    const button = page.locator('[data-testid="primary-button"]');
-    await expect(button).toHaveScreenshot('primary-button.png');
-});
-```
-
-### Accessibility Testing (a11y)
-
-Ensures applications are usable by people with disabilities.
-
-```
-┌─────────────────────────────────────────────────────────────┐
-│              Accessibility Testing Checklist                 │
-├─────────────────────────────────────────────────────────────┤
-│  WCAG 2.1 Guidelines                                         │
-│  ├── Perceivable                                            │
-│  │   ├── Alt text for images                                │
-│  │   ├── Captions for video                                 │
-│  │   └── Sufficient color contrast                          │
-│  ├── Operable                                               │
-│  │   ├── Keyboard navigation                                │
-│  │   ├── Focus indicators visible                           │
-│  │   └── No keyboard traps                                  │
-│  ├── Understandable                                         │
-│  │   ├── Clear labels and instructions                      │
-│  │   ├── Predictable navigation                             │
-│  │   └── Error identification                               │
-│  └── Robust                                                 │
-│      ├── Valid HTML                                         │
-│      └── ARIA attributes correct                            │
-└─────────────────────────────────────────────────────────────┘
-```
-
-**Tools**: axe-core, Pa11y, WAVE, Lighthouse
-
-```typescript
-// Playwright + axe-core Example
-import AxeBuilder from '@axe-core/playwright';
-
-test('homepage accessibility', async ({ page }) => {
-    await page.goto('/');
-
-    const results = await new AxeBuilder({ page })
-        .withTags(['wcag2a', 'wcag2aa'])
-        .analyze();
-
-    expect(results.violations).toEqual([]);
-});
-```
-
-### Additional Specialized Testing Types (SWEBOK)
-
-The following test types are defined in SWEBOK v4.0 as test objectives:
-
-#### Installation Testing
-
-Verifies that the software installs correctly in the target environment.
-
-```
-┌─────────────────────────────────────────────────────────────┐
-│              Installation Testing Checklist                  │
-├─────────────────────────────────────────────────────────────┤
-│                                                              │
-│  Pre-Installation                                            │
-│  ├── Prerequisites verified (OS, runtime, dependencies)    │
-│  ├── Disk space requirements met                            │
-│  └── Permissions and access rights confirmed                │
-│                                                              │
-│  Installation Process                                        │
-│  ├── Fresh installation succeeds                            │
-│  ├── Upgrade from previous version succeeds                 │
-│  ├── Custom installation options work                       │
-│  └── Silent/unattended installation works                   │
-│                                                              │
-│  Post-Installation                                           │
-│  ├── Application launches correctly                         │
-│  ├── Configuration files created properly                   │
-│  ├── Registry/system settings correct                       │
-│  └── Uninstallation removes all components                  │
-│                                                              │
-└─────────────────────────────────────────────────────────────┘
-```
-
-#### Alpha and Beta Testing
-
-| Phase | Participants | Environment | Purpose |
-|-------|--------------|-------------|---------|
-| **Alpha** | Internal users, developers | Development site | Early validation, major issues |
-| **Beta** | External users, customers | Customer site | Real-world validation, feedback |
-| **Open Beta** | General public | Various | Wide exposure, stress testing |
-
-#### Recovery Testing
-
-Tests the system's ability to recover from failures.
-
-```
-┌─────────────────────────────────────────────────────────────┐
-│              Recovery Testing Scenarios                      │
-├─────────────────────────────────────────────────────────────┤
-│                                                              │
-│  Hardware Failures                                           │
-│  ├── Power outage during transaction                        │
-│  ├── Disk failure and RAID recovery                         │
-│  └── Network disconnection and reconnection                 │
-│                                                              │
-│  Software Failures                                           │
-│  ├── Application crash recovery                             │
-│  ├── Database connection loss and reconnect                 │
-│  └── Service restart behavior                               │
-│                                                              │
-│  Data Recovery                                               │
-│  ├── Backup and restore procedures                          │
-│  ├── Transaction rollback                                   │
-│  └── Point-in-time recovery                                 │
-│                                                              │
-│  Metrics:                                                    │
-│  • Recovery Time Objective (RTO): Max acceptable downtime   │
-│  • Recovery Point Objective (RPO): Max acceptable data loss │
-│                                                              │
-└─────────────────────────────────────────────────────────────┘
-```
+> **Note**: "IT" in this document always refers to "Integration Testing", not "Information Technology".
 
-#### Configuration Testing
-
-Tests the system under different configurations.
-
-```
-Configuration Matrix Example:
-
-┌──────────────────┬─────────┬─────────┬─────────┐
-│ Configuration    │ Config A│ Config B│ Config C│
-├──────────────────┼─────────┼─────────┼─────────┤
-│ Memory           │ 4 GB    │ 8 GB    │ 16 GB   │
-│ Database         │ SQLite  │ MySQL   │ PostgreSQL│
-│ Cache            │ None    │ Redis   │ Memcached│
-│ Load Balancer    │ None    │ Nginx   │ HAProxy │
-└──────────────────┴─────────┴─────────┴─────────┘
-
-Test each supported configuration combination.
-```
-
-#### Back-to-Back Testing
+---
 
-Compares outputs of multiple implementations with identical inputs.
+## Testing Framework Selection
 
-```
-┌─────────────────────────────────────────────────────────────┐
-│              Back-to-Back Testing                            │
-├─────────────────────────────────────────────────────────────┤
-│                                                              │
-│  Use Cases:                                                  │
-│  ├── Comparing new version against old version              │
-│  ├── Comparing optimized code against reference impl        │
-│  ├── Cross-platform consistency verification                │
-│  └── Validating refactored code behavior                    │
-│                                                              │
-│  Process:                                                    │
-│  ┌─────────┐     ┌─────────────┐     ┌──────────┐          │
-│  │ Input   │────▶│ Version A   │────▶│ Output A │──┐       │
-│  │ Data    │     └─────────────┘     └──────────┘  │       │
-│  │         │     ┌─────────────┐     ┌──────────┐  ▼       │
-│  │         │────▶│ Version B   │────▶│ Output B │─▶Compare │
-│  └─────────┘     └─────────────┘     └──────────┘          │
-│                                                              │
-└─────────────────────────────────────────────────────────────┘
-```
+| Framework | Levels | Best For |
+|-----------|--------|----------|
+| **ISTQB** | UT → IT/SIT → ST → AT/UAT | Enterprise, compliance, formal QA |
+| **Industry Pyramid** | UT (70%) → IT (20%) → E2E (10%) | Agile, DevOps, CI/CD |
 
-#### Usability Testing
+---
 
-Evaluates how easily users can learn and use the system.
+## Testing Pyramid (Default Ratios)
 
 ```
-┌─────────────────────────────────────────────────────────────┐
-│              Usability Testing Methods                       │
-├─────────────────────────────────────────────────────────────┤
-│                                                              │
-│  Observational Methods                                       │
-│  ├── Think-aloud protocol                                   │
-│  ├── Eye tracking                                           │
-│  └── Session recording                                      │
-│                                                              │
-│  Task-Based Methods                                          │
-│  ├── Task completion rate                                   │
-│  ├── Time on task                                           │
-│  └── Error rate                                             │
-│                                                              │
-│  Survey Methods                                              │
-│  ├── System Usability Scale (SUS)                           │
-│  ├── Net Promoter Score (NPS)                               │
-│  └── Post-task questionnaires                               │
-│                                                              │
-│  Key Metrics:                                                │
-│  • Learnability: Time to complete first task                │
-│  • Efficiency: Time to complete after learning              │
-│  • Memorability: Performance after period of non-use        │
-│  • Satisfaction: User rating scores                         │
-│                                                              │
-└─────────────────────────────────────────────────────────────┘
+              ┌─────────┐
+              │   E2E   │  ← 10% (Fewer, slower, expensive)
+             ─┴─────────┴─
+            ┌─────────────┐
+            │    IT/SIT   │  ← 20% (Integration Testing)
+           ─┴─────────────┴─
+          ┌─────────────────┐
+          │       UT        │  ← 70% (Unit Testing - Foundation)
+          └─────────────────┘
 ```
 
-### Specialized Testing Summary
-
-| Type | Purpose | When to Use |
-|------|---------|-------------|
-| Contract Testing | API compatibility | Microservices |
-| Mutation Testing | Test quality assessment | Critical code paths |
-| Chaos Engineering | Resilience validation | Production systems |
-| Property-Based | Edge case discovery | Algorithms, parsers |
-| Visual Regression | UI consistency | Frontend changes |
-| Accessibility | Inclusive design | All user-facing apps |
-| Installation | Deployment verification | Release candidates |
-| Alpha/Beta | Early user validation | Pre-release phases |
-| Recovery | Failure recovery | Business-critical systems |
-| Configuration | Multi-config support | Cross-platform apps |
-| Back-to-Back | Version comparison | Migrations, refactoring |
-| Usability | User experience | User-facing applications |
+| Level | Percentage | Execution Time Target |
+|-------|------------|----------------------|
+| Unit Testing (UT) | 70% | < 10 min total |
+| Integration Testing (IT) | 20% | < 30 min total |
+| E2E Testing | 10% | < 2 hours total |
 
 ---
 
-## Test-Related Measures
-
-Quantitative measures for evaluating both the software under test and the quality of testing itself.
-
-**Reference**: SWEBOK v4.0 Section 5.4
+## Test Level Requirements
 
-### Program Evaluation Measures
+### Unit Testing (UT)
 
-#### Fault Density
-
-```
-Fault Density = Total Faults / Size
-
-Where Size can be:
-- KLOC (Thousands of Lines of Code)
-- Function Points
-- Story Points
-
-Industry Benchmarks:
-┌─────────────────────┬────────────────────────────┐
-│ Quality Level       │ Faults per KLOC            │
-├─────────────────────┼────────────────────────────┤
-│ Typical             │ 1 - 25                     │
-│ Good                │ 0.5 - 1                    │
-│ Excellent           │ < 0.5                      │
-│ Safety-Critical     │ < 0.1                      │
-└─────────────────────┴────────────────────────────┘
-```
-
-#### Reliability Growth Models
-
-Track defect discovery rate over time to predict remaining defects.
-
-```
-┌─────────────────────────────────────────────────────────────┐
-│              Reliability Growth Curve                        │
-├─────────────────────────────────────────────────────────────┤
-│                                                              │
-│  Defects                                                     │
-│  Found                                                       │
-│    │     ╭────────────────────────────────                  │
-│    │   ╭─╯                                                   │
-│    │  ╭╯                                                     │
-│    │ ╭╯                                                      │
-│    │╭╯                                                       │
-│    ├╯                                                        │
-│    └──────────────────────────────────────▶ Time            │
-│                                                              │
-│  As testing progresses:                                      │
-│  • Defect discovery rate decreases                          │
-│  • Curve approaches asymptote (total defects)               │
-│  • Remaining defects can be estimated                       │
-│                                                              │
-│  Common Models:                                              │
-│  • Goel-Okumoto: Exponential                                │
-│  • Musa: Logarithmic                                        │
-│  • Jelinski-Moranda: De-eutrophication                      │
-│                                                              │
-└─────────────────────────────────────────────────────────────┘
-```
+**Characteristics**: Isolated, Fast (< 100ms each), Deterministic
 
-### Test Evaluation Measures
+#### Scope
 
-#### Fault Seeding
+| Include | Exclude |
+|---------|---------|
+| Single function/method | Database queries |
+| Single class | External API calls |
+| Pure business logic | File I/O operations |
+| Data transformations | Multi-class interactions |
+| Validation rules | Network calls |
 
-Insert known faults to measure test effectiveness.
+#### Naming Convention
 
+**File Naming**:
 ```
-Fault Detection Effectiveness = Seeded Faults Found / Total Seeded Faults
-
-If tests find 80% of seeded faults, estimate:
-- Similar detection rate for real faults
-- Remaining faults ≈ Found faults / Detection rate
-
-Example:
-- Seeded 20 faults, tests found 16 (80%)
-- Found 40 real faults during testing
-- Estimated total real faults ≈ 40 / 0.8 = 50
-- Estimated remaining ≈ 10 faults
+[ClassName]Tests.[ext]      # C#
+[ClassName].test.[ext]      # TypeScript/JavaScript
+[class_name]_test.[ext]     # Python, Go
 ```
 
-#### Coverage Metrics Summary
+**Method Naming** (choose ONE per project):
 
-| Metric | Formula | Target |
-|--------|---------|--------|
-| Statement Coverage | Executed statements / Total statements | ≥ 70% |
-| Branch Coverage | Executed branches / Total branches | ≥ 60% |
-| Condition Coverage | Conditions evaluated T & F / Total conditions | ≥ 80% |
-| MC/DC | Conditions independently affecting decision | 100% (safety-critical) |
-| Requirements Coverage | Tested requirements / Total requirements | 100% |
-| Mutation Score | Killed mutants / Total mutants | ≥ 80% |
+| Style | Best For | Example |
+|-------|----------|---------|
+| `[Method]_[Scenario]_[Result]` | C#, Java | `CalculateTotal_NegativePrice_ThrowsException()` |
+| `should_[behavior]_when_[condition]` | JavaScript/TypeScript | `should_reject_login_when_account_locked()` |
+| `test_[method]_[scenario]_[expected]` | Python (pytest) | `test_validate_email_invalid_format_returns_false()` |
 
-### Testing Process Metrics
+#### Coverage Thresholds
 
-```
-┌─────────────────────────────────────────────────────────────┐
-│              Key Testing Metrics                             │
-├─────────────────────────────────────────────────────────────┤
-│                                                              │
-│  Efficiency Metrics                                          │
-│  ├── Test Case Productivity = Tests created / Effort        │
-│  ├── Defect Detection Rate = Defects found / Test hours     │
-│  └── Automation Rate = Automated tests / Total tests        │
-│                                                              │
-│  Effectiveness Metrics                                       │
-│  ├── Defect Leakage = Prod defects / Total defects          │
-│  ├── Test Effectiveness = Defects found / Defects present   │
-│  └── Phase Containment = Defects found in phase / Injected  │
-│                                                              │
-│  Progress Metrics                                            │
-│  ├── Test Execution Rate = Tests run / Tests planned        │
-│  ├── Pass Rate = Tests passed / Tests executed              │
-│  └── Blocking Rate = Blocked tests / Total tests            │
-│                                                              │
-└─────────────────────────────────────────────────────────────┘
-```
+| Metric | Minimum | Recommended |
+|--------|---------|-------------|
+| Line Coverage | 70% | 85% |
+| Branch Coverage | 60% | 80% |
+| Function Coverage | 80% | 90% |
 
 ---
 
-## Defect Management
-
-Systematic tracking and management of defects throughout the testing lifecycle.
-
-**Reference**: ISTQB CTFL v4.0 Section 5.5, ISO/IEC/IEEE 29119-3
-
-### Defect Lifecycle
-
-```
-┌─────────────────────────────────────────────────────────────┐
-│                    Defect Lifecycle                          │
-├─────────────────────────────────────────────────────────────┤
-│                                                              │
-│   ┌────────┐    ┌────────┐    ┌──────────┐                  │
-│   │  New   │───▶│  Open  │───▶│ In Progress│                │
-│   └────────┘    └────────┘    └──────────┘                  │
-│                      │              │                        │
-│                      │              ▼                        │
-│                      │        ┌──────────┐                  │
-│                      │        │  Fixed   │                  │
-│                      │        └──────────┘                  │
-│                      │              │                        │
-│                      │              ▼                        │
-│                      │        ┌──────────┐    ┌──────────┐  │
-│                      │        │ Verified │───▶│  Closed  │  │
-│                      │        └──────────┘    └──────────┘  │
-│                      │              │                        │
-│                      │              ▼                        │
-│                      │        ┌──────────┐                  │
-│                      └───────▶│ Reopened │                  │
-│                               └──────────┘                  │
-│                                                              │
-│   Alternative paths:                                         │
-│   - New → Rejected (not a bug, duplicate)                   │
-│   - Open → Deferred (postponed to later release)            │
-│   - Open → Won't Fix (accepted risk)                        │
-│                                                              │
-└─────────────────────────────────────────────────────────────┘
-```
-
-### Defect Report Template
-
-```markdown
-# Defect Report
-
-## Summary
-[One-line description of the defect]
-
-## ID: BUG-1234
-## Priority: P1/P2/P3/P4
-## Severity: Critical/High/Medium/Low
-
-## Environment
-- **Version**: 2.3.1
-- **OS**: Windows 11 / macOS 14.2
-- **Browser**: Chrome 120
-- **Device**: Desktop / Mobile
-
-## Steps to Reproduce
-1. Navigate to login page
-2. Enter valid username "testuser"
-3. Enter invalid password "wrong123"
-4. Click "Login" button
-5. Observe error message
-
-## Expected Result
-Error message: "Invalid credentials. Please try again."
-
-## Actual Result
-Generic error: "Something went wrong."
+### Integration Testing (IT)
 
-## Screenshots/Videos
-[Attach relevant media]
+**Characteristics**: Component integration, Real dependencies (often containerized), 1-10 seconds each
 
-## Additional Information
-- Occurs consistently (100% reproducible)
-- Related to ticket: FEAT-456
-- Log file: [attached]
-```
-
-### Severity vs Priority
+#### When Required
 
-| Severity | Description | Examples |
-|----------|-------------|----------|
-| Critical | System crash, data loss, security breach | App won't start, data corruption |
-| High | Major feature broken, no workaround | Cannot complete checkout |
-| Medium | Feature impaired but has workaround | Export fails, manual copy works |
-| Low | Minor issue, cosmetic | Typo, alignment issue |
+**Decision Rule**: If your unit test uses a wildcard matcher (`any()`, `It.IsAny<>`, `Arg.Any<>`) for a query/filter parameter, that functionality MUST have an integration test.
 
-| Priority | Description | Response Time |
-|----------|-------------|---------------|
-| P1 | Fix immediately | Same day |
-| P2 | Fix before release | Within sprint |
-| P3 | Fix when possible | Next sprint |
-| P4 | Nice to fix | Backlog |
+| Scenario | Reason |
+|----------|--------|
+| Query predicates | Mocks cannot verify filter expressions |
+| Entity relationships | Verify foreign key correctness |
+| Composite keys | In-memory DB may differ from real DB |
+| Field mapping | DTO ↔ Entity transformations |
+| Pagination | Row ordering and counting |
+| Transactions | Rollback behavior |
 
-### Defect Metrics
+#### Scope
 
-```
-┌─────────────────────────────────────────────────────────────┐
-│                    Key Defect Metrics                        │
-├─────────────────────────────────────────────────────────────┤
-│                                                              │
-│  Defect Density = Total Defects / Size (KLOC or FP)         │
-│  - Industry average: 1-25 defects per KLOC                  │
-│                                                              │
-│  Defect Detection Efficiency (DDE) =                        │
-│    Defects found before release / Total defects × 100       │
-│  - Target: > 90%                                            │
-│                                                              │
-│  Defect Removal Efficiency (DRE) =                          │
-│    Defects removed / Defects injected × 100                 │
-│  - Target: > 95%                                            │
-│                                                              │
-│  Mean Time to Detect (MTTD) = Avg time from injection       │
-│  Mean Time to Resolve (MTTR) = Avg time from report to fix  │
-│                                                              │
-│  Defect Leakage Rate = Production defects / Total defects   │
-│  - Target: < 5%                                             │
-│                                                              │
-└─────────────────────────────────────────────────────────────┘
-```
+| Include | Exclude |
+|---------|---------|
+| Database CRUD operations | Full user workflows |
+| Repository + Database | Cross-service communication |
+| Service + Repository | UI interactions |
+| API endpoint + Service layer | |
+| Message queue producers/consumers | |
+| Cache read/write operations | |
 
-### Root Cause Analysis
+#### Naming Convention
 
 ```
-┌─────────────────────────────────────────────────────────────┐
-│              Common Defect Root Causes                       │
-├─────────────────────────────────────────────────────────────┤
-│  Requirements (35-40%)                                       │
-│  ├── Ambiguous requirements                                 │
-│  ├── Missing requirements                                   │
-│  └── Changed requirements                                   │
-├─────────────────────────────────────────────────────────────┤
-│  Design (20-25%)                                             │
-│  ├── Incorrect algorithm                                    │
-│  ├── Integration issues                                     │
-│  └── Performance not considered                             │
-├─────────────────────────────────────────────────────────────┤
-│  Code (25-30%)                                               │
-│  ├── Logic errors                                           │
-│  ├── Boundary conditions                                    │
-│  └── Exception handling                                     │
-├─────────────────────────────────────────────────────────────┤
-│  Environment (10-15%)                                        │
-│  ├── Configuration issues                                   │
-│  ├── Third-party dependencies                               │
-│  └── Data issues                                            │
-└─────────────────────────────────────────────────────────────┘
+[ComponentName]IntegrationTests.[ext]
+[ComponentName].integration.test.[ext]
+[ComponentName].itest.[ext]
 ```
 
 ---
 
-## Test Process Management
-
-Structured approach to planning, monitoring, and controlling testing activities.
+### System Testing (ST)
 
-**Reference**: ISTQB CTFL v4.0 Chapter 5, ISO/IEC/IEEE 29119-2
+**Characteristics**: Complete system, Production-like environment, Requirement-based
 
-### Test Planning
+#### Scope
 
-#### Test Plan Components (ISO/IEC/IEEE 29119-3)
+| Include | Exclude |
+|---------|---------|
+| Complete API workflows | UI visual testing |
+| Cross-service transactions | User journey simulations |
+| Data flow through entire system | A/B testing scenarios |
+| Security requirements | |
+| Performance under load | |
+| Error handling & recovery | |
 
-```
-┌─────────────────────────────────────────────────────────────┐
-│                   Test Plan Structure                        │
-├─────────────────────────────────────────────────────────────┤
-│                                                              │
-│  1. Test Plan Identification                                 │
-│     - Project name, version, date                           │
-│                                                              │
-│  2. Introduction                                             │
-│     - Purpose, scope, objectives                            │
-│                                                              │
-│  3. Test Items                                               │
-│     - Features to be tested                                 │
-│     - Features not to be tested                             │
-│                                                              │
-│  4. Test Approach                                            │
-│     - Test levels and types                                 │
-│     - Test techniques                                       │
-│     - Entry/exit criteria                                   │
-│                                                              │
-│  5. Test Environment                                         │
-│     - Hardware, software, tools                             │
-│     - Test data requirements                                │
-│                                                              │
-│  6. Test Schedule                                            │
-│     - Milestones, dependencies                              │
-│                                                              │
-│  7. Roles and Responsibilities                               │
-│     - Team structure, RACI matrix                           │
-│                                                              │
-│  8. Risks and Contingencies                                  │
-│     - Risk assessment, mitigation                           │
-│                                                              │
-│  9. Approvals                                                │
-│     - Sign-off requirements                                 │
-│                                                              │
-└─────────────────────────────────────────────────────────────┘
-```
-
-#### Entry and Exit Criteria
-
-| Criteria Type | Examples |
-|---------------|----------|
-| **Entry Criteria** (start testing) | Requirements approved, code complete, environment ready, test data available |
-| **Exit Criteria** (stop testing) | All P1/P2 tests passed, coverage target met, no critical defects open |
-
-```markdown
-## Entry Criteria for System Testing
-- [ ] All integration tests passed
-- [ ] Test environment deployed and verified
-- [ ] Test data prepared and loaded
-- [ ] Test cases reviewed and approved
-- [ ] All blockers from IT resolved
-
-## Exit Criteria for System Testing
-- [ ] 100% of critical test cases executed
-- [ ] 95% of high priority test cases passed
-- [ ] No Critical or High severity defects open
-- [ ] Code coverage > 80%
-- [ ] Performance benchmarks met
-```
+#### Types
 
-### Test Monitoring and Control
-
-#### Key Progress Metrics
-
-```
-┌─────────────────────────────────────────────────────────────┐
-│              Test Progress Metrics                           │
-├─────────────────────────────────────────────────────────────┤
-│                                                              │
-│  Execution Metrics:                                          │
-│  - Tests Planned: 500                                        │
-│  - Tests Executed: 350 (70%)                                │
-│  - Tests Passed: 320 (91% of executed)                      │
-│  - Tests Failed: 30 (9% of executed)                        │
-│  - Tests Blocked: 15                                         │
-│                                                              │
-│  Defect Metrics:                                             │
-│  - Total Defects Found: 45                                   │
-│  - Open Defects: 12 (3 Critical, 5 High, 4 Medium)          │
-│  - Fixed Defects: 28                                         │
-│  - Verified Defects: 20                                      │
-│                                                              │
-│  Coverage Metrics:                                           │
-│  - Requirements Coverage: 85%                                │
-│  - Code Coverage: 78%                                        │
-│  - Risk Coverage: 90%                                        │
-│                                                              │
-└─────────────────────────────────────────────────────────────┘
-```
+| Type | Description |
+|------|-------------|
+| Functional | Verify features work as specified |
+| Performance | Load, stress, scalability testing |
+| Security | Penetration, vulnerability scanning |
+| Reliability | Failover, recovery, stability |
+| Compatibility | Cross-platform, browser compatibility |
 
-#### Test Dashboard Example
+#### Naming Convention
 
 ```
-Test Progress Dashboard - Sprint 15
-═══════════════════════════════════════════════════════════════
-
-Test Execution                    Defect Status
-█████████████████░░░░ 85%        Open:     ███░░░░░░░ 12
-                                  Fixed:    ████████░░ 28
-Passed  │████████████████│ 320    Verified: ██████░░░░ 20
-Failed  │██              │  30
-Blocked │█               │  15    Trend: ↓ (improving)
-
-Coverage                          Build Health
-Requirements: ███████████░ 85%    Last Build: ✓ Pass
-Code:         ████████░░░░ 78%    Unit Tests: 245/245 ✓
-Risk Items:   █████████░░░ 90%    Int Tests:  89/92 ⚠
-                                  Flaky Rate: 2.1%
+[Feature]SystemTests.[ext]
+[Feature].system.test.[ext]
+[Feature]_st.[ext]
 ```
 
-### Test Completion
-
-#### Test Summary Report
-
-```markdown
-# Test Summary Report
-
-## Project: [Project Name]
-## Version: [Version Number]
-## Test Period: [Start Date] - [End Date]
-
-## Executive Summary
-[Brief overview of testing activities and outcomes]
-
-## Test Scope
-- Features tested: [list]
-- Features not tested: [list with justification]
-
-## Test Results Summary
-
-| Test Level | Planned | Executed | Passed | Failed | Pass Rate |
-|------------|---------|----------|--------|--------|-----------|
-| Unit       | 500     | 500      | 498    | 2      | 99.6%     |
-| Integration| 150     | 150      | 145    | 5      | 96.7%     |
-| System     | 200     | 195      | 188    | 7      | 96.4%     |
-| E2E        | 50      | 48       | 46     | 2      | 95.8%     |
-
-## Defect Summary
-
-| Severity | Found | Fixed | Open | Deferred |
-|----------|-------|-------|------|----------|
-| Critical | 2     | 2     | 0    | 0        |
-| High     | 8     | 7     | 1    | 0        |
-| Medium   | 15    | 12    | 2    | 1        |
-| Low      | 20    | 10    | 5    | 5        |
-
-## Coverage Analysis
-- Requirements coverage: 95%
-- Code coverage: 82%
-- Risk coverage: 100% (all high-risk items tested)
+---
 
-## Open Issues and Risks
-1. [Issue 1]: Impact and mitigation
-2. [Issue 2]: Impact and mitigation
+### End-to-End Testing (E2E)
 
-## Recommendations
-1. [Recommendation 1]
-2. [Recommendation 2]
+**Characteristics**: User perspective, Full stack (UI → API → Database), Slowest (30s+ each)
 
-## Conclusion
-[Final assessment and release recommendation]
+#### Scope
 
-## Sign-off
-- QA Lead: [Name, Date]
-- Dev Lead: [Name, Date]
-- Product Owner: [Name, Date]
-```
+| Include | Exclude |
+|---------|---------|
+| Critical user journeys | Every possible user path |
+| Login/Authentication flows | Edge cases (use UT/IT) |
+| Core business transactions | Performance benchmarking |
+| Cross-browser functionality | |
+| Smoke tests for deployments | |
 
-### Test Process Improvement
+#### Naming Convention
 
 ```
-┌─────────────────────────────────────────────────────────────┐
-│              Continuous Improvement Cycle                    │
-├─────────────────────────────────────────────────────────────┤
-│                                                              │
-│         ┌───────────┐                                        │
-│         │   Plan    │                                        │
-│         └─────┬─────┘                                        │
-│               │                                              │
-│               ▼                                              │
-│  ┌───────────┐         ┌───────────┐                        │
-│  │   Act     │◀───────▶│    Do     │                        │
-│  └───────────┘         └─────┬─────┘                        │
-│               ▲              │                               │
-│               │              ▼                               │
-│         ┌─────┴─────┐                                        │
-│         │   Check   │                                        │
-│         └───────────┘                                        │
-│                                                              │
-│  Retrospective Questions:                                    │
-│  - What went well?                                          │
-│  - What could be improved?                                  │
-│  - What actions will we take?                               │
-│                                                              │
-└─────────────────────────────────────────────────────────────┘
+[UserJourney].e2e.[ext]
+[Feature].e2e.spec.[ext]
+e2e/[feature]/[scenario].[ext]
 ```
 
 ---
 
 ## Test Doubles
 
-### Types
-
-| Type | Purpose | Example Use |
+| Type | Purpose | When to Use |
 |------|---------|-------------|
 | **Stub** | Returns predefined values | Fixed API responses |
 | **Mock** | Verifies interactions | Verify method called |
@@ -2455,78 +219,34 @@ Risk Items:   █████████░░░ 90%    Int Tests:  89/92 ⚠
 | **Spy** | Records calls, delegates to real | Partial mocking |
 | **Dummy** | Placeholder, never used | Fill required parameters |
 
-### Usage Guidelines
+### Usage by Test Level
 
-```
-┌─────────────────────────────────────────────────────────┐
-│                  When to Use What                       │
-├─────────────────────────────────────────────────────────┤
-│  Unit Tests (UT)                                        │
-│  ├── Use Mocks/Stubs for all external dependencies     │
-│  └── Verify interactions with Mocks                    │
-├─────────────────────────────────────────────────────────┤
-│  Integration Tests (IT)                                 │
-│  ├── Use Fakes for databases (in-memory, containers)   │
-│  ├── Use Stubs for external APIs                       │
-│  └── Minimize mocking - test real integrations         │
-├─────────────────────────────────────────────────────────┤
-│  System Tests (ST)                                      │
-│  ├── Use real components whenever possible             │
-│  ├── Use Fakes only for external third-party services  │
-│  └── No mocking within the system boundary             │
-├─────────────────────────────────────────────────────────┤
-│  E2E Tests                                              │
-│  ├── Use real everything                               │
-│  └── Stub only external payment/email services         │
-└─────────────────────────────────────────────────────────┘
-```
+| Level | Guidance |
+|-------|----------|
+| **UT** | Use Mocks/Stubs for all external dependencies |
+| **IT** | Use Fakes for databases, Stubs for external APIs |
+| **ST** | Use real components, Fakes only for external third-party |
+| **E2E** | Use real everything; stub only external payment/email |
 
 ---
 
 ## Mock Limitations
 
-### Query Predicate Verification
-
-**Problem**:
-When mocking repository methods that accept query predicates (e.g., lambda expressions,
-filter functions), using wildcard matchers like `any()` ignores the actual query logic,
-allowing incorrect queries to pass unit tests.
+**Problem**: Wildcard matchers (`any()`, `It.IsAny<>`) ignore actual query logic, allowing incorrect queries to pass.
 
-**Example**:
+**Rule**: If mocking a method that accepts a query/filter/predicate parameter, you MUST have a corresponding integration test to verify the query logic.
 
 ```python
-# Python Example
+# Example - Python
 # ❌ This test cannot verify query correctness
 mock_repo.find.return_value = users
-# Query could be wrong, test still passes
 
 # ✓ Add integration test to verify actual query
 ```
 
-```typescript
-// TypeScript Example
-// ❌ Jest mock ignores actual filter
-jest.spyOn(repo, 'findBy').mockResolvedValue(users);
-
-// ✓ Verify with integration test
-```
-
-```csharp
-// C# Example
-// ❌ Moq ignores the actual expression
-_repo.Setup(r => r.FindAsync(It.IsAny<Expression<Func<User, bool>>>()))
-     .ReturnsAsync(users);
-
-// ✓ Verify with integration test or use It.Is<> to validate
-```
-
-**Rule of Thumb**:
-If your unit test mocks a method that accepts a query/filter/predicate parameter,
-you MUST have a corresponding integration test to verify the query logic.
-
 ---
 
-## Test Data Management
+## Test Data Requirements
 
 ### Principles
 
@@ -2535,294 +255,63 @@ you MUST have a corresponding integration test to verify the query logic.
 3. **Determinism**: Tests don't depend on shared state
 4. **Readability**: Test data clearly shows intent
 
-### Patterns
-
-```csharp
-// Builder Pattern for Test Data
-public class UserBuilder
-{
-    private string _name = "Default User";
-    private string _email = "default@example.com";
-    private bool _isActive = true;
-
-    public UserBuilder WithName(string name)
-    {
-        _name = name;
-        return this;
-    }
-
-    public UserBuilder WithEmail(string email)
-    {
-        _email = email;
-        return this;
-    }
-
-    public UserBuilder Inactive()
-    {
-        _isActive = false;
-        return this;
-    }
-
-    public User Build() => new User
-    {
-        Name = _name,
-        Email = _email,
-        IsActive = _isActive
-    };
-}
-
-// Usage in tests
-var activeUser = new UserBuilder()
-    .WithName("Active User")
-    .Build();
-
-var inactiveUser = new UserBuilder()
-    .WithName("Inactive User")
-    .Inactive()
-    .Build();
-```
-
-### Distinct Identifiers
-
-When entities have both a surrogate key (auto-generated ID) and a business identifier
-(e.g., employee number, department code), test data MUST use different values for each.
+### Distinct Identifiers Rule
 
-**Problem**:
-If test data uses identical values for both fields, field mapping errors go undetected.
+When entities have both a surrogate key (auto-generated ID) and a business identifier, test data MUST use different values for each.
 
 ```python
-# Python Example
-# ❌ Wrong: id equals business_code
+# ❌ Wrong: id equals business_code - mapping errors undetected
 dept = Department(id=1, business_code=1)
 
 # ✓ Correct: distinct values catch mapping errors
 dept = Department(id=1, business_code=1001)
 ```
 
-```csharp
-// C# Example
-// ❌ Wrong: Id equals DeptId - mapping errors go undetected
-var dept = new Department { Id = 1, DeptId = 1 };
-
-// ✓ Correct: distinct values catch field mapping bugs
-var dept = new Department { Id = 1, DeptId = 1001 };
-```
-
-**Validation**:
-```csharp
-// C#
-testData.Dept.Id.Should().NotBe(testData.Dept.DeptId,
-    "Test precondition: Id must differ from business identifier");
-```
-
-### Composite Keys
+### Composite Keys Rule
 
 For entities with composite primary keys, ensure each record has a unique key combination.
 
-```csharp
-// C# Example
-// ❌ Key collision - same (Id, SendTime) combination
-var batch1 = new BatchRecord { Id = 0, SendTime = now };
-var batch2 = new BatchRecord { Id = 0, SendTime = now };  // Conflict!
-
-// ✓ Unique combinations
-var batch1 = new BatchRecord { Id = 0, SendTime = now.AddSeconds(1) };
-var batch2 = new BatchRecord { Id = 0, SendTime = now.AddSeconds(2) };
-```
+```python
+# ❌ Key collision
+batch1 = BatchRecord(id=0, send_time=now)
+batch2 = BatchRecord(id=0, send_time=now)  # Conflict!
 
-**Tip**: Create helper functions that auto-generate unique composite keys.
-
-```csharp
-// C# Helper Example
-private static int _timeOffset = 0;
-public static BatchRecord CreateWithUniqueKey(DateTime baseTime)
-{
-    return new BatchRecord
-    {
-        SendTime = baseTime.AddSeconds(Interlocked.Increment(ref _timeOffset))
-    };
-}
+# ✓ Unique combinations
+batch1 = BatchRecord(id=0, send_time=now + timedelta(seconds=1))
+batch2 = BatchRecord(id=0, send_time=now + timedelta(seconds=2))
 ```
 
 ---
 
-## Test Environment Isolation
+## Test Environment
 
-### Purpose
+### Language-Specific Tools
 
-Ensure consistent, reproducible test results across development machines and CI/CD pipelines.
-
-### Why It Matters
-
-- **Reproducibility**: Same tests produce same results everywhere
-- **Isolation**: Project dependencies don't conflict with system or other projects
-- **CI/CD Parity**: Local environment matches CI environment
-
-### Language-Specific Virtual Environments
-
-| Language | Tools | Lock File |
-|----------|-------|-----------|
-| Python | venv, virtualenv, conda, poetry | requirements.txt, poetry.lock |
-| Node.js | nvm, fnm + npm/yarn/pnpm | package-lock.json, yarn.lock |
-| Ruby | rbenv, rvm, bundler | Gemfile.lock |
-| Java | SDKMAN, jenv, Maven/Gradle | pom.xml, build.gradle.lock |
+| Language | Version Manager | Lock File |
+|----------|----------------|-----------|
+| Python | venv, virtualenv, poetry | requirements.txt, poetry.lock |
+| Node.js | nvm, fnm | package-lock.json, yarn.lock |
+| Ruby | rbenv, rvm | Gemfile.lock |
+| Java | SDKMAN, jenv | pom.xml, build.gradle.lock |
 | .NET | dotnet SDK | packages.lock.json |
 | Go | go mod | go.sum |
 | Rust | rustup, cargo | Cargo.lock |
 
-#### Best Practices
+### Best Practices
 
 1. **Always use virtual environments** for development and testing
 2. **Commit lock files** to version control
 3. **Pin versions** in CI/CD pipelines
 4. **Document required runtime versions** in README or .tool-versions
 
-#### Example: Python with venv
-
-```bash
-# Create virtual environment
-python -m venv .venv
-
-# Activate
-source .venv/bin/activate  # Linux/macOS
-.venv\Scripts\activate     # Windows
-
-# Install dependencies
-pip install -r requirements.txt
-
-# Run tests
-pytest tests/
-```
-
-#### Example: Node.js with nvm
-
-```bash
-# Use project's Node version
-nvm use
-
-# Install dependencies
-npm ci
-
-# Run tests
-npm test
-```
-
-### Containerized Testing
-
-Use containers to provide consistent external dependencies (databases, message queues, etc.) for integration and system tests.
-
-#### When to Use
-
-| Test Level | Container Usage |
-|------------|-----------------|
-| UT (Unit Testing) | ❌ Not needed - use mocks |
-| IT (Integration Testing) | ✅ Testcontainers for databases, caches |
-| ST (System Testing) | ✅ Docker Compose for full environment |
-| E2E (End-to-End) | ✅ Full containerized stack |
-
-#### Testcontainers
-
-Testcontainers provides lightweight, disposable containers for testing.
-
-```csharp
-// C# Example with Testcontainers
-public class DatabaseIntegrationTests : IAsyncLifetime
-{
-    private readonly PostgreSqlContainer _postgres = new PostgreSqlBuilder()
-        .WithImage("postgres:15")
-        .Build();
-
-    public async Task InitializeAsync()
-    {
-        await _postgres.StartAsync();
-    }
-
-    public async Task DisposeAsync()
-    {
-        await _postgres.DisposeAsync();
-    }
-
-    [Fact]
-    public async Task Should_Connect_To_Database()
-    {
-        var connectionString = _postgres.GetConnectionString();
-        // Use connectionString for tests
-    }
-}
-```
-
-```python
-# Python Example with Testcontainers
-import pytest
-from testcontainers.postgres import PostgresContainer
-
-@pytest.fixture(scope="module")
-def postgres_container():
-    with PostgresContainer("postgres:15") as postgres:
-        yield postgres
-
-def test_database_connection(postgres_container):
-    connection_url = postgres_container.get_connection_url()
-    # Use connection_url for tests
-```
-
-#### Docker Compose for System Tests
-
-```yaml
-# docker-compose.test.yml
-version: '3.8'
-services:
-  app:
-    build: .
-    depends_on:
-      - db
-      - redis
-      - rabbitmq
-    environment:
-      - DATABASE_URL=postgres://test:test@db:5432/testdb
-      - REDIS_URL=redis://redis:6379
-      - RABBITMQ_URL=amqp://guest:guest@rabbitmq:5672
-
-  db:
-    image: postgres:15
-    environment:
-      POSTGRES_USER: test
-      POSTGRES_PASSWORD: test
-      POSTGRES_DB: testdb
-
-  redis:
-    image: redis:7-alpine
-
-  rabbitmq:
-    image: rabbitmq:3-management
-```
-
-```bash
-# Run system tests with Docker Compose
-docker-compose -f docker-compose.test.yml up -d
-npm run test:system
-docker-compose -f docker-compose.test.yml down -v
-```
-
-### Environment Parity Checklist
+### Container Usage by Test Level
 
-```
-┌─────────────────────────────────────────────────────────────┐
-│              Environment Parity Checklist                   │
-├─────────────────────────────────────────────────────────────┤
-│  ✅ Same runtime version (Node, Python, etc.) locally & CI │
-│  ✅ Same database version in containers & production       │
-│  ✅ Lock files committed and used in CI (npm ci, pip -r)   │
-│  ✅ Environment variables documented and consistent        │
-│  ✅ Container images tagged with specific versions         │
-│  ✅ .tool-versions or similar for runtime version mgmt     │
-├─────────────────────────────────────────────────────────────┤
-│  ❌ Using "latest" tags in production/CI                   │
-│  ❌ Different DB versions between dev and CI               │
-│  ❌ Missing lock files in repository                       │
-│  ❌ Hardcoded paths or machine-specific configurations     │
-└─────────────────────────────────────────────────────────────┘
-```
+| Level | Container Usage |
+|-------|-----------------|
+| UT | Not needed - use mocks |
+| IT | Testcontainers for databases, caches |
+| ST | Docker Compose for full environment |
+| E2E | Full containerized stack |
 
 ---
 
@@ -2830,63 +319,22 @@ docker-compose -f docker-compose.test.yml down -v
 
 ### Test Execution Strategy
 
-```yaml
-# Example CI Pipeline
-stages:
-  - unit-test        # Run on every commit
-  - integration-test # Run on every commit
-  - system-test      # Run on PR merge to main
-  - e2e-test         # Run on release candidates
-
-unit-test:
-  stage: unit-test
-  script:
-    - npm run test:unit
-  timeout: 10m
-  rules:
-    - if: $CI_PIPELINE_SOURCE == "push"
-
-integration-test:
-  stage: integration-test
-  services:
-    - postgres:14
-    - redis:7
-  script:
-    - npm run test:integration
-  timeout: 30m
-  rules:
-    - if: $CI_PIPELINE_SOURCE == "push"
-
-system-test:
-  stage: system-test
-  environment: staging
-  script:
-    - npm run test:system
-  timeout: 2h
-  rules:
-    - if: $CI_COMMIT_BRANCH == "main"
-
-e2e-test:
-  stage: e2e-test
-  environment: staging
-  script:
-    - npm run test:e2e
-  timeout: 4h
-  rules:
-    - if: $CI_COMMIT_TAG
-```
-
-### Test Reports
+| Stage | When | Timeout |
+|-------|------|---------|
+| Unit Test | Every commit | 10 min |
+| Integration Test | Every commit | 30 min |
+| System Test | PR merge to main | 2 hours |
+| E2E Test | Release candidates | 4 hours |
 
-Required metrics for each test level:
+### Required Metrics
 
 | Metric | UT | IT | ST | E2E |
 |--------|----|----|----|----|
-| Pass/Fail Count | ✅ | ✅ | ✅ | ✅ |
-| Execution Time | ✅ | ✅ | ✅ | ✅ |
-| Coverage % | ✅ | ✅ | ⚠️ | ❌ |
-| Flaky Test Rate | ✅ | ✅ | ✅ | ✅ |
-| Screenshots/Videos | ❌ | ❌ | ⚠️ | ✅ |
+| Pass/Fail Count | Required | Required | Required | Required |
+| Execution Time | Required | Required | Required | Required |
+| Coverage % | Required | Required | Optional | Not needed |
+| Flaky Test Rate | Required | Required | Required | Required |
+| Screenshots/Videos | Not needed | Not needed | Optional | Required |
 
 ---
 
@@ -2894,20 +342,10 @@ Required metrics for each test level:
 
 ### AAA Pattern
 
-```csharp
-[TestMethod]
-public void MethodName_Scenario_ExpectedBehavior()
-{
-    // Arrange - Set up test data and environment
-    var input = CreateTestInput();
-    var sut = new SystemUnderTest();
-
-    // Act - Execute the behavior under test
-    var result = sut.Execute(input);
-
-    // Assert - Verify the result
-    Assert.AreEqual(expected, result);
-}
+```
+// Arrange - Set up test data and environment
+// Act - Execute the behavior under test
+// Assert - Verify the result
 ```
 
 ### FIRST Principles
@@ -2922,209 +360,89 @@ public void MethodName_Scenario_ExpectedBehavior()
 
 ### Anti-Patterns to Avoid
 
-```
-❌ Test Interdependence
-   Tests that must run in specific order
-
-❌ Flaky Tests
-   Tests that sometimes pass, sometimes fail
-
-❌ Testing Implementation Details
-   Tests that break when refactoring
-
-❌ Over-Mocking
-   Mocking so much that nothing real is tested
-
-❌ Missing Assertions
-   Tests that verify nothing meaningful
-
-❌ Magic Numbers/Strings
-   Unexplained values in test code
-
-❌ Identical Test IDs
-   Using same values for surrogate and business keys
-```
+- Test Interdependence (tests must run in specific order)
+- Flaky Tests (sometimes pass, sometimes fail)
+- Testing Implementation Details (tests break on refactoring)
+- Over-Mocking (nothing real is tested)
+- Missing Assertions (tests verify nothing meaningful)
+- Magic Numbers/Strings (unexplained values)
+- Identical Test IDs (same values for surrogate and business keys)
 
 ---
 
 ## Test Documentation Structure
 
-Improve test discoverability by maintaining a standardized documentation structure within test directories.
-
 ### tests/README.md Required Sections
 
-Every `tests/` directory SHOULD include a README.md with the following sections for discoverability.
+Every `tests/` directory SHOULD include a README.md with:
 
 #### 1. Test Overview Table
 
-List all test types with count, technology stack, and execution environment.
-
-```markdown
 | Test Type | Count | Framework | Environment |
 |-----------|-------|-----------|-------------|
 | Unit Tests | 150 | Jest | Node.js |
 | Integration Tests | 45 | Jest | Node.js + TestContainers |
 | E2E Tests | 12 | Playwright | Browser |
-```
 
 #### 2. Current Status Section
 
-Display latest test execution results with clear pass/fail indicators.
-
-```markdown
-## Current Status
-
 | Metric | Value | Target | Status |
 |--------|-------|--------|--------|
-| Pass Rate | 98.5% | ≥ 95% | ✅ |
-| Line Coverage | 82% | ≥ 80% | ✅ |
-| Branch Coverage | 75% | ≥ 70% | ✅ |
-
-**Last Run**: 2026-01-20 14:30 UTC
-**Report**: [test-report-20260120-143000.md](results/test-report-20260120-143000.md)
-```
+| Pass Rate | 98.5% | >= 95% | Pass |
+| Line Coverage | 82% | >= 80% | Pass |
+| Branch Coverage | 75% | >= 70% | Pass |
 
 #### 3. Report Links Section
 
-Include links to test reports, gap analysis, and coverage summary.
-
-```markdown
-## Reports
-
 | Report Type | Location | Description |
 |-------------|----------|-------------|
-| Test Results | `results/` | Timestamped test execution reports |
-| Coverage | `coverage/` | Code coverage reports (HTML, JSON) |
-| Gap Analysis | `docs/gap-analysis.md` | Missing test coverage analysis |
-```
+| Test Results | `results/` | Timestamped execution reports |
+| Coverage | `coverage/` | Code coverage reports |
+| Gap Analysis | `docs/gap-analysis.md` | Missing coverage analysis |
 
 ### Test Report Naming Convention
 
 | Item | Convention | Example |
 |------|------------|---------|
-| Report filename | `test-report-YYYYMMDD-HHMMSS.md` | `test-report-20260120-143000.md` |
-| Report directory | `tests/results/` | `tests/results/test-report-*.md` |
-| Coverage directory | `tests/coverage/` | `tests/coverage/lcov-report/` |
-| Gap analysis | `tests/docs/gap-analysis.md` | - |
+| Report filename | `test-report-YYYYMMDD-HHMMSS.md` | `test-report-20260129-143000.md` |
+| Report directory | `tests/results/` | |
+| Coverage directory | `tests/coverage/` | |
 
-### Directory Structure Example
+### Directory Structure
 
 ```
 tests/
 ├── README.md                    # Test overview and status
 ├── results/                     # Test execution reports
-│   ├── test-report-20260120-143000.md
-│   └── test-report-20260119-090000.md
 ├── coverage/                    # Coverage reports
-│   ├── lcov-report/
-│   └── coverage-summary.json
 ├── docs/                        # Test documentation
-│   └── gap-analysis.md
 ├── unit/                        # Unit tests
 ├── integration/                 # Integration tests
 └── e2e/                         # End-to-end tests
 ```
 
-### Benefits
-
-| Benefit | Description |
-|---------|-------------|
-| **Discoverability** | Developers can quickly find test status without searching |
-| **Transparency** | Current quality metrics visible at a glance |
-| **Traceability** | Historical reports enable trend analysis |
-| **Onboarding** | New team members understand test structure immediately |
-
 ---
 
-## Quick Reference Card
+## Coverage Targets Summary
 
-```
-┌─────────────────────────────────────────────────────────────┐
-│           Reference Standards                                │
-├─────────────────────────────────────────────────────────────┤
-│  • ISTQB CTFL v4.0 - Testing certification                  │
-│  • ISO/IEC/IEEE 29119 - Testing standards                   │
-│  • SWEBOK v4.0 - Software engineering knowledge             │
-├─────────────────────────────────────────────────────────────┤
-│              Testing Fundamentals (SWEBOK)                   │
-├─────────────────────────────────────────────────────────────┤
-│  Error → Fault → Failure (cause chain)                      │
-│  Oracle Problem: How to know expected result?               │
-│  Limitation: Testing proves presence, not absence of bugs   │
-│  Testability: Controllability + Observability + Isolability │
-├─────────────────────────────────────────────────────────────┤
-│              Testing Framework Options                       │
-├─────────────────────────────────────────────────────────────┤
-│  ISTQB: UT → IT/SIT → ST → AT/UAT (Enterprise/Compliance)  │
-│  Industry: UT (70%) → IT (20%) → E2E (10%) (Agile/DevOps)  │
-├─────────────────────────────────────────────────────────────┤
-│                    Testing Levels Summary                   │
-├──────────┬──────────────────────────────────────────────────┤
-│   UT     │ Single unit, isolated, mocked deps, < 100ms     │
-├──────────┼──────────────────────────────────────────────────┤
-│  IT/SIT  │ Component integration, real DB, 1-10 sec        │
-├──────────┼──────────────────────────────────────────────────┤
-│   ST     │ Full system, requirement-based (ISTQB only)     │
-├──────────┼──────────────────────────────────────────────────┤
-│  E2E     │ User journeys, UI to DB, critical paths only    │
-├──────────┼──────────────────────────────────────────────────┤
-│  AT/UAT  │ Business validation by end users (ISTQB only)   │
-├──────────┴──────────────────────────────────────────────────┤
-│                    Test Types (ISTQB)                       │
-├─────────────────────────────────────────────────────────────┤
-│  Functional: Verify system behavior (black-box)            │
-│  Non-Functional: Performance, security, usability          │
-│  Structural: Code coverage, white-box techniques           │
-│  Change-Related: Confirmation & regression testing         │
-├─────────────────────────────────────────────────────────────┤
-│                 Test Design Techniques                      │
-├─────────────────────────────────────────────────────────────┤
-│  Black-Box: EP, BVA, Decision Table, State Transition      │
-│             Pairwise Testing, Use Case Testing              │
-│  White-Box: Statement, Branch, Condition, MC/DC            │
-│             Data Flow (All-Defs, All-Uses)                  │
-│  Experience: Exploratory, Error Guessing, Checklists       │
-├─────────────────────────────────────────────────────────────┤
-│                    Coverage Targets                         │
-├─────────────────────────────────────────────────────────────┤
-│  Line: 70% min / 85% recommended                           │
-│  Branch: 60% min / 80% recommended                         │
-│  Function: 80% min / 90% recommended                       │
-│  Mutation Score: ≥ 80% for critical code                   │
-├─────────────────────────────────────────────────────────────┤
-│              Specialized Testing Types                      │
-├─────────────────────────────────────────────────────────────┤
-│  Contract: API compatibility for microservices             │
-│  Mutation: Test quality via code mutations                 │
-│  Chaos: Resilience via failure injection                   │
-│  Property-Based: Random inputs based on properties         │
-│  Visual Regression: UI screenshot comparison               │
-│  Accessibility: WCAG compliance validation                 │
-│  Installation: Deployment verification                      │
-│  Recovery: Failure recovery (RTO/RPO)                       │
-│  Configuration: Multi-config testing                        │
-│  Usability: User experience (SUS, NPS)                      │
-├─────────────────────────────────────────────────────────────┤
-│               Test-Related Measures                         │
-├─────────────────────────────────────────────────────────────┤
-│  Fault Density = Faults / KLOC (target: < 1)               │
-│  Defect Leakage = Prod defects / Total defects (< 5%)      │
-│  Fault Seeding: Insert known faults to measure detection   │
-│  Reliability Growth: Track defect rate over time           │
-└─────────────────────────────────────────────────────────────┘
-```
+| Metric | Minimum | Recommended |
+|--------|---------|-------------|
+| Line | 70% | 85% |
+| Branch | 60% | 80% |
+| Function | 80% | 90% |
+| Mutation Score | - | >= 80% (critical code) |
 
 ---
 
 ## Related Standards
 
+- [Testing Theory Knowledge Base](../skills/testing-guide/testing-theory.md) - Educational content, examples, techniques
 - [Test-Driven Development](test-driven-development.md) - TDD/BDD/ATDD methodology
-- [Test Completeness Dimensions](test-completeness-dimensions.md) - 7-dimension test coverage
+- [Test Completeness Dimensions](test-completeness-dimensions.md) - 8-dimension test coverage
 - [Spec-Driven Development](spec-driven-development.md) - SDD workflow integration
-- [Anti-Hallucination Standard](anti-hallucination.md)
 - [Code Check-in Standards](checkin-standards.md)
 - [Code Review Checklist](code-review-checklist.md)
-- [Commit Message Guide](commit-message-guide.md)
+- [Deployment Standards](deployment-standards.md) - Test requirements for deployment readiness
 
 ---
 
@@ -3132,13 +450,14 @@ tests/
 
 | Version | Date | Changes |
 |---------|------|---------|
-| 2.2.0 | 2026-01-20 | Added Test Documentation Structure section: tests/README.md required sections, test report naming conventions, directory structure example. |
-| 2.1.0 | 2026-01-05 | Added SWEBOK v4.0 reference. New sections: Testing Fundamentals (Faults vs Failures, Oracle Problem, Theoretical Limitations, Testability, Test Adequacy), Test-Related Measures (Fault Density, Reliability Growth, Fault Seeding). Expanded: Test Design Techniques (Pairwise Testing, Data Flow Testing), Specialized Testing (Installation, Alpha/Beta, Recovery, Configuration, Back-to-Back, Usability). Updated Quick Reference Card. |
-| 2.0.0 | 2026-01-05 | Major update aligned with ISTQB CTFL v4.0 and ISO/IEC/IEEE 29119. Added: Static Testing (reviews, static analysis), Test Design Techniques (EP, BVA, Decision Table, State Transition, Use Case, Statement/Branch/Condition/MC/DC coverage), Experience-Based Testing (exploratory, error guessing, checklists), Risk-Based Testing (risk assessment, prioritization), Specialized Testing (contract, mutation, chaos, property-based, visual regression, accessibility), Defect Management (lifecycle, metrics, root cause), Test Process Management (planning, monitoring, completion) |
-| 1.3.0 | 2025-12-29 | Add: Testing Framework Selection (ISTQB vs Industry Pyramid), IT/SIT abbreviation clarification, source references |
-| 1.2.0 | 2025-12-19 | Add: Mock Limitations section, When Integration Tests Are Required, Distinct Identifiers, Composite Keys test data patterns |
-| 1.1.1 | 2025-12-11 | Improved: System test example to use generic domain concepts instead of specific business terminology |
-| 1.1.0 | 2025-12-05 | Add test environment isolation section (venv, containers) |
+| 3.0.0 | 2026-01-29 | **Major refactor**: Split into Rules (this file) and Theory (testing-theory.md). Reduced from 141KB/3185 lines to ~12KB/350 lines. All educational content moved to skills/testing-guide/testing-theory.md. Rules-only format optimized for AI agent consumption. |
+| 2.2.0 | 2026-01-20 | Added Test Documentation Structure section |
+| 2.1.0 | 2026-01-05 | Added SWEBOK v4.0 reference, Testing Fundamentals, Test-Related Measures |
+| 2.0.0 | 2026-01-05 | Major update aligned with ISTQB CTFL v4.0 and ISO/IEC/IEEE 29119 |
+| 1.3.0 | 2025-12-29 | Add Testing Framework Selection, IT/SIT abbreviation clarification |
+| 1.2.0 | 2025-12-19 | Add Mock Limitations, Integration Test requirements, Test Data patterns |
+| 1.1.1 | 2025-12-11 | Improved System test example with generic domain concepts |
+| 1.1.0 | 2025-12-05 | Add test environment isolation section |
 | 1.0.0 | 2025-12-05 | Initial testing standards with UT/IT/ST/E2E coverage |
 
 ---