Register → sign in → review work → create and prioritize a task → update progress → log out.
Portfolio case study · TaskFlow SaaS
Quality is not a final check.
It is a delivery system.
I designed this lab to show how I turn product risk into practical coverage, clear evidence, and an honest release recommendation.
01 / Product under test
A small SaaS product with real testing depth.
TaskFlow is a local-first project and task management app with authentication, registration, dashboard summaries, task CRUD, search, filters, notifications, profile, settings, and a REST-style task API.
Authorization boundaries, data integrity, input validation, state synchronization, keyboard access, and responsive task workflows.
The main demo stays usable. Eighteen intentional defects activate only through the isolated buggy-demo configuration.
02 / Testing strategy
Risk first. Traceability throughout.
I used a layered strategy: fast smoke confidence for release-critical flows, deeper manual investigation where human observation adds value, API checks at system boundaries, and Playwright coverage for stable repeatable journeys.
Understand
Review product intent, acceptance criteria, architecture, and user risk.
Model risk
Prioritize authentication, authorization, task integrity, and release-critical paths.
Design coverage
Combine examples, boundaries, equivalence classes, negative paths, and charters.
Execute & learn
Capture evidence, report reproducible defects, and update regression coverage.
03 / Test coverage
Coverage tells a story, not just a percentage.
The inventory intentionally includes positive, negative, edge, boundary, API, responsive, cross-browser, and accessibility cases. Unexecuted and blocked work stays visible instead of being counted as success.
36Passed7Failed2Blocked3Not executed
04 / Bugs discovered
Reports optimized for fast decisions.
Each defect contains environment, severity, priority, preconditions, concise reproduction steps, expected and actual behavior, evidence location, and retest status.
●●●
GET /api/tasks/other-user-id → 200 OK · private task returned
User can access another account’s task by changing the task ID
Server returns the task payload
●●●
qa@example.com → account created twice
Registration accepts an already registered email
Second account is created
●●●
Filter: High → Low-priority tasks displayed
High-priority filter returns low-priority tasks
Low tasks are included and High tasks omitted
05 / Automation, API & CI
Automation protects feedback speed.
The automated layer targets stable, high-value behavior while the manual layer keeps space for usability, exploratory learning, and nuanced visual observation.
Maintainable by design
Page objects isolate selectors and actions. Specs describe user intent across login, registration, CRUD, search, filters, validation, logout, and failure paths.
tests/e2e/pages/
├── login.page.ts
└── tasks.page.tsBoundary-focused checks
GET, POST, PATCH, and DELETE cases cover success, missing authorization, invalid fields, unknown resources, and documented error shapes.
Authorization: Bearer demo-token
Content-Type: application/jsonQuality on every change
GitHub Actions installs deterministically, lints, type-checks, runs unit and API checks, executes browser tests, and preserves the Playwright report.
lint → typecheck → test
→ playwright → report06 / Results & lessons
Honest results create trust.
The reported figures come directly from the project’s test inventory: 36 passed, 7 failed, 2 blocked, and 3 not executed. No business impact or production metrics are invented.
Traceability exposes gaps
Linking requirements, tests, results, and defects made untested assumptions visible and kept the release discussion grounded in evidence.
State deserves dedicated tests
Several high-value defects came from synchronized UI state—duplicates, counters, persistence, and combined filters—not isolated field validation.
Good QA communicates risk
A pass rate alone is insufficient. Severity, affected module, remaining coverage, and explicit exit criteria make the result actionable.
Transferable experience
Document analysis built habits that strengthen my QA work.
Two years of professional document analysis strengthened my attention to detail, validation discipline, inconsistency detection, requirements compliance, structured documentation, process rigor, and focus on information accuracy. It was not a software QA role—but those habits transfer directly to careful testing and precise defect communication.