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 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