All 75 QA & Testing quiz questions below come with a short explanation, visible right on the page — no sign-in needed. They're grouped by beginner and intermediate levels and 10 subtopics, so you can revise one part at a time. Choose Try QA & Testing quiz above to take a scored run and review the questions you got wrong.
What the QA & Testing quiz covers
QA in Practice13
Process & Risk13
Test Design Techniques8
Test Levels & Types7
Test case & Test data7
Automation & API6
Non-functional Testing6
Defect Reporting5
Static Testing & Reviews5
Testing Principles5
Beginner level — 20 QA & Testing questions
Question 1·Testing Principles
What does the principle "testing shows the presence of defects" mean?
A.The more test cases there are, the fewer bugs reach production
B.Passing tests do not prove the software has no bugs
C.A tester has not finished the job until they find a defect
D.Every piece of software contains at least one undiscovered defect
Answer: B
Testing can only demonstrate that defects are present, never that the system is defect-free. A fully passing test suite only says the parts checked showed no failures — it says nothing about what wasn't checked.
A.Because current testing tools are not powerful enough
B.Because testers never have enough time on a project
C.The number of input and state combinations is too large to run through
D.Because the requirements always change during development
Answer: C
Because the input and state space explodes combinatorially. Even a single integer input has billions of values, not counting operation order and system states. So testing is always a matter of risk-based sampling.
Which information must a usable bug report contain?
A.The reproduction steps, the expected result and the actual result
B.The name of the person who caused the defect
C.The code suspected of causing the defect
D.An estimate of how long the fix will take
Answer: A
At minimum: reproduction steps, expected result, actual result, plus environment details (version, browser, account, data) and evidence. Without reproduction steps, the bug will almost certainly be bounced back.
How does confirmation testing differ from regression testing?
A.Confirmation runs on staging and regression on production
B.Confirmation is manual while regression is automated
C.Confirmation is done by testers and regression by developers
D.Confirmation checks the fix while regression checks everything else
Answer: D
Confirmation testing reruns the exact failing case to verify the fix works. Regression testing runs other cases to ensure the fix didn't break what already worked. Fixing a bug requires both.
A.Checking the ability to recover after an incident
B.A quick check of the core functionality
C.Checking every function before a release
D.Checking system performance under heavy load
Answer: B
Quick check that core flows still work after a new build — login, main business flow, database connection. If the smoke test is red, reject the build immediately, no need to run the full test suite.
A.Agreeing in advance what counts as having tested enough
B.Recording the planned end date of the testing phase
C.Listing the functions outside the testing scope
D.Deciding who may close a fixed bug
Answer: A
Fix in advance the conditions that count as enough testing: requirements coverage, the ratio of test cases executed, the number of remaining open bugs per severity level, and residual risk. Without these criteria, "is testing done?" stays a subjective argument.
A.401 means not authenticated while 403 means not authorized
B.401 means a wrong password while 403 means a locked account
C.401 is caused by the client and 403 by the server
D.401 is for the web and 403 for APIs
Answer: A
401 Unauthorized = not authenticated or invalid token, the client needs to log in again. 403 Forbidden = we know who you are, but you lack permission for this resource. Confusing the two makes clients behave wrongly, e.g. logging users out when they only lack permission.
A.Whether the system works across several browsers
B.Whether people with disabilities can use it
C.Whether the interface matches the design
D.Whether users can complete their task easily
Answer: D
It measures whether real users can get their work done easily — easy to learn, easy to operate, few mistakes. It does not verify whether the functionality is correct, but whether that correct functionality is usable.
A.That the system works correctly across platforms and configurations
B.That the system's modules communicate correctly
C.That the system handles the required number of concurrent users
D.That old data is still readable after an upgrade
Answer: A
Checks that the system runs correctly on different platforms and configurations: browsers, operating systems, devices, screen resolutions, application versions. You cannot cover everything, so choose based on real user data.
A.Alpha checks functionality while beta checks performance
B.Alpha happens at the development site while beta happens at the users'
C.Alpha is run by internal testers and beta by outsourced testers
D.Alpha runs before the code is finished and beta after release
Answer: B
Both are forms of acceptance testing. Alpha takes place at the development site, usually performed by potential users or internal staff under supervision. Beta takes place at the user's real workplace, in their real environment.
How does ad-hoc testing differ from exploratory testing?
A.Ad-hoc is done by newcomers and exploratory by experienced testers
B.Ad-hoc only checks the UI while exploratory also covers the business
C.Ad-hoc runs before requirements exist and exploratory afterwards
D.Exploratory testing has direction and notes while ad-hoc has neither
Answer: D
Exploratory has a goal (a charter), a time box, and notes on the path taken — so it's measurable and handover-ready. Ad-hoc is free-form, undirected, unrecorded testing, mainly to get familiar with the product.
A.When the system is brand new and nobody understands the domain
B.When you need to measure the testing time per function precisely
C.When you must prove coverage for an external audit
D.When you need quick coverage of familiar ground
Answer: D
When you need fast coverage of familiar areas without the effort of writing detailed test cases: checklists for forms, for list screens, for payment flows, for file upload. Low authoring cost with stable coverage.
A.The whole team, with the tester holding the specialist role
B.The Product Owner, because they accept the items
C.The tech lead, because they review the code
D.The tester, because it is their specialty
Answer: A
The whole team — the whole-team approach. The tester brings test expertise and a risk-seeking mindset, but developers write unit tests, review each other's work, and share the Definition of Done. When quality is delegated to one person, it always gets checked only at the last stage.
How does equivalence partitioning reduce the number of test cases?
A.Combine several test steps into one case
B.Drop the lower-priority test cases
C.Only test the values at the boundaries of the valid range
D.Group values handled identically and test one value per group
Answer: D
Divide the input domain into groups the system handles identically, then test only one representative value per group. For an age input from 18 to 60, the three groups are under 18, 18 to 60, and over 60 — testing more values within the same group reveals nothing new.
Define the minimum conditions to start: the build is deployed to the test environment, smoke tests have passed, requirements are finalized, and test data is ready. Starting without meeting these criteria means most of the time is spent waiting and reporting environment issues.
A.A sanity test is automated while a smoke test is manual
B.They are the same thing named differently by company
C.A sanity test runs before release and a smoke test after
D.A sanity test checks the fixed area deeply while a smoke test checks broadly
Answer: D
Smoke test is broad and shallow — do the main functions work, to decide whether the build is worth testing further. Sanity test is narrow and deep — focused on the area just fixed or added, to confirm the change works correctly.
B.Scenarios are for manual testing while cases are for automation
C.Scenarios are written by the customer while cases are written by QA
D.A scenario states what to check while a case states the steps and result
Answer: D
A scenario states what to check at a general level — "ordering when out of stock". A case concretises it into steps, input data and expected results so others can repeat it. Scenarios are used for planning and coverage review; cases are used for execution.
Given a brand-new screen to test, where should you start?
A.Read the requirement and try the main flow before going into detail
B.Test every input with invalid values first
C.Check compatibility across several browsers
D.Write out the full set of test cases before opening the screen
Answer: A
Read the requirements to understand what this screen is for, then run the main flow once. If the main flow is already broken, return the build immediately instead of spending time on detailed checks. Only then move on to error branches, boundary values, and combinations.
In a daily team meeting, what information from QA is most useful?
A.The detailed test plan for next week
B.What is blocked and any newly identified risks
C.The full list of bugs reported that day
D.How many test cases were run yesterday
Answer: B
State what is currently blocked (broken environment, waiting for data, waiting for a fix) and newly discovered risks affecting the release plan. These are the things that need the whole team to coordinate; progress metrics are visible to everyone in the tool.
What does the pesticide paradox describe in testing?
A.Fixing one defect usually creates another
B.Automated tests are always less reliable than manual ones
C.A test suite repeated forever stops finding new defects
D.The more testers there are, the harder it is to agree on results
Answer: C
Running the same test suite repeatedly leads to diminishing defect detection effectiveness — it only covers known paths, while new defects hide where no one has looked. The suite needs regular review and augmentation.
How do error, defect and failure differ in ISTQB terms?
A.An error is caused by developers, a defect found by testers, a failure reported by users
B.An error is minor, a defect is major, and a failure is a production incident
C.A person makes an error, producing a defect in the product, which causes a failure at run time
D.The three words are synonyms used in different contexts
Answer: C
Causal chain: a human makes an error (mistake) → leaves behind a defect (bug in code or documentation) → which may cause a failure (incorrect system behavior) when executed. A defect may never cause a failure if that code never runs.
A.Severity is for production and priority for the test environment
B.Severity is the technical impact while priority is the urgency
C.The two figures must always match
D.Severity is set by testers and priority by developers
Answer: B
Severity = impact on the system (crash, data loss, wrong figures, UI misalignment). Priority = urgency of the fix, decided on business grounds. The two are independent and often diverge.
An age field accepts 18 to 60. Which values does boundary value analysis pick?
A.17, 18, 60, 61
B.18, 30, 60
C.0, 18, 60, 100
D.17, 19, 59, 61
Answer: A
17, 18, 60, 61 — one value just inside and just outside each boundary. The most common coding mistake here is confusing > with >=, and only values right at the boundary expose that kind of error.
When is a decision table the right test design technique?
A.When you need to measure statement coverage of the source
B.When the result depends on a combination of several conditions
C.When the system has many screens following one another
D.When testing an input with several value ranges
Answer: B
When the outcome depends on a combination of multiple conditions — e.g. discount rules based on membership tier, order value and promo code. The table surfaces combinations the specification missed.
B.Examining the product without executing the code
C.Testing a frozen version that no longer changes
D.Testing an interface with no user interaction
Answer: B
Examining the work product without executing code: requirements review, design review, code review, and static analysis with tools (linter, security scanning, type checking). It can find defects in documentation, which dynamic testing cannot reach.
A.Load runs at the expected traffic while stress pushes past the limit
B.Load runs on production while stress runs on staging
C.Load measures response time while stress measures memory consumption
D.Load tests user numbers while stress tests data volume
Answer: A
Load test runs at expected load levels to confirm the system meets targets. Stress test pushes beyond limits to find the breaking point and see how the system fails — graceful degradation or collapse dragging down other systems.
Test design, execution, and learning about the product happen simultaneously — the result of the previous step guides the next. This is an experience-based technique, not ad-hoc unorganized testing.
A.Always accompanied by a screenshot for each step
B.Written in the most detailed language possible
C.Clear preconditions and a verifiable expected result
D.Covering as many functions as possible in one case
Answer: C
Has a clear precondition (account, data, state), defined steps, and a verifiable expected result. Simple test: can someone else read it and re-run it to reach the same pass or fail conclusion?
How is the defect clustering principle used in test planning?
A.Test only the modules written in the current Sprint
B.Spread the test cases evenly across every module
C.Skip modules that already had many defects, since they have been fixed
D.Concentrate effort on the modules with the most defect history
Answer: D
A small part of a module usually contains most of the defects, so concentrate test effort there: the most complex areas, the most changed, and those with the densest defect history. This is a database for allocation, not gut feeling.
State transition testing fits which kind of feature best?
A.A feature that only displays data with no actions
B.A feature with a clear state lifecycle
C.A feature with many numeric input fields
D.A feature computing from several parallel conditions
Answer: B
Features with a state lifecycle: orders, accounts, approval workflows, login sessions. The technique checks both valid transitions and transitions that must not occur.
Beyond the status code, what should an API test check?
A.How many log lines the server writes
B.Which library versions the server is running
C.The shape of the returned data and its effect on stored data
D.The response time of the first call
Answer: C
Check the structure and content of the returned data (correct schema, correct types, missing fields) and side effects — whether data is persisted correctly to the database, whether events or emails are sent. A 200 only says the request was accepted, not that the result is correct.
Why should production data not be copied as-is into a test environment?
A.Personal data carries legal constraints on protection and access
B.Production data changes constantly so the tests become unstable
C.Production data is too large for the test environment to hold
D.Production data lacks enough edge cases for testing
Answer: A
Because it contains personal data — names, phone numbers, addresses, payment details — while the test environment usually has much weaker access control. The right way is to anonymize or generate fake data that keeps the same distribution characteristics.
An automated test passes and fails without any code change. What is the right response?
A.Ignore it as normal behaviour for end-to-end tests
B.Delete it from the suite and check that part by hand
C.Find the source of nondeterminism and fix it or quarantine that test
D.Rerun it up to three times automatically and take the best result
Answer: C
Trace the nondeterminism: fixed-time waits instead of condition-based waits, data shared across tests, order-dependent execution, or external service dependencies. Until it is fixed, take that test out of the blocking flow rather than re-running it until it goes green.
A developer closes a defect as "cannot reproduce". What should QA do next?
A.Raise the severity to the maximum to force it to be handled
B.Add the environment, the data and the evidence, then reopen it
C.Accept the closure since the developer understands the system better
D.Escalate to management for immediate intervention
Answer: B
Add the exact preconditions: build version, account and permissions, specific data, browser and device, timing, plus video or logs. Most cases that cannot be reproduced are reported missing one condition the reporter assumed was obvious.
D.Moving testing activities earlier in the development cycle
Answer: D
Moving testing activity earlier: joining requirements review, asking questions at design time, writing test cases before coding. The earlier a bug is found, the cheaper it is to fix.
A.Run an automated scanner and report all its findings
B.Authorization, sensitive data, and input validation
C.Assess the strength of the encryption algorithms in use
D.Attempt a denial-of-service attack against staging
Answer: B
Three basic groups: authorization (a low-privilege account calling a high-privilege API directly), sensitive data (whether passwords and tokens are exposed in logs, URLs, API responses), and input validation (long strings, special characters, uploading files of the wrong format).
A.The time left in the Sprint after subtracting the coding
B.The scope, the risk level, and data from similar past items
C.The expected number of test cases times the average time per case
D.The developer's estimate for the coding work
Answer: B
Based on scope (how many flows, how many combinations), risk level (how deep coverage is needed), and historical data from similar items. Remember to include time for data preparation, retesting after fixes, and running regression.
A.Assessing whether the requirement is technically feasible
B.Deciding whether the requirement is worth doing
C.Rewriting the requirement to match the documentation standard
D.Checking whether the requirement is verifiable
Answer: D
Check whether the requirement is verifiable: clear criteria to say right or wrong, exception cases stated, something about empty data and limits, no contradiction with other requirements. A vague requirement at this stage is the cheapest defect to fix.
Based on experience: places where this system has broken before, common programming errors, and intuition about where things tend to go wrong. Usually implemented as a list of suspicious cases accumulated over the course of the project.
Link requirements ↔ test cases ↔ bugs to answer two questions: which requirements have no test case yet, and when a requirement changes, which cases need updating. It's also the coverage evidence for audited projects.
What Vietnamese-specific issues does English testing not surface?
A.How many concurrent users the system can handle
B.How secure the login session is
C.Vietnamese diacritics in sorting and searching
D.The server's response time when the language is switched
Answer: C
The group around Vietnamese diacritics: sorting a list of names, whether an unaccented search returns accented results, longer strings breaking the layout, and whether the input method loses diacritics when the input field handles characters itself.
A.Checking whether the interface's translation is accurate
B.Checking the application runs on older browsers
C.Checking page load speed on low-end devices
D.Keyboard navigation, contrast, and image labels
Answer: D
Three groups that are easy to check and high value: keyboard navigation (tab reaches everything, focus is clearly visible, no traps), text colour contrast, and alt text for images plus labels for inputs so screen readers can read them.
How is ISO/IEC 25010 used in non-functional testing?
A.It provides a list of quality characteristics
B.It certifies the testing team's quality
C.It prescribes the mandatory format of test reports
D.It sets minimum performance thresholds for the system
Answer: A
Use it as a checklist of quality characteristics when planning: performance, security, reliability, usability, compatibility, maintainability, portability, and functional suitability. The point is not to miss any group.
B.Build a role matrix and test the forbidden cells too
C.Ask the developers which roles they handled
D.Read the source of the system's permission checks
Answer: B
Build a role × action matrix, mark the allowed cells and the forbidden cells, then test both kinds of cells — especially calling the API directly for forbidden cells. Many systems only hide the button in the UI without blocking it on the server side.
D.After each bug fix, running only the related part
Answer: A
Run automatically on every code merge with the fast suite (smoke and main flows), plus the full suite on a nightly schedule. The closer detection is to the point that caused the bug, the easier root cause tracing is.
Why should test cases be independent of each other?
A.To reduce how many test cases must be written
B.So new testers find them easier to read
C.So they can be run individually and in parallel
D.To reduce the whole suite's run time
Answer: C
So they can run individually and in parallel, and so one failing case doesn't drag a whole row of cases into false red. Chained dependent cases make results depend on execution order, and tracing the cause becomes very costly.
Which metric should headline a performance test report?
A.The total number of requests sent during the test
B.The average response time across all requests
C.Response time by percentile (p95, p99)
D.The fastest response time recorded
Answer: C
Use percentiles (p95, p99) together with error rate and throughput. The average hides the tail: a 200 millisecond average looks fine while 5% of users wait more than three seconds — and that's often the group with the most data.
A defect keeps reopening after being marked fixed. What is the usual cause?
A.The two sides understand the correct behaviour differently
B.The test environment did not have the new build
C.The tester reran the wrong original test case
D.The developer fixed it carelessly so it was not fully resolved
Answer: A
Usually a difference in understanding the correct behavior: the report describes the symptom but does not state the expected result, so the developer fixes it according to their understanding while the tester checks according to their own.
D.The parameter combinations are too numerous to try exhaustively
Answer: D
With many parameters, the number of combinations grows multiplicatively and can't all be tested. This technique picks a set of cases that covers every pair of values for every pair of parameters — far smaller than full coverage, yet according to many studies still catches most combination defects.
What are the minimum states in a defect lifecycle?
A.Each person should name the states in their own way
B.Each severity level should have its own state chain
C.Just two states, open and closed
D.New, in progress, awaiting retest, closed, and rejected
Answer: D
For this process, the appropriate state set is: new → in progress → pending retest → closed, with a rejected branch for reports that aren't defects or are duplicates. The key point is that each state has one clearly responsible person so defects don't sit idle because no one knows it's their turn.
You find a defect that seems to duplicate an existing report. What should you do?
A.Close the new one immediately since someone reported it first
B.File it separately so nothing is missed
C.Compare first; if it is a duplicate, link it and add the details
D.Wait for the developer to decide whether it is a duplicate
Answer: C
Compare before concluding it's a duplicate: the same symptom doesn't necessarily mean the same cause. If it truly is a duplicate, link the two reports and add the new information to the original defect — different reproduction steps, different environment — since that helps diagnose it faster.
What decisions should a bug triage meeting produce?
A.The priority, the assignee, and the expected timing
B.The specific fix for each reported bug
C.Who is responsible for letting the bug escape
D.The technical cause of each bug
Answer: A
Three decisions: priority (fix now, fix this cycle, or defer), owner, and expected timing. This meeting decides the order of work, not a place to discuss technical causes — that wastes the time of people who aren't involved.
How should the regression set for a release be selected?
A.The most recently written test cases
B.The cases that have found bugs in the past
C.The changed area, its dependent areas, and the critical flows
D.Every existing test case, excluding none
Answer: C
Three groups: areas changed directly; areas that depend on the changed parts — ask the developers to identify these; and the most critical flows even if unrelated to the change, because those must not break.
What should a test summary report for stakeholders contain?
A.The complete list of test cases run
B.The technical details of each reported bug
C.The scope covered, the remaining risks, and a recommendation
D.How many bugs each team member found
Answer: C
Three most important parts: what was and wasn't tested; remaining risks with their impact if they occur; and a recommendation on whether to release. Readers need a basis for a decision, not a list of test cases.
C.Predicting exactly how many bugs remain in the product
D.Comparing the bug level across modules to focus the effort
Answer: D
Used to compare between modules: defects divided by size shows which areas have more problems than normal, so testing and review can focus there. Don't use it to evaluate individuals, since that creates an incentive to hide defects.
What should a review of someone else's test cases focus on?
A.Whether the case count meets the target
B.The writing style and formatting of the descriptions
C.The missing cases and whether the expected results are clear
D.The estimated run time of each case
Answer: C
Two things: missing cases — error branches, boundary values, situations real users often hit; and whether the expected results are clear — a case that says "the system works correctly" will lead two people to different conclusions.
Reading a requirement, which question best exposes gaps?
A.What happens in the unfavourable situations
B.Who proposed this feature
C.When this feature is expected to be finished
D.Which technology this feature will be built with
Answer: A
Ask about the unhappy path: what if the operation fails, what to show when data is empty, what a user without permission sees, what happens if done twice. Requirements almost always describe the happy path in detail and leave the rest blank.
C.They describe in detail how the feature is implemented
D.They are objectively verifiable and not open to interpretation
Answer: D
The most important thing is objectively verifiable: two readers must reach the same conclusion on whether it is met. "The page loads fast" is unusable; "the page shows main content within two seconds on 4G" is usable.
What preparation does a user acceptance testing round need?
A.Business scenarios, realistic data, and a way to capture feedback
B.A detailed list of technical test cases
C.Every bug fixed before it starts
D.An environment identical to production in its infrastructure
Answer: A
Three things: business-oriented scenarios rather than technical steps; realistic data so users recognise their own work; and a clear way to record feedback to distinguish real defects from change requests.
What is the purpose of the three amigos practice before starting an item?
A.Dividing the work between the three roles
B.Aligning the understanding between three roles before the work starts
C.Deciding which technical solution to use
D.Producing a more accurate completion estimate
Answer: B
To align understanding before starting: the business person states what is needed, the developer raises technical constraints, the tester asks about undescribed branches. Three viewpoints surface mismatched understandings while fixes are still very cheap.
What does writing tests in behaviour-driven syntax provide?
A.Non-programmers can read and comment on them
B.The scenarios run faster than tests written in code
C.Test cases are generated automatically from the requirement document
D.No implementation code is needed for each step
Answer: A
The main benefit is that non-programmers can read and comment: scenarios written in business language become living documentation, so the requester confirms understanding right there. In return, you must maintain an extra mapping layer from wording to code.
How should an API test collection in a tool like Postman be organized for the long term?
A.Each person keeps their own collection on their own machine
B.Hardcode the address and token into each request
C.Separate the environment configuration and keep the collection in the repository
D.Put every request into a single folder
Answer: C
Two important things: separate environment configuration (addresses, credentials) from the requests so they can run across multiple environments; and put the collection into a repo to track changes, review, and run it in the pipeline using a command-line tool.
What matters when testing user-facing error messages?
A.The shorter the message the better in every case
B.It says clearly what happened and what to do next
C.It shows a technical error code for reference
D.It uses one generic message for every kind of error
Answer: B
A good message tells what happened and what the user should do next. "An error occurred" helps nothing; "Invalid card number, please check the 16 digits" does. Also check that the message does not expose technical information such as table names or queries.
Testing payment with a gateway sandbox, which cases come first?
A.The payment gateway's processing speed
B.Successful payments with several different card types
C.Failed payments, cancellations, and lost responses
D.The payment page's visual appearance
Answer: C
Prioritize the failure branches: card declined, user cancels midway, closes the browser after paying but before returning, and the confirmation webhook never arrives. This is where money and order status are most likely to diverge.
What cases matter when testing a one-time code (OTP) flow?
A.Expired codes, repeated wrong entries, and repeated resends
B.The code input field's appearance across devices
C.How fast the message reaches the user's phone
D.Whether the code's length is appropriate
Answer: A
Three groups: an expired code is rejected; entering it wrong many times triggers a temporary lock instead of unlimited retries; and continuous resend requests are rate-limited. Additionally: a used code cannot be reused, and one person's code cannot be used for another account.
Testing a paginated, sortable list in the UI — what deserves attention?
A.Whether changing the filter or sort returns to the first page
B.The first page's load speed
C.The colour of the pagination buttons
D.Whether the rows per page matches the configuration
Answer: A
The most error-prone group: changing the filter or sort while on a middle page. If it does not return to the first page, the user sees an empty page or mismatched data. Along with: a partially filled last page, an empty list, and duplicate values when sorting.
Testing a mobile app on an unstable network — what should be the focus?
A.Interrupted operations and the state once the network returns
B.Whether the disconnected notice appears
C.Screen load speed on a weak network
D.How much data the application consumes
Answer: A
Focus on operations interrupted midway: losing network right after pressing send. The user does not know whether it was sent, and retrying may create two records. Also the state after the network returns — whether the data syncs correctly.
How should testing of a feature with several user roles be organized?
A.Test each role in turn across the whole feature
B.Test with the highest-privileged account for speed
C.A matrix of roles against actions, checking the forbidden cases too
D.Only test the most-used roles
Answer: C
Build a role-and-action matrix, then check both directions: a role with permission can do it, and a role without sufficient permission is blocked. The second direction matters more because authorization errors are missing checks, not incorrect checks.
What cases should search testing cover in a Vietnamese application?
A.Where the search box sits in the interface
B.The result speed with long keywords
C.Searching without diacritics, case differences, and extra whitespace
D.How many results are shown per page
Answer: C
Three important groups: searching without diacritics must return results with diacritics; case does not matter; and extra whitespace at the start and end is ignored. Vietnamese users often type without diacritics for speed, so this is the most common case, not an edge case.
Several people share one test environment and data conflicts arise. What is the durable fix?
A.Restore the data to its initial state every morning
B.Agree on an hourly schedule for using the environment
C.Ask everyone to announce before editing shared data
D.Give each person their own data, created and cleaned up by them
Answer: D
Each person uses a separate dataset — separate account, separate data with a distinguishing prefix — and creates and cleans up themselves. This removes the cause of conflict instead of managing it, and scales as the team grows.
A third-party service is not ready but the dependent feature needs testing. What now?
A.Skip the integration part and only test the interface
B.Use a simulator built to the specification to test your own part
C.Call the third party's production environment directly
D.Wait until the service is ready before testing
Answer: B
Use a mock built exactly to the spec to test all your own logic immediately. The mock also lets you set up error branches that are hard to reproduce with the real service. But there must be one round of testing with the real service before release, because spec and reality often diverge.
After a production configuration change, what needs re-verification?
A.The whole system, as for a full release
B.The flows depending on that configuration plus the main flows
C.No testing is needed since the code has not changed
D.Just check that the configuration was applied correctly
Answer: B
Check the flows that depend directly on that configuration plus the system's main flow. Changing configuration doesn't change code, so the previously run test suite detects nothing, while many serious incidents originate from exactly this kind of change.
What matters when testing a data export download feature?
A.Where the download button sits in the interface
B.The exported data matches the filter and the file opens correctly
C.Whether the filename contains a timestamp
D.The generation time for large data
Answer: B
Two main groups: whether the exported data matches the selected filter and sort — a common bug is exporting everything instead of the current view; and whether the file opens correctly in common tools, especially Vietnamese characters not being corrupted.
