★ "QA Engineer in training — I break things on purpose, so your users never have to."

I'm Naveen Prabu, a final-year B.Tech Information Technology student at Sri Shakthi Institute of Engineering and Technology, Coimbatore — and, more relevantly to this page, someone who has decided that testing is not the fallback plan for people who "couldn't become developers." It's a discipline of its own: precision over speed, skepticism over assumption, and protecting the person on the other end of the screen who never asked to debug your app for you.

Right now I test manually — deliberately, thoroughly, and with a written trail (test scenarios, test cases, execution logs, Jira tickets) to back up every claim I make about quality. I'm actively leveling that skill set up into automation, learning Python and Selenium WebDriver so the regression checks I currently run by hand can eventually run themselves while I go hunt for the bugs a script can't see.

If you're a recruiter: I'm looking for an entry-level QA / Manual Testing role. If you're a hiring manager: the case studies below are real work, not tutorial screenshots. If you're a fellow tester: I'd genuinely like to hear how you structure your test suites.

This isn't a finished skill list — it's a live roadmap.

Manual Testing Fundamentals     [██████████████████████] Solid ground
Test Case & Scenario Design     [██████████████████████] Solid ground
Jira Bug Reporting              [██████████████████████] Solid ground
SQL for Test Data Validation    [██████████████████████] Solid ground
Python for Automation           [██████████░░░░░░░░░░░░] In progress
Selenium WebDriver              [███████░░░░░░░░░░░░░░░] In progress
SDET-style Automation Suite     [███░░░░░░░░░░░░░░░░░░░] Just getting started

Next milestones: first end-to-end Selenium script → first automated regression suite on a demo app → contributing that suite back into a GitHub repo, same as the manual projects below.

Testing & QA

Languages

Tools

In Progress — Automation Track

Most portfolios show finished code. This one shows finished scrutiny.

I ran a full manual QA cycle against OrangeHRM, a real-world open-source HR management application, focused on the Login module — the single most security-sensitive entry point of the whole system. The goal wasn't to click around until something looked broken; it was to prove, on paper and in Jira, that the module had actually been checked against how real users (and careless ones, and malicious ones) would use it.

What I did:

• Designed 20 test scenarios, deliberately spanning functional, negative, edge-case, and UI categories — not just "does login work," but "what happens when it shouldn't."
• Converted the highest-value scenarios into 10 documented test cases, each with preconditions, steps, expected results, and actual results.
• Executed every test case and logged findings as a proper Jira defect report — steps to reproduce, severity, and priority included, not just a one-line complaint.
• Compiled everything into a Test Summary Report, closing with a security enhancement recommendation based on what the testing surfaced.

A timed, independent assignment — no walkthrough given, no modules pre-defined for me. I had to explore the application cold, decide what mattered, and deliver against a real deadline.

I tested three modules of the Tichi web app: Sign Up, a two-page Sign In flow, and Forgot Password. Rather than confirming the happy path and calling it done, I pushed on how each flow handled bad input, broken sequences, and edge conditions — which is where the real defects were hiding.

What I found and delivered:

• 8 real bugs identified across the three modules, each logged with reproduction steps
• 41 test cases written and executed, landing at roughly an 80% pass rate
• A defect sheet with an embedded screenshot as visual proof for one of the logged issues
• A live Jira ticket (TAP-1) tracking the assignment
• Full writeup and artifacts published to GitHub, submitted on deadline

More case studies are coming as I level up into automation — the next one on this page will have a .py file in it, not just a spreadsheet.

"Untested code is a hypothesis. A test case is how you find out if you were wrong before your users do."

A few things I hold to:

• Positive results and passing tests are not the same thing. A negative scenario that behaves correctly is a pass — that distinction matters more than people think.
• I test in production... just kidding. Never in production.
• If a bug is easy to find, assume there are three harder ones hiding behind it.

★

_{Every bug I find is one your users never will.}