Jain University Students and Postman: A Hands-On API Collection Worksheet

You build a useful Postman collection by choosing one public API, defining an environment for its base URL and variables, writing requests for positive, negative and boundary cases, and adding assertions to each one. The worksheet below turns that work into a coverage score out of 100, so you can see what is missing rather than guess. The whole exercise fits into a 14-day plan.

What a Postman collection should prove

A collection is a saved, ordered set of API requests. It becomes a test asset only when each request carries assertions: checks that fail loudly when the API behaves differently from what you expect. A collection with no assertions is just a list of bookmarks.

Good API tests answer five questions:

• Does the endpoint return the right status code?
• Is the response body shaped correctly, with the expected fields and data types?
• Are the values correct, not merely present?
• What happens with bad input, missing data or a nonexistent resource?
• Does the response arrive in a reasonable time?

Choosing a public practice API for your collection

Pick an API built for practice, so you are not hammering a real service. Free options widely used for learning include JSONPlaceholder (posts, comments, users, todos), Reqres and PokeAPI. Read the chosen API’s own documentation for rate limits and terms before you start. Note that some practice APIs fake writes: a POST returns a success response but does not persist the data. Your assertions must reflect that behaviour, so run a request manually first and read the real response before you write checks.

This guide uses JSONPlaceholder-style resources (/posts, /users) as the illustrative example. Confirm the current endpoints and response shapes in the API’s documentation before copying anything.

Setting up environments and variables in Postman

Environments let one collection run against different targets without editing every request. Even with a single public API, create at least two environments so the habit is built in.

1. Create an environment named Practice-Primary with variables such as baseUrl, validUserId and invalidUserId.
2. Create a second environment, Practice-Alt, with different values. For example, a different valid ID, or a deliberately wrong base URL to prove your tests can fail.
3. Write every request URL as {{baseUrl}}/users/{{validUserId}}. Never hard-code hosts.
4. Store anything secret (API keys, tokens) as a secret-type variable, and never export an environment containing real keys to a public repository.
5. Use collection variables for values shared across environments, and keep environment variables for values that change per target.

Writing assertions: the core test patterns

Postman runs scripts in the Tests tab after a response arrives, using the pm object. The following snippets are illustrative patterns; adapt field names to the API you chose and run them yourself before relying on them.

pm.test("Status is 200", function () {
  pm.response.to.have.status(200);
});

pm.test("Response time under 1000 ms", function () {
  pm.expect(pm.response.responseTime).to.be.below(1000);
});

pm.test("User has expected fields", function () {
  const body = pm.response.json();
  pm.expect(body).to.have.property("id");
  pm.expect(body.email).to.be.a("string");
});

pm.test("Content-Type is JSON", function () {
  pm.response.to.have.header("Content-Type");
  pm.expect(pm.response.headers.get("Content-Type")).to.include("application/json");
});

For chaining requests, save a value from one response and use it in the next:

const created = pm.response.json();
pm.environment.set("createdPostId", created.id);

Then reference {{createdPostId}} in the follow-up GET or DELETE request.

The scoring worksheet for API collection coverage

Fill this in after building your collection. Award points only when the item is fully done and visible in the collection, not when it is planned. Total possible: 100.

Reading your total on the coverage worksheet

• 0 to 39: a request list with few checks. Add status and body assertions first.
• 40 to 69: a reasonable happy-path suite. The gap is almost always negative and boundary cases.
• 70 to 89: solid. Focus on chaining, environments and evidence.
• 90 to 100: portfolio-ready, provided you can explain every assertion in an interview.

Worked illustration: scoring a small /users and /posts collection

This example is illustrative. The numbers are invented to show how scoring works; no tests were run to produce them.

Suppose a student targets four endpoints: GET /users, GET /users/{id}, GET /posts and POST /posts. The collection has six requests and one environment. Every request asserts status 200 or 201. Two requests check body fields. There is one negative case (GET /users/9999 expecting 404). No chaining, no boundary tests, and no Runner evidence.

The total is 52.5, so this collection sits in the middle band. The fastest gains: add PUT and DELETE (+8), a second environment (+5), three more negative cases (+7.5) and a Runner execution (+4). That alone would lift the score past 77.

A 14-day plan to complete the collection

The free two-week online internship from CareerSwami runs for 14 days, and this worksheet maps neatly onto that window. It offers a free offer letter and a free completion certificate after successful completion. Here is one way to pace the work, whichever track you follow:

1. Days 1-2: choose the API, read its documentation, send every request manually and note actual responses.
2. Days 3-4: create environments and variables; build folders and GET requests.
3. Days 5-6: write status, header and response-time assertions.
4. Days 7-8: add body and schema checks; cover POST, PUT/PATCH and DELETE.
5. Days 9-10: write negative and boundary cases.
6. Days 11-12: add chaining and run the Collection Runner; fix flaky or wrong assertions.
7. Day 13: score yourself with the worksheet and list the gaps.
8. Day 14: export the collection and environments (without secrets), write a one-page README and finalise your summary.

Jain University students: fitting API testing into the FET internship structure

The Faculty of Engineering & Technology describes its programmes as including career and industry-oriented training plus a 120-day internship that begins in the fourth semester. For a software testing learner, that gives a clear timeline: by semester 4 you want evidence you can show a prospective host, and a polished Postman collection with a scored worksheet is exactly that kind of evidence. The same page presents the faculty as part of JAIN (Deemed-to-be University).

FET also publishes a placements contact page that directs students to the “Student Career Advisory and Placement Support” team for recruitment, internships and part-time jobs. That is the natural place to ask how a testing portfolio is viewed when applying for an internship.

If you are in the B.Tech Computer Science and Engineering (technology) programme, the programme page describes an optional Minor with IIIT Hyderabad certificates, with an additional cost noted. Separate CSE pages, including one for CSE and Business Systems, list semester-wise curricula, so the syllabus you follow depends on your specific programme.

What is not confirmed here: whether a short online internship or self-built project can count toward the 120-day internship, how the internship is evaluated, and what documents are required. Treat the CareerSwami internship and this worksheet as supplementary skill-building unless your department confirms otherwise in writing.

Verification steps for Jain University students before using this work for the internship

1. Ask your department coordinator for the current internship regulation or handbook for your programme and batch, and check the stated duration, evaluation method and required documents.
2. Email the coordinator asking in writing: “Can an online internship or project completed outside the university be recognised as part of the semester 4 internship, or only as additional work?”
3. Contact the placement team through the phone numbers on the FET placements page and ask whether they review testing portfolios or GitHub links before recommending internship openings.
4. Confirm with your department whether your programme’s syllabus includes software testing or API testing courses, and align your collection with the course outcomes.
5. If you are considering the IIIT Hyderabad Minor, ask for the current fee and selection criteria in writing before committing.
6. Check your academic calendar for semester breaks so your 14 days do not collide with exams.

Turning the finished collection into a portfolio piece

A recruiter or faculty reviewer cannot judge a collection you only describe. Package it so someone can run it in minutes:

• Export the collection and sanitised environments as JSON files and push them to a public repository.
• Write a README covering the API chosen, how to import the files, which environment to select, and your worksheet score with the gaps you knowingly left.
• Add a screenshot of a clean Collection Runner pass and one of a deliberately failing test, showing that your assertions can detect real defects.
• Prepare a 60-second explanation of one negative case and why you chose it.

Optionally, run the exported collection from the command line with Newman, Postman’s command-line runner, to show you understand how tests plug into automation pipelines. Check Postman’s current documentation for installation and usage, since tools change.

Assertion mistakes that make Postman tests unreliable

• Asserting only that a response exists. A 200 with the wrong body still passes. Add field and value checks.
• Trusting fake writes. On practice APIs, a created resource may not be retrievable afterwards. Assert what the documentation says, not what a real system would do.
• Hard-coded IDs. They break when you switch environments. Use variables.
• Tests that can never fail. Temporarily break a URL or expected value to confirm the assertion turns red.
• Order-dependent requests without notice. If request 5 needs a value from request 3, say so in the folder description.
• Overly tight timing thresholds. Network variation makes 200 ms limits flaky on public APIs; choose thresholds you can justify.

Frequently Asked Questions

How many requests should a Postman practice collection contain?

Quality matters more than count, but 15 to 25 requests across three or four endpoints is enough to score well on the worksheet. That allows positive, negative and boundary cases for each resource without padding.

Should I write assertions in the Tests tab or use pre-request scripts?

Assertions belong in the Tests tab, which runs after the response arrives. Pre-request scripts are for preparation, such as generating a random value or setting a variable before the request is sent.

Why does my POST request return 201 but the new record is missing afterwards?

Some practice APIs simulate writes without saving them. Read the API documentation, and assert only on the response to the POST itself rather than expecting the record to appear in later GET calls.

How do I test negative scenarios against a public API?

Send a nonexistent ID, a wrong data type, an empty body or an unsupported method, and assert the status code the documentation promises. If the documentation is silent, record the observed behaviour and note it as an assumption.

What is the difference between an environment variable and a collection variable?

Environment variables change with the target you select, such as a different base URL. Collection variables travel with the collection and suit values that stay the same everywhere.

Can I run my collection without opening the Postman app?

Yes. Export the collection and environment files and run them with Newman, Postman’s command-line runner. This is how API checks are commonly wired into automated builds, so mention it in your README if you try it.

Will a Postman collection help me get a software testing internship?

It gives you concrete evidence of skill, which is more persuasive than a skills list. Pair it with a README and a scored worksheet so a reviewer can see your reasoning. It does not guarantee any internship or job.

Does the 14-day CareerSwami internship suit this worksheet?

The plan above is paced for 14 days, so you can use it as your project structure if you choose a relevant track. Check the track list on the CareerSwami site to pick the one closest to software testing.