214 lines
4.5 KiB
Plaintext
214 lines
4.5 KiB
Plaintext
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. |