How I Built a Complete API Testing Portfolio Project

Behind the Scenes: My First API Testing Project Using GoRest

If you’ve spent any time looking at QA job descriptions lately, you’ve probably noticed how many mention “API testing experience” like it’s as basic as knowing how to use a computer. The first time I saw this requirement, I had a minor panic moment: “Wait, I’ve been focusing on UI testing… do I need to learn a whole new skill set now?”

Short answer: Yes. But here’s the good news – API testing isn’t as intimidating as it sounds once you break through the initial jargon barrier. To prove this to myself (and build my portfolio), I decided to create a comprehensive API testing project using the public GoRest API.

Let me walk you through what I learned, how I approached it, and how you can create something similar for your own portfolio.

The Project: Testing User Endpoints Like a Real QA Analyst

Instead of just randomly poking at API endpoints, I wanted to simulate what a QA analyst would actually do when testing a real product’s backend. I chose the GoRest API because:

1. It’s publicly accessible (no special permissions needed)
2. It offers user management features similar to real SaaS products
3. It requires token authentication (a real-world scenario)
4. It has comprehensive documentation

Career Changeup Tip: When selecting public APIs for portfolio projects, look for ones that require authentication. Managing tokens is a key skill employers want to see in API testers.

What I Tested: CRUD Operations (The Building Blocks of API Testing)

If you’re new to API testing, CRUD (Create, Read, Update, Delete) operations are the fundamental actions that most APIs support. I focused my testing on these user-related operations:

• Creating new users with valid and invalid data
• Reading user information
• Updating existing user data
• Deleting users
• Testing authentication requirements

These operations mirror the kinds of functionality you’d test in real-world applications like CRMs, healthcare systems, or financial platforms.

My Testing Scope: The Method to My Madness

Here’s a breakdown of the test cases I designed:

ID	Title	What It Tests
API-001	Create User with Valid Data	Happy path – can we create a user successfully?
API-002	Create User with Missing Email	Validation – does the API require email fields?
API-003	Create User with Invalid Email Format	Format validation – does the API check email format?
API-004	Create User with Duplicate Email	Uniqueness validation – does the API prevent duplicates?
API-005	Create User with Invalid Gender	Enum validation – does the API validate limited options?
API-006	Update User Name and Status	Can we modify existing records?
API-007	Delete User	Can we remove users from the system?
API-008	Retrieve Deleted User (Negative)	Error handling – how does the API respond to missing resources?

My Learning Moment: Designing these test cases forced me to think about data validation in a completely different way than UI testing. With UIs, you can often see validation happening. With APIs, you need to deliberately try to break things and carefully examine response codes and messages.

Tech Toolkit of the Week: Postman

For this project, I used Postman as my primary testing tool. If you’re not familiar with Postman, it’s like a web browser specifically for APIs – it lets you send requests and examine responses without writing code.

Here’s what I loved about it:

• Visual Request Builder: No need to memorize complex command-line syntax
• Environment Variables: I could store my authentication token and base URL to reuse across requests
• Response Visualization: Formatted JSON responses made them easier to read
• Collections: I organized related requests together for better structure
• Export Feature: Generated documentation I could include in my portfolio

Side Hustle Strategy: Spend time learning Postman’s environment variable feature. Being able to explain how you managed test environments and authentication tokens is a standout skill in interviews.

Creating Professional Documentation (Because That’s Half the Job)

Just like with my UI testing project, I created comprehensive documentation to showcase my attention to detail:

1. Test Plan

My test plan outlined:

• Project scope and objectives
• Environment setup details
• Authentication approach
• Test data management
• Success criteria

Here’s a snippet from my test plan:

## Authentication Strategy
All tests requiring authentication will use a bearer token stored as a Postman environment variable.
Token rotation will occur weekly, with the current token documented in the environment export.

2. Detailed Test Cases

Each test case included:

• Endpoint: The specific API route being tested
• Method: GET, POST, PUT, DELETE, etc.
• Request Headers: Including authentication tokens
• Request Body: The data being sent (for POST/PUT requests)
• Expected Response Code: 200, 201, 400, 401, etc.
• Expected Response Body: What data should be returned
• Assertions: Specific checks to perform

My Learning Moment: Writing assertions for API tests was new to me. Unlike UI tests where you might check if a button is visible, API assertions focus on status codes, response times, and data validation. I learned to consider both the happy path (everything works) and edge cases (what happens when things go wrong).

3. Defect Documentation

Since I was working with a public API that generally works correctly, I created simulated defects to demonstrate how I would document API issues:

Simulated Defect: “Create User Without Email Returns 201”

• Type: Validation Logic
• Severity: Major
• Expected: 422 Unprocessable Entity
• Actual: 201 Created
• Impact: System allows creation of invalid user records that may cause downstream data integrity issues

My Learning Moment: Determining severity for API bugs requires thinking about the entire system. A bug that seems minor on the surface (like accepting invalid data) can have major implications for data quality and system integrity.

What This Project Taught Me About API Testing

Creating this comprehensive API test project taught me several valuable lessons:

1. The power of negative testing – Some of the most important tests are the ones that verify the API properly rejects invalid operations.
2. The importance of authentication testing – Security is a critical aspect of API testing that UI testers might not focus on as much.
3. Documentation differences – API test documentation requires more technical detail about request/response specifics than UI test documentation.
4. The efficiency advantage – API tests can validate core business logic much faster than UI tests, which is why companies value this skill.

How You Can Create Your Own API Testing Portfolio Project

If you’re looking to build your own API testing portfolio, here’s my advice:

1. Start with a public API – Options include GoRest, JSONPlaceholder, or the GitHub API
2. Focus on CRUD operations first – Master the basics before moving to complex scenarios
3. Document everything professionally – Include test plans, cases, and simulated defects
4. Use Postman collections – Create and export organized collections to show your work
5. Consider authentication – Choose APIs that require tokens for more realistic scenarios

Ask a Tester: Community Q&A

Q: Is it better to learn API testing or focus more on UI testing for entry-level QA roles?

A: Based on my job search experience, having both skills is increasingly expected even for entry-level positions. I’ve found that adding API testing to my portfolio has opened more doors. Many companies see API testing as more efficient and stable than UI testing alone, so demonstrating both skills shows you understand the complete testing pyramid.

What’s Next: Automating My API Tests

This manual API testing project is just the beginning. I’ve already started planning the automation phase using Python and the Requests library. The repository includes a scaffolded structure for those automated tests, which will be my next portfolio addition.

All project artifacts are available in my GitHub repository:

• Test_Plan.md – Overall strategy and approach
• create-user-tests.md – Detailed test cases for user creation
• update-user-tests.md – Test cases for user modifications
• execution-log-qase.xlsx – Results of my test runs
• gorest-env.json – Postman environment export
• gorest-user-tests.postman_collection.json – Complete Postman collection
• defect-log.md – Documented issues and expected behavior
• README.md – Project overview and guide
• automation-ideas.md – Plans for future enhancements

View the full GoRest API QA project on GitHub →

Let’s Connect on API Testing!

Are you also learning API testing? Have questions about setting up your own portfolio project with Postman? Drop your questions in the comments!

---

#TestLikeAGirl #APITesting #QAPortfolio #Postman #CareerTransition

Join our community! Sign up for the weekly TestLikeAGirl newsletter for exclusive transition tips, job opportunities, and virtual coffee chats with women who’ve successfully made the leap into tech.