From 7d811d8ddbc07a1fd0abfdfec5a7885e1df37a47 Mon Sep 17 00:00:00 2001 From: Sina Torabizadeh Date: Wed, 15 Jul 2026 17:29:32 +0330 Subject: [PATCH] docs: import qa workflow knowledge from grilling session --- README.md | 23 ++++ docs/current-workflows.md | 163 ++++++++++++++++++++++ docs/glossary.md | 41 ++++++ docs/improvement-goals.md | 87 ++++++++++++ docs/pain-points.md | 137 +++++++++++++++++++ docs/qa-profile.md | 50 +++++++ docs/state-machines.md | 49 +++++++ docs/workflow-steps.md | 46 +++++++ raw/001-raw.txt | 254 +++++++++++++++++++++++++++++++++++ raw/002-session-with-gpt.txt | 214 +++++++++++++++++++++++++++++ 10 files changed, 1064 insertions(+) create mode 100644 docs/current-workflows.md create mode 100644 docs/glossary.md create mode 100644 docs/improvement-goals.md create mode 100644 docs/pain-points.md create mode 100644 docs/qa-profile.md create mode 100644 docs/state-machines.md create mode 100644 docs/workflow-steps.md create mode 100644 raw/001-raw.txt create mode 100644 raw/002-session-with-gpt.txt diff --git a/README.md b/README.md index 1ff1d7f..8a05a86 100644 --- a/README.md +++ b/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 diff --git a/docs/current-workflows.md b/docs/current-workflows.md new file mode 100644 index 0000000..d6ef44b --- /dev/null +++ b/docs/current-workflows.md @@ -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 +``` diff --git a/docs/glossary.md b/docs/glossary.md new file mode 100644 index 0000000..b626f5e --- /dev/null +++ b/docs/glossary.md @@ -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. diff --git a/docs/improvement-goals.md b/docs/improvement-goals.md new file mode 100644 index 0000000..228f66e --- /dev/null +++ b/docs/improvement-goals.md @@ -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? diff --git a/docs/pain-points.md b/docs/pain-points.md new file mode 100644 index 0000000..6b074af --- /dev/null +++ b/docs/pain-points.md @@ -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 diff --git a/docs/qa-profile.md b/docs/qa-profile.md new file mode 100644 index 0000000..4ed3044 --- /dev/null +++ b/docs/qa-profile.md @@ -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. diff --git a/docs/state-machines.md b/docs/state-machines.md new file mode 100644 index 0000000..5947a5e --- /dev/null +++ b/docs/state-machines.md @@ -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. | diff --git a/docs/workflow-steps.md b/docs/workflow-steps.md new file mode 100644 index 0000000..d655fb0 --- /dev/null +++ b/docs/workflow-steps.md @@ -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 diff --git a/raw/001-raw.txt b/raw/001-raw.txt new file mode 100644 index 0000000..ba60ece --- /dev/null +++ b/raw/001-raw.txt @@ -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. \ No newline at end of file diff --git a/raw/002-session-with-gpt.txt b/raw/002-session-with-gpt.txt new file mode 100644 index 0000000..6784bdf --- /dev/null +++ b/raw/002-session-with-gpt.txt @@ -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. \ No newline at end of file