Software Testing Interview Questions & Answers (2026)

Assess impact and risk, discuss with product and dev, decide to fix, defer with a workaround or delay release, and document the decision.

Internationalisation tests that the product can support many languages and formats; localisation tests that a specific locale is correct for text, currency, date and layout.

List conditions and actions in a table and cover every combination of conditions (rules) — ideal for business rules like loan approval: salary > X AND credit score > Y → approve.

Status code, response body and schema, headers, response time, error messages for invalid input, authentication (401/403) and that data is saved in the database.

Clear, concise, independent, repeatable, traceable to a requirement, with precise expected results and tested data.

An urgent patch released outside the normal schedule to fix a critical production defect, followed by regression testing and merge back to the main branch.

Verify inserted, updated and deleted rows match UI actions, check constraints, duplicates, NULLs and totals with COUNT and SUM queries.

Verification: are we building the product right? (reviews, walkthroughs — no code run). Validation: are we building the right product? (actual testing against user needs).

Basic operations, division by zero, decimals, large numbers, order of operations, clear and backspace, repeated operations and memory keys.

Add, remove, update quantity, price and tax calculation, coupon codes, stock limits, cart persistence after login and checkout navigation.

Allowed and disallowed formats, size limits, empty file, duplicate names, special-character names, cancel upload, slow network and multiple files.

Severity is impact on the system; priority is urgency of the fix. A crash in a rare report is high severity, low priority; a spelling mistake in the logo is low severity, high priority.

A team meeting at the end of a sprint to discuss what went well, what did not and what to improve next.

Code is built and tested automatically on each change; tests are quality gates that stop faulty builds from moving forward.

Checking the application works across browsers, devices, operating systems, screen sizes and network conditions.

Testing services directly without the UI, checking status codes, responses, security and performance. It finds issues early and is faster than UI tests.

DELETE removes selected rows and can be rolled back; TRUNCATE quickly removes all rows and resets the table.

A language to query databases. Testers use it to verify data saved by the application, prepare test data and check backend results.

Send page, size, sort and filter parameters, then verify counts, order, boundaries (first, last, empty page) and invalid parameter handling.

JIRA Query Language, used to search issues, for example project = ABC AND status = Open AND priority = High.

Re-check the requirement, reproduce with clear steps and evidence (screenshots, logs), discuss with the BA/PO and record the final decision.

Smoke testing checks that the critical features of a new build work (broad and shallow). Sanity testing checks that a specific fix or area works after a change (narrow and deep).

They let testers verify totals and counts per category, such as the number of orders per customer, and compare them with the UI or reports.

Log and track bugs, link them to stories, build dashboards and filters with JQL, manage sprints and generate reports.

Success, failure and pending flows, timeouts, refunds, double-click payments, every method (UPI, cards, net banking), rounding, security (no card data stored) and reconciliation with bank reports.

For a field accepting 1–100: valid class 1–100 (test 50), invalid below 1 (test −5), invalid above 100 (test 150). One value represents each class.

Alpha is done in-house by internal teams before release; beta is done by a limited group of real users in their own environment.

Peer review for clarity, coverage of requirements, correct expected results, test data and traceability, then update and baseline them.

The observation that a small number of modules contain most defects, so testing should focus on those areas.

Prioritising tests by the likelihood and impact of failure, so critical areas get the most coverage when time is limited.

A technique that tests all pairs of input values instead of every combination, greatly reducing test cases while catching most defects.

Break the work into modules and test cases, use past velocity or three-point estimation (optimistic, likely, pessimistic), add time for test data, environment issues, retesting and regression, and keep a risk buffer.

Testing how a system moves between states based on events, for example an order going from placed to paid to shipped to delivered.

Learning, test design and execution at the same time, without scripted cases — time-boxed sessions with a charter (e.g. 'explore checkout with coupons'), noting bugs and ideas. Great for finding edge cases.

Verifying the application works across different hardware, software and settings combinations.

Valid keyword, partial match, no results, special characters, very long text, empty search, case sensitivity, spelling errors, suggestions and speed of results.

Testing that is continuous and collaborative within each sprint, with testers working alongside developers and product owners from the start.

Talk to developers and users, explore the product, review similar systems, create notes and mind maps, confirm assumptions and write test cases as you learn.

Evaluating software to find defects and confirm it meets requirements. It reduces risk, protects users and saves the cost of fixing bugs after release.

INNER returns matching rows, LEFT keeps all left rows, RIGHT keeps all right rows and FULL keeps all rows from both tables.

Testing how a system moves between states based on events, for example an order going from placed to paid to shipped to delivered.

A scenario is a high-level thing to test (user logs in); test cases are the detailed steps and data that verify it.

The team selects stories for the sprint. QA helps estimate testing effort, clarifies acceptance criteria and flags dependencies and risks.

Statuses like To Do, In Progress, In Review, Ready for QA, Done and Reopened, with transitions that depend on the team's configuration.

DELETE removes selected rows and can be rolled back; TRUNCATE quickly removes all rows and resets the table.

A regular review where QA, development and product assess new bugs and decide severity, priority, owner and target release.

Valid keyword, partial match, no results, special characters, very long text, empty search, case sensitivity, spelling errors, suggestions and speed of results.

Shift left with early reviews, improve test design, automate regression, use better test data, add monitoring and learn from escaped defects.

A document defining scope, approach, resources, schedule, entry and exit criteria, risks and deliverables of testing.

Defects found after release that testing should have caught; leakage % = defects in production / total defects x 100.

A suite is a collection of related test cases; a run is one execution of a set of tests against a build.

Valid transfer, insufficient balance, daily limit, wrong beneficiary, OTP failure, network drop mid-transaction, duplicate click and statement update.

A bug is behaviour that deviates from agreed requirements; an enhancement is a new or improved capability beyond the current requirements.

SDLC is the full software development life cycle; STLC is the testing life cycle: requirement analysis, test planning, test design, environment setup, execution and closure.

Positive cases use valid inputs to confirm expected behaviour; negative cases use invalid inputs to confirm the system handles errors gracefully.

Success, failure and pending flows, timeouts, refunds, double-click payments, every method (UPI, cards, net banking), rounding, security (no card data stored) and reconciliation with bank reports.

Smoke tests run on every build for quick feedback; full regression runs less often, such as nightly or before release.

Scope (in and out), objectives, approach, environments, schedule, roles, entry/exit criteria, risks and mitigation, deliverables and tools.

Measuring speed and stability: load (expected users), stress (beyond limits), spike (sudden surge), endurance (long duration) and scalability testing.

State the problem, location and condition briefly, for example 'Checkout button disabled after applying a coupon on the cart page'.

Alpha is done in-house by internal teams before release; beta is done by a limited group of real users in their own environment.

The observation that a small number of modules contain most defects, so testing should focus on those areas.

New → Assigned → Open → Fixed → Retest → Verified → Closed, with Reopened, Rejected, Deferred and Duplicate as side paths.

Risk-based testing: cover critical user flows, recent changes and high-defect areas first. Clearly communicate the untested risks and get stakeholder sign-off.

Functional testing checks what the system does (login, checkout). Non-functional testing checks how well it does it (performance, security, usability, compatibility).

Use mocks or stubs from the API contract such as Swagger, write test cases early and validate again when the real service is available.

A technique that tests all pairs of input values instead of every combination, greatly reducing test cases while catching most defects.

Re-check the requirement, reproduce with clear steps and evidence (screenshots, logs), discuss with the BA/PO and record the final decision.

A development model where each development phase has a matching testing phase, such as requirements with acceptance tests and design with integration tests.

A set of steps with inputs and expected results. Components: ID, title, preconditions, steps, test data, expected result, actual result and status.

A scenario is a high-level thing to test (user logs in); test cases are the detailed steps and data that verify it.

An API style using HTTP methods on resources identified by URLs, usually exchanging JSON and staying stateless.

Valid login, invalid login, forgot password, locked account and session handling are the main scenarios to cover.

Break the work into modules and test cases, use past velocity or three-point estimation (optimistic, likely, pessimistic), add time for test data, environment issues, retesting and regression, and keep a risk buffer.

Scope (in and out), objectives, approach, environments, schedule, roles, entry/exit criteria, risks and mitigation, deliverables and tools.

Re-testing existing features after a change. Automate stable, repetitive, high-value flows that run every release.

Status code, response body and schema, headers, response time, error messages for invalid input, authentication (401/403) and that data is saved in the database.

Keep tests modular, prioritise by risk, use exploratory testing, automate stable parts and keep close contact with product owners.

Unit, integration, system and acceptance testing, moving from individual components to the complete product in front of users.

Verification: are we building the product right? (reviews, walkthroughs — no code run). Validation: are we building the right product? (actual testing against user needs).

By business criticality, usage frequency, defect history, risk and dependencies, running high-priority cases first.

GET retrieves data and has parameters in the URL; POST sends data in the body to create or process something.

The extent of requirements or code exercised by tests. Measure requirement coverage with a traceability matrix and code coverage with tools.

Designing tests from user flows described in use cases to verify complete real-world interactions.

Talk to developers and users, explore the product, review similar systems, create notes and mind maps, confirm assumptions and write test cases as you learn.

A model with many fast unit tests at the base, fewer API or integration tests in the middle and a small number of UI tests at the top.

Test on real devices and OS versions, interrupts such as calls, battery, network changes, gestures, permissions and app store guidelines.

Clear, concise, independent, repeatable, traceable to a requirement, with precise expected results and tested data.

The inputs used in tests. Prepare using valid, invalid and boundary values from production-like but masked data, spreadsheets or generators.

User Acceptance Testing — end users or the client verify that the system meets business needs in a production-like environment before go-live.

Mandatory fields, email format, password rules, duplicate email, terms checkbox, captcha, confirmation email and field length limits.

Valid keyword, partial match, no results, special characters, very long text, empty search, case sensitivity, spelling errors, suggestions and speed of results.

Positive cases use valid inputs to confirm expected behaviour; negative cases use invalid inputs to confirm the system handles errors gracefully.

Testing how a system moves between states based on events, for example an order going from placed to paid to shipped to delivered.

Static testing reviews documents and code without executing; dynamic testing executes the software to observe behaviour.

Code is built and tested automatically on each change; tests are quality gates that stop faulty builds from moving forward.

Log and track bugs, link them to stories, build dashboards and filters with JQL, manage sprints and generate reports.

Reproduce and assess impact, inform stakeholders, help developers fix and verify in staging, run regression and check monitoring after the hotfix, then do a post-mortem.

Add, remove, update quantity, price and tax calculation, coupon codes, stock limits, cart persistence after login and checkout navigation.

Rules such as NOT NULL, UNIQUE, PRIMARY KEY, FOREIGN KEY and CHECK that keep data valid and consistent.

Shift left with early reviews, improve test design, automate regression, use better test data, add monitoring and learn from escaped defects.

Testing services directly without the UI, checking status codes, responses, security and performance. It finds issues early and is faster than UI tests.

Internationalisation tests that the product can support many languages and formats; localisation tests that a specific locale is correct for text, currency, date and layout.

A team meeting at the end of a sprint to discuss what went well, what did not and what to improve next.

Keep tests modular, prioritise by risk, use exploratory testing, automate stable parts and keep close contact with product owners.

Test 17, 18, 19, 59, 60 and 61.

Test on real devices and OS versions, interrupts such as calls, battery, network changes, gestures, permissions and app store guidelines.

Clear, concise, independent, repeatable, traceable to a requirement, with precise expected results and tested data.

Evaluating software to find defects and confirm it meets requirements. It reduces risk, protects users and saves the cost of fixing bugs after release.

The extent of requirements or code exercised by tests. Measure requirement coverage with a traceability matrix and code coverage with tools.

Smoke testing checks that the critical features of a new build work (broad and shallow). Sanity testing checks that a specific fix or area works after a change (narrow and deep).

Check SQL injection, brute-force lockout, password masking, session timeout, HTTPS, cookie flags, error messages not revealing users and password reset flow.

Peer review for clarity, coverage of requirements, correct expected results, test data and traceability, then update and baseline them.

A development model where each development phase has a matching testing phase, such as requirements with acceptance tests and design with integration tests.

Re-check the requirement, reproduce with clear steps and evidence (screenshots, logs), discuss with the BA/PO and record the final decision.

200 OK, 201 Created, 204 No Content, 400 Bad Request, 401 Unauthorized, 403 Forbidden, 404 Not Found, 500 Internal Server Error.

A language to query databases. Testers use it to verify data saved by the application, prepare test data and check backend results.

A scenario is a high-level thing to test (user logs in); test cases are the detailed steps and data that verify it.

An epic is a large body of work; stories are user-facing slices of it; tasks are technical work items; bugs are defects.

They let testers verify totals and counts per category, such as the number of orders per customer, and compare them with the UI or reports.

Smoke tests run on every build for quick feedback; full regression runs less often, such as nightly or before release.

A document defining scope, approach, resources, schedule, entry and exit criteria, risks and deliverables of testing.

DELETE removes selected rows and can be rolled back; TRUNCATE quickly removes all rows and resets the table.

Use mocks or stubs from the API contract such as Swagger, write test cases early and validate again when the real service is available.

Valid keyword, partial match, no results, special characters, very long text, empty search, case sensitivity, spelling errors, suggestions and speed of results.

Functional testing checks what the system does (login, checkout). Non-functional testing checks how well it does it (performance, security, usability, compatibility).

Moves to the chosen floor, doors open and close, door sensor stops closing on obstruction, overload alarm, emergency button, behaviour in a power cut, max capacity and the floor display.

Unit, integration, system and acceptance testing, moving from individual components to the complete product in front of users.

Assess impact and risk, discuss with product and dev, decide to fix, defer with a workaround or delay release, and document the decision.

Valid card and PIN, wrong PIN, three failed attempts, amount above balance, amount above daily limit, invalid denomination, machine out of cash, network failure and receipt printing.

The observation that a small number of modules contain most defects, so testing should focus on those areas.

Testing how a system moves between states based on events, for example an order going from placed to paid to shipped to delivered.

Reproduce and assess impact, inform stakeholders, help developers fix and verify in staging, run regression and check monitoring after the hotfix, then do a post-mortem.

Checking the application works across browsers, devices, operating systems, screen sizes and network conditions.

Scope (in and out), objectives, approach, environments, schedule, roles, entry/exit criteria, risks and mitigation, deliverables and tools.

A defect that stops testing or release of a feature because no workaround exists, so it is highest priority.

New → Assigned → Open → Fixed → Retest → Verified → Closed, with Reopened, Rejected, Deferred and Duplicate as side paths.

The team selects stories for the sprint. QA helps estimate testing effort, clarifies acceptance criteria and flags dependencies and risks.

Valid login, wrong password, empty fields, case sensitivity, max length, SQL-injection strings, password masking, 'remember me', lock-out after N attempts and the forgot-password link.

Evaluating how easy and pleasant a product is to use by observing real users complete tasks and noting confusion.

Test execution rate, pass percentage, defect density, defect leakage, defect rejection ratio, requirement coverage and automation coverage.

Verify inserted, updated and deleted rows match UI actions, check constraints, duplicates, NULLs and totals with COUNT and SUM queries.

GET retrieves data and has parameters in the URL; POST sends data in the body to create or process something.

A regular review where QA, development and product assess new bugs and decide severity, priority, owner and target release.

An urgent patch released outside the normal schedule to fix a critical production defect, followed by regression testing and merge back to the main branch.

The inputs used in tests. Prepare using valid, invalid and boundary values from production-like but masked data, spreadsheets or generators.

Checking that people with disabilities can use the product, using screen readers, keyboard navigation, colour contrast and WCAG guidelines.

Sprint planning (estimate test effort), daily stand-up (status and blockers), sprint review (demo) and retrospective (improve). Testers clarify acceptance criteria early and test within the sprint.

Prioritising tests by the likelihood and impact of failure, so critical areas get the most coverage when time is limited.

A set of steps with inputs and expected results. Components: ID, title, preconditions, steps, test data, expected result, actual result and status.

Success, failure and pending flows, timeouts, refunds, double-click payments, every method (UPI, cards, net banking), rounding, security (no card data stored) and reconciliation with bank reports.

Valid keyword, partial match, no results, special characters, very long text, empty search, case sensitivity, spelling errors, suggestions and speed of results.

The hardware, software, data and configuration where testing happens, set up to mirror production as closely as practical.

The team selects stories for the sprint. QA helps estimate testing effort, clarifies acceptance criteria and flags dependencies and risks.

New → Assigned → Open → Fixed → Retest → Verified → Closed, with Reopened, Rejected, Deferred and Duplicate as side paths.

Keep tests modular, prioritise by risk, use exploratory testing, automate stable parts and keep close contact with product owners.

Use mocks or stubs from the API contract such as Swagger, write test cases early and validate again when the real service is available.

Valid login, invalid login, forgot password, locked account and session handling are the main scenarios to cover.

Severity = impact on the system. Priority = urgency to fix. Logo misspelt on the homepage → low severity, high priority. Crash in a rarely used report → high severity, low priority.

Check SQL injection, brute-force lockout, password masking, session timeout, HTTPS, cookie flags, error messages not revealing users and password reset flow.

An epic is a large body of work; stories are user-facing slices of it; tasks are technical work items; bugs are defects.

Shift left with early reviews, improve test design, automate regression, use better test data, add monitoring and learn from escaped defects.

Allowed and disallowed formats, size limits, empty file, duplicate names, special-character names, cancel upload, slow network and multiple files.

Break the work into modules and test cases, use past velocity or three-point estimation (optimistic, likely, pessimistic), add time for test data, environment issues, retesting and regression, and keep a risk buffer.

SDLC is the full software development life cycle; STLC is the testing life cycle: requirement analysis, test planning, test design, environment setup, execution and closure.

GET retrieves data and has parameters in the URL; POST sends data in the body to create or process something.

Valid card and PIN, wrong PIN, three failed attempts, amount above balance, amount above daily limit, invalid denomination, machine out of cash, network failure and receipt printing.

Testing that is continuous and collaborative within each sprint, with testers working alongside developers and product owners from the start.

Black box tests behaviour without code knowledge; white box tests internal logic and paths; grey box uses partial knowledge of the internals.

Designing tests from user flows described in use cases to verify complete real-world interactions.

Smoke tests run on every build for quick feedback; full regression runs less often, such as nightly or before release.

A human error causes a defect in the code, and when that defect is executed it produces a failure visible to users.

Verifying the application works across different hardware, software and settings combinations.

A bug is behaviour that deviates from agreed requirements; an enhancement is a new or improved capability beyond the current requirements.

Measuring speed and stability: load (expected users), stress (beyond limits), spike (sudden surge), endurance (long duration) and scalability testing.

A language to query databases. Testers use it to verify data saved by the application, prepare test data and check backend results.

Code is built and tested automatically on each change; tests are quality gates that stop faulty builds from moving forward.

Test on real devices and OS versions, interrupts such as calls, battery, network changes, gestures, permissions and app store guidelines.

Scope (in and out), objectives, approach, environments, schedule, roles, entry/exit criteria, risks and mitigation, deliverables and tools.

By business criticality, usage frequency, defect history, risk and dependencies, running high-priority cases first.

Keep tests modular, prioritise by risk, use exploratory testing, automate stable parts and keep close contact with product owners.

Testing services directly without the UI, checking status codes, responses, security and performance. It finds issues early and is faster than UI tests.

They let testers verify totals and counts per category, such as the number of orders per customer, and compare them with the UI or reports.

The team selects stories for the sprint. QA helps estimate testing effort, clarifies acceptance criteria and flags dependencies and risks.

Entry criteria are conditions that must be met to start testing (build ready, environment set); exit criteria define when testing can stop (pass rate, no critical defects).

A team meeting at the end of a sprint to discuss what went well, what did not and what to improve next.

A shared checklist for when a story is complete, usually including code review, tests passing, no open critical bugs and documentation updated.

A set of steps with inputs and expected results. Components: ID, title, preconditions, steps, test data, expected result, actual result and status.

A model with many fast unit tests at the base, fewer API or integration tests in the middle and a small number of UI tests at the top.

Positive cases use valid inputs to confirm expected behaviour; negative cases use invalid inputs to confirm the system handles errors gracefully.

SDLC is the full software development life cycle; STLC is the testing life cycle: requirement analysis, test planning, test design, environment setup, execution and closure.

List conditions and actions in a table and cover every combination of conditions (rules) — ideal for business rules like loan approval: salary > X AND credit score > Y → approve.

Assess impact and risk, discuss with product and dev, decide to fix, defer with a workaround or delay release, and document the decision.

Test 17, 18, 19, 59, 60 and 61.

Testing at the edges of input ranges, such as 17, 18 and 19 for an age limit of 18, since errors cluster at boundaries.

The hardware, software, data and configuration where testing happens, set up to mirror production as closely as practical.

Valid transfer, insufficient balance, daily limit, wrong beneficiary, OTP failure, network drop mid-transaction, duplicate click and statement update.

Functional testing checks what the system does (login, checkout). Non-functional testing checks how well it does it (performance, security, usability, compatibility).

The observation that a small number of modules contain most defects, so testing should focus on those areas.

A suite is a collection of related test cases; a run is one execution of a set of tests against a build.

An urgent patch released outside the normal schedule to fix a critical production defect, followed by regression testing and merge back to the main branch.

Valid login, invalid login, forgot password, locked account and session handling are the main scenarios to cover.

A scenario is a high-level thing to test (user logs in); test cases are the detailed steps and data that verify it.

Basic operations, division by zero, decimals, large numbers, order of operations, clear and backspace, repeated operations and memory keys.

Risk-based testing: cover critical user flows, recent changes and high-defect areas first. Clearly communicate the untested risks and get stakeholder sign-off.

The number of defects per size of software, for example defects per thousand lines of code or per module, used to compare quality.

Black box tests behaviour without code knowledge; white box tests internal logic and paths; grey box uses partial knowledge of the internals.

Break the work into modules and test cases, use past velocity or three-point estimation (optimistic, likely, pessimistic), add time for test data, environment issues, retesting and regression, and keep a risk buffer.

State the problem, location and condition briefly, for example 'Checkout button disabled after applying a coupon on the cart page'.

Testing that is continuous and collaborative within each sprint, with testers working alongside developers and product owners from the start.

Using experience to guess where defects likely hide, such as empty fields, special characters or unexpected sequences, and designing tests for them.

200 OK, 201 Created, 204 No Content, 400 Bad Request, 401 Unauthorized, 403 Forbidden, 404 Not Found, 500 Internal Server Error.

DELETE removes selected rows and can be rolled back; TRUNCATE quickly removes all rows and resets the table.

Functional testing checks what the system does (login, checkout). Non-functional testing checks how well it does it (performance, security, usability, compatibility).

Test 17, 18, 19, 59, 60 and 61.

The observation that a small number of modules contain most defects, so testing should focus on those areas.

200 OK, 201 Created, 204 No Content, 400 Bad Request, 401 Unauthorized, 403 Forbidden, 404 Not Found, 500 Internal Server Error.

A human error causes a defect in the code, and when that defect is executed it produces a failure visible to users.

Rules such as NOT NULL, UNIQUE, PRIMARY KEY, FOREIGN KEY and CHECK that keep data valid and consistent.

Statuses like To Do, In Progress, In Review, Ready for QA, Done and Reopened, with transitions that depend on the team's configuration.

Test execution rate, pass percentage, defect density, defect leakage, defect rejection ratio, requirement coverage and automation coverage.

A defect that stops testing or release of a feature because no workaround exists, so it is highest priority.

Checking that people with disabilities can use the product, using screen readers, keyboard navigation, colour contrast and WCAG guidelines.

A model with many fast unit tests at the base, fewer API or integration tests in the middle and a small number of UI tests at the top.

Use mocks or stubs from the API contract such as Swagger, write test cases early and validate again when the real service is available.

Sprint planning (estimate test effort), daily stand-up (status and blockers), sprint review (demo) and retrospective (improve). Testers clarify acceptance criteria early and test within the sprint.

Evaluating how easy and pleasant a product is to use by observing real users complete tasks and noting confusion.

They let testers verify totals and counts per category, such as the number of orders per customer, and compare them with the UI or reports.

Assess impact and risk, discuss with product and dev, decide to fix, defer with a workaround or delay release, and document the decision.

Severity is impact on the system; priority is urgency of the fix. A crash in a rare report is high severity, low priority; a spelling mistake in the logo is low severity, high priority.

Status code, response body and schema, headers, response time, error messages for invalid input, authentication (401/403) and that data is saved in the database.

The team selects stories for the sprint. QA helps estimate testing effort, clarifies acceptance criteria and flags dependencies and risks.

Designing tests from user flows described in use cases to verify complete real-world interactions.

Send page, size, sort and filter parameters, then verify counts, order, boundaries (first, last, empty page) and invalid parameter handling.

Testing shows presence of defects, exhaustive testing is impossible, test early, defects cluster, the pesticide paradox, testing is context-dependent and absence-of-errors is a fallacy.

Static testing reviews documents and code without executing; dynamic testing executes the software to observe behaviour.

A document defining scope, approach, resources, schedule, entry and exit criteria, risks and deliverables of testing.

JIRA Query Language, used to search issues, for example project = ABC AND status = Open AND priority = High.

Designing tests from user flows described in use cases to verify complete real-world interactions.

A development model where each development phase has a matching testing phase, such as requirements with acceptance tests and design with integration tests.

Basic operations, division by zero, decimals, large numbers, order of operations, clear and backspace, repeated operations and memory keys.

Valid card and PIN, wrong PIN, three failed attempts, amount above balance, amount above daily limit, invalid denomination, machine out of cash, network failure and receipt printing.

Test 17, 18, 19, 59, 60 and 61.

Log and track bugs, link them to stories, build dashboards and filters with JQL, manage sprints and generate reports.

Break the work into modules and test cases, use past velocity or three-point estimation (optimistic, likely, pessimistic), add time for test data, environment issues, retesting and regression, and keep a risk buffer.

Verify inserted, updated and deleted rows match UI actions, check constraints, duplicates, NULLs and totals with COUNT and SUM queries.

Evaluating how easy and pleasant a product is to use by observing real users complete tasks and noting confusion.

The team selects stories for the sprint. QA helps estimate testing effort, clarifies acceptance criteria and flags dependencies and risks.

An epic is a large body of work; stories are user-facing slices of it; tasks are technical work items; bugs are defects.

A final document summarising what was tested, defects found and open, metrics, lessons learned and the recommendation for release.

Assess impact and risk, discuss with product and dev, decide to fix, defer with a workaround or delay release, and document the decision.

They let testers verify totals and counts per category, such as the number of orders per customer, and compare them with the UI or reports.

Alpha is done in-house by internal teams before release; beta is done by a limited group of real users in their own environment.

Code is built and tested automatically on each change; tests are quality gates that stop faulty builds from moving forward.

Testing that is continuous and collaborative within each sprint, with testers working alongside developers and product owners from the start.

SDLC is the full software development life cycle; STLC is the testing life cycle: requirement analysis, test planning, test design, environment setup, execution and closure.

Checking the application works across browsers, devices, operating systems, screen sizes and network conditions.

Functional testing checks what the system does (login, checkout). Non-functional testing checks how well it does it (performance, security, usability, compatibility).

For a field accepting 1–100: valid class 1–100 (test 50), invalid below 1 (test −5), invalid above 100 (test 150). One value represents each class.

A model with many fast unit tests at the base, fewer API or integration tests in the middle and a small number of UI tests at the top.

Positive cases use valid inputs to confirm expected behaviour; negative cases use invalid inputs to confirm the system handles errors gracefully.

Entry criteria are conditions that must be met to start testing (build ready, environment set); exit criteria define when testing can stop (pass rate, no critical defects).

Internationalisation tests that the product can support many languages and formats; localisation tests that a specific locale is correct for text, currency, date and layout.

Risk-based testing: cover critical user flows, recent changes and high-defect areas first. Clearly communicate the untested risks and get stakeholder sign-off.

Using experience to guess where defects likely hide, such as empty fields, special characters or unexpected sequences, and designing tests for them.

Test on real devices and OS versions, interrupts such as calls, battery, network changes, gestures, permissions and app store guidelines.

DELETE removes selected rows and can be rolled back; TRUNCATE quickly removes all rows and resets the table.

Scope (in and out), objectives, approach, environments, schedule, roles, entry/exit criteria, risks and mitigation, deliverables and tools.

An urgent patch released outside the normal schedule to fix a critical production defect, followed by regression testing and merge back to the main branch.

User Acceptance Testing — end users or the client verify that the system meets business needs in a production-like environment before go-live.

Defects found after release that testing should have caught; leakage % = defects in production / total defects x 100.

Break the work into modules and test cases, use past velocity or three-point estimation (optimistic, likely, pessimistic), add time for test data, environment issues, retesting and regression, and keep a risk buffer.

Statuses like To Do, In Progress, In Review, Ready for QA, Done and Reopened, with transitions that depend on the team's configuration.

Code is built and tested automatically on each change; tests are quality gates that stop faulty builds from moving forward.

Re-check the requirement, reproduce with clear steps and evidence (screenshots, logs), discuss with the BA/PO and record the final decision.

Testing how a system moves between states based on events, for example an order going from placed to paid to shipped to delivered.

Status code, response body and schema, headers, response time, error messages for invalid input, authentication (401/403) and that data is saved in the database.

Shift left with early reviews, improve test design, automate regression, use better test data, add monitoring and learn from escaped defects.

Clear, concise, independent, repeatable, traceable to a requirement, with precise expected results and tested data.

An API style using HTTP methods on resources identified by URLs, usually exchanging JSON and staying stateless.

Positive cases use valid inputs to confirm expected behaviour; negative cases use invalid inputs to confirm the system handles errors gracefully.

Valid login, invalid login, forgot password, locked account and session handling are the main scenarios to cover.

200 OK, 201 Created, 204 No Content, 400 Bad Request, 401 Unauthorized, 403 Forbidden, 404 Not Found, 500 Internal Server Error.

Checking that people with disabilities can use the product, using screen readers, keyboard navigation, colour contrast and WCAG guidelines.

A set of steps with inputs and expected results. Components: ID, title, preconditions, steps, test data, expected result, actual result and status.

Rules such as NOT NULL, UNIQUE, PRIMARY KEY, FOREIGN KEY and CHECK that keep data valid and consistent.

A regular review where QA, development and product assess new bugs and decide severity, priority, owner and target release.

Scope (in and out), objectives, approach, environments, schedule, roles, entry/exit criteria, risks and mitigation, deliverables and tools.

A language to query databases. Testers use it to verify data saved by the application, prepare test data and check backend results.

The extent of requirements or code exercised by tests. Measure requirement coverage with a traceability matrix and code coverage with tools.

Verifying the application works across different hardware, software and settings combinations.

Testing at the edges of input ranges, such as 17, 18 and 19 for an age limit of 18, since errors cluster at boundaries.

DELETE removes selected rows and can be rolled back; TRUNCATE quickly removes all rows and resets the table.

Valid transfer, insufficient balance, daily limit, wrong beneficiary, OTP failure, network drop mid-transaction, duplicate click and statement update.

The observation that a small number of modules contain most defects, so testing should focus on those areas.

Re-check environment, data, browser and steps; check the logs; try the reporter's setup; add video and console logs; mark it 'cannot reproduce' only after discussing with the developer, and keep monitoring.

Sprint planning (estimate test effort), daily stand-up (status and blockers), sprint review (demo) and retrospective (improve). Testers clarify acceptance criteria early and test within the sprint.

Black box tests behaviour without code knowledge; white box tests internal logic and paths; grey box uses partial knowledge of the internals.

The team selects stories for the sprint. QA helps estimate testing effort, clarifies acceptance criteria and flags dependencies and risks.

The number of defects per size of software, for example defects per thousand lines of code or per module, used to compare quality.

Unit, integration, system and acceptance testing, moving from individual components to the complete product in front of users.

Valid card and PIN, wrong PIN, three failed attempts, amount above balance, amount above daily limit, invalid denomination, machine out of cash, network failure and receipt printing.

Evaluating how easy and pleasant a product is to use by observing real users complete tasks and noting confusion.

Measuring speed and stability: load (expected users), stress (beyond limits), spike (sudden surge), endurance (long duration) and scalability testing.

Talk to developers and users, explore the product, review similar systems, create notes and mind maps, confirm assumptions and write test cases as you learn.

User Acceptance Testing — end users or the client verify that the system meets business needs in a production-like environment before go-live.

Valid login, wrong password, empty fields, case sensitivity, max length, SQL-injection strings, password masking, 'remember me', lock-out after N attempts and the forgot-password link.

Evaluating software to find defects and confirm it meets requirements. It reduces risk, protects users and saves the cost of fixing bugs after release.

Using experience to guess where defects likely hide, such as empty fields, special characters or unexpected sequences, and designing tests for them.

Prioritising tests by the likelihood and impact of failure, so critical areas get the most coverage when time is limited.

Re-check environment, data, browser and steps; check the logs; try the reporter's setup; add video and console logs; mark it 'cannot reproduce' only after discussing with the developer, and keep monitoring.

Positive cases use valid inputs to confirm expected behaviour; negative cases use invalid inputs to confirm the system handles errors gracefully.

Internationalisation tests that the product can support many languages and formats; localisation tests that a specific locale is correct for text, currency, date and layout.

Shift left with early reviews, improve test design, automate regression, use better test data, add monitoring and learn from escaped defects.

Measuring speed and stability: load (expected users), stress (beyond limits), spike (sudden surge), endurance (long duration) and scalability testing.

Check access with valid, expired and missing tokens, role-based permissions, error codes and that sensitive data is never exposed.

Peer review for clarity, coverage of requirements, correct expected results, test data and traceability, then update and baseline them.

Verifying the application works across different hardware, software and settings combinations.

DELETE removes selected rows and can be rolled back; TRUNCATE quickly removes all rows and resets the table.

Unit, integration, system and acceptance testing, moving from individual components to the complete product in front of users.

Basic operations, division by zero, decimals, large numbers, order of operations, clear and backspace, repeated operations and memory keys.

A shared checklist for when a story is complete, usually including code review, tests passing, no open critical bugs and documentation updated.

Rules such as NOT NULL, UNIQUE, PRIMARY KEY, FOREIGN KEY and CHECK that keep data valid and consistent.

Evaluating how easy and pleasant a product is to use by observing real users complete tasks and noting confusion.

An epic is a large body of work; stories are user-facing slices of it; tasks are technical work items; bugs are defects.

Black box tests behaviour without code knowledge; white box tests internal logic and paths; grey box uses partial knowledge of the internals.

Statuses like To Do, In Progress, In Review, Ready for QA, Done and Reopened, with transitions that depend on the team's configuration.

Re-check the requirement, reproduce with clear steps and evidence (screenshots, logs), discuss with the BA/PO and record the final decision.

Code is built and tested automatically on each change; tests are quality gates that stop faulty builds from moving forward.

Severity is impact on the system; priority is urgency of the fix. A crash in a rare report is high severity, low priority; a spelling mistake in the logo is low severity, high priority.

Mandatory fields, email format, password rules, duplicate email, terms checkbox, captcha, confirmation email and field length limits.

Sprint planning (estimate test effort), daily stand-up (status and blockers), sprint review (demo) and retrospective (improve). Testers clarify acceptance criteria early and test within the sprint.

Internationalisation tests that the product can support many languages and formats; localisation tests that a specific locale is correct for text, currency, date and layout.

SDLC is the full software development life cycle; STLC is the testing life cycle: requirement analysis, test planning, test design, environment setup, execution and closure.

Reproduce and assess impact, inform stakeholders, help developers fix and verify in staging, run regression and check monitoring after the hotfix, then do a post-mortem.

User Acceptance Testing — end users or the client verify that the system meets business needs in a production-like environment before go-live.

A final document summarising what was tested, defects found and open, metrics, lessons learned and the recommendation for release.

A language to query databases. Testers use it to verify data saved by the application, prepare test data and check backend results.

Valid login, invalid login, forgot password, locked account and session handling are the main scenarios to cover.

Verification: are we building the product right? (reviews, walkthroughs — no code run). Validation: are we building the right product? (actual testing against user needs).

Testing shows presence of defects, exhaustive testing is impossible, test early, defects cluster, the pesticide paradox, testing is context-dependent and absence-of-errors is a fallacy.

Re-testing existing features after a change. Automate stable, repetitive, high-value flows that run every release.

Clear, concise, independent, repeatable, traceable to a requirement, with precise expected results and tested data.

Rules such as NOT NULL, UNIQUE, PRIMARY KEY, FOREIGN KEY and CHECK that keep data valid and consistent.

Verifying the application works across different hardware, software and settings combinations.

A scenario is a high-level thing to test (user logs in); test cases are the detailed steps and data that verify it.

Break the work into modules and test cases, use past velocity or three-point estimation (optimistic, likely, pessimistic), add time for test data, environment issues, retesting and regression, and keep a risk buffer.

Checking that people with disabilities can use the product, using screen readers, keyboard navigation, colour contrast and WCAG guidelines.

Send page, size, sort and filter parameters, then verify counts, order, boundaries (first, last, empty page) and invalid parameter handling.

Evaluating software to find defects and confirm it meets requirements. It reduces risk, protects users and saves the cost of fixing bugs after release.

Add, remove, update quantity, price and tax calculation, coupon codes, stock limits, cart persistence after login and checkout navigation.

They let testers verify totals and counts per category, such as the number of orders per customer, and compare them with the UI or reports.