I do not test whether software looks finished.
I test whether its confidence is deserved.
A passing build, a clean dashboard, or a completed test run is only an output.
The real quality questions are:
What was verified?
What was assumed?
What can fail?
What evidence supports the release decision?
My work is organized around four signals:
|
Find missing rules, conflicting interpretations, and unsupported assumptions. |
Trace state and data back to an explicit source of truth. |
Attack retries, concurrency, partial failure, and dependency boundaries. |
Release only when the available evidence matches the actual risk. |
flowchart LR
A[Requirement] --> B[States and invariants]
B --> C[Failure hypotheses]
C --> D[Observable evidence]
D --> E[Release decision]
|
Can requirement impact be traced without hiding uncertainty? An evidence-backed requirement-to-code impact analyzer for backend teams. Quality focus
|
Can financial data remain trustworthy after retries and corrections? An operational ledger for wholesale vegetable depots in Vietnam. Quality focus
|
|
What degrades first when a full-stack system is under pressure? A property-management platform with payments, contracts, notifications, search, and external dependencies. Quality focus
|
What evidence should block or permit a release? A learning platform with frontend, backend, PostgreSQL, Redis, queues, and observability. Quality focus
|
[ ] invalid state transitions
[ ] duplicate or out-of-order operations
[ ] stale reads and inconsistent projections
[ ] retries without idempotency
[ ] partial success across dependencies
[ ] authorization gaps
[ ] silent fallback behavior
[ ] unobservable failures
[ ] green tests that asserted the wrong thing
[ ] requirements that cannot be tested consistently
| Area | Focus |
|---|---|
| Test design | exploratory, scenario-based, state-transition, risk-based |
| API | Postman, contracts, validation, error semantics |
| Data | SQL, PostgreSQL, reconciliation, invariants |
| Automation | Vitest, Playwright, integration tests |
| Reliability | retries, idempotency, queues, dependency failure |
| Observability | logs, metrics, Prometheus, Grafana |
| Engineering context | TypeScript, NestJS, Next.js, Docker, GitHub Actions |
Development is supporting context.
The primary question remains:
Does the system behave correctly, fail safely, and leave enough evidence to explain what happened?
target_role: QA/QC Intern
trajectory: System-level Quality Engineer
developing:
- production-oriented API testing
- test automation
- reliability and performance analysis
- English communication for global QA teams