corgispec-qa-smoke

name	corgispec-qa-smoke
description	Smoke test gate — verifies the application launches and critical paths are accessible before deeper QA
license	MIT
compatibility	Requires a running or launchable application. Called before any deeper QA testing begins.
metadata	{"author":"corgispec","version":"1.0.0","generatedBy":"1.0.0"}

Smoke Test Gate

"Does it even launch?" — The first gate in any QA cycle.

Overview

This skill executes a minimal smoke test to confirm the application is functional at the most basic level before investing time in deeper QA. If smoke fails, all further testing is aborted — there is no point testing features on a broken build.

A smoke pass means:

• The application starts without crashing
• No HTTP 500 errors on critical endpoints
• No unhandled runtime exceptions in logs
• Critical navigation paths are reachable
• Build version matches the expected release

When to Use

• As the first step after deploying or launching a build for QA
• Before executing any test cases from qa-testcases.md
• After a hotfix deployment to confirm basic stability
• When a QA session begins and you need a go/no-go decision

Do NOT use this skill for deep functional testing, regression, or performance validation.

Preconditions

• Application is deployed or can be launched locally
• Expected build version is known (from tasks.md, release tag, or deploy log)
• Critical paths are identified (login page, main dashboard, primary API health endpoint)

Steps

1. Launch or confirm application is running

Start the application (or confirm the deployed instance is reachable):

• Web app: verify the root URL returns HTTP 200
• API service: verify the health/status endpoint responds
• CLI tool: verify --version or --help executes without error

If the app fails to start or the URL is unreachable, FAIL immediately.

2. Verify build version

Confirm the running instance matches the expected version:

• Check version endpoint, page footer, response headers, or CLI output
• Compare against the expected version from the change artifacts

If version does not match, FAIL — wrong build is deployed.

3. Check for runtime errors

Inspect available logs (console, server logs, browser devtools) for:

• Unhandled exceptions or stack traces
• Fatal errors during startup
• Critical dependency failures (DB connection, auth service)

If critical errors are present, FAIL.

4. Verify critical paths are accessible

Navigate or request each critical path:

• Authentication page loads (if applicable)
• Main dashboard/home page renders
• Primary API endpoints return expected status codes (200/201, not 500/503)
• No blank pages or broken layouts on key screens

If any critical path returns 500 or fails to render, FAIL.

5. Read assigned test cases

If qa-testcases.md exists in the change directory:

1. Read the file and identify cases assigned to the current smoke scope
2. Execute only cases tagged [smoke] or explicitly listed for this gate
3. Record pass/fail for each

6. Report result

Produce a smoke report in this format:

## Smoke Test Report

- **Build Version:** <actual> (expected: <expected>)
- **Timestamp:** <ISO 8601>
- **Result:** PASS | FAIL

### Checks

| Check | Status | Notes |
|-------|--------|-------|
| App launches | PASS/FAIL | <detail> |
| Version match | PASS/FAIL | <detail> |
| No runtime errors | PASS/FAIL | <detail> |
| Critical path: <name> | PASS/FAIL | <detail> |
| ... | ... | ... |

### Decision

- **PASS** → Proceed to full QA test cases
- **FAIL** → Abort QA. Reason: <summary>

Common Mistakes

• Testing too deeply — Smoke is not regression. Only check "does it launch and respond." Move on quickly.
• Ignoring version mismatch — Testing the wrong build wastes everyone's time. Always verify version first.
• Skipping log inspection — An app can return 200 while throwing errors internally. Check logs.
• Continuing after failure — If smoke fails, STOP. Do not proceed to deeper QA. Report and block.