1place Release & QA Testing Processes

Overview of our Testing & Version Release Procedures

• We ship a Quarterly Stable Release that has passed our full automated and manual test suite.
• Between quarterlies, we publish Weekly Pre-Release builds (opt-in “beta”) so select customers can access new features or urgent fixes sooner.
• Pre-releases are supported, but they’re not the final quarterly build; they may change before GA.

Release Channels

1) Monthly Tested 'Production Release' Versions for General Availability (GA)

• Who it’s for: All customers, production environments.
• Quality bar: Must pass all quality gates (see “Testing & Quality Gates”).
• Change control: Release notes, upgrade guide, and rollback guidance provided.
• Support/SLA: Full production support.
• Created on the 1st Thursday of each month. If today was 7/2/2026 (which is the 1st Thursday in July) the version # would look like this: 26.0702.1.
• The Production Release is then updated each Thursday for the rest of the month, with any necessary bug fixes in the version and then re-released with a slight change to the version #, such as 26.0702.2, 26.0702.3, etc...

2) Daily (Untested) 'Beta' Versions for Beta Users

• Who it’s for: Opt-in customers who want earlier access to features or time-sensitive fixes.
• Purpose: Validate fixes/changes in real-world scenarios ahead of the quarterly release.
• Expectations: May receive minor updates week-to-week; we may iterate quickly based on feedback.
• Support/SLA: Best-effort with prioritized bug handling; we recommend using in staging first, then production only if you’re comfortable with beta software.
• Created Mon-Thurs, following this process:
  • New version created and named using this convention:
    • Current Date of release (beta)
    • Example: If today was 7/15/2026 and a new (untested) version was created from the source code (master) version, the version would be called: 26.0715 (beta)
  • New version installed on local Dev/Testing server.
  • Automated testing is performed to double-check the Top 100 Critical Features.
  • If no bugs are found related to database changes, then we will distribute (install) that 'stable' beta version on certain (larger) customer servers for beta users to test. 
  • If 1 or more bugs related to 'database' changes (such as stored procedures, etc) then we will NOT install that un-stable version on any live Customer servers until the problem is fixed/re-released/re-tested/passed x hours or days later. 
  • We will also install the latest stable 'Beta' version on ALL Live servers each Thursday.

3) Hotfix (as needed)

• Who it’s for: All customers impacted by a critical issue.
• Scope: Minimal, targeted fixes; released outside the normal cadence when necessary.

Testing & Quality Gates

We use a mix of automated and manual testing. Every quarterly Final Release must clear all gates; weekly pre-releases clear a subset focused on the changed areas plus safety nets (smoke/regression).

Automated (CI/CD-gated)

• Static analysis & linting: style, code smells, security patterns (SAST).
• Unit tests: function/method-level correctness; fast and isolated.
• Integration tests: components/services talk to each other correctly (DB, cache, APIs).
• API contract tests: request/response schemas, versioning guarantees.
• End-to-end (E2E) UI tests: user flows across the app (e.g., Selenium/Playwright).
• Regression suite: prevents re-introducing previously fixed defects.
• Performance/load tests: baseline throughput and latency; detect regressions.
• Security checks: dependency vulnerability scans; basic DAST on key routes.
• Migration tests: database schema changes apply/rollback cleanly.

Manual / Human-in-the-loop

• Smoke test: “Does it basically run?” quick, broad pass.
• Sanity test: targeted verification of areas touched by a change.
• Exploratory testing: creative probing beyond scripted paths.
• Cross-browser/device checks: where applicable.
• Accessibility checks: key workflows against WCAG principles.
• UAT (User Acceptance Testing): internal stakeholders (and, for pre-releases, select customers) validate workflows and outcomes.

Versioning & Labels

• Monthly Stable: YY.MMDD.x  (Example: 25.0702.1)
  • Hotfix: YY.MMDDx (increment patch).  (Example: 25.0723a, or 25.0723b for a 2nd release on the same day)
• Daily Beta: YY.MMDD  (Example: 25.0723-beta)
• Each build comes with release notes (via Version Changes Log) that list new features, fixes, known issues, and any breaking changes.

Automated Quick-Tests (Executed on Pre-Release Versions)

Sometimes a new feature is needed BEFORE the General When particular users request the use of an un-tested / beta version (ed a preThe following is a list of the '