This page outlines the quality assurance aspect of the Bahmni-SNOMED FHIR Terminology Server initiative.

In order to assure the delivery is of highest quality, the team has come up with the action plan which is described in this page. It outlines the activities, assumptions, considerations, etc., to perform QA checks by the team under different  environments

Following are the QA aspects that are described in this page

1. Environments   

2. Types of testing 

3. Development & QA Activities for Quality Assurance

4. Definition of Ready 

5. Definition of Done 

6. Assumptions

Environments

Bahmni-SNOMED Integration currently supports 2 environments with 1 shared resource for both the environments. Please find the details below

Types of Testing

Below are the types of testing that will be performed

• Unit Testing (Dev’s local machine)

• API Contract Testing (Postman/Brew) 

• Integration Testing

• Security Testing

• E2E Testing

Development & QA Activities for Quality Assurance

Below diagram outlines the Dev and QA activities for quality assurance

Open

Definition of Ready

• Thorough grooming of stories with the team

• Acceptance Criteria and Test Scenarios documented in Jira

Definition of Done

• All stories must be tested in a QA environment before being marked as "closed" or "done" in the JIRA Board.

Assumptions

• Testing - Scenario-based manual testing is currently planned, with test scenarios documented in Jira and Wiki.

• Deployment - Docker based deployment onto Dev and QA environments. Code Repository is maintained on snomed-master branch(with exception of OMOD that is maintained directly on the master branch)

• Pull Strategy - Bahmni master to be pulled after each Sprint into snomed-master to ensure that SNOMED branches has not deviated much w.r.t Bahmni Master and to avoid merge issues later in the project.

• Merge Strategy - Changes from the snomed-master branch to be merged into Bahmni master at some logical point ( preferably after every milestone).

• A JIRA card to be created to track regression efforts after merging. This involves  collaboration with the Bahmni Product QA team to ensure no regression issues are introduced and SNOMED use-cases work even after merging into the core product.

• A trivy report would be run, and the results would be shared during the showcase in terms of security.

• There might be a need for the Bahmni community to evaluate Bahmni-SNOMED locally through docker based installation by configuring  either a public SNOMED or dedicated Snowstorm server instance. Hence documentation would be made on docker based local setup. Therefore testing has to also ensure regression on local setup in addition to AWS Dev/QA environments. The documentation would be published on Wiki.

• Biweekly call (which can be combined with IPM) to discuss the Test scenarios