You have one test. It checks if a user profile loads correctly. You test with userId = 1. Passes. But does it work for userId 2? 3? 100? What about a user that does not exist? You could copy-paste the request 100 times. Or you could feed 100 rows of data to ONE request and let Postman loop through them.
That is data-driven testing. One request. One set of tests. Many inputs. A CSV file provides the data. The Collection Runner iterates through each row.
Open any text editor. Create a file. First row is headers — these become your variable names. Each subsequent row is one test iteration.
userId,expectedName,expectedEmail,expectedStatus
1,Leanne Graham,Sincere@april.biz,200
2,Ervin Howell,Shanna@melissa.tv,200
3,Clementine Bauch,Nathan@yesenia.net,200
10,Clementina DuBuque,Rey.Padberg@karina.biz,200
999,,,404CSV files must use UTF-8 encoding. If you create them in Excel, use "Save As > CSV UTF-8." Excel loves adding BOM characters and weird encodings that break Postman. When in doubt, use a plain text editor like VS Code or Notepad++.
Column headers in your CSV automatically become data variables. Reference them with {{columnName}} — exactly like environment variables.
GET {{baseUrl}}/users/{{userId}}
// For row 1: GET https://www.testerrank.com/api/users/1
// For row 2: GET https://www.testerrank.com/api/users/2
// For row 5: GET https://www.testerrank.com/api/users/999// Post-response script (Tests tab)
const expectedStatus = parseInt(pm.iterationData.get("expectedStatus"));
const expectedName = pm.iterationData.get("expectedName");
const expectedEmail = pm.iterationData.get("expectedEmail");
const userId = pm.iterationData.get("userId");
// Test 1: Status code matches expected
pm.test(`User ${userId}: Status code is ${expectedStatus}`, function () {
pm.response.to.have.status(expectedStatus);
});
// Test 2: Name matches (only for valid users)
if (expectedStatus === 200) {
const responseData = pm.response.json();
pm.test(`User ${userId}: Name is "${expectedName}"`, function () {
pm.expect(responseData.name).to.eql(expectedName);
});
pm.test(`User ${userId}: Email is "${expectedEmail}"`, function () {
pm.expect(responseData.email).to.eql(expectedEmail);
});
}Click "Runner" button (or right-click collection > Run Collection)
Select the collection and the specific request to run
Click "Select File" and choose your CSV file
Postman shows a preview — verify column names match your {{variables}}
Set Iterations to match your CSV row count (5 rows = 5 iterations)
Select the correct Environment from the dropdown
Click "Run" — watch each iteration execute with different data
After the run, you see results for each iteration. Green checkmarks for passes. Red X for failures. Click any iteration to see the actual request sent and response received. This is how you test 100 scenarios in 30 seconds instead of 30 minutes.
Add a negative test case in your CSV — a userId that does not exist (like 999). Test that the API returns 404. Good QA engineers test unhappy paths too, not just happy ones.
Q: Explain data-driven testing in Postman. How do you implement it?
A: Data-driven testing means running the same request and tests with multiple sets of input data. In Postman, you create a CSV or JSON file where each row/object represents one test case. Column headers become data variables accessible via {{columnName}} in the request or pm.iterationData.get("columnName") in scripts. You use the Collection Runner to load the data file — it runs one iteration per row. This approach lets you test many scenarios (valid inputs, edge cases, error cases) without duplicating requests. It is especially useful for boundary testing, user validation, and regression testing across large datasets.
Key Point: CSV data-driven testing: column headers become variables, each row is one iteration. One request tests 100 scenarios.