docs: import qa workflow knowledge from grilling session

This commit is contained in:
2026-07-15 17:29:32 +03:30
parent 61fd3e314e
commit 7d811d8ddb
10 changed files with 1064 additions and 0 deletions

254
raw/001-raw.txt Normal file
View 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.