Interview Prep

Software testing is the process of checking that an app or website works as expected and meets the needs of its users, and finding defects before real people run into them.

It includes running the software (clicking, tapping, typing, breaking things on purpose) and also reviewing requirements and designs early, before any code is written.

Why it matters:

• Cost. A bug found while reviewing a requirement costs minutes to fix. The same bug found after release can mean hotfixes, app store reviews and support tickets.
• Trust and money. If a banking app shows the wrong balance or a shop’s checkout fails, users leave and may not come back.
• Safety and legal risk. Some bugs leak personal data or break accessibility laws.

For example, if a food delivery app charges the card but does not create the order, users lose money and the company loses customers and reputation.

One important point: testing cannot prove there are no bugs. It reduces risk and gives the team information to decide whether the product is ready to release.

Learn more: What Is Software Testing?

The three terms are related but focus on different things:

	Focus	Goal	Example
Quality assurance (QA)	The process	Prevent defects	Agreeing that every user story needs acceptance criteria before development
Quality control (QC)	The product	Detect defects	Checking a finished build before release
Testing	The product	Find defects and give information	Running checkout test cases on build 4.2

A simple way to remember it: QA asks “Are we working in a way that produces quality?” and QC asks “Does this product have quality?” Testing is the main hands-on activity of QC.

For example, in a shopping app team, QA might mean introducing requirement reviews and a definition of done. QC and testing mean actually installing the new build and trying to add items, apply coupons and pay.

In real life, job titles mix these up. A “QA Engineer” usually spends most of the day testing, but a good one also helps improve the process, which is real QA.

Learn more: What Is Software Testing?

These three words describe a chain of cause and effect:

1. Error (mistake): a person does something wrong. A developer misreads “users must be 18 or older” and writes age > 18.
2. Defect (bug, fault): the result of that mistake in the product. The line age > 18 is now in the code.
3. Failure: the defect is executed and the system behaves wrongly. An 18-year-old tries to sign up and sees “You are too young”.

So: error → defect → failure.

Two useful details:

• Not every defect causes a failure. If the faulty code is in a screen nobody ever opens, the defect exists but no failure is observed yet.
• Failures can also come from the environment, for example a server outage or a full phone storage, not only from defects.

As testers we usually observe failures, and then we report them so developers can find and fix the underlying defect.

Learn more: What Is Software Testing?

Verification: “Are we building the product right?” It checks whether the product matches its specification and requirements. Reviews, walkthroughs and most test cases are verification.

Validation: “Are we building the right product?” It checks whether the product actually solves the user’s problem in real use. User acceptance testing, usability testing and beta programs are validation.

Example: a banking app login

• The spec says: “User logs in with a 6-digit PIN.” You test that 6 digits are accepted, 5 and 7 are rejected, and the error messages are correct. Everything passes, so the feature is verified.
• In a beta, many users forget the PIN and ask for Face ID or fingerprint login. Support tickets grow. The feature is not validated, because the requirement itself did not fit users’ needs.

	Verification	Validation
Compares against	Specification	User needs
Typical activities	Reviews, test cases	UAT, usability tests, beta
Can be static?	Yes (document reviews)	Mostly dynamic

Both are needed: verification without validation gives a perfectly built wrong product.

Learn more: Verification vs Validation

All three are about checking a new build, but they differ in scope and purpose.

	Smoke	Sanity	Regression
Question	Is this build stable enough to test?	Does this fix/change work?	Did anything that worked before break?
Scope	Wide and shallow	Narrow and a bit deeper	Wide and deep
When	Every new build	After a small fix or change	Before release, after significant changes
Duration	Minutes	Minutes	Hours to days (often automated)

Example with a shopping app:

• Smoke: a new build arrives. You check the app opens, login works, search shows products, cart and checkout open. If login crashes, the build is rejected.
• Sanity: the developer fixed the coupon field. You apply a few coupons and check the total updates correctly, before spending time on deeper testing.
• Regression: before releasing, you run the full checkout, account and search suites to make sure the new coupon logic did not break card payments, shipping costs or order history.

Note that teams use “smoke” and “sanity” a bit differently, so it is fine to say you follow your team’s definitions.

Learn more: Regression and Smoke Suites

Retesting (also called confirmation testing) means running the same test that failed again on a new build, to confirm the bug is fixed.

Regression testing means re-testing other existing features to make sure the change did not break anything that used to work.

Example: in a photo app, you reported “App crashes when uploading a HEIC photo.”

• Retesting: on the new build, you upload the same HEIC photo, on the same device and OS, following the same steps. It works, so you move the bug to Verified/Closed.
• Regression: you also upload JPG and PNG photos, try uploading from the camera, check that profile pictures still display and that the gallery still loads. The fix touched the upload code, so anything near it could be affected.

	Retesting	Regression
Target	One known bug	Features that already worked
Test cases	Same steps as the failed test	Existing regression suite
Planned in advance?	No, triggered by a fix	Yes, run regularly
Good for automation?	Rarely	Very often

You usually do both: retest first, then run regression around the change.

Learn more: Types of Testing

A test plan is a document that describes the scope, approach, resources and schedule of testing for a specific project or release. Its real purpose is alignment: everyone knows what will be tested, what will not, and when testing is “done”.

Typical contents:

• Scope: features in scope and, just as important, out of scope.
• Approach: types of testing (functional, regression, accessibility…), manual vs automated.
• Environments and devices: for example iOS 17-18 on iPhone SE and 15, Android 13-15 on Samsung and Pixel, Chrome/Safari/Firefox for web.
• Test data and accounts needed.
• Roles and responsibilities.
• Schedule and milestones.
• Risks and mitigations: “payment sandbox may be unstable, so we will book extra time”.
• Entry criteria: when testing can start (build deployed, smoke test passed).
• Exit criteria: when testing stops (all high-priority tests run, no open critical bugs).
• Deliverables: test cases, bug reports, summary report.

In agile teams, a test plan is often a one-page wiki per release or epic rather than a large formal document. A test plan is different from a test strategy, which describes the company-wide approach, and from test cases, which describe individual checks.

Learn more: Writing a Test Plan

The STLC describes the testing activities from start to finish. A common version has six phases:

Phase	What happens	Output
1. Requirement analysis	Review requirements and user stories, ask questions, find unclear or untestable parts	List of questions, testable requirements
2. Test planning	Decide scope, approach, devices, effort, risks	Test plan
3. Test case design	Write test scenarios, test cases and test data	Test cases, test data, traceability matrix
4. Environment setup	Prepare servers, builds, devices, accounts	Ready test environment, smoke test passed
5. Test execution	Run tests, report bugs, retest fixes	Test results, bug reports
6. Test closure	Evaluate exit criteria, summarize, share lessons learned	Test summary report

Example: for a new “Pay with Apple Pay” feature, you first ask what happens if the card is declined (phase 1), decide to test on three iPhones (phase 2), write test cases for success, cancel and decline (phase 3), set up sandbox cards on the devices (phase 4), run the tests and file bugs (phase 5), then write a summary for the release decision (phase 6).

In agile, these phases still happen, just in small loops inside every sprint instead of once per project.

Learn more: SDLC and STLC

Test strategy: the “how we test here” rules

• Long-lived, for the whole product or organization.
• Covers: test levels and types we use, manual vs automation approach, tools, environments, how we handle defects, risk approach, quality metrics, supported devices and browsers policy.
• Example line: “Every story gets exploratory testing; critical flows are covered by automated regression on each build; we support the latest two iOS versions and Android 10+.”

Test plan: the “what we do for this release” document

• Short-lived, for one project, release or epic.
• Covers: scope and out of scope, schedule, who tests what, specific devices, test data, risks, entry and exit criteria.
• Example line: “Release 5.2: new checkout. Test on iPhone 12 and 16, Pixel 8, Galaxy A15. Exit when no open critical bugs and all high-priority cases pass.”

	Strategy	Plan
Scope	Product / company	One release or project
Lifetime	Months or years	Weeks
Level	General approach	Concrete details

The plan follows the strategy. In agile teams both are often lightweight: a strategy page on the wiki and a one-page plan per release.

Learn more: Writing a Test Plan

If you draw the development process as a timeline from left (idea) to right (release), traditional testing happens on the right. Shift-left means moving testing activities to the left, earlier.

Why: a missing requirement found in a planning meeting costs a five-minute conversation. The same problem found after release costs a hotfix, unhappy users and maybe lost money.

What it looks like for a tester

• Review user stories and acceptance criteria in refinement and ask questions: “What happens if the coupon expires during checkout?”
• Review designs for missing states: empty, error, loading, long text, dark mode.
• Three amigos sessions (product, developer, tester) before work starts.
• Write test scenarios before the feature is ready, and share them with developers so they can check them while coding.
• Test early builds, API endpoints and feature branches instead of waiting for the full feature.
• Encourage unit and API tests by developers.

Shift-left doesn’t replace later testing. We still do regression and exploratory testing before release, and many teams also “shift right” by monitoring production.

Example: in refinement I asked what happens to a scheduled post if the user deletes their account. Nobody had thought about it, and it was solved before a line of code was written.

Learn more: SDLC and STLC

Entry criteria: can we start testing?

Examples:

• The build is deployed to the test environment and the smoke test passes.
• The user story has acceptance criteria and designs.
• Test data and accounts are ready.
• Release notes list what changed.

Without them, testers waste time on broken builds or guess what to test.

Exit criteria: can we stop testing and release?

Examples:

• All planned high-priority test cases were run, with 95%+ passing.
• No open critical or high-severity bugs; remaining bugs are reviewed and accepted by the product owner.
• Regression suite run on the agreed devices and browsers.
• Test summary shared.

Why they matter: they turn “is it ready?” from a feeling into a checklist everyone agreed on earlier. They also protect the team from pressure: if a critical bug is open, the criteria say we’re not done.

Exit criteria never mean “zero bugs”; that’s impossible. They mean the remaining risk is known and accepted.

In agile teams, entry criteria often look like a Definition of Ready, and exit criteria like the Definition of Done for a story or a release checklist.

Learn more: SDLC and STLC

The question I ask myself is: did I get to check what this case checks?

Failed: yes, I ran the steps, and the actual result is different from the expected result because of a defect in the product. For example, in a food delivery app the expired coupon SPRING5 is still accepted and the discount applies. I mark it Failed, write the actual result, attach a screenshot and link a bug.

Blocked: no, something outside this case stopped me before I could find out. Typical causes:

• the test environment or a third-party sandbox is down (the payment provider returns 503 errors);
• test data or an account I need doesn’t exist;
• another bug is in the way: sign-in is broken, so I can’t reach checkout at all.

I mark it Blocked, write the reason and link the blocking issue if there is one, then re-run it when it’s cleared. If it fails then, it becomes Failed.

	Failed	Blocked
Was the case executed?	Yes	Not to the end
What’s wrong?	The product	Something the case depends on
What I record	Actual result, evidence, bug key	Reason, blocking issue, when to re-run

Why it matters: a wrong Failed sends a developer hunting for a bug that isn’t in their code. A wrong Blocked hides a real defect. And in the summary report, blocked cases count as not verified, not as tested.

One nuance: when a bug blocks other cases, the case that hit the bug is Failed, and the cases behind it are Blocked by that bug. When the bug is fixed, they’re all run again.

Learn more: Test Runs and Test Management Tools

A requirements traceability matrix (RTM) is a table of links: each requirement or user story on one side, the test cases that check it on the other. In practice most teams add the latest run result and the bugs found, because that’s what people ask about.

Requirement	Test cases	Latest result	Bugs
FD-104 Coupon rules	C202	Failed	FD-242
FD-105 Tip the courier	none	–	–
FD-106 Pay with a saved card	C301	Blocked	–

Why use it

• Coverage gaps (forward traceability). Going from requirement to tests, FD-105 (tip the courier) has no tests at all and FD-106 was blocked, so neither is verified. Without the matrix those gaps hide behind a nice pass rate.
• Why does this exist? (backward traceability). Going from a bug or test back to its requirement shows which story a bug hurts, and finds orphan tests linked to nothing, often for removed features.
• Impact analysis. When the coupon rule changes, the matrix lists the cases and bugs linked to FD-104, so I know what to update and re-run. I still think about indirect effects; for example, reorder copies old carts together with their coupons, so a new coupon rule affects it too.
• Reporting and audits. The summary report can say exactly which requirements were tested, failed or not tested. Regulated projects (finance, health) often require this.

How I keep one: I link each test case to its story while writing it, record statuses in the run, and link every failure to a bug. Then the tool (Xray, TestRail, Zephyr) or a spreadsheet can generate the matrix.

One caution: a link says a requirement has a test, not that it’s tested well. One happy-path case per story gives “100% coverage” and still misses most bugs. I use the matrix to find gaps and risk to decide depth.

Learn more: Traceability and Test Summary Reports

A test summary report (also called a test closure or completion report) closes a test cycle. Its job is to help the team decide whether to release, so I keep it to one page with six parts:

1. Scope. Release and build number, environments and devices, dates, and which stories or features were in scope.
2. What was tested. Features and requirements covered, plus anything special like a retest of earlier fixes.
3. What wasn’t tested, and why. Blocked areas, cases not run, requirements without tests, devices we didn’t have. This is the part readers can’t guess, so it’s never optional.
4. Results. Executed, passed, failed, blocked, not run. Always with meaning: “3 failures, all in checkout”, not just “92% passed”.
5. Open bugs by severity, with the user impact of the worst ones: “FD-241 (Major): ‘Remember me’ is ignored, so every user is signed out each time they restart the app.”
6. Risks and recommendation. What could still go wrong, then a clear call: go, no-go, or go if specific conditions are met.

A short example of the last part:

Recommendation: not ready for Friday as is. Go on Monday if FD-241 and FD-242 are fixed and retested and card payment passes once the payment sandbox is back. FD-243 can ship as a known issue if Product accepts it.

The product owner (or whoever owns the release) makes the decision; my job is to make sure they decide with the facts.

During the cycle I also send short daily or weekly updates in the same shape (progress, new important bugs, blockers, what I need), so the final report holds no surprises.

Learn more: Traceability and Test Summary Reports

I think of it in five steps.

1. Scope the run. From the test plan and the release notes, I decide what to run: all P1 cases, plus P2 cases for the areas that changed, plus retests of bugs fixed in this release. Impact analysis and the traceability matrix help me see which requirements and cases are affected.

2. Create the runs. In the test management tool (TestRail, Xray, Zephyr, or a disciplined spreadsheet for a small team), I create one run per build and environment, for example “2.0.0 regression · build 412 · iPhone 15” and the same for a Pixel. I filter by platform so iOS-only cases don’t end up in the Android run, and I assign testers by section or device so every case has one owner.

3. Execute with discipline. Each case gets a status as soon as it’s run:

• Passed when the actual result matches;
• Failed with the actual result, evidence and a linked bug;
• Blocked with the reason (sandbox down, missing data, another bug);
• Skipped / N/A with a reason.

If I find that a case is out of date, I note it on the result and update the repository after the run, rather than silently editing it mid-run.

4. Track and unblock daily. I watch executed vs remaining (a burndown) and the failed and blocked P1 cases. A flat burndown usually means a blocker, so I raise it at stand-up the same day. I send a short daily update: progress, important new bugs, blockers, what I need.

5. Retest, re-run, report. When fixes arrive in a new build, I create a new run with the failed, blocked and untested cases plus a regression subset around the fixes. The old run stays as the record of the old build. At the end I write a one-page test summary report with what was and wasn’t tested, open bugs by severity, risks and a recommendation.

Learn more: Test Runs and Test Management Tools

In most teams the decision belongs to the product owner, release manager or engineering lead, because it’s a business decision that weighs quality against deadlines, marketing and customer commitments. My role is to make sure it’s an informed decision.

What I bring, on one page

1. Scope tested: which features, platforms and devices, and at what depth.
2. Open bugs that matter: each with severity, who is affected, workaround, and whether a fix is in progress. Not the full list, the ones that influence the decision.
3. What was not tested or only partly tested, and why.
4. Exit criteria status: for example “no open critical bugs, all P1 regression passed on tier 1 devices” and which criteria are met or not.
5. Risks outside testing: an unstable third-party API, a store review deadline, a backend migration in the same week.
6. My recommendation: go, no-go, or go with conditions such as a feature flag, a staged rollout or a hotfix plan.

How I say it

I keep it short and in business language: “I recommend go with a staged rollout. The one open major bug affects saved addresses on Android 10, about 2% of our users, and there’s a workaround. I’d recommend no-go if the payment timeout issue reappears in the final build.”

If I disagree with the decision

I state my concern clearly, once, with evidence. If a critical risk such as data loss or a security hole is accepted, I make sure the decision and its owner are documented, and I escalate if it’s serious enough. Then I support the team and help reduce the impact.

Learn more: Writing a Test Plan

First I check that we actually disagree about the risk, not about the words. Often “Major” means something different to me and to the PM.

1. Translate the bug into impact

Not “the sync has a race condition”, but “if a user edits a note on two devices within a few seconds, one edit is lost without warning. Our heaviest users do this every day, and lost data creates support tickets and churn.”

I add what I know about how many users, how often, and whether there’s a workaround, and I’m honest about what I don’t know.

2. Offer options, not just “no”

• Ship with the feature behind a feature flag, off for everyone or on for a small group.
• Staged rollout with a clear rule to halt it.
• Ship but disable the specific path (for example, turn off multi-device editing for now).
• Delay by one or two days for a targeted fix and a focused retest.

3. If the PM still decides to ship, make the risk acceptance explicit

• Record it on the ticket: the risk, who accepted it, and the reason.
• Add it to the known issues for the support team and, if needed, the release notes.
• Agree on monitoring (crash rate, error logs, support tickets for that flow) and a trigger: “If we see more than a handful of reports in 48 hours, we roll back or hotfix.”
• Schedule the fix.

4. Escalate only when it’s justified

For security holes, data loss, legal or payment issues, I escalate to engineering or product leadership, calmly and with evidence, and I tell the PM I’m doing it. For anything less, I accept that the business can take risks I wouldn’t have taken.

Learn more: Severity vs Priority

A Friday hotfix is a risk in itself, so the first question I ask is: does it really have to ship tonight? If the bug is blocking payments or leaking data, yes. If it’s a cosmetic issue, Monday morning is often safer. If it must go, here’s my plan.

1. Understand the change (10 minutes)

• What was the bug, and what exactly did the developer change? I look at the pull request with them.
• Which other features use that code? This is my impact analysis.

2. Test the right build

I test the exact build or deployment that will go out, not a local or older one. For mobile, that means the release candidate from the same pipeline.

3. Retest the fix

The original steps, plus variations: other devices, other user types, the edge case that caused the bug.

4. Focused regression plus smoke

• Areas that share the changed code.
• A smoke test of the critical paths: launch, login, browse, checkout or the app’s main job.

5. Plan for things going wrong

• Web: how do we roll back the deployment, and how fast?
• Mobile: an app store release can’t simply be pulled back from devices, so a feature flag or server-side switch matters even more. On iOS we can request an expedited review if the fix is urgent, but approval time isn’t guaranteed. A phased or staged rollout limits the blast radius.
• Monitoring and people: who watches crash reports and error logs tonight, and who is on call this weekend?

6. Communicate

A short message to the team and support: what was fixed, what was tested, what wasn’t, and what to watch. On Monday, I make sure the fix gets a proper regression test and we discuss in the retro why it escaped.

Learn more: Regression and Smoke Suites

Both tools reduce the blast radius of a release, but they don’t reduce the need for testing. They change what I test and add a phase after release.

How they work

• Staged rollout: a release reaches a percentage of users first. Google Play supports staged rollouts by percentage that you can increase or halt. The App Store offers a phased release for automatic updates over seven days, which can be paused, although users can still update manually. On the web, teams use canary releases or traffic percentages.
• Feature flag: code ships to everyone, but a feature is turned on remotely for chosen users, markets or percentages, without a new build.

What changes in my testing

• Both states: every flagged feature is tested with the flag on and off, and the “off” path must still be the old, working behavior.
• Switching: what happens if the flag changes while the user is in the middle of the flow, or between sessions? Is cached data from the new feature handled when it’s turned off?
• Combinations: several flags at once can interact. I agree with the team which combinations are realistic, and push for removing old flags.
• Targeting: is the feature really shown only to the right users, countries or app versions?
• Test environments: I need a way to set flags for my test accounts.

During the rollout

• Agree beforehand on what we watch: crash-free users, error rates, conversion, support tickets.
• Agree on pause and rollback criteria, so nobody debates it under pressure.
• For mobile, remember: halting a rollout stops new installs of that version, but users who already have it keep it. A server-side flag is often the real emergency brake.

Example: we rolled out a new checkout to 5% of Android users behind a flag. Payment errors were slightly higher on one bank’s 3-D Secure page, so we turned the flag off within minutes, fixed it, and resumed the next day.

Learn more: TestFlight and Firebase App Distribution

During the incident: users first

I help reproduce it, narrow down who is affected (platform, version, region), verify the fix, and do a focused regression before it ships. Analysis waits until the fire is out.

After the incident: a blameless review

“Blameless” doesn’t mean nobody is responsible. It means we assume people acted reasonably with the information they had, and we look for the conditions that made the mistake easy. People only share honestly if they don’t fear punishment.

Two questions, not one

1. Why did the defect happen? Unclear requirement, missing validation, a risky change merged late?
2. Why didn’t we catch it? Wrong test data, an environment that differs from production, a device we don’t cover, a scenario nobody thought of, or testing that was cut due to time?

Going deeper with “5 whys”

The order total was wrong for some users. Why? The discount was applied twice. Why? The app retried the request after a timeout. Why wasn’t it caught? Our test environment never times out. Why? We have no way to simulate slow responses. Why? Nobody owned network testing tools.

The 5 whys is a heuristic, not a rule; sometimes there are several causes and it’s fine to stop at three or go to seven.

Output: a few owned actions

• A regression test for this bug and for its category (for example, all retryable payment requests).
• A tool or environment improvement, like a proxy to simulate timeouts.
• A process change if needed, such as a review checklist for retry logic.
• Each action has an owner and a date, and we check them in the next retro.

As a tester, I own my part openly: “I didn’t test slow networks on checkout. From now on it’s in our checklist.”

Learn more: Bug Life Cycle

My goal in the first hour is to turn “people are angry” into facts the team can act on.

Minutes 0-15: confirm and size it

• Read the reviews: what do they have in common? Crash on launch, can’t log in, payment fails, a feature removed?
• Check the version: are the reviews from the new version? Store consoles show the app version for many reviews.
• Check the data: crash reporting (for example Crashlytics or Sentry), Android vitals in Google Play Console, App Store Connect crash data, backend error dashboards, and support tickets.
• Find the pattern: one platform, OS version, device, country, language, or user type such as users who upgraded vs fresh installs.

Minutes 15-35: reproduce

• Install the exact production version on a matching device. If it’s an upgrade issue, install the previous version first, create data, then update.
• Capture evidence: video, logs, the failing request. Even a partial reproduction (“only after upgrade, only with a saved card”) helps a lot.

Minutes 15-45, in parallel: raise the alarm

I don’t wait until I’ve reproduced it. I post in the incident or release channel with what we know: “Since release 4.2, 1-star reviews mention login failures. Crashlytics shows a new crash on Android 12 at login, about 8% of sessions on that version. Reproducing now.” Then I keep updating that one thread.

Minutes 30-60: help choose the fastest safe fix

• Halt the staged rollout or pause the phased release, so fewer users get the bad version.
• Turn off a feature flag or fix it on the server, if the problem allows that.
• Hotfix if needed, and I start preparing the test plan for it.
• Make sure support and whoever answers store reviews have a short, accurate message.

Afterwards: reply to reviews once the fix is out, verify that the crash rate drops, and run a blameless review of why we missed it.

Learn more: adb Basics

I combine a work breakdown with three-point estimates, then sanity-check the result.

1. List the tasks. For a feature, that’s more than running tests:

• understanding the story and asking questions;
• test design: scenarios, cases, charters, the regression set;
• environment and test data setup;
• execution on each device or browser we test on;
• bug reports and follow-up;
• retesting fixes and regression around them, usually in more than one round;
• status updates and the summary;
• a visible buffer for late builds and blockers.

2. Three numbers per task. Optimistic, most likely and pessimistic. The PERT formula (O + 4M + P) / 6 gives an expected value; the sums of O and P give a range.

3. Cross-check. How long did something similar take last time? Some teams also compare with the dev estimate using their own historical ratio, but only as a check: a small change to payments can need far more testing than a big text change.

4. Say it with assumptions. “About five days, three to eight, assuming the build is on staging Monday and we test on four phones.” Rounded, with a range, never “28.17 hours”.

5. Re-estimate as soon as scope or an assumption changes, and compare estimate with actual afterwards so the next one is better.

In scrum teams the whole team often estimates stories in story points with planning poker. There, my job is to make the testing part visible: devices, data, payment sandboxes, risky integrations.

Learn more: Estimating Testing Effort

This is a negotiation, not a failure. The estimate’s job is to turn “there isn’t enough time” into a clear choice.

1. Show the gap and the breakdown. “My estimate is five days; Thursday gives three. Here’s what the five days are made of.” A task list makes it concrete instead of sounding like a complaint.

2. Prioritize by risk. Score areas by likelihood and impact. Money, personal data and the main flow come first and get tested deepest.

3. Offer options, each with its risk:

Option	Trade-off
Test high-risk areas deeply, the rest lightly	Lower-risk bugs may slip through
Reduce scope (e.g. ship “later today”, not “tomorrow”)	Less value in this release
Move the date	Business cost of waiting
Add a tester or developer help	Onboarding time
Release behind a feature flag to a small group	Needs flag and monitoring in place

4. Write down what won’t be tested by the deadline, in the plan or ticket: “Not tested: large text, Samsung A-series, custom tips above €50.”

5. The product owner decides. I make the risk visible; they decide whether to accept it. Then I re-estimate if anything changes during testing, and say so early.

The difference from the classic “no time to test everything” question is timing: here I raise it when the estimate is made, so the team can still change scope or date instead of discovering the gap on release day.

Learn more: Estimating Testing Effort

Continuous integration (CI) means developers merge small changes often, and every change is automatically built and checked by a CI server such as GitHub Actions, GitLab CI or Jenkins.

CD has two meanings:

• Continuous delivery: every change that passes is ready to release; a person decides when.
• Continuous deployment: every passing change goes to production automatically.

A typical pipeline: build → unit tests → lint → deploy to a test environment → automated API/UI tests → manual testing → release.

Where I fit as a manual tester:

• Testing early: if the team makes builds for pull requests, I test the change before it’s merged.
• Knowing the build: I check which build contains a fix (ticket, release notes, the app’s About screen) before retesting, and always report the exact build.
• Reading a red pipeline: which stage failed, which test, and is it related to the change? I don’t fix it, but I can tell whether there’s anything to test yet.
• Flaky tests: I make them visible and push for a ticket instead of re-running until green.
• What automation can’t judge: new features, exploratory testing, real devices, usability and accessibility, and checking features behind feature flags in both states.

Example: “The PR is red on a map UI test that also fails on main without changes. Looks flaky. I tested the PR build on two phones and the fix works; I’ll retest on staging once it’s merged.”

Learn more: Git and CI for Testers

• Severity = the impact of the bug on the system or user. Usually proposed by the tester and confirmed in triage. Levels like blocker/critical, major, minor, trivial.
• Priority = the urgency of fixing it. Usually set by the product owner or lead, based on business needs. Levels like P1 (highest) to P4 (low).

They are independent, which gives four combinations:

	High priority	Low priority
High severity	Banking app crashes when tapping “Transfer” for all users. Fix now.	App crashes when exporting a statement as CSV on a legacy Android version used by 0.1% of users. Serious, but can wait.
Low severity	Company name is misspelled on the home screen or app store screenshot. Nothing breaks, but everyone sees it.	A slightly misaligned icon on a rarely used settings screen.

A good answer also mentions that priority can change: a low-priority bug can become high priority before a big marketing launch, or if a key customer complains.

Learn more: Severity vs Priority

The bug life cycle (defect life cycle) is the journey of a bug from discovery to closure. Exact names depend on the team and tool (for example Jira), but a typical flow is:

1. New: the tester reports the bug.
2. Triaged / Open: a lead or product owner confirms it is real and not a duplicate, and sets the priority.
3. Assigned: a developer becomes the owner.
4. In Progress: the developer reproduces it and works on a fix.
5. Fixed / Ready for test: the fix is in a new build the tester can install.
6. Verified / Closed: the tester retests on that build, the fix works, and the bug is closed.

Alternative paths:

• Reopened: the retest fails, so the bug goes back to the developer.
• Not a bug / Rejected: the app works as designed.
• Cannot reproduce: nobody can make it happen again; the tester adds missing details or it is closed.
• Duplicate: the same bug was already reported.
• Deferred / Won’t fix: valid, but postponed to a later release or accepted as is.

Example: you report that a shopping app’s cart badge shows the wrong count (New). It is assigned and fixed in build 2.3.1. You retest on 2.3.1, but the badge is still wrong after removing an item, so you reopen it with the new details. In 2.3.2 it works, and you close it.

Learn more: Bug Life Cycle

The goal of a bug report is simple: a developer can reproduce and understand the bug without asking you anything.

Key parts:

• Title: short and specific. “Checkout: app crashes when tapping Pay with an expired card” instead of “Payment broken”.
• Environment: device, OS version, browser, app build, environment (QA/staging), account used.
• Preconditions: for example “logged in, one item in cart”.
• Steps to reproduce: numbered, exact, starting from a known point.
• Expected result and actual result.
• Severity and priority.
• Evidence: screenshot, screen recording, console or crash logs.
• Frequency: always, or “3 out of 10 tries”.

Good habits:

• One bug per report.
• Reproduce it before reporting, and find the shortest steps.
• Check for duplicates first.
• Stay neutral and factual. Describe behavior, not people: “the button does nothing”, not “someone forgot to code the button”.
• Add useful extras: does it happen on iOS too? In another browser? Was it working in the previous build?

A small example: “Steps: 1. Open cart. 2. Change quantity to 0. 3. Tap Update. Expected: item is removed. Actual: item stays with quantity 0 and total 0.00.”

Learn more: How to Write a Bug Report

A duplicate is the same problem reported twice. It might be found through a different path, but it has the same cause and one fix will solve both.

Bug A: “Checkout: Pay button does nothing with a saved Visa card.” Bug B: “Can’t complete order with saved card on iOS.” If both fail because the saved-card token isn’t sent, B is a duplicate of A.

A related bug is in the same area or looks similar, but it’s a separate problem that needs its own fix.

Bug C: “Checkout: Pay button does nothing when the promo code is invalid.” Same button, same symptom, but a different cause. It’s related, not a duplicate.

How I handle it

1. Search first: by screen name, error message, key words, and recent bugs in that area.
2. If it looks like a duplicate, I check the conditions. Same steps? Same platform? If my case adds new information, like “also happens on Android”, I add a comment to the original instead of opening a new bug.
3. If it’s related, I create a new bug and link it (“relates to”) so the developer sees both together.
4. If I’m not sure, I report it, link it, and write “possibly the same cause as ABC-123”. The developer can confirm and mark it as a duplicate later.

Duplicates aren’t a disaster, but too many waste triage time. Missing a real second bug because I assumed it was a duplicate is worse.

Learn more: Working with Jira

Bugs that happen “sometimes” are often the most serious ones in production, so I don’t ignore them.

1. Capture what I have, immediately

• Notes: exact time, build, device, account, what I did just before, network.
• Logs before they’re overwritten: browser console and network tab, adb logcat on Android, device logs on iOS.
• A screenshot or, ideally, a screen recording. I often keep recording running during exploratory sessions for exactly this reason.
• Check the crash reporting tool or server logs for that time.

2. Think about what could make it intermittent

• Timing: double taps, slow responses, a race between two requests.
• State: first launch vs later, logged in for a long time, app returning from background.
• Data: a specific account, item, long text, special characters, an expired token.
• Environment: network switch, low memory, another device or OS version, a time zone or date.

3. Vary one condition at a time

Repeat the steps with a slow network, then with a different account, then after backgrounding the app. Changing one thing at a time tells me what matters.

4. Report it honestly

If I still can’t reproduce it reliably, I report it as intermittent: “Seen 1 time in about 20 attempts”, with all evidence and what I already tried. I ask the developer to look at the logs; sometimes the stack trace alone is enough to find the cause.

Example: a cart sometimes showed an empty list. After trying different things, it happened only when I tapped the Cart tab within a second of adding an item. It was a race between two API calls, which the developer fixed once I gave him that detail.

Learn more: How to Write a Bug Report

A fixed bug coming back is a regression: something that worked has broken again. It’s a useful signal, so I handle it carefully.

1. Confirm it’s really the same bug

I follow the original steps on the current build. Same symptom, same conditions? Sometimes it’s a similar bug with a different cause, for example the original fix covered iOS but this happens on Android.

2. Find when it came back

I check which builds have it. “Fixed in 3.4.0, still fine in 3.4.2, broken again in 3.5.0” helps the developer find the change that reintroduced it, often a merge, a refactor or a library update.

3. Reopen or create a new bug, following the team’s rules

• Many teams reopen the original if it’s the same bug and the original hasn’t been released yet.
• If the fix was already released, teams often create a new bug marked as a regression and linked to the original, so release history stays correct.

Either way, I add the new build number, evidence, and a link to the original fix.

4. Raise the priority if needed. A regression of something users already have working is often more urgent than a new bug.

5. Prevent it next time

• Make sure the scenario is in the regression suite, or ask for an automated test.
• In the retro, ask how it came back: missing unit test, a merge conflict, two branches fixing the same code?

Learn more: Bug Life Cycle

First, describe exactly what happened. “Crash” means different things to different people:

• Crash: the app closes and you’re back on the home screen.
• Freeze: the app stops responding. On Android, if the main thread is blocked for about 5 seconds, the system shows an “App isn’t responding” (ANR) dialog. On iOS, the system can terminate an app that hangs for too long.
• Blank or white screen: the app or page is open but shows nothing. On the web this is often a JavaScript error.

What goes into the report

• Title: where and when. “Order history: app crashes when opening an order with 50+ items.”
• Environment: app build and version, device model, OS version, environment (staging or production), account.
• Steps and frequency: “3 out of 3 tries” or “1 in 10”.
• Exact time it happened, with time zone, so the developer can find it in logs.
• Evidence:
  • Mobile: the stack trace from adb logcat (look for FATAL EXCEPTION) or the crash report from the iPhone or Xcode, plus a link to the crash in Crashlytics or Sentry if the app uses one.
  • Web: the console error with its stack trace, and the failing request from the Network tab.
  • A screen recording showing the steps and the crash.
• Only the relevant log lines in the description, with the full log attached.

Useful extras: Does it happen on the previous build? On the other platform? After a fresh install? With another account? Each answer helps the developer narrow it down.

Crashes usually get high severity, since the user loses their work and can’t continue.

Learn more: adb Basics

I compare what I see against a reference: the requirements, acceptance criteria, designs, platform conventions, and what a user would reasonably expect.

Bug: the product doesn’t do what it should.

The spec says a coupon gives 10% off, but the total doesn’t change. Or: the app crashes, loses data, or shows the wrong price. Even without a spec, a crash is never “expected”.

Feature request (or improvement): it works as intended, but it could be better or different.

The search works correctly, but users would like to filter by price. Nobody asked for it, so it’s a new requirement, not a defect.

Question: I can’t tell what the expected behavior is.

Should a discount apply before or after delivery fees? The spec doesn’t say, and both are plausible. I ask the product owner first, in the ticket or the team chat.

Grey areas are common. A confusing label that matches the design isn’t a defect against the spec, but it may cause real user mistakes. I report it as a usability issue or improvement, explain the impact, and let the product owner decide.

Keeping these separate matters: the bug list stays focused on real defects, good ideas go to the backlog, and questions get answered instead of argued about.

Learn more: User Stories and Acceptance Criteria

Usability findings get dismissed when they sound like taste. I make them factual:

• Title that states the problem and the effect: “Account screen has no way back; users get stuck”.
• What I observed: the screen, device, steps, and what happened. A screenshot or short recording.
• Who and how many: “3 of 5 colleagues in a hallway test”, “new users”, “on small phones”. A think-aloud quote helps.
• User impact: time lost, mistakes, abandoned tasks, data or money at risk.
• Reference: the heuristic or platform guideline it breaks, for example Nielsen’s “Error prevention” for a delete without confirmation.
• Severity: Nielsen’s 0–4 usability scale (cosmetic, minor, major, catastrophe) based on frequency, impact and persistence, mapped to the team’s bug severity.
• Suggestion (optional): the designer owns the solution, so I describe the problem first.

If it matches the spec but still confuses people, I say so: “works as specified, but users can’t find it”. That’s a validation finding and still worth fixing.

Learn more: Usability Testing Basics

A test scenario is a one-line description of a situation worth testing. It answers what to test.

A test case is a detailed description of how to test one specific behavior: preconditions, steps, test data and expected result.

One scenario usually becomes several test cases.

Example: scenario “User logs in to the banking app”

Test case	Steps (short)	Expected result
TC-01 Valid login	Enter valid email and password, tap Log in	Home screen with balance appears
TC-02 Wrong password	Valid email, wrong password	Error “Incorrect email or password”, stays on login
TC-03 Empty fields	Tap Log in with empty fields	Fields are highlighted with required messages
TC-04 Locked account	Enter wrong password 3 times	Account locked message and reset option

	Test scenario	Test case
Detail	Low	High
Answers	What to test	How to test it
Contains	One sentence	Preconditions, steps, data, expected result
Good for	Quick coverage overview, agile teams	Repeatable, handover-friendly testing

Scenarios are quick to write and help you check coverage; test cases are better when tests must be repeated exactly or run by someone else.

Learn more: Test Scenarios vs Test Cases vs Checklists

• Positive testing checks the system does what it should when the user does things correctly (the happy path).
• Negative testing checks the system behaves sensibly when the user does things wrong or unexpectedly. It should show a clear message and never crash, freeze or save bad data.

Example: a sign-up form with email, password (min 8 characters) and phone number

Positive tests:

• Valid email, 10-character password, valid phone number: account is created.
• Email with a plus sign, like anna+shop@test.com: accepted.

Negative tests:

• Email without @ (“anna.test.com”): error “Enter a valid email”.
• 7-character password: error about minimum length.
• Letters in the phone number field.
• Email that is already registered.
• Submitting with no internet connection.
• Pasting 5,000 characters into the name field.

A negative test passes when the app handles the bad input correctly. “Negative” describes the input, not the result.

Most teams start with positive tests to confirm the basics, then spend a lot of effort on negative tests, because that is where users (and bugs) tend to surprise you.

Learn more: Types of Testing

Both are black-box techniques that help you test smart, not everything.

Equivalence partitioning (EP) divides inputs into groups (partitions) where the software should behave the same way. You test one value from each partition.

For an age field that accepts 18 to 60:

Partition	Example value	Expected
Below 18 (invalid)	10	Error
18 to 60 (valid)	35	Accepted
Above 60 (invalid)	75	Error
Not a whole number (invalid)	“abc”, empty, 25.5	Error

Boundary value analysis (BVA) focuses on the edges of partitions, because developers often make off-by-one mistakes, such as writing age > 18 instead of age >= 18.

Boundary values to test: 17, 18, 60, 61 (two-value BVA). Many testers also add 19 and 59 (three-value BVA).

Value	Expected
17	Rejected
18	Accepted
60	Accepted
61	Rejected

Together, the techniques give strong coverage with about 8-10 tests instead of hundreds. On a mobile app, also check that the numeric keyboard appears and that pasted values like ” 18 ” with spaces are handled.

Learn more: Boundary Value Analysis

In exploratory testing, you do not follow a script. You learn, design and execute tests at the same time, using what you discover to decide what to try next.

It is not random. Good exploratory testing has structure:

• A charter (goal): “Explore the photo editor’s undo and redo to find data loss issues.”
• A time box: often 60-90 minutes, shorter for small charters.
• Notes: what you tried, questions, bugs and ideas for follow-up.
• A short debrief with the team afterwards.

Example: exploring a food delivery app’s checkout for 45 minutes, you might change the address after choosing a time slot, put the app in the background during payment, switch to airplane mode, apply two coupons, rotate the phone and use very large text. Scripted tests often miss these combinations.

When to use it:

• New features with incomplete documentation.
• When you need fast feedback early in a sprint.
• To complement scripted regression tests and find “unknown unknowns”.
• When time is short and you want to focus on risky areas.

It differs from ad hoc testing, which has no charter or notes and is hard to repeat or report on.

Learn more: Exploratory Testing

A decision table is a test design technique for business rules where several conditions combine to decide the result. Each column is a rule: one combination of conditions and its expected action.

Example: free shipping rule: “Members get free shipping. Non-members get it on orders over 50 EUR.”

	R1	R2	R3	R4
Is member?	Yes	Yes	No	No
Order over 50 EUR?	Yes	No	Yes	No
Free shipping	Yes	Yes	Yes	No

With two yes/no conditions there are 2 x 2 = 4 rules, so 4 test cases. Three conditions give 8, and so on. Building the table often reveals gaps in requirements: “What about a member with a discount code that brings the total under 50?” is a question to ask the product owner before anything is built.

When I use it: discounts and pricing, loan or insurance eligibility, permissions by role, form logic that shows or hides fields.

If the table gets too big, I merge rules where a condition doesn’t matter (R1 and R2 above: members always get free shipping) or combine it with pairwise testing.

Learn more: Decision Tables

Some features behave differently depending on what state they are in. State transition testing models these states, the events that move between them, and checks each transition.

Example: an online order

• States: Placed, Paid, Shipped, Delivered, Canceled.
• Valid transitions: Placed to Paid (payment succeeds), Paid to Shipped, Shipped to Delivered, Placed or Paid to Canceled (user cancels).

What I test

1. Each valid transition at least once, and that the UI, emails and buttons match the new state.
2. Invalid transitions: can a Delivered order be canceled? Can a Canceled order be shipped? Can the user tap Cancel after it shipped? These should be blocked.
3. Sequences: full paths like Placed, Paid, Canceled, and refund issued.
4. Repeated events: pressing Pay twice, or a cancellation and a shipment happening at the same time.

Another classic: login with lockout. States: Active, 1 failed attempt, 2 failed, Locked. Test that a correct password resets the counter and that a Locked account can’t log in even with the right password.

Drawing a simple state diagram first makes missing transitions easy to spot and is a good discussion tool with developers.

Learn more: State Transition Testing

The problem: a flight search form with 4 trip types, 3 cabin classes, 5 passenger counts, 2 currencies and 3 languages has 4 x 3 x 5 x 2 x 3 = 360 combinations. Testing all of them is not realistic.

Pairwise (all-pairs) testing: most bugs are caused by a single value or by the interaction of two values. Pairwise testing creates a small set of tests where every pair of values appears at least once. For the form above, that is about 20 tests instead of 360.

How I do it

1. List the fields and the values for each, using equivalence partitions (not every number from 1 to 9, but 1, a typical value and the maximum).
2. Generate the combinations with a tool like PICT or an online pairwise generator.
3. Add constraints for impossible combinations (an infant can’t travel alone).
4. Add risk-based extras: combinations that matter to the business or have failed before, like “one-way, business class, 9 passengers, EUR”.
5. Test each field on its own for validation and boundaries too.

Pairwise is a smart way to reduce tests, not a guarantee. A bug that needs three specific values together can still slip through, so I combine it with the risky combinations I know about.

Learn more: Equivalence Partitioning

The difference is how much you know about the inside of the system.

Black box testing

• You test inputs and outputs based on requirements, without seeing the code.
• Techniques: equivalence partitioning, boundary values, decision tables, state transitions.
• Example: enter a 101-character name and check the error message.
• Mostly done by testers and also by users in acceptance testing.

White box testing

• You design tests from the code structure: branches, conditions, loops.
• Goal: cover paths in the code (for example, both sides of every if).
• Example: a unit test for the discount function that covers each branch.
• Mostly done by developers.

Grey box testing

• You test from the outside, but use some inside knowledge to aim better.
• Examples from my daily work:
  • Checking the API response in DevTools to see if a bug is front end or backend.
  • Looking in the database to confirm an order was saved with the right status.
  • Knowing from the architecture that two screens use the same endpoint, so a fix in one needs a retest in the other.
  • Reading logs to understand a crash.

Most experienced manual testers work in grey box style: user-focused, but technically aware.

Learn more: Black, White and Grey Box

A use case describes how an actor reaches a goal: preconditions, the main success scenario (happy path), alternative flows (other routes that still reach the goal), exception flows (errors that stop the normal path) and postconditions (what must be true afterward).

My steps

1. List every flow. For “Reorder a previous order”: the main flow, “some dishes sold out”, “prices changed”, “restaurant closed”, “card declined” and so on.
2. One test per flow, at least. For an alternative, I follow the branch and check it rejoins the main flow. For an exception, I check the message, that nothing half-finished is left, and whether the user can recover.
3. Preconditions become setup. “Customer has a completed order” is test data, not a step.
4. Postconditions become expected results. After a successful reorder: one new order, charged once, the original order unchanged. A nice confirmation screen isn’t enough.
5. Use other techniques inside steps. Boundary values for a quantity, state transitions for an order status.
6. Look for missing flows. “What if every dish is sold out?” If the use case doesn’t say, I raise it as a gap rather than guessing.

Coverage is flows tested divided by all flows. Ten variations of the happy path still cover one flow.

Learn more: Use Case Testing

Error guessing is an experience-based technique: I pick tests based on the mistakes developers typically make, not only on what the spec says.

What I typically try

• Text: empty, spaces only, very long, apostrophes like O’Neil, emoji, <b> tags.
• Numbers: 0, negative, too many decimals, other number formats (1.250,50 in Germany).
• Dates and time: 29 February, another time zone, midnight, daylight saving changes.
• Actions: the same thing twice, interrupting an action halfway (lock the phone, take a call).
• Environment: permissions denied, slow or lost network.

How I make it reliable

1. I cover the spec first with equivalence partitioning, boundaries or decision tables, so coverage is measurable.
2. Then I timebox an error-guessing session, often as part of exploratory testing.
3. I keep a checklist fed by real escaped bugs, and pick items by risk for each feature. A planned version of this, where you list likely failures and design a test to provoke each one, is called a fault attack.

The weakness is that it depends on experience and its coverage is hard to measure. That’s why I combine it with systematic techniques instead of relying on it alone.

Learn more: Error Guessing and Checklists

Pairwise testing guarantees that every pair of values appears in at least one test. That’s powerful, but it leaves gaps:

Gap	Example	How I compensate
Three-way interactions	A bug only with German + PayPal + Firefox	Add that row explicitly, or generate 3-way coverage (PICT /o:3) for risky features
Missing or impossible combinations	Safari on Windows rows, or a forgotten constraint hiding a real pair	Model constraints in the tool instead of deleting rows; only exclude what truly can’t exist
Poor value choices	Listing desktop browsers but forgetting mobile Safari	Choose values with equivalence partitioning and real usage data
Business rules	Fees that depend on specific combinations	Use a decision table for rule-based logic
Order and timing	A bug only when payment is retried after a timeout	Use state transition or use case testing
Popular combinations	40% of users on Chrome + Android + English + Card	Add the top real-world combinations as extra rows

Pairwise also doesn’t give expected results: every row still needs a clear “what correct looks like”.

So I present it as a smart way to reduce a combinatorial set, never as complete coverage.

Learn more: Pairwise Testing

Many basics are the same (functional checks, bug reports, test design), but each platform has its own risks.

Things you test more on mobile apps:

• Device and OS fragmentation: many models, screen sizes, notches, Android manufacturer skins.
• Interruptions: incoming calls, notifications, alarms, low battery popups.
• App lifecycle: backgrounding, killing the app, returning after hours. Is state kept?
• Permissions: camera, location, notifications. What if the user denies them?
• Gestures and hardware: swipe, pinch, long press, rotation, Android back button, biometrics.
• Network: switching Wi-Fi to 4G, airplane mode, offline mode.
• Install, update and uninstall, plus app store requirements.
• Battery, memory and storage use.

Things you test more on websites:

• Cross-browser: Chrome, Safari, Firefox, Edge, and versions.
• Responsive layouts at many widths and zoom levels.
• URLs and navigation: browser back/forward, refresh, bookmarks, deep links, opening in a new tab.
• Cookies, cache and sessions across tabs.
• Keyboard navigation and DevTools evidence (console errors, network calls).

Example: the same “edit profile” form may lose your input on mobile when you leave the app to copy a code from email, while on the web it may break when you press the browser’s back button and return.

Learn more: iOS vs Android Differences

You cannot test on every device, so you build a device matrix based on data and risk.

Choosing devices:

• Use analytics to see the top devices, OS versions and screen sizes your users actually have.
• Cover the extremes: smallest and largest screens, oldest supported OS, newest OS (and betas), a low-end Android with little memory.
• Include key manufacturers (Samsung, Pixel, Xiaomi…) because of Android fragmentation.
• Add tablets if the app supports them.

Emulators, simulators and real devices:

	Emulator / Simulator	Real device
Cost and speed	Free, fast to switch models	Costly, need maintenance
Good for	Layouts, flows, early checks, many screen sizes	Performance, camera, GPS, biometrics, push, battery, real networks
Limitations	Not real performance or sensors, no manufacturer quirks	Limited number available

The Android Emulator imitates hardware and OS; the iOS Simulator only imitates the software, so it is even less like a real iPhone.

A practical approach: develop and do early checks on emulators and simulators, run the main tests on a set of real devices in the office, and use a cloud device farm (such as BrowserStack or Firebase Test Lab) for wider coverage. Always confirm release-critical flows, like payments and login, on real devices.

Learn more: Device Fragmentation

The app may share one design, but the two platforms behave differently, so I plan tests for each.

Android

• Fragmentation: hundreds of manufacturers, screen sizes and OS versions, plus custom skins (Samsung One UI, Xiaomi HyperOS) that change fonts, battery savers and permissions.
• System Back button / gesture: every screen needs a sensible Back behavior. Does Back close a modal, or exit the app by accident?
• Install sources: APKs, Play Console testing tracks, Firebase App Distribution. Easy to sideload a build with adb.

iOS

• Fewer devices, faster OS adoption: most users update within months, so I focus on the latest two OS versions and the smallest and largest iPhones.
• Swipe from the left edge to go back, and no hardware Back button, so every screen needs a visible way out.
• Stricter rules: permissions can only be asked once from the app; after “Don’t Allow” the user must go to Settings.
• Test builds come through TestFlight or a registered device.

Both: design conventions differ (iOS action sheets vs Android bottom sheets, date pickers, toasts are Android-only), so I check that each platform feels native and matches its own design, not the other one’s.

Learn more: iOS vs Android Differences

An interruption is anything that takes the user’s attention or the system’s resources away from the app. Users get interrupted all the time, so the app must cope.

What I use to interrupt:

• Incoming phone or video call (from a second phone).
• SMS, push notifications from other apps, alarms and timers.
• Low battery warning, battery saver turning on.
• Losing Wi-Fi or switching to mobile data, airplane mode.
• Pressing Home, opening the app switcher, locking the screen.
• Plugging in headphones or a charger, Bluetooth connecting.

When I interrupt: at the risky moments, not on a static screen. For example: while a video is playing, during a file upload, on the payment confirmation screen, while filling in a long form, or in the middle of a game level.

What I expect afterwards:

• No crash and no frozen screen.
• Form data and scroll position are kept.
• Media pauses and can resume.
• Ongoing actions finish or fail clearly; a payment is never charged twice.
• Timers and sessions behave sensibly after a long interruption.

Example bug: a call arrives while the checkout spinner is showing; after the call, the user taps Pay again and gets two orders.

Learn more: Interruptions (Calls, SMS, Alarms)

When the user leaves the app, it moves through lifecycle states: active, background, suspended, and sometimes killed by the OS to free memory. When the user returns, the app must restore itself correctly. Many bugs hide here.

Typical bugs:

• Lost state: the half-filled form is empty, the user is thrown back to the Home screen.
• Crash on return after the OS killed the process (the app tries to use data that no longer exists).
• Stale data: the inbox still shows old messages, prices are outdated.
• Session problems: the token expired in the background, and the next tap fails silently instead of asking to log in again.
• Audio, timers, location: music stops, a countdown jumps, location tracking stops or drains battery.

How I test it:

1. Background for a few seconds, then for 10+ minutes and overnight.
2. Open several heavy apps (camera, games) to create memory pressure.
3. On Android, enable Developer options > Don’t keep activities to force the worst case.
4. Change things while away: rotate, switch language, dark mode, revoke a permission, log out on another device.
5. Return via the app icon, the app switcher, and a notification.

Learn more: Background and Foreground

I start by asking how notifications are triggered (an action in the app, a backend event, a marketing tool) and how I can send one on the test environment.

Delivery and content

• Arrives on time, with the correct title, text, image and badge count.
• Long text is truncated nicely; special characters and emoji display correctly.
• The right user gets it, and only once.

App states

• App in foreground (in-app banner or silent update?), background, and killed.
• Device locked: lock screen preview respects privacy settings.

Tapping the notification

• Opens the right screen (deep link), even from a killed state.
• Works if the user is logged out: login first, then the target screen.

Permissions and settings

• iOS asks permission; Android 13+ asks too, older Android grants by default.
• If permission is denied, the app does not keep nagging, and in-app settings toggles actually stop notifications.

Edge cases

• No notifications after logout or for a deleted account.
• Many notifications at once are grouped sensibly.
• Do Not Disturb, low network, app reinstalled (new push token).

I test on real devices because simulators and emulators do not always match real push behavior.

Learn more: Push Notifications

Permissions are a classic source of crashes and dead ends, because the user can say no.

What I check:

1. Timing and reason: the app asks when the feature is used (tapping “Scan QR”), not on first launch for everything. A short explanation says why.
2. Every answer:
   • Allow / Allow while using the app.
   • Allow once (iOS and Android 11+): works now, asks again next time.
   • Precise vs approximate location.
   • Deny: the app keeps working and shows a helpful message.
   • Deny permanently (iOS after the first deny, Android after two denies): the app offers a button to open Settings instead of a dead button.
3. Change it later: grant or revoke in system Settings while the app is in the background, then return. No crash, the feature updates.
4. Limited access: iOS “Selected photos” only.
5. Upgrades: permissions survive an app update.

Resetting between tests: reinstall the app, or use Settings > Apps > Permissions. On Android, adb shell pm reset-permissions or pm revoke is fast.

Example bug: after denying camera access, the Scan button shows a black screen forever instead of explaining what to do.

Learn more: App Permissions

Most users don’t install the app fresh; they update it. So upgrade testing is critical.

Fresh install

• Installs from the store or test channel, opens without crashing.
• Onboarding, permission prompts and default settings are correct.
• Works on the oldest supported OS version.

Upgrade (the important part)

1. Install the current production version.
2. Use it like a real user: log in, create data, change settings, save drafts, download offline content.
3. Upgrade to the new build without uninstalling.
4. Check: still logged in (or asked nicely to log in), data and settings kept, database migration worked, no crash on first launch.
5. Repeat from an older version (for example two or three releases back), because users skip updates.

Uninstall and reinstall

• Local data is gone, but server data comes back after login.
• On iOS, Keychain data can survive uninstall; check the app doesn’t log in as the old user unexpectedly.

Edge cases

• Low storage, download interrupted, forced update screen when the version is too old.

On Android, adb install -r upgrades a build in place, which makes this quick.

Learn more: Install, Update and Uninstall

I think of it as a question: does this test depend on real hardware or real-world conditions?

I choose an emulator or simulator when:

• A new feature has just landed and I want quick feedback on the flow.
• I need to check layouts on many screen sizes or OS versions quickly.
• I want to reproduce a bug on a specific OS version I don’t have in the office.
• I need easy tools: screenshots, setting a fake GPS location, changing language, slow network profiles.

I use a real device when testing:

• Camera, NFC, Bluetooth, sensors, biometrics (Face ID, fingerprint).
• Push notifications and interruptions like real phone calls.
• Performance, battery, heat and memory on low-end devices.
• Real networks: switching Wi-Fi to 4G, weak signal in an elevator.
• Manufacturer quirks, like Samsung keyboards or aggressive battery savers.
• Touch feel and gestures, and the final release sign-off.

Example: I verify a new settings screen on three emulator sizes in ten minutes, then confirm the QR scanner and payment flow on a real iPhone and a low-end Samsung.

Learn more: Simulators and Emulators

Gestures

• Tap, double tap, long press: does each do the right thing, and does a fast double tap trigger an action twice?
• Swipe: swipe-to-delete, carousels, pull-to-refresh. Partial swipes and swiping back the other way.
• Pinch and zoom on images and maps: limits, zooming out past the minimum.
• Drag and drop: reorder lists, drop outside the target.
• Conflicts: a horizontal carousel inside a vertical scroll, a side menu vs the iOS swipe-back or Android back gesture, gestures near the screen edges.
• Accessibility: every gesture action is also available another way (a button or a screen reader action).

Rotation

• Rotate on each important screen, especially mid-task: a half-filled form, a playing video, an open modal, a scrolled list.
• Layout adapts: nothing cut off, no overlapping, keyboard still usable.
• No data loss: on Android, rotation recreates the screen, so a classic bug is a form that empties itself.
• Screens that should be locked to portrait stay locked.
• Also check tablets, split screen and foldables if supported.

Example bug: rotating during video playback restarts the video from the beginning.

Learn more: Gestures

Mobile apps can’t simply be “deployed to a URL” like websites, so teams use beta distribution tools.

iOS: TestFlight

• Developers upload a build to App Store Connect; testers get it through the TestFlight app.
• Internal testers (team members) get builds right away; external testers need a quick Apple beta review first.
• Builds expire after 90 days. Testers can send feedback and screenshots from inside TestFlight, and crash reports are collected.

Android

• Google Play testing tracks: internal, closed and open testing. Builds come through the normal Play Store.
• Firebase App Distribution: testers get an email or use the App Tester app; works for iOS too.
• Direct APK installed with adb, common for quick dev builds.

Good habits as a tester

• Always note the version and build number (for example 4.2.0 (318)) and the environment (dev, staging, production) in bug reports.
• After a fix, confirm the new build actually contains it before retesting.
• Keep older builds available for upgrade testing.

Learn more: TestFlight and Firebase App Distribution

Office Wi-Fi is fast and stable; real users are on trains, in elevators and on cheap data plans.

Scenarios I test

• No connection at launch and in the middle of a flow.
• Slow connection (3G-like): loading indicators, timeouts, images loading progressively.
• Flaky connection: requests that fail halfway.
• Switching from Wi-Fi to mobile data during an upload or video.
• Captive portal (hotel Wi-Fi that needs a login page).
• Connection returns: does the app recover by itself or need a restart?

What I expect

• A clear, friendly message, not an endless spinner or a raw error.
• A retry option; offline actions are queued or clearly rejected.
• No duplicate actions: tapping Send twice on a slow network doesn’t send two messages.
• Cached content shown when offline, if the app supports it.

Tools

• Airplane mode and Wi-Fi toggles on a real device.
• iOS Network Link Conditioner (Developer settings), Android emulator network settings.
• Charles or Proxyman to throttle, block or delay specific requests.
• Browser DevTools throttling for the web version.

Learn more: Network Conditions

Good evidence turns “it crashed” into a bug a developer can fix in minutes.

Android

• Connect the device and run adb logcat. Clear it first (adb logcat -c), reproduce, then save the output.
• Look for FATAL EXCEPTION and the stack trace below it; that is what the developer needs.
• adb shell screenrecord or the built-in screen recorder for video; adb bugreport for a full report.
• Android Studio’s Logcat window lets you filter by app.

iOS

• Connect the iPhone to a Mac and open the Console app (or Xcode > Devices and Simulators) to stream logs and view crash logs.
• On the device: Settings > Privacy & Security > Analytics & Improvements > Analytics Data holds crash files you can share.
• TestFlight crash feedback is also sent to the team.
• Screen recording from Control Center.

Both

• Crash reporting tools like Firebase Crashlytics or Sentry: I find the crash there and link it in the ticket.
• Always include the build number, device, OS version, exact time of the crash and steps.
• Paste only the relevant part of the log, and attach the full file.

Learn more: adb Basics

1. Decide which browsers matter. I look at analytics and the supported browser list. A typical list: Chrome, Safari (macOS and iOS), Firefox, Edge, and Samsung Internet if many Android users use it. Usually the latest one or two versions.

2. Split the work.

• Run the full test suite on the most-used browser.
• On the others, run key flows (sign up, login, search, checkout) and the risky areas.

3. Know what usually breaks:

• Layout differences: flexbox/grid quirks, fonts, scrollbars.
• Safari especially: date inputs, autoplay video, cookies blocked by privacy features, 100vh on iPhone.
• Form controls and autofill look and behave differently.
• Newer JavaScript or CSS features not supported yet.
• File uploads, downloads, copy and paste, print.

4. Tools. Real browsers on my machine, real phones for mobile browsers, and a cloud service like BrowserStack or LambdaTest for combinations I don’t have.

5. Report clearly. Include browser name, version and OS, because “it doesn’t work” means nothing without them.

Example: a checkout button worked everywhere except Safari on iPhone, where it was hidden under the bottom toolbar.

Learn more: Cross-browser Testing

A responsive site adapts its layout to the screen size. Designs usually define breakpoints (for example 375, 768, 1024, 1440 px).

How I test

1. Slowly resize the browser from very narrow (320 px) to very wide (1920 px+), watching for anything that breaks between breakpoints, not just at them.
2. Use DevTools device mode to check common phones and tablets in portrait and landscape.
3. Confirm on real devices, because real browsers have toolbars, notches, touch and on-screen keyboards that device mode doesn’t fully simulate.

What I look for

• No horizontal scrolling, nothing cut off or overlapping.
• Navigation collapses into a working menu on small screens.
• Text is readable, images scale and don’t stretch.
• Tables and long words (URLs, emails) don’t break the layout.
• Touch targets are big enough to tap.
• Modals and forms fit the screen and stay usable when the keyboard opens.
• Browser zoom to 200% still works (also an accessibility check).
• Long translated text (German) still fits.

Example bug: at 800 px, between the tablet and desktop breakpoints, the menu items wrap onto two lines and cover the page title.

Learn more: Responsive Design Testing

DevTools let me see what happens behind the page, so I can tell whether a bug is in the front end or the backend.

• Console: JavaScript errors and warnings. A red error when clicking “Save” is great evidence for a bug report.
• Network: every request the page makes, its status code, request payload, response and timing. If Save shows “Success” but the request returned 500, I’ve found the real bug. I can also throttle the network (for example to 3G or Slow 4G) or go offline.
• Application / Storage: cookies, localStorage, sessionStorage. I can clear them to test as a new user or check that a token is removed after logout.
• Elements: inspect HTML and CSS, check alt text and labels, temporarily edit text to test very long values.
• Device mode: quick responsive checks on phone and tablet sizes.
• Lighthouse: basic performance and accessibility audits.

In bug reports I attach the console error, the failing request (URL, status, response) or a HAR file, so developers know where to look straight away.

Example: a search showed “No results” for every query. The Network tab showed a 401 response, so the real problem was an expired session, not the search itself.

Learn more: DevTools for Testers

All three store data in the browser, but they behave differently:

	Cookies	localStorage	sessionStorage
Sent to server	Yes, with every request	No	No
Lifetime	Until expiry date, or until browser closes	Until cleared	Until the tab closes
Size	About 4 KB	About 5-10 MB	About 5-10 MB
Shared between tabs	Yes	Yes (same origin)	No, per tab
Typical use	Login session, consent	Preferences, cart, theme	One-time form steps

Why it matters for testing

• Logout: check that session cookies and tokens in storage are really removed. Then press Back; private data should not appear.
• New user: clear storage in DevTools to test first-visit behavior (onboarding, cookie banner).
• Multiple tabs: a cart in localStorage appears in a second tab; a wizard in sessionStorage does not.
• Security: session cookies should have HttpOnly, Secure and SameSite flags, and sensitive data should not sit in localStorage in plain text.
• Consent: if the user rejects non-essential cookies, tracking cookies should not appear.

You can see and edit all three in DevTools under Application (Chrome) or Storage (Firefox).

Learn more: Cookies, Sessions and Storage

Accessibility means people with disabilities can use the product. Many issues can be found in minutes:

1. Keyboard only: put the mouse away. Can I reach every link, button and field with Tab, in a logical order? Is the focus visible? Can I close a modal with Esc, and am I not trapped?
2. Screen reader: VoiceOver (Mac/iPhone), TalkBack (Android) or NVDA (Windows). Do buttons have meaningful names (“Add to cart”, not “button”)? Do images have alt text?
3. Zoom and text size: browser zoom to 200%, large system font on mobile. Nothing should be cut off or overlap.
4. Color and contrast: text is readable, and color is not the only signal (an error isn’t just a red border, it has a message too).
5. Forms: every field has a visible label, errors are announced and explain how to fix them.
6. Media: videos have captions, nothing autoplays loudly or flashes.
7. Touch targets on mobile are large enough.

Then I run an automated check like Lighthouse or axe to catch things like missing labels and low contrast. Automated tools find only part of the problems, so the manual checks stay important. The standard to reference is WCAG, usually level AA.

Learn more: Accessibility Basics (WCAG)

An API is how the app talks to the server. Testing it directly lets me find bugs before the UI exists and isolate whether a problem is front end or backend.

A request has: a method (GET, POST, PUT, PATCH, DELETE), a URL, headers (like Authorization), and often a JSON body. I get these from the API docs (Swagger/OpenAPI) or by copying a request from the DevTools Network tab.

What I check in the response

• Status code: 201 after creating, 400 for bad input, 401 without a token, 404 for a missing item.
• Body: correct fields, types and values; no sensitive data like password hashes.
• Headers and response time.
• Side effects: the item really exists afterwards (follow up with a GET).

Tests I write

• Valid request (happy path).
• Missing required fields, wrong types, too-long values, empty body.
• No token, expired token, and another user’s ID (can user A read user B’s order?).
• Duplicates, boundary values, pagination limits.

Postman basics: collections to group requests, environments for dev/staging URLs and tokens, variables, and simple tests (pm.expect) so a collection can be re-run as a quick regression check.

Learn more: API Testing with Postman

Every response from the server has a status code. The first digit tells you the group:

Code	Meaning	Tester’s note
200 OK	Success	Still check the body; a 200 can contain an error message.
201 Created	New item created	Expected after a successful POST.
204 No Content	Success, empty body	Common for DELETE.
301 / 302	Redirect	Check old URLs redirect correctly.
400 Bad Request	Invalid input	Should come with a clear validation message.
401 Unauthorized	Not logged in / bad token	App should send the user to login.
403 Forbidden	Logged in, but not allowed	Good sign in access-control tests.
404 Not Found	Doesn’t exist	Show a friendly page, not a blank screen.
409 Conflict	Duplicate or clash	For example, email already registered.
429 Too Many Requests	Rate limited	Expected after many login attempts.
500 Internal Server Error	Server crashed	Almost always a backend bug.
502 / 503 / 504	Gateway, unavailable, timeout	Infrastructure or slow services.

Why it matters: in DevTools or Postman, the status code tells me where to look. A 500 goes to the backend developer; a 200 with wrong data displayed may be a front-end bug. And the UI should handle every error code gracefully.

Learn more: API Testing with Postman

I’m not a penetration tester, but many serious security bugs are easy to spot with simple checks. I only do this on test environments, with permission.

Access control (the most common real problem)

• With two test accounts, open user A’s order URL as user B, or change an ID in the URL or API request. You should get 403 or 404, never someone else’s data.
• A normal user can’t reach admin pages by typing the URL.

Authentication and sessions

• Wrong-login messages don’t reveal whether the email exists.
• Lockout or rate limiting after many attempts.
• Logout and password change really end sessions; the Back button doesn’t show private data.

Input handling

• Special characters, very long input and simple script tags in text fields are shown as text, not executed.
• File uploads reject unexpected types and huge files.

Data exposure

• No passwords, tokens or personal data in URLs, logs, error messages or API responses that don’t need them.
• HTTPS everywhere; cookies use Secure and HttpOnly.

Reporting: security bugs go to a restricted ticket or the security contact, not a public channel. I use the OWASP Top 10 as a map of what to look for.

Learn more: Security Basics for Testers

1. Clarify. Which page or action? Slow to load, or slow to respond to a click? All the time or at peak hours? Which device, browser, network and location? For one user or many?

2. Reproduce and measure. I open the page with DevTools, preferably in a fresh profile with cache disabled, and also try with throttling (slow 4G, CPU slowdown) to mimic a real phone.

3. Find where the time goes.

• Network tab: is one API request taking 6 seconds? That points to the backend (check the “waiting for server” time). Are there huge images, many requests, or files blocking the page?
• Performance tab / Lighthouse: long JavaScript tasks, layout shifts, Core Web Vitals like LCP.
• Compare environments and accounts: maybe it’s only slow for users with 5,000 orders.

4. Report with facts. “Order history takes 7.8 s to load for account X; GET /orders takes 7.2 s and returns 4 MB. Other pages load in under 1 s.” Attach a HAR file or Lighthouse report.

5. Follow up. After the fix, measure again the same way. For load and stress problems, I’d involve someone running performance tests with tools like JMeter or k6.

Learn more: Performance Basics

Both combine rows from two tables using a condition, usually foreign key = primary key, such as ON oi.order_id = o.id.

	INNER JOIN	LEFT JOIN
Rows kept	Only rows with a match on both sides	Every row from the left table
No match on the right	Row is dropped	Right-side columns are NULL

Example. Orders 1001 and 1009 have items, order 1010 has none.

• orders JOIN order_items returns the items of 1001 and 1009. Order 1010 silently disappears.
• orders LEFT JOIN order_items also returns 1010, with NULL in the item columns.

Why testers care: LEFT JOIN plus IS NULL finds things that are missing:

SELECT o.id
FROM orders o
LEFT JOIN order_items oi ON oi.order_id = o.id
WHERE oi.id IS NULL;   -- orders without items

The same pattern finds users who never ordered or orphan rows. And it’s a warning: a report built on an INNER JOIN hides exactly the broken records you’re looking for.

One trap: after a LEFT JOIN, a condition like WHERE oi.dish = 'Pizza' removes the NULL rows again. Put conditions on the right table in the ON clause if you want to keep unmatched rows.

Learn more: SQL for Testers

They filter at different moments:

1. FROM / JOIN builds the rows.
2. WHERE removes rows. Aggregates don’t exist yet, so WHERE COUNT(*) > 1 is an error.
3. GROUP BY folds the remaining rows into groups and calculates COUNT, SUM, AVG…
4. HAVING removes groups, using those aggregates.

SELECT user_id, COUNT(*) AS orders, SUM(total) AS spent
FROM orders
WHERE status <> 'canceled'      -- ignore canceled orders (rows)
GROUP BY user_id
HAVING COUNT(*) >= 2;           -- users with 2+ real orders (groups)

Tester uses: HAVING COUNT(*) > 1 finds duplicates (emails, coupon uses, payment ids), and HAVING with SUM finds orders whose total doesn’t match their items.

Learn more: SQL for Testers

I split it into two questions: who is calling (authentication) and what may they do (authorization). I only do this on a test environment, with test accounts and the team’s OK.

Authentication: expect 401

• No Authorization header, a malformed one (Bearer abc), an expired token and a token whose payload I edited (for example role changed to admin, old signature kept).
• I check every protected endpoint, not a sample. One endpoint that skips the expiry check is enough to keep a stolen token alive.
• If it’s a JWT, I decode it and check exp and the claims, remembering that decoding isn’t verifying.

Authorization: expect 403 or 404

• Horizontal (IDOR): two users with the same role, Anna and Ben. With Anna’s token I request Ben’s order, address and invoice by id, with GET, PATCH and DELETE, and also ids hidden in query parameters or bodies. Expected: 404 or 403 and no data.
• Vertical: a customer token on admin endpoints (GET /admin/users, POST /refunds). Expected: 403 and no side effect, which I confirm with a follow-up request.
• Sneaky fields: a profile update with "role": "admin" must be ignored or rejected.

I like to write a small role × endpoint matrix (anonymous, own, other user’s, admin) so nothing is skipped, and save the requests in a Postman collection so they run on every release. Findings go to the team’s private security channel.

Learn more: API Testing in Depth

A 200 only means the server didn’t complain. I check the response in layers:

1. Status and headers. 201 plus a Location header after a create, 204 after a delete, Content-Type: application/json, and Cache-Control: no-store on personal data.
2. Schema. All documented fields are there, spelled the same on every endpoint, with the right types: a price is a number, not "12.50". Required fields are never null. In Postman I can automate this with pm.response.to.have.jsonSchema(...).
3. Values. The total equals the items plus the delivery fee, dates have the right format and time zone, and enum values are only the documented ones.
4. Consistency. The data matches the database (a quick SQL query) and what the app shows. After an update or delete, I send a GET to prove the change was really saved.
5. Error quality. Errors have one consistent shape, name the field and the rule, and are readable.
6. Leaks. No password hashes, tokens, internal flags, other users’ data, stack traces, SQL or server paths.

Example: a profile update returned 200 with the new phone number, which looked fine, but the body also contained passwordHash and an internal role field. A status-only test would never catch that.

Learn more: API Testing in Depth

I start from the docs (OpenAPI/Swagger): required fields, types, ranges and the documented status codes. Then:

Happy path

• A valid body returns 201, a Location header and the new order. A follow-up GET /orders/{id} and, if I can, a database query show the same data. Server-calculated fields like total and status are right.

Negative and boundary, one change at a time

• Remove each required field in turn → 400 naming that field.
• Wrong types: "quantity": "2", 2.5, an object instead of an array.
• Empty string, null and a missing field are three separate tests.
• Boundaries: if quantity is 1–20, try 0, 1, 20, 21 and -1. Huge values and very long text.
• Invalid enum values ("paymentMethod": "bitcoin"), unknown ids ("restaurantId": 999).
• Malformed JSON → 400; Content-Type: text/plain → 415 (or 400).
• Extra fields like "total": 0 or "status": "delivered" must be ignored or rejected, never applied.

Auth and duplicates

• No token, expired token → 401. Wrong role → 403. Referencing another user’s address → rejected.
• Send the same request twice. With the same Idempotency-Key there should be only one order.

Every response gets checked beyond the status: a 4xx with a clear message, no stack traces, and no order created when the request failed.

Learn more: API Testing in Depth

A JWT (JSON Web Token) is a common format for access tokens. It looks like xxxxx.yyyyy.zzzzz:

• Header: the signing algorithm, e.g. {"alg": "HS256", "typ": "JWT"}.
• Payload: the claims, e.g. sub (user id), exp (expiry, in seconds since 1970), iat (issued at), plus custom ones like role.
• Signature: created by the server with a secret or private key.

The header and payload are only encoded, not encrypted, so anyone holding the token can read them. Decoding is not verifying: only the server can check the signature.

What I test (on a test environment):

• Claims: exp exists and the lifetime matches the requirement; the role is right; nothing secret is in the payload.
• Expired token → 401 on every protected endpoint.
• Tampered token: change role to admin and keep the old signature → 401. An unsigned "alg": "none" token must also be rejected.
• Refresh: the app gets a new access token quietly when the old one expires; after logout the refresh token no longer works.
• Handling: tokens don’t appear in URLs, logs or error messages, and I mask them in bug reports.

I decode test tokens with a local tool or the team’s approved decoder, never production tokens on a public website.

Learn more: API Testing in Depth

Client-side validation runs in the app or the browser before anything is sent. It gives instant feedback: “Enter an email like name@example.com”, “Use at least 8 characters”. It’s there for the user’s convenience.

Server-side validation runs on the server when the request arrives. It repeats the same rules and adds checks only the server can do: is the email already registered, is the item in stock, is this the fifth sign up from the same IP in a minute? It’s there to protect the data and the business.

Why test both?

• Client-side checks can be skipped: anyone can call the API with Postman or curl, change a request with a proxy tool or DevTools, or use an old app version without the newest rules.
• The iOS app, the Android app and the website often have their own client rules, which drift apart. The server is the one place they all meet.
• If only the client checks, bad data gets into the database and breaks other screens, reports or apps later. Sometimes it’s a security problem (XSS, SQL injection).

How I test it

1. Note each rule the app enforces (lengths, formats, required fields, age).
2. Capture a valid request in DevTools or a proxy tool.
3. Send it again with each rule broken: too long, wrong format, missing field, an underage date of birth.
4. Expect a validation error (often 400 or 422) with a clear message per field, and no data saved.

I also check the two layers agree: if the app accepts anna+shop@mail.com but the server rejects it, users get a confusing error after submitting.

Learn more: Forms and Validation

A good error message helps the user fix the problem in one try. I check these things:

• Specific and actionable. “Enter a postcode like SW1A 1AA” instead of “Invalid input”. It says what’s wrong and how to fix it.
• Plain language. No codes (“Error 422”), no jargon (“regex mismatch”), no blame (“illegal value”).
• Next to the field. The message sits under the field, and the field itself is marked. On long forms, an error summary at the top lists all problems as links that move focus to each field.
• Not color only. Red border plus text plus an icon, so people who can’t see red still notice it (WCAG 1.4.1 Use of Color).
• Accessible. The field is marked invalid (aria-invalid), the message is linked to it (aria-describedby), and after a failed submit focus moves to the summary or the first invalid field.
• Right timing. It appears when the user leaves the field or submits, not while they’re still typing, and disappears as soon as the value is fixed.
• Input kept. Nothing the user typed is cleared because of an error.
• Safe. It doesn’t reveal more than it should, for example whether an email has an account on a login or reset screen.

Server errors need the same care: “We couldn’t save your address right now. Your details are kept, please try again” is far better than “Something went wrong”.

Example rewrite: “Invalid date” → “Enter a real date of birth, like 27 3 1995”.

Learn more: Forms and Validation

Agile is a way of building software in small increments, releasing often and adapting to feedback instead of planning everything up front.

Scrum is the most popular Agile framework. Work is done in sprints (usually two weeks), with:

• Roles: product owner (decides what to build), scrum master (helps the process), developers (everyone who builds, including testers).
• Events: sprint planning, daily scrum, sprint review, retrospective, plus backlog refinement.
• Artifacts: product backlog, sprint backlog, increment.

What a tester does in a sprint:

• Refinement and planning: asks questions about user stories, helps write clear acceptance criteria, points out risks and edge cases, helps estimate testing effort.
• Early in the sprint: prepares test scenarios and test data while developers code; tests stories as soon as they are ready, not all at the end.
• During the sprint: reports bugs quickly and talks directly with developers, retests fixes, does exploratory testing.
• Daily scrum: shares progress and blockers (“the filter story is blocked by a crash on Android”).
• End of the sprint: regression testing, helps demo the stories in the review, suggests improvements in the retrospective.

The key idea is that quality is the whole team’s responsibility, and the tester helps the team build it in from the beginning.

Learn more: SDLC and STLC

A user story is a short description of a feature from the user’s perspective:

As a shopper, I want to save products to a wishlist so that I can buy them later.

It describes who, what and why, and is a starting point for a conversation, not a full specification.

Acceptance criteria (AC) are specific, testable conditions the story must meet to be accepted. They are often written as Given / When / Then:

• Given I am logged in, when I tap the heart icon on a product, then it is added to my wishlist and the heart turns red.
• Given a product is in my wishlist, when I tap the red heart, then it is removed.
• Given I am logged out, when I tap the heart, then I am asked to log in.
• The wishlist is kept after logging out and back in, and is the same on app and website.

How testers use them:

• Each criterion becomes one or more test cases.
• While reviewing them, testers spot gaps: What happens when an out-of-stock product is in the wishlist? Is there a maximum number of items? Does it work offline?
• Good AC are clear, testable and measurable. “The wishlist loads fast” is vague; “the wishlist loads in under 2 seconds on 4G” is testable.

Learn more: User Stories and Acceptance Criteria

Automation is an investment: it takes time to build and to maintain, so it should pay back.

Good candidates

• Regression of critical flows that must work on every build: login, sign up, search, checkout, payments.
• Smoke tests run after each deployment.
• Repetitive, data-heavy checks: the same form with 50 data sets, many locales, many API combinations.
• Tests that are boring or error-prone for humans, like comparing long price tables.
• API tests, which are fast and stable compared with UI tests.

Keep manual

• Exploratory testing and new features still changing every sprint.
• Usability, look and feel, and accessibility judgment with a screen reader.
• One-off checks or things that are very hard to automate reliably (real phone calls, some hardware features).

Questions I ask for each test: How often will it run? Is the feature stable? How bad is it if this breaks? How expensive is it to automate and keep green? Can it be tested at a lower level (unit or API) instead of the UI?

As a manual tester, I help by marking candidates in the test suite and writing clear, stable test cases that automation engineers can turn into scripts.

Learn more: Regression and Smoke Suites

A regression suite slowly becomes outdated: features change, screens are redesigned, and old tests describe things that no longer exist. A messy suite wastes time and gets ignored.

Habits that keep it healthy

• Update as you go: when a story changes behavior, update the related test cases in the same sprint.
• Add tests for escaped bugs: every production bug gets a regression test so it can’t come back unnoticed.
• Remove or merge obsolete and duplicate tests. Fewer good tests beat many confusing ones.
• Tag tests by area (checkout, profile), priority (P1-P3) and platform (iOS, Android, web).
• Review regularly, for example once a quarter, together with developers or the product owner.
• Move stable, repetitive tests to automation and note it, so they aren’t also run by hand.

Choosing what to run

• Smoke subset on every build.
• Risk-based subset for a normal release: P1 tests plus the areas touched by changes.
• Full regression before major releases or big refactors.

Example: after a redesign of the profile area, I archived 14 outdated cases, rewrote 6, and added 3 for new edge cases. The profile run went from 2 hours to 50 minutes and became more accurate.

Learn more: Regression and Smoke Suites

I see developers as teammates with the same goal. Here’s how a sprint usually looks for me:

Before coding

• In refinement and planning, I ask questions about edge cases and acceptance criteria, and help estimate testing effort.
• I write test scenarios early and share them with the developer, so they can check the obvious cases while coding.

During the sprint

• Test small pieces as soon as they’re ready, like an API endpoint or one screen, instead of waiting for the whole feature.
• Do quick pair testing or a demo with the developer on their branch.
• Join the daily stand-up to raise blockers (“I can’t test payments, the sandbox is down”).

When I find bugs

• For small issues during development, a quick message or showing them is often faster than a ticket.
• For real bugs, a clear bug report with steps, evidence and environment.
• Retest fixes quickly so stories don’t get stuck.

At the end

• Regression on affected areas, and a short summary of what was tested and any known risks.
• In the retrospective, suggest improvements, like “let’s add test data setup to the story”.

Example: sitting with a developer for 15 minutes on day 3 caught a validation issue that would otherwise have been a ticket ping-pong on day 9.

Learn more: SDLC and STLC

A “mini waterfall” inside a sprint is very common: developers code for eight days, QA tests for two, and bugs roll over. Shifting left is less about testers and more about how the team flows work.

1. Get in before the code

• Join refinement and ask testing questions: “What if the card expires mid-checkout? What does the empty state look like?”
• Hold short three amigos sessions (product, developer, tester) for risky stories, ending with clear acceptance criteria and examples.
• Share my test ideas with the developer before they start coding. Many bugs are prevented because the developer reads the list.

2. Test smaller things, sooner

• Test the API as soon as the endpoint exists, before the UI is ready.
• Test feature branch builds or preview environments instead of waiting for the sprint build.
• Pair with the developer for 20 minutes when a story is “almost done”.

3. Fix the flow, not just the testing

The real cause is often big stories and too much work in progress. I suggest splitting stories so they can be finished and tested within a few days, and limiting how many are open at once. “Stop starting, start finishing.”

4. Help developers test more

Unit and API tests for business rules, a shared checklist for common UI states, and a smoke test they can run before handing over.

5. Start small and measure

I’d propose one or two changes for the next sprint, for example three amigos for every story over a certain size and testing on feature branches. After a few sprints we look at simple signals: fewer stories rolling over, bugs found earlier, less end-of-sprint crunch.

End-of-sprint regression and exploratory testing still happen, but they become a final check instead of the first time anyone looks at the work.

Learn more: User Stories and Acceptance Criteria

I would first ask a few questions: what login methods are supported (email, phone, Google/Apple, biometrics)? What are the password rules and lockout policy? Then I would group my checks:

Functional (positive)

• Valid email and password logs in and opens the right screen.
• “Remember me” / staying logged in works after closing the app.
• Social and biometric login, if supported.

Negative and validation

• Wrong password, unregistered email, empty fields.
• Email with spaces before or after, uppercase letters.
• Very long input, emojis, pasted values.
• No internet or slow network: clear message, no endless spinner.

Security

• Password is masked, with a working show/hide toggle.
• Error message does not reveal which field was wrong (“Incorrect email or password”).
• Account locks or slows down after several wrong attempts.
• Logout really ends the session; the back button does not show private data.

UI and usability

• Correct keyboard type (email keyboard), autofill and password managers work.
• Tab/Next order between fields, Log in button state.
• “Forgot password” link works end to end.

Accessibility and platform

• Screen reader labels, large text, dark mode, rotation.
• On web: Enter key submits, works in all supported browsers.

Learn more: Login and Sign Up

The interviewer is not interested in pens. They want to see how you think. So start with questions, then work through categories.

1. Clarify requirements. Who is it for (kids, office, astronauts)? Ballpoint or fountain? What surfaces should it write on? Any price or lifetime targets?

2. Then structure the tests (example: a lift):

• Functional: pressing a floor button takes you to that floor; doors open and close; the display shows the correct floor; up/down call buttons on each floor work; emergency button and phone connect to help.
• Usability: buttons reachable from a wheelchair, Braille on buttons, audio floor announcements, clear labels.
• Performance: time to arrive after a call; behavior at rush hour with calls from many floors; maximum load.
• Safety: overload alarm and refusal to move; doors reopen when something blocks them; behavior during a power cut or fire alarm; it never moves with doors open.
• Edge and negative cases: pressing all buttons at once; pressing the current floor; pressing a button many times; pressing “close door” while someone enters.
• Compatibility / environment: works in heat, cold and humidity.

For a pen, the same structure applies: does it write (functional), is it comfortable (usability), how many pages until the ink runs out (performance), is the cap safe if swallowed by a child (safety), does it write upside down or on wet paper (edge cases).

Finish by saying how you would prioritize: safety first, then core functions.

Learn more: Types of Testing

A segmented control (like “Day | Week | Month” in a fitness app) and a dropdown (like a “Country” selector) both let the user choose one option from several. I would check:

Selection behavior

• The correct option is selected by default.
• Exactly one option is selected at a time (options are mutually exclusive).
• Tapping an option updates the content below (chart, list, price) correctly, and quickly.
• Tapping the already selected option does nothing strange.
• Fast repeated taps do not show data from the wrong option.

State persistence

• The selection is kept after going to another screen and back, rotating the device, backgrounding the app and, if required, restarting it.

Content and layout

• Long labels and translations (German!) are not cut off.
• Large text sizes, small screens and dark mode.
• Dropdown: long lists scroll, search works if present, the list closes when tapping outside, and the chosen value shows in the field.
• Disabled options cannot be selected.

Accessibility

• Screen reader announces the label, role and “selected” state.
• Touch targets are big enough; keyboard navigation works on web (arrow keys, Enter, Esc for dropdowns).

Platform

• Native iOS/Android look and behavior, and on web, all supported browsers.

Learn more: Segmented Control

First I’d ask: what does it search (products, users, help articles)? Which fields does it match? Is there autocomplete, filtering, or a minimum length?

Input

• Exact match, partial word, different case (“IPHONE” vs “iphone”).
• Typos and plurals, if fuzzy search is supported.
• Leading and trailing spaces, empty search, only spaces.
• Special characters (&, %, quotes), emoji, accented letters, other languages.
• Very long text and pasted text.

Results

• Relevant results first; count is correct; pagination or infinite scroll works.
• Search terms highlighted, if designed.
• No results state is helpful (suggestions, not a blank page).
• Works together with filters and sorting, and keeps them when going back.

Behavior and UI

• Autocomplete suggestions appear quickly and are tappable.
• Enter key or Search button on the keyboard submits; clear (x) button works.
• Fast typing doesn’t show results for an old query.
• Loading and error states, slow network, offline.
• Recent searches saved and deletable, if supported.
• URL contains the query on web, so results can be shared and the Back button works.

Security and accessibility

• Script tags are shown as text.
• Field has a label for screen readers; results are announced.

Learn more: Search, Filters and Sorting

I’d first clarify: guest cart or only logged-in? Maximum quantities? How do discounts, tax and shipping work?

Basic actions

• Add from product page and list, add the same item twice (quantity goes up, no duplicate line).
• Change quantity with buttons and by typing; 0, negative, and above the maximum.
• Remove items, remove the last item (empty cart state), undo if supported.
• Variants: same product in different size or color as separate lines.

Calculations

• Line totals, subtotal, discounts, tax, shipping and grand total are correct.
• Rounding with prices like 9.99 x 3.
• Coupon codes: valid, expired, invalid, applied twice, minimum order value.
• Currency and locale formatting.

Persistence

• Cart survives refresh, closing the app, logging out and in.
• Guest cart merges correctly after login.
• Same account on phone and web shows the same cart.

Edge cases

• Item goes out of stock or changes price while in the cart: clear message.
• Double tapping Add on a slow network.
• Cart badge count matches the cart content.

Handoff: proceed to checkout with exactly the items and totals shown.

Learn more: Shopping Cart and Checkout

I’d ask first: what is the date for (birthday, booking, deadline)? Are there min and max dates? Can the user type the date? Is a time included?

Valid and invalid values

• Today, past and future dates, according to the rules (no booking in the past, must be 18+).
• Boundaries: exactly the min and max date, one day before and after.
• Calendar edge cases: 29 February in leap and non-leap years, 31st of short months, 31 December to 1 January.
• Typed input: wrong formats, letters, partial dates, pasting.

Ranges (check-in / check-out)

• End before start is blocked; same-day ranges follow the rules.
• Changing the start date updates or validates the end date.

Locale and time zone

• Date format follows the locale (12/03 vs 03/12), first day of week (Sunday vs Monday).
• A date selected late at night isn’t saved as the previous or next day on the server because of time zone conversion. Test with the device in a different time zone.
• Daylight saving changes, if time is involved.

UI and platform

• Native pickers differ: iOS wheels or calendar, Android calendar dialog, browser date inputs (Safari behaves differently).
• Clear and cancel work; selected date is shown correctly after reopening.
• Keyboard navigation, screen reader announces the date, large text.

Learn more: Date & Time Picker

I’d ask: how does the user enable biometric login? What is the fallback? What happens after several failures?

Setup

• Offered after a normal login; can be enabled and disabled in app settings.
• iOS asks for Face ID permission (with a clear reason); declining is handled.
• Device without biometrics enrolled: option hidden or explains what to do.

Using it

• Successful scan logs in quickly to the right account.
• Failed scan (wrong finger, covered face): retry allowed.
• Too many failures: the system locks biometrics and asks for device passcode, or the app falls back to its own password.
• Cancel the prompt: user can log in with password instead.

Changes on the device

• New fingerprint or face added in system settings: the app should require the password again before trusting biometrics (a security expectation).
• Biometrics turned off in settings, permission revoked, device passcode removed.

Security and session

• Logout, password change on another device, or account blocked: biometrics no longer log in.
• No sensitive data visible in the app switcher before authentication.

Platform

• Face ID vs Touch ID on iPhones; fingerprint, face unlock and “weak vs strong” biometrics on Android.
• Real devices needed; simulators can only fake a match or no-match.

Learn more: Biometric Login

I’d start with questions: which fields are required, what are the rules for each one (length, format, allowed characters), which countries and languages are supported, and what happens after sign up (confirmation email, automatic login, an existing email)?

Then I’d group my tests:

Happy path

• Sign up with valid data, open the confirmation email, log in with the new account.
• Check every value was saved exactly as entered: on the profile, in emails, in the admin panel or database.

Each field

• Empty, spaces only, valid and invalid classes, and the boundaries: minimum, maximum and one beyond.
• Required vs optional matches the spec.

Real-world data

• Names like O'Brien, Đorđe, Anne-Marie or a single name.
• Emails with + and subdomains, phone numbers with spaces and a country code, postcodes from every supported country.
• Age rules on the exact birthday, spaces before and after, pasted text, emoji.

Validation behavior

• Errors appear on blur or submit (not while typing), say how to fix the problem, sit next to the field, and clear once fixed.
• After a failed submit, focus goes to an error summary or the first invalid field, and nothing typed is lost.

Whole form

• Double tap or double Enter on submit: one account. Email already registered. Server error, no connection, session timeout: clear message, input kept. Back and refresh after submitting.

Server-side

• Send invalid data straight to the API with Postman or DevTools. The server must reject it, not only the app.

Security, accessibility and platforms

• No personal data in the URL, password masked, rate limiting on sign up, marketing consent unticked by default.
• Screen reader labels and error announcements, keyboard only, large text, contrast.
• The right keyboards and AutoFill on iOS and Android, password managers in browsers.

Learn more: Forms and Validation

I use SQL to look behind the screen. The UI shows a view of the data; the database shows what was really stored.

What I use it for

• Verifying results. After placing an order in the app, I run SELECT * FROM orders WHERE id = 1007 and check the total, status and coupon, then the related rows in order_items. The screen can say “Success” while the saved data is wrong.
• Finding test data. “A user with a canceled order and no city saved” is one query instead of an hour of clicking.
• Checking preconditions. Before a test, I confirm the data it needs really exists.
• Investigating bugs. If the stored price is right but the screen shows the wrong one, it’s a front-end bug. If the stored price is already wrong, it’s a back-end bug. That makes my bug report much more precise, and I paste the query and result into it.
• Data-quality checks. Duplicates (GROUP BY email HAVING COUNT(*) > 1), orphan rows (a LEFT JOIN with IS NULL) and totals that don’t match their items.

Safety

I work read-only on shared databases and never run UPDATE or DELETE on staging or production without the team’s approval. If I need to create test data, I do it on my own test database, write the SELECT with the same WHERE first, and use a transaction where possible.

Learn more: SQL for Testers

Group by the value that should be unique, count each group, and keep only groups with more than one row:

SELECT LOWER(TRIM(email)) AS email, COUNT(*) AS accounts
FROM users
GROUP BY LOWER(TRIM(email))
HAVING COUNT(*) > 1;

• GROUP BY makes one row per email.
• HAVING filters the groups after counting. WHERE COUNT(*) > 1 would fail, because WHERE runs before anything is counted.
• LOWER and TRIM catch duplicates that differ only in capitals or spaces. Email providers treat the address part before the @ as case-insensitive in practice, so the app should too.

To see the actual accounts behind each duplicate:

SELECT id, email, signed_up
FROM users
WHERE LOWER(TRIM(email)) IN (
  SELECT LOWER(TRIM(email)) FROM users
  GROUP BY LOWER(TRIM(email)) HAVING COUNT(*) > 1
)
ORDER BY LOWER(email), signed_up;

As a tester I’d report it as a sign-up bug (uniqueness is checked case-sensitively), include the query and the ids, and mention the impact, for example the same person getting two welcome coupons.

Learn more: SQL for Testers

I’d treat the database as the second half of the expected result.

1. Find the record. Use the order number from the confirmation screen: SELECT * FROM orders WHERE id = 1007;. Without it: WHERE user_id = <my test user> ORDER BY created_at DESC LIMIT 5.
2. Compare the fields the app showed. Total, status, restaurant, delivery address, coupon.
3. Check the fields it didn’t show. Foreign keys point to the right user and restaurant, coupon_id is set when I used a coupon, timestamps are in the expected time zone, nothing important is unexpectedly NULL.
4. Check related tables. SELECT * FROM order_items WHERE order_id = 1007; Right dishes, quantities and prices. Then payments, coupon usage, stock or loyalty points, whatever the feature touches.
5. Check that numbers agree. The order total equals SUM(quantity * unit_price) minus discounts, rounded to cents.
6. Check for duplicates and side effects. Exactly one order was created, even after a double tap or a network retry, and nothing else changed unexpectedly.

I do all of this read-only. If something is wrong, I put the queries and their results into the bug report so developers can reproduce it, and I say which layer is broken: if the database is right but the screen is wrong, it’s a front-end bug; if the stored data is already wrong, it’s the back end.

Learn more: SQL for Testers

I match three things before I retest.

1. The ticket. Many teams fill a “Fixed in build” or “Fix version” field. If Jira is connected to the code host, the ticket’s Development panel shows the branch, commits and pull request, sometimes the builds and deployments too.

2. The build. The release notes for a build, or its page in the CI tool, list the PRs or tickets it contains. TestFlight’s “What to Test” and Firebase App Distribution notes often do the same.

3. My device. The app’s About screen, TestFlight or App Tester shows version and build, e.g. 2.1.0 (412). For a website, the version may be in the footer, a /version endpoint or the console.

If the fix is in 412 and I have 411, I don’t retest yet: I install 412 or ask when it lands.

Three traps I watch for:

• A higher number isn’t proof. A hotfix build from an old release branch can be newer and still lack the fix.
• App or backend? A server fix may be on staging but not production, or affect old app versions too.
• Feature flags. The code can be in the build but switched off for my account.

When I verify, I write it down precisely: “Verified on 2.1.0 (412), staging, iPhone 15, flag reorder_current_prices ON.”

Learn more: Git and CI for Testers

Formal studies are great, but most of the time I can still find a lot:

1. Heuristic evaluation. I walk through realistic tasks and check each screen against Nielsen’s 10 usability heuristics: is there feedback after actions (visibility of system status)? Is there a way back or undo (user control and freedom)? Are destructive actions confirmed (error prevention)? Do error messages say how to fix the problem?
2. Platform guidelines. Apple’s Human Interface Guidelines and Google’s Material Design describe expected patterns. Breaking them hurts consistency.
3. Hallway tests. I ask a colleague who hasn’t seen the feature to try one task while I watch quietly, ideally thinking aloud. Five minutes, often eye-opening.
4. Real-world signals. Support tickets, app store reviews and analytics (where people drop out of a flow) show where real users struggle.
5. My own first impression. I note what confused me the first time, before I get used to the feature.

These methods predict problems; they don’t prove them. So in reports I’m clear about the evidence: “2 of 3 colleagues couldn’t find X” or “breaks heuristic 5, one tap deletes the account”. When possible, I recommend a small test with about five real users per round for the riskiest flows.

Learn more: Usability Testing Basics

Use present, past, future, and aim for about 60 to 90 seconds.

• Present: who you are now and what you’re doing toward testing.
• Past: one or two things from your background that make you a good tester, with a concrete example.
• Future: what you’re looking for and why this role or company.

Example answer (career changer):

I’m a customer support specialist at a travel booking company, and for the last six months I’ve been training to become a manual tester. I finished a testing course and a practice project where I tested a food delivery app end to end: a test plan, test cases, bug reports and a release recommendation.

In support, a big part of my day is reproducing problems customers report and writing clear tickets for developers. Last year I noticed that several failed-booking complaints came from older Android phones. I collected the details, and the team found a bug in the payment screen. That’s when I realized I enjoy finding the cause more than closing the ticket.

Now I’m looking for a junior QA role in a product team. Your app is used by people on the go, so mobile quality really matters, and I like that your testers work inside the development teams.

Tips

• Practice from three bullet points, not a script, so it sounds natural.
• Choose the past example on purpose: it’s the thread they’re most likely to ask about next.
• End with the role, then stop. A short pause is fine.

Learn more: Tell Me About Yourself and Why QA

A strong answer has three parts:

1. A true moment or pattern that drew you to testing.
2. What you enjoy about the work itself: investigating, narrowing a vague problem down to exact steps, thinking like the user, helping the team ship with confidence.
3. What you’ve done about it: a course, a practice project, bugs filed in an open-source project, a beta program.

Example answer:

In retail I was always the one who noticed when the till prices didn’t match the shelf labels, and I’d track down why: a wrong product code, an old promotion. When I learned that testing is basically that for software, I took a course and tested a practice food delivery app end to end. The part I enjoy most is turning “something’s wrong with checkout” into exact steps a developer can fix, and knowing that real people won’t hit that problem.

What to avoid

Answer	Why it hurts
“QA is easier than programming.”	Suggests you don’t respect or understand the role.
“I want to move to development in a year.”	Fine to grow, but leading with leaving is a red flag.
“I like technology.”	Says nothing about testing.

It’s perfectly fine to mention you’re curious about automation or other directions later. Frame it as growing within quality, not escaping it.

Learn more: Tell Me About Yourself and Why QA

First, I remember that we are on the same team with the same goal: a good product. So I stay calm and treat it as a puzzle, not a fight.

If they say “it works on my machine”:

1. Re-check it myself on a fresh build to make sure it is still reproducible.
2. Compare environments: device, OS, browser, app build, environment (QA vs local), account, test data, network, language settings. Often the difference is right there.
3. Add evidence: screen recording, exact steps, logs, console errors, the API response.
4. Offer to show them on my device, or reproduce it together. Five minutes side by side often solves it.

If they say “it’s not a bug, it’s expected”:

1. Check the source of truth: requirements, acceptance criteria, designs.
2. If the spec supports me, I point to it politely. If the spec is silent or unclear, it is a question for the product owner, not something the developer and I should decide alone.
3. If it is truly expected but confusing for users, I may suggest it as an improvement instead.

Example: a developer could not reproduce a crash on the checkout screen. We compared and found I was using an account with an expired saved card, while he used a fresh account. Once I shared the test account, he fixed it in an hour.

And if I was wrong, I simply say so and update the ticket.

Learn more: Bug Life Cycle

This happens all the time, so I use risk-based testing: focus effort where a failure would hurt most and is most likely.

1. Assess risk for each area using two questions:

• Impact: how bad is it if this breaks? (money, data, legal, many users)
• Likelihood: how likely is it to break? (new or changed code, complex logic, history of bugs, many integrations)

2. Prioritize:

	High likelihood	Low likelihood
High impact	Test first, in depth	Test the main paths
Low impact	Quick check	Skip or test last

In a shopping app, that usually means: login, search, cart, checkout and payment first, especially if checkout was changed in this release. A rarely used “edit avatar” screen can wait.

3. Use efficient techniques: a smoke test, then exploratory sessions on risky areas, then the most important regression tests (and automated ones, if available).

4. Communicate clearly. I tell the team and product owner what was tested, what was not, and what risk remains. The release decision belongs to the team or product owner, but they should make it with full information.

5. Afterwards, suggest improvements: earlier involvement, more automation for regression, or a feature flag so risky features can be turned off quickly.

Learn more: Writing a Test Plan

Use STAR to keep the answer short and clear (about 1-2 minutes):

• Situation: the project and context.
• Task: what you were responsible for.
• Action: what you did to find and investigate the bug. This is the most important part.
• Result: the impact, and what you or the team learned.

Example answer:

Situation: I was testing a food delivery app before a big release with a new checkout.

Task: I had to test the payment flow on iOS and Android.

Action: All the scripted tests passed, so I did some exploratory testing around interruptions. I started a payment, and while the spinner was showing, I switched to my banking app to approve it and then came back. On Android the app showed an error, so I tapped Pay again. The order was charged twice. I reproduced it three times, captured logcat and the network requests, and saw that the app sent the payment request again when returning to the foreground.

Result: The developer fixed it the same day and added a check against duplicate payments. It would have hit many users, since most of them approve payments in their banking app. Since then, I always include interruption tests in payment flows.

If you’re a beginner, a bug from a course project, a personal app or crowdtesting is perfectly fine. Just make it real.

Learn more: How to Write a Bug Report

Almost every release ships with some known bugs. My job is to make sure the decision is made knowingly.

1. Make the risk visible. I list the open bugs with severity, how many users are affected, platforms, and whether there’s a workaround. For example: “On Android 10 only (3% of users), the profile photo upload fails. Workaround: upload from the web.”

2. Give a clear recommendation. I say what I think, with facts: “I’m comfortable releasing with these four minor bugs. I would not release with the payment rounding bug, because it affects every order.”

3. Let the right person decide. The product owner or release manager makes the go/no-go call. If they accept a risk I flagged, that’s their call, and I make sure it’s documented.

4. Reduce the impact.

• Feature flags to turn off the broken part.
• Release notes or support team informed about known issues and workarounds.
• Fixes planned for the next sprint or a hotfix.

5. Watch after release. Check crash reports, store reviews and support tickets, and verify the fixes when they arrive.

If a critical bug is open, such as data loss or a security issue, I clearly push back and escalate, calmly and with evidence.

Learn more: Severity vs Priority

Interviewers ask this to see how you disagree, not whether you win. Use STAR (Situation, Task, Action, Result) and keep it under two minutes.

Example answer:

Situation: In a food delivery app, I found that the “Reorder” button added items even if they were no longer on the restaurant’s menu. The developer said it was fine, because checkout would show an error later.

Task: I thought users would be confused and lose trust, and I needed to raise that without turning it into an argument.

Action: First I asked him to explain his reasoning, and I learned the menu API was slow, so checking availability on Reorder would add a delay. Then I showed him a short recording of the user experience: three items added, then an error at payment. I suggested we ask the product owner, since it was really a product decision. We brought both views to her in five minutes, with the trade-off clearly stated.

Result: She chose a middle ground: check availability in the background and show a message on the cart. The developer and I worked well together after that, and I learned to ask about technical constraints before pushing my view.

What makes this work

• You listened first and understood the other side.
• You used evidence, not opinions.
• You moved the decision to the right person.
• You ended with a result and a lesson.

If you’re new to testing, a disagreement from a school project, a previous job or volunteer work is fine. Just make it real.

Learn more: Bug Life Cycle

Some repetition is part of testing, like regression runs before every release or checking the same flow on several devices. The risk isn’t boredom itself, it’s missing things because you’re on autopilot.

How I stay sharp

• Use checklists. They keep me from skipping steps when I’ve done something ten times.
• Vary the details: different accounts, data, devices or order of steps each run. The goal stays the same, but I see the product from new angles, and that’s how I often find new bugs.
• Stay curious: I ask “what changed since last time?” and look at those areas more closely.
• Short breaks between long runs, and I don’t run a big regression late in the day if I can avoid it.
• Batch similar work, for example all the iPad checks together, to reduce switching.

Make it better for the team

• If I run the same checks every sprint, I suggest them for automation and help write the scenarios.
• I remove or merge outdated test cases, so the suite is shorter.
• I keep test data ready to save setup time.

Example: our release smoke test took me about two hours on three devices. I listed the most stable steps and worked with a developer to automate them. Now I spend that time on exploratory testing of new features, which is where most bugs are found anyway.

Learn more: Regression and Smoke Suites

Everyone makes mistakes, and interviewers know it. They want to see ownership and learning. Use STAR and spend most of the time on what you did and changed.

Example answer:

Situation: I was testing a fitness app release that included a new workout timer.

Task: I had to test the timer and run the regression checklist on iOS and Android.

Action: I tested the timer carefully on both platforms, but only with the app in the foreground. After release, users reported that the timer stopped when they locked the screen, which is what most people do during a workout. When I saw the reports, I told my lead right away that I had missed that scenario, reproduced it within minutes, and wrote a clear bug report so the developer could start immediately. I tested the hotfix the same day, including locking the screen, switching apps and receiving a call.

Result: The fix was out in two days. Since then, I always include background, lock screen and interruption checks for any feature that runs over time, and I added them to our regression checklist so the whole team covers them.

Tips

• Choose something real but not disastrous.
• Own it: “I missed”, not “it was missed”.
• The lesson should be a concrete habit or change, not just “I’ll be more careful”.

Learn more: Interruptions (Calls, SMS, Alarms)

I mix using, reading and asking, and I start contributing early.

1. Use the product like a customer

I sign up, complete the main flows, and try the main job of the app: order food, transfer money, book a trip. I note anything confusing; a fresh pair of eyes notices things the team stopped seeing.

2. Read what exists

• User stories and recent tickets, especially bugs: they show where the product breaks.
• Support tickets and app store reviews: they show what users struggle with.
• Any docs, designs, API documentation and the glossary of domain terms.

3. Talk to people

Short chats with a developer, the product owner and someone from support. Good questions: “What are the most important flows? What breaks most often? What would be the worst bug for us?”

4. Build a simple map

A list or mind map of features, user types, integrations and risky areas. It becomes my guide for testing and grows over time.

5. Start testing small things

I pick a small story or do a focused exploratory session in a low-risk area. Testing is one of the fastest ways to learn how a product really works.

For a new domain like banking or insurance, I also learn the key terms and rules (for example, what a pending transaction is), because many bugs only become visible once you know how things should work.

Learn more: Testing Without Documentation

Changing priorities are normal, especially around releases and production issues. What matters is that nothing gets lost and everyone knows the impact.

1. Clarify the change

“Should I stop the checkout testing completely, or finish the critical part first?” I make sure I know what’s more important now and what’s being pushed back, and who decided.

2. Save my state

Before switching, I take two minutes to note what I tested, what’s left, open questions and any suspicious behavior. I update the ticket so it clearly shows “partly tested”, not “done”.

3. Communicate what moves

I tell the team or the product owner: “I’m switching to the production issue. The new filter feature won’t be tested today, so it may not make tomorrow’s build.” That way the delay is a known decision, not a surprise.

4. Focus on the new task

I give the urgent work my full attention instead of switching back and forth all day.

5. Come back and review

When I return, I re-read my notes and check whether anything changed in the meantime, like a new build or a changed requirement.

Example: in the middle of testing a new loyalty program, a payment bug hit production. I noted where I was, moved the ticket back to “In testing” with a comment, and helped reproduce and verify the hotfix. The next morning, my notes let me continue in minutes, and the PM already knew the loyalty feature would be a day late.

Learn more: Working with Jira

There’s no universal right number: junior QA salaries vary a lot by country, city, company and industry. What matters is that you’ve done your research and can answer calmly.

1. Prepare before any call

• Look at job ads that publish salary ranges. In some countries and US states employers must share a range in the ad or before the interview.
• Check salary surveys or comparison sites for your country, and official statistics where available.
• Ask testers in local communities, or recruiters, who usually know the market.
• Decide your realistic range and your minimum, and whether you mean gross or net, monthly or yearly.

2. Early in the process, ask for their range

I’d like to understand the role a bit better first. Could you share the range you’ve budgeted for this position?

3. If they insist, give your researched range

Based on what I’ve seen for junior QA roles in [city], I’m looking at something between [X] and [Y], depending on the full package and the growth opportunities.

4. Be honest

• Never invent a current salary or a competing offer.
• In some places employers aren’t allowed to ask about salary history. You can still politely decline: “I’d rather focus on what’s fair for this role.”
• If an offer is lower than your research suggests, you can ask once, politely, with reasons.

Learn more: Tell Me About Yourself and Why QA

Use four steps:

1. Agree honestly. Don’t argue with the facts.
2. Reframe with real testing work you’ve done, and offer to show it.
3. Connect transferable experience from past roles.
4. Show how you learn, with a fact rather than an adjective.

Example answer:

That’s right, I haven’t worked as a tester yet. But I’ve done the work of testing on a complete practice project: I planned the release by risk, wrote test cases, filed bug reports with steps and evidence, and wrote a go/no-go recommendation. It’s all in my portfolio, and I’d be happy to walk you through one bug report.

In my five years in customer support I reproduced customer problems and wrote tickets developers could act on every day, so the communication side of testing isn’t new to me.

I learned all of this in six months while working full-time, and I’d bring the same approach to learning your product.

Why it works

• It’s honest, so there’s nothing to catch in follow-up questions.
• It replaces the missing job title with evidence they can check.
• It ends with an offer to show work, which moves the conversation to your strengths.

Learn more: A QA CV and Portfolio Without Experience

Always have two or three questions ready, and adapt them to who you’re talking to. The answers also help you decide if you want the job.

About the work

• What does a typical week look like for a tester here?
• How do testers and developers work together? When does QA first see a feature?
• Is testing mostly manual, automated or both? Is there a path toward automation for someone interested?
• How are releases tested, and who decides whether something ships?

About the team and growth

• How many testers are on the team, and who would I learn from?
• What would a great first three months look like in this role?
• What’s the biggest quality challenge the team has right now?

About the process

• What are the next steps, and when can I expect to hear back?

Match the question to the person

Interviewer	Good topics
Recruiter	Process, timeline, team structure, salary range
Tester or QA lead	Test process, tools, releases, learning
Developer or product owner	Collaboration, how bugs are handled, what they value in a tester
Manager	Expectations, growth, how success is measured

Benefits and vacation are fair questions, best asked with the recruiter or at the offer stage.

Learn more: How QA Hiring Works

I don’t start by writing. I start by listening, because a strategy is only useful if it fits this product, this team and this stage.

1. Understand the product and its risks (first 1-2 weeks)

• Who are the users, and what would hurt them most? Losing money, losing data, a broken sign-up, a privacy leak?
• What are the business goals for the first release: speed to market, a pilot with one big customer, an app store launch?
• Is there regulation? Payments, health data, accessibility laws in the target markets.
• Which parts are complex or new for the team, such as a third-party payment provider or offline sync?

2. Make the key decisions with the team

• Quality goals: what “good enough to release” means here, in plain words.
• Test levels: what developers cover with unit and API tests, what I cover with exploratory and end-to-end testing, and where we need contract or integration tests.
• Manual vs automation: in an early product the UI changes constantly, so I’d invest early in API checks and a small smoke suite, and keep the rest exploratory until flows stabilize.
• Environments and test data: at least one stable test environment, a way to create accounts and orders quickly, and production-like data that is safe to use.
• Platforms: an initial device and browser policy based on the target market, to be replaced with real analytics after launch.
• Bugs and releases: how bugs are triaged, which severities block a release, who makes the go/no-go call.

3. Keep it short and alive

I write it as one or two wiki pages, review it with the developers and product owner, and put a date on it to revisit after the first release, because a pre-launch strategy and a strategy for a product with 100,000 users are different things.

Example: on a new fintech app, the biggest risks were the card top-up flow and identity verification. We agreed that every change there needed API tests plus a manual end-to-end pass on real devices, while profile and settings screens only got exploratory testing. That one decision shaped most of our effort.

Learn more: Writing a Test Plan

Risk-based testing is easy to say and harder to do well. Here is how I run it.

1. List the risks with the people who know them (30-60 minutes)

I run a short session with a developer and the product owner. Developers know where the code is fragile; the product owner knows what would hurt the business. We list risk items as concrete statements, for example “a user is charged but the order is not created”, not just “checkout”.

2. Score impact and likelihood

• Impact: money, data loss, legal exposure, number of users affected, reputation.
• Likelihood: what changed in this release, code complexity, new integrations, how many bugs this area had before, and production incidents.

A simple 1-3 scale for each is enough. The point is the conversation, not precise numbers.

3. Map the score to test depth, not just order

Risk	What I do
High	Scripted checks plus exploratory sessions, real devices, negative and edge cases
Medium	Main paths and the riskiest edges
Low	A quick smoke check, or nothing, stated openly

4. Re-evaluate as I go. If I find three bugs in an area I rated “medium”, its likelihood just went up, and I shift time there.

5. Report in terms of risk. “All high risks are covered and pass. Two medium risks were only partly tested: currency formatting in Arabic and the iPad layout. Low risks not tested: settings and help pages.”

That last step is what makes it risk-based testing instead of just running fewer tests. People can only accept a risk they can see.

Learn more: Writing a Test Plan

Every test plan leaves things out. The skill is doing it on purpose and out loud.

What I usually consider leaving out

• Areas that didn’t change and have no shared code with what did change, and have a clean history.
• Things already covered well at another level, such as validation rules covered by API or unit tests.
• Low-impact, low-usage features: if analytics show 0.5% of users open a screen and a failure would be cosmetic, it gets a smoke check at most.
• Platform combinations outside the agreed device and browser matrix.
• Third-party systems we don’t own, beyond checking our integration with them.

How I get agreement

1. Write it down in the test plan under “Out of scope”, with one line of reasoning per item.
2. Frame it as a trade-off, not a request: “If we test the old export screen, we lose half a day on the new checkout. I recommend skipping export because it hasn’t changed since March.”
3. Ask the product owner to confirm. A quick “agreed” on the ticket or in the planning meeting is enough. It becomes the team’s decision, not mine.
4. Name the trigger to revisit: “If the export code is touched, it moves back into scope.”

Example: for a redesign of an e-commerce home page, I proposed not testing the legacy gift card flow on old Android versions, which had a tiny share of users and no code changes. The PM agreed, and we spent the time on the new product carousel, where we found a crash on small screens.

If something I chose not to test breaks later, the written decision makes the retro about improving our risk judgment, not about blame.

Learn more: Writing a Test Plan

You can’t buy every phone, so the goal is maximum risk coverage per dollar.

1. Data first

• The app’s own analytics (for example Firebase, App Store Connect, Google Play Console): top devices, OS versions, screen sizes, and how that differs by market.
• If the app is new, public market share for the target countries (for example StatCounter) as a starting point. A banking app launching in one country should not use a global average.
• Crash and review data: devices that already cause trouble.

2. Add risk-based picks that analytics alone would miss

• The oldest supported OS version on each platform, and the newest (plus the public beta before a major release).
• A small screen and a large screen or tablet if supported.
• A low-end Android with little RAM, because memory pressure and slow CPUs reveal bugs flagships hide.
• Key manufacturers with custom Android skins, such as Samsung or Xiaomi, because of battery and background restrictions.
• Hardware the app relies on: NFC for payments, a specific camera setup, biometrics.

3. Tier it

Tier	Devices	Used for
1	4-6 real devices covering most users	Every release, full regression of critical flows
2	Wider set, often in a cloud device farm	Smoke and key flows before major releases
3	Emulators and simulators	Layouts, early checks, many screen sizes

4. Spend wisely. A few mid-range and older real phones are often better value than one new flagship. A cloud farm such as BrowserStack or Firebase Test Lab covers breadth without buying hardware.

5. Review it every quarter or after each major OS release, and write the policy down so “why don’t we test on X?” has a clear answer.

Learn more: Device Fragmentation

The hardest part of a migration is that most of the requirements are unwritten: the old system is the spec, including behavior nobody remembers adding.

1. Inventory what exists

• Map current features and flows, including edge cases: discount rules, rounding, time zones, deep links, emails, push notifications, integrations.
• Use analytics and support tickets to see what users actually do, and talk to support about “weird” behavior customers rely on.
• Decide with the product owner which differences are intended (the redesign) and which would be regressions.

2. Compare old and new

• Run the same scenarios in both systems and compare results: prices, totals, search results, generated documents.
• For backend migrations, compare API responses for the same inputs. Developers can often automate this comparison, and I focus on reviewing the differences.

3. Test the data and the upgrade path

• Existing accounts with real-shaped data: very old accounts, long names, special characters, users with thousands of orders.
• Upgrade from the old app version to the new one: are users still logged in, are settings, drafts and offline data kept?
• What happens to users who don’t update the app but hit the new backend?

4. Plan the rollout with a way back

• Prefer a gradual switch: a feature flag, a percentage of traffic, or one market first.
• Ask early: how do we roll back, and what happens to data written in the new system if we do?
• Agree on what to monitor in the first days: error rates, failed payments, support tickets.

Example: in a checkout migration, comparing order totals between the old and new system revealed that the new one rounded tax per line instead of per order. It was a few cents per order, but it would have broken invoices for business customers.

Learn more: Install, Update and Uninstall

Vague requirements are normal, especially in fast-moving teams. Waiting for a perfect spec isn’t an option, but guessing silently isn’t either.

1. Find other sources of truth (oracles)

• Designs, the ticket’s comments, Slack threads, the API documentation.
• Comparable products: how the existing web version, a competitor or the platform convention behaves.
• Consistency with the rest of our own app.
• The people: a 10-minute call with the product owner and developer clears up more than a day of guessing.

2. Write my assumptions down and get them confirmed

I list them in the ticket: “I assume a promo code can’t be combined with gift cards. I assume the limit is per account, not per device.” Then I ask the product owner to confirm or correct them. This turns hidden assumptions into acceptance criteria.

3. Explore to learn, in short sessions

Time-boxed exploratory sessions with a charter, for example “explore the referral flow with new and existing users to discover the rules for rewards”. I note what the feature does, and that becomes lightweight documentation.

4. Separate bugs from questions

Clear failures (crashes, data loss, inconsistencies with confirmed rules) are bugs. “Should it do X or Y?” is a question for the product owner, not a bug report. Mixing them creates noise and arguments.

5. Fix the cause, not only the feature

As a senior, I raise it in the retro and suggest something concrete: testers joining refinement, acceptance criteria as a “definition of ready” item, or a short “three amigos” talk before work starts.

Learn more: Testing Without Documentation

I like metrics that help the team make a decision or spot a trend, and I’m careful with any metric that becomes a target for people.

Goodhart’s law is the key idea, often phrased as “when a measure becomes a target, it ceases to be a good measure.” If testers are rewarded for bug counts, you get many tiny duplicate bugs. If the team is judged on pass rate, failing tests get skipped or rewritten until they pass.

Metrics I find useful (as trends, with context)

• Escaped defects: bugs found in production, ideally grouped by severity and by why they escaped. This is the closest to what users experience.
• DRE (defect removal efficiency; ISTQB uses a similar measure called defect detection percentage): bugs found before release ÷ (bugs found before release + bugs found after release), for a defined period. Useful as a trend, but it depends on how you count, and it can look great simply because production bugs aren’t reported.
• Crash-free users or sessions and app store ratings for mobile apps.
• Lead time and the four DORA metrics (deployment frequency, lead time for changes, change failure rate, and time to restore service). They measure the delivery system as a whole, not testers.
• Time from bug report to fix for high-severity bugs.

Metrics that are risky on their own

• Number of bugs found per tester: rewards quantity, punishes testers on stable areas.
• Test pass rate: 98% passing says nothing if the 2% failing are all in checkout, or if the tests don’t cover the risky parts.
• Number of test cases or “test coverage %” without saying coverage of what.
• Bugs per developer: destroys trust and makes people argue about bug reports.

How I use them: few metrics, shown as trends, discussed by the team, and always with a story: “Escaped bugs went up this quarter; four of six came from the new payment provider, which we can’t test in staging. Here’s what I propose.”

Learn more: Writing a Test Plan

Automation is an investment: it pays off when the time saved by running a check many times is larger than the cost of building it and keeping it working.

What I’d automate first

1. A small smoke suite of the critical paths (login, search, checkout), run on every build.
2. API checks for business rules: they’re faster and far more stable than UI tests.
3. Data-heavy, repetitive checks: many locales, price combinations, validation rules.
4. Regression for escaped bugs that would be expensive to see again.

New features that change every sprint, visual and usability judgment, and one-off checks stay manual.

How I work with automation engineers

• I bring the “what” and “why”: prioritized scenarios with clear steps, data and expected results, plus the risk behind each one.
• They bring the “how”: the right level (unit, API, UI), framework design, stable selectors. I ask developers to add accessibility labels or test IDs where needed.
• We review together which manual cases can be retired once automated, so nothing is run twice.
• I review failures with them: is it a product bug, a test bug or an environment issue?

Flaky tests

A flaky test is a test that passes and fails without any change in the code. It’s worse than no test, because people learn to ignore red builds. Our rule was: quarantine it right away, open a ticket, and fix or delete it within the sprint. Sometimes the “flakiness” is a real race condition in the app, so I investigate before we blame the test.

Keeping exploratory testing

The best outcome of automation is that I spend less time on repetitive checks and more time exploring the risky, new and weird parts. I make that explicit in planning, so the saved time doesn’t silently disappear.

Learn more: Regression and Smoke Suites