v1.1.1 — Portfolio Hardening and Metadata Alignment

Overview

This patch release hardens the public portfolio presentation and aligns release metadata while preserving all previously verified QA, API, database, defect, and CI results.

Changes

• Aligned npm project metadata to version 1.1.1.
• Added the v1.1.1 portfolio-hardening changelog entry.
• Updated the Day 6 execution report to reflect the published v1.1.0 release.
• Replaced obsolete release-pending language with accurate post-release status.

Verified API Baseline

• 25 executed manual/API test cases
• 18 passed / 7 failed test cases
• 26 requests in the complete validation suite
• 61 runtime assertions
• 51 passing assertions
• 10 known assertion failures
• 3 confirmed API defects

Verified CI Baseline

• 19 requests
• 19 test scripts
• 45 runtime assertions
• 45 passing assertions
• 0 failures
• GitHub Actions quality gate: Pass

Verified Database Baseline

• 19 SQL validation and analysis queries
• 13 automated validation-summary checks
• 6 database-constraint negative tests

Scope

This patch does not alter Postman test logic, SQL validation logic, confirmed defect results, requirements-traceability outcomes, or CI quality-gate behavior.

Day 6 — Newman and GitHub Actions Automation

Overview

This release adds command-line and continuous-integration API testing to
the completed manual, REST API and PostgreSQL testing portfolio.

Day 6 Highlights

• Added Newman as a project dependency
• Executed the complete Postman validation suite through Newman
• Added a stable 19-request CI smoke/regression collection
• Executed 45 passing CI assertions
• Added GitHub Actions automation
• Protected demonstration credentials with repository secrets
• Generated JSON and JUnit reports
• Preserved separate smoke and full-validation workflow artifacts
• Retained all Day 5 test expectations and confirmed-defect evidence
• Added CI coverage mapping, execution reporting and troubleshooting
  documentation
• Replaced duplicate warning annotations with one informational notice
• Added final successful main workflow evidence

Verified CI Results

Metric	Result
CI requests executed	19
CI test scripts executed	19
CI pre-request scripts executed	2
CI assertions executed	45
CI assertions passed	45
CI assertions failed	0
CI runtime errors	0
Complete validation requests	26
Complete validation test scripts	26
Complete validation assertions	61
Complete validation assertions passed	51
Known complete-suite failures	10
Complete-suite runtime errors	0
GitHub Actions quality gate	Pass
Automated report formats	JSON and JUnit
Workflow artifact groups	2

Testing Strategy

The stable CI smoke/regression collection is the strict passing quality
gate.

The complete validation collection preserves positive, negative,
boundary, authorization and confirmed-defect coverage. Its 10 known
failed assertions remain visible without overriding a successful CI
quality gate.

The final workflow displays one expected error annotation from Newman's
nonzero complete-suite exit code and one informational notice explaining
the documented requirement mismatches.

Confirmed API Findings

• Invalid booking-date sequences are accepted during creation and update
• Zero and negative total prices are accepted
• Missing required fields return HTTP 500 instead of a clear HTTP 400 or
  HTTP 422 client-validation response

Security

• Public environment credentials remain blank
• Local environments remain excluded from Git
• GitHub Actions credentials use repository secrets
• Active tokens are not committed
• Generated local Newman results remain ignored
• Public screenshots and exports were reviewed for sensitive values

Previous Baseline

The Day 5 manual, API and database testing baseline remains available as
release v1.0.0.

Day 5 — Manual, API and Database Testing Baseline

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