Java QA Automation Engineer interview prep

Short answer: A full test case with preconditions, steps, and expected result is needed where reproducibility and traceability matter: audit, compliance, complex multi-step flows. A lightweight checklist is enough for regression on stable features and exploratory sessions, where speed matters more.

In depth:

1. Test case — a formal document anyone can replay step by step; expensive to write and maintain.
2. Checklist — a list of what to verify, without detailed steps; fast to draft, flexible to use.
3. Selection criterion — maintenance cost versus the need for rigor and auditability.

⚠️ Common mistake: dragging heavy formal test cases into places where a checklist suffices and drowning in documentation upkeep instead of actual testing. The interviewer wants to hear you justify the choice under time pressure.

Short answer: New → Assigned → In Progress → Fixed → Retest → Closed. That's the main flow, but it has important branches: Reopened (the bug came back after the fix), Rejected (not a bug), Duplicate (already filed), Deferred (postponed). The key to the answer is naming not just the line but the branches, and who performs each transition.

In depth:

1. New — the tester filed the bug.
2. Assigned → In Progress — the lead assigns a developer, who picks it up.
3. Fixed — the developer fixed it and handed it back for verification.
4. Retest → Closed — the tester re-verifies on the new build and closes it.
5. Branches — Reopened (tester), Rejected/Duplicate (developer or lead), Deferred (PM postpones it).

 New ──► Assigned ──► In Progress ──► Fixed ──► Retest ──► Closed
 (QA)     (lead)        (dev)         (dev)     (QA)       (QA)
           │                                      │ failed
           ▼                                      ▼
 Rejected / Duplicate (dev, lead)          Reopened ──► back into work
 Deferred (postponed by PM)

⚠️ Common mistake: naming only the straight line New→Closed and forgetting the Reopened/Rejected/Duplicate/Deferred branches — those are exactly what show you've worked in a real tracker.

Short answer: The client (browser, mobile app) sends a request, the server processes it and returns a response — the request/response model over HTTP. You can't rely on client-side validation because the client is fully under the user's control: the form can be bypassed via curl, Postman, or DevTools and any data sent to the server. So the server must validate itself, and QA tests both layers independently.

In depth:

1. Client — renders the UI, does first-pass validation for convenience (fast feedback, less traffic), holds the token.
2. Server — the source of truth: checks permissions, validates the body, writes to the DB. It's the only layer you can trust.
3. What QA does — doesn't just click the UI but hits the API directly, bypassing the client: sends empty/invalid fields, someone else's id, injections — and checks the server rejected them (400/403) rather than saving them.

  CLIENT                         SERVER
 ┌────────┐   request  (HTTP)  ┌─────────┐
 │  UI    │ ─────────────────► │  API    │
 │ ✔ UX   │                    │ ✔ manda-│
 │ valid. │ ◄───────────────── │ tory    │──► DB
 └────────┘   response         │ valid.  │
     ▲  can be bypassed:       └─────────┘
     └── curl / Postman / DevTools

⚠️ Common mistake: assuming that because the Submit button is disabled on the form, invalid data never reaches the server. The UI is bypassed in a second — a robust system validates everything server-side.

Short answer: adb controls an Android device or emulator: installing a build, clearing data, deep links, screenshots and logcat — the system log, which you filter down to the app's process. xcrun simctl does the same for the iOS Simulator (macOS with Xcode): install, launch, openurl, a simulated push, a screenshot and log stream. A bug report gets the log around the moment of failure, not an hour of the whole stream.

In depth:

1. Clean start — pm clear wipes the app's data, logcat -c clears the buffer before you reproduce.
2. Only the app's log — the --pid filter by process; Android crashes live in the crash buffer, and for ANRs and system issues there is adb bugreport (a zip archive).
3. Scenarios — a deep link via am start -a VIEW -d, process death in the background via am kill, permissions via install -g or pm grant.
4. iOS — simctl push tests push handling without APNs, simctl privacy grants and resets permissions; logs and crash reports from a real iPhone come from Xcode (Devices and Simulators) or Console.app.

# Android: device or emulator
adb devices                                  # is it connected?
adb install -r -g app-debug.apk              # reinstall, grant permissions
adb shell pm clear com.example.shop          # wipe app data
adb logcat -c                                # clear the log before the steps
adb logcat --pid=$(adb shell pidof -s com.example.shop) > app.log
adb logcat -b crash -d                       # stacks of recent crashes
adb shell am start -a android.intent.action.VIEW -d "shop://orders/42"
adb exec-out screencap -p > screen.png

# iOS Simulator (macOS + Xcode)
xcrun simctl install booted Shop.app
xcrun simctl launch booted com.example.shop
xcrun simctl openurl booted "shop://orders/42"
xcrun simctl push booted com.example.shop push.json
xcrun simctl io booted screenshot screen.png
xcrun simctl spawn booted log stream --predicate 'process == "Shop"'

⚠️ Common mistake: attaching an unfiltered logcat or a screenshot with no log to a bug report. The developer needs the exact time, the PID and the exception stack — clear the buffer, reproduce, and save the process log.

Short answer: A primitive holds the value itself, and a reference variable holds a reference to an object. Local variables live on the thread's stack and objects on the heap. Java always passes arguments by value: for an object, the reference is copied, not the object.

In depth:

1. Primitives — byte, short, int, long, float, double, char, boolean. They cannot be null, and == compares values.
2. Reference types — classes, interfaces, arrays. A variable can be null, and == compares references.
3. Where they live — it depends on the declaration: a local int sits in a stack frame, an int field sits inside the object on the heap. The JIT may eliminate an object allocation, but that does not change program behaviour.
4. Passing to a method — the method gets a copy. Through a copied reference you can change the shared object: a helper calling users.add(...) changes the caller's test data too. You cannot repoint the caller's variable at another object.

static void change(int count, List<String> users) {
    count++;                     // a copy of the number
    users.add("bob");            // a copy of the reference, same object
    users = new ArrayList<>();   // only the local copy changes
}

int count = 1;
List<String> users = new ArrayList<>(List.of("ann"));
change(count, users);
System.out.println(count);       // 1
System.out.println(users);       // [ann, bob]

⚠️ Common mistake: saying objects are passed by reference. If they were, users = new ArrayList<>() would replace the caller's list too, and it does not.