AI Skill Report Card
Testing PlannerVersi E2E
PlannerVersi E2E QA Testing
Quick Start13 / 15
Bash# Test a page with default settings Test the "Associativo" page # Test with specific scope Test the "Curva de Vendas" page frontend only # Test with custom credentials Test "Taxa de Administração" with user admin@vp6.com.br and password admin123
Recommendation▾
Add concrete input/output examples showing actual test results, error messages, and status codes rather than describing what will be tested
Workflow14 / 15
Input Parsing (Required)
- Extract page name (required)
- Parse scope: FRONTEND/BACKEND/AMBOS (default: AMBOS)
- Parse credentials (default: teste@vp6.com.br/teste2026)
- Parse organization if multi-tenant
- Parse specific functionalities to test
- Capture additional observations
Execution Order (Always Follow)
- Authentication
- Route mapping in config/routes.ts
- Component mapping and endpoint extraction
- Navigation to page (if FRONTEND/AMBOS)
- Enterprise/version/module selection
- Initial load validation (Network + Redux + DOM)
- Functional testing (CRUD operations)
- Fresh refetch persistence validation
- Version/module switching regression
- Final report generation
- Bug correction instructions (if issues found)
Recommendation▾
Include specific templates for test reports and bug classification with actual examples of HIGH/MEDIUM/LOW issues found
Examples12 / 20
Example 1: Input: "Test the Associativo page frontend only" Output: Complete frontend validation including UI interaction, Redux state verification, and network request monitoring
Example 2: Input: "Validate Taxa de Administração backend with user admin@test.com" Output: Direct API testing of all CRUD endpoints with authentication and data persistence verification
Example 3: Input: "Test Curva de Vendas page, test: add, edit, save" Output: Full E2E testing focusing specifically on creation, editing, and saving workflows
Recommendation▾
Provide default test data examples and specific API endpoint patterns for common PlannerVersi pages to reduce setup time
Best Practices
Critical Validation Rules:
- Never consider a test passed without fresh refetch confirmation
- Always cross-validate: Network + Redux + DOM states
- Test persistence by forcing data reload (version switch, navigation, refresh)
- Use React input helpers for masked fields (currency, percentage)
- Prefer creating/deleting test data over modifying production data
Performance Guidelines:
- Minimize screenshots (max 8 per test)
- Avoid fixed waits - use DOM polling for loading states
- Use compact table/form reading helpers
- Capture evidence only when necessary for bug reporting
Bug Classification:
- HIGH: Data loss, save failures, broken CRUD, authentication blocks
- MEDIUM: Stale Redux, visual inconsistencies, incomplete form population
- LOW: Layout issues, minor UX problems that don't block workflows
Common Pitfalls
Never do these:
- Trust only UI success messages without backend verification
- Skip refetch validation after save operations
- Use
@ts-ignoreoras anyin bug fixes - Suggest try/catch blocks to hide errors
- Test with excessive waits instead of proper DOM polling
- Report bugs without concrete evidence (status codes, console errors, state snapshots)
Always verify:
- Redux state updates match network responses
- Saved data persists after fresh page load/refetch
- Version/module switching clears stale data properly
- Form fields populate correctly when editing existing records