---
title: QA
description: Jan is a ChatGPT-alternative that runs on your own computer, with a local API server.
slug: /engineering/qa
keywords:
  [
    Jan AI,
    Jan,
    ChatGPT alternative,
    local AI,
    private AI,
    conversational AI,
    no-subscription fee,
    large language model,
  ]
---

<head>
    <title>QA</title>
    <meta name="description" content="Jan is a ChatGPT-alternative that runs on your own computer, with a local API server. Learn about the QA process for engineering and development phases."/>
    <meta name="keywords" content="Jan AI, Jan, ChatGPT alternative, local AI, private AI, conversational AI, no-subscription fee, large language model, QA, quality assurance, engineering, development"/>
    <meta property="og:title" content="QA"/>
    <meta property="og:description" content="Jan is a ChatGPT-alternative that runs on your own computer, with a local API server. Learn about the QA process for engineering and development phases."/>
    <meta property="og:url" content="https://jan.ai/engineering/qa"/>
    <meta name="twitter:card" content="summary"/>
    <meta name="twitter:title" content="QA"/>
    <meta name="twitter:description" content="Jan is a ChatGPT-alternative that runs on your own computer, with a local API server. Learn about the QA process for engineering and development phases."/>
</head>

### Phase 1: Planning

#### Definition of Ready (DoR):

- [ ] **Scope Defined:** The features to be implemented are clearly defined and scoped out.
- [ ] **Requirements Gathered:** Gather and document all the necessary requirements for the feature.
- [ ] **Stakeholder Input:** Ensure relevant stakeholders have provided input on the document scope and content.

#### Definition of Done (DoD):

- [ ] **Document Complete:** All sections of the document are filled out with relevant information.
- [ ] **Reviewed by Stakeholders:** The document has been reviewed and approved by stakeholders.
- [ ] **Ready for Development:** The document is in a state where developers can use it to begin implementation.

### Phase 2: Development

#### Definition of Ready (DoR):

- [ ] **Task Breakdown:** The development team has broken down tasks based on the document.
- [ ] **Communication Plan:** A plan is in place for communication between developers and writers if clarification is needed during implementation.
- [ ] **Developer Understanding:** Developers have a clear understanding of the document content.

#### Definition of Done (DoD):

- [ ] **Code Implementation:** The feature is implemented according to the document specifications.
- [ ] **Developer Testing:**
  - Unit tests and basic integration tests are completed
  - Developer also completed self-testing for the feature (please add this as a comment in the ticket, with the tested OS and as much info as possible to reduce overlaping effort).
  - (AC -> Code Changes -> Impacted scenarios)
- [ ] **Communication with Writers:** Developers have communicated any changes or challenges to the writers, and necessary adjustments are made in the document. (Can be through a note in the PR of the feature for writers to take care, or create a separate PR with the change you made for the docs, for writers to review)

### Phase 3: QA for feature

#### Definition of Ready (DoR):

- [ ] **Test Note Defined:** The test note is prepared outlining the testing items.
- [ ] **Environment Ready:** PR merged to nightly build, Nightly build notes updated (automatically from pipeline after merged).
- [ ] **Status:** Ticket moved to the column Testing and assigning to QA/writers to review.
- [ ] **Test Data Prepared:** Relevant test data is prepared for testing the scenarios.

#### Definition of Done (DoD):

- [ ] **Test Executed:** All identified test items are executed on different OS, along with exploratory testing.
- [ ] **Defects Logged:** Any defects found during testing are resolved / appropriately logged (and approved for future fix).
- [ ] **Test Sign-Off:** QA team provides sign-off indicating the completion of testing.

### Phase 4: Release (DoR)

- [ ] **Pre-release wait time:** Code change to pre-release version should be frozen for at least X (hrs/days) for Regression testing purpose.
  - Pre-release cut off on Thu morning for the team to regression test.
  - Release to production (Stable) during working hour on Mon morning (if no blocker) or Tue morning.
  - During the release cut off, the nightly build will be paused, to leave room for pre-release build. The build version used for regression test will be notified.
- [ ] **Pre-release testing:** A review of the implemented feature has been conducted, a long with regression test (check-list) by the team.
  - Release checklist cloned from the templat for different OS (with hackMD link)
  - New key test items from new feature added to the checklist.
  - Split 3 OS to different team members for testing.
- [ ] **Document Updated:** The document is updated based on the review and feedback on any discrepancies or modification needed for this release.
- [ ] **Reviewed by Stakeholders:** New feature and the updated document is reviewed and approved by stakeholders. The document is in its final version, reflecting the implemented feature accurately.

### Notes (WIP)

- [ ] **API collection run:** to run along with nightly build daily, for critical API validation
- [ ] **Automation run:** for regression testing purpose, to reduce manual testing effort for the same items each release on multiple OS.
