Manual Testing Interview
Questions and answers with examples.

Manual testing is the process of testing software by hand, without automation tools — executing test cases, observing the actual result, and comparing it with the expected result. The tester plays the role of an end user.

Manual testing is preferred when:

• The feature is new and changing frequently — automation would be rewritten constantly.
• The test needs human judgement — usability, visual design, exploratory testing.
• The test is a one-off — automation cost is not justified.
• Short project timelines where building a framework would take too long.

Manual testing is also used to design the test cases that later get automated. It never goes away completely — every automation suite starts with manual exploration.

Verification checks whether the product is being built correctly — it answers "Are we building the product right?" It is done during development through reviews, walkthroughs, inspections and static analysis.

Validation checks whether the right product is being built — it answers "Are we building the right product?" It is done after development through actual testing — unit, integration, system and acceptance testing.

1. Testing shows the presence of defects, not their absence. Testing reduces the probability of undiscovered defects but cannot prove there are none.
2. Exhaustive testing is impossible. You cannot test every combination of inputs and preconditions — use risk-based prioritisation.
3. Early testing saves time and money. Defects found in requirements cost far less to fix than defects found in production.
4. Defect clustering. A small number of modules usually contain most of the defects — the Pareto principle applies.
5. Pesticide paradox. If the same tests run repeatedly, they stop finding new bugs. Test cases must be reviewed and updated regularly.
6. Testing is context dependent. An e-commerce site is tested differently from a banking application.
7. Absence-of-errors fallacy. A bug-free product that does not meet user needs is still useless.

A test strategy is a high-level document that defines the overall testing approach for an organisation — what types of testing will be done, at what level, and with what tools. It is usually stable across projects.

A test plan is project-specific. It covers scope, objectives, resources, schedule, deliverables, risks and entry/exit criteria for a particular release.

A test scenario is a one-line statement of what to test — "Verify login with valid credentials." One scenario can have many test cases.

1. Unit testing — testing individual components or functions in isolation. Usually done by developers.
2. Integration testing — testing how two or more units work together. Approaches: top-down, bottom-up, sandwich, big-bang.
3. System testing — testing the complete, integrated application against the requirements. Done by the testing team.
4. Acceptance testing — testing whether the system meets business needs. Types: User Acceptance Testing (UAT), Alpha, Beta, Operational Acceptance Testing.

Manual testers are most involved in system and acceptance testing, and often support integration testing.

Black box testing — the tester has no knowledge of the internal code. Testing is based on inputs and expected outputs. Manual functional testing is black box testing.

White box testing — the tester has full knowledge of the internal code and tests paths, branches, conditions and loops. Usually done by developers or automation engineers.

Grey box testing — partial knowledge of the internals. The tester knows the database schema or API structure and uses that knowledge to design better tests. Most manual testing with SQL checks and API calls is grey box.

A test case is a set of steps with expected results that verifies one specific behaviour of the application.

Standard fields:

• Test Case ID — unique identifier, e.g. TC-LOGIN-001
• Test Scenario — the feature being tested
• Test Case Description — what this case verifies
• Preconditions — what must be true before the test starts
• Test Steps — numbered actions
• Test Data — the inputs used
• Expected Result — what should happen
• Actual Result — what actually happened
• Status — Pass / Fail / Blocked / Not Run
• Severity / Priority — if the test fails
• Comments — notes or defect IDs

A test scenario is a high-level statement of what to test. It answers "What should I test?" and is usually one line.

A test case is the detailed set of steps, data and expected results to test that scenario. It answers "How do I test it?"

One scenario can have many test cases. Test scenarios are written first, then expanded into test cases.

Positive testing checks that the system works correctly with valid inputs. Example: login with a valid email and correct password should land on the dashboard.

Negative testing checks that the system handles invalid inputs gracefully. Example: login with a wrong password should show an error message, not crash or log the user in.

Both are essential. Positive testing confirms the happy path works; negative testing confirms the system is robust when users do unexpected things.

Boundary Value Analysis is a test design technique that focuses on the boundaries of input ranges, because defects cluster at the edges. For a range of 1 to 100, you test 0, 1, 2, 99, 100 and 101.

BVA finds off-by-one errors that equivalence partitioning alone misses.

Equivalence Partitioning divides input data into groups or classes where all values in a class should behave the same way. You test one value from each class instead of every possible value.

This reduces the number of test cases from hundreds to three, while still covering all behaviours.

A Requirement Traceability Matrix (RTM) is a table that maps each requirement to the test cases that cover it. It proves that every requirement has been tested and that no test case exists without a requirement.

The RTM is used in audits, to measure test coverage, and to show the client exactly what has been verified.

An error is a human mistake — a developer types the wrong operator or misreads a requirement.

A defect (also called a fault or bug) is the flaw in the code or design that results from the error. It is what the tester finds.

A failure is what happens when the defect is executed — the system behaves incorrectly.

In everyday testing, bug and defect are used interchangeably. Strictly speaking, a defect is the flaw and a failure is the visible symptom.

Severity is the technical impact of the bug on the system — how badly it breaks functionality.

Priority is the business urgency of fixing it — how soon it must be fixed.

The bug life cycle is the sequence of states a defect passes through from discovery to closure.

A good bug report includes:

• Bug ID and a clear, specific title — "Balance not deducted after ATM withdrawal", not "ATM problem".
• Environment — browser, OS, device, build version, test environment.
• Preconditions — account with ₹20,000 balance, card inserted, PIN entered.
• Steps to reproduce — numbered, exact, no assumptions.
• Expected result — what should have happened.
• Actual result — what actually happened.
• Severity and priority — with justification.
• Attachments — screenshot, video, log file, API response.
• Assignee — the right developer or team.

The test: could a developer fix this without asking you a single question? If not, the report is incomplete.

Retesting verifies that a specific bug has been fixed. You run the same test case that failed, with the same data, and check that it now passes.

Regression testing verifies that the fix did not break anything else. You run a broader set of tests that cover the affected area and related functionality.

Smoke testing is a quick check that the critical functionality of a new build works. If smoke fails, the build is rejected and not tested further. It answers "Is the build stable enough to test?"

Sanity testing is a narrow, deep check of a specific area after a small change. It answers "Does this particular fix work and did it break this specific area?"

Alpha testing is done at the developer's site by internal teams before the product is released to external users. It often involves both developers and testers.

Beta testing is done at the customer's site by real users who are not part of the organisation. It happens after alpha testing and before the final release. Feedback from beta users drives final fixes.

Alpha is controlled and internal; beta is uncontrolled and real-world.

A defect is something that does not work as specified in the requirements. The system is supposed to do X, but it does Y.

An enhancement is a request for something that was never specified — a new feature, a better UX, or an improvement to an existing feature. The current behaviour is not wrong; it could just be better.

A Decision Table is a test design technique for business rules that depend on multiple conditions. It lists every combination of conditions and the expected action for each combination.

Use it when the logic has two or more conditions and you need to make sure every combination is tested. It is common in insurance, banking and e-commerce rules.

State Transition testing is used when the system behaves differently depending on its current state. You draw a state diagram and test every valid and invalid transition.

Example — an order in an e-commerce system:

• Cart → Placed (valid)
• Placed → Shipped (valid)
• Shipped → Delivered (valid)
• Delivered → Returned (valid)
• Delivered → Placed (invalid — should be rejected)
• Cancelled → Shipped (invalid — should be rejected)

Testing the invalid transitions is where you find the most bugs — systems often do not guard against illegal state changes.

Error Guessing is an experience-based technique where the tester uses intuition about where bugs are likely to be. It is not formal — it comes from having tested similar systems before.

Common guesses:

• What happens if I enter special characters in a name field?
• What if I paste a very long string into a short input?
• What if I click the submit button twice quickly?
• What if I upload a file with an unsupported extension?
• What if I leave a field blank that is supposed to be optional?

Error guessing is most useful when you have domain experience. It complements formal techniques — it does not replace them.

The number depends on risk, complexity and the cost of failure — not on a fixed formula.

Practical approach:

1. List the scenarios — every path the user can take through the feature.
2. Apply test design techniques — equivalence partitioning and BVA reduce the input combinations to a manageable set.
3. Add negative cases — invalid inputs, empty fields, boundary violations.
4. Add integration cases — how the feature interacts with other features.
5. Prioritise by risk — test the payment path thoroughly, the help tooltip lightly.

For a login page, three to five cases is usually enough: valid login, invalid password, empty fields, unregistered email, password length boundary.

A test execution report summarises what was tested, what passed, what failed, and what is still open. It is shared with the team and stakeholders before release.

It should contain:

• Build number and environment tested
• Test period and who tested
• Total test cases, passed, failed, blocked, not run
• Defect summary by severity and status
• Areas not tested and why
• Risks and open issues
• Recommendation — release or hold

Selection criteria:

• Business critical paths — login, payment, order placement. These always run.
• Areas changed in this release — code changes are the most likely source of new bugs.
• Areas connected to the change — a change in the cart may affect checkout and order history.
• Previously defective areas — modules with a history of bugs should be retested.
• High-traffic features — the pages most users touch.
• Integration points — payment gateways, shipping APIs, third-party services.

Keep the regression suite lean enough to run every release. If it takes three days, it will not be run consistently.

Compatibility testing checks that the application works correctly across different browsers, operating systems, devices, screen sizes and network conditions.

Dimensions to cover:

• Browsers — Chrome, Firefox, Edge, Safari, and their recent versions
• Operating systems — Windows, macOS, Android, iOS
• Devices — desktop, tablet, mobile; different screen resolutions
• Network — 4G, 3G, slow connection, offline behaviour
• Hardware — printers, scanners, payment terminals where relevant

Prioritise based on your analytics — test the browsers and devices your users actually use, not every combination that exists.

Cross-browser testing is a subset of compatibility testing focused on browsers.

What to check:

• Layout — alignment, spacing, overflow, broken images
• Fonts and text — rendering, wrapping, truncation
• JavaScript behaviour — date pickers, dropdowns, validation messages
• Form controls — file upload, number spinners, date inputs behave differently across browsers
• CSS features — flexbox, grid and animations may render differently
• Third-party widgets — payment iframes, chat widgets, maps

Common bugs: a button that works in Chrome but not Safari, a date picker that shows the wrong format in Firefox, a fixed header that overlaps content on mobile.

Usability testing checks how easy and pleasant the application is to use. It is about the user's experience, not just whether the feature works.

What to look for:

• Can a new user complete the main task without help?
• Are error messages clear and actionable?
• Is the navigation logical?
• Are buttons and links clearly clickable?
• Is the text readable — font size, contrast, line length?
• Does the app work on a small screen without horizontal scrolling?
• Are loading states visible, so the user knows something is happening?

Usability issues are often reported as enhancements rather than defects, but they affect real user retention.

Localisation testing checks that the application works correctly for a specific locale — language, date format, currency, number format and cultural conventions.

What to check:

• Translation — no untranslated strings, no awkward phrasing, no text overflow when the translated word is longer
• Date and time — DD/MM/YYYY vs MM/DD/YYYY, time zones, daylight saving
• Currency — correct symbol, decimal separator (₹1,00,000 vs $100,000), rounding rules
• Address formats — some countries need state, others need postal code first
• Name formats — not every culture has first and last name in that order
• Right-to-left languages — Arabic and Hebrew need mirrored layouts
• Images and icons — culturally appropriate, no text baked into images

Key areas for manual mobile testing:

• Installation and uninstallation — install from the store, upgrade, uninstall cleanly
• Network handling — Wi-Fi to 4G switch, offline mode, slow network, airplane mode
• Interruptions — incoming call, SMS, low battery alert, app backgrounded and resumed
• Orientation — portrait and landscape layouts
• Gesture support — tap, long press, swipe, pinch, scroll
• Device compatibility — different screen sizes, resolutions, OS versions
• Battery and memory — does the app drain battery or leak memory over time?
• Permissions — camera, location, contacts, notifications
• Push notifications — delivered when app is open, backgrounded, or closed

Mobile testing also has platform-specific guidelines — Apple's Human Interface Guidelines and Google's Material Design.

As a manual tester, you use SQL to confirm that the UI action actually wrote the correct data to the database. You are not modifying data — you are verifying it.

Common checks:

• Insert — after registering a user, query the users table and check that the email, name and hashed password are correct.
• Update — after changing a profile, query the table and check the updated values and the timestamp.
• Delete — after deleting a record, confirm it is gone or flagged as inactive.
• Referential integrity — deleting a user should handle their orders correctly, not leave orphans.
• Audit fields — created_by, created_at, modified_by, modified_at are populated correctly.

SELECT user_id, email, full_name, created_at
FROM users
WHERE email = 'ravi@example.com';

-- expected: one row with the name and today's timestamp

Always test with read-only credentials. Never modify production data during testing.

Even as a manual tester, basic API testing with Postman is a valuable skill. It lets you verify backend behaviour independently of the UI.

What to check:

• Status code — 200 for success, 201 for created, 400 for bad request, 401 for unauthorized, 404 for not found, 500 for server error.
• Response body — correct fields, correct values, correct data types.
• Response time — acceptable performance.
• Headers — content type, CORS headers, caching headers.
• Authentication — calling without a token should return 401.
• Validation — sending invalid data should return a clear error, not a 500.
• Idempotency — calling the same GET twice should not change state.

POST https://api.example.com/v1/users
Content-Type: application/json

{
  "email": "ravi@example.com",
  "name": "Ravi Raj"
}

// expected: 201 Created with the new user_id

In Agile, testing is continuous, not a phase at the end. The manual tester is involved from the first day of the sprint.

Typical activities:

• Sprint planning — review acceptance criteria, ask questions about edge cases, estimate testing effort.
• Backlog refinement — identify test scenarios early, flag requirements that are not testable.
• During the sprint — write test cases as the developer builds, test features as they become available, log defects immediately.
• Daily standup — report progress, blockers and any quality risks.
• Sprint review — demonstrate tested features and share quality status.
• Retrospective — discuss what testing went well and what caused delays.

The Agile tester also helps define the definition of done — "tested, no open critical bugs, regression passed."

Estimation combines the size of the work with the risk and complexity of the features.

Practical approach:

1. Break down by feature — not one number for the whole release.
2. Estimate test case creation — roughly 15–30 minutes per test case for a familiar feature.
3. Estimate execution — roughly 10–20 minutes per test case for the first run.
4. Add regression time — the existing suite plus new tests.
5. Add a buffer — 20–30% for retesting, defect logging and unexpected issues.
6. Adjust for risk — high-risk features get more cycles.

Base estimates on historical data from previous releases — how long did similar features actually take? Without history, estimates are guesses.

Step 1 — Check your own steps first. Did you leave out a precondition, a specific browser, or a data state that the developer does not have?

Step 2 — Reproduce it again with the exact environment details — browser version, build number, user role, test data. Record a video if possible.

Step 3 — If it reproduces, add the missing details to the bug report and reassign. Most "not reproducible" cases are missing environment information.

Step 4 — If it does not reproduce consistently, mark it as intermittent and add what you know — frequency, conditions, screenshots from the original occurrence.

Step 5 — If the developer still disagrees, escalate to the test lead and product owner. Present the evidence calmly. The goal is to resolve the bug, not to win the argument.

Step 6 — If the bug is genuinely not reproducible and low impact, close it as "not reproducible" but document it in case it reappears.

Step 1 — Gather facts immediately. What is broken, who is affected, how many users, and is there a workaround?

Step 2 — Communicate. Notify the product owner, development lead and support team. Do not wait until you have a root cause.

Step 3 — Reproduce in a staging environment with production-like data if possible.

Step 4 — Log a bug with full details — production environment, user impact, steps to reproduce, logs, screenshots.

Step 5 — Work with the team on a fix. Once fixed, test the fix in staging, then verify in production after deployment.

Step 6 — Add a regression test case so the same defect cannot slip through again.

Step 7 — In the retrospective, ask why the existing test suite missed it — was the scenario untested, untestable, or tested with the wrong data?

Testing never proves the absence of bugs, so you stop based on agreed exit criteria, not on a feeling.

Common exit criteria:

• Test case execution — 100% of planned test cases run, or all critical/high-priority ones.
• Defect status — no open critical or high-severity defects. Medium and low defects have a documented plan.
• Defect discovery rate — the number of new bugs found per day has dropped to near zero.
• Coverage — all requirements are covered in the traceability matrix.
• Regression — the regression suite has passed on the final build.
• Risk acceptance — the product owner accepts the remaining known risks.

The decision to release is a business decision. Your job is to provide clear evidence and a recommendation.

A test plan documents the scope, approach, resources, schedule and risks for testing a specific release. The most important parts are the entry and exit criteria because they define when testing starts and when it stops.

1. Read the requirements — user story, acceptance criteria, design mockups, API documentation.
2. Talk to the product owner — what is the business goal? What would a failure look like to a user?
3. Talk to the developer — what changed, what is the riskiest part, what did they not test?
4. Explore the feature manually first — before writing formal cases, use the feature like a real user. This finds obvious issues fast.
5. Design test cases using techniques — scenarios, equivalence partitioning, BVA, state transitions.
6. Include negative and edge cases — invalid inputs, empty states, maximum values, special characters.
7. Test integrations — how does this feature interact with existing features?
8. Test non-functional aspects — performance under load, usability, compatibility.

Risk-based testing prioritises testing effort based on the likelihood and impact of failure. High-risk areas get more testing; low-risk areas get less.

Risk = Probability of failure × Impact of failure

How to apply it:

1. Identify risks — brainstorm with the team. What could break? What is new? What is complex? What has failed before?
2. Score each risk — probability (low/medium/high) and impact (low/medium/high).
3. Prioritise — high-probability, high-impact risks get tested first and most thoroughly.
4. Allocate effort — more test cases, more test data variations, more regression cycles for high-risk areas.
5. Review — risks change as the project progresses.

Risk-based testing is how you make testing decisions when you do not have time to test everything.

Testing against third-party services has three layers:

1. Integration testing with the real service — test in a sandbox environment provided by the third party. Verify the happy path, error responses, timeouts and authentication.
2. Testing your error handling — what does your app do when the third party is slow, returns an error, or is completely down? This is where most bugs are.
3. Contract testing — verify that your app sends the expected request format and handles the expected response format. If the third party changes their API, contract tests catch it.

For manual testing, use mock services or stubs when the real service is unreliable or expensive. Test the real service during integration testing phases.

Coverage is not about running every test case — it is about knowing what you have tested and what you have not.

Methods to track coverage:

• Requirements traceability matrix — every requirement maps to at least one test case. If a requirement has no test case, it is a gap.
• Test case coverage — how many test cases have been executed? But executed is not the same as passed.
• Defect coverage — are the same areas failing repeatedly? That suggests inadequate testing.
• Risk coverage — are the high-risk areas tested thoroughly?
• Code coverage — if you have access, statement and branch coverage tell you what code paths are not tested. Manual testers usually rely on developers for this.

The honest answer is that coverage is never 100%. The goal is to know your gaps and communicate them.

A test lead is focused on the technical execution of testing. They review test cases, assign testing tasks, monitor defect quality, mentor testers, and report daily status.

A test manager is focused on the broader management aspects. They own the test strategy, manage the budget and resources, handle stakeholder communication, and make release recommendations.

In smaller teams, the same person may do both roles.

Positive cases:

• Login with valid email and valid password → dashboard loads
• Login with valid email and password containing special characters
• Remember me checkbox keeps the session after browser restart

Negative cases:

• Login with valid email and wrong password → error message
• Login with unregistered email → error message
• Login with empty email field → validation message
• Login with empty password field → validation message
• Login with both fields empty → validation message
• Login with invalid email format (no @) → validation message
• Login with password shorter than 8 characters → validation message
• Login with incorrect password 5 times → account locks

UI and usability cases:

• Password field masks the input
• Tab order moves logically through the form
• Login button is disabled until both fields have input (if that is the requirement)

Security cases:

• Password is not visible in the page source or network tab
• Login page redirects to dashboard if already logged in
• Session expires after the configured timeout

Positive cases:

• Upload a valid file with an allowed extension → file is accepted
• Upload a file at the exact maximum allowed size
• Upload a file just below the maximum size
• Upload a file with a long but valid filename
• Cancel the upload mid-way and verify the file is not saved
• Upload the same file twice — is it accepted or does it show a duplicate warning?

Negative cases:

• Upload a file with a disallowed extension (.exe, .bat) → rejected with a clear error
• Upload a file above the maximum size → rejected with a clear error
• Upload a zero-byte file → rejected
• Upload a file with no extension → rejected
• Upload a corrupted file → rejected gracefully
• Upload a file with special characters in the name

Edge cases:

• Upload when the server is slow — does the progress bar behave correctly?
• Upload on a mobile browser — does the file picker work?
• Upload multiple files at once if the feature supports it

Cart stage:

• Add item to cart, verify cart count and subtotal
• Add multiple items, verify total is correct
• Remove an item, verify the total updates
• Change quantity, verify price recalculates
• Apply a valid discount code → price reduces correctly
• Apply an invalid or expired discount code → clear error
• Proceed with an empty cart → blocked with a message

Checkout stage:

• Enter a valid shipping address → accepted
• Enter an incomplete address → validation error
• Select a different shipping method → cost updates
• Log in during checkout → cart is preserved

Payment stage:

• Pay with a valid card → order confirmation
• Pay with a declined card → clear error, order not placed
• Pay with an expired card → rejected
• Close the payment window mid-transaction → order not placed, no charge
• Refresh the confirmation page → does not place a duplicate order

Happy path:

• Enter a registered mobile number → OTP is sent
• Enter the correct OTP within the validity period → login succeeds
• Resend the OTP → a new OTP is sent and the old one is invalidated

Negative cases:

• Enter an unregistered mobile number → error, no OTP sent
• Enter a wrong OTP → error message with remaining attempts
• Enter the OTP after the validity period → error, ask to resend
• Enter an OTP with fewer or more than the required digits → validation error
• Enter a previously used OTP → rejected
• Enter wrong OTP 3 times → account temporarily locked

Edge cases:

• Request multiple OTPs quickly → only the latest is valid
• Request an OTP when the SMS gateway is slow → does the UI show a loading state?
• Try to brute-force a 4-digit OTP → rate limiting should block it

Step 1 — Reproduce with a simple, known search term — for example, "laptop". If that works, the issue is with the specific query. If not, the search feature is broken.

Step 2 — Try a single word, a phrase, and a misspelled word to test the search algorithm's behaviour.

Step 3 — Check whether search is case-sensitive, whether it handles special characters, and whether it searches all relevant fields (title, description, tags).

Step 4 — Check the database directly — does the data exist? If the product is in the database but search does not find it, the issue is the search index or query.

Step 5 — Check the API response in Postman — does the backend return the correct results? If the API is correct but the UI is wrong, the bug is in the frontend.

Step 6 — Log the bug with the exact search term, the expected results, the actual results, the database evidence, and the API response.

Step 1 — Stay calm and collaborative. "Works on my machine" usually means the environments differ, not that either person is wrong.

Step 2 — Compare environments. Browser version, operating system, build number, test data, user role, database state.

Step 3 — Reproduce on the developer's machine if possible. If it passes there, capture the difference.

Step 4 — Add the missing environment details to the bug report and reassign.

Step 5 — If the bug only happens on a specific configuration, mark it as configuration-specific. That is still a bug if that configuration is supported.

Step 6 — If needed, involve the test lead and agree on the correct test environment for the feature.

Step 1 — Run smoke tests first. If the build is broken, testing stops there.

Step 2 — Focus on what changed in this release. Code changes are the most likely source of new bugs.

Step 3 — Test the critical business paths — login, payment, order placement. These must work.

Step 4 — Run the core regression suite — the tests for features connected to the changes.

Step 5 — Test high-risk areas identified by the team, even if they did not change.

Step 6 — Skip low-risk, unchanged features. Document what you did not test so the team knows the gaps.

Step 7 — Report clearly: what passed, what failed, what was not tested, and your release recommendation.

Step 1 — Categorise the fields: mandatory vs optional, text vs number vs dropdown vs date, simple vs conditional (fields that appear based on another field's value).

Step 2 — Test each mandatory field with valid data to confirm the form submits.

Step 3 — Test each mandatory field with empty data to confirm validation appears.

Step 4 — Apply equivalence partitioning and BVA to numeric and text fields — do not test every possible value, test representative values and boundaries.

Step 5 — Test conditional fields — when the condition is met, does the field appear and become mandatory if required?

Step 6 — Test the form as a whole — submission, save-as-draft, cancel, browser back button, refresh mid-entry.

Step 7 — Test field interactions — does filling field A auto-populate field B, and is that correct?

Valid dates:

• Select today's date
• Select a past date (if allowed)
• Select a future date (if allowed)
• Type a valid date in the text field

Boundary dates:

• Minimum allowed date — is it selectable?
• Maximum allowed date — is it selectable?
• One day before the minimum → should be blocked
• One day after the maximum → should be blocked

Invalid inputs:

• 31 February → should show an error or auto-correct
• 29 February in a non-leap year → error
• Date in the wrong format → validation error
• Letters in the date field → validation error
• Empty date on a mandatory field → validation error

UI behaviour:

• Month navigation works forward and backward
• Year dropdown allows selecting the correct range
• Date picker is usable on mobile and with keyboard only
• Date format matches the locale

Step 1 — Do not ignore it. Intermittent bugs are still bugs.

Step 2 — Record everything you know: when it happened, what you were doing, the environment, how many times out of how many attempts.

Step 3 — Look for a pattern. Does it happen only on a slow network? Only with a specific data set? Only when another test has run first?

Step 4 — Attach whatever evidence you have: screenshots, console logs, network logs, video.

Step 5 — Report it as intermittent, with the frequency — "happened 3 out of 10 attempts". Do not overstate or understate the frequency.

Step 6 — If you can, add a note about what might be causing it — a timing issue, a race condition, a state-dependent bug. Developers will investigate further.

Step 7 — Keep monitoring. If it becomes reproducible, add the reproduction steps to the same bug.

Step 1 — Talk to the product owner or business analyst. Even without a formal document, they know what the feature is supposed to do.

Step 2 — Talk to the developer. They built it — they can explain the intended behaviour.

Step 3 — Explore the feature as a user. What does it seem designed to do? What are the obvious paths and edge cases?

Step 4 — Compare with similar features in the same app or competitors. What behaviour would a user expect?

Step 5 — Use heuristics to design tests — CRUD (create, read, update, delete), boundary values, invalid inputs, interruptions, concurrent use.

Step 6 — Document your assumptions and the test scenarios you covered. Share them with the team — this often triggers the requirements discussion that should have happened earlier.

Step 1 — Log it. Out of scope does not mean you forget about it. A bug that is not logged does not exist.

Step 2 — Assign the correct severity and priority. A critical bug in an out-of-scope area may still need attention.

Step 3 — Discuss with the test lead and product owner. The decision to fix now, fix later, or accept the risk is a business decision.

Step 4 — If deferred, mark it as deferred with a target release. It goes into the backlog for future consideration.

Step 5 — If it is a critical bug that affects users even in out-of-scope areas, escalate. Sometimes the scope needs to change.

Step 6 — Never delete or ignore a bug because it is inconvenient. Document and let the team decide.