> For the complete documentation index, see [llms.txt](https://knowledgebase.fabricdata.com/fabric-knowledge-base/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://knowledgebase.fabricdata.com/fabric-knowledge-base/support/releases/testing-criteria-and-qa-plan-for-new-feature-releases.md).

# Testing Criteria & QA Plan for New Feature Releases

### Feature releases testing

#### **Steps in Specifications**

**Product:** When there is a feature / product change request / product enhancement: Done by Product Team\
**BA:** When something is a project Ticket e.g. New integration, or creation of new field. Will be done by BA (no designs required).

1. **Product requirement document/ System configuration document**
   1. (BA/Product) Functional test criteria based on planned functionality - explained through user stories, functional acceptance criterias and edge-cases/ use cases.
      1. Scope
      2. User story → As a User we can do x, y, z on feature.
      3. Acceptance criteria → Ideally using given when then format for scenario-based or list containing logic, security
      4. Edge-cases or happy path use cases
   2. (Tech leads) Initial Estimation Exploration :
      1. Can we develop this feature?
      2. Can the feature support X much performance?
      3. Infrastructure impact analysis (BA/Product)
         1. AWS
         2. Loggly
         3. Playwright
   3. (BA/Product) Integration Analysis
      1. What will the new feature/project likely impact?
         1. Other client's upstream and downstream integration
         2. Looker
         3. Nuvo
         4. Okta / any other SSO’s
         5. Enrichment system (EIDR, IMDB, Gracenote)
   4. (BA/Product) UAT plan/ acceptance that has been agreed with the clients
2. **Design (UX & UI)** **acceptance criterias**
   1. (Design team) UI Acceptance Criteria Design from Design Team to be included
   2. (Design team) UX Acceptance Criteria Design from Design Team to be included
3. **QA testing plan:** team the testing plan in the ticket based on Acceptance Criteria
   1. Testing plan
      1. Test scope and environments
      2. Test runner (manual/ automation)
      3. Functional test
         1. Test scenarios based on\
            Include all business ACs (acceptance criterias), edge-cases, main use cases that have been populated
            1. Unit test scenarios
            2. Product/ business functional test scenarios
            3. Integration test scenarios
         2. Unit, Functional and Integration test scripts
            1. Test steps
            2. Test acceptance criteria
            3. Test data - if needed
      4. API test\
         Make sure that if we test the API and/ or back end functionality if needed (e.g. cast & crew
      5. Non Functional tests
         1. UI/UX Level Testing: Component Level Testing
            1. Whenever we plan a new feature, we need to create the UX/UI testing plan, and then this get’s included in regression tests for rest of features.
            2. E.g. When I click asset tab, the line item must be expanded. Or This is a date / time field, if I input hours will it work or will it not work. If it’s mandatory, does the red box tell me it’s mandatory. Is the error message correct?
4. **Tech Lead Implementation Details**
   1. Then we get Implementation details from Tech Leads (After we have from QA)
      1. Tech leads consider edge cases and performance parameteres in designing the architecture and tech strategy / approach.

#### Before release

1. Functional Test in FDS Dev & QA
2. Smoke & Sanity tests\
   in FDS QA\
   This is testing the happy path which cannot be broken. Ideally, an automated test\
   Notes:
   * Smoke test scenarios based on functionality that needs to be added for future smoke test/ regression test that we have.
   * e.g. If the functionality touch record functionality, we shouldn’t have any issues with Records. We can still create records, we don’t have to go into details.
   * Ideally needs to be done before every release to the client
3. \*Regression test (once we have more resource/ everything is automated - we should conduct this continuously before a release)

#### Release Management

Feature Toggles: What toggle are expected to be turned on and released for Clients.

1. List of every environment and client with toggle status
2. E.g. For next release, please toggle on Task manager v3 or For next release, toggle off x feature because it failed testing.

### Maintenance testing

These are regular tests that we’re doing in an effort to have a clean highly functional platform

#### Monthly

* **Smoke & Sanity Testing** - following the release schedule\
  Should be done in FDS QA and Client QA\
  This test usually contains the happy path (e.g. create record, delete record, etc) and frequently used functionality by clients

#### Quarterly/ Bi-yearly

* **Regression testing**:
  * Every functionality needs to be tested.
  * Should take into account smoke tests + more things.
    1. E.g. For Smoke & Sanity E.g. Create update delete. But for Full Regression, we would test more fields.
  * Full Regression is to be done in FDS.<br>
* **Performance testing**
  * E.g. Our Clients will give us NFR e.g. I need this to work also in Internet Explorer as well.
  * E.g. When we have 200 images in the Image Tab, it takes 5 mins.
  * Measuring response times
  * Identifying bottlenecks
  * Locating failure points<br>
* **Load testing**\
  Load testing checks how the software behaves under both normal and peak conditions. This is done to determine how much work load the software can handle before performance is negatively affected.\
  \
  You can perform load tests by running multiple applications simultaneously, subjecting a server to a high amount of traffic, or downloading a large quantity of files.\
  \
  Load tests are used to ensure fast and scalable software.<br>
* **Stress Tests**\
  Stress testing checks how the software behaves under abnormal conditions. This determines the limit at which the software will break.\
  \
  It’s important to find out what happens when the system is under stress. Does the right error message display? Does the system fail? How will it recover?\
  \
  Stress tests help testers analyze what happens when a system fails. This ensures that software is recoverable, stable, and reliable.\
  \
  Bulk import stress test.
* **Penetration testing**\
  Yearly tests that we’re currently doing already.

***

<details>

<summary>Related Articles</summary>

* [Client QA Testing and Release Approval](/fabric-knowledge-base/support/releases/client-qa-testing-and-release-approval.md)
* [<mark style="color:blue;">Security</mark>](/fabric-knowledge-base/support/security.md)
* [<mark style="color:blue;">Infrastructure</mark>](/fabric-knowledge-base/support/infrastructure.md)

</details>