I’ll follow this structure for every topic 👇

👉 Question
👉 What the interviewer is checking
👉 What to do (Concept)
👉 Practical Steps (Postman)
👉 Expected Result / Status Code
👉 How to explain in interview (Sample Answer)

CRUD Meaning:

• Create → POST
• Read → GET
• Update → PUT / PATCH
• Delete → DELETE

✅ What is Core Validation?

Core validation means checking whether the API is behaving correctly, not just whether it gives a
response.

👉 As a tester, we never trust only the response.

We validate:

• Status code
• Data in response
• Data changes in DB (via GET)

1️⃣ API Methods & Status Codes (POST & GET)

Interview Question

“Create a POST request to create a user and then fetch the same user using GET.”

What the interviewer is checking

• Do you understand HTTP methods

• Can you create and fetch data
• Do you know status codes
• Can you use Postman properly
What to do (Concept)

• POST → Used to create new data

• GET → Used to fetch existing data
• Server gives status codes to show success/failure

Practical Steps (Postman)

Step 1: Create user using POST

1. Open Postman
2. Select POST method
3. Enter URL
4. [Link]
5. Go to Body → raw → JSON
6. Enter data:

{
"name": "Samiksha",
"email": "samiksha@[Link]",
"age": 25
}

6. Click Send

Step 2: Verify POST response

• Check Status Code → 201 Created

• Response body should show user data with ID

Step 3: Fetch user using GET

1. Select GET
2. Use URL:

[Link]

3. Click Send

Expected Result
 Action Status Code
POST success 201 Created
GET success 200 OK

How to explain in interview

“First I create a user using POST method by passing data in JSON format. After getting 201
Created status, I use the user ID in a GET request to fetch the same user and verify the data.”

2️⃣ Positive, Negative & Boundary Testing (Age Field)

Interview Question

“If Age is mandatory and allowed range is 18–60, how will you test it?”

What the interviewer is checking

• Test case thinking

• Edge cases
• Validation understanding
• Real-time QA mindset

What to do (Concept)

Test Type Meaning

Positive Valid input
Negative Invalid input
Boundary Edge values
Data Type Wrong data type

Practical Test Scenarios

Positive Testing

• Age = 25
• Expected → Accepted

Negative Testing
 • Age = blank
• Expected → Error

Boundary Testing

• Age = 17 → Fail
• Age = 18 → Pass
• Age = 60 → Pass
• Age = 61 → Fail

Data Type Testing

• Age = "Eighteen" (string)

• Expected → Validation error

Expected Status Codes

Scenario Status
Valid age 200 OK
Blank / invalid 400 Bad Request

Interview Answer

“I will perform positive testing with valid age, negative testing by leaving the field blank,
boundary testing using 17, 18, 60 and 61, and data type testing by passing string instead of
number.”

🔹 3. Environment & Reusability (Postman)

(Full Practical Steps + Explanation)

🔸 A. What is an Environment in Postman?

✅ Meaning (Simple)

An environment is a place where we store reusable values like:

• Base URL
• Token
 • IDs

Instead of writing them again and again in every request.

🔸 Why We Use Environment Variables?

• Avoid hardcoding values
• Easy to change data in one place
• Same collection works for Dev, QA, Prod
• Saves time & avoids mistakes

🔸 B. Create an Environment (Step-by-Step)

🛠 Practical Steps

1⃣ Open Postman
2⃣ Top-right corner → Click Environment dropdown
3️⃣ Click Manage Environments
4️⃣ Click Add

🛠 Add Environment Details

Environment Name:

QA

Add Variables:

Variable Name Initial Value Current Value

base_url [Link] [Link]

token

user_id

5️⃣ Click Save

🎯 Expected Result
 • Environment created with variables

📌 Actual Result

• QA environment visible in dropdown

🔸 C. Use Environment Variables in Requests

🛠 Practical Steps

1️⃣ Use Base URL

❌ Hardcoded (Wrong)

[Link]

✅ Correct (Reusable)

{{base_url}}/users/{{user_id}}

💡 Why?

• Change base_url once

• All APIs update automatically

🔸 D. Set Variable Values Automatically (Token / ID)

🔹 Example: Save Token After Login

🛠 Practical Steps

1⃣ Open POST – Login User

2⃣ Go to Tests tab
3️⃣ Add script:

var jsonData = [Link]();

[Link]("token", [Link]);

4️⃣ Click Send

🎯 Expected Result

• Token stored in environment

📌 Actual Result

• {{token}} updated automatically

🔹 Use Token in Other APIs

1⃣ Open any secured API

2⃣ Go to Authorization
3️⃣ Type → Bearer Token
4️⃣ Token field:

{{token}}

🔸 E. Avoid Hardcoding IDs

🔹 Example: Save User ID After Create User API

🛠 Practical Steps

1⃣ Open POST – Create User

2⃣ Go to Tests tab
3️⃣ Add script:

var jsonData = [Link]();

[Link]("user_id", [Link]);

4️⃣ Click Send

🎯 Expected Result

• New user ID stored

📌 Actual Result

• {{user_id}} updated automatically

🔹 Use User ID in GET API
{{base_url}}/users/{{user_id}}

🔸 F. Switch Between Dev / QA / Prod

🛠 Practical Steps

1⃣ Create multiple environments:

Dev
QA
Prod

2⃣ Change only base_url value:

• Dev → [Link]
• QA → [Link]
• Prod → [Link]

3️⃣ Select environment from dropdown

4️⃣ Run same collection

🎯 Expected Result

• Same APIs work in all environments

📌 Actual Result

• No code change needed

🔹 Step-by-Step: Use {{token}} in Request

🛠 Practical Steps

1⃣ Open secured API (example: Get User)

2⃣ Go to Authorization tab
3️⃣ Select Type → Bearer Token
4️⃣ In Token field, enter:

{{token}}
5️⃣ Click Save
6⃣ Click Send

🎯 Expected Result

• API should authenticate successfully

📌 Actual Result

• Status code 200 OK

• Data returned

❌ If Token is Hardcoded (Wrong Practice)

• Token expires
• API fails

🧠 Real Project Example

In office:

• Morning → QA testing
• Evening → Prod verification

You just switch environment, no rewriting APIs.

🎤 Interview Answer (Strong)

“I use Postman environments to store reusable values like base URL, token, and IDs. This
helps avoid hardcoding and allows the same collection to run across Dev, QA, and Prod by
simply switching environments.”

4️⃣ Authentication – Positive & Negative

Interview Question
“This API is secured. How will you access it?”

What the interviewer is checking

• Auth knowledge
• Security understanding
• Error handling

What to do (Concept)

• APIs require authentication

• Common type → Bearer Token

Practical Steps

Positive Auth

1. Go to Auth tab
2. Select Bearer Token
3. Paste valid token
4. Send request

Negative Auth

• Remove token
• Send request again

Expected Result

Scenario Status
Valid token 200 OK
Missing token 401 Unauthorized

Interview Answer

“I use Bearer token authentication. With a valid token I get 200 OK, and without token API
returns 4️01 Unauthorized.”
5️⃣ API Chaining (POST → DELETE)
Interview Question

“Create a user and delete the same user using its ID.”

What the interviewer is checking

• Advanced fresher skill

• Automation thinking
• Real-time API flow

What to do (Concept)

• Use response data in next request

• Save ID dynamically

Practical Steps

1. Create user using POST

2. Go to Tests tab
3. Add:

var data = [Link]();

[Link]("user_id", [Link]);

4. Create DELETE request:

{{base_url}}/users/{{user_id}}

Expected Result

• Delete success → 200 OK or 204 No Content

Interview Answer

“After creating the user, I capture the ID from response and store it in environment variable,
then use it in DELETE request.”
6️⃣ Validating Response Body & Headers
Interview Question

“API shows success, how will you verify data correctness?”

What the interviewer is checking

• Attention to detail
• Validation mindset
• Not trusting only status code

What to do (Concept)

• Verify response body

• Verify headers

Practical Checks

• Check keys: id, name, email

• Validate correct values
• Header:

Content-Type: application/json

Interview Answer

“I validate response body fields and also verify headers like Content-Type to ensure data is
correctly returned.”

🔹 2. Request Organization & Management – Full Practical Steps

(Postman)
🔸 STEP 1: Create a Postman Collection
🎯 What are we doing?

We are creating one collection for one application.

🛠 Practical Steps

1⃣ Open Postman
2⃣ On the left panel, click Collections
3️⃣ Click New (or +)
4️⃣ Select Collection
5️⃣ In Name, type:

E-Commerce API Testing

6⃣ In Description, type:

This collection contains APIs for Login, User, Orders, and Payments modules of the E-
Commerce application.

7️⃣ Click Create

💡 Why we do this?

• Keeps all APIs in one place

• Easy to share with team
• Easy to run collection in future

✅ Expected

• One collection created

📌 Actual

• Collection visible in Collections panel

🔸 STEP 2: Create Module-Wise Folders

🎯 What are we doing?

We are grouping APIs based on application modules.

🛠 Practical Steps

1⃣ Right-click on E-Commerce API Testing collection

2⃣ Click Add Folder
3️⃣ Folder name:

Login

4️⃣ Click Create

👉 Repeat the same steps to create:

User
Orders
Payments

💡 Why we do this?

• Matches application structure

• Easy to test module-wise
• Helps during sprint testing

✅ Expected

• 4 folders inside collection

📌 Actual

• Login, User, Orders, Payments folders created

🔸 STEP 3: Add Requests Inside Each Folder

🔹 Login Module – Practical Steps

🛠 Add Login API

1⃣ Right-click Login folder

2⃣ Click Add Request
3️⃣ Request name:

POST – Login User

4️⃣ Click Save to Collection

5️⃣ Select Method → POST

6⃣ Enter URL:

{{base_url}}/login

7️⃣ Go to Body → raw → JSON

{
"username": "testuser",
"password": "test123"
}

8⃣ Click Save

💡 Why this naming?

• Method + action is clear

• Easy for team to understand

🔹 User Module – Practical Steps

🛠 Create User API

1⃣ Right-click User folder

2⃣ Add Request → Name:

POST – Create User

3️⃣ Method → POST

4️⃣ URL:

{{base_url}}/users

5️⃣ Body → raw → JSON

{
"name": "Rahul",
"email": "rahul@[Link]"
}

6⃣ Save request

🛠 Get User API

1⃣ Add Request → Name:

GET – Get User By ID

2⃣ Method → GET
3️⃣ URL:

{{base_url}}/users/{{user_id}}

4️⃣ Save request

🔹 Orders Module – Practical Steps

🛠 Create Order API

1⃣ Add Request in Orders folder

2⃣ Name:

POST – Create Order

3️⃣ Method → POST

4️⃣ URL:

{{base_url}}/orders

5️⃣ Body:

{
"userId": 101,
"product": "Mobile",
"quantity": 1
}

6⃣ Save
🔹 Payments Module – Practical Steps
🛠 Make Payment API

1⃣ Add Request in Payments folder

2⃣ Name:

POST – Make Payment

3️⃣ Method → POST

4️⃣ URL:

{{base_url}}/payments

5️⃣ Body:

{
"orderId": 501,
"amount": 15000,
"method": "UPI"
}

6⃣ Save

🔸 STEP 4: Final Collection Structure (What You Should

See)
📁 E-Commerce API Testing
├── 📁 Login
│ └── POST – Login User
├── 📁 User
│ ├── POST – Create User
│ └── GET – Get User By ID
├── 📁 Orders
│ └── POST – Create Order
└── 📁 Payments
└── POST – Make Payment

🔸 STEP 5: Collection Runner Execution (The Final Test)

🎯 What are we doing?

Multiple APIs ekasobat (bulk madhe) run karun pass/fail result check karne.

🛠 Practical Steps
1⃣ Open Runner: Right-click kara 'E-Commerce API Testing' collection var ani select kara
'Run Collection'.

2⃣ Select Order: Runner window madhe check kara ki sagle APIs (Login $\rightarrow$ User
$\rightarrow$ Orders $\rightarrow$ Payments) correct sequence madhe aahet ka.

3️⃣ Configuration:

• Iterations: 1 (Basic test sathi).

• Delay: 0ms (Jar server fast asel tar).

4️⃣ Execute: Blue button var click kara — 'Run E-Commerce API Testing'.

5️⃣ Analyze Results: Screen var Green (Pass) kiva Red (Fail) indicators check kara.

⚠️ Imp Note: Scripts naseel tar Runner fail hoil!

Interviewer tula thambvun vicharel: "Runner tar run jhala, pan pass ki fail he kase kalnar?"

Tyasathi tula pratyek request chya 'Tests' tab madhe khali dila script takava lagel (he STEP 3
madhech karave lagte):

Snippet to add in Tests Tab:

JavaScript
[Link]("Status code is 200", function () {
[Link](200);
});

🎤 Collection Runner badal Interviewer la kay sangayche?

“After creating the collection structure, I add validation scripts in each request. Then I use the
Collection Runner to test the complete functional flow together. This helps me identify which
module is failing, and I debug the issue using the Postman Console.”

Summary Checklist (Fresher Interview):

1. Collection (E-Commerce) ✅
2. Folders (Module-wise) ✅
3. Requests (Method + Name) ✅
4. Tests (Status Code Check) ⬅️ Add this!
5. Runner (Bulk Execution) ⬅️ Add this!
👉 How to Debug Failed Requests in Collection Runner
Step 1: Identify the Failed Request

• Open Collection Runner report

• Check which request is marked as Failed
• Note the request name and order

Step 2: Check Status Code & Response

• Click on the failed request

• Verify:

• Status Code (e.g., 400, 401, 500)

• Error message in Response Body

Step 3: Check Validation Script (Tests Tab)

• Open the failed request

• Go to the Tests tab
• Check which assertion failed
• Correct wrong expectations if needed

Step 4: Verify Request Data

• Check:

• URL
• Headers (Authorization, Content-Type)
• Request Body / Parameters
• Ensure correct environment variables are used

Step 5: Check Postman Console

• Open Postman Console (View → Show Postman Console)

• Check logs and error details
• Look for undefined variables or script errors
 Step 6: Re-run the Request Individually

• Run the failed request alone

• Confirm whether the issue is with:

• Data
• Script
• Sequence dependency

Step 7: Re-run Collection

• Fix the issue

• Run the Collection Runner again
• Verify all requests pass

👉 Short Interview Answer

“If a request fails in Collection Runner, I first identify the failed request, check its status code
and response, verify the test scripts and request data, debug using the Postman Console, and
then re-run the request and the collection.”

हे answer बोललास तर interviewer ला real project experience vibe येतो 💯

4️⃣
Extra "Fresher" Bonus: Exporting the Collection

If they ask, "How will you give your tests to the Developer?", tell them:

• "I will click on the three dots (...) next to the collection and select Export. This generates a
JSON file which the developer can import into their own Postman."

🔥 Interviewer’s Favourite Trick: 500 Error

Question

“If API gives 5️00 Internal Server Error, what will you do?”

Perfect Answer
“First I check request body, headers and input values. If everything is correct, I check
Postman console for details and then report it to developer because 500 is a server-side
issue.”

NOW Scenario Based API Testing (Most IMP)

To answer your question: Yes, this is enough to clear 80-90% of manual/API testing
interviews. It covers the "Bread and Butter" of daily API testing.

However, to make you "bulletproof" against that last 10% of tricky questions, here are three
small additions you should keep in your back pocket:

Real-World Bug Reporting

If they ask, "How do you report an API bug?"

• Sample Answer: "I provide the Request URL, Method, Headers, Request Body
(Payload), the Status Code I received vs. Expected, and the Response Body. I also
include the Postman Console logs."

Query Parameter vs Path Parameter

👉 Interview Question

“What is the difference between /users/1 and /users?id=1?”

👉 What the interviewer is checking

• API design understanding

• Real-time usage clarity

👉 What to do (Concept)

• Path Parameter → Specific resource identify करतो

• Query Parameter → Filter / search / sort साठी वापरतो

👉 Practical Steps (Postman)

Path Param
GET {{base_url}}/users/1

Query Param

GET {{base_url}}/users?id=1

👉 Expected Result / Status Code

• Valid data → 200 OK

👉 How to explain in interview

“Path parameters are used to uniquely identify a resource, while query parameters are used
for filtering or searching data.”

Payload vs Response Validation

👉 Interview Question

“What do you check in an API response apart from data?”

👉 What the interviewer is checking

• Validation mindset
• Data-type awareness

👉 What to do (Concept)

• Payload → Request body sent to API

• Response → API output
• Validate data types & formats

👉 Practical Steps (Postman)

• Check response JSON:

• id → number
• price → decimal
• date → ISO format

👉 Expected Result

• Correct data types & formats

👉 Interview Answer
“I validate response data types like integer IDs, decimal values, and date formats along with
the actual data.”

415 Unsupported Media Type

👉 Interview Question

“You get 4️15️ error. Why?”

👉 What the interviewer is checking

• Header knowledge

👉 What to do (Concept)

• API expects specific Content-Type

👉 Practical Steps

1. Body → raw
2. Select wrong type (Text)
3. Send request

👉 Expected Result

• 415 Unsupported Media Type

👉 Interview Answer

“4️15️ occurs when Content-Type header is incorrect, like sending text instead of JSON.”

SQL Injection Testing (API)

👉 Interview Question

“How do you test API for SQL Injection?”

👉 What the interviewer is checking

• Security awareness

👉 What to do (Concept)
• Try malicious inputs

👉 Practical Steps

Body field value:

' OR 1=1 --

👉 Expected Result

• 400 / 401
• No unauthorized data

👉 Interview Answer

“I pass SQL injection strings in input fields and validate that API blocks them with proper
error response.”

Idempotency Scenario
👉 Interview Question

“What happens if POST is hit multiple times quickly?”

👉 What the interviewer is checking

• Real-world thinking

👉 What to do (Concept)

• Prevent duplicate records

👉 Practical Steps

• Click Send 4–5 times rapidly

👉 Expected Result

• Only one record created

• Or duplicate request rejected

👉 Interview Answer

“This checks idempotency. API should avoid creating duplicate records.”

Accept Header (JSON vs XML)
👉 Interview Question

“How do you test multiple response formats?”

👉 What the interviewer is checking

• Header handling

👉 What to do (Concept)

• Use Accept header

👉 Practical Steps

Headers:

Accept: application/json
Accept: application/xml

👉 Expected Result

• Response format changes

👉 Interview Answer

“I change the Accept header to validate if API supports JSON and XML formats.”

File Upload API Testing

👉 Interview Question

“How do you test file upload API?”

👉 What the interviewer is checking

• Postman hands-on skill

👉 What to do (Concept)

• Use form-data
👉 Practical Steps

1. Body → form-data
2. Key → File
3. Upload file

👉 Expected Result

• 200 / 201 OK

👉 Interview Answer

“I test file upload APIs using form-data and file type keys in Postman.”

Regex Email Validation (Tests Tab)

👉 Interview Question

“How do you validate email format?”

👉 What the interviewer is checking

• Basic scripting

👉 What to do (Concept)

• Regex validation

👉 Practical Steps

Tests tab:

[Link]("Valid Email", function () {

[Link]([Link]()).[Link](/@/);
});

👉 Expected Result

• Test passes for valid email

👉 Interview Answer

“I use regex in the Tests tab to validate email format in response.”

Final Check: Do you know these "Common" Status Codes?

Your guide mentions 200, 201, 400, 401, and 500. Just memorize these three more to be safe:

• 403 Forbidden: You are logged in, but you don't have permission to see this specific
data (different from 401).
• 404 Not Found: The URL or the specific ID doesn't exist.
• 204 No Content: Often seen after a successful DELETE. It means "It worked, but
there's nothing left to show you."

💡 My Advice for your Interview:

When you explain these, always use the word "Validate." * Don't just say: "I check the
code."

• Say: "I validate the response status code and verify the JSON schema." It makes you
sound like a professional.

Here are the 20 most important scenario-based questions for a Fresher Manual Tester.

Category 1: Method & Logic Scenarios

1. Scenario: You have a GET request to fetch user details. The response shows 200 OK,
but the data is empty []. Is this a bug?
o Answer: Not necessarily. If there are no users in the database, 200 OK with an
empty array is correct. It’s a bug only if you know data exists.
2. Scenario: What is the difference between PUT and PATCH in a practical task?
o Answer: PUT replaces the entire resource. If you miss a field, it might become
null. PATCH only updates the specific field you send.
3. Scenario: You need to test an API that creates a profile. What happens if you click
the 'Send' button 5 times rapidly?
o Answer: This tests Idempotency. Ideally, it should create 1 user and give
errors for others, or handle it without creating 5 duplicate accounts.
4. Scenario: If you need to search for a specific product by its name "Laptop", how will
you send this in Postman?
o Answer: Using Query Parameters. Example:
{{url}}/products?name=laptop.
5. Scenario: How do you test if an API supports multiple formats like XML and JSON?
o Answer: By changing the Accept header in the request to application/xml
or application/json.
Category 2: Status Code Scenarios

6. Scenario: You send a request and get a 401 Unauthorized. What is the first thing
you check?
o Answer: I will check the Auth tab to see if the Bearer Token or API Key is
missing or expired.
7. Scenario: You are getting a 403 Forbidden error. Is this the same as 401?
o Answer: No. 401 means "Who are you?" (Login issue). 403 means "I know
who you are, but you don't have permission to see this."
8. Scenario: When testing a DELETE request, it returns 204 No Content. Is this a
success?
o Answer: Yes. 204 means the action was successful, and there is nothing more
to show.
9. Scenario: You see a 415 Unsupported Media Type. Why did this happen?
o Answer: The Content-Type header is wrong. For example, the API expects
JSON, but you sent Plain Text.
10. Scenario: What will you do if an API returns 500 Internal Server Error?
o Answer: I will check my input first. If input is correct, I’ll check the Postman
Console for server logs and report it to the developer as a server-side crash.

Category 3: Negative & Boundary Scenarios

11. Scenario: An API field "Username" accepts 5 to 15 characters. List the test cases.
o Answer: 4 characters (Fail), 5 (Pass), 10 (Pass), 15 (Pass), 16 (Fail).
12. Scenario: How do you test an API for SQL Injection?
o Answer: In the input field (Body), I will enter values like ' OR 1=1 -- to see
if the API returns unauthorized data.
13. Scenario: What happens if you send a POST request body with a missing "Required"
field?
o Answer: It should return 400 Bad Request with a clear error message (e.g.,
"Email is required").
14. Scenario: If an API expects a Date in DD-MM-YYYY, what will you test?
o Answer: Invalid formats like MM-DD-YYYY, YYYY/MM/DD, or putting a string
like "Today".
15. Scenario: Testing "Amount" field: What happens if you enter a negative value?
o Answer: It should return a validation error (400 Bad Request), not process a
negative payment.

Category 4: Postman Specific Scenarios

16. Scenario: You have 50 APIs to test for a project. How do you manage them?
o Answer: I will create a Collection and organize them into folders (e.g., Auth,
Users, Payments).
17. Scenario: Your API URL changes from [Link] to [Link]. Do you
update every request?
 o Answer: No, I will use an Environment Variable {{base_url}} and just
update the variable value once.
18. Scenario: How do you verify that the "email" in the response is actually a valid email
format?
o Answer: I will check the Response Body manually or write a small script in
the Tests tab using Regex.
19. Scenario: How do you test a "File Upload" API in Postman?
o Answer: Go to Body -> form-data, change the key type from Text to File,
and upload the file.
20. Scenario: You need to pass a Token from a Login API to a Profile API. How do you
do it?
o Answer: API Chaining. I will save the token from the Login response into a
Global/Environment variable and use it in the Headers of the next API.