Glossary

Also: 3DS

With 3-D Secure the customer is sent to their bank, often their banking app, to approve a payment before it completes. In Europe it is the usual way to meet Strong Customer Authentication (SCA) rules. Testers check success, failure and cancellation, and what happens when the app goes to the background during the redirect.

In practice: The user approves the payment in their banking app and switches back, and the shop should show "Order confirmed", not an empty checkout.

Related:Payment gatewayTest card

Also: AC

Acceptance criteria are specific, testable conditions attached to a user story. They define the boundaries of the feature and are a direct source of test cases. They are often written as Given / When / Then.

In practice: "Given I am logged in, when I tap the heart icon on a product, then the product appears in my wishlist and the icon turns red."

Related:User storyRequirementAcceptance testing

Acceptance testing is the final test level, checking whether the system meets business needs and acceptance criteria so it can be released. It may be done by users (UAT), the product owner or the customer.

In practice: Before launch, the product owner goes through every acceptance criterion of the new loyalty points feature and signs it off.

Related:User acceptance testingSystem testingAcceptance criteriaValidation

Also: a11y testing

Accessibility testing checks that everyone, including people with visual, hearing, motor or cognitive impairments, can use the app or site. It covers screen reader support, color contrast, text scaling, keyboard navigation and touch target size, often measured against WCAG.

In practice: With VoiceOver on, the "Pay" button is announced only as "Button", so a blind user cannot tell what it does.

Related:Screen readerDynamic TypeTouch targetWCAGUsability testing

Also: Expandable section, Disclosure, Collapsible

Testers check the indicator matches the state, the whole header is clickable, aria-expanded updates, deep links open the right section, and opening doesn't lose the user's place.

In practice: An FAQ where tapping 'Returns' opens its answer and the chevron points up.

Related:Tabs

If login says "No account with this email" for one address and "Wrong password" for another, an attacker learns who has an account. Login, sign up and password reset should give the same generic response either way.

In practice: "If an account exists for this email, we've sent a reset link" is safe. "This email is not registered" is not.

Related:AuthenticationSecurity testingError message

The primary actor is the one who wants the goal (a customer reordering food). Secondary actors help along the way, like a payment provider or an email service. Each actor hints at test data and roles you need.

In practice: In 'Reset password', the primary actor is the customer; the email service is a secondary actor that sends the link.

Related:Use caseUse case testing

The actual result is the behavior you observed while testing. If it differs from the expected result, you have found a possible bug. In a bug report, describe it precisely, including error messages and screenshots.

In practice: Expected: the cart shows 2 items. Actual: the cart badge shows 2 but the cart screen lists only 1 item.

Related:Expected resultBug report

Also: Informal testing

Ad hoc testing is unplanned and unstructured: the tester tries things based on intuition and experience, without a charter or notes. It can find bugs quickly but is hard to repeat or measure, which is the main difference from exploratory testing. (Monkey testing, feeding random input, often with a tool, is a related idea.)

In practice: While waiting for a build, you randomly tap buttons on the settings screen very fast and discover that two dialogs open on top of each other.

Related:Exploratory testing

Also: Android Debug Bridge

adb talks to a connected Android device or emulator. Testers use it to install builds, take screenshots and recordings, read logcat, clear app data and simulate events, all from the computer.

In practice: adb install app-debug.apk installs a test build, and adb shell pm clear com.shop.app resets the app to a fresh install state.

Related:LogcatEmulator

Agile is a set of values and principles for developing software iteratively, delivering small working pieces often and adapting to change. Testers in agile teams work alongside developers from the start of each feature rather than at the end of the project.

In practice: Instead of releasing a whole banking app after a year, the team releases a working login and balance screen in month one, then adds transfers, then cards.

Related:ScrumSprintUser storySoftware development life cycle

Also: Flight mode

It's the quickest way to test offline behavior on a real device. Note that Wi-Fi can be turned back on while airplane mode stays on.

In practice: Turning on airplane mode during a photo upload should show 'Upload paused' rather than silently losing the photo.

Related:Offline modeInterruption

Also: Dogfooding

Employees use the product in a controlled setting before outside users see it. It's followed by beta testing with external users.

In practice: Everyone at the food delivery company orders lunch through the new app version for a week before beta.

Related:Beta testingAcceptance testing

Also: Alternative text, Accessibility label

Meaningful images need alt text describing their content or purpose; decorative images should have empty alt text so screen readers skip them. Testers check with a screen reader or by inspecting the HTML.

In practice: A product photo announced as "IMG_4821.jpg" instead of "Red running shoes, side view" is an accessibility bug.

Related:Screen readerWCAGARIA

Also: Alternate flow

Alternative flows branch off a step of the main success scenario when a condition differs, then usually rejoin it. Each one deserves its own test scenario, because developers often code the main path first and the alternatives in a hurry.

In practice: While reordering, two of three dishes are available: the app adds those two, lists the missing one, and the customer still orders.

Related:Use caseMain success scenarioException flow

Also: Keystore

Keys can require the user to authenticate (fingerprint or PIN) before each use. Adding a new fingerprint can invalidate them, which is a useful test case.

In practice: After adding a new fingerprint, the banking app asks for the password again because its key was invalidated.

Related:Biometric authenticationSecure EnclaveKeychain

Also: App not responding

An ANR happens when the app's main thread is blocked. Testers report it like a crash, with steps and the 'ANR in' section from logcat.

In practice: Tapping Export on a large order history freezes the app, and Android asks 'App isn't responding. Close app?'

Related:CrashLogcat

Also: Application programming interface

An API (application programming interface) is a defined set of requests and responses that lets one program use another. Mobile apps and websites usually call backend APIs to log in, load data and save changes. Testers can check API calls with DevTools or tools like Postman.

In practice: When you open your orders in a shopping app, the app sends a request to an API like GET /api/orders and shows the list it gets back.

Related:Integration testingDevToolsGrey-box testing

API keys identify applications rather than individual users, for example a restaurant's ordering system that updates its menu. Testers check that missing, wrong and revoked keys are rejected with 401, that one partner's key can't touch another partner's data, and that keys never appear in URLs, responses or logs.

In practice: A request with "x-api-key: test_pk_..." updates Partner 42's menu; the same request with Partner 43's key returns 403.

Related:AuthenticationBearer token

Also: Backward compatibility

Removing or renaming fields, changing types or making a field required are breaking changes, so they go into a new version while the old one keeps working for apps that haven't updated. Testers run the old version's tests on every release and try the oldest supported app version against the new back end.

In practice: The 2025 FoodDash app still calls /v1/orders after /v2 renames "total" to "amount"; v1 must keep returning "total".

Related:Contract testingSemantic versioningForced update

Also: Application lifecycle

Mobile operating systems pause, suspend and kill apps to save battery and memory. Each change of state is a chance for bugs: lost form data, frozen timers, duplicate requests. Testers move apps between states on purpose and check that nothing breaks.

In practice: You start filling in a long delivery form, switch to WhatsApp for two minutes, and come back. The form should still be filled in.

Related:InterruptionState persistence

Also: Permissions, Runtime permissions

Mobile apps must ask before using sensitive features, and users can deny or revoke permission at any time. Testers check allow, deny, "only this time", revoking in settings, and the app's explanation of why it needs access.

In practice: If the user denies camera access, the "Scan card" button should explain how to enable it in Settings instead of showing a black screen.

Related:AuthorizationOS version

Also: ATT

If the user declines, the app must still work. Testers check the prompt timing and that denying doesn't break features.

In practice: Declining 'Allow tracking' should only affect ads, not stop the user from ordering food.

Related:App permissions

Also: ATS

An applicant tracking system stores every application a company receives and lets recruiters search and filter candidates, often by keywords and by answers to screening questions. It also tracks where each candidate is in the hiring process. Because recruiters search it like a search engine, a CV that lacks the job ad's key terms may never be seen by a person.

In practice: A recruiter searches the ATS for "mobile testing" and "Jira". A CV that only says "quality checks on apps" doesn't appear in the results, even though the candidate has done that work.

Related:Take-home assignmentQA portfolio

Also: WAI-ARIA, aria-label

ARIA (Accessible Rich Internet Applications) adds roles like dialog or tab, states like aria-expanded and labels like aria-label. It helps when native HTML isn't enough, but wrong ARIA is worse than none.

In practice: A custom dropdown without aria-expanded leaves screen reader users unaware whether the list is open or closed.

Related:Screen readerWCAGAlt text

Also: Audio session

Phones decide which app may play sound. A call, alarm or navigation prompt takes audio focus, and other apps should pause or duck their volume, then resume sensibly.

In practice: A podcast should pause when a call comes in, and lower its volume briefly while the maps app says 'turn left'.

Related:InterruptionApp lifecycle

Also: Login, Sign in, AuthN

Authentication answers "who are you?" through login, one-time codes, biometrics or social sign-in. Testers check correct and incorrect credentials, lockouts, sessions and how the app behaves when a session expires.

In practice: Logging in with the right email but wrong password should show a generic error, and five failed attempts should temporarily lock the account.

Related:AuthorizationSessionTwo-factor authentication

Also: AuthZ

Authorization answers "what can you do?". After logging in, users should only reach their own data and the features their role allows. Testers try to open other users' data or admin pages by changing URLs or IDs.

In practice: Changing /orders/1042 to /orders/1043 in the browser must not show another customer's order.

Related:AuthenticationSecurity testing

Also: Android backup

It can make a 'fresh' reinstall restore old settings or even login state. Testers check what should and shouldn't come back.

In practice: After reinstalling, the app skips onboarding because Auto Backup restored its old settings file.

Related:KeychainUpgrade testing

Also: Suggestions, Typeahead

Autocomplete speeds up search and forms by suggesting queries, addresses or products. Testers check relevance, keyboard selection, what happens on fast typing, and that suggestions don't show for the wrong query.

In practice: Typing "head" in a shop suggests "headphones" and "headphones wireless"; arrow keys and Enter should select a suggestion.

Related:DebounceDropdown

Also: Auto-fill

Autofill uses hints on each field (autocomplete on the web, textContentType on iOS, autofillHints on Android) to know what to put where: name, email, address, password, one-time code. Wrong or missing hints put values in the wrong fields or offer nothing. Autofilled values must also pass validation.

In practice: Tapping a saved contact above the keyboard fills name, email and address, but the city ends up in the postcode field because that field has the wrong autocomplete token.

Related:Password managerAutocompleteText field

Also: Recovery codes

Each code should work exactly once, be shown only at setup (or regenerated with re-authentication) and never be emailed in plain text.

In practice: Using backup code #3 logs you in; using #3 again is rejected.

Related:Two-factor authenticationOne-time password (OTP)

Also: Throughput

Low bandwidth makes large downloads slow, like images, videos and big app bundles. It's different from latency, which is about delay rather than capacity.

In practice: A 4 MB hero image takes over 10 seconds on a slow 3G connection.

Related:LatencyNetwork throttling

Also: Access token

After login, the server issues an access token that the app sends on every request in the Authorization header. Like a ticket, it isn't tied to a face: anyone who has it can use it until it expires or is revoked. Testers check that missing, invalid and expired tokens get 401 and that tokens are masked in bug reports.

In practice: GET /v1/users/me with "Authorization: Bearer eyJhbGci..." returns Anna's profile; without the header it returns 401.

Related:JWTAuthenticationRefresh token

Also: Beta, Pre-release testing

Beta builds go out through TestFlight, Google Play testing tracks or Firebase App Distribution. Feedback from beta users catches problems on devices and in situations the team didn't cover.

In practice: 200 external beta testers use the new checkout for a week before it ships to everyone.

Related:TestFlightFirebase App DistributionUser acceptance testing

Also: Bidi

Numbers, URLs and brand names inside RTL text can appear in the wrong order or jump around. It's a classic RTL test case.

In practice: An Arabic sentence with an order number shows the digits reversed.

Related:Right-to-left (RTL)Localization

Also: Biometrics, Face ID, Touch ID, Fingerprint login

Biometrics don't replace the password on the server; they unlock credentials stored securely on the device. Testers check enrollment, failed scans, fallback to passcode, and what happens when the user adds a new fingerprint.

In practice: After three failed Face ID scans, the banking app should offer the app PIN instead of locking the user out.

Related:AuthenticationPassword manager

Apps must offer a fallback (app password or device passcode) instead of leaving users stuck.

In practice: After five non-matching faces, Face ID is locked and the app should offer password login.

Related:Biometric authentication

Also: Specification-based testing, Behavioral testing

In black-box testing the tester treats the software as a closed box and designs tests from requirements and behavior, not from the code. Techniques like equivalence partitioning and boundary value analysis are black-box techniques. Most manual testing is black-box.

In practice: You test a login screen by entering valid and invalid credentials and checking the results, with no idea how the login code is written.

Related:White-box testingGrey-box testingEquivalence partitioning

Also: Blocked

A test is blocked when you can't reach or complete the thing it checks: the environment is down, test data is missing, or an earlier bug stops you getting there. Blocked is not Failed: nothing was proven wrong about this case's behavior yet. Always write the reason and, where there is one, link the issue that blocks it.

In practice: The card payment case is blocked because the payment provider's sandbox returns 503 errors. It's re-run when the sandbox is back.

Related:Execution statusBlockerEnvironmentTest run

Also: Showstopper

A blocker is the highest severity level: the bug prevents a key feature from working or blocks further testing, and there is no workaround. Blockers usually must be fixed before anything is released.

In practice: Nobody can log in on the new build, so none of the other features can be tested at all.

Related:SeverityPrioritySmoke testing

Also: Sheet

Bottom sheets can be modal (blocking the page) or standard (persistent). Testers check dragging, snap heights, scrolling inside, the keyboard and every way to close it.

In practice: Tapping 'Delivery time' opens a sheet with time slots and a Confirm button.

Related:ModalScrimDetent

Also: BVA

Boundary value analysis (BVA) tests the values at the edges of each partition, because developers often make off-by-one mistakes there (using < instead of <=). You test the boundary itself and the value just outside it.

In practice: For an age field accepting 18-60, test 17, 18, 60 and 61 (and often 19 and 59 too).

Related:Equivalence partitioningEdge case

Teams commonly use main (shared latest code), feature or fix branches (one piece of work), release branches (a version being stabilized) and hotfix branches (urgent fixes to what's live). Conventions differ between teams.

In practice: The fix for FD-327 lives on fix/FD-327-reorder-prices until it's merged into main.

Related:GitPull requestMergeRelease

Also: Decision coverage

Branch coverage is stronger than statement coverage: every if needs at least one test that goes each way.

In practice: An 'if member' check needs one test with a member and one without for full branch coverage.

Related:Statement coverageWhite-box testing

Also: Breadcrumbs, Breadcrumb trail

Breadcrumbs help users move up a level. The current page shouldn't be a link, the trail should match the real hierarchy, and screen readers shouldn't read the separators aloud.

In practice: Home › Camping › Tents › Basecamp Dome 2P, where 'Tents' takes you back to the tent list.

Related:Navigation bar

Also: Responsive breakpoint, Media query

Responsive sites use breakpoints (such as 640, 768, 1024 px) to rearrange content. Bugs cluster just around them, so testers check widths slightly below and above each breakpoint, not just common device sizes. (Not to be confused with a proxy breakpoint, which pauses a network request.)

In practice: At exactly 768 px the navigation menu disappears and the hamburger icon hasn't appeared yet, so there is no menu at all.

Related:Responsive designViewportWindow size classBoundary value analysis

It's the most common serious web risk: hidden buttons without server checks, admin pages open to normal users, or other users' data reachable by changing IDs.

In practice: A normal customer opens /admin by typing the URL, because the link was only hidden from the menu.

Related:IDORAuthorizationOWASP Top 10

Also: Browser support matrix

Teams choose it from analytics, often in tiers: fully tested, smoke tested, and best effort. Bugs in unsupported browsers may still be worth reporting if many users are affected.

In practice: Tier 1: Chrome, Safari iOS and Edge, latest two versions. Tier 2: Firefox and Samsung Internet.

Related:Cross-browser testingDevice matrix

Attackers automate thousands of guesses. Apps defend with lockouts, rate limiting, CAPTCHAs and strong password rules. Testers check that repeated wrong attempts are actually limited.

In practice: Entering a wrong 6-digit SMS code 20 times in a row should be blocked long before every code could be tried.

Related:Rate limitingAuthentication

Also: Issue

A bug is the everyday word for a defect: a flaw that causes the software to behave incorrectly or differently from requirements or reasonable user expectations. Bugs range from typos to crashes and data loss.

In practice: In a weather app, the temperature shows in Fahrenheit even though the user selected Celsius in settings.

Related:DefectErrorFailureBug report

Also: Defect life cycle

The bug life cycle (or defect life cycle) is the set of statuses a bug moves through, such as New, Open, Assigned, In Progress, Fixed / Ready for test and Verified / Closed, with side paths like Reopened, Duplicate, Not a bug, Cannot reproduce and Deferred. The exact statuses depend on the team and tool.

In practice: You report a bug (New), triage confirms it (Open), a developer takes it (Assigned, In Progress) and fixes it (Fixed), the fix reaches a test build (Ready for test), you retest it and it works, so you close it (Verified / Closed).

Related:Bug reportRetestingJira

Also: Defect report, Ticket

A bug report documents a defect with a short title, environment and build, steps to reproduce, expected result, actual result, severity, priority and evidence such as screenshots or videos. A good report lets a developer reproduce the bug without asking any questions.

In practice: Title: "Checkout: app crashes when tapping Pay with an expired card (Android 14, build 4.2.1)", followed by numbered steps, expected and actual results and a screen recording.

Related:SeverityPriorityReproducibleExpected resultActual result

Also: Version

A build is a version of the software produced from the source code at a certain point in time, usually with a number such as 2.4.0 (318). Testers always note which build they tested, because bugs may be fixed or introduced in a later one.

In practice: The bug report says "Found in build 3.1.0 (512) on Android". The developer fixes it in build 513 and you retest on that build.

Related:EnvironmentSmoke testingRelease

A button triggers an action immediately. Buttons come in levels of emphasis (primary, secondary, tertiary or text) and have several states: default, hover, pressed, focused, disabled and loading. Testers check every state, not just the happy tap.

In practice: On a checkout screen the "Place order" button should become disabled and show a spinner after the first tap, so a second tap can't create a duplicate order.

Related:UI stateDouble submitTouch target

Also: Browser cache

A cache keeps copies of previously loaded data, such as images, scripts or API responses, so they do not have to be downloaded again. Stale caches can make testers see old versions, so clearing the cache or using a private window is a common troubleshooting step.

In practice: The developer says the logo was updated, but you still see the old one until you do a hard refresh that bypasses the browser cache.

Related:CookieDevTools

Also: CTA, Primary action

The CTA is the most important action on a screen and is usually the most prominent button. A screen should have one clear primary CTA. Testers check it is visible, reachable above the keyboard and not hidden by banners or sticky bars.

In practice: On a product page the CTA is "Add to cart". If a cookie banner covers it on small phones, users can't buy anything.

Related:ButtonTouch target

Also: Subtitles

Captions help deaf and hard-of-hearing users, and anyone watching without sound. Testers check timing, accuracy and that sounds like [doorbell rings] are included.

In practice: The tutorial video has auto-generated captions that spell the product name wrong throughout.

Related:Accessibility testingWCAG

Hotel, airport and café Wi-Fi often show a captive portal. Apps see a 'connected' network that returns odd responses, which can confuse them.

In practice: On hotel Wi-Fi before logging in, the app shows 'Unexpected data' instead of 'No internet connection'.

Related:Network throttlingOffline mode

Also: SSL pinning

Pinning protects users from interception, but it stops testers from inspecting traffic with Charles or Proxyman. Teams usually provide debug builds without pinning.

In practice: Proxyman shows only failed connections for the production app, so you ask for a debug build.

Related:SSL certificateProxy tool

Also: Check box, Tick box

Checkboxes allow zero, one or many selections. Testers check the label is clickable, the mixed state in 'select all', keyboard Space, and required checkboxes like terms acceptance.

In practice: Ticking 'I agree to the terms' enables the Create account button; the label text should toggle it too.

Related:Radio buttonToggle switchIndeterminate state

A checklist is a list of items or conditions a tester verifies, without detailed steps or expected results for each one. It relies on the tester's knowledge and is great for quick checks, repeated reviews and areas that change often.

In practice: A login screen checklist: password is masked, show/hide toggle works, error appears for wrong password, keyboard type is email for the email field, 'Forgot password' link opens.

Related:Test caseSmoke testing

Also: Tag, Pill, Token

Chips often sit in a scrollable row above results. Testers check selected states beyond color, scroll hints, removing the right chip and duplicates.

In practice: 'Vegan', 'Open now' and 'Under €15' filter chips above a restaurant list.

Related:Segmented controlCheckbox

Also: Front-end validation

Client-side validation checks required fields, formats and lengths on the device, so users see mistakes immediately without waiting for the server. It improves the experience but can't be trusted: anyone can skip it by calling the API directly, editing the request or using an old app version. That's why the same rules must also exist on the server.

In practice: A sign up form shows "Enter an email like name@example.com" as soon as you leave the field, before anything is sent to the server.

Related:Server-side validationInput validationInline validation

Also: Time drift

Wrong device time makes TOTP codes fail, certificates look invalid and timestamps appear in the future. Testers change the device time on purpose to check.

In practice: A phone set 3 minutes behind generates authenticator codes that the server keeps rejecting.

Related:TOTPTime zone

Code review happens in a pull request. It catches mistakes early and spreads knowledge. Testers rarely review code, but the PR's description and changed files are a good hint about what to test.

In practice: The reviewer asks how the reorder fix handles a dish that's no longer on the menu.

Related:Pull requestStatic testingReview

A cold start loads everything from scratch. In a warm start the process is still alive but the screen must be rebuilt; in a hot start the app simply comes back to the foreground. Testers check launch time, splash screens and opening the app from a notification or deep link when it's fully closed.

In practice: Tapping a delivery notification while the app is fully closed should still open the order screen after the cold start.

Related:App lifecycleDeep link

Each yes/no condition doubles the combinations: 3 conditions give 8, 10 give 1,024. Testers use decision tables, pairwise testing and risk to choose a sensible subset.

In practice: A form with 12 optional yes/no settings has 4,096 combinations, far too many to test one by one.

Related:Pairwise testingDecision table

Builds are made from commits, so the commit hash is the most precise answer to "is this fix in my build?". Hashes are long but usually shown shortened to 7 characters.

In practice: Build 412 was made from commit 7f3d0b1, which includes the fix from a1c9e2f.

Related:GitBranchBuild

Compatibility testing checks that the software works correctly in different environments: device models, operating system versions, browsers, screen sizes and network types. It matters a lot in mobile because of fragmentation.

In practice: The sign-up button is cut off on a small Android phone with Android 11, but looks fine on a Pixel 8 with Android 15.

Related:Cross-browser testingFragmentationReal deviceResponsive design

If an app doesn't save its state, every configuration change can wipe form fields or scroll position. Testers trigger them deliberately mid-task.

In practice: Switching the system to dark mode while typing a review clears the text you typed.

Related:OrientationState persistence

Also: Cookie banner, GDPR banner

Under EU and UK rules, rejecting must be as easy as accepting, and the choice must actually be respected. Testers check the cookies set after each choice in DevTools.

In practice: After clicking 'Reject all', analytics cookies still appear in the Application panel, which is a bug.

Related:CookieThird-party cookie

Also: JavaScript error

Errors often explain why a button 'does nothing'. Testers copy the full message into bug reports, along with the steps that caused it.

In practice: Clicking 'On sale' does nothing, and the console shows 'TypeError: Cannot read properties of undefined (reading map)'.

Related:DevToolsBug report

Also: CD

With continuous delivery a person decides when to release. With continuous deployment every change that passes the pipeline goes to production without a human step. Mobile apps rarely do the latter because of store review.

In practice: The web shop deploys to production automatically after the pipeline passes; the app is submitted to the stores by hand.

Related:Continuous integration (CI)PipelineReleaseDevOps

Also: CI, CI/CD

CI servers run unit and integration tests on each change and report failures within minutes. Combined with continuous delivery, it gives testers a fresh build to test many times a day.

In practice: A developer's change breaks 12 unit tests and the CI pipeline turns red before the change reaches testers.

Related:DevOpsBuildUnit testing

When the app and the server are built by different teams, a contract test catches changes like a renamed field before they break the app.

In practice: The server renames 'price' to 'amount', and the contract test fails before the mobile app shows empty prices.

Related:APIIntegration testing

Also: Color contrast

Low contrast makes text hard to read, especially in sunlight or for people with low vision. WCAG AA requires 4.5:1 for normal text, 3:1 for large text and for UI parts like icons and input borders. Testers measure it with DevTools or contrast checkers.

In practice: Light grey placeholder text (#BBBBBB) on white has a ratio of about 1.9:1, far below the 4.5:1 minimum.

Related:WCAGAccessibility testing

Cookies are small pieces of text a website asks the browser to store to remember things like login sessions, preferences or the contents of a cart. The browser sends them back to the server with every request to that site. Testers check behavior with cookies cleared or blocked, and that consent choices are respected.

In practice: After clearing cookies you are logged out of the shop and your cart is empty, which is expected. But if you rejected analytics cookies and they are still set, that is a bug.

Related:CacheDevTools

Also: LCP, INP, CLS, Web Vitals

LCP measures how fast the main content appears, INP how quickly the page responds to input, and CLS how much the layout jumps around while loading. They give testers concrete numbers to report instead of "the page feels slow".

In practice: You tap "Add to cart" just as a banner loads and pushes the page down, so you hit "Remove" instead. That layout shift is what CLS measures.

Related:LighthousePerformance testing

Also: Promo code, Discount code, Voucher

Coupon logic is full of rules: minimum order value, expiry dates, one use per customer, which products qualify and whether codes can be combined. That makes it a favorite place for testers to look for money-losing bugs.

In practice: Applying SAVE10 twice should not give 20% off, and an expired code should show a clear message.

Related:Boundary value analysisIdempotency

Also: App crash

A crash is a failure where the app unexpectedly quits or freezes completely. Crashes are usually high severity. Testers report the exact steps, device, OS and build, and attach crash logs when available.

In practice: The app closes instantly whenever you open a notification for an order that was already canceled.

Related:FailureSeverityBug report

Also: Critical path, Key user flow

Smoke and regression suites are built around critical journeys, because if one breaks, the product effectively doesn't work.

In practice: For a food delivery app: open app, find a restaurant, add to cart, pay, track the order.

Related:Smoke testingRegression testing

Cross-browser testing verifies a website on the browsers its users actually use, such as Chrome, Safari, Firefox and Edge, on desktop and mobile. Browsers render pages and support features slightly differently, so layouts and features can break in only one of them.

In practice: A date picker works in Chrome but shows a plain text field in Safari on iPhone, so users cannot pick a date.

Related:Compatibility testingResponsive designDevTools

Also: XSS

If a site shows user input without escaping it, someone can enter HTML or JavaScript that runs for every visitor. A basic manual check is entering text like <b>test</b> into fields and seeing whether it appears as bold text instead of plain characters.

In practice: A product review containing <b>Great</b> shows the word in bold. The page is rendering user input as HTML and should be reported.

Related:SQL injectionSecurity testingInput validation

In a REST API, CRUD usually maps to POST, GET, PUT or PATCH, and DELETE. Testers chain them: create an item, read it back, update it, read again, delete it and confirm a final read returns 404.

In practice: POST /addresses → 201 with id 31; GET /addresses/31 → 200; PATCH → 200; DELETE → 204; GET /addresses/31 → 404.

Related:HTTP methodAPIEndpoint

Also: ISTQB Foundation, Certified Tester Foundation Level

CTFL is the Certified Tester Foundation Level, the entry-level certificate in the ISTQB scheme. The current syllabus is version 4.0, released in 2023, with six chapters: Fundamentals of Testing, Testing Throughout the Software Development Lifecycle, Static Testing, Test Analysis and Design, Managing the Test Activities, and Test Tools. The exam is multiple choice; whether employers value it varies by country and company.

In practice: A new tester studies the free syllabus and sample exams for a few weeks and passes the CTFL exam, which helps them get past the CV filter at an outsourcing company.

Related:ISTQBStatic testingEquivalence partitioningBoundary value analysis

Also: Keyset pagination

Offset paging ('skip 20') shows duplicates or skips items when data changes between pages. Cursor paging ('after item 4821') avoids that, which is why feeds use it.

In practice: A new product added while you browse doesn't push the last item of page 1 onto page 2 again.

Related:PaginationInfinite scroll

Also: Dark theme, Night mode

Dark mode is a system or app setting that switches the UI to dark colors. Testers check that all screens switch correctly, text remains readable with good contrast, and no images, icons or hard-coded colors become invisible.

In practice: In dark mode, the black logo on the login screen disappears against the dark background, and a help text stays dark grey on black.

Related:Accessibility testingCompatibility testing

Also: Migration

When an app changes how it stores data, every older format must be converted on update. Migrations that only handle the previous version break for users who skip versions.

In practice: Users who update from 1.0 straight to 2.0 lose their favorites because only the 1.9 → 2.0 migration exists.

Related:Upgrade testingState persistence

Also: DB

Most apps keep their data in a relational database: a set of tables linked by keys. The screens you test are just a view of this data, so checking the database tells you whether the app really saved what it showed.

In practice: The app says "Order placed", but the orders table has no new row. The bug is in saving, not in the screen.

Related:Table (database)SQLPrimary keyForeign key

Also: Calendar picker, Date input

Date pickers prevent typos in dates but bring their own risks: time zones, locale formats, leap years, disabled dates and ranges. Testers check boundaries such as month ends, Feb 29, past and future limits, and how dates are shown in different languages.

In practice: A hotel booking app should not let the check-out date be before the check-in date, and must show "03/04" correctly as 3 April in the UK and March 4 in the US.

Related:Time zoneLocaleBoundary value analysis

Also: DST, Summer time

On DST change days one hour doesn't exist (spring) and one hour happens twice (autumn). Alarms, bookings, reminders and "24 hours later" calculations often break on those days. Testers set the device date and time zone to a DST change to check.

In practice: A reminder set for 02:30 on the last Sunday of March never fires in Belgrade, because that time is skipped.

Related:Time zoneDate picker

Instead of sending a request on every keystroke, a debounced search waits until the user pauses (for example 300 ms). This reduces server load and flicker. Testers type fast and slow, and watch the network log for extra requests and out-of-order results.

In practice: Typing "headphones" should trigger one search request after you stop typing, not ten requests for "h", "he", "hea" and so on.

Related:Race conditionAPI

Decision table testing captures business rules with several conditions in a table, where each column is one combination of conditions and the expected outcome. It helps you avoid missing combinations.

In practice: Free shipping rules: is the user a member (yes/no) and is the order over 50 euros (yes/no)? The table shows all four combinations and whether shipping is free for each.

Related:State transition testingEquivalence partitioning

A deep link is a URL that takes the user directly to specific content in an app, for example a product page. Testers check deep links when the app is installed, not installed, logged out and already open.

In practice: A link shop.example.com/product/123 shared in a chat should open product 123 in the shopping app, or the website if the app is not installed.

Related:Push notificationUniversal Link / App LinkDeferred deep link

Also: Fault

A defect is an imperfection in a work product, usually code, that does not meet its requirements. Defects are caused by human errors, and when the faulty code runs it may cause a failure. "Bug" and "defect" are used interchangeably in practice.

In practice: The developer wrote "if (age > 18)" instead of "if (age >= 18)", so 18-year-olds cannot sign up. That line of code is the defect.

Related:ErrorFailureBug

If the app isn't installed, the user goes to the store, installs, and then lands on the linked content instead of the home screen.

In practice: An ad for a specific jacket leads to the store, and after install the app opens that jacket.

Related:Deep linkUniversal Link / App Link

Also: DoD

It usually includes code review, tests passing, acceptance criteria verified, no open critical bugs and documentation updated. Testers make sure 'done' really means done.

In practice: The developer says the feature is done, but it hasn't been tested on Android, which the Definition of Done requires.

Related:Definition of ReadySprintAcceptance criteria

Also: DoR

Typical items: testable acceptance criteria, designs attached, dependencies known, open questions answered. Testers help by asking questions before the sprint starts.

In practice: The story can't enter the sprint because it says 'show an error' without saying which error or when.

Related:Definition of DoneUser storyAcceptance criteria

Also: Snap point

Sheets with detents can be dragged between heights. Testers check every detent, small screens, landscape and large text.

In practice: Dragging the delivery-time sheet up snaps it from half height to full height.

Related:Bottom sheet

Also: Device cloud, Cloud device lab

Device farms let testers check devices they don't own, either manually in the browser or with automated tests.

In practice: A bug appears only on Samsung phones, so you reproduce it on a Galaxy A54 in a cloud device lab.

Related:Device matrixReal device

Also: Test matrix, Device coverage

A good matrix covers the most popular devices, the oldest and newest supported OS, a small screen, a low-end device and a tablet or foldable. It's usually based on analytics.

In practice: Your matrix has iPhone SE, iPhone 16, Pixel 8, Galaxy A15, a Xiaomi phone and an iPad.

Related:FragmentationDevice farm

Also: Push token, FCM token

Tokens change on reinstall and sometimes on update. Duplicate or stale tokens cause double notifications or pushes that never arrive.

In practice: After a cold start the app registers its token twice, so every order update arrives twice.

Related:Push notification

Code goes through automated builds, tests and deployments many times a day. Manual testers focus on exploratory testing, risky changes and checking features behind feature flags.

In practice: A fix merged at 10:00 is live for 5% of users by 11:00 and for everyone by the afternoon.

Related:Continuous integration (CI)Release

Also: Developer tools, Browser dev tools, Inspector

Browser developer tools (in Chrome, Firefox, Safari and Edge) let you inspect HTML and CSS, see console errors, watch network requests, simulate devices and throttle the connection. They are very useful for testers to gather evidence for bug reports.

In practice: The "Submit" button does nothing. In DevTools you open the Console and see a red JavaScript error, and in Network you see the request returned a 500 error. Both go in the bug report.

Related:APICross-browser testingGrey-box testingResponsive design

Also: Accents, Accent marks

Diacritics change how text is stored and compared. Users often type without them, so a good search treats "cafe" and "café" as the same. Names with diacritics must also be saved and displayed correctly everywhere.

In practice: Searching "cevapi" in a food app should still find "Ćevapi".

Related:LocalizationInput validation

A disabled control tells the user an action exists but isn't available yet, for example until a form is complete. It must look clearly disabled, ignore taps and keyboard input, and ideally make it obvious what's needed to enable it.

In practice: The "Continue" button stays disabled until the user accepts the terms. A classic bug: the button looks grey but still submits the form when tapped.

Related:UI stateButton

Also: Double click bug, Duplicate submission

If a button stays active while a request is in progress, a quick double tap or a slow network can send the same request twice. This can create duplicate orders, payments, messages or accounts. Buttons should disable or ignore repeated taps while working.

In practice: A user double-taps "Pay" on a slow connection and is charged twice for one order.

Related:ButtonRace conditionIdempotency

Also: Select, Picker, Combo box

Dropdowns, also called selects or pickers, save space when there are many options. On mobile they often open a native picker or a bottom sheet. Testers check long lists, search, default values, keyboard use and what happens near the screen edge.

In practice: A country dropdown with 195 options should be searchable and should show the selected country after the user closes it.

Related:Segmented controlModal

Also: Duplicate

Before filing, testers search the tracker for existing reports. Duplicates get linked to the original and closed. If you have new information, add it as a comment on the original.

In practice: You find a crash on the cart screen, search Jira for "cart crash", and add your device details to the existing ticket instead of creating a new one.

Related:Bug life cycleBug reportJira

Also: Font scaling, Large text, Text size

Dynamic Type is Apple's name for system-wide text size settings on iOS; Android has a similar font size and display size setting. Apps should respect it, and layouts should still work at the largest sizes without text being cut off or overlapping.

In practice: With the largest text size enabled, the "Continue" button label wraps onto two lines and gets clipped, so it reads "Contin".

Related:Accessibility testingTruncation

Also: Corner case

An edge case is a rare or extreme condition, such as the minimum or maximum value, an empty list, a very long name, no network, or a date like 29 February. Edge cases are where many bugs hide because developers often do not think of them.

In practice: A user named "Oluwaseun Adebayo-Williamson" has a name so long that it overlaps the logout button on the profile screen.

Related:Boundary value analysisNegative testingTruncation

Empty states happen for new users, after filters remove everything, or when a search finds nothing. A good empty state explains why it's empty and what to do next. Testers deliberately create empty states because developers often forget them.

In practice: Searching a shop for "xyzqwe" should show "No results for 'xyzqwe'" with suggestions, not a blank page or an endless spinner.

Related:Loading stateUI state

Also: Android Emulator

An emulator mimics both the hardware and operating system of a device, so you can run a mobile app on a computer. The Android Emulator in Android Studio is the most common example. It is free and convenient but does not perfectly match real devices in performance, sensors or manufacturer customizations.

In practice: You quickly check a layout on a Pixel 4 and a Pixel Tablet using Android emulators before testing on the real phones in the office.

Related:SimulatorReal deviceFragmentation

Also: API endpoint, Route

An endpoint combines a URL path and a method. API documentation lists endpoints with their inputs and outputs. Testers call endpoints directly, for example in Postman, to test logic without the UI.

In practice: POST /api/coupons/apply with code SAVE10 should return the discounted total, and an expired code should return a 400 with a clear error.

Related:APIHTTP methodJSON

Apps check entitlements to unlock features. Bugs appear when the entitlement isn't updated after renewal, cancellation or refund.

In practice: Premium should end when the entitlement expires on 15 November, not stay unlocked forever.

Related:In-app purchase

Also: Exit criteria

Entry criteria might be 'build deployed to staging, test data ready'. Exit criteria might be 'all high-priority tests run, no open blockers'. They stop teams from starting too early or finishing too soon.

In practice: Testing can't start because the staging environment still runs yesterday's build, so the entry criteria aren't met.

Related:Software testing life cycleTest plan

Also: Test environment

An environment is a complete place where the software runs, including its servers, databases, configuration and third-party connections. Teams usually have several, such as development, QA/test, staging and production, so that testing does not affect real users.

In practice: You test a new payment flow in the QA environment with fake cards, so no real money moves and no real customers see unfinished features.

Related:StagingProductionBuild

Epics group related stories, like 'New checkout'. Testers use them to see the bigger picture and plan end-to-end tests across stories.

In practice: The epic 'Apple Pay & Google Pay' contains 6 stories and 14 bugs.

Related:User storyJira

Also: Equivalence class partitioning, ECP

Equivalence partitioning divides input data into partitions (classes) where every value should be treated the same way by the software. Testing one representative value per partition gives good coverage with few tests. It covers both valid and invalid partitions.

In practice: An age field accepts 18-60. Partitions are below 18 (invalid), 18-60 (valid) and above 60 (invalid), so you might test 10, 35 and 75.

Related:Boundary value analysisBlack-box testingTest data

Also: Mistake

In testing vocabulary, an error is a mistake made by a person, for example a developer typing the wrong condition or an analyst writing an unclear requirement. Errors lead to defects in the product, which may then cause failures.

In practice: A developer misreads "minimum 8 characters" as "maximum 8 characters". That misunderstanding is the error.

Related:DefectFailure

It is one of the experience-based techniques. Experienced testers try inputs like apostrophes in names, double taps, 29 February, empty lists or a phone call mid-payment, because these break apps again and again.

In practice: You type O'Brien in the name field because apostrophes often break sign-up forms.

Related:Exploratory testingEdge caseFault attackExperience-based testing

Also: Validation message, Inline error

A good error message is visible, placed next to the problem, written in plain language and says how to fix it. Testers check the wording, the position, that it disappears when the problem is fixed, and that screen readers announce it.

In practice: "Password must be at least 8 characters" under the password field is helpful. "Error 422" at the top of the page is not.

Related:Input validationUI state

Also: Validation summary

On long forms, an error summary tells users how many problems there are and where. After submit, focus moves to the summary so screen readers announce it, and each item is a link that moves focus to the field. It complements, not replaces, the message next to each field.

In practice: "There are 2 problems: Enter your date of birth. Accept the Terms to continue." Tapping the first line jumps to the Day box.

Related:Error messageScreen readerFocus order

Also: Entity tag

The client sends the ETag back in an If-None-Match header. If the resource hasn't changed, the server answers 304 Not Modified with an empty body and the client uses its cached copy. With If-Match on an update, a stale ETag gets 412 Precondition Failed, which prevents lost updates. Testers check that the ETag changes when the data changes.

In practice: A restaurant's menu returns ETag "r3-v3". Sending If-None-Match: "r3-v3" returns 304 until the menu is edited.

Related:Cache

Also: Click propagation

If a button sits inside a clickable card, one tap can trigger both unless the developer stops it. It's behind many 'tapping the heart also opens the product' bugs.

In practice: Tapping the favorite heart on a product card adds it to favorites and also opens the product page.

Related:Button

Also: Error flow

Exception flows describe how the system handles failures such as a declined card, an expired link or a closed restaurant. Testers check the message, that no half-finished data is left behind, and whether the user can recover. Some teams call alternative and exception flows together 'extensions'.

In practice: The reset link is older than 30 minutes, so the app shows 'This link has expired' and offers to send a new one.

Related:Use caseAlternative flowNegative testing

Also: Test status, Test result

Passed means the actual result matched the expected one. Failed means it didn't, because of a defect in the product. Blocked means the case could not be run because something outside it is broken or missing. Retest means a linked bug was fixed and the case must be run again. Skipped or Not applicable means it was deliberately not run. Untested means nobody has run it yet. Exact names vary between tools.

In practice: Login passed, the coupon case failed, and the card payment case is blocked because the payment sandbox is down.

Related:Test runBlocked testRetestingTest execution

Also: Photo metadata

Apps must respect the orientation tag or photos appear sideways, and should usually strip location data before sharing photos publicly.

In practice: A marketplace listing photo still contains the seller's home GPS coordinates in its EXIF data.

Related:HEICPhoto picker

The expected result is the correct behavior you expect to see, based on requirements, designs or common sense. You compare it with the actual result to decide whether a test passes or fails. It should be specific enough that two testers would judge it the same way.

In practice: After tapping "Save" on the profile screen, the expected result is a toast saying "Profile saved" and the new name shown at the top.

Related:Actual resultTest caseBug report

Error guessing, exploratory testing and checklist-based testing are the classic experience-based techniques. They complement systematic black-box techniques by finding the bugs no requirement mentions.

In practice: A tester who has seen many sign-up forms tries an emoji in the name and a leap-day birthday, without being told to.

Related:Error guessingExploratory testingChecklistFault attack

In exploratory testing the tester explores the product without detailed scripts, using what they learn to decide what to try next. It is structured with a goal (a charter) and a time box, and findings are noted as you go. It is great at finding bugs scripted tests miss.

In practice: Charter: "Explore the photo editor for 30 minutes, focusing on undo and redo." You try rotating, cropping, undoing ten times, switching apps mid-edit and note everything odd.

Related:Ad hoc testingTest case

A failure is an event where the system does not do what it should, observed by a user or tester. It happens when defective code is executed. Not every defect causes a failure, for example if the faulty code is never reached.

In practice: The user taps "Pay" and the app crashes. The crash is the failure caused by a defect in the payment code.

Related:ErrorDefectCrash

Also: Software attack

Instead of guessing ad hoc, the tester starts from a list of possible defects or failures (from experience, past bug reports or published lists) and attacks the software to see if they exist. The idea was popularized by James Whittaker's book How to Break Software.

In practice: From a list of upload failures, the tester deliberately denies the camera permission, cuts the network mid-upload and picks a 12 MB photo.

Related:Error guessingExperience-based testing

Sites should test for a feature and offer a fallback. Guessing from the user agent breaks for new or less common browsers.

In practice: Express pay is hidden in browsers without the Payment Request API instead of throwing an error.

Related:User agentCross-browser testing

Also: Feature toggle, Remote config

Teams release code hidden behind flags and turn it on for testers, a small percentage of users, or everyone. Testers need to know which flags are on when they test.

In practice: The new checkout is only visible when the 'checkout_v2' flag is enabled for your test account.

Related:DevOpsRelease

Also: Mind map

Building a feature map while exploring shows what exists, what you've tested and where the risks are. It's especially useful when there's no documentation.

In practice: Rewards → Earn beans → Refunds: marked high risk, one open question for the product owner.

Related:Exploratory testingRisk-based testing

Also: Lab data, Real user monitoring, CrUX

Lab data is repeatable and great for debugging; field data shows what real users experience. They often disagree, and both are useful in a bug report.

In practice: Lighthouse looks fine on your laptop, but field data shows LCP of 4 s for most mobile users.

Related:LighthouseCore Web Vitals

Also: Magic number

Servers check the signature (sometimes called the magic number) because a file's name and extension are easy to fake. A renamed .exe still starts with 'MZ', not with a PDF or JPEG signature.

In practice: A file named invoice.pdf is rejected because its first bytes show it's actually a ZIP archive.

Related:MIME typeSecurity testing

Also: App Distribution, App Tester

Teams upload builds to Firebase App Distribution and testers get an email or an app to install them. It's common for Android test builds that aren't yet on Google Play, often alongside Google Play's internal testing tracks.

In practice: Each night the CI server uploads a new Android build, and testers install it from the App Tester app the next morning.

Related:TestFlightBuild

Also: Intermittent test

A flaky test gives inconsistent results on the same build, often because of timing, network or test data issues. Flaky tests reduce trust in testing and should be investigated, since they sometimes hide real intermittent bugs.

In practice: The "upload profile photo" test fails about one run in five because the upload sometimes takes longer than the test waits.

Related:ReproducibleRace condition

Also: FOUC, Theme flash

A common dark mode bug on the web: the page flashes white before switching to dark, because the theme is applied after the first render.

In practice: Reloading a dark-themed site at night briefly blinds you with a white page.

Related:Dark mode

Also: Rounding error

0.1 + 0.2 gives 0.30000000000000004 in most programming languages. Values must be rounded before display or comparison, especially money and ratings.

In practice: A rating filter shows '★ 3.5000000000000004+', and a 4.8-star product is filtered out at 4.8.

Related:Boundary value analysisSlider

Also: Tab order

Focus should follow the visual reading order. Jumps, skipped controls or focus landing on hidden elements confuse keyboard and screen reader users.

In practice: Pressing Tab after the email field jumps to the footer, skipping the password field.

Related:Keyboard navigationWCAG

When a modal is open, keyboard focus should move into it, stay inside it while it is open, and return to the element that opened it when it closes. Without this, keyboard and screen reader users get lost in content they can't see.

In practice: Pressing Tab repeatedly in a "Cookie settings" dialog should cycle through its buttons only, never reaching the links on the page underneath.

Related:ModalScreen readerWCAG

Also: Minimum version, Update prompt

Teams force updates when old versions can no longer work with the server. Testers check the version comparison, the store link, and that the prompt disappears after updating.

In practice: Version 1.10 keeps showing 'Update required' because the app compares '1.10' < '1.9' as text.

Related:Semantic versioningUpgrade testing

Also: FK

Foreign keys link tables together and are what you join on. If the database doesn't enforce them, you can get orphan rows: records that point to something that no longer exists. Testers look for these after deletes and migrations.

In practice: An order item with order_id = 1016 when there is no order 1016 is an orphan row, usually caused by deleting an order but not its items.

Related:Primary keyJOIN (SQL)Table (database)

Also: Device fragmentation

Fragmentation describes the large number of different device and OS combinations in use, especially on Android, where many manufacturers ship different screen sizes, hardware and custom versions of the OS. It means testers must choose a representative set of devices to test on.

In practice: The app works on Samsung and Pixel phones, but on a Xiaomi device the aggressive battery saver kills it in the background and notifications never arrive.

Related:Compatibility testingReal deviceEmulator

Functional testing checks that each feature behaves as specified: inputs produce the correct outputs and actions have the correct effects. It focuses on what the system does, not how fast or how securely it does it.

In practice: Checking that tapping "Add to cart" adds the product, updates the cart badge and shows the correct total price.

Related:Non-functional testingBlack-box testingRequirement

Gestures are the ways users interact with touch screens. Testers check that each supported gesture works, does not conflict with system gestures (like swipe-back on iOS) and has an alternative for users who cannot perform it.

In practice: Swiping left on an email to delete it also triggers the iOS back gesture when the swipe starts near the screen edge.

Related:Touch targetAccessibility testing

Also: Given/When/Then

Gherkin makes criteria concrete and testable, and tools like Cucumber can even run them as automated tests, a practice called behavior-driven development (BDD). Each scenario reads like a mini test case.

In practice: Given a running workout, When the user taps Pause, Then the timer stops and the button changes to Resume.

Related:Acceptance criteriaUser story

Also: Version control

Git records each change (a commit) with its author, date and message, and lets many people work in parallel on branches. Websites like GitHub, GitLab and Bitbucket host Git repositories and add pull requests and pipelines.

In practice: A developer's commit message 'Use current menu prices when reordering (FD-327)' links the code change to the bug.

Related:CommitBranchPull requestContinuous integration (CI)

Grey-box testing combines both views: you test through the user interface but use partial knowledge of internals, such as API calls, database tables or logs, to design better tests and confirm results.

In practice: After changing your email in the app, you check in DevTools that the API request sent the new email and returned a 200 response.

Related:Black-box testingWhite-box testingAPIDevTools

Also: Haptics, Vibration feedback

Haptics accompany long presses, toggles and successful payments. Testers check they fire once, at the right moment, and respect system settings.

In practice: A long press on a message gives one short tap of vibration as the menu opens.

Related:Gesture

Browsers can export a HAR (HTTP Archive) file from the DevTools Network tab. Attaching one to a bug report lets developers see exactly which requests failed. It can contain cookies and tokens, so share it carefully.

In practice: The checkout fails only for you. You export a HAR file, and the developer sees a 500 from the tax service.

Related:DevToolsBug report

Also: HEIF

Uploads need to accept HEIC or convert it, otherwise iPhone users get confusing errors. It belongs in every image upload test kit.

In practice: An iPhone photo upload fails with 'Something went wrong' because the server only accepts JPEG and PNG.

Related:EXIF

Also: Rule of thumb

Testers use heuristics like 'too small, too big, just right', CRUD, or consistency checks (HICCUPPS) to generate test ideas and judge results. They guide thinking; they don't guarantee answers.

In practice: Using the Goldilocks heuristic, you try 0, 1, a normal amount and 10,000 items in the cart.

Related:Test oracleExploratory testingTest tour

Also: Expert review

Several evaluators (Nielsen suggests three to five) inspect the product separately, note every problem with the heuristic it breaks and a severity, then merge their lists. It is fast and cheap, but it predicts problems rather than watching real users hit them, so it complements usability tests.

In practice: Three testers review a new checkout screen in an afternoon and find 14 issues, including missing feedback after Apply coupon.

Related:Usability heuristicsUsability testing

Buttons and tab labels must stay above it (inside the safe area), or users trigger the home gesture instead of the button.

In practice: The 'Checkout' button sits under the home indicator, and swiping it closes the app.

Related:Safe areaNavigation bar

Also: Patch

Hotfixes address serious production problems. Testers focus on verifying the fix and a quick targeted regression, because there's little time.

In practice: Payments fail for all Mastercard users, so a hotfix ships the same afternoon.

Related:ReleaseRegression testing

Also: HTTP verb, GET, POST

Each API request uses a method that says what it intends to do. Testers check that the right method is used (for example, never sending passwords with GET) and test what happens when requests are repeated.

In practice: Sending the same POST /orders twice creates two orders, while sending the same GET /orders twice changes nothing.

Related:APIHTTP status codeIdempotency

Also: Status code, Response code

Status codes are grouped: 2xx success, 3xx redirect, 4xx client errors (bad request, unauthorized, not found), 5xx server errors. Testers read them in DevTools or proxy tools to understand failures and to check that the app shows the right message for each.

In practice: The app says "Wrong password" but the network tab shows a 500, so the real problem is a server error, not the password.

Related:APIHTTP methodDevTools

Also: HttpOnly, Secure flag

Session cookies should be HttpOnly, Secure (HTTPS only) and have a SameSite setting. Testers check these flags in the DevTools cookie table.

In practice: The session_id cookie has no tick in the HttpOnly column, so any injected script could read it.

Related:CookieSessionSameSite

HTTPS protects passwords, cards and personal data from being read or changed in transit. Testers check that every page and API call uses HTTPS and that browsers show no "not secure" or mixed-content warnings.

In practice: The login page loads over HTTPS, but the profile picture comes from an http:// address and the browser shows a mixed-content warning.

Related:SSL certificateSecurity testing

An idempotent operation can safely be repeated: doing it twice has the same effect as doing it once. Payment and order systems rely on this to protect users from retries, refreshes and double taps. Testers check it by repeating actions on purpose.

In practice: Refreshing the "Order confirmed" page or tapping "Pay" twice should still result in exactly one order and one charge.

Related:Double submitAPI

POST requests aren't idempotent, so a retry after a lost response could create a second order or payment. With an Idempotency-Key header, the server stores the first response and returns it again for the same key. Payment APIs such as Stripe use this pattern, and there is an IETF draft standard for the header.

In practice: The app sends POST /orders twice with Idempotency-Key: order-001 after a timeout; both responses show order 1046 and only one order exists.

Related:IdempotencyDouble submitRetry with backoff

Also: Insecure direct object reference

If the server doesn't check that the logged-in user owns the requested object, changing /orders/1042 to /orders/1043 shows someone else's order. Test only with your own test accounts.

In practice: Logged in as test user Anna, you open /invoices/88 and see test user Ben's invoice.

Related:Broken access controlAuthorization

Also: Change impact analysis

Testers read the change description, ask developers what code was touched and think about everything that depends on it. The result is a focused regression subset instead of retesting everything.

In practice: A payment SDK update means retesting checkout, refunds, saved cards and order history, but not the profile photo upload.

Related:Regression testingRisk-based testing

Also: IAP, Subscription

The store handles payment; the app unlocks the content. Testers use sandbox or license-tester accounts, never real money, and check restore, refunds and subscriptions.

In practice: Buying 'Premium yearly' in the app charges through Google Play and unlocks premium on all the user's devices.

Related:EntitlementSandbox account

Also: Mixed state, Partially checked

A 'Select all' checkbox should show mixed when some items are selected, checked when all are, and empty when none are. Screen readers announce it as 'mixed'.

In practice: You select 2 of 5 emails, so the 'Select all' box shows a dash instead of a tick.

Related:Checkbox

Web apps store messages, drafts or cached data in IndexedDB. Testers inspect it in the DevTools Application panel and check it's cleared on logout when it should be.

In practice: An email web app keeps the last 500 messages in IndexedDB so the inbox opens offline.

Related:Local storageOffline mode

Feeds and shops often use infinite scroll instead of page numbers. Testers check the loading indicator, the end of the list, duplicates, scroll position after going back, and behavior on slow networks.

In practice: After opening a product and pressing Back, the list should return to the same position, not the top.

Related:PaginationLoading state

Also: Live validation, Real-time validation

Inline validation checks a field when the user leaves it (on blur) or while typing, and shows the message next to that field. Done well, it waits until the user has finished and clears the error as soon as the value is fixed. Done badly, it shouts "invalid" after the first letter.

In practice: After leaving the postcode field with "SW1A", the user sees "Enter a full postcode, like SW1A 1AA" right under it, and the message disappears once they type the rest.

Related:Input validationError messageClient-side validation

Also: Formatted input

Input masks help users enter structured data, but they often break paste, autofill, deleting and international formats. Testers check that pasting a full value works, that the mask fits every supported country, and that the saved value is clean.

In practice: A phone field forces the US format (555) 555-1234, so a UK number can't be entered and pasting "+44 7700 900123" turns into nonsense.

Related:Text fieldInput validationAutofill

Also: Form validation, Field validation

Validation checks format, length, required fields and allowed values. It can run on the client (instantly, for good UX) and must also run on the server (for security). Testers try valid, invalid, empty, too long and unusual inputs.

In practice: An email field should reject "anna@" and "anna.com" with a clear message, and accept "anna+shop@example.co.uk".

Related:Error messageNegative testingBoundary value analysis

Also: Install testing

It covers fresh installs, low storage, interrupted installs and what remains after uninstalling. Upgrade testing is its close cousin.

In practice: Installing the app with almost no free storage should show a clear message, not a half-installed app.

Related:Upgrade testing

Integration testing checks the interfaces and interactions between components or systems, such as the app and its backend API, or the app and a payment provider. Many bugs hide in the gaps between pieces that each work fine on their own.

In practice: The app and the payment service both work alone, but when combined the app sends the price in euros while the service expects cents, so a 10 euro order is charged 0.10.

Related:Unit testingSystem testingAPI

Also: i18n

Internationalization prepares the code (no hard-coded text, flexible layouts, Unicode, date and number formats). Localization then adds the actual translations and regional details.

In practice: Because texts are hard-coded, the 'Buy' button can't be translated without a new release.

Related:LocalizationLocale

Also: Interruption testing

Interruption testing checks how an app behaves when something else grabs the screen or the system's attention. The app should pause sensibly and resume without losing data or crashing.

In practice: A phone call arrives during a video upload. After the call, the upload should continue or clearly offer to retry.

Related:App lifecyclePush notification

Testers care most about the T: if you can't say how to test a story, it isn't ready. Stories that are too big are also hard to test well.

In practice: 'Improve the app' fails INVEST: it isn't small, estimable or testable.

Related:User storyDefinition of Ready

Also: International Software Testing Qualifications Board

ISTQB is a non-profit organization that publishes syllabi and exam rules for software testing certifications, from Foundation Level to Advanced and specialist modules. Exams are run through national member boards and accredited exam providers. Its syllabi and glossary are free to download from istqb.org.

In practice: A job ad for a consultancy asks for "ISTQB Foundation Level (CTFL) or willingness to obtain it".

Related:CTFL (ISTQB Foundation Level)

Jira, made by Atlassian, is a widely used issue tracker where teams manage user stories, tasks and bugs on boards and backlogs. Testers use it to file bug reports, follow the bug life cycle and link bugs to stories. Similar tools include Linear, Azure DevOps and YouTrack.

In practice: You create a Jira ticket of type "Bug", fill in steps, expected and actual results, attach a video and link it to the story "Wishlist".

Related:Bug reportBug life cycleScrum

Also: INNER JOIN, LEFT JOIN

An INNER JOIN keeps only rows that have a match in both tables. A LEFT JOIN keeps every row from the left table and fills the missing side with NULL, which is how testers find records that are missing their partner, such as orders without items.

In practice: orders LEFT JOIN order_items, keeping rows where the item side is NULL, lists every order that has no items.

Related:SQLForeign keyNULL

Also: Jira Query Language

JQL lets testers build precise filters, like all open bugs in the current release. Saved filters can power dashboards and notifications.

In practice: project = SHOP AND type = Bug AND status != Done ORDER BY priority DESC

Related:JiraBug life cycle

JSON (JavaScript Object Notation) represents data as keys and values, lists and nested objects. Testers read JSON responses to check that data is correct and complete, and edit request bodies to test validation.

In practice: The product page shows no price. The JSON response has "price": null, so the problem is in the data, not the app's layout.

Related:APIEndpoint

Teams use JSON Schema (often generated from an OpenAPI file) to check API responses automatically. A schema test catches renamed or missing fields, wrong types and unexpected fields that a status-code check would miss. Postman can validate a response with pm.response.to.have.jsonSchema(schema).

In practice: A schema that requires "total" to be a number fails when an endpoint suddenly returns "total": "24.99".

Related:OpenAPIJSONContract testing

Also: JSON Web Token

A JWT carries claims such as the user id (sub), the role and the expiry time (exp). The header and payload are only encoded, not encrypted, so anyone holding the token can decode and read them. Only the server can verify the signature, so decoding a token proves nothing about whether it's genuine.

In practice: Decoding Anna's token shows "sub": "u_1001", "role": "customer" and an exp 50 minutes from now. Changing the role to admin breaks the signature, and the API must answer 401.

Related:Bearer tokenAuthenticationSession token

Unlike Scrum, Kanban has no fixed sprints. Work moves across columns like To do, In progress, In test and Done, and limits stop too much piling up in one column.

In practice: The 'In test' column has a limit of 3, so developers help test before starting new work.

Related:ScrumJira

Also: Keyboard accessibility

Many people navigate without a mouse. Every interactive element must be reachable with Tab, in a logical order, with a visible focus indicator, and must work with Enter, Space or arrow keys as appropriate.

In practice: You can Tab to the "Accept cookies" banner but not to its buttons, so keyboard users can never close it.

Related:Focus trapFocus orderWCAGARIA

Also: Secure storage

Apps keep login tokens in the Keychain (Android has the Keystore). Because Keychain items can outlive the app, a reinstalled app may still find an old token.

In practice: After deleting and reinstalling the app, it greets you with the previous user's name because the old token was still in the Keychain.

Related:Password managerUpgrade testing

Also: Ping, Round-trip time

High latency makes every request slow to start, even on a fast connection. It's why apps feel sluggish on satellite or congested mobile networks.

In practice: A 600 ms round trip means an app that makes 5 requests in a row waits 3 seconds before showing anything.

Related:BandwidthNetwork throttling

It speeds up the first view of a page. Testers check that lazy content does load when scrolled to, doesn't cause layout jumps, and that the main image is not lazy-loaded.

In practice: Product photos further down the page load as you scroll, but the hero image appears immediately.

Related:Core Web VitalsPerformance testing

Also: Photo viewer, Media viewer

Lightboxes need swipe and arrow-key navigation, zoom, a counter, and a way to close that returns the user to the same thumbnail. Focus must stay inside while it's open.

In practice: Tapping the third listing photo opens it full screen, showing '3 of 12', and closing it returns to the same spot in the grid.

Related:ModalFocus trap

Lighthouse loads a page, measures it and gives scores from 0 to 100 with a list of concrete problems. Scores vary between runs and machines, so testers compare runs under the same conditions and focus on the specific findings.

In practice: Lighthouse reports that images on the home page are 4 MB each and that buttons have no accessible name.

Related:Core Web VitalsAccessibility testingDevTools

Specialists use tools like JMeter or k6 to simulate many users. Manual testers mainly report slowness they notice and help define realistic scenarios.

In practice: The site is tested with 5,000 simultaneous shoppers before a Black Friday sale.

Related:Stress testingPerformance testing

Network requests take time, so apps need a loading state that tells the user something is happening. Testers check that it appears, that it disappears when done, that the user can't trigger the same action twice, and what happens if loading never finishes.

In practice: On a slow 3G network, the search results screen should show a skeleton list instead of an empty white screen that looks broken.

Related:UI stateEmpty stateDouble submit

Also: localStorage, Session storage, Web storage

Local storage (localStorage) keeps key-value data in the browser for one origin until the site or the user clears it, and is shared by all tabs of that site. Its sibling, session storage (sessionStorage), works the same way but belongs to a single tab and is cleared when the tab closes. Unlike cookies, neither is sent to the server automatically. Testers inspect and edit both in DevTools, and check that nothing sensitive is stored there.

In practice: The shopping cart lives in localStorage, so it's still there after closing the browser, which is expected. A plain-text password stored there is a security bug.

Related:CookieIndexedDBCacheDevTools

A locale combines language and region, such as en-US or sr-RS. It changes how dates (3/4 vs 4.3.), numbers (1,000.50 vs 1.000,50) and currencies are displayed. Testers switch the device locale to check formatting and translations.

In practice: A price shown as "1,299.00" in English should appear as "1.299,00" with a Serbian locale.

Related:LocalizationTime zoneDate picker

Also: L10n

Localization (L10n) adapts a product for a specific market: translated text, date and number formats, currencies, and right-to-left layout for languages like Arabic. Testers check that translations fit, nothing is left untranslated and formats are correct. It builds on internationalization (i18n), which prepares the code so localization is possible at all.

In practice: In the French version, prices show as "1 299,00 €" and dates as 12/10/2026, but one button still says "Cancel" in English.

Related:TruncationCompatibility testingInternationalization (i18n)Locale

Also: adb logcat, Device log

When an Android app crashes, logcat usually contains the reason (the stack trace). Testers capture the relevant part and attach it to bug reports. On iOS, the Xcode console or the Console app serve the same purpose.

In practice: Reproduce the crash with the device connected, run adb logcat, and copy the lines starting with "FATAL EXCEPTION".

Related:CrashBug report

Also: Basic flow, Main flow

Also called the basic flow or main flow. It is written as numbered steps that alternate between what the actor does and how the system responds. Extensions (alternative and exception flows) branch off from its steps.

In practice: Open Orders, tap Reorder, check the cart, place the order, see the confirmation.

Related:Use caseAlternative flowException flowPositive testing

Also: Map Remote

Testers use it to simulate empty lists, huge lists, missing fields or error responses without changing the server.

In practice: You map GET /v1/products to a file with an empty list and check that the app shows a proper empty state.

Related:Proxy toolEmpty state

If the server copies the whole request body into the database, a user can add fields like "role": "admin" or "balance": 9999 to a normal profile update. Protected fields must be ignored or rejected. Test only on test environments with permission.

In practice: PATCH /users/me with {"name": "Ana", "role": "admin"} returns 200, and a follow-up GET shows role: admin.

Related:Broken access controlAuthorizationInput validation

Also: Merge conflict

After a merge, the next build of the target branch contains the change. When two branches changed the same lines, a developer has to resolve a merge conflict by hand.

In practice: PR #418 was merged as commit 7f3d0b1, so the next staging build, 412, contains the fix.

Related:BranchPull requestBuild

Also: Content type, Media type

Browsers and servers use MIME types to decide how to handle files. Wrong MIME types cause downloads instead of previews, or rejected uploads.

In practice: An upload form accepts application/pdf, but the server returns PDFs as text/plain, so they display as gibberish.

Related:File signatureHTTP status code

Browsers block or warn about mixed content because it weakens the page's security. Testers spot it in the DevTools console and the address bar's padlock.

In practice: The checkout page is HTTPS, but the payment logo loads from http://, and the console shows a mixed-content warning.

Related:HTTPSDevTools

Also: Stub, Fake

Developers mock payment providers, servers or databases so tests run fast and predictably. Testers should remember that mocked parts still need testing against the real thing.

In practice: The checkout passes every test with a mocked payment provider, but fails with the real one because of a different date format.

Related:Unit testingIntegration testing

Also: Dialog, Popup

Modals, or dialogs, demand attention for a decision or a short task. While open, the background is dimmed and not interactive. Testers check every way to close it, keyboard focus, scrolling behind it, and what happens on small screens or with the back button.

In practice: "Delete this photo?" with Cancel and Delete is a modal. Pressing Esc on web or the Android back button should close it without deleting anything.

Related:Focus trapToast

Options are mutually exclusive when only one can be selected at a time. Radio buttons and segmented controls work this way. Testers check that selecting one option always deselects the previous one and that it is never possible to have zero or two selected (unless designed).

In practice: In a shipping options list, choosing "Express" must deselect "Standard". If both look selected, that is a bug.

Related:Segmented control

Also: App bar, Tab bar, Toolbar

iOS and Android use the names differently: iOS calls the top bar a navigation bar and the bottom a tab bar; Material calls the bottom one a navigation bar. Testers check back titles, truncation, safe areas and re-tap behavior.

In practice: Re-tapping the Home tab should scroll the feed back to the top.

Related:TabsSafe area

Also: Hamburger menu, Side menu

Drawers hold many or secondary destinations. Testers check focus, scroll lock, closing after navigation, highlighting the current page and edge-swipe conflicts.

In practice: Choosing 'Orders' from the side menu should close the drawer and highlight Orders next time it opens.

Related:ModalScroll lockFocus trap

Negative testing checks how the system behaves when users enter wrong data or do unexpected things. The software should show clear errors and never crash, lose data or accept bad input.

In practice: Entering letters in a phone number field, or pasting a 5,000-character comment, should show a helpful message rather than crash the app.

Related:Positive testingEdge caseBoundary value analysis

Inside a bottom sheet, the list should scroll first and the sheet should only move when the list is at the top. Getting it wrong makes lists impossible to scroll.

In practice: Trying to scroll the time slots drags the whole sheet down instead.

Related:Bottom sheetGesture

Also: Throttling, Network conditioning

Testers simulate 3G, high latency, packet loss or offline mode with DevTools, proxy tools or device developer settings. Slow networks expose missing loading states, timeouts, race conditions and double submits.

In practice: With "Slow 3G" enabled, the login button can be tapped three times before the first request finishes.

Related:Loading stateRace conditionProxy tool

Non-functional testing checks quality characteristics rather than specific features. It covers performance, security, usability, accessibility, compatibility, reliability and more. A feature can work correctly and still fail non-functional testing.

In practice: The search works, but it takes 9 seconds to show results on a 3G connection. That is a non-functional (performance) problem.

Related:Functional testingPerformance testingUsability testingSecurity testingAccessibility testing

Also: NULL value

NULL behaves differently from normal values: nothing is equal to NULL (not even NULL), so you must write IS NULL or IS NOT NULL. Conditions like city <> 'Berlin' also skip rows where city is NULL, a common source of wrong counts.

In practice: WHERE coupon_id = NULL returns zero rows without any error. WHERE coupon_id IS NULL returns the orders placed without a coupon.

Related:Table (database)SQLJOIN (SQL)

Also: OAuth, OpenID Connect

OAuth 2.0 is an authorization framework: the user approves access, and the app receives an access token limited by scopes. "Sign in with Google" adds OpenID Connect on top of OAuth to also tell the app who the user is. Testers usually test the result: the login flow, the token's scopes, and that endpoints refuse tokens without the needed scope.

In practice: A fitness app asks for permission to read your steps from another service, but not your contacts; its token only has the steps scope.

Related:Social loginAuthorizationBearer token

Off-by-one errors come from mixing up "less than" and "less than or equal", or counting the start and end points twice. They hide at boundaries, which is exactly where boundary value analysis looks.

In practice: A hotel stay from 20 to 21 October is shown as "2 nights" and charged twice.

Related:Boundary value analysisEdge case

Also: Offline support

Good offline behavior means clear messages, cached data marked as possibly outdated, and safe syncing when the connection returns.

In practice: Offline, the shopping list still opens and new items are queued, then synced when the phone is back online.

Related:CacheNetwork throttling

Also: OTP, Verification code

OTPs are the most common second factor. Testers check expiry, reuse, resend, wrong attempts and how the code is entered (autofill, paste, leading zeros).

In practice: A 6-digit code 042917 arrives by SMS; it should expire after 5 minutes and stop working once used.

Related:Two-factor authenticationTOTP

Also: Allow once, Only this time

Apps must check permission status every time instead of remembering an earlier 'yes'.

In practice: Location was allowed once yesterday; today the app should ask again, not assume it still has access.

Related:App permissions

Also: Swagger, API spec

OpenAPI files power interactive API docs where you can read and try every endpoint. Testers compare real responses with what the spec promises.

In practice: The spec says price is a number, but the API returns "19.99" as a string, which is a bug.

Related:APIEndpointPostman

Also: OAT, Operational testing

It answers 'can we operate this?' rather than 'does it work for users?'. It's usually done by operations or platform teams.

In practice: The team restores last night's database backup to confirm recovery actually works before launch.

Related:Acceptance testingProduction

Also: Optimistic update, Rollback

Optimistic UI makes apps feel fast: a like, a toggle or an archive shows as done right away while the request runs in the background. If the server fails, the app must undo the change and tell the user. Testers simulate failures to check that rollback really happens.

In practice: You turn off "Offers" and the switch flips instantly. On a failing network it should flip back with a message, not stay off while the server still has it on.

Related:Toggle switchLoading stateState persistence

Also: Portrait, Landscape, Rotation

Rotating the device changes the screen size and, on Android, may recreate the screen entirely. Testers rotate during typing, loading and playback to find layout breaks and lost state.

In practice: Rotating the phone while a checkout form is half filled should keep every value you typed.

Related:State persistenceResponsive design

Also: Operating system version, iOS version, Android version

Apps support a range of OS versions, and behavior differs between them: permissions, notifications, back gestures and system dialogs all change. Bug reports must include the OS version, and test plans cover the oldest and newest supported ones.

In practice: The photo picker works on Android 14 but crashes on Android 10, the oldest version the app supports.

Related:FragmentationCompatibility testing

Also: OWASP

Published by the OWASP foundation, it's a common map for what to look for: broken access control, injection, security misconfiguration and more. Testers use it as a checklist of areas, not a step-by-step guide.

In practice: Your team's security checklist is organized by OWASP Top 10 categories.

Related:Security testingBroken access control

Also: Application ID, Bundle ID

adb commands and store listings use it to identify an app. Debug and release builds often have different package names so they can be installed side by side.

In practice: adb shell pm clear com.shopeasy.app.debug resets only the debug build.

Related:adb

On unstable networks some data is lost, causing retries, stalls and timeouts. Testers simulate it with network conditioners to find apps that hang.

In practice: With 10% packet loss, the video call freezes, but the chat should still deliver messages, perhaps late.

Related:LatencyNetwork throttling

Instead of loading thousands of results at once, the app loads page 1, then page 2 and so on. Testers look for duplicated or missing items between pages, wrong page counts and what happens when data changes while browsing.

In practice: The last product on page 1 appears again as the first product on page 2 after sorting by price.

Related:Infinite scrollAPI

Also: All-pairs testing

When many options combine (browsers × languages × payment methods), testing all combinations is impossible. Pairwise testing catches most interaction bugs with far fewer tests.

In practice: Instead of 4 × 3 × 5 = 60 combinations, 20 pairwise tests cover every pair of browser, language and payment method.

Related:Combinatorial explosionDecision tablePICT

Servers should never store or send plain passwords. Instead they store a hash, which can be checked but not reversed. A tester's clue that this is wrong: a "forgot password" email that contains your actual password.

In practice: Requesting a password reset sends a link to set a new password, never "Your password is Secret123!".

Related:AuthenticationSecurity testing

Also: iCloud Keychain, Passwords app

Many users never type passwords; their password manager fills them in. Forms must be marked up so autofill works, and paste must not be blocked. Testers try autofill on both mobile and web.

In practice: On the sign-in screen, iOS should offer the saved password above the keyboard. If the fields aren't recognized, users with long generated passwords get stuck.

Related:AutofillBiometric authenticationText field

Apps rarely process cards themselves. They send payments to a provider like Stripe, Adyen or PayPal. These providers have test modes with special test card numbers for approved, declined and 3-D Secure payments, which testers use instead of real cards.

In practice: Using the provider's "card declined" test number should show a clear payment error and keep the cart intact.

Related:IdempotencyDouble submitStaging

Performance testing measures speed, responsiveness and stability, for example load times, memory use and behavior with many users. It includes load testing and stress testing, which usually need tools. Manual testers still notice slow screens, lag and battery drain.

In practice: A news website loads in 1.5 seconds normally, but during a big event with thousands of visitors it takes 20 seconds or fails.

Related:Non-functional testingLoad testingStress testing

Also: Pre-permission prompt

Because iOS shows the system prompt only once, apps prime first and ask in context. Testers check the flow after 'Allow', 'Don't Allow' and later changes in Settings.

In practice: 'Turn on order updates so you know when your food arrives' appears before the system notification prompt.

Related:App permissionsPush notification

Also: Image picker

Modern pickers let users share selected photos only. Testers check the app works with limited access and doesn't demand full gallery permission unnecessarily.

In practice: The app opens the system photo picker and receives only the 2 photos the user chose.

Related:App permissionsEXIF

You describe parameters and values in a plain text model file, add constraints for impossible combinations, and PICT prints a small set of test rows that covers every pair. It can also generate higher-order (3-way and more) combinations. It is open source on GitHub.

In practice: A model with Browser, OS, Language and Payment lines produces about 16 to 20 rows instead of 144 combinations.

Related:Pairwise testingCombinatorial explosion

Also: CI pipeline, CI/CD pipeline

A typical CI/CD pipeline builds the code, runs unit tests and lint, deploys to a test environment, runs automated API and UI tests and prepares a release. A red pipeline means a stage failed; the log says which one and why.

In practice: PR #418's pipeline is red because one UI test timed out waiting for map tiles.

Related:Continuous integration (CI)Continuous delivery / deployment (CD)Flaky testBuild

Also: Hint text

Placeholders give an example of what to enter, such as "name@example.com". They should not replace a real label, because the hint vanishes as soon as the user types and is often low contrast. Testers check it is not mistaken for a pre-filled value.

In practice: A form that uses only placeholders as labels leaves users unsure what each field was for once they've typed in it.

Related:Text fieldWCAG

Also: Scrum poker

Each team member picks a card (often 1, 2, 3, 5, 8, 13) for a user story. Cards are shown together so nobody anchors on the first opinion; the highest and lowest explain their reasoning and the team votes again.

In practice: Developers say 3, the tester says 8 because the story needs four devices and a payment sandbox, and the team agrees on 5 after discussing it.

Related:Story pointsScrumUser story

Also: Subaddressing, Plus sign email

Many email providers deliver mail for name+tag@domain to name@domain, so people use tags to filter mail and see who shares their address. These addresses are valid, but forms often reject the plus sign by mistake.

In practice: Maya signs up as maya+groceries@mail.com and the form says "Enter a valid email address".

Related:Input validationEdge case

Also: Happy path testing

Positive testing checks that the system does what it should when the user does things correctly. It confirms the happy path works before you start trying to break it.

In practice: Entering a valid email and a strong password on the sign-up screen creates the account and opens the welcome screen.

Related:Negative testingEdge case

Preconditions are what must be true before you start; postconditions are the state you check afterward, such as data saved, money charged once or a link no longer working. Checking postconditions catches bugs that a happy confirmation screen hides.

In practice: After a reorder, a new order exists, the card was charged once and the original order is unchanged.

Related:PreconditionUse caseExpected result

Also: API client

In Postman you build requests (method, URL, headers, body), send them and inspect the response. Requests can be saved in collections, use environments for staging and production, and include automated checks.

In practice: You send POST /api/login with a wrong password 6 times in Postman to check that the account lockout works even without the app.

Related:APIEndpointJSON

A precondition is the state the system, data or device must be in before a test case begins. Writing preconditions down makes tests repeatable and stops confusion about why a test failed.

In practice: "User is logged in and has at least one item in the cart" is a precondition for testing the checkout screen.

Related:Test caseTest data

Also: PK

No two rows can share a primary key and it can't be empty. Other tables point to a row by storing its primary key, which is how orders know which user placed them.

In practice: Order 1007 is the only row in orders with id = 1007, even if two orders have the same total and date.

Related:Foreign keyTable (database)Database

Priority describes the urgency of fixing a bug, for example P1 (Highest) to P4 (Low), or simply high, medium and low. It is typically decided by the product owner or team lead, considering business impact, deadlines and how many users are affected. A low-severity bug can still be high priority.

In practice: The company logo is misspelled on the home page. Severity is low (nothing breaks), but priority is high because every visitor sees it.

Related:SeverityBug report

Also: Prod, Live

Production is the real, live system where customers use the app or website and real data and money are involved. Testing in production is done carefully and in limited ways, because mistakes affect real people.

In practice: After release, a tester does a quick check on production that the app opens, login works and the home screen loads, without placing real orders.

Related:EnvironmentStaging

Also: Breakpoint (Charles/Proxyman)

Breakpoints in Charles or Proxyman let testers change prices, status codes or fields on the fly to see how the app and server react. Not the same as a responsive layout breakpoint.

In practice: You pause the order request, change the total to 0.01 and see whether the server trusts it.

Related:Proxy toolMap Local

Also: Charles, Proxyman, Fiddler, HTTP proxy

Tools like Charles Proxy, Proxyman and Fiddler show every request and response, and can modify them, slow them down or block them. Testers use them to check what an app sends and to simulate server errors.

In practice: Using Proxyman's map local feature, you replace the real product list response with an empty one to test the empty state.

Related:APINetwork throttlingSSL certificate

Also: Pseudo-locale

Android and Xcode offer pseudo-locales. Any plain English text that remains is hard-coded, and anything cut off will break in long real languages.

In practice: '[Þļåçé öŕðéŕ !!!]' instead of 'Place order' shows the button is too narrow.

Related:LocalizationInternationalization (i18n)Truncation

Also: PR, Merge request, MR

The pull request page shows the changed lines, reviewers' comments and CI results. Some teams build a test version of every pull request so testers can check a change before it's merged.

In practice: PR #418 changes the price calculation; its checks are green and a teammate approved it.

Related:BranchMergeCode reviewContinuous integration (CI)

Also: Usage description

A missing purpose string can crash the app or block the feature. Testers check the text is present, specific and translated.

In practice: 'Snapbite uses your camera so you can add photos of your dish to reviews.'

Related:App permissionsPermission priming

Also: Push, Notification

Push notifications are alerts delivered by a server to a mobile device (or browser). Testers check permission prompts, delivery when the app is in the foreground, background or closed, the content, and that tapping the notification opens the right screen.

In practice: Tapping a "Your order has shipped" notification should open that order's tracking screen, not just the home screen.

Related:Deep linkReal device

Also: Testing portfolio

A QA portfolio is a page or repository, often on GitHub or Notion, that shows samples of a tester's work so employers can see it before an interview. For people without testing experience it usually holds practice-project artifacts: a test plan, test cases, bug reports and exploratory session notes. It must never contain confidential material such as take-home assignments or employer data.

In practice: A career changer's GitHub repository with a one-page test plan, eight test cases and three bug reports from a practice food delivery app, plus links to issues they filed in an open-source project.

Related:Test planTest caseBug report

Also: QA

Quality assurance (QA) is process-oriented: it focuses on how the team works so that quality is built in from the start. It includes things like defining standards, reviewing requirements, agreeing on a definition of done and improving workflows. In everyday job titles, "QA" is often used loosely to mean testing.

In practice: A team decides that every user story must have acceptance criteria before development starts, so developers and testers share the same understanding of "done".

Related:Quality controlSoftware testingAcceptance criteria

Also: QC

Quality control (QC) is product-oriented: it examines what has been built to find defects before it is released. Testing, inspections and reviews of the actual product are QC activities. QA tries to prevent defects, QC tries to detect them.

In practice: A tester runs the checkout test cases on the new build of a shopping app and reports that the discount code field rejects valid codes.

Related:Quality assuranceSoftware testing

Also: SQL query, Statement

A SELECT query reads data and changes nothing. INSERT, UPDATE and DELETE change data, so testers run them only on their own test database, never on shared or production data without permission.

In practice: SELECT name, email FROM users WHERE city IS NULL lists the users who have no city saved.

Related:SQLDatabaseJOIN (SQL)

Also: URL parameter, Query string

Query parameters make a page's state shareable and bookmarkable, and let Back and refresh restore it. They must never contain secrets such as passwords or tokens, because URLs end up in history and server logs.

In practice: Sharing shop.com/search?q=lamp&sort=price_asc with a friend should show them the same sorted results.

Related:APISecurity testing

A race condition happens when the result depends on which of two or more things finishes first, such as two network requests or a fast double tap. These bugs are often intermittent and hard to reproduce, so testers try fast, repeated and interrupted actions.

In practice: Tapping "Place order" twice very quickly creates two orders and charges the card twice.

Related:ReproducibleState persistence

Also: Radio, Option button

Radio groups are for a few visible, mutually exclusive options. Testers check grouping, default selection, arrow-key navigation and that the whole row is tappable.

In practice: Standard, Express and Same-day shipping as radio buttons: picking Express unselects Standard and updates the total.

Related:CheckboxMutually exclusiveSegmented control

Rate limiting protects servers and accounts from abuse, such as password guessing or spamming "Resend code". Testers trigger the limit on purpose and check the message and the cool-down.

In practice: "Resend code" becomes available again only after 30 seconds, and after five resends the user must wait an hour.

Related:Brute-force attackTwo-factor authentication

Also: Step-up authentication

Changing email, disabling 2FA or deleting an account should require proving it's really you, even in a logged-in session.

In practice: Before turning off two-factor authentication, the app asks for the current password again.

Related:AuthenticationTwo-factor authentication

Also: Physical device

Testing on real devices shows how the app really behaves with actual hardware, sensors, network conditions, performance, battery and manufacturer customizations. Teams test on a selection of popular devices and may use cloud device farms for more coverage.

In practice: A scrolling list is smooth on the emulator but stutters badly on a real budget Android phone with 3 GB of RAM.

Related:EmulatorSimulatorFragmentation

Also: prefers-reduced-motion

Animations and auto-playing content can cause discomfort. Apps should respect the setting by simplifying or stopping motion. Testers turn it on and check carousels, transitions and parallax.

In practice: With Reduce Motion on, the home carousel starts paused and slides change without a sliding animation.

Related:WCAGAccessibility testing

WCAG 1.4.10 asks that content works at 320 CSS pixels wide (like 400% zoom) without scrolling in two directions.

In practice: At 400% zoom the article becomes one column, but the data table still forces sideways scrolling, which is acceptable only for content like tables.

Related:Responsive designWCAG

Access tokens are short-lived so a stolen one stops working soon. A refresh token lets the app get a new access token without asking the user to log in again. It must stop working after logout, and with rotation each refresh returns a new refresh token and invalidates the old one.

In practice: After logging out of the banking app, replaying the old POST /auth/refresh request must return 401.

Related:Bearer tokenJWTSession

Also: Regression

Regression testing re-tests existing features after code changes, bug fixes or updates to make sure nothing that worked before is now broken. Because it is repeated often, it is a common candidate for automation.

In practice: After the team adds Google Pay to checkout, you re-run the card payment and PayPal tests to make sure those still work.

Related:RetestingSmoke testingSanity testingTest suite

A release is the act of delivering a specific build to users, for example publishing it to the App Store and Google Play or deploying it to a website. Releases are often preceded by a final round of regression and smoke testing.

In practice: Version 5.2 of a banking app is released to 10% of Android users first, and to everyone a week later if no serious crashes appear.

Related:BuildProductionRegression testing

Also: RC

If testing finds no blocking problems, the release candidate becomes the release. If it does, the team fixes them and builds a new candidate (RC2, RC3…).

In practice: RC1 has a crash on login, so the team ships RC2 a day later after retesting.

Related:BuildReleaseRegression testing

Also: Changelog, What's new

Release notes tell testers what to retest and where to look for regressions. Reading them first is the start of every new-build routine.

In practice: Build 318's notes list the fix for BUG-412, so you retest it first, then run a smoke test.

Related:BuildRetestingTestFlight

Large render-blocking files delay the first paint, so users stare at a white screen. They show up early in the DevTools waterfall.

In practice: A 1.1 MB script without defer keeps the page blank for 3 seconds on mobile.

Related:Core Web VitalsLighthouse

Also: Browser engine

Chrome, Edge and Samsung Internet use Blink; Safari uses WebKit; Firefox uses Gecko. On iOS, browsers use WebKit because of Apple's rules (only in the EU may they use their own engine, and few do), so testing 'Chrome on iPhone' mostly tests Safari's engine.

In practice: A layout bug appears in Safari and in Chrome on iPhone, but not in Chrome on Android, so it's a WebKit issue.

Related:Cross-browser testingBrowser matrix

A high reopen rate can mean rushed fixes, unclear bug reports or missing regression tests. It's a team health metric, not a way to blame individuals.

In practice: Out of 50 bugs fixed this sprint, 6 were reopened: a 12% reopen rate.

Related:Bug life cycleRetesting

Also: Reproducible bug, Repro

A bug is reproducible when following specific steps reliably triggers it. Reproducible bugs are much easier to fix. For intermittent bugs, testers note how often it happens (for example 3 out of 10 tries) and any conditions that seem related.

In practice: "The app crashes every time you rotate the phone while the video is loading" is reproducible. "It crashed once yesterday" is not yet.

Related:Bug reportRace conditionFlaky test

A requirement describes a capability or condition the product must have. Functional requirements describe behavior ("users can reset their password"), non-functional ones describe qualities ("the home screen loads in under 2 seconds"). Testers check requirements are clear and testable.

In practice: "The password must be at least 8 characters and contain one number" is a requirement you can turn directly into test cases.

Related:Acceptance criteriaUser storyTraceability matrix

Status says where the bug is in the workflow; resolution says how it ended. Two closed bugs can have very different resolutions.

In practice: Status: Closed. Resolution: Duplicate (of SHOP-2041).

Related:Bug life cycleDuplicate bug

Also: Responsive web design, RWD

Responsive design means the same website rearranges and resizes its content to fit the screen, using flexible layouts and breakpoints. Testers check layouts at many widths, in portrait and landscape, and look for overlapping, hidden or overflowing content.

In practice: On a 375-pixel-wide phone screen, the desktop navigation should collapse into a hamburger menu instead of overflowing off the side of the page.

Related:ViewportCross-browser testingDevTools

Also: Confirmation testing

Retesting means repeating the exact steps of a failed test after the developer fixes the bug, to confirm the fix. It targets one known defect, while regression testing looks for new, unexpected breakage elsewhere.

In practice: You reported that the app crashes when uploading a HEIC photo. In the new build, you upload the same HEIC photo again to confirm it works.

Related:Regression testingBug life cycle

Also: Exponential backoff, Retry

Good apps retry temporary failures, but slowly enough not to overload the server. Retries must never repeat actions that aren't safe to repeat, like payments without idempotency.

In practice: The app retries loading the feed after 1, 2 and 4 seconds, then shows a Retry button.

Related:TimeoutIdempotency

Also: Walkthrough, Inspection, Peer review

Reviews range from informal (a colleague reads it) to walkthroughs (the author presents it) and formal inspections (a checklist, roles and logged findings).

In practice: During a test case review, a colleague notices no case covers the account lockout.

Related:Static testingVerification

Also: Right to left, RTL layout

In RTL, back arrows, sliders, progress bars and swipe directions flip. Testers switch the device language to check mirroring and mixed RTL/LTR text.

In practice: In Arabic, the slider fills from right to left and the back arrow points right.

Related:LocalizationInternationalization (i18n)

Also: Risk-based prioritization

Rate each area's likelihood and impact, then test the highest scores first and deepest. It's how testers decide what to do when there isn't time to test everything.

In practice: Payments are high likelihood (new SDK) and high impact (money), so they're tested first; the 'About' screen comes last.

Related:Test planPriorityImpact analysis

Also: Notch, Safe area insets

Modern phones have screen areas where content can be hidden or hard to tap. Layouts should keep important content and buttons inside the safe area. Testers check edge-to-edge screens on devices with different cut-outs.

In practice: On an iPhone with a Dynamic Island, the app's back button is partly hidden behind it in landscape mode.

Related:OrientationFragmentation

Also: SameSite attribute

It helps protect against cross-site attacks. Lax is a common default; None requires the Secure flag. Wrong settings can also break legitimate logins from other sites.

In practice: After a bank redirects back from 3-D Secure, the shop logs you out because its session cookie is SameSite=Strict.

Related:CookieHttpOnly cookie

Also: License tester, Test account

Apple uses Sandbox Accounts and StoreKit testing; Google uses license testers. Subscriptions renew much faster in sandbox, so a month can pass in minutes.

In practice: A tester buys a monthly subscription with a sandbox account and watches it renew every few minutes.

Related:In-app purchaseStaging

Sanity testing is a narrow, quick check done after a small change or bug fix, to decide whether it is reasonable to continue with more testing. It is narrow but goes a little deeper into one area, and is usually unscripted.

In practice: Developers fixed the coupon field. You quickly apply a few coupons and check the total updates, before running the full checkout regression suite.

Related:Smoke testingRetestingRegression testing

Also: VoiceOver, TalkBack

A screen reader converts on-screen content into speech or braille and lets users navigate with gestures or a keyboard. VoiceOver (iOS, macOS), TalkBack (Android) and NVDA or JAWS (Windows) are common. Testers check that every element has a meaningful label, role and state, in a logical order.

In practice: With TalkBack on, an icon-only "Share" button is read as "Unlabelled button", so the user cannot know what it does.

Related:Accessibility testingWCAG

Also: Backdrop, Overlay

Tapping the scrim usually means cancel. It must block taps to the page behind; if taps pass through, users trigger actions they can't see.

In practice: Tapping the dimmed area to close the sheet also presses the + button behind it.

Related:ModalBottom sheet

Without it, scrolling inside an overlay scrolls the page underneath instead, and users lose their place.

In practice: Scrolling the open menu on a phone moves the product list behind it, which is a bug.

Related:ModalBottom sheetNavigation drawer

Scrum organizes work into sprints, with roles (product owner, scrum master, developers including testers) and events (sprint planning, daily scrum, sprint review, retrospective). Work is pulled from a prioritized product backlog.

In practice: Every morning the team has a 15-minute daily scrum where the tester mentions that the new filter screen is blocked by a crash.

Related:AgileSprintUser story

Also: Search field, Search box

Testers check the keyboard's Search key, clearing, cancel behavior, auto-capitalization and autocorrect, blank and spaces-only queries, and recent searches.

In practice: Typing 'pizza' and pressing Search on the keyboard shows pizza places; tapping × clears both text and results.

Related:AutocompleteDebounceText field

Face ID and Touch ID data never leaves the Secure Enclave. Apps only get a yes/no result and can use keys that are unlocked by it.

In practice: The banking app never receives your face data; it only learns that the Secure Enclave approved the unlock.

Related:Biometric authenticationAndroid Keystore

Security testing looks for weaknesses that could let attackers steal data, take over accounts or misuse the system. Manual testers can check basics such as session timeout, access to other users' data and how sensitive data is shown or stored.

In practice: You change the order ID in the URL from /orders/1001 to /orders/1002 and can see another customer's order. That is a serious security bug.

Related:Non-functional testingNegative testing

Also: Segmented button, Toggle button group

A segmented control is a horizontal set of two to five segments that act as one control, with one segment selected at a time. It switches between views or filters of related content. Its options are mutually exclusive.

In practice: An activity screen in a fitness app has a segmented control with "Day | Week | Month" that changes the chart below.

Related:Mutually exclusiveState persistenceTouch target

Also: Design token, Color token

Using semantic colors instead of hard-coded hex values lets the app adapt to dark mode and high contrast automatically. Hard-coded colors are a top source of dark mode bugs.

In practice: Text using the 'label' color turns white in dark mode; text hard-coded as #111 stays nearly black and becomes invisible.

Related:Dark modeContrast ratio

Also: SemVer

In 2.4.1, a major change bumps 2, new features bump 4 and bug fixes bump 1. The build number (e.g. 318) is separate and identifies the exact build.

In practice: Release notes for 3.0.0 hint at big changes, so you plan a much wider regression test than for 2.4.2.

Related:ReleaseBuildRelease notes

Also: Back-end validation

The server repeats the app's rules and adds checks only it can do, such as "email already registered", stock levels or rate limits. If the data is invalid it answers with an error (often 400 or 422) and saves nothing. Testers check it by sending invalid data straight to the API, around the app.

In practice: The app blocks users under 18, but a tester sends a sign up request from Postman with a 2012 date of birth. The server must reject it with a validation error.

Related:Client-side validationInput validationAPI

Service workers are a key part of progressive web apps (PWAs). Testers check offline behavior and that updates actually reach users instead of an old cached version.

In practice: After a release, users still see the old checkout because the service worker served cached files.

Related:CacheOffline mode

After login the server creates a session, usually tracked with a cookie or token. Sessions should expire after inactivity or logout, and should not survive in ways that put the user at risk. Testers check expiry, logout on all devices and the back button after logout.

In practice: After tapping Log out, pressing the browser back button should not show the account page again.

Related:AuthenticationCookie

Also: Auth token

After a successful login the server returns a token (often stored in a cookie or the device's secure storage). Every later request sends it. Logging out should invalidate it, and it should expire after a while.

In practice: After "Log out of all devices", a phone that was logged in should be sent back to the login screen on its next request.

Related:SessionAuthenticationCookie

Also: SBTM

Sessions (often 60–90 minutes) make exploratory work visible and reportable: what was tested, what was found and what's left. The debrief shares results with the team.

In practice: A 90-minute session on the checkout charter ends with 3 bugs, 2 questions and a note that refunds weren't covered.

Related:Exploratory testingTest charter

Severity describes the impact of a bug on the system or user: for example blocker or critical (crash, data loss, no workaround), major, minor or trivial (cosmetic). The tester usually proposes it, and it is confirmed or adjusted in triage. It is independent of how soon the bug will be fixed.

In practice: The app crashes on launch for all users: critical severity. A slightly misaligned icon: low severity.

Related:PriorityBug reportBlocker

Instead of testing only at the end, testers review requirements, designs and early builds. Questions asked in a planning meeting can prevent bugs that would otherwise take days to fix later.

In practice: Spotting that a story never says what happens when a coupon expires during checkout, before any code is written.

Related:Software development life cycleRequirementVerification

Also: iOS Simulator

A simulator imitates the software environment of a device without copying its hardware. The iOS Simulator in Xcode runs iOS apps on a Mac. It is fast and useful for layout and flows, but cannot fully test things like the camera, push notifications, real performance or battery.

In practice: You use the iOS Simulator to check the app on an iPhone SE and an iPhone 16 Pro Max screen size, then confirm camera scanning on a real iPhone.

Related:EmulatorReal device

Also: Skeleton loader, Shimmer

Skeletons feel faster than spinners and reduce layout shift. Testers check they're replaced by real content, an empty state or an error, never left on screen forever.

In practice: The orders list shows three grey bars while loading, then the real orders appear in the same places.

Related:Loading stateEmpty state

Also: Skip to content

Without it, keyboard users must tab through every header link on every page. It's a quick accessibility check on any website.

In practice: Pressing Tab on a news site shows 'Skip to content'; pressing Enter moves focus to the article.

Related:Keyboard navigationWCAG

Also: Range slider, Seek bar

Sliders suit approximate values like volume or a price range, not exact ones like age. Testers check min and max are reachable, rounding, keyboard support and what screen readers announce.

In practice: A price filter from €0 to €250 should actually reach €250, not stop at €240.

Related:Boundary value analysisFloating-point error

Also: Build verification testing, BVT

Smoke testing is a short, broad set of tests run on a new build to confirm that the critical functions work at all. If the smoke test fails, the build is rejected and deeper testing does not start. It is wide but shallow.

In practice: On a new build of a shopping app you check: the app launches, you can log in, search shows products, and you can open the cart. If login crashes, the build goes back to the developers.

Related:Sanity testingRegression testingBuild

Also: OAuth login, Sign in with Apple, Sign in with Google

The app asks an identity provider to vouch for the user instead of handling a password. Testers check first-time vs returning users, canceled consent, hidden emails (Apple relay addresses) and linking with an existing email account.

In practice: A user who signed up with email and later taps "Continue with Google" using the same address should land in the same account, not a new empty one.

Related:Authentication

Also: SDLC

The software development life cycle (SDLC) describes the phases of building software, typically requirements, design, development, testing, deployment and maintenance. Models such as Waterfall, V-model and Agile arrange these phases differently. Testing should start early in the SDLC, not only at the end.

In practice: A team building a fitness app gathers requirements, designs the screens, codes the features, tests them, publishes to the app stores and then fixes bugs reported by users.

Related:Software testing life cycleAgileRequirement

Also: Testing, QA testing

Software testing is the process of evaluating an app or website to find defects and to check that it meets its requirements and the needs of its users. It includes running the software (dynamic testing) and also reviewing documents and designs (static testing). Testing cannot prove there are no bugs, but it reduces the risk that serious ones reach users.

In practice: Before a food delivery app is released, a tester places orders, changes addresses, cancels orders and pays with different cards to see whether anything breaks or behaves unexpectedly.

Related:Quality assuranceQuality controlBugTest case

Also: STLC

The software testing life cycle (STLC) is the sequence of testing activities: requirement analysis, test planning, test case design, test environment setup, test execution and test closure. Each phase has its own inputs and outputs. It runs alongside the SDLC.

In practice: For a new "Pay with Apple Pay" feature, a tester reviews the requirements, plans which devices to use, writes test cases, prepares a test environment, runs the tests and finally writes a summary report.

Related:Software development life cycleTest planTest case

Also: Iteration

A sprint is a time-boxed iteration in Scrum, usually one to four weeks, at the end of which the team should have a potentially releasable increment. Testing happens during the sprint, not after it.

In practice: In a two-week sprint the team commits to "Save favorite stores" and "Dark mode toggle", and both must be developed and tested by the sprint review.

Related:ScrumAgileUser story

Also: Structured Query Language

SQL (Structured Query Language, said "S-Q-L" or "sequel") is how people and programs talk to databases such as PostgreSQL, MySQL, SQL Server and SQLite. Testers mostly use it to read data: to check what the app really saved, find test data and investigate bugs.

In practice: After placing an order in the app, a tester runs SELECT * FROM orders WHERE id = 1007 to confirm the total and status were saved correctly.

Related:DatabaseQueryJOIN (SQL)SQL injection

If an app builds database queries from raw user input, an attacker can type special text that changes the query. Manual testers don't need to exploit it, but entering characters like a single quote (') into fields and reporting server errors is a useful basic check.

In practice: Typing O'Brien into a name field crashes the sign-up with a database error. That's a sign the input isn't handled safely.

Related:Cross-site scripting (XSS)Security testingInput validation

Also: Responsive images

Together with the sizes attribute, it lets phones download small thumbnails while large screens get sharper images. Testers check the Network panel for oversized downloads.

In practice: A 400px-wide thumbnail should download a ~40 KB file, not the 4 MB original.

Related:Lazy loadingPerformance testing

Also: TLS certificate, HTTPS certificate

Certificates make HTTPS work. To inspect encrypted traffic, proxy tools install their own certificate on the test device. Some apps use certificate pinning and refuse that, which is why test builds often disable it.

In practice: After installing the Charles certificate on a test iPhone, you can read the JSON the app sends during checkout.

Related:Proxy toolHTTPSCertificate pinning

Also: Stacktrace, Backtrace

Developers use the stack trace to find the failing line. Testers copy the relevant part, usually starting at the exception name, into the bug report.

In practice: logcat shows 'FATAL EXCEPTION … NullPointerException at DeepLinkParser.kt:27', the line the developer needs.

Related:CrashLogcat

Also: Pre-production, Pre-prod

Staging is an environment that copies production settings, infrastructure and often realistic data. It is the final place to test a release before it goes live, to catch problems that only appear in a production-like setup.

In practice: The new release passes all tests in QA, but on staging the image uploads fail because the storage configuration is different. Better to find it here than in production.

Related:EnvironmentProduction

State persistence is the app's ability to keep data and UI state, such as form input, selected tabs or scroll position, across navigation, screen rotation, backgrounding or restarts. Lost state is a very common mobile bug.

In practice: You fill in half a long form, switch to your email app to copy a code, and come back to find all fields empty.

Related:Race conditionSegmented control

When the OS kills a backgrounded app to free memory, users expect to return exactly where they were. Apps must save and restore screens, form input and scroll positions; testers simulate the kill on purpose.

In practice: After an hour in the background, reopening the banking app should still show the half-filled transfer form, not the home screen.

Related:App lifecycleState persistence

State transition testing models the system as states and the events that move it between them, then tests valid and invalid transitions. It suits features where the same action has different results depending on the current state.

In practice: After three wrong PINs a banking app goes from "Active" to "Locked". You test that a fourth attempt stays locked, and that resetting the PIN moves it back to "Active".

Related:Decision tableBug life cycle

Also: Line coverage

It's the simplest code coverage measure (code coverage is the umbrella term). 100% statement coverage can still miss bugs, because a decision may never take its 'false' path.

In practice: Tests for a discount function run every line, but never the case where no discount applies.

Related:Branch coverageWhite-box testing

Reviews, walkthroughs, inspections and static analysis tools find problems early and cheaply. Dynamic testing, by contrast, runs the software.

In practice: Reading a user story and noticing it contradicts the design mockup is static testing.

Related:VerificationShift-leftReview

Also: Quantity stepper, Spin button

Testers check the limits, typed values, long-press repeat, rapid taps against the server, and what happens at zero.

In practice: A cart quantity stepper should stop at the 4 items in stock instead of letting you pick 5.

Related:Boundary value analysisDouble submit

Story points compare stories with each other instead of counting hours. In most teams they cover all the work to finish a story, including testing.

In practice: A story estimated at 8 points is expected to be roughly as big as two 3-point stories plus some uncertainty.

Related:Planning pokerSprintUser story

The goal is to learn the limits and make sure failures are graceful, with clear errors and full recovery afterwards.

In practice: At 3x the expected traffic the ticket shop slows down but keeps working; at 5x it shows a queue page instead of crashing.

Related:Load testingPerformance testing

Also: One link per card

It gives a large tap area with only one link for screen readers, while other buttons in the card still work on their own.

In practice: Tapping anywhere on a restaurant card opens it, and VoiceOver reads it as one link instead of five.

Related:Event bubblingScreen reader

Also: Schema.org, JSON-LD

It powers rich search results like ratings, prices and breadcrumbs. Testers can validate it with Google's Rich Results Test.

In practice: A product page includes JSON-LD with its name, price and availability, so search results show '€89 · In stock'.

Related:Breadcrumb

System testing evaluates the whole application end to end, in an environment close to production. It covers both functional and non-functional requirements and is where most manual testers spend their time.

In practice: You test the full journey in a travel app: search a flight, choose seats, pay, receive the confirmation email and see the booking in "My trips".

Related:Integration testingAcceptance testing

Also: SUS

Created by John Brooke in 1986. Participants rate 10 statements from strongly disagree to strongly agree, and the answers convert to a score from 0 to 100. The score is not a percentage; around 68 is often cited as average. It is useful for comparing versions, not for finding specific problems.

In practice: After a usability round, the redesigned checkout scores 78 on SUS, up from 61 for the old one.

Related:Usability testing

Also: Database table

Each row is one record (one user, one order) and each column is one property (email, total, status). Every column has a type, such as text, integer or date, and may or may not allow empty (NULL) values.

In practice: The users table has columns id, name, email and city, with one row per registered user.

Related:DatabasePrimary keyNULL

Also: Tab strip, Tab row

Tabs should keep each view's state, show which one is active, work with swipe on Android and arrow keys on the web, and fit labels in every language.

In practice: Active · Delivered · Returns tabs on an orders screen, each keeping its own scroll position.

Related:Segmented controlBottom sheet

Also: Take-home task, Home assignment, Test assignment

A take-home assignment is a practical task in a hiring process that the candidate does independently within a deadline, for example "test our website's checkout and send bug reports and a short summary within 48 hours". Reviewers look at how well the candidate follows the instructions, prioritizes by risk, writes reproducible reports and communicates what was and wasn't tested.

In practice: A candidate gets a staging link and 48 hours, spends about four hours testing, and sends a summary on top, bug reports sorted by severity, and a "Not tested, and why" section.

Related:Bug reportSeverityTest summary reportStaging

Also: Test card number

Payment providers publish special card numbers that simulate outcomes like approved, declined or insufficient funds, without moving real money. Testers always use these on test environments, never real cards.

In practice: Stripe's 4242 4242 4242 4242 approves any test payment; other published numbers trigger a decline or a 3-D Secure challenge.

Related:Payment gateway3-D SecureStaging

A test case describes exactly how to test one thing: preconditions, steps, test data and the expected result. Anyone on the team should be able to follow it and get the same outcome. Good test cases are specific, independent and easy to repeat.

In practice: "TC-012: Log in with a valid email and wrong password. Expected: an error message 'Incorrect email or password' is shown and the user stays on the login screen."

Related:Test scenarioTest suiteExpected resultPreconditionTest data

Also: Test repository, Test case library

The repository holds the master copy of every test case with fields like priority, type and automation status. Cases are written once and reused in many test runs, release after release, so the repository has to be kept up to date when the product changes.

In practice: FoodDash's repository has sections for Login, Cart, Checkout and Tracking. For release 2.0, the tester picks 40 of its 300 cases into a new run.

Related:Test caseTest suiteTest runTest management tool

Also: Session charter

A charter keeps exploration focused, for example 'Explore checkout with expired cards to discover payment error handling'. Sessions are usually time-boxed to 60–90 minutes.

In practice: Charter: 'Explore the search filters on a slow network to find loading and race-condition issues.' 60 minutes.

Related:Exploratory testing

Test coverage measures the extent to which something has been exercised by tests. For manual testers it usually means requirement coverage (how many requirements have tests) or feature, device and browser coverage. High coverage reduces risk but never guarantees zero bugs.

In practice: You tested the checkout on Chrome and Safari but not Firefox, so your browser coverage for checkout is two out of three supported browsers.

Related:Traceability matrixTest plan

Test data is any data needed to run a test: usernames, passwords, card numbers, product IDs, files to upload and so on. Good test data covers valid, invalid and unusual values, and never uses real customers' personal information.

In practice: For a sign-up form you might prepare emails like anna@test.com (valid), anna@test (invalid) and a 254-character email (boundary).

Related:Test casePreconditionBoundary value analysis

Also: Testing estimate, Effort estimation

A test estimate covers understanding the requirement, test design, environment and data setup, execution on every device or browser, bug reporting, retest and regression, reporting and a buffer for blockers. It is a forecast, not a promise, and it is updated when scope or assumptions change.

In practice: "Testing scheduled orders is about five days, three to eight, assuming the build is on staging Monday."

Related:Three-point estimationWork breakdown structureTest planRisk-based testing

During execution a tester follows each case, notes the actual result, attaches evidence such as screenshots or logs for anything that isn't a clean pass, sets a status and links a bug report to every failure. In Xray, "Test Execution" is also the name of the Jira issue type that holds a run.

In practice: The tester runs TC-202, sees the expired code SPRING5 accepted, marks it Failed, attaches a screen recording and links bug FD-242.

Related:Test runExecution statusActual resultBug report

Also: TestRail, Xray, Zephyr

It keeps suites organized, tracks which tests passed on which build, and links test results to stories and bugs.

In practice: The release dashboard shows 182 of 190 regression tests passed on build 318, with 3 failures linked to bugs.

Related:Test suiteTest runTest case repositoryRegression testingJira

Also: Oracle

A spec is the obvious oracle, but testers also compare against the product itself, similar products, user expectations, standards and claims in marketing. When there's no spec, naming your oracle makes a bug report convincing.

In practice: 'Expected: 120 beans, the same number the Home screen shows' uses consistency within the product as the oracle.

Related:HeuristicExpected result

A test plan describes the scope, approach, resources, schedule, environments, risks and entry/exit criteria for testing a specific project or release. It keeps everyone aligned on what will and will not be tested. In agile teams it is often short and lives in a wiki page.

In practice: The test plan for a new app release says: test on iOS 17-18 and Android 13-15, focus on the new checkout, skip the legacy loyalty screen, and stop testing when no open critical bugs remain.

Related:Test strategySoftware testing life cycleTest coverage

Also: Testing pyramid

Lower levels are cheaper and faster, so most checks belong there. Manual and end-to-end testing sit at the top, focused on real user journeys and things automation misses. An upside-down 'ice-cream cone' means too much slow, manual testing.

In practice: A team with 2,000 unit tests, 200 API tests and 20 end-to-end tests follows the pyramid.

Related:Unit testingIntegration testingSystem testing

Also: Test cycle, Test execution (Xray)

A run is created from cases in the repository, tied to one build and one environment or device, and assigned to testers. As they work, each case gets an execution status. The run is the record of what was actually tested, where, by whom and with what outcome. Tools name it differently: test run, test cycle or test execution.

In practice: "FoodDash 2.0.0 regression, build 412, iPhone 15 (iOS 18)": 120 cases, 104 passed, 9 failed, 3 blocked, 4 untested.

Related:Test executionExecution statusTest case repositoryTest summary report

A test scenario is a one-line description of a situation or user journey worth testing. It says what to test, not exactly how. One scenario usually becomes several detailed test cases.

In practice: Scenario "User adds an item to the cart" could become test cases for adding one item, adding the same item twice, adding an out-of-stock item, and adding while offline.

Related:Test caseTest suiteUser story

A test strategy sets out the general principles of how testing is done: which levels and types of testing are used, what is automated, which tools and environments are standard, and how risk is handled. It is broader and more stable than a test plan, which applies it to one project.

In practice: A company's mobile test strategy says that every release gets automated unit tests, a manual smoke test on five real devices and exploratory testing of new features.

Related:Test planTest coverage

A test suite is a collection of test cases organized around a feature, a type of testing or a goal. Grouping tests makes it easy to plan, run and report on them together.

In practice: A "Payments" suite in a banking app contains all test cases for card payments, transfers and payment history, and is run before every release.

Related:Test caseRegression testingSmoke testing

Also: Test closure report

It helps the team decide whether to release. Good reports are short, honest about risks and clear about what was not tested.

In practice: 'Tested 142 cases, 3 open medium bugs, payment refunds not tested on Android 10 — recommend release with a known-issue note.'

Related:Software testing life cycleTest plan

Also: Tour

Tours give exploration a focus. The money tour follows features that earn revenue; the back button tour presses Back everywhere; the interruptions tour adds calls and notifications.

In practice: On the back button tour you discover that pressing Back after paying shows the Pay screen again, enabled.

Related:Exploratory testingHeuristic

Developers upload a build, and invited testers install it through the TestFlight app. Builds expire after 90 days. Testers check the version and build number in TestFlight before testing and report which build they used.

In practice: The bug is fixed in build 2.4.0 (318). You update through TestFlight and retest on that exact build.

Related:BuildFirebase App DistributionRelease

Also: Text input, Input field, Edit text

Text fields are the most common form control. They have a label, an input area, optional helper text, and states like focused, filled, error and disabled. Testing them covers validation, keyboard types, copy and paste, length limits and special characters.

In practice: The phone number field on a delivery app should open the numeric keyboard and accept "+381 64 123 4567".

Related:PlaceholderInput validationError message

Also: Thinking aloud

The facilitator asks the participant to keep talking ('I'm looking for... I expected...') and stays neutral, without helping. Hearing expectations and confusion in the user's own words explains why a problem happens, not just that it happens.

In practice: 'I'd expect the address to be under Profile... no... maybe Settings?' tells you the option is hard to find.

Related:Usability testing

Browsers increasingly block or limit them. Features that rely on third-party cookies, like some embedded logins or widgets, can break in Safari and Firefox.

In practice: The embedded chat widget logs you out on every page in Safari, because its third-party cookie is blocked.

Related:CookieConsent banner

It often happens during or just before backlog refinement. Each role brings a different view: what's needed, how to build it, and how it could break. Testers' questions about edge cases often change the story before any code is written.

In practice: In a 15-minute three amigos session, the tester asks what happens to a paused workout after a phone call, and a new criterion is added.

Related:User storyAcceptance criteriaShift-left

Also: PERT estimate, Three-point estimate

Instead of one number, each task gets O (optimistic), M (most likely) and P (pessimistic). The PERT formula (O + 4M + P) / 6 gives a weighted expected value, and the sums of O and P give a range for the whole job.

In practice: Test design takes 3 h at best, 4 h most likely and 7 h at worst: (3 + 16 + 7) / 6 ≈ 4.3 h.

Related:Test estimationWork breakdown structure

Also: TTFB

A slow TTFB points to the server or backend, not the page size. In DevTools it appears as the 'Waiting for server response' part of a request.

In practice: The recommendations API waits 3 seconds before sending anything; that's a backend issue to report.

Related:Core Web VitalsAPI

Also: Timezone, UTC offset

Servers often store times in UTC while users see local time. Converting between them causes bugs around midnight, daylight saving changes and travel. Testers change the device time zone to catch them.

In practice: A booking made at 23:30 in Belgrade shows up on the next day in the app because the server stored it in UTC and the app displayed it without converting.

Related:Date pickerLocale

Without a timeout, an app may spin forever on a dead connection. Testers check that a timeout exists, is reasonable, and leads to a clear message with a retry.

In practice: After 30 seconds without a response, the app should show 'Can't connect. Try again.' instead of an endless spinner.

Related:Loading stateRetry with backoff

Also: Snackbar, Notification banner

Toasts (called snackbars in Material Design) confirm an action without interrupting the user. They disappear after a few seconds and may include one action, such as Undo. Testers check timing, stacking, position, readability and screen reader announcements.

In practice: After archiving an email, "Conversation archived · Undo" appears at the bottom for four seconds. Tapping Undo should restore the email.

Related:ModalUI state

Also: Switch, Toggle

A toggle switch represents a binary setting that takes effect immediately, without a Save button. Testers check that the visual state matches the real setting, that the change persists, and what happens if saving the setting fails.

In practice: Turning off "Push notifications" in settings should stop notifications right away and still show "off" after restarting the app.

Related:State persistenceUI state

Also: Hint

Touch screens have no hover, so tooltips must also work on focus or tap, be dismissible with Esc, and never be the only way to name a button.

In practice: Hovering or tabbing to an ⓘ icon shows 'Fee: €1.50 for transfers under €100'.

Related:ModalToastARIA

Also: Authenticator app code

Both sides use a shared secret and the current time, so a phone with a wrong clock produces codes the server rejects. Servers usually accept one step either side to allow small differences.

In practice: Google Authenticator shows a new 6-digit code every 30 seconds for your bank account.

Related:One-time password (OTP)Clock skew

Also: Touch threshold

If the threshold is too small, taps become accidental swipes; too large, and swipes feel sluggish. Gesture bugs often come down to these thresholds.

In practice: A tiny wobble while tapping an email opens the swipe-to-delete action instead.

Related:Gesture

Also: Tap target, Hit area

A touch target is the tappable area of a control, which can be larger than the visible icon. Guidelines recommend at least 44x44 points on iOS and 48x48 dp on Android; on the web, WCAG 2.5.8 asks for at least 24x24 CSS pixels (44x44 is the comfortable target). Small or overlapping targets cause mis-taps and accessibility problems.

In practice: The small "x" to close a banner is only 16 pixels wide, so users keep tapping the ad behind it instead.

Related:Accessibility testingGestureSegmented control

Also: RTM, Requirements traceability matrix

A requirements traceability matrix (RTM) maps requirements to test cases, and often to test results and bugs. It shows at a glance which requirements are tested, which are not, and what is affected when a requirement changes.

In practice: Requirement REQ-07 "User can change language" maps to TC-31, TC-32 and TC-33. If REQ-07 has no test cases, the gap is obvious.

Related:RequirementTest coverageTest caseTest runImpact analysis

Also: Bug triage

Teams triage in regular meetings or asynchronously. Testers bring evidence, product owners weigh business priority, and developers estimate effort.

In practice: In Monday's triage, the checkout crash becomes P1 for this sprint and the icon misalignment goes to the backlog.

Related:SeverityPriorityBug life cycle

Truncation is when text is shortened or clipped, sometimes intentionally with an ellipsis (...), sometimes as a bug where important information is hidden. It often appears with long names, translations, small screens or large text sizes.

In practice: In German, the button "Save changes" becomes "Änderungen speichern" and shows as "Änderungen spei", with the rest cut off.

Related:LocalizationDynamic TypeEdge case

Also: 2FA, MFA

Two-factor authentication (2FA) adds a second step, such as a one-time code sent by SMS, a code from an authenticator app (TOTP) or a security key. MFA (multi-factor authentication) is the broader term for two or more factors. Testers check expired codes, wrong codes, resending, pasting the code and what happens if the user loses access to the second factor.

In practice: A bank app sends a 6-digit code by SMS. A code older than 5 minutes should be rejected, and "Resend code" should not be spammable.

Related:AuthenticationSessionOne-time password (OTP)TOTPBackup codes

Also: Component state, Interaction state

Every interactive element has several visual states. Designers define them, and developers often forget some. Testing each state, and the transitions between them, catches many visual and functional bugs.

In practice: A text field has default, focused, filled, error and disabled states. If the error state looks identical to the default state, users won't notice their mistake.

Related:ButtonDisabled stateLoading state

Also: Component testing

Unit testing checks individual units of code, such as a function or class, in isolation. It is the first test level, almost always automated and written by developers. Fast unit tests catch many bugs before testers ever see the build.

In practice: A developer writes an automated test checking that the function calculateTotal() returns 25.00 for two items priced 10.00 and 15.00.

Related:Integration testingWhite-box testing

Also: App Link

iOS calls them Universal Links and Android App Links. They rely on verification files hosted on the website, so a misconfigured domain opens the browser instead of the app.

In practice: Tapping https://shop.example/order/42 in an email opens the order in the app, or on the website if the app isn't installed.

Related:Deep linkDeferred deep link

Also: Update testing, Migration testing

Real users don't install fresh; they update. Upgrade testing installs an old version, creates data, then updates to the new build and checks logins, saved items, settings and database migrations.

In practice: After updating from 3.1 to 3.2, users are logged out and their saved addresses are gone. A fresh install would never show this bug.

Related:Regression testingState persistence

Also: Nielsen's heuristics, 10 usability heuristics

Nielsen's 10 usability heuristics (from Nielsen Norman Group) include visibility of system status, user control and freedom, consistency and standards, and error prevention. Evaluators review a screen against them to find problems without needing real users.

In practice: A Delete account button with no confirmation breaks the 'Error prevention' heuristic.

Related:Heuristic evaluationUsability testingHeuristic

Usability testing evaluates whether users can achieve their goals effectively, efficiently and with satisfaction. It often involves watching real users try tasks and noting where they get confused. Testers also flag usability issues they notice during normal testing.

In practice: Five users are asked to change their delivery address. Three of them cannot find the option because it is hidden inside "Account > Other".

Related:Accessibility testingNon-functional testingValidationUsability heuristicsThink-aloud protocol

A use case names the actor, the preconditions, the main success scenario, the alternative and exception flows, and what must be true afterward (postconditions). Testers turn each flow into at least one test scenario.

In practice: 'Reorder a previous order' in a food delivery app: the happy path, plus sold-out dishes, a closed restaurant and a declined card.

Related:Use case testingActorMain success scenarioAlternative flowException flowPostcondition

Also: Scenario testing

A use case describes how a user reaches a goal, like 'buy a train ticket'. Tests follow the main flow and each alternative, such as a sold-out train or a declined card.

In practice: Main path: search, choose seat, pay. Alternatives: seat taken during payment, card declined, session timeout.

Related:Use caseTest scenarioBlack-box testing

Also: UAT, End-user testing

User acceptance testing (UAT) is acceptance testing done by the intended users or their representatives, using realistic scenarios. Its goal is to confirm the product is fit for real use, not to find small technical bugs.

In practice: Branch staff at a bank use the new internal app for a week to process real-looking requests and confirm it supports their daily work.

Related:Acceptance testingValidation

Also: UA string

Websites sometimes change behavior based on the user agent. DevTools can fake it to imitate other devices, but that doesn't change the real rendering engine, so it can't replace testing on real browsers.

In practice: The site shows "Your browser is not supported" to the latest Firefox because it only checks for the word "Chrome" in the user agent.

Related:Cross-browser testingDevTools

Also: Story

A user story describes a small piece of value in the form "As a [type of user], I want [goal] so that [reason]." It is a placeholder for a conversation and is completed by acceptance criteria that say when it is done.

In practice: "As a shopper, I want to save items to a wishlist so that I can buy them later."

Related:Acceptance criteriaRequirementSprint

Also: V model

Requirements pair with acceptance testing, system design with system testing, architecture with integration testing and code with unit testing. Test planning starts as soon as each document exists.

In practice: While developers design the system, testers already write system test cases from the same design document.

Related:Waterfall modelUnit testingAcceptance testing

Validation checks whether the product fulfills its intended use and the real needs of its users. It answers "Are we building the right product?" A product can pass verification and still fail validation if the requirements were wrong.

In practice: The 4-digit PIN works exactly as specified, but in user testing older customers keep forgetting it and ask for Face ID instead. The product is verified but not validated.

Related:VerificationAcceptance testingUsability testing

Verification checks whether a work product meets its specified requirements. It answers "Are we building the product right?" and includes reviews, walkthroughs and tests against the spec.

In practice: The spec says the PIN field accepts exactly 4 digits. You verify that it rejects 3 and 5 digits and accepts 4.

Related:ValidationRequirement

The viewport is the part of the page currently visible to the user. Its width determines which responsive layout is shown. In DevTools you can change the viewport size to simulate different devices.

In practice: At a viewport width of 768 pixels the product grid should show two columns, and at 1280 pixels it should show four.

Related:Responsive designDevTools

Also: List virtualization, Windowing

Feeds and tables with thousands of rows recycle a small number of row elements as you scroll. Testers check scrolling speed, jumping, and that find-in-page or screen readers still work.

In practice: A 10,000-item order history stays smooth because only about 20 rows exist in the page at any time.

Related:Infinite scrollPerformance testing

Also: Waterfall

Requirements, design, build, test and release happen one after another. It's predictable, but bugs in requirements are often found very late, when they're expensive to fix.

In practice: A bank's core system is planned for a year, with a 3-month testing phase at the end.

Related:Software development life cycleV-modelAgile

Also: Web Content Accessibility Guidelines

WCAG (Web Content Accessibility Guidelines) are published by the W3C and define testable success criteria at levels A, AA and AAA. Most laws and companies target level AA. Although written for the web, they are also widely applied to mobile apps.

In practice: WCAG AA requires a contrast ratio of at least 4.5:1 for normal text, so light grey text on a white background often fails.

Related:Accessibility testingScreen reader

Also: Structural testing, Glass-box testing

White-box testing designs tests from the internal structure of the code, for example making sure every branch of an if-statement runs. It is mostly done by developers, often through unit tests.

In practice: A developer sees the discount code has three branches (expired, valid, already used) and writes a test for each one.

Related:Black-box testingGrey-box testingUnit testing

Compact is under 600 dp, medium 600–839 dp and expanded 840 dp and up; newer guidance adds large (1200 dp+) and extra-large (1600 dp+). Foldables and split screen move apps between classes while they run. iOS has a similar idea called size classes (compact or regular width and height).

In practice: Unfolding the phone moves the app from compact to expanded, and it should switch to a two-pane layout.

Related:OrientationResponsive designBreakpoint

Also: Multi-step form, Stepper (steps)

Each step validates its own fields; Back must keep the data, the indicator must match the visible step, and errors should return the user to the right step.

In practice: Shipping › Delivery › Payment › Review, with 'Step 2 of 4' announced to screen readers.

Related:Input validationState persistence

Also: WBS, Work breakdown

A work breakdown structure (WBS) lists the tasks needed to finish a piece of work, each small enough to picture (roughly an hour to a day). Estimating the tasks and adding them up is more accurate than guessing one big number.

In practice: "Test the tipping feature" becomes: read the story, design cases, set up test data, run on iPhone, run on Android, report bugs, retest and regression, write the summary.

Related:Test estimationThree-point estimation

If users can avoid a bug easily, it often gets a lower priority. Testers note known workarounds in bug reports because they affect how urgent the fix is.

In practice: The "Save" button doesn't work on the profile screen, but changes save when you press Enter. That's a workaround, though the bug still needs fixing.

Related:PrioritySeverity