Back

gstack Tutorial 8: QA & Security (Live Testing + OWASP+STRIDE Audits)

/qa tests your app with live browser, finds bugs, fixes with atomic commits. /cso security audit covers OWASP Top 10 + STRIDE threat model with zero-noise design and exploit scenarios.

Tutorial Overview

Series index: gstack Tutorial Series

/qa tests your app with a live browser, finds bugs, fixes them, then re-verifies. /cso runs a security audit covering OWASP Top 10 + STRIDE threat model.

What you will learn

  • /qa full QA workflow with auto-fix
  • ✅ Regression test generation from fixes
  • /qa-only report-only mode
  • /cso security audit with zero-noise design
  • ✅ Exploit scenarios for each finding
  • ✅ Full QA flow example

Why Live QA?

Static testing misses UI bugs

flowchart LR
    A[Unit Tests Pass] --> B[Deploy]
    B --> C[UI Broken]
    C --> D[User Complaint]

    style C fill:#ffcccc
    style D fill:#ffcccc

/qa catches what users see

flowchart TD
    A[/qa] --> B[Live Browser]
    B --> C[Click Through Flows]
    C --> D[Find Visual Bugs]
    D --> E[Fix with Atomic Commit]
    E --> F[Re-verify]
    F --> G{Passed?}
    G -->|No| D
    G -->|Yes| H[Regression Test]

    style A fill:#e1f5ff
    style H fill:#e8f5e9

/qa — Full QA Workflow

How it works

  1. Launch browser — Real Chromium via Playwright
  2. Navigate to target — Your staging or production URL
  3. Click through flows — Login, forms, navigation
  4. Find bugs — Visual issues, broken links, missing elements
  5. Fix with atomic commits — One fix per commit
  6. Re-verify — Run the same flow again
  7. Generate regression test — Every fix becomes a test

Usage

/qa https://staging.myapp.com

Output:

QA Testing https://staging.myapp.com

┌─────────────────────────────────────────────────────────────┐
│ QA SESSION                                                   │
├─────────────────────────────────────────────────────────────┤
│ 🧪 Testing login flow...                                     │
│ ✅ Login successful                                          │
│                                                              │
│ 🧪 Testing dashboard navigation...                          │
│ ❌ BUG FOUND: Sidebar menu not visible on mobile            │
│    Location: src/components/Sidebar.tsx                      │
│    Issue: CSS media query missing                            │
│                                                              │
│ 🔧 Fixing...                                                 │
│ Commit: fix sidebar mobile visibility                        │
│                                                              │
│ 🧪 Re-verifying...                                           │
│ ✅ Sidebar now visible on mobile                             │
│                                                              │
│ 📝 Generating regression test...                             │
│ Created: tests/sidebar-mobile.test.ts                        │
└─────────────────────────────────────────────────────────────┘

QA Complete: 1 bug found, 1 fixed, 1 test added

Bug categories

Category Example Auto-fix
Visual Element hidden on mobile Yes
Functional Button not clickable Yes
Content Missing text, typo Yes
Performance Slow page load No (ASK)
Accessibility Missing ARIA labels Yes

Atomic commits

Each fix is a separate commit:

fix: sidebar mobile visibility (QA #1)
fix: form validation message color (QA #2)
fix: missing aria-label on submit button (QA #3)

Regression Test Generation

Every fix becomes a test

// tests/sidebar-mobile.test.ts
// Generated from QA fix: sidebar mobile visibility

import { test, expect } from '@playwright/test';

test('sidebar visible on mobile viewport', async ({ page }) => {
  await page.setViewportSize({ width: 375, height: 667 });
  await page.goto('/dashboard');
  await expect(page.locator('[data-testid="sidebar"]')).toBeVisible();
});

Test tracking

┌────────────────────────────────────────────┐
│ QA TEST COVERAGE                            │
├────────────────────────────────────────────┤
│ Tests generated: 12                         │
│ From QA sessions: 3                         │
│ Pass rate: 100%                             │
├────────────────────────────────────────────┤
│ Latest: sidebar-mobile.test.ts              │
└────────────────────────────────────────────┘

/qa-only — Report Mode

When to use

  • You want a QA report without code changes
  • External QA team will fix issues
  • Document bugs before sprint planning
  • Compliance audit documentation

Usage

/qa-only https://staging.myapp.com

Output:

QA Report Only (no fixes)

┌─────────────────────────────────────────────────────────────┐
│ QA REPORT                                                    │
├─────────────────────────────────────────────────────────────┤
│ Summary:                                                     │
│ - Bugs found: 5                                              │
│ - Severity distribution:                                     │
│   🔴 HIGH: 1 (login form submits without validation)        │
│   🟡 MEDIUM: 2 (broken links, missing tooltips)             │
│   🟢 LOW: 2 (typos, color contrast)                         │
│                                                              │
│ Details:                                                     │
│                                                              │
│ 🔴 HIGH: Login form accepts empty email                     │
│    Path: /login                                              │
│    Expected: Validation error on empty submit                │
│    Actual: Form submits, shows server error                  │
│    Screenshot: qa-bug-001.png                                │
│                                                              │
│ 🟡 MEDIUM: "Learn More" link broken on homepage             │
│    Path: /                                                   │
│    Expected: Navigate to /features                           │
│    Actual: 404 page                                          │
│    Screenshot: qa-bug-002.png                                │
│                                                              │
│ ...                                                          │
└─────────────────────────────────────────────────────────────┘

Report saved: qa-report-2026-04-07.md
No fixes applied. Use /qa to fix these issues.

/cso — Security Audit

What it covers

OWASP Top 10 + STRIDE threat model:

OWASP Category STRIDE Category
A01 Broken Access Control Spoofing
A02 Cryptographic Failures Tampering
A03 Injection Repudiation
A04 Insecure Design Information Disclosure
A05 Security Misconfiguration Elevation of Privilege
A06 Vulnerable Components Denial of Service
A07 Auth Failures -
A08 Software Integrity -
A09 Logging Failures -
A10 SSRF -

Zero-noise design

17 false positive exclusions + 8/10 confidence gate:

┌────────────────────────────────────────────┐
│ SECURITY AUDIT CONFIGURATION               │
├────────────────────────────────────────────┤
│ Confidence threshold: 8/10                 │
│ False positive exclusions: 17 patterns     │
│ - Generic placeholder secrets              │
│ - Example.com URLs                         │
│ - Test fixtures                            │
│ - Documentation examples                   │
│ - Intentional demo code                    │
└────────────────────────────────────────────┘

Usage

/cso

Output:

Running security audit...

┌─────────────────────────────────────────────────────────────┐
│ CSO SECURITY AUDIT                                           │
├─────────────────────────────────────────────────────────────┤
│ Files scanned: 47                                            │
│ Findings: 2                                                  │
│                                                              │
│ 🔴 HIGH: SQL Injection in user search                       │
│    Location: src/api/search.ts:23                            │
│    Confidence: 9/10                                          │
│                                                              │
│    Code:                                                     │
│      const query = `SELECT * FROM users WHERE name           │
│                     LIKE '%${input}%'`;                      │
│                                                              │
│    Exploit scenario:                                         │
│      1. Attacker enters: '; DROP TABLE users; --             │
│      2. Query becomes: SELECT * FROM users WHERE name        │
│         LIKE '%'; DROP TABLE users; --%'                     │
│      3. Users table deleted                                  │
│                                                              │
│    Fix: Use parameterized query                              │
│      db.users.findMany({ where: { name: { contains: input }}})│
│                                                              │
│ 🟡 MEDIUM: Missing CSRF protection on form                  │
│    Location: src/components/Form.tsx:45                      │
│    Confidence: 8/10                                          │
│                                                              │
│    Code:                                                     │
│      <form action="/api/submit" method="POST">               │
│        {/* No CSRF token */}                                 │
│      </form>                                                 │
│                                                              │
│    Exploit scenario:                                         │
│      1. Attacker creates malicious site                      │
│      2. Victim visits attacker site while logged in          │
│      3. Hidden form POSTs to your /api/submit                │
│      4. Action executed with victim's credentials            │
│                                                              │
│    Fix: Add CSRF token to form                               │
│      <input type="hidden" name="_csrf" value={csrfToken} />   │
└─────────────────────────────────────────────────────────────┘

Security audit complete. 2 findings require fixes.
Run /qa after fixing to verify.

Exploit scenarios

Every finding includes:

  1. Attack vector — How to exploit
  2. Impact — What happens
  3. Step-by-step walkthrough — Concrete attack path
  4. Fix — Specific code change

Full QA Flow Example

Scenario

Test and secure a new feature on staging.

Commands

# Step 1: Security audit first
/cso

# [Fix security findings]

# Step 2: QA testing
/qa https://staging.myapp.com

# [QA finds and fixes bugs]

# Step 3: QA-only for final report
/qa-only https://staging.myapp.com

# Step 4: Ready for ship
/ship

Integration with review workflow

flowchart TD
    A[Code Complete] --> B[/review]
    B --> C[/cso]
    C --> D{Security findings?}
    D -->|Yes| E[Fix security]
    E --> C
    D -->|No| F[/qa]
    F --> G{Bugs found?}
    G -->|Yes| H[Fix bugs]
    H --> F
    G -->|No| I[/qa-only]
    I --> J[Generate report]
    J --> K[/ship]

    style B fill:#fff3e0
    style C fill:#ffebee
    style F fill:#e8f5e9
    style K fill:#e1f5ff

Skill Quick Reference

Command Purpose Output
/qa <url> Full QA with fixes Bugs fixed, tests added
/qa-only <url> Report only Bug report, no fixes
/cso Security audit OWASP + STRIDE findings
/qa --flows Test specific flows Targeted flow testing
/qa --screenshots Capture all screenshots Visual documentation

Summary

QA & Security in gstack provides:

  1. Live browser testing — See what users see
  2. Auto-fix with commits — One fix, one commit, one test
  3. Regression coverage — Every fix becomes a test
  4. Security audit — OWASP + STRIDE, zero-noise
  5. Exploit scenarios — Concrete attack walkthroughs

Key takeaways

  • ✅ Run /cso before /qa (security first)
  • ✅ Use /qa for auto-fix, /qa-only for reports
  • ✅ Check regression tests after QA session
  • ✅ Review exploit scenarios to understand impact

Series navigation: