Skip to main content
QA Learning Guide

Manual Testing
from zero.

Learn how professional QA testers think — write test cases, explore with browser DevTools, run smoke and regression checks, and practice on real pages at elangodev.com.

What is manual testing?

Every time you open an app and ask "does this button work?" or "why is this error message confusing?" you are doing informal manual testing. Professional manual QA turns that instinct into repeatable test cases, structured bug reports, and release checklists so teams ship software users can trust.

This guide is hands-on. You will practice on public pages of this site — contact forms, blog navigation, handbook content — using only a browser and DevTools. No test automation framework required to get started.

Test CasesSmoke TestingRegressionBug ReportsDevToolsAccessibilityCross-browser
Start here

Recommended learning path

Complete these six steps in order. Each builds practical skills you can list on a resume or use in your first QA role.

  1. 1

    Learn the core testing methods

    Read the testing methods section. Each method includes a simple analogy, step-by-step example, and pass vs fail outcomes on this site. Jump to section →

  2. 2

    Write your first test case

    Use the test case template to document steps, expected results, and test data for the contact form happy path. Jump to section →

  3. 3

    Practice negative testing

    Submit the contact form with missing fields and invalid email. Confirm error messages appear and no success toast shows. Jump to section →

  4. 4

    Explore with browser DevTools

    Open Chrome or Firefox DevTools. Inspect elements, watch the Network tab during form submit, and check Console for errors. Jump to section →

  5. 5

    Run a smoke test on public pages

    Walk through the site inventory checklist — home, blog, handbook, contact, and footer links. Log any broken navigation. Jump to section →

  6. 6

    File a practice bug report

    Pick a minor UI issue (spacing, typo, or responsive layout). Document it using the bug report template. Jump to section →

Foundations

QA fundamentals

Vocabulary and concepts every manual tester should know before writing the first test case.

What is manual testing?

Manual testing means a human tester explores software without automation scripts. You click buttons, fill forms, read messages, and compare what you see to what the requirements say should happen. It catches usability problems, visual bugs, and confusing flows that code-only checks often miss.

Manual vs automated testing

Automated tests repeat the same steps quickly in CI pipelines. Manual testing is better for first impressions, exploratory sessions, and subjective quality like readability or layout. Most teams use both: automation for regression, manual for new features and edge cases.

Test cases and test plans

A test case is one scenario with steps, test data, and an expected result. A test plan groups cases by feature or release. Good documentation lets another tester reproduce your work without guessing what you did.

Positive vs negative testing

Positive testing confirms the app works with valid input (happy path). Negative testing deliberately uses bad data — empty fields, wrong formats, extremely long text — to confirm the app fails gracefully with clear error messages instead of crashing.

Regression testing

After a bug fix or new feature, regression testing re-runs related scenarios to ensure nothing else broke. A short smoke checklist on core pages (home, contact, login) is a practical daily regression habit.

Exploratory testing

Exploratory testing has no fixed script upfront. You learn the product while testing, following curiosity: What if I double-click? What happens on slow network? What if I go back mid-form? Time-box 30 minutes and note surprises.

Core methods

Testing methods with real examples

Each method below includes a plain-language analogy, step-by-step instructions, a hands-on example on this site, and clear pass vs fail outcomes.

MethodOne-line summaryTime
Smoke TestingA 5-minute health check before anything else~5–15 min
Functional TestingDoes each feature do exactly what it should?~30–60 min per feature
Positive TestingThe happy path — everything entered correctly~10 min per scenario
Negative TestingDeliberately break things with bad input~20–30 min per feature
Regression TestingDid the fix break something else?~20–45 min (use a saved checklist)
Exploratory TestingNo script — follow your curiosity30–60 min time-boxed session
Boundary TestingTest the edges — min, max, and just outside limits~15–25 min per field
Usability TestingCan a real person use this without confusion?~45 min with a volunteer or self walkthrough
Cross-Browser TestingSame site, different browsers — should look and work the same~30 min (same checklist, 2+ browsers)
Accessibility TestingCan everyone use the site — including keyboard-only users?~30–45 min per critical flow

Smoke Testing

A 5-minute health check before anything else

~5–15 min

Smoke testing confirms the most critical paths work after a deploy. You do not test every edge case — you verify the app is stable enough for deeper testing.

Think of it like this

Like starting your car before a long drive — you check the engine starts, lights work, and doors close. You are not inspecting every bolt yet.

When: After every deploy, before a demo, or at the start of your work day.

How to do it — step by step

  1. 1

    Open the homepage — page loads without errors

  2. 2

    Click Blog in the nav — listing appears

  3. 3

    Open one article — content is readable

  4. 4

    Open Contact — form fields are visible

  5. 5

    Submit with fake test data — success message shows

Real example on this site

https://elangodev.com/contact

Contact page

Submit the form with valid test data

Name

Smoke Test User

Email

smoke@example.com

Message

Quick smoke test — please ignore.

Smoke test PASSED

  • All 5 steps complete without 404 or blank pages
  • No red errors in the browser Console
  • Contact form shows a success confirmation

Smoke test FAILED — stop and report

  • Homepage or /contact returns 404 or white screen
  • Navigation link goes to the wrong page
  • Form submit spins forever with no feedback
Practice this method

Functional Testing

Does each feature do exactly what it should?

~30–60 min per feature

Functional testing verifies that every button, field, and link behaves according to requirements. You test what the feature is supposed to do, not how pretty it looks.

Think of it like this

Like checking a vending machine — you put in a coin, press B4, and expect a snack to drop. The label, color, and logo are separate concerns.

When: When a new feature ships or an existing feature is changed.

How to do it — step by step

  1. 1

    Read what the feature should do (requirement or help text)

  2. 2

    List every input, button, and link on the page

  3. 3

    Test each one with valid data and observe the result

  4. 4

    Compare actual behavior to the documented expectation

  5. 5

    Log any mismatch as a bug with steps to reproduce

Real example on this site

https://elangodev.com/contact

Contact form

Verify every field and the submit button work as designed

Required fields

Name, email, message

Submit button

Sends data to the server

Success state

User sees confirmation

Functional test PASSED

  • Each field accepts input and shows a label
  • Submit sends data — Network tab shows POST /api/messages with 201
  • User sees a clear success message after submit

Functional test FAILED

  • Submit button does nothing when all fields are filled
  • Success toast appears but Network shows HTTP 500
  • Email field accepts text with no @ symbol and still submits
Practice this method

Positive Testing

The happy path — everything entered correctly

~10 min per scenario

Positive testing uses valid, expected input to confirm the application works under normal conditions. This is the first test you write for any feature.

Think of it like this

Like ordering your usual coffee with the correct size and name — the barista should hand you exactly what you asked for, no surprises.

When: First test for any new feature; baseline before trying edge cases.

How to do it — step by step

  1. 1

    Identify valid test data (realistic name, proper email format)

  2. 2

    Fill every required field correctly

  3. 3

    Submit once and wait for the response

  4. 4

    Confirm success message and no Console errors

Real example on this site

https://elangodev.com/contact

Contact form — happy path

Fill all fields with valid data and submit once

Name

Jane Tester

Email

jane.tester@example.com

Message

Positive test — valid data only.

Positive test PASSED

  • Form accepts all valid input without warnings
  • Success confirmation appears within a few seconds
  • User is not stuck on a loading spinner

Positive test FAILED

  • Valid email rejected with a false validation error
  • Form clears but no success message appears
  • Page reloads and loses all entered data unexpectedly
Practice this method

Negative Testing

Deliberately break things with bad input

~20–30 min per feature

Negative testing uses invalid, missing, or unexpected input to verify the app handles errors gracefully — clear messages, no crashes, no data corruption.

Think of it like this

Like trying to pay with an expired card — the cashier should politely decline and ask for another card, not freeze or charge you anyway.

When: After positive tests pass; essential for forms, login, and search.

How to do it — step by step

  1. 1

    Submit the form with all fields empty — note error messages

  2. 2

    Enter an invalid email (e.g. not-an-email) — submit again

  3. 3

    Fill only some required fields — confirm partial submit is blocked

  4. 4

    Double-click Submit rapidly — confirm no duplicate messages

Real example on this site

https://elangodev.com/contact

Contact form — validation

Submit with empty fields, then with invalid email

Empty submit

All fields blank → expect errors

Bad email

hello@ → expect format error

Missing message

Name + email only → expect error

Negative test PASSED

  • Empty submit shows clear errors on each missing field
  • Invalid email is rejected before or after submit
  • No success message when validation fails
  • No HTTP 500 — server handles bad input safely

Negative test FAILED

  • Empty submit succeeds silently or shows generic error
  • Invalid email is accepted and stored
  • App crashes or shows a stack trace to the user
Practice this method

Regression Testing

Did the fix break something else?

~20–45 min (use a saved checklist)

Regression testing re-runs previously passing tests after a code change to ensure existing features still work. Bugs often hide in unrelated areas.

Think of it like this

Like checking that fixing the kitchen tap did not flood the bathroom — one repair can accidentally affect another room.

When: After every bug fix, refactor, or new feature merge.

How to do it — step by step

  1. 1

    Open your saved smoke checklist from last release

  2. 2

    Re-run every case that passed before the change

  3. 3

    Pay extra attention to pages linked from the changed feature

  4. 4

    Compare results — any new failure is a regression bug

Real example on this site

https://elangodev.com/

Full site smoke re-run

Re-test home → blog → article → contact after a deploy

Before fix

Contact form passed on Monday

Change

Footer CSS updated on Tuesday

After fix

Re-run same contact test — still passes?

Regression test PASSED

  • All previously passing tests still pass
  • No new Console errors on pages that were clean before
  • Navigation and forms behave identically to last release

Regression test FAILED

  • Contact form worked yesterday but fails today after unrelated change
  • Footer update broke mobile menu on /blog
  • Dark mode toggle disappeared after handbook edit
Practice this method

Exploratory Testing

No script — follow your curiosity

30–60 min time-boxed session

Exploratory testing is simultaneous learning, test design, and execution. You have a time box and a mission, but no fixed steps — discoveries drive what you test next.

Think of it like this

Like exploring a new city without a map — you wander, notice interesting alleys, and remember spots that felt confusing or delightful.

When: New features, before major releases, or when scripted tests feel stale.

How to do it — step by step

  1. 1

    Set a timer for 30 minutes and pick a starting page

  2. 2

    Click everything that looks clickable — note surprises

  3. 3

    Try browser Back mid-flow, refresh mid-form, open 5 tabs

  4. 4

    Write down anything confusing, slow, or broken

Real example on this site

https://elangodev.com/blog

Blog — exploratory session

Spend 30 minutes clicking without a script

Try

Open 3 articles in new tabs

Try

Spam-click the same link 5 times

Try

Use Back button while article loads

Good exploratory session

  • You found at least one usability note or edge case
  • Session notes list URL, action, and what felt wrong
  • No critical crash — but minor issues are logged

Issues worth reporting

  • Double-clicking submit sends two identical messages
  • Article shows blank content after using browser Back
  • Mobile menu stays open and blocks half the screen
Practice this method

Boundary Testing

Test the edges — min, max, and just outside limits

~15–25 min per field

Boundary testing focuses on values at the limits of what is allowed: empty string, one character, maximum length, special characters. Most bugs live at the edges, not the middle.

Think of it like this

Like a parking garage with a 2 m height limit — test a car at 1.99 m (pass), exactly 2 m (pass), and 2.01 m (fail).

When: Forms with length limits, numeric fields, file uploads, and pagination.

How to do it — step by step

  1. 1

    Find the min and max rules (e.g. message required, email format)

  2. 2

    Test empty value, 1 character, and a very long string (500+ chars)

  3. 3

    Test special characters: <script>, emoji, accents (é, ñ)

  4. 4

    Confirm the app truncates, rejects, or accepts per requirements

Real example on this site

https://elangodev.com/contact

Message field boundaries

Test empty, 1-char, long text, and special characters

Empty

"" → should fail validation

1 char

"Hi" → may pass or fail per rules

Long text

500+ characters → no layout break

Special

<script>alert(1)</script> → safely stored/displayed

Boundary test PASSED

  • Empty message blocked with a clear error
  • Very long text does not break layout or crash the page
  • Special characters are escaped — no script runs in the browser

Boundary test FAILED

  • Single-space message accepted when it should be rejected
  • Long text overflows the container or freezes the browser
  • Script tags execute — critical security bug
Practice this method

Usability Testing

Can a real person use this without confusion?

~45 min with a volunteer or self walkthrough

Usability testing evaluates how easy and pleasant the product is to use. You observe whether labels make sense, flows feel natural, and errors are understandable — not just whether code works.

Think of it like this

Like watching someone assemble IKEA furniture — the pieces might fit, but unclear instructions cause frustration.

When: New user flows, redesigns, or when support tickets mention confusion.

How to do it — step by step

  1. 1

    Give yourself a goal without hints: 'Send a message to the site owner'

  2. 2

    Start from the homepage — can you find /contact in under 30 seconds?

  3. 3

    Read every label aloud — do they make sense without jargon?

  4. 4

    Note anywhere you hesitated, mis-clicked, or re-read instructions

Real example on this site

https://elangodev.com/

Find and use the contact form

Pretend you are a first-time visitor who needs help

Task

Send a project inquiry

Constraint

No direct URL — use nav only

Measure

Time to find form + clarity of labels

Usability test PASSED

  • Contact page found within 2 clicks from home
  • Field labels are plain language (not technical codes)
  • Error messages tell the user how to fix the problem

Usability test FAILED

  • Contact link hidden or labeled unclearly ('Reach out' with no context)
  • Submit button disabled with no explanation why
  • Success message disappears before user can read it
Practice this method

Cross-Browser Testing

Same site, different browsers — should look and work the same

~30 min (same checklist, 2+ browsers)

Cross-browser testing verifies your application works in Chrome, Firefox, Safari, and Edge. Layout engines differ — a page perfect in Chrome may break in Safari.

Think of it like this

Like printing the same photo on two printers — colors and margins should match closely enough that no one notices a difference.

When: Before major releases and after CSS or font changes.

How to do it — step by step

  1. 1

    Pick your smoke checklist (home, blog, contact)

  2. 2

    Run the exact same steps in Chrome

  3. 3

    Repeat in Firefox or Safari — compare screenshots

  4. 4

    Log any layout, font, or behavior differences

Real example on this site

https://elangodev.com/handbook

Handbook in Chrome vs Firefox

Open the same page in two browsers side by side

Chrome

Code blocks scroll correctly

Firefox

Same code blocks — no overflow?

Safari

Dark mode text still readable?

Cross-browser test PASSED

  • Navigation, forms, and content work in all tested browsers
  • No major layout shift between Chrome and Firefox
  • Fonts load and headings hierarchy looks consistent

Cross-browser test FAILED

  • Submit button visible in Chrome but cut off in Safari mobile
  • Custom font falls back to broken spacing in Firefox
  • Dark mode contrast fails in one browser only
Practice this method

Accessibility Testing

Can everyone use the site — including keyboard-only users?

~30–45 min per critical flow

Accessibility (a11y) testing ensures people with disabilities can use your product — keyboard navigation, screen readers, sufficient contrast, and meaningful labels.

Think of it like this

Like a building with ramps and elevators, not just stairs — everyone should reach the same destination.

When: Ongoing for public sites; required before launch in many organizations.

How to do it — step by step

  1. 1

    Unplug your mouse — tab through /contact using only keyboard

  2. 2

    Confirm focus ring is visible on every interactive element

  3. 3

    Check every input has a visible label or aria-label

  4. 4

    Run Lighthouse Accessibility audit in Chrome DevTools

Real example on this site

https://elangodev.com/contact

Keyboard-only contact flow

Complete the form using Tab, Shift+Tab, Enter, and Space only

Tab order

Name → Email → Message → Submit

Focus

Blue outline visible on each field

Submit

Activates with Enter or Space on button

Accessibility test PASSED

  • Full form completable without a mouse
  • Focus order matches visual layout (top to bottom)
  • Errors announced or visible next to the relevant field
  • Lighthouse accessibility score ≥ 90 (guideline, not law)

Accessibility test FAILED

  • Tab key skips the submit button entirely
  • No visible focus indicator — keyboard user is lost
  • Email field has placeholder but no accessible label
  • Errors shown only in red with no text explanation
Practice this method
Documentation

Writing test cases

Good test cases are repeatable, observable, and independent. Copy the template below into a spreadsheet or test management tool.

1. Name your test clearly
Use action + object: "Submit contact form with valid data" not "Test 1". IDs like TC-CONTACT-001 help traceability in spreadsheets or Jira.
2. List preconditions
State starting URL, login state, and test data. Another tester should not need to ask "were you logged in?"
3. One action per step
Step 3: Click Submit — not "Fill form and submit and check email." Split actions so failures pinpoint the exact step.
4. Expected result must be observable
Bad: "It works." Good: "Green toast shows 'Message sent' and form fields clear." Observable outcomes are pass/fail without debate.
5. Record actual result and evidence
On failure, capture screenshot, URL, browser version, and Console errors. Attach Network HAR only when debugging API-related UI issues.
6. Maintain a smoke suite
Keep 10–15 high-priority cases you run before every release. On elangodev.com that might be: home, blog, contact happy path, footer links, mobile nav.

Sample test case (contact form)

JSON
Test Case ID: TC-CONTACT-001
Title: Submit contact form with valid data
Priority: High
Preconditions: User is on https://elangodev.com/contact
Test Data:
  - Full name: Manual Test User
  - Email: manual-test@example.com
  - Message: Practice submission from manual testing guide.

Steps:
  1. Navigate to /contact
  2. Enter full name, email, and message
  3. Click Send / Submit

Expected Result:
  - Success confirmation appears
  - No JavaScript errors in Console
  - Network tab shows POST /api/messages with HTTP 201 (optional check)

Actual Result: [fill when executing]
Status: Pass / Fail
Tester: [your name]
Date: [YYYY-MM-DD]
DevTools

Browser tools for manual testers

Press F12 (Windows/Linux) or Option+Cmd+I (Mac) to open DevTools. These panels cover 90% of day-to-day manual QA work.

Elements (Inspector)

View HTML structure, CSS classes, and computed styles.

How: Right-click any element → Inspect. Verify buttons are real <button> or <a> tags, not unclickable divs.

Console

See JavaScript errors and warnings that break functionality.

How: Open DevTools → Console. Reload the page. Red errors during normal use are bugs worth reporting.

Network

Watch HTTP requests when forms submit or pages load data.

How: Network tab → submit contact form → find POST /api/messages. Check status 201 and response JSON.

Device toolbar

Simulate phone and tablet screen sizes.

How: Toggle device mode (Ctrl+Shift+M). Test 375px, 768px, and 1280px widths on key pages.

Lighthouse (Chrome)

Quick accessibility, performance, and SEO signals — not a full QA substitute.

How: DevTools → Lighthouse → run Accessibility audit on /contact and /blog.

Application → Cookies

Verify cookie consent and session behavior.

How: After accepting or rejecting cookies, confirm consent cookie is set and analytics behave per policy.

Hands-on practice

Practice scenarios on elangodev.com

Real pages, real forms — use fake test data only. Document pass/fail in your test case template as you go.

Highfunctional

Contact form — happy path

The most common real-world manual test: fill a public form and confirm success feedback. Use clearly fake test data only.

Open /contact

Preconditions

Browser on https://elangodev.com/contact. Cookie banner dismissed if shown.

Steps

  1. Enter full name: Manual Test User
  2. Enter email: manual-test@example.com
  3. Enter message: Practice message from the manual testing guide.
  4. Click the submit button once.

Expected results

  • Success message or confirmation appears
  • No uncaught errors in the browser Console
  • Form does not leave the user stuck with a spinning button forever
ConsoleNetwork

Try next

Try submitting with an empty email to practice negative testing.

https://elangodev.com/contact
ElementsConsoleNetwork
Open DevTools (F12) and follow the steps on the left
Highnegative

Contact form — validation errors

Negative testing ensures bad input is rejected with helpful messages, not silent failure or server errors.

Open /contact

Preconditions

On /contact with empty or invalid fields ready.

Steps

  1. Leave all fields empty and click submit.
  2. Note inline or toast validation messages.
  3. Enter invalid email (e.g. not-an-email) and submit.
  4. Enter valid email but leave message empty and submit.

Expected results

  • User sees clear validation feedback for each invalid case
  • No success message when validation fails
  • No HTTP 500 in Network tab for client-side validation cases
ConsoleNetwork
https://elangodev.com/contact
ElementsConsoleNetwork
Open DevTools (F12) and follow the steps on the left
Highfunctional

Blog listing and article read

Content sites need reliable navigation from index to article and back. Test reading flow and shareable URLs.

Open /blog

Preconditions

At least one published blog post exists on the site.

Steps

  1. Open /blog and confirm article cards or list loads.
  2. Click the first visible article title or Read link.
  3. Confirm article title, body, and metadata render.
  4. Use browser Back to return to the listing.
  5. Copy article URL, open in a new tab — page should load directly.

Expected results

  • Listing shows titles and excerpts without layout break
  • Article page loads with readable typography
  • Back navigation returns to blog index without broken state
  • Direct URL works (deep linking)
ElementsConsole

Try next

Try a non-existent slug manually in the URL to confirm a proper 404 page.

https://elangodev.com/blog
ElementsConsoleNetwork
Open DevTools (F12) and follow the steps on the left
Mediumfunctional

Handbook long-form content

Technical documentation pages stress scrolling, headings, code blocks, and anchor links.

Open /handbook

Preconditions

Stable internet; /handbook loads fully.

Steps

  1. Open /handbook and scroll through multiple sections.
  2. Click an in-page table-of-contents or anchor link if present.
  3. Select and copy a code snippet — formatting should remain readable.
  4. Toggle dark mode if available and re-check contrast.

Expected results

  • Headings create a clear hierarchy (H1 → H2 → H3)
  • Code blocks do not overflow horizontally without scroll
  • Anchor jumps scroll to the correct section
  • Dark mode does not make text unreadable
ElementsLighthouse
https://elangodev.com/handbook
ElementsConsoleNetwork
Open DevTools (F12) and follow the steps on the left
Mediumnegative

Login page — UI and validation only

Test the login form UI without real credentials. Do not brute-force accounts or use production passwords.

Open /login

Preconditions

On /login. Use fake credentials only.

Steps

  1. Submit with empty email and password — note validation.
  2. Enter invalid email format and submit.
  3. Enter valid-looking fake credentials — note error message (expected failure).
  4. Check Forgot password link navigates to /forgot-password.

Expected results

  • Empty submit shows validation, not a blank screen
  • Invalid login shows a user-safe error (no stack traces)
  • Password field masks input
  • Forgot password link works
ConsoleNetwork

Try next

Never test with real user passwords or credential stuffing.

https://elangodev.com/login
ElementsConsoleNetwork
Open DevTools (F12) and follow the steps on the left
Mediumcompatibility

Responsive layout spot check

Mobile users are a large share of traffic. Resize or emulate devices on high-traffic pages.

Open /

Preconditions

DevTools device toolbar enabled.

Steps

  1. Set viewport to 390×844 (mobile). Open /, /contact, /blog.
  2. Open mobile nav menu (hamburger) if present — all items reachable.
  3. Set viewport to 768×1024 (tablet) — no overlapping text.
  4. Set viewport to 1280×800 (desktop) — content uses width well.

Expected results

  • No horizontal scrollbar on body at standard breakpoints
  • Tap targets at least ~44px tall on mobile nav and buttons
  • Hero and footer remain readable without zooming
Device toolbarElements
https://elangodev.com/
ElementsConsoleNetwork
Open DevTools (F12) and follow the steps on the left
Smoke suite

Public pages inventory

Pages marked for smoke testing should be checked before every release. Auth and legal pages follow lighter schedules unless they change.

Quick smoke checklist (6 pages)

/ → /about → /services → /blog → /handbook → /contact

PathLabelCategorySmoke
/HomeCoreYes
/aboutAboutCoreYes
/authorAuthorCoreNo
/servicesServicesCoreYes
/blogTechnical BlogContentYes
/handbookEngineering HandbookContentYes
/contactContactCoreYes
/api-testingAPI Testing GuideLearningNo
/manual-testingManual Testing GuideLearningNo
/npmNPM PackagesResourcesNo
/privacyPrivacy PolicyLegalNo
/termsTerms of ServiceLegalNo
/editorialEditorial PolicyLegalNo
/site-mapSite MapUtilityNo
/loginLoginAuthNo
/signupSign upAuthNo
Compatibility

Cross-browser checklist

Run this list in Chrome plus one other browser before calling a release ready.

  • Homepage loads without layout shift or missing fonts
  • Contact form submits successfully in Chrome and Firefox
  • Blog article typography readable in Safari
  • Dark mode (if used) consistent across browsers
  • Mobile menu opens and closes in Edge mobile emulation
  • No Console errors on first load of /handbook
  • Footer social icons visible and clickable
  • Print preview of /privacy is readable (optional)
A11y

Accessibility manual checks

Automated Lighthouse scans help, but keyboard-only navigation and logical focus order require human verification.

  • Tab key moves focus through /contact form fields in logical order
  • Visible focus ring on buttons and links
  • Images that convey meaning have alt text
  • Form inputs have associated <label> or aria-label
  • Color contrast sufficient in light and dark themes
  • Page has one clear <h1> per route
  • Skip-to-content link or landmark regions (header, main, footer)
  • No information conveyed by color alone (errors also use text)
Defects

How to file a bug report

Developers fix bugs faster when reports are specific and reproducible. Use this template in Jira, GitHub Issues, or a shared doc.

Bug report template

JSON
Bug ID: BUG-001
Title: [short summary — e.g. Contact submit button overlaps footer on mobile]
Severity: Minor / Major / Critical / Blocker
Environment:
  - URL: https://elangodev.com/contact
  - Browser: Chrome 124 / Firefox 125 / Safari 17
  - OS: Windows 11 / macOS 14 / Ubuntu 22.04
  - Viewport: 390×844 (iPhone 14) or 1920×1080

Steps to Reproduce:
  1. Open /contact on mobile viewport
  2. Scroll to bottom of form
  3. Observe submit button position

Expected Result:
  Submit button stays visible above footer with adequate spacing.

Actual Result:
  Button is partially hidden behind footer; user cannot tap it.

Attachments: screenshot-001.png, console-log.txt (if errors)
Notes: Reproduces only below 400px width.

Ethics note: Report security vulnerabilities responsibly through proper channels. Do not test production systems you do not own without permission.

Defect severity levels

Severity describes user impact, not how hard the fix is. Align with your team on definitions early.

Blocker

Core flow completely broken; release must not ship.

Example: Contact form submit returns 500 for every user; homepage does not load.

Critical

Major feature unusable; no reasonable workaround.

Example: Login always fails for valid credentials; blog articles show blank content.

Major

Important feature impaired; workaround exists but is painful.

Example: Dark mode toggle missing on mobile; contact form works only after refresh.

Minor

Cosmetic or low-impact issue; fix when convenient.

Example: Slight misalignment of footer icons; typo in non-critical helper text.

Trivial

Nitpick; no user impact.

Example: Extra pixel of padding on desktop-only badge.

Continue learning

Manual testing pairs well with API verification and deeper engineering reading.

API Testing Guide

When the UI looks wrong because of server responses, verify the API with Postman. Learn GET, POST, status codes, and sandbox endpoints.

Read more about API Testing Guide

Engineering Handbook

Deeper technical context on HTTP, CORS, authentication, and how this site is built — useful when bugs span front end and back end.

Read more about Engineering Handbook
Pitfalls

Common mistakes

Testing only the happy path

Valid input is necessary but not sufficient. Always try empty fields, wrong formats, double-submit, and back-button mid-flow.

Vague bug reports

"Contact broken" does not help developers. Include exact URL, steps, expected vs actual, browser, and screenshots.

Ignoring the Console

A page can look fine while JavaScript throws errors. Open Console on every serious test session.

Testing in one browser only

Safari and Firefox still surface layout and date-picker bugs Chrome hides. Spot-check at least two engines before sign-off.

Using production data carelessly

Contact and message APIs write real data. Use fake emails like test@example.com and obvious test messages. Never spam forms.

Confusing UI bugs with API bugs

If the UI shows success but Network shows 500, report both. If Postman returns 200 but the form fails, suspect front-end validation or CORS — see the API Testing Guide.

Troubleshooting

When testing gets confusing

I cannot reproduce a reported bug
Match the reporter's browser, viewport, and cache state. Try incognito. Ask for a screen recording or HAR file. Clear cookies if the issue involves consent or auth.
Flaky test — passes sometimes, fails others
Look for race conditions: slow network, animations, or double-click submit. Throttle Network to Slow 3G in DevTools and retry.
Page looks different from staging vs production
Compare build versions, feature flags, and CDN cache. Hard refresh (Ctrl+Shift+R) bypasses cached CSS.
Form submits but nothing appears to happen
Check Network for failed POST, Console for errors, and whether a toast appears off-screen on mobile. Verify you are not blocked by ad blockers intercepting analytics only.

Frequently asked questions

Quick answers for beginners starting a manual QA learning journey.

What is manual testing?
Manual testing is when a human interacts with software to find defects — clicking, typing, reading screens, and comparing behavior to requirements — without running automated test scripts. It is essential for usability, visual quality, and exploratory discovery.
Do I need coding skills to do manual testing?
No. Entry-level manual QA focuses on attention to detail, clear communication, and structured test cases. Basic browser DevTools help but are learnable in an afternoon. Coding becomes useful later for test automation.
What is the difference between manual and automated testing?
Manual testing relies on human judgment and exploration. Automated testing runs scripts (Selenium, Playwright, Cypress) on a schedule. Automation is fast for regression; manual testing excels at new features, UX, and ad-hoc exploration.
What should I test first on a new website?
Start with a smoke test: homepage loads, main navigation works, one critical user journey (contact, signup, or checkout) succeeds, and there are no obvious Console errors. Then expand into negative cases and cross-browser checks.
How do I practice manual testing on elangodev.com?
Use the practice scenarios on this page. Begin with the contact form happy path and validation cases, then run the blog and navigation scenarios. Document results in the test case template and file practice bugs with the bug report template.
What is a test case?
A test case documents ID, title, preconditions, steps, test data, expected result, and actual result. It should be repeatable by someone who did not write it.
What is negative testing?
Negative testing uses invalid or boundary input — empty fields, malformed email, extremely long strings — to verify the application handles errors gracefully instead of crashing or corrupting data.
What tools do manual testers use?
Browsers (Chrome, Firefox, Safari), DevTools (Elements, Console, Network, device mode), screenshot tools, spreadsheets or TestRail/Jira for cases, and optionally Lighthouse for accessibility signals.
How do I write a good bug report?
Include a short title, severity, environment (URL, browser, OS, viewport), numbered steps to reproduce, expected vs actual result, and screenshots or videos. See the bug report template on this page.
Is manual testing enough for production apps?
Rarely alone. Serious products combine manual exploration with automated regression, API tests, monitoring, and staged rollouts. Manual testing remains vital for release sign-off and customer-facing polish.
Can I test the login page without an account?
Yes — test UI validation, empty submit, invalid email format, and error messages with fake credentials. Do not attempt credential stuffing or password guessing.
How does manual testing relate to the API Testing Guide?
Manual testing checks what users see. API testing checks server responses directly. When a form fails, use Network tab in the browser first, then Postman from the API Testing Guide to isolate front-end vs back-end issues.

Pair UI testing with API testing

When a form fails, check the Network tab — then verify the API directly with Postman using the API Testing Guide.

API Testing Guide Engineering Handbook