93 lines
5.4 KiB
Plaintext
93 lines
5.4 KiB
Plaintext
---
|
|
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.
|