Skip to content

Day 5 — Manual, API and Database Testing Baseline

Choose a tag to compare

View all tags
@daryal89 daryal89 released this 31 Jul 08:02
· 9 commits to main since this release
v1.0.0
8294e4d

Overview

This release establishes the completed Day 5 baseline for the API and
database testing portfolio.

It captures the project after completion of requirements analysis, test
planning, manual/API test design, PostgreSQL validation, Postman
execution, defect confirmation, requirements traceability and public
evidence sanitization.

Portfolio Highlights

  • Designed and executed 25 manual/API test cases
  • Built and executed a 26-request Postman collection
  • Executed 61 automated Postman assertions
  • Completed the collection with zero runtime errors
  • Documented three confirmed API defects
  • Created a PostgreSQL validation suite
  • Updated the Requirements Traceability Matrix
  • Preserved original defect-draft outcomes
  • Added public-safe collection, environment and runner-result files
  • Organized execution and defect screenshot evidence

Day 5 API Execution Results

Metric Result
Requests created 26
Requests executed 26
Assertions executed 61
Assertions passed 51
Assertions failed 10
Runtime errors 0
Average response time 36 ms
Manual/API test cases executed 25
Test cases passed 18
Test cases failed 7
Test cases blocked 0
Confirmed API defects 3

The failed assertions are intentionally retained because they document
observed differences between the portfolio requirement baseline and the
public demonstration API's behavior.

They are not Postman runtime or collection-configuration errors.

Confirmed API Defects

DEF-API-001 — Invalid Booking-Date Sequence Accepted

The API accepted checkout dates earlier than check-in dates during:

  • Booking creation
  • Authenticated full booking update

Related test cases:

  • TC-BOOK-004
  • TC-UPD-005

Severity: High

DEF-API-002 — Nonpositive Total Prices Accepted

The API created bookings using:

  • totalprice = 0
  • totalprice = -1

Related test cases:

  • TC-BOOK-005
  • TC-VAL-002

Severity: High

DEF-API-003 — Missing Required Fields Return HTTP 500

The API returned HTTP 500 when the following required fields were
omitted:

  • firstname
  • bookingdates
  • lastname

No invalid booking was created, but the API returned an internal
server-error response instead of a clear HTTP 400 or HTTP 422
client-validation response.

Related test cases:

  • TC-BOOK-002
  • TC-BOOK-003
  • TC-BOOK-006

Severity: Medium

PostgreSQL Validation Results

Metric Result
SQL validation and analysis queries 19
Automated validation-summary checks executed 13
Automated validation-summary checks passed 13
Automated validation-summary checks failed 0
Database-constraint negative tests executed 6
Database-constraint negative tests passed 6
Database-constraint negative tests failed 0
Production integrity failures identified 0

Included Portfolio Assets

Test Documentation

  • Software test plan
  • Requirements baseline
  • Test-case Excel workbook
  • GitHub-previewable test-case CSV
  • Requirements Traceability Matrix
  • Defect workbook and CSV
  • Three detailed confirmed defect reports

Postman Assets

  • Public-safe Postman collection
  • Sanitized environment template
  • Sanitized Collection Runner result
  • Authentication-token workflow
  • Automated booking-ID workflow
  • Positive, negative, boundary, authorization and response-time
    assertions

Database Assets

  • PostgreSQL schema
  • Synthetic test-data script
  • SQL validation queries
  • Automated validation-summary script
  • Database-constraint negative tests
  • Day 4 database execution report

Evidence and Reports

  • Day 4 database execution evidence
  • Day 5 API execution evidence
  • Confirmed defect evidence
  • Day 4 database execution report
  • Day 5 API execution report
  • Organized screenshot evidence index

Security and Data Handling

The public repository uses synthetic, nonproduction test data.

Public assets were reviewed to remove or protect:

  • Passwords
  • Active authentication tokens
  • Dynamic booking identifiers
  • Private environment values
  • Postman account-linked metadata
  • Real customer information
  • Production database information

Environment Limitation

The Restful Booker API and the local PostgreSQL portfolio database are
separate testing environments.

The public API does not provide authorized access to its underlying
database. Therefore:

  • Direct API-to-database reconciliation was not performed
  • Database verification after an API deletion was not performed
  • API results do not prove local database persistence
  • Local database results do not prove public API persistence

Reproduction Notes

The public-safe collection and environment template can be imported into
Postman Desktop.

Valid demonstration credentials must be entered only in a private local
environment.

Because Restful Booker is a public demonstration service:

  • Dynamic booking IDs may differ
  • Response times may differ
  • Existing booking records may reset
  • The documented results represent the recorded Day 5 execution session

Next Phase

Day 6 will focus on:

  • Newman command-line collection execution
  • GitHub Actions workflow design
  • Stable smoke-test automation
  • Automated report generation
  • Portfolio presentation and job-readiness materials
Assets 2
Loading