Career Story

My path into QA began with telecommunications and IoT, where I learned to think in terms of connected systems, real-world behavior, and reliability. I later moved into enterprise software testing and now work across sales, payment, inventory, and financial workflows.

That technical background still shapes how I investigate software. I rarely stop at what appears on screen; I follow the rule through its API behavior, stored data, and effect on the next business process.

QA Mindset

I see quality as a shared responsibility. QA adds the most value when it helps the team recognize risk before release, not only when it reports defects after implementation.

• What user or business goal could fail?
• Which rule, boundary, or integration is most exposed to risk?
• How can the issue be reproduced and understood quickly?
• What evidence confirms the fix and protects regression coverage?

How I Work

1. Clarify the requirement Review acceptance criteria, dependencies, data conditions, and unclear behavior before execution.
2. Prioritize risk Focus coverage on business-critical paths, calculations, permissions, state changes, and integrations.
3. Design meaningful scenarios Combine positive, negative, boundary, recovery, and end-to-end cases.
4. Investigate across layers Compare UI behavior with API payloads and database records when diagnosing failures.
5. Communicate actionable findings Report defects with concise reproduction steps, evidence, impact, and retest scope.
6. Confirm release confidence Retest fixes, run focused regression, and communicate remaining risk.

Work Style

I work best when QA is involved early enough to question requirements, prepare data, and identify risky dependencies. During execution, I keep evidence organized and make defect reports concise enough for developers to act on without unnecessary back-and-forth.

Professional Values

Clarity

Requirements, defects, and residual risk should be understandable.

Evidence

A pass, failure, or release recommendation should be traceable.

Business Context

Technically valid behavior can still be wrong for the process.

Curiosity

Tools improve testing, but good questions reveal the risk.

Growth Direction

My strongest foundation is manual and business-process testing. I use Postman and MySQL to investigate integrations and data. I also have practical exposure to Katalon and Selenium for test automation, as well as Gherkin for writing clear, readable behavior-driven test scenarios (BDD) that support repeatable checks. My next step is to build deeper automation capability without overstating my current experience.