This practice set takes a Postman collection from manual runs in the Collection Runner to fully automated execution with Newman in CI/CD, then covers mock servers and Swagger/OpenAPI contract testing. Start with the quick reference below — it has every command and pipeline snippet the exercises use.

Quick Reference: Newman Commands & Pipelines

1. Export your collection and environment

In Postman, export the collection (Export → Collection v2.1) and the environment as JSON files, and commit them to your test repository — for example smoke.postman_collection.json and qa.postman_environment.json. Keep secrets out of the exported environment; pass them at run time instead.

2. Install and run Newman

npm install -g newman newman-reporter-htmlextra

# Run a collection against an environment
newman run smoke.postman_collection.json -e qa.postman_environment.json

# Run one folder, with a data file for data-driven iterations
newman run regression.postman_collection.json -e qa.postman_environment.json \
  --folder "Bookings" -d testdata/bookings.csv

# Pass a secret at run time instead of storing it in the environment file
newman run smoke.postman_collection.json -e qa.postman_environment.json \
  --env-var "password=$API_PASSWORD"

# Reports for CI: JUnit XML (for the build) + an HTML report (for people)
newman run smoke.postman_collection.json -e qa.postman_environment.json \
  -r cli,junit,htmlextra \
  --reporter-junit-export results/junit.xml \
  --reporter-htmlextra-export results/report.html

Useful options: -n 3 repeats the run three times, --timeout-request 10000 fails requests slower than 10 seconds, and --bail stops at the first failure.

3. How Newman fails the build

Newman exits with code 0 when every test passes and 1 when any test fails. CI tools treat a non-zero exit code as a failed step, so the build goes red automatically — no extra configuration needed.

4. Jenkins pipeline

pipeline {
    agent any
    triggers { cron('H 2 * * *') }                     // nightly regression
    stages {
        stage('API tests') {
            steps {
                withCredentials([string(credentialsId: 'api-password', variable: 'API_PASSWORD')]) {
                    sh '''
                      newman run regression.postman_collection.json -e qa.postman_environment.json \
                        --env-var "password=$API_PASSWORD" \
                        -r cli,junit,htmlextra \
                        --reporter-junit-export results/junit.xml \
                        --reporter-htmlextra-export results/report.html
                    '''
                }
            }
        }
    }
    post {
        always {
            junit 'results/junit.xml'
            archiveArtifacts artifacts: 'results/**', allowEmptyArchive: true
        }
    }
}

More on pipelines: Jenkins Pipelines & Jenkinsfile.

5. GitHub Actions

name: API tests
on: [push, pull_request]
jobs:
  newman:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 20
      - run: npm install -g newman newman-reporter-htmlextra
      - run: >
          newman run smoke.postman_collection.json -e qa.postman_environment.json
          -r cli,htmlextra --reporter-htmlextra-export results/report.html
      - uses: actions/upload-artifact@v4
        if: always()
        with:
          name: newman-report
          path: results/

Now work through the exercises below, using a demo API such as RESTful Booker.

Advertisement

Collection Runner — Suite Execution

Practice executing complete API test suites using Postman Collection Runner as part of a structured Postman Newman CI/CD workflow.

Exercise 1: Execute Smoke Suite

  • Run the complete smoke test suite.
  • Verify that all critical APIs pass successfully.
  • Confirm that the application’s core API functionality is working correctly.

Exercise 2: Execute Regression Suite

  • Run the complete regression suite.
  • Verify that existing functionality continues to work after API changes.
  • Identify any regressions introduced by new development.

Exercise 3: Execute Sanity Suite

  • Run the sanity test suite.
  • Validate critical functionality after a new build or API change.
  • Confirm that the latest deployment is stable enough for further testing.

Exercise 4: Execute Against QA

  • Run the complete collection using the QA environment.
  • Verify environment-specific variables and endpoints.
  • Confirm that authentication, base URLs, and test data are configured correctly.

Exercise 5: Analyze Failures

  • Investigate execution failures reported by Collection Runner.
  • Identify whether failures are caused by the API, test script, test data, or environment.
  • Review request and response details to determine the root cause.

Exercise 6: Debug Flaky APIs

  • Identify unstable API behavior.
  • Determine whether failures are intermittent or consistent.
  • Investigate possible timing, data, dependency, network, or environment-related issues.
  • Re-run the API to confirm whether the failure is reproducible.

Exercise 7: Re-run Failed Requests

  • Execute failed requests again after debugging.
  • Verify that the identified issue has been resolved.
  • Confirm that the API passes consistently after the fix.

Exercise 8: Capture Execution Logs

  • Collect execution logs from the test run.
  • Review request, response, assertion, and error details.
  • Preserve important logs for defect investigation and reporting.

Exercise 9: Validate Test Coverage

  • Verify that all required APIs are included in the suite.
  • Confirm that Smoke, Sanity, Regression, and Negative scenarios are covered.
  • Identify APIs or business scenarios that are missing from the test suite.

Exercise 10: Share Execution Results

  • Prepare execution results.
  • Share reports and important failures with the team.
  • Highlight passed tests, failed tests, blocked tests, and major defects.

Purpose

The Collection Runner executes organized API test folders such as:

  • Smoke
  • Sanity
  • Regression
  • Negative

These suites can be executed against a selected environment with multiple iterations and test data.

Collection Runner provides the foundation for automated API execution before integrating the collection into a Postman Newman CI/CD pipeline.

Newman & CI/CD Integration

Practice running Postman collections using Newman and integrating API tests into CI/CD pipelines.

Newman is particularly useful when Postman collections need to be executed automatically without opening the Postman application. This makes it an important component of a Postman Newman CI/CD workflow.

Exercise 1: Execute Collection Using Newman

  • Run Postman collections from the command line using Newman.
  • Execute collections in headless mode.
  • Pass environment files and collection files through Newman commands.
  • Verify that the collection executes successfully outside the Postman application.

Exercise 2: Generate HTML Reports

  • Generate HTML execution reports after every run.
  • Review test results, failures, assertions, and execution details.
  • Store reports for future analysis.
  • Make reports available to the QA and development teams.

Exercise 3: Fail Build on Test Failure

  • Configure the CI pipeline to fail when API tests fail.
  • Ensure that test failures are reflected in the build status.
  • Prevent successful deployment when critical API tests fail.

Exercise 4: Integrate Newman with Jenkins

  • Execute Postman collections through Jenkins pipelines.
  • Configure Newman commands inside the Jenkins pipeline.
  • Pass the required collection and environment files.
  • Publish test reports after execution.

Exercise 5: Schedule Nightly Runs

  • Configure scheduled API test execution.
  • Run regression suites automatically every night.
  • Review failures from scheduled executions.
  • Use nightly execution to identify regressions early.

Exercise 6: Handle Environment Variables

  • Manage environment-specific variables inside CI pipelines.
  • Use separate configurations for QA, staging, and production-like environments.
  • Avoid hardcoding environment-specific values in test scripts.
  • Secure sensitive credentials and tokens.

Exercise 7: Store Build Artifacts

  • Publish HTML reports as Jenkins build artifacts.
  • Preserve reports for future analysis.
  • Maintain historical execution results where required.
  • Make reports accessible to the QA and development teams.

Exercise 8: Debug CI Failures

  • Investigate API failures occurring in CI.
  • Compare CI execution with local execution.
  • Check environment variables, authentication, test data, and network issues.
  • Determine whether the problem is related to the API or CI configuration.

Exercise 9: Optimize Execution Time

  • Reduce API execution duration.
  • Remove unnecessary requests.
  • Optimize test data and scripts.
  • Avoid unnecessary dependencies between test cases.
  • Run appropriate suites based on the pipeline stage.

Exercise 10: Maintain Pipeline Stability

  • Keep CI execution stable and reliable.
  • Monitor flaky tests and resolve recurring pipeline failures.
  • Maintain reusable Newman commands and configurations.
  • Ensure environment configuration remains consistent.

Purpose

Run Postman collections automatically in CI using Newman while generating execution reports for every build.

A typical Postman Newman CI/CD workflow can be structured as:

  • Developer commits code.
  • Jenkins pipeline starts.
  • Required environment is selected.
  • Newman executes the Postman collection.
  • API test assertions are executed.
  • Test results are generated.
  • HTML reports are published.
  • Failed tests cause the build to fail.
  • QA and developers investigate failures.
  • Successful builds continue to the next pipeline stage.

Mock Servers

Practice working with Postman Mock Servers.

Mock servers are useful when backend APIs are unavailable, under development, or difficult to access consistently. They allow testers to continue API and UI testing without waiting for the actual backend implementation.

Exercise 1: Create Mock APIs

  • Create mock APIs before backend development is complete.
  • Define expected request and response behavior.
  • Create sample responses based on API requirements.

Exercise 2: Validate UI with Mock APIs

  • Test frontend functionality using mock API responses.
  • Validate UI behavior before live APIs are available.
  • Verify how the frontend handles different API responses.

Exercise 3: Simulate Error Responses

  • Return simulated error responses.
  • Test scenarios such as:
    • 400 Bad Request
    • 401 Unauthorized
    • 403 Forbidden
    • 404 Not Found
    • 500 Internal Server Error
  • Verify that the application handles API errors correctly.

Exercise 4: Simulate Slow Responses

  • Simulate delayed API responses.
  • Validate application behavior when APIs respond slowly.
  • Verify loading indicators, timeout handling, and user-facing messages.

Exercise 5: Validate Fallback Behavior

  • Verify fallback mechanisms when APIs fail.
  • Confirm that the application handles API failures gracefully.
  • Test alternative flows when the primary API is unavailable.

Exercise 6: Update Mock Data

  • Maintain mock responses dynamically.
  • Update response data according to application requirements.
  • Add new response scenarios when business requirements change.

Exercise 7: Maintain Mock Versioning

  • Manage multiple mock versions.
  • Maintain different responses for different application versions.
  • Ensure that changes to mock data do not unexpectedly break existing tests.

Exercise 8: Validate Contracts

  • Validate API contracts using mock servers.
  • Ensure that requests and responses follow the expected structure.
  • Compare mock responses with the documented API specification.

Exercise 9: Replace Mock APIs

  • Replace mock APIs with live APIs when backend development is complete.
  • Verify that the application works correctly with actual APIs.
  • Compare live API behavior against the expected mock behavior.

Exercise 10: Decommission Mock Servers

  • Remove mock servers when they are no longer required.
  • Ensure that production and testing environments use the appropriate live APIs.
  • Remove outdated mock data and unnecessary configurations.

Purpose

Mock servers allow API testing before backend implementation is completed.

They are especially useful for:

  • Early API testing
  • Frontend development
  • Error simulation
  • Slow-response testing
  • Fallback testing
  • Contract validation

Swagger & API Contract Testing

Practice contract validation using Swagger/OpenAPI specifications.

API contract testing verifies whether the actual API implementation follows the documented request and response structure. Further reading: Negative Testing & Error Handling in REST Assured.

Exercise 1: Validate Against Swagger

  • Compare API requests and responses with the documented specification.
  • Verify that the implementation matches the API contract.
  • Validate endpoints, parameters, headers, request bodies, and responses.

Exercise 2: Identify Missing Fields

  • Detect missing response fields.
  • Compare the actual response with the documented response structure.
  • Report fields that are required by the specification but missing from the response.

Exercise 3: Validate Data Types

  • Verify response data types.
  • Validate fields such as:
    • String
    • Integer
    • Boolean
    • Array
    • Object
  • Identify situations where the API returns an unexpected data type.

Exercise 4: Validate Optional vs Mandatory Fields

  • Confirm required fields are returned when applicable.
  • Verify that optional fields behave according to the specification.
  • Identify missing mandatory fields.

Exercise 5: Report Contract Mismatches

  • Document contract validation failures.
  • Share mismatches with developers and API owners.
  • Include request, response, expected behavior, and actual behavior in the defect.

Exercise 6: Validate Backward Compatibility

  • Verify compatibility after API updates.
  • Ensure existing consumers are not unexpectedly affected.
  • Validate existing API behavior after changes.

Exercise 7: Handle API Version Upgrades

  • Validate newer API versions.
  • Compare behavior between old and new versions.
  • Identify breaking changes introduced by the new version.

Exercise 8: Validate Deprecated APIs

  • Verify deprecated endpoints.
  • Confirm that deprecation does not unexpectedly break existing functionality.
  • Identify whether consumers have an alternative API available.

Exercise 9: Review Documentation

  • Identify gaps in API documentation.
  • Report incorrect, missing, or outdated API specifications.
  • Ensure API documentation reflects the current implementation.

Exercise 10: Collaborate with Developers

  • Work with developers to resolve contract issues.
  • Confirm that implementation and documentation remain aligned.
  • Re-test APIs after contract-related fixes.

Purpose

Contract testing ensures that APIs continue matching their documented Swagger/OpenAPI specification. You may also find Complete REST Assured Practice Roadmap useful.

Reporting & Real-Time Project Tasks

Reporting Tasks

Practice:

  • Prepare API Execution Summary
  • Identify Defects
  • Analyze Test Failures
  • Suggest Improvements
  • Share Results with the Team
  • Maintain Regression Checklist
  • Track Test Execution Status
  • Document API Defects
  • Maintain API Test Reports
  • Track Smoke Test Results
  • Track Regression Test Results
  • Track CI/CD Execution Results
  • Maintain Historical Reports

Real-Time Project Tasks

Practice:

  • Design API Test Strategy
  • Design Postman Framework
  • Define Smoke APIs
  • Define Sanity APIs
  • Define Regression APIs
  • Define Negative Test Scenarios
  • Create Reusable Scripts
  • Maintain Common Assertions
  • Maintain Test Data Strategy
  • Handle Dynamic Test Data
  • Handle Authentication Tokens
  • Handle Flaky APIs
  • Analyze API Failures
  • Prepare API Test Summary Report
  • Integrate Newman with CI/CD
  • Configure Jenkins API execution
  • Maintain API test suites
  • Present API Testing During Interviews

Interview-Level Explanations

Be prepared to explain the following topics during interviews.

API Testing Approach

Explain your end-to-end API testing process, including:

  • Requirement analysis
  • API documentation review
  • Test scenario identification
  • Request validation
  • Response validation
  • Positive testing
  • Negative testing
  • Authentication testing
  • Authorization testing
  • Data validation
  • Status code validation
  • Response time validation
  • Regression testing
  • Reporting

A strong interview explanation should describe how you move from understanding requirements to creating API tests, executing them, analyzing failures, reporting defects, and integrating important regression tests into CI/CD.

Token Handling Strategy

Explain:

  • Authentication mechanisms
  • Token generation
  • Token storage
  • Token reuse
  • Token expiration
  • Refresh token handling
  • Environment-specific credentials
  • Secure credential management
  • Authentication dependencies between APIs

Be prepared to explain how you handle dynamic tokens rather than hardcoding authentication values.

Negative Testing Strategy

Explain defensive API testing techniques such as:

  • Invalid input
  • Missing mandatory fields
  • Invalid authentication
  • Invalid authorization
  • Invalid data types
  • Boundary values
  • Invalid IDs
  • Unsupported methods
  • Duplicate requests
  • Malformed requests
  • Invalid query parameters
  • Invalid headers
  • Expired tokens

Debugging Process

Explain how API issues are investigated:

  1. Reproduce the failure.
  2. Check the request.
  3. Verify headers and authentication.
  4. Validate request parameters and body.
  5. Inspect the response.
  6. Check status codes.
  7. Review response time.
  8. Check test scripts and assertions.
  9. Compare with API documentation.
  10. Check environment variables.
  11. Determine whether the issue is reproducible.
  12. Report the defect with evidence.
  13. Re-test after the developer fixes the issue.

CI/CD Integration

Explain:

  • Newman
  • Command-line execution
  • Jenkins integration
  • Automated execution
  • Scheduled regression runs
  • HTML reports
  • Build failure conditions
  • Build artifacts
  • Environment variables
  • Pipeline configuration
  • Test result reporting

You should be able to explain how Postman Newman CI/CD allows API tests created in Postman to become part of an automated delivery pipeline.

Challenges Faced

Be prepared to discuss real-world challenges such as:

  • Dynamic test data
  • Token expiration
  • Dependent APIs
  • Flaky APIs
  • Environment differences
  • Third-party API failures
  • Test data management
  • CI failures
  • API contract changes
  • Unstable test environments
  • API version changes
  • Production Issues

Explain production defects identified through API testing, such as:

  • Incorrect status codes
  • Missing response fields
  • Authentication issues
  • Data inconsistency
  • Incorrect business logic
  • Unexpected error handling
  • Performance degradation
  • Incorrect validation
  • Broken API contracts

Performance Concerns

Discuss:

  • API response time
  • Timeout issues
  • High request volume
  • Concurrent requests
  • Slow endpoints
  • Large response payloads
  • Performance degradation
  • Network latency
  • Database-related delays

Team Collaboration

Explain how you collaborate with:

  • Developers
  • Business analysts
  • DevOps engineers
  • QA engineers
  • Product owners

Explain how you communicate API failures, contract mismatches, test results, and production issues with the appropriate team members.

Improvements Suggested

Be prepared to discuss improvements such as:

  • Increasing automation coverage
  • Introducing reusable assertions
  • Improving test data management
  • Reducing flaky tests
  • Integrating tests into CI/CD
  • Improving reporting
  • Improving API documentation
  • Introducing better environment management
  • Improving authentication handling
  • Optimizing regression execution

Automation Transition

Be prepared to explain the following:

Postman vs REST Assured

Understand the differences between:

  • Postman
  • Newman
  • REST Assured
  • Code-based automation frameworks

Postman is generally convenient for API exploration, manual testing, debugging, and creating collections quickly.

Newman allows those Postman collections to be executed from the command line and integrated into CI/CD.

REST Assured provides a code-based approach that is useful when teams require more complex automation logic, framework customization, reusable Java components, and integration with broader automated testing frameworks.

When to Move from Postman to Automation

Consider moving to code-based automation when:

  • The API suite becomes large.
  • Complex test logic is required.
  • Advanced data handling is needed.
  • Framework-level customization is required.
  • Integration with existing automation frameworks is needed.
  • Large-scale regression automation is required.
  • Extensive reusable programming components are required.
  • Complex reporting and test orchestration are needed.

Using Postman for Smoke Testing

Postman can be useful for:

Smoke collections can contain critical APIs that need to be executed after every deployment or build.

Limitations of Postman

Postman is highly useful for:

  • Manual API Testing
  • Exploratory Testing
  • API Debugging
  • Smoke Testing
  • Regression Testing
  • CI Execution Using Newman

However, for large-scale automation frameworks requiring complex programming logic, extensive customization, advanced reporting, sophisticated data handling, and maintainable code-based frameworks, teams may transition to tools such as REST Assured.

Demo API Mapping

RESTful Booker

Practice Collection Runner and Newman using RESTful Booker.

Execute:

  • Smoke Suite
  • Sanity Suite
  • Regression Suite
  • Negative Tests
  • Collection Runner
  • Newman Execution
  • Newman HTML Reports
  • Jenkins Integration
  • Scheduled Regression Execution
  • CI/CD Execution

Use RESTful Booker to practice the complete API testing lifecycle, from creating Postman collections to executing them through a Postman Newman CI/CD pipeline.

Postman Mock Servers

Practice:

  • Creating mock endpoints
  • Simulating successful responses
  • Simulating error responses
  • Simulating slow responses
  • Testing frontend behavior
  • Validating fallback behavior
  • Updating mock data
  • Validating API contracts
  • Replacing mock APIs with live APIs

Swagger Petstore

Practice contract validation using Swagger Petstore.

Validate:

  • Request Contract
  • Response Contract
  • Required Fields
  • Optional Fields
  • Data Types
  • Response Structure
  • Status Codes
  • API Version Compatibility
  • Deprecated APIs
  • Documentation Accuracy
📖 Related tutorials

📚 Official documentation: Postman Learning Center · MDN: HTTP

FAQs

What Is the Collection Runner Used For?

The Collection Runner executes complete API test suites such as:

  • Smoke
  • Sanity
  • Regression
  • Negative

It also supports:

  • Multiple iterations
  • Environment selection
  • Test data execution
  • Failure analysis
  • Re-runs
  • Execution logs
  • Test reporting

Collection Runner is useful for validating a complete Postman collection before integrating it into Newman and CI/CD.

What Is Newman?

Newman is the Postman command-line runner.

It enables:

  • Headless Execution
  • HTML Reports
  • Jenkins Integration
  • CI/CD Execution
  • Nightly Scheduled Runs
  • Build Artifacts
  • Automated Test Execution
  • Fail Build on Test Failure

Newman allows Postman collections to run outside the Postman application, making it suitable for automated pipelines.

What Is Postman Newman CI/CD?

Postman Newman CI/CD refers to integrating Postman API collections with Newman and a CI/CD platform such as Jenkins.

A typical workflow is:

  1. Create API tests in Postman.
  2. Organize tests into Smoke, Sanity, Regression, and Negative collections or folders.
  3. Validate the collection using Collection Runner.
  4. Execute the collection using Newman.
  5. Integrate Newman with Jenkins or another CI/CD system.
  6. Generate execution reports.
  7. Fail the build when critical API tests fail.
  8. Store reports as build artifacts.
  9. Schedule automated regression execution.

When Should Mock Servers Be Used?

Use mock servers when backend APIs are unavailable or still under development.

Practice:

  • Simulated Responses
  • Error Responses
  • Slow Responses
  • Fallback Scenarios
  • Contract Validation
  • Frontend Integration Testing

Replace mock APIs with live APIs once the actual backend APIs become available.

What Is Contract Testing?

Contract testing validates whether an API implementation matches its documented Swagger/OpenAPI specification.

Verify:

  • Request Structure
  • Response Structure
  • Data Types
  • Required Fields
  • Optional Fields
  • Missing Fields
  • Status Codes
  • Version Compatibility
  • Deprecated APIs
  • API Documentation

What Should Be Explained During Interviews?

Be prepared to explain:

  • API Testing Approach
  • Token Handling
  • Negative Testing
  • Debugging Process
  • CI/CD Integration
  • Newman
  • Jenkins Integration
  • Collection Runner
  • Mock Servers
  • Contract Testing
  • Project Challenges
  • Production Issues
  • Performance Concerns
  • Team Collaboration
  • Improvements Suggested
  • Postman vs REST Assured
  • When to Move to Automation
  • Limitations of Postman
  • Postman Newman CI/CD Workflow

What Are the Limitations of Postman?

Postman is highly useful for:

  • Manual API Testing
  • Exploratory Testing
  • API Debugging
  • Smoke Testing
  • Regression Testing
  • CI Execution Using Newman

For large-scale automation frameworks requiring complex programming logic, extensive customization, advanced reporting, sophisticated test data management, and maintainable code-based frameworks, teams may transition to tools such as REST Assured.

The key point is that Postman and Newman can provide a strong API testing workflow, while code-based frameworks may be more appropriate when automation requirements become more complex.