docs: import qa workflow knowledge from grilling session
This commit is contained in:
23
README.md
23
README.md
@@ -1,2 +1,25 @@
|
|||||||
# qa_improve
|
# qa_improve
|
||||||
|
|
||||||
|
QA workflow improvement project for the Yara724 insurance claim management platform.
|
||||||
|
|
||||||
|
## Knowledge Documents
|
||||||
|
|
||||||
|
- [Domain Glossary](docs/glossary.md) — Case, Blame, Claim, Policy, roles
|
||||||
|
- [State Machines](docs/state-machines.md) — Case, Blame, and Claim status lifecycle
|
||||||
|
- [Workflow Steps](docs/workflow-steps.md) — Sequential Blame and Claim steps
|
||||||
|
- [QA Profile](docs/qa-profile.md) — Engineer background, role, responsibilities
|
||||||
|
- [Current Workflows](docs/current-workflows.md) — Daily workflow, Jira creation, bug investigation
|
||||||
|
- [Pain Points](docs/pain-points.md) — Bottlenecks, time breakdown, challenges
|
||||||
|
- [Improvement Goals](docs/improvement-goals.md) — Priorities, opportunities, open questions
|
||||||
|
|
||||||
|
## Source Files
|
||||||
|
|
||||||
|
- `raw/001-raw.txt` — Original working document
|
||||||
|
- `raw/002-session-with-gpt.txt` — GPT session assessment
|
||||||
|
- `CONTEXT.md` — Polished context from grilling session
|
||||||
|
|
||||||
|
## Repos (reference)
|
||||||
|
|
||||||
|
- `repos/api/` — Backend API
|
||||||
|
- `repos/ui-user/` — User Frontend
|
||||||
|
- `repos/ui-expert/` — Expert Frontend
|
||||||
|
|||||||
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
|
||||||
254
raw/001-raw.txt
Normal file
254
raw/001-raw.txt
Normal file
@@ -0,0 +1,254 @@
|
|||||||
|
Working Document
|
||||||
|
Background
|
||||||
|
|
||||||
|
I have an educational background in Mechanical Engineering (Solid Mechanics), so my knowledge of Computer Science and Software Engineering fundamentals is limited compared to software engineers.
|
||||||
|
|
||||||
|
Currently, I work as a QA Engineer in a software company that develops insurance-related systems. One of the primary products is an insurance claim management platform used for Third-Party Vehicle Insurance and Comprehensive Vehicle Insurance.
|
||||||
|
|
||||||
|
Although my official title is QA Engineer, my day-to-day responsibilities extend well beyond software testing.
|
||||||
|
|
||||||
|
Current Responsibilities
|
||||||
|
|
||||||
|
My responsibilities include, but are not limited to:
|
||||||
|
|
||||||
|
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
|
||||||
|
Daily Workflow
|
||||||
|
|
||||||
|
The overall workflow currently looks like this:
|
||||||
|
|
||||||
|
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
|
||||||
|
My Jira Responsibilities
|
||||||
|
|
||||||
|
A significant portion of my working time is spent creating high-quality Jira tasks.
|
||||||
|
|
||||||
|
This process typically includes:
|
||||||
|
|
||||||
|
Writing a meaningful title
|
||||||
|
Writing a detailed description
|
||||||
|
Explaining the business requirement
|
||||||
|
Specifying affected URLs
|
||||||
|
Specifying affected pages
|
||||||
|
Attaching screenshots
|
||||||
|
Annotating screenshots (using Paint)
|
||||||
|
Highlighting UI elements
|
||||||
|
Explaining expected behavior
|
||||||
|
Writing backend expectations
|
||||||
|
Specifying API modifications
|
||||||
|
Explaining request body changes
|
||||||
|
Explaining response model changes
|
||||||
|
Describing validation rules
|
||||||
|
|
||||||
|
Sometimes I also need to specify:
|
||||||
|
|
||||||
|
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
|
||||||
|
|
||||||
|
When I discover a bug, I usually follow a workflow similar to this:
|
||||||
|
|
||||||
|
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
|
||||||
|
Tools I Use
|
||||||
|
|
||||||
|
I regularly work with the following tools:
|
||||||
|
|
||||||
|
Jira
|
||||||
|
Swagger
|
||||||
|
MongoDB
|
||||||
|
Browser DevTools
|
||||||
|
Bruno
|
||||||
|
Postman
|
||||||
|
JMeter
|
||||||
|
Paint (for UI annotations)
|
||||||
|
|
||||||
|
I also occasionally read code from several repositories:
|
||||||
|
|
||||||
|
Backend
|
||||||
|
User Frontend
|
||||||
|
Expert Frontend
|
||||||
|
|
||||||
|
My code-reading ability is still at a beginner level.
|
||||||
|
|
||||||
|
AI-Assisted Workflow
|
||||||
|
|
||||||
|
To improve consistency, I already use ChatGPT as part of my workflow.
|
||||||
|
|
||||||
|
The process is:
|
||||||
|
|
||||||
|
Raw Requirement
|
||||||
|
│
|
||||||
|
▼
|
||||||
|
ChatGPT
|
||||||
|
│
|
||||||
|
▼
|
||||||
|
Structured Jira Ticket
|
||||||
|
│
|
||||||
|
▼
|
||||||
|
Manual Review
|
||||||
|
│
|
||||||
|
▼
|
||||||
|
Publish to Jira
|
||||||
|
|
||||||
|
This has significantly improved the quality of my Jira tickets.
|
||||||
|
|
||||||
|
Current Challenges
|
||||||
|
|
||||||
|
Several challenges consume a considerable amount of my time.
|
||||||
|
|
||||||
|
1. Documentation Overhead
|
||||||
|
|
||||||
|
Creating complete Jira tickets requires significant manual effort.
|
||||||
|
|
||||||
|
This includes:
|
||||||
|
|
||||||
|
Writing descriptions
|
||||||
|
Organizing requirements
|
||||||
|
Creating screenshots
|
||||||
|
Highlighting UI changes
|
||||||
|
Explaining backend changes
|
||||||
|
2. Context Switching
|
||||||
|
|
||||||
|
Multiple projects are active simultaneously.
|
||||||
|
|
||||||
|
Because I spend most of my time supporting the Yara project, I rarely have enough time to review other projects.
|
||||||
|
|
||||||
|
3. Technical Learning Curve
|
||||||
|
|
||||||
|
Since my background is Mechanical Engineering rather than Computer Science, I often use development tools without fully understanding their best practices.
|
||||||
|
|
||||||
|
For example:
|
||||||
|
|
||||||
|
Swagger
|
||||||
|
MongoDB
|
||||||
|
Postman
|
||||||
|
Bruno
|
||||||
|
Browser DevTools
|
||||||
|
JMeter
|
||||||
|
|
||||||
|
I know how to accomplish tasks, but not always the most efficient or standard way.
|
||||||
|
|
||||||
|
4. Requirement Quality
|
||||||
|
|
||||||
|
Some Jira tickets are created by our CTO using AI.
|
||||||
|
|
||||||
|
Since the CTO is relatively new to the product, some generated titles and descriptions lack sufficient product context.
|
||||||
|
|
||||||
|
As a result:
|
||||||
|
|
||||||
|
Requirements can become ambiguous.
|
||||||
|
Reading and understanding them takes extra effort.
|
||||||
|
Additional clarification is often required before implementation.
|
||||||
|
My Main Goal
|
||||||
|
|
||||||
|
I want to redesign my workflow so that I can:
|
||||||
|
|
||||||
|
Spend less time on repetitive documentation.
|
||||||
|
Produce higher-quality Jira tickets.
|
||||||
|
Automate repetitive work wherever possible.
|
||||||
|
Better utilize AI throughout the workflow.
|
||||||
|
Free enough time to contribute to other projects.
|
||||||
|
Improve my technical understanding of the software ecosystem.
|
||||||
|
Questions for Further Analysis
|
||||||
|
|
||||||
|
To optimize this workflow, I'd like to answer the following questions step by step.
|
||||||
|
|
||||||
|
Process Understanding
|
||||||
|
What percentage of my 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?
|
||||||
|
Long-Term Objective
|
||||||
|
|
||||||
|
My long-term objective is to 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 me to focus more on high-value engineering work rather than repetitive documentation.
|
||||||
214
raw/002-session-with-gpt.txt
Normal file
214
raw/002-session-with-gpt.txt
Normal file
@@ -0,0 +1,214 @@
|
|||||||
|
QA Workflow Assessment (Version 0.1)
|
||||||
|
1. Profile
|
||||||
|
|
||||||
|
Official Job Title
|
||||||
|
|
||||||
|
QA Engineer
|
||||||
|
|
||||||
|
Experience
|
||||||
|
|
||||||
|
Approximately 1 year
|
||||||
|
|
||||||
|
Primary Projects
|
||||||
|
|
||||||
|
Yara (main project)
|
||||||
|
TamasLink (Call Center)
|
||||||
|
Other projects (Balan, Beno, Karjo, etc.) on a periodic basis
|
||||||
|
|
||||||
|
Reporting
|
||||||
|
|
||||||
|
Work requests come directly from both the CEO and CTO.
|
||||||
|
2. Nature of the Role
|
||||||
|
|
||||||
|
Although the official title is QA Engineer, the actual responsibilities extend far beyond traditional software testing.
|
||||||
|
|
||||||
|
The role combines responsibilities from multiple disciplines:
|
||||||
|
|
||||||
|
QA Engineer
|
||||||
|
Requirement Analyst
|
||||||
|
Product Analyst
|
||||||
|
Technical Writer
|
||||||
|
Bug Investigator
|
||||||
|
API Tester
|
||||||
|
Database Inspector
|
||||||
|
3. 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.
|
||||||
|
4. Requirement Analysis Process
|
||||||
|
|
||||||
|
For 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
|
||||||
|
|
||||||
|
For ambiguous or larger requirements:
|
||||||
|
|
||||||
|
Receive Request
|
||||||
|
↓
|
||||||
|
Analyze current workflow
|
||||||
|
↓
|
||||||
|
Discuss with Frontend / Backend
|
||||||
|
↓
|
||||||
|
Reach verbal agreement
|
||||||
|
↓
|
||||||
|
Create Jira Task
|
||||||
|
5. Investigation Workflow
|
||||||
|
|
||||||
|
When validating features or investigating bugs, the workflow typically involves several tools.
|
||||||
|
|
||||||
|
UI
|
||||||
|
↓
|
||||||
|
Browser DevTools
|
||||||
|
↓
|
||||||
|
Network Requests
|
||||||
|
↓
|
||||||
|
Swagger
|
||||||
|
↓
|
||||||
|
MongoDB
|
||||||
|
↓
|
||||||
|
Root Cause Analysis
|
||||||
|
6. Current Toolset
|
||||||
|
|
||||||
|
Daily tools include:
|
||||||
|
|
||||||
|
Jira
|
||||||
|
Swagger
|
||||||
|
MongoDB
|
||||||
|
Browser DevTools
|
||||||
|
Bruno
|
||||||
|
Postman
|
||||||
|
JMeter
|
||||||
|
Paint (UI annotation)
|
||||||
|
|
||||||
|
The repositories of the backend and frontend applications are also consulted when necessary, although code-reading skills are still at a beginner level.
|
||||||
|
|
||||||
|
7. Current Pain Points
|
||||||
|
A. API Complexity
|
||||||
|
|
||||||
|
The biggest time consumer is API investigation.
|
||||||
|
|
||||||
|
Reasons include:
|
||||||
|
|
||||||
|
Large number of APIs
|
||||||
|
Difficulty remembering rarely used APIs
|
||||||
|
Finding the correct endpoint
|
||||||
|
Understanding API sequences within a business flow
|
||||||
|
Authentication before testing
|
||||||
|
Preparing request bodies
|
||||||
|
Switching between multiple tools
|
||||||
|
B. Authentication Overhead
|
||||||
|
|
||||||
|
Many test sessions require repeating the authentication process.
|
||||||
|
|
||||||
|
Typical sequence:
|
||||||
|
|
||||||
|
Open Swagger
|
||||||
|
↓
|
||||||
|
Captcha API
|
||||||
|
↓
|
||||||
|
Login API
|
||||||
|
↓
|
||||||
|
Receive Token
|
||||||
|
↓
|
||||||
|
Authorize
|
||||||
|
↓
|
||||||
|
Start Testing
|
||||||
|
|
||||||
|
This workflow may be repeated multiple times every day.
|
||||||
|
|
||||||
|
C. Stateful Business Flows
|
||||||
|
|
||||||
|
The application is heavily state-driven.
|
||||||
|
|
||||||
|
Many APIs cannot be tested independently because business entities must first reach a specific state.
|
||||||
|
|
||||||
|
Example:
|
||||||
|
|
||||||
|
Create Case
|
||||||
|
↓
|
||||||
|
Upload Documents
|
||||||
|
↓
|
||||||
|
Expert Review
|
||||||
|
↓
|
||||||
|
Approval
|
||||||
|
↓
|
||||||
|
Payment
|
||||||
|
|
||||||
|
This creates dependencies between APIs and significantly increases investigation time.
|
||||||
|
|
||||||
|
D. Test Data Preparation
|
||||||
|
|
||||||
|
MongoDB is frequently used to:
|
||||||
|
|
||||||
|
Inspect business entities
|
||||||
|
Verify system state
|
||||||
|
Modify test data when necessary
|
||||||
|
E. Context Switching
|
||||||
|
|
||||||
|
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.
|
||||||
|
|
||||||
|
8. Current AI Usage
|
||||||
|
|
||||||
|
ChatGPT is already integrated into the workflow.
|
||||||
|
|
||||||
|
Current use cases include:
|
||||||
|
|
||||||
|
Converting raw requirements into structured Jira tickets
|
||||||
|
Improving wording
|
||||||
|
Organizing documentation
|
||||||
|
9. Observations
|
||||||
|
|
||||||
|
Based on the current information, the main bottlenecks do not appear to be writing Jira tickets.
|
||||||
|
|
||||||
|
Instead, the primary bottlenecks are:
|
||||||
|
|
||||||
|
Reconstructing business context.
|
||||||
|
Finding the correct APIs.
|
||||||
|
Navigating complex API chains.
|
||||||
|
Preparing valid test data.
|
||||||
|
Repeating authentication and setup tasks.
|
||||||
|
Frequent context switching across tools.
|
||||||
|
10. Initial Improvement Opportunities
|
||||||
|
|
||||||
|
Without changing the product itself, several areas appear promising for future optimization:
|
||||||
|
|
||||||
|
Standardized Bruno/Postman collections organized by business flows.
|
||||||
|
Better use of environments and variables to reduce repetitive authentication work.
|
||||||
|
Documentation of business flow → API mappings.
|
||||||
|
Reusable test data and state preparation procedures.
|
||||||
|
AI-assisted API discovery and workflow navigation.
|
||||||
|
AI-assisted root cause analysis support.
|
||||||
|
A centralized QA knowledge base to preserve project knowledge across time and projects.
|
||||||
Reference in New Issue
Block a user