@keber/qa-framework 1.5.1 → 1.6.1

package/skills/qa-ado-integration/SKILL.md

@@ -63,7 +63,7 @@ After sync, each TC file must have `adoId: <NNN>` in its YAML frontmatter block.
 
 ### Step 4 — Configure Playwright ADO reporter
 
-See `references/scripts-and-config.md` for the reporter config block to add to `qa/07-automation/playwright.config.ts`.
+See `references/scripts-and-config.md` for the reporter config block to add to `qa/07-automation/e2e/playwright.config.ts`.
 
 Required fields:
 - `orgUrl`, `projectName`, `planId`, `runName`
@@ -100,4 +100,4 @@ Update `qa/08-azure-integration/module-registry.json` with:
 - ADO Test Plan populated with test cases
 - `qa/03-test-cases/automated/TC-*.md` — ADO IDs injected
 - `qa/08-azure-integration/module-registry.json` updated
-- `qa/07-automation/playwright.config.ts` updated with reporter config
+- `qa/07-automation/e2e/playwright.config.ts` updated with reporter config

package/skills/qa-automation/SKILL.md

@@ -14,7 +14,7 @@ description: >
 
 **Stage**: 5 — Automation  
 **Prerequisite**: All specs for the target submodule are complete and contain no `PENDING-CODE` sections  
-**Output**: `qa/07-automation/e2e/{module}/{submodule}.spec.ts` + supporting files  
+**Output**: `qa/07-automation/e2e/tests/{module}/{submodule}.spec.ts` + supporting files  
 **Next stage**: Stage 6 — Maintenance (`qa-maintenance`) or Stage 5b — Stabilization (`qa-test-stabilization`) if tests fail
 
 > **Pipeline rule**: Never automate a TC whose spec contains `PENDING-CODE`. Resolve spec gaps first.
@@ -24,8 +24,8 @@ description: >
 ## Inputs Required
 
 1. `qa/01-specifications/{module}/` — full spec set for target submodule
-2. `qa/07-automation/playwright.config.ts` — confirm project name maps to submodule tag
-3. `qa/07-automation/fixtures/auth.ts` — identify available auth fixtures
+2. `qa/07-automation/e2e/playwright.config.ts` — confirm project name maps to submodule tag
+3. `qa/07-automation/e2e/fixtures/auth.ts` — identify available auth fixtures
 4. TC list (from test plan or Stage 4) — defines which TCs to automate in this session
 5. `qa/qa-framework.config.json` → screenshotPath, automationRoot
 
@@ -38,7 +38,7 @@ description: >
 For every new submodule, run a dedicated inspection script before writing tests.
 **Template**: `references/dom-inspection-template.js` — copy, set the 4 constants at the top, run.
 
-1. Copy `references/dom-inspection-template.js` → `qa/07-automation/_inspect-{submodule}.js`
+1. Copy `references/dom-inspection-template.js` → `qa/07-automation/e2e/_inspect-{submodule}.js`
 2. Set the 4 constants at the top of the script:
    - `MODULE_ROUTE` — the submodule's URL path (e.g. `'/Users'`, `'/Products/list'`)
    - `APP_SHELL_SEL` — a selector that confirms the SPA has loaded (nav, sidebar, app shell)
@@ -150,7 +150,7 @@ See `references/patterns.md` for full TypeScript implementations.
 
 ## Outputs
 
-- `qa/07-automation/e2e/{module}/{submodule}.spec.ts`
+- `qa/07-automation/e2e/tests/{module}/{submodule}.spec.ts`
 - `qa/07-automation/e2e/page-objects/{SubmoduleName}Page.ts`  (when POM criteria met)
-- `qa/07-automation/playwright.config.ts` (updated or confirmed)
+- `qa/07-automation/e2e/playwright.config.ts` (updated or confirmed)
 - `qa/README.md` automation status updated

package/skills/qa-maintenance/SKILL.md

@@ -24,7 +24,7 @@ description: >
 
 1. Description of the change — which submodule, what changed, and why
 2. `qa/01-specifications/{module}/` — specs affected by the change
-3. `qa/07-automation/e2e/{module}/` — automation affected by the change
+3. `qa/07-automation/e2e/tests/{module}/` — automation affected by the change
 4. Optionally: ADO work item or defect report describing the change
 
 ---
@@ -105,6 +105,6 @@ change-summary: {one-line description of what changed}
 
 - Updated `qa/01-specifications/{module}/*.md` files
 - Updated `qa/03-test-cases/automated/TC-*.md` files
-- Updated `qa/07-automation/e2e/{module}/*.spec.ts`
+- Updated `qa/07-automation/e2e/tests/{module}/*.spec.ts`
 - Updated `qa/README.md`
 - Updated `AGENT-NEXT-STEPS.md` (or sprint moved to history if complete)

package/templates/automation-scaffold/playwright.config.ts

@@ -13,21 +13,32 @@ for (const key of required) {
 }
 
 // Optional: Azure DevOps reporter configuration
-// Uncomment and fill in when ADO integration is enabled.
+// To enable: set env vars ADO_ORG, ADO_PROJECT, ADO_PAT, ADO_PLAN_ID and CI=true,
+// then uncomment the reporter entry in the `reporter` array below.
+// Install:  npm install @alex_neo/playwright-azure-reporter --save-dev
 // import { AzureReporter } from '@alex_neo/playwright-azure-reporter';
-// const adoConfig = {
-//   token:           process.env.AZURE_TOKEN!,
-//   planId:          Number(process.env.ADO_PLAN_ID),
-//   projectName:     process.env.ADO_PROJECT_NAME!,
-//   orgUrl:          process.env.ADO_ORG_URL!,
-//   testRunTitle:    `[Automated] Sprint {{NNN}} — ${new Date().toISOString().slice(0, 10)}`,
-//   publishResultsOnFailure: true,
-//   isDisabled:      process.env.ADO_SYNC_DISABLED === 'true',
+// const adoReporterConfig = {
+//   orgUrl:                  `https://dev.azure.com/${process.env.ADO_ORG}`,
+//  // In CI it uses System.AccessToken (pipeline's OAuth, not subject to Conditional Access Policy).
+//  // Locally, if you want to test the reporter, you can set ADO_PAT manually.
+//   token:                   process.env.SYSTEM_ACCESSTOKEN ?? process.env.ADO_PAT,
+//   planId:                  Number(process.env.ADO_PLAN_ID),
+//   projectName:             process.env.ADO_PROJECT!,
+//   testRunTitle:            `[Auto] Sprint {{NNN}} — ${new Date().toISOString().slice(0, 10)}`,
+//   publishTestResultsMode:  'testRun' as const,
+//   uploadAttachments:       true,
+//   attachmentsType:         ['screenshot', 'video', 'trace'] as const,
+//   isDisabled:              !process.env.CI,   // only publishes when CI=true
+//  autoMarkTestCasesAsAutomated: {
+//    enabled:                    true,
+//    updateAutomatedTestName:    true,   // saves test title in AutomatedTestName
+//    updateAutomatedTestStorage: true,   // saves spec file name in AutomatedTestStorage
+//  },
 // };
 
 export default defineConfig({
   // ------ Test discovery ------
-  testDir:  '.',
+  testDir:  './tests',
   // Use any subdir pattern your project standardizes on, e.g.:
   // testMatch: ['**/*.spec.ts'],
 
@@ -44,7 +55,7 @@ export default defineConfig({
     ['html',  { open: 'never' }],
     ['list'],
     // Uncomment for ADO:
-    // ['@alex_neo/playwright-azure-reporter', adoConfig],
+    // ['@alex_neo/playwright-azure-reporter', adoReporterConfig],
   ],
 
   // ------ Global settings ------

package/agent-instructions/00-module-analysis.md

@@ -1,266 +0,0 @@
-# Agent Instructions: Module Analysis
-
-> ⚠️ **DEPRECATED**: This file is superseded by `.github/skills/qa-module-analysis/SKILL.md`.
-> Kept as reference during the transition period. Do not update this file.
-
-**File**: `agent-instructions/00-module-analysis.md`  
-**Purpose**: Instructions for an AI agent to perform complete functional analysis of an application module and produce the 6-file specification set.
-
----
-
-## When to use these instructions
-
-Use this instruction set when:
-- Analyzing a new module for the first time
-- A module has been updated and its spec needs to be refreshed
-- Building the initial `01-specifications/` tree for a project
-
----
-
-## Prerequisites (Agent must verify before starting)
-
-1. Confirm that `qa-framework.config.json` exists and contains `project.qaBaseUrl`
-2. Confirm that `qa/00-standards/naming-conventions.md` is available
-3. Confirm that the Playwright CLI (playwright-mcp or equivalent) is available for browser interaction
-4. Ask the user for:
-   - The module name and URL (or route prefix) to analyze
-   - The submodules to analyze (if known; otherwise discover from the UI)
-   - QA user credentials (handle via env vars — never store in markdown)
-
-**⚠️ SECURITY**: Never write real credentials to any file. If credentials appear in any output, replace immediately with `<PLACEHOLDER>`.
-
----
-
-## Phase 1 — Preparation
-
-### 1.1 Review existing specs
-
-Check if a `qa/01-specifications/module-{name}/` directory already exists.
-
-- If it does: read all existing files to understand what is already documented. Only re-analyze what has changed.
-- If it does not: create the directory structure.
-
-### 1.2 Generate module code
-
-If no module code exists yet, allocate a unique 2–6 uppercase letter code for the module.  
-Check `qa/00-standards/naming-conventions.md` for existing codes to avoid conflicts.
-
-Example: module "Operación" → code `OPER`; submodule "Catálogos" → code `CAT`
-
-### 1.3 Plan the session
-
-Identify all submodules in scope. A submodule typically corresponds to:
-- A distinct menu item or section in the application
-- A distinct CRUD entity (users, products, orders, etc.)
-- A distinct workflow (approval, registration, reporting)
-
-Document the planned submodules in `qa/01-specifications/module-{name}/README.md` before analysis begins.
-
----
-
-## Phase 2 — Exploration
-
-For each submodule, perform the following exploration using browser automation (Playwright CLI):
-
-### 2.1 Navigation and route mapping
-
-```
-Navigate to {{QA_BASE_URL}} and log in with the appropriate role
-Navigate to the submodule URL
-Record:
-  - Full URL of each page/view
-  - Page title
-  - Navigation breadcrumb
-```
-
-### 2.2 UI inventory
-
-For each screen in the submodule:
-
-```
-Record all:
-  - Input fields (name, type, required/optional, validation rules visible in UI)
-  - Dropdowns (static or dynamic/AJAX, options if static)
-  - Buttons (action, what they trigger)
-  - Tables/grids (columns, default sorting, pagination)
-  - Modals (trigger condition, fields, confirmation behavior)
-  - Status indicators / badges / alerts
-  - File upload / download controls
-```
-
-### 2.3 API endpoint discovery
-
-```
-Observe network requests during key interactions (create, read, update, delete)
-Record:
-  - Endpoint path (e.g., /api/GetUsers, api/CreateUser)
-  - HTTP method
-  - Request payload shape (field names)
-  - Response shape (key fields)
-```
-
-### 2.4 Role-based access testing
-
-```
-For each configured test user role:
-  Log in as that role
-  Navigate to the submodule
-  Record: can access? (YES / NO / PERMISSION_ERROR)
-  Record: which actions are available vs hidden
-```
-
-### 2.5 Workflow discovery
-
-```
-Execute the primary happy path with appropriate test data
-Record each step
-Identify branch points (e.g., approve vs reject)
-Record state transitions
-```
-
-### 2.6 Business rule discovery
-
-```
-Attempt invalid inputs for each validation
-Record: validation message text, field that shows the error
-Attempt boundary conditions (empty, max length, duplicate, etc.)
-Record: system behavior
-```
-
----
-
-## Phase 3 — Documentation (6-file output)
-
-Produce the following files for each submodule. Use the templates in `qa/00-standards/` and `templates/specification/`.
-
-### File 00: `00-inventory.md`
-
-Contents:
-- Module header (name, code, URL, deployment date if known)
-- Submodule header (name, code, routes)
-- UI element inventory table
-  - Element name | Type | Required | Notes
-- API endpoint table
-  - Method | Path | Purpose
-- Key identifiers and selectors observed in the UI
-
-### File 01: `01-business-rules.md`
-
-Contents:
-- Each rule as `RN-{MODULE}-{NNN}`: Description
-- Rule type: Validation / Access Control / State Machine / Calculation / Integration
-- Trigger: what user action triggers this rule
-- Error message: exact text shown when rule is violated (if applicable)
-
-Aim for 5–15 business rules per submodule.
-
-### File 02: `02-workflows.md`
-
-Contents:
-- Each major workflow as `FL-{MODULE}-{NNN}`: Title
-- Use ASCII flowchart or Mermaid block diagram
-- Cover: happy path + main alternative paths + error paths
-
-### File 03: `03-roles-permissions.md`
-
-Contents:
-- Role × Feature matrix table
-  - Row: test user role
-  - Column: feature/action (view, create, edit, delete, approve, export, etc.)
-  - Cell: ✅ / ❌ / ⚠️ (limited)
-- Notes on role inheritance or conditional access
-
-### File 04: `04-test-data.md`
-
-Contents:
-- Prerequisites: what data must exist before tests run
-- Data shapes: for each key test scenario, what data is needed
-  - DO NOT include real user credentials
-  - Use env var references for any credential: `process.env.QA_USER_EMAIL`
-- Data dependencies between submodules (if any)
-
-### File 05: `05-test-scenarios.md`
-
-Contents:
-- Summary table at top: total TCs, by priority, by type
-- For each TC:
-  - ID: `TC-{MODULE}-{SUBMODULE}-{NNN}`
-  - Title: brief action description
-  - Priority: P0 / P1 / P2 / P3
-  - Type: Functional / Regression / Security / Negative / Integration
-  - Origin: `UI-OBSERVED` / `PENDING-CODE` / `BLOCKED-PERMISSIONS`
-  - Preconditions
-  - Steps (numbered)
-  - Expected result
-  - Automation feasibility: Yes / Partial / No
-
-Target: **50–85 TCs per submodule** is a well-analyzed submodule.
-
-#### TC coverage must include:
-- ✅ Access control (each role: can access / cannot access)
-- ✅ Happy path (primary workflow end-to-end)
-- ✅ Negative scenarios (required field empty, invalid format, duplicate, etc.)
-- ✅ State transitions (create → edit → delete; pending → approved → rejected)
-- ✅ Cross-module dependencies (if any)
-- ✅ Export/download (if feature exists)
-- ✅ Pagination/search (if feature exists)
-
-TC origin rules:
-- Only write `UI-OBSERVED` if you directly observed the behavior in the QA environment
-- If a feature is documented but not visible in the QA environment: `PENDING-CODE`
-- If you couldn't test it due to permission restrictions: `BLOCKED-PERMISSIONS`
-
----
-
-## Phase 4 — Review and Session Summary
-
-### 4.1 Completeness checklist
-
-After completing all submodule files, verify:
-
-- [ ] All menu items in the module have a corresponding submodule folder
-- [ ] All TCs marked `UI-OBSERVED` were actually observed in this session
-- [ ] `01-business-rules.md` covers all visible validation behaviors
-- [ ] `03-roles-permissions.md` reflects the access observed for each role
-- [ ] No credentials appear in any file
-- [ ] All TC IDs are unique across the module
-- [ ] Module README lists all submodules with their codes and TC counts
-
-### 4.2 Write session summary
-
-Create `qa/SESSION-SUMMARY-{YYYY-MM-DD}.md` with:
-
-```markdown
-# Session Summary — {YYYY-MM-DD}
-
-## Module analyzed
-{module-name} ({module-code})
-
-## Submodules documented
-| Submodule | Code | TC count | Notes |
-|-----------|------|----------|-------|
-| {name}    | {code} | {N}    | {any notable blocking issues} |
-
-## Files created
-- {list of all files created with their paths}
-
-## Blockers
-- {any features that couldn't be analyzed and why}
-
-## Observations for next session
-- {what to tackle next}
-```
-
----
-
-## Quality Standards
-
-A well-executed module analysis session:
-
-1. Takes between 2-6 hours depending on module complexity
-2. Produces 6 files per submodule (not more, not less)
-3. Has no hardcoded credentials in any file
-4. Has TC IDs that follow the `TC-{MODULE}-{SUBMODULE}-{NNN}` pattern
-5. Has business rules that are verifiable in automated tests
-6. Has at least 1 P0 TC per submodule (the primary happy path)
-7. Does not invent TCs for behavior that wasn't observed in the QA environment

package/agent-instructions/01-spec-generation.md

@@ -1,281 +0,0 @@
-# Agent Instructions: Specification Generation
-
-> ⚠️ **DEPRECATED**: This file is superseded by `.github/skills/qa-spec-generation/SKILL.md`.
-> Kept as reference during the transition period. Do not update this file.
-
-**File**: `agent-instructions/01-spec-generation.md`  
-**Purpose**: Detailed instructions for generating the 6-file submodule specification set from a completed module analysis or from existing source material (UI observation, requirements docs, developer input).
-
----
-
-## When to use
-
-- After Phase 2 (Exploration) of module analysis is complete
-- When updating specs after a code change
-- When a spec file is missing or incomplete
-
----
-
-## Inputs Required
-
-Before generating specs, gather:
-
-1. **Module exploration notes** — from the analysis session
-2. **Module code** — from `qa/00-standards/naming-conventions.md` or allocate a new one
-3. **Submodule name** and its kebab-case directory name
-4. **QA environment observations** — what you actually saw in the UI
-
----
-
-## File-by-File Generation Rules
-
-### `00-inventory.md` — UI and API Inventory
-
-**Header block** (always required):
-
-```markdown
-# MODULE: {Module Display Name} — Submodule: {Submodule Display Name}
-
-| Field | Value |
-|-------|-------|
-| Module code | {MODULE_CODE} |
-| Submodule code | {SUBMODULE_CODE} |
-| Primary URL | {{QA_BASE_URL}}/path/to/submodule |
-| Status | Active / Deprecated / In Development |
-| Last updated | YYYY-MM-DD |
-```
-
-**UI element table**:
-
-```markdown
-## UI Elements
-
-| Element | Type | Required | Notes |
-|---------|------|----------|-------|
-| {field-name} | text / select / checkbox / date | Yes/No | {validation rule} |
-```
-
-**API endpoints table**:
-
-```markdown
-## API Endpoints
-
-| Method | Path | Purpose |
-|--------|------|---------|
-| GET | /api/{endpoint} | {description} |
-| POST | /api/{endpoint} | {description} |
-```
-
-**Do NOT include**: credentials, personal data, real user IDs.
-
----
-
-### `01-business-rules.md` — Business Rules
-
-**Format for each rule**:
-
-```markdown
-### RN-{MODULE}-{NNN}: {Rule Title}
-
-- **Type**: Validation / Access Control / State Machine / Calculation / Integration
-- **Trigger**: {What user action triggers this rule}
-- **Behavior**: {What the system does when the rule is evaluated}
-- **Error message** (if validation): "{exact text as shown in UI}"
-- **Notes**: {any special circumstances}
-```
-
-**Rule identification tips**:
-- Every required field → at least 1 RN (field is required)
-- Every unique constraint → 1 RN (duplicate not allowed)
-- Every state transition → 1 RN (can only approve if status=pending)
-- Every role restriction → 1 RN (only role X can see this)
-- Every auto-calculated field → 1 RN (total = quantity × price)
-
-**Minimum**: 5 rules per submodule. **Typical**: 8–15.
-
----
-
-### `02-workflows.md` — User Workflows
-
-**Format for each workflow**:
-
-```markdown
-### FL-{MODULE}-{NNN}: {Workflow Title}
-
-**Actor**: {Role who performs this workflow}
-**Trigger**: {What initiates the workflow}
-**Precondition**: {What must be true before this starts}
-
-**Flow**:
-```
-[Start]
-    │
-    ▼
-[Step 1: action]
-    │
-    ├─ [Alternative: condition] ──► [Alternative path]
-    │
-    ▼
-[Step 2: action]
-    │
-    ▼
-[End: outcome]
-```
-
-**Postcondition**: {State of the system after the workflow completes}
-```
-
-Cover at minimum:
-- Primary happy path (end-to-end main scenario)
-- Rejection / cancellation path (if applicable)
-- Error path (validation failure, system error)
-
----
-
-### `03-roles-permissions.md` — Role Matrix
-
-**Format**:
-
-```markdown
-# Roles and Permissions — {Submodule}
-
-## Access Matrix
-
-| Feature / Action | {Role 1} | {Role 2} | {Role 3} |
-|-----------------|---------|---------|---------|
-| View list | ✅ | ✅ | ❌ |
-| Create new | ✅ | ❌ | ❌ |
-| Edit | ✅ | ❌ | ❌ |
-| Delete | ✅ | ❌ | ❌ |
-| Approve | ❌ | ✅ | ❌ |
-| Export | ✅ | ✅ | ❌ |
-
-## Test User Reference
-
-| Role | Env var (email) | Env var (password) |
-|------|----------------|-------------------|
-| {Role 1} | `QA_USER_{ROLE}_EMAIL` | `QA_USER_{ROLE}_PASSWORD` |
-
-**Notes**: {any conditional access rules, e.g., "Admin can only edit own records"}
-```
-
-**Do NOT include**: actual email addresses, passwords, or personal identifiers.
-
----
-
-### `04-test-data.md` — Test Data Requirements
-
-**Format**:
-
-```markdown
-# Test Data — {Submodule}
-
-## Prerequisites
-
-The following data must exist in the QA environment before tests run:
-
-| Item | Description | Source |
-|------|-------------|--------|
-| {entity} | {description} | QA seed / pre-existing |
-
-## Data shapes for key scenarios
-
-### Scenario: {happy path}
-- Field A: {value type, e.g., "any valid text, max 100 chars"}
-- Field B: {value type}
-- User: role `{ROLE_NAME}`, credentials from `QA_USER_{ROLE}_EMAIL` env var
-
-### Scenario: {negative — duplicate}
-- Precondition: {entity} with the same key already exists
-- Field A: {same value as existing record}
-- Expected: {system rejection behavior}
-
-## Dynamic data generation
-
-For tests that create new records, use the EXEC_IDX pattern to avoid collisions:
-
-```typescript
-const EXEC_IDX = Math.floor(Date.now() / 60_000) % 100_000;
-const uniqueTitle = `Test-${EXEC_IDX}`;
-```
-
-## Data isolation rules
-
-1. Each test must operate on its own data (no shared mutable state between tests)
-2. Tests that require pre-existing data must provision it in `beforeAll`
-3. Provisioned data does not need to be cleaned up if EXEC_IDX-based names are used
-```
-
----
-
-### `05-test-scenarios.md` — Test Cases
-
-**Header block** (always required):
-
-```markdown
-# Test Scenarios — {Module}: {Submodule}
-
-**Module code**: {MODULE_CODE}  
-**Submodule code**: {SUBMODULE_CODE}  
-**Last updated**: YYYY-MM-DD
-
-## Summary
-
-| Priority | Count | Automated | Manual |
-|----------|-------|-----------|--------|
-| P0 | {N} | {N} | {N} |
-| P1 | {N} | {N} | {N} |
-| P2 | {N} | {N} | {N} |
-| P3 | {N} | {N} | {N} |
-| **Total** | **{N}** | **{N}** | **{N}** |
-```
-
-**Format for each test case**:
-
-```markdown
-### TC-{MODULE}-{SUBMODULE}-{NNN}: {TC Title}
-
-| Field | Value |
-|-------|-------|
-| Priority | P0 / P1 / P2 / P3 |
-| Type | Functional / Negative / Regression / Security / Integration |
-| Origin | UI-OBSERVED / PENDING-CODE / BLOCKED-PERMISSIONS |
-| Automation | Yes / Partial / No |
-| Playwright | (leave blank until automation is written; then: `tests/{module}/file.spec.ts`) |
-
-**Preconditions**:
-- {precondition 1}
-
-**Steps**:
-1. {step 1}
-2. {step 2}
-3. {step 3}
-
-**Expected result**: {what should happen}
-
-**Notes**: {any special considerations, DEF references, skip conditions}
-```
-
-**Mandatory coverage categories** (must have at least 1 TC per category where applicable):
-
-- [ ] Access: unauthenticated user redirected to login
-- [ ] Access: role without permission receives error / empty page
-- [ ] Happy path: primary workflow with valid data succeeds
-- [ ] Negative: required field missing → validation error shown
-- [ ] Negative: duplicate record → system rejects with error message
-- [ ] Negative: invalid format → system rejects with format error
-- [ ] State transition: state changes correctly on action
-- [ ] Export / download: if feature exists, file is generated
-- [ ] Pagination / search: if feature exists, filtering works correctly
-
----
-
-## Common Anti-Patterns to Avoid
-
-| Anti-pattern | Why it's wrong | Correct approach |
-|---|---|---|
-| TC for a feature not in QA env | Creates invalid test expectations | Mark as `PENDING-CODE`, don't write test steps |
-| TC with a real user's DNI in steps | Security issue | Use env var reference |
-| TC with "click the X button" without knowing the element exists | Assumes UI without observation | Verify element exists first |
-| 100+ TCs per submodule by copy-pasting variations | Bloats the spec without value | Merge near-identical cases, use parameterization |
-| TC with "verify system works correctly" as expected result | Untestable | Write observable, measurable expected result |