138 lines
3.4 KiB
Markdown
138 lines
3.4 KiB
Markdown
---
|
||
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
|