🧪 4 months, 4 projects, 400+ test cases — here's what I've been building.

I'm a Manual QA Tester with 2+ years of experience testing 30+ Android, iOS, and web apps. Over the past few months I turned that experience into a public, verifiable portfolio:

📱 iOS Air Printer App — 150+ test cases, 20 modules, tested across 6 languages including Arabic RTL, plus accessibility and security testing 📱 iOS Celebrity Face-Match App — 100+ test cases, 54+ bugs found (including 2 app-crashing bugs) across 5 devices 🌐 Web business platform — 150+ bugs logged, including silent data-save failures that would've shipped unnoticed 🔌 Football Data API — Postman-based API testing with structured assertions and edge-case coverage

Every project follows the same discipline: understand requirements → design structured test cases → execute thoroughly → document findings clearly enough that a dev team can act without back-and-forth.

I'm now expanding into automation with Playwright + Python — not to replace manual testing, but because knowing when to automate and when a human needs to actually look is what separates good QA from a checklist.

Have a build that needs a real second pair of eyes before it ships? Let's talk.

Full breakdowns + bug reports linked in my profile. #softwaretesting #qualityassurance #manualtesting #apitesting #qaengineer #testautomation

A good QA report should make the next fix obvious.

Finding bugs is only one part of QA.

The more important part is documenting them clearly enough that a founder, designer or developer can understand what happened, why it matters, and what should be fixed first.

When I test a website, landing page or SaaS flow, I focus on making each important issue easy to act on.

For each issue, I document:

• what happened • where it happened • steps to reproduce • expected behavior • actual behavior • screenshot or visual note • severity level • launch impact • suggested next action

The goal is not to create a huge report that nobody wants to read.

The goal is to help the team decide:

• what must be fixed before launch • what can be fixed soon after launch • what only needs monitoring • what is not critical enough to block release

This matters a lot for small teams and early-stage products.

When time is limited, a confusing QA report can slow the team down. A clear one helps everyone move faster.

That is the kind of QA work I focus on: practical testing, clear bug reports, launch-readiness checks, and feedback that helps teams fix the right things first.