docs: import qa workflow knowledge from grilling session
This commit is contained in:
163
docs/current-workflows.md
Normal file
163
docs/current-workflows.md
Normal file
@@ -0,0 +1,163 @@
|
||||
---
|
||||
last_updated: 2025-07-15
|
||||
tags: [workflow, qa-process, jira, yara724]
|
||||
source: import-knowledge
|
||||
---
|
||||
|
||||
# Current QA Workflows — Yara724
|
||||
|
||||
## Daily Workflow
|
||||
|
||||
```
|
||||
CEO Request
|
||||
↓
|
||||
Requirement Analysis
|
||||
↓
|
||||
Convert Requirement into Jira Task
|
||||
↓
|
||||
Write Documentation
|
||||
↓
|
||||
Create Mockups / Annotated Screenshots
|
||||
↓
|
||||
Describe Backend Changes
|
||||
↓
|
||||
Developers Implement
|
||||
↓
|
||||
QA Testing
|
||||
↓
|
||||
Bug Investigation
|
||||
↓
|
||||
Frontend / Backend Root Cause Analysis
|
||||
↓
|
||||
Retest
|
||||
```
|
||||
|
||||
## Requirement Intake
|
||||
|
||||
Requirements do not follow a standardized process. Typical characteristics:
|
||||
|
||||
- Received from different stakeholders.
|
||||
- Usually communicated verbally or as short informal messages.
|
||||
- Often consist of only one sentence or a rough idea.
|
||||
- Frequently marked as urgent.
|
||||
- Sometimes conflict with existing business workflows.
|
||||
- Require additional clarification before implementation.
|
||||
|
||||
## Requirement Analysis — Clear Requirements
|
||||
|
||||
```
|
||||
Receive Request
|
||||
↓
|
||||
Open Jira
|
||||
↓
|
||||
Navigate the current flow
|
||||
↓
|
||||
Capture screenshots
|
||||
↓
|
||||
Document the requirement
|
||||
↓
|
||||
Use ChatGPT with a predefined Jira template
|
||||
↓
|
||||
Review
|
||||
↓
|
||||
Publish Jira Task
|
||||
```
|
||||
|
||||
## Requirement Analysis — Ambiguous / Larger Requirements
|
||||
|
||||
```
|
||||
Receive Request
|
||||
↓
|
||||
Analyze current workflow
|
||||
↓
|
||||
Discuss with Frontend / Backend
|
||||
↓
|
||||
Reach verbal agreement
|
||||
↓
|
||||
Create Jira Task
|
||||
```
|
||||
|
||||
## Jira Ticket Creation Process
|
||||
|
||||
A significant portion of working time is spent creating high-quality Jira tasks:
|
||||
|
||||
- Writing a meaningful title
|
||||
- Writing a detailed description
|
||||
- Explaining the business requirement
|
||||
- Specifying affected URLs and pages
|
||||
- Attaching and annotating screenshots (using Paint)
|
||||
- Highlighting UI elements
|
||||
- Explaining expected behavior
|
||||
- Writing backend expectations
|
||||
- Specifying API modifications
|
||||
- Explaining request body / response model changes
|
||||
- Describing validation rules
|
||||
|
||||
Sometimes also specifying:
|
||||
- Which API should be used
|
||||
- Which fields are missing
|
||||
- Which response properties should be added
|
||||
- Which endpoint should be modified
|
||||
- How the frontend expects the backend response
|
||||
|
||||
## Bug Investigation Workflow
|
||||
|
||||
```
|
||||
UI
|
||||
↓
|
||||
Browser DevTools
|
||||
↓
|
||||
Network Request
|
||||
↓
|
||||
Swagger
|
||||
↓
|
||||
Backend Response
|
||||
↓
|
||||
Compare with Frontend Expectations
|
||||
↓
|
||||
Determine Root Cause
|
||||
```
|
||||
|
||||
Possible outcomes:
|
||||
- Frontend bug
|
||||
- Backend bug
|
||||
- Wrong API called
|
||||
- Missing request parameter
|
||||
- Incorrect request body
|
||||
- Missing response field
|
||||
- Validation issue
|
||||
- Business logic issue
|
||||
|
||||
For some bugs, QA reads frontend/backend code to explain why a condition or logic is wrong.
|
||||
|
||||
## AI-Assisted Workflow (Current)
|
||||
|
||||
```
|
||||
Raw Requirement
|
||||
↓
|
||||
ChatGPT
|
||||
↓
|
||||
Structured Jira Ticket
|
||||
↓
|
||||
Manual Review
|
||||
↓
|
||||
Publish to Jira
|
||||
```
|
||||
|
||||
ChatGPT is used to convert raw requirements into structured Jira tickets. Improvement on ticket quality noted. Also used for wording and organizing documentation.
|
||||
|
||||
## Investigation Workflow (with MongoDB)
|
||||
|
||||
```
|
||||
UI
|
||||
↓
|
||||
Browser DevTools
|
||||
↓
|
||||
Network Requests
|
||||
↓
|
||||
Swagger
|
||||
↓
|
||||
MongoDB
|
||||
↓
|
||||
Root Cause Analysis
|
||||
```
|
||||
41
docs/glossary.md
Normal file
41
docs/glossary.md
Normal file
@@ -0,0 +1,41 @@
|
||||
---
|
||||
last_updated: 2025-07-15
|
||||
tags: [domain-language, insurance, yara724]
|
||||
source: import-knowledge
|
||||
---
|
||||
|
||||
# Domain Glossary — Yara724 Insurance Platform
|
||||
|
||||
## Core Entities
|
||||
|
||||
**Case**
|
||||
The top-level container for an insurance event. A Case is made up of two subsets: Blame and Claim.
|
||||
_Avoid_: Incident, Event
|
||||
|
||||
**Blame**
|
||||
The fault/culpability determination within a Case — determining who is at fault in an accident.
|
||||
_Avoid_: Liability, Fault, Culpability
|
||||
|
||||
**Claim**
|
||||
The financial compensation request within a Case — the policyholder requesting payment for damages. A Claim can only be filed after the Blame determination is complete.
|
||||
_Avoid_: Request, Payment, Demand
|
||||
|
||||
**Policy**
|
||||
An insurance contract between the insurer and the insured, covering specific vehicles and risks.
|
||||
|
||||
## People & Roles
|
||||
|
||||
**Expert**
|
||||
A professional (surveyor/assessor) who reviews Cases — evaluates damage, determines blame, and approves claims. Uses the Expert UI.
|
||||
|
||||
**Insured / Customer**
|
||||
The person or entity holding the policy who files a Claim. Uses the User UI.
|
||||
|
||||
**Insurer**
|
||||
The insurance company that underwrites the Policy and pays out Claims.
|
||||
|
||||
**Super Admin**
|
||||
A role with full system access — can toggle features (queries) on and off, and configure system-wide settings.
|
||||
|
||||
**Roles**
|
||||
Multiple roles with varying access levels. All roles ultimately review the Case file in some capacity — the difference is what actions they can take and what data they see.
|
||||
87
docs/improvement-goals.md
Normal file
87
docs/improvement-goals.md
Normal file
@@ -0,0 +1,87 @@
|
||||
---
|
||||
last_updated: 2025-07-15
|
||||
tags: [improvement, goals, priorities, yara724]
|
||||
source: import-knowledge
|
||||
---
|
||||
|
||||
# Improvement Goals — Yara724 QA Workflow
|
||||
|
||||
## Primary Goal
|
||||
|
||||
Automate repetitive work — addresses the two biggest time sinks (bug diagnosis at 40% and API investigation at 25%).
|
||||
|
||||
## Secondary Goal
|
||||
|
||||
Free time for other projects, improve technical understanding.
|
||||
|
||||
## Long-Term Objective
|
||||
|
||||
Build an AI-assisted QA workflow that combines product knowledge, API analysis, documentation, testing, and bug investigation into a streamlined process. The goal is to reduce manual effort, improve consistency, and allow focus more on high-value engineering work rather than repetitive documentation.
|
||||
|
||||
---
|
||||
|
||||
## Priority 1: State Preparation Automation (FIRST)
|
||||
|
||||
A tool that chains API calls to bring a Case to any target state, supporting:
|
||||
|
||||
- Fresh Case creation each time (default)
|
||||
- Reuse of existing Cases from MongoDB (optional)
|
||||
- All target states: ready for Expert review, ready for Claim submission, ready for Insurer review, etc.
|
||||
- Target states cover the full Blame → Claim lifecycle
|
||||
- Interface TBD — options: Bruno collection, standalone script, CLI tool
|
||||
|
||||
- [ ] Define success metrics for Priority 1
|
||||
|
||||
## Priority 2: Bug Diagnosis Assistance (SECOND)
|
||||
|
||||
AI that takes a network request/response (from DevTools) and suggests likely root cause, reducing the 40% bug investigation bucket.
|
||||
|
||||
**Current bug reporting format**: QA pastes a URL + screenshot into Jira. Does not paste full request/response body or expected vs actual comparison — this is the gap AI can fill.
|
||||
|
||||
- [ ] Define success metrics for Priority 2
|
||||
|
||||
---
|
||||
|
||||
## Improvement Opportunities (from workflow assessment)
|
||||
|
||||
1. Standardized Bruno/Postman collections organized by business flows
|
||||
2. Better use of environments and variables to reduce repetitive authentication work
|
||||
3. Documentation of business flow → API mappings
|
||||
4. Reusable test data and state preparation procedures
|
||||
5. AI-assisted API discovery and workflow navigation
|
||||
6. AI-assisted root cause analysis support
|
||||
7. A centralized QA knowledge base to preserve project knowledge across time and projects
|
||||
|
||||
---
|
||||
|
||||
## Open Questions (from original working doc)
|
||||
|
||||
### Process Understanding
|
||||
- What percentage of time is spent on each activity?
|
||||
- Which activities are repetitive?
|
||||
- Which activities require human judgment?
|
||||
- Which activities can be automated?
|
||||
- Which activities can be standardized using templates?
|
||||
|
||||
### Documentation
|
||||
- Can screenshots be automatically annotated?
|
||||
- Can UI differences be detected automatically?
|
||||
- Can Jira tickets be generated directly from screenshots?
|
||||
- Can API changes be inferred automatically from Swagger?
|
||||
|
||||
### Backend Analysis
|
||||
- Can request/response differences be detected automatically?
|
||||
- Can API regressions be detected before manual testing?
|
||||
- Can Swagger documentation be compared automatically between versions?
|
||||
|
||||
### Testing
|
||||
- Which regression tests should be automated?
|
||||
- Which tests should remain manual?
|
||||
- Can Bruno/Postman collections generate parts of Jira tickets automatically?
|
||||
|
||||
### AI Integration
|
||||
- Can AI generate the first draft of every Jira task?
|
||||
- Can AI determine whether a bug belongs to the frontend or backend?
|
||||
- Can AI summarize long Jira tickets?
|
||||
- Can AI analyze DevTools network traffic?
|
||||
- Can AI explain unfamiliar code sections?
|
||||
137
docs/pain-points.md
Normal file
137
docs/pain-points.md
Normal file
@@ -0,0 +1,137 @@
|
||||
---
|
||||
last_updated: 2025-07-15
|
||||
tags: [pain-points, bottlenecks, qa-process, yara724]
|
||||
source: import-knowledge
|
||||
---
|
||||
|
||||
# Pain Points — Yara724 QA Workflow
|
||||
|
||||
## Time Breakdown (estimated)
|
||||
|
||||
| Activity | % of Day |
|
||||
|---|---|
|
||||
| Bug investigation (diagnosis) | 40% |
|
||||
| API investigation / test setup | 25% |
|
||||
| Creating Jira tickets | 15% |
|
||||
| Context switching (tool switching) | 10% |
|
||||
| Taking requirements | 5% |
|
||||
| Other | 5% |
|
||||
|
||||
- [ ] Validate time percentages with actual measurement
|
||||
|
||||
## 1. API Investigation (25%)
|
||||
|
||||
The biggest time consumer. Reasons:
|
||||
|
||||
- 10–20 API calls to prepare a test case from scratch
|
||||
- Cases cannot be reused due to backend constraints — must create fresh each time
|
||||
- Large number of APIs; difficulty remembering rarely used APIs
|
||||
- Finding the correct endpoint
|
||||
- Understanding API sequences within a business flow
|
||||
- Preparing request bodies
|
||||
- Switching between multiple tools
|
||||
|
||||
## 2. Authentication Overhead
|
||||
|
||||
Many test sessions require repeating the authentication process. Typical sequence:
|
||||
|
||||
```
|
||||
Open Swagger
|
||||
↓
|
||||
Captcha API
|
||||
↓
|
||||
Login API
|
||||
↓
|
||||
Receive Token
|
||||
↓
|
||||
Authorize
|
||||
↓
|
||||
Start Testing
|
||||
```
|
||||
|
||||
Repeated ~10 times/day, ~2 minutes each = ~20 min/day pure waste.
|
||||
|
||||
## 3. Bug Diagnosis (40%)
|
||||
|
||||
Most time-consuming activity. Root cause analysis done via:
|
||||
|
||||
- Visual inspection (comparing UI behavior with expected behavior)
|
||||
- Swagger doc comparison (sometimes)
|
||||
- Reading frontend/backend code (for some bugs)
|
||||
|
||||
## 4. Context Switching (10%)
|
||||
|
||||
Knowledge is fragmented across multiple systems:
|
||||
|
||||
- Jira
|
||||
- Swagger
|
||||
- DevTools
|
||||
- MongoDB
|
||||
- Bruno
|
||||
- Backend code
|
||||
- Frontend code
|
||||
- Product knowledge
|
||||
|
||||
A single investigation often requires moving repeatedly between these tools.
|
||||
|
||||
## 5. Documentation Overhead (15%)
|
||||
|
||||
Jira ticket creation takes ~15 min each. Bottleneck is analysis/thinking, not formatting.
|
||||
|
||||
## 6. Weak Jira ↔ Code Traceability
|
||||
|
||||
- Commit messages rarely reference Jira ticket IDs
|
||||
- Folders are disorganized
|
||||
|
||||
## 7. Stateful Business Flows
|
||||
|
||||
The application is heavily state-driven. Many APIs cannot be tested independently because business entities must first reach a specific state:
|
||||
|
||||
```
|
||||
Create Case
|
||||
↓
|
||||
Upload Documents
|
||||
↓
|
||||
Expert Review
|
||||
↓
|
||||
Approval
|
||||
↓
|
||||
Payment
|
||||
```
|
||||
|
||||
This creates dependencies between APIs and significantly increases investigation time.
|
||||
|
||||
## 8. Test Data Preparation
|
||||
|
||||
MongoDB is frequently used to:
|
||||
|
||||
- Inspect business entities
|
||||
- Verify system state
|
||||
- Modify test data when necessary
|
||||
|
||||
## 9. Technical Learning Curve
|
||||
|
||||
Background is Mechanical Engineering, not CS. Often uses development tools without fully understanding their best practices:
|
||||
|
||||
- Swagger, MongoDB, Postman, Bruno, Browser DevTools, JMeter
|
||||
|
||||
Knows how to accomplish tasks, but not always the most efficient or standard way.
|
||||
|
||||
## 10. Requirement Quality
|
||||
|
||||
Some Jira tickets are created by the CTO using AI. Since the CTO is relatively new to the product, some generated titles and descriptions lack sufficient product context:
|
||||
|
||||
- Requirements can become ambiguous
|
||||
- Reading and understanding them takes extra effort
|
||||
- Additional clarification is often required before implementation
|
||||
|
||||
## Primary Bottlenecks (Summary)
|
||||
|
||||
The main bottlenecks are NOT writing Jira tickets. Instead:
|
||||
|
||||
1. Reconstructing business context
|
||||
2. Finding the correct APIs
|
||||
3. Navigating complex API chains
|
||||
4. Preparing valid test data
|
||||
5. Repeating authentication and setup tasks
|
||||
6. Frequent context switching across tools
|
||||
50
docs/qa-profile.md
Normal file
50
docs/qa-profile.md
Normal file
@@ -0,0 +1,50 @@
|
||||
---
|
||||
last_updated: 2025-07-15
|
||||
tags: [qa-engineer, profile, role, yara724]
|
||||
source: import-knowledge
|
||||
---
|
||||
|
||||
# QA Engineer Profile — Yara724
|
||||
|
||||
## Background
|
||||
|
||||
- **Education**: Mechanical Engineering (Solid Mechanics) — CS/SE fundamentals are limited compared to software engineers.
|
||||
- **Experience**: ~1 year as QA Engineer.
|
||||
- **Code-reading level**: Beginner — reads Backend, User Frontend, Expert Frontend repos when necessary.
|
||||
|
||||
## Official Title vs Actual Role
|
||||
|
||||
Although the official title is QA Engineer, the role combines responsibilities from multiple disciplines:
|
||||
|
||||
- QA Engineer
|
||||
- Requirement Analyst
|
||||
- Product Analyst
|
||||
- Technical Writer
|
||||
- Bug Investigator
|
||||
- API Tester
|
||||
- Database Inspector
|
||||
|
||||
## Responsibilities
|
||||
|
||||
- Functional Testing
|
||||
- Regression Testing
|
||||
- Exploratory Testing
|
||||
- Creating Jira Stories and Tasks
|
||||
- Bug Reporting
|
||||
- Product Analysis
|
||||
- Requirement Analysis
|
||||
- Documentation
|
||||
- UI/UX Improvement Suggestions
|
||||
- Backend API Validation
|
||||
- Communication with Frontend and Backend Developers
|
||||
- Supporting Product Design Decisions
|
||||
|
||||
## Projects
|
||||
|
||||
- **Yara** (main project) — insurance claim management platform
|
||||
- **TamasLink** (Call Center)
|
||||
- Other projects (Balan, Beno, Karjo, etc.) on a periodic basis
|
||||
|
||||
## Reporting
|
||||
|
||||
Work requests come directly from both the CEO and CTO.
|
||||
49
docs/state-machines.md
Normal file
49
docs/state-machines.md
Normal file
@@ -0,0 +1,49 @@
|
||||
---
|
||||
last_updated: 2025-07-15
|
||||
tags: [state-machines, domain-model, yara724]
|
||||
source: import-knowledge
|
||||
---
|
||||
|
||||
# State Machines — Yara724 Case Lifecycle
|
||||
|
||||
A Case has three independent state machines that run sequentially (Blame first, then Claim).
|
||||
|
||||
## Case Status
|
||||
|
||||
The top-level lifecycle of the entire Case.
|
||||
_Avoid_: Case State, Case Phase
|
||||
|
||||
| Status | Description |
|
||||
|---|---|
|
||||
| OPEN | Initial state. Persists from creation through inviting the second party. |
|
||||
| WAITING_FOR_SECOND_PARTY | Second party has been invited, awaiting their response. |
|
||||
| WAITING_FOR_EXPERT | Blame resulted in disagreement; case escalated to Expert. |
|
||||
| WAITING_FOR_DOCUMENT_RESEND | Expert or system requests additional documents from user. |
|
||||
| WAITING_FOR_SIGNATURES | Awaiting signatures from relevant parties. |
|
||||
| COMPLETED | Case fully resolved (Blame decided + Claim processed if applicable). |
|
||||
| CANCELLED | Case voluntarily cancelled by a party. |
|
||||
| AUTO_CLOSED | Case closed automatically (e.g., timeout, policy expired). |
|
||||
|
||||
## Blame Status
|
||||
|
||||
Determines whether the case proceeds between the parties or requires Expert intervention.
|
||||
_Avoid_: Blame State, Fault Status
|
||||
|
||||
| Status | Description |
|
||||
|---|---|
|
||||
| UNKNOWN | Initial state. Awaiting first party's fault attribution. |
|
||||
| AGREED | Parties agree on fault attribution. Case proceeds directly to Claim without Expert. |
|
||||
| DISAGREEMENT | Parties disagree on fault. Case escalates to Expert for determination. |
|
||||
|
||||
## Claim Status
|
||||
|
||||
The financial compensation track — only active after Blame is resolved and a Claim is filed.
|
||||
_Avoid_: Claim State
|
||||
|
||||
| Status | Description |
|
||||
|---|---|
|
||||
| PENDING | Claim filed, awaiting initial review. |
|
||||
| UNDER_REVIEW | Expert or Insurer actively reviewing the Claim. |
|
||||
| APPROVED | Claim approved for payout. |
|
||||
| REJECTED | Claim denied. |
|
||||
| NEEDS_REVISION | Claim returned to user for corrections or additional information. |
|
||||
46
docs/workflow-steps.md
Normal file
46
docs/workflow-steps.md
Normal file
@@ -0,0 +1,46 @@
|
||||
---
|
||||
last_updated: 2025-07-15
|
||||
tags: [workflow, steps, blame, claim, yara724]
|
||||
source: import-knowledge
|
||||
---
|
||||
|
||||
# Workflow Steps — Yara724 Case Lifecycle
|
||||
|
||||
Granular progression within each phase. Steps are ordered — a Case moves through them sequentially.
|
||||
|
||||
## Relationships
|
||||
|
||||
- **Case** is the top-level entity — contains one Blame and one Claim.
|
||||
- **Blame** determines whether the Case proceeds to **Claim** (via Expert) or resolves directly (parties agree).
|
||||
- **Claim** is only active when Blame results in DISAGREEMENT and Expert is involved.
|
||||
- A Case can end at any point via CANCELLED or AUTO_CLOSED.
|
||||
|
||||
## Blame Steps
|
||||
|
||||
1. CREATED
|
||||
2. FIRST_BLAME_CONFESSION
|
||||
3. FIRST_VIDEO
|
||||
4. FIRST_INITIAL_FORM
|
||||
5. FIRST_LOCATION
|
||||
6. FIRST_VOICE
|
||||
7. FIRST_DESCRIPTION
|
||||
8. FIRST_INVITE_SECOND
|
||||
9. SECOND_INITIAL_FORM
|
||||
10. SECOND_LOCATION
|
||||
11. SECOND_VOICE
|
||||
12. SECOND_DESCRIPTION
|
||||
|
||||
## Claim Workflow Steps
|
||||
|
||||
1. CLAIM_CREATED
|
||||
2. SELECT_OUTER_PARTS
|
||||
3. SELECT_OTHER_PARTS
|
||||
4. CAPTURE_PART_DAMAGES
|
||||
5. UPLOAD_REQUIRED_DOCUMENTS
|
||||
6. USER_SUBMISSION_COMPLETE
|
||||
7. USER_EXPERT_RESEND (user fulfills Expert's request for more documents/photos)
|
||||
8. EXPERT_DAMAGE_ASSESSMENT
|
||||
9. EXPERT_FINAL_REPLY (after user objection — Expert's last priced reply)
|
||||
10. EXPERT_COST_EVALUATION
|
||||
11. INSURER_REVIEW
|
||||
12. CLAIM_COMPLETED
|
||||
Reference in New Issue
Block a user