Manual Testing Tutorial for Beginners: From SDLC to Your First Bug Report

If you are starting a QA career in 2026 and you skip manual testing, you are skipping the foundation every working tester is built on. Tools come and go. The discipline of manual testing is what separates engineers who find real bugs from engineers who run scripts and hope.

What manual testing actually is

Manual testing is the practice of validating software by hand, without scripted automation, against the requirements it was built to meet. That definition is technically correct and almost completely useless. Here is the better one. Manual testing is the discipline of using a product the way real users will, then deliberately abusing it the way real users sometimes do, then writing down everything that broke in a way the engineering team can act on. It is part empathy, part suspicion, part documentation.

Why you cannot skip manual testing in 2026

Every few months someone declares manual testing dead. They are wrong every time. Automation handles repetition. Manual testing handles judgment. When a feature is brand new and the requirements are still shifting, no automation script in the world will help you. When you are checking whether the new checkout flow feels right or feels wrong, no robot will catch what your eyes catch. The companies hiring fastest in 2026 want testers who can do both, but they will not hire someone who only knows the second.

SDLC explained the way teams actually use it

The Software Development Life Cycle is the path a feature travels from idea to production. It is usually drawn as a clean five-stage diagram. In real life it is messy, it loops, and it has fistfights. The five core stages you need to know are:

1. Requirements gathering. Product, design, and engineering decide what to build and why.
2. Design. Architecture, mockups, technical specs, and the inevitable arguments about scope.
3. Development. Engineers write code. QA reads the requirements and starts thinking about how to break them.
4. Testing. Where you live. Where the work either holds up or falls apart.
5. Deployment and maintenance. The release goes out, monitoring runs, regressions get caught, the cycle repeats.

The QA engineer who only shows up at stage four is the one who finds problems too late to fix cheaply. The QA engineer who shows up at stage one is the one who never lets the worst defects get coded in the first place.

STLC: the testing life cycle inside the SDLC

The Software Testing Life Cycle is the pattern that organizes how testing happens within a development cycle. It has six phases:

1. Requirement analysis. Read the requirements. Find the gaps. Ask the questions that make the product manager nervous.
2. Test planning. Decide scope, approach, resources, schedule, and exit criteria.
3. Test case design. Write the cases that will prove the feature works or expose where it does not.
4. Test environment setup. Get the build, the data, the tools, and the access you need.
5. Test execution. Run the cases. Log defects. Retest fixes.
6. Test cycle closure. Final reports, lessons learned, and the documentation that helps the next release.

Test case design: the artifact that defines you

If you take one thing from this tutorial, take this. Your test cases are how the rest of the engineering organization measures your craft. A bad test case is vague, untraceable, and useless six months later. A good test case is specific, repeatable, and reads like a recipe a stranger could follow.

The minimum fields every test case needs are:

• Test case ID and title
• Module or feature it covers
• Preconditions
• Test steps, numbered, in plain language
• Expected result
• Actual result (filled at execution)
• Pass/fail status
• Severity if it fails
• Tester name and execution date

That is the floor, not the ceiling. Mature teams add traceability to requirements, automation linkage, and metadata for reporting. But if your test cases consistently include the fields above, you are already writing better cases than half the testers I have hired.

Types of testing every beginner needs to know

You do not need to memorize all 50+ testing types. You do need to know these:

• Functional testing: does the feature do what it is supposed to do
• Regression testing: did the new change break anything that used to work
• Smoke testing: do the most critical paths still load and respond
• Sanity testing: targeted retest of the area that just got fixed
• Exploratory testing: structured improvisation to find what scripted tests miss
• Usability testing: is the feature actually pleasant to use
• Compatibility testing: does it work across browsers, devices, and platforms

Defect lifecycle and severity vs priority

A defect goes through a fairly standard lifecycle: New, Assigned, Open, Fixed, Retest, Verified, Closed. Sometimes detours through Rejected, Deferred, or Reopened. Knowing this lifecycle keeps you from logging the same bug twice or losing track of the ones in flight.

The two values that confuse beginners most are severity and priority. Severity is how bad the bug is technically. Priority is how soon it needs to be fixed. They are not the same. A typo on the homepage might be low severity but very high priority because it affects every visitor. A crash in a feature only ten users have access to might be high severity but low priority because the impact is limited.

Writing a bug report that gets fixed

Most bugs do not get ignored because they are unimportant. They get ignored because the report is hard to act on. Engineers triage dozens of reports a day. The clearer yours is, the faster it moves. Every defect report needs:

• A clear, specific title (not “login broken” but “Login fails with 500 error when password contains @ symbol”)
• Environment details (browser, OS, build version)
• Numbered steps to reproduce, in the smallest possible sequence that triggers the bug
• Expected behavior
• Actual behavior
• Screenshots, video, console logs, or network requests where relevant
• Frequency (always, intermittent, one-time)
• Severity and priority your best estimate

Your first hands-on practice

Stop reading after this section and go do this. Pick any production website you use often. Pretend you have been asked to test the signup flow. Write ten test cases using the format above. Cover happy path, invalid email, weak password, missing required field, edge cases like maximum length input, browser back button mid-flow, and what happens if the network drops at the wrong moment. By the time you finish, you will have done more practical testing than three hours of video tutorials would have given you.

Where to go from here

Manual testing is the floor. Once you can write clear cases, find real defects, and write reports that get acted on, the next step is automation. Tools like Playwright and Selenium let you scale the work you are doing manually into suites that run on every commit. But automation built on a weak manual foundation is a trap. Most flaky test suites in the industry exist because someone tried to automate before they understood what they were testing.

The order is fixed. Manual first. Automation second. Skipping it is what produces testers who can run scripts but cannot find bugs.

Written by

Anveet Singh Chhabda

QA engineer and software testing educator. Manual testing, Playwright automation, and API testing taught from real-world product experience.