Software Test Documentation Templates

I) Test Policy (Company Level Document)

1) Test Definition             
(Verification & Validation)

2) Testing Process
(Proper planning before starts testing)

3) Testing Standards

4) Testing Measurements
(QAM, TTM, PCM)

5) Risks

6) Approvals

7) Comments

8) Revision History
--------------------------------------------------------
II) Test Strategy (Company Level Document)
  Table of Contents
1.0    Introduction
2.0    Objective
3.0    Scope of the Document
4.0    Test Approach
4.1              Introduction
4.2              Functional and Usability Issues
5.0        Phases of Testing
5.1              Documentation Review
5.2              Unit /Module and Integration Testing
5.3              System Testing
5.4              Pre – Production Testing
5.5              Responsibilities
6.0      Test Management
6.1              Test Procedures
6.2              Test Report
6.3              Test Phase Acceptance
6.4              Timescales
7.0       Risks and Assumptions
7.1               Risks
7.2               Issues
7.3               Assumptions
7.4               Related Documents
8.0      Revision History -------------------------------------------------------- III) Business Requirements Specification
  Table of Contents
1.0    Introduction
1.1    Purpose
1.2    Scope
1.3    Background
1.4    Assumptions
1.5    Constraints
1.6    Dependencies
1.7    Users of the product
2.0    Functional Requirements
3.0    Usability Requirements
3.1    Help
3.2    Navigation
3.3    Feedback
3.4    Look and Feel
4.0    Performance Requirements
4.1    Capacity
4.2    Availability
4.3    Latency
5.0    Security Requirements
5.1    Protection
5.2    Authorization and Authentication

6.0    Revision History -------------------------------------------------------- IV) Software Requirements Specification

Table of Contents
1.0    Introduction
1.1    Purpose
1.2    Scope of the project
1.3    References
2.0    System Requirements Specification
3.0    Functional Requirements Specification
3.1    Use Cases
3.2    Functional Requirements – Online Catalog
3.3    Functional Requirements – Administration
4.0    Non Functional Requirements
4.1    Usability Requirements
4.2    Performance Requirements
4.3    Compatibility Requirements
4.3.1    Operating Systems
4.3.2    Browsers
4.4    Security Requirements

5.0    Revision History  -------------------------------------------------------- V) System Test Plan
  1) Test Plan ID:
Some type of unique company generated number to identify this test plan.

2) Introduction:
Describe the purpose of the Plan, possibly identifying the level of the plan (System Test Plan etc.). This is essentially the executive summary part of the plan.

3) Test Items:
These are things you intend to test within the scope of this test plan.

4) References:
List all documents that support this test plan. Refer to the actual version/release number of the document as stored in the configuration management system.

5) Features to be Tested:
This is a listing of what is to be tested from the Users viewpoint of what the system does. This is not a technical description of the software, but a Users view of the functions.

6) Features not to be tested:
This is a listing of what is NOT to be tested from both the Users viewpoint of what the system does and a configuration management/version control view. This is not a technical description of the software, but a Users view of the functions.

7) Test Approach:
This is your overall test strategy for this test plan; it should be appropriate to the level of the plan (master, acceptance, etc.) and should be in agreement with all higher and lower levels of plans. Overall rules and processes should be identified.

8) Entry Criteria:
It describes when to start Testing

9) Exit Criteria:
It describes when to stop testing

10) Suspension Criteria:
It describes when to stop testing temporarily.

11) Roles & Responsibilities
Team Lead or Test Lead and Team members Roles and Responsibilities.

12) Schedule:
Schedule for all Test activities in this Software Test Process.

13) Training:
Training on the application/system (Domain Training)

Training for any test tools to be used.

14) Test Environment / Lab:
It describes Require Hardware and software for setting-up Test Environment or Test Lab.

15) Test Deliverables:
Lists out that what is to be delivered as part of this plan?

16) Approvals
Who can approve the process as complete and allow the project to proceed to the next level.

17) Glossary:
Define terms and acronyms used in the document, it can be used to understood the terms used in this plan.
--------------------------------------------------------
VI) Requirements Traceability Matrix
  1) Serial No
2) Type of Requirement
3) Requirement Source
4) Requirement ID
5) Requirement Description
6) Test Case ID
7) Test Case Description
8) Test Log
9) Defect ID
10) Defect Description
11) Requirement Status
12) Software Version
13) Comments --------------------------------------------------------
VII) Test Scenario
  1) Scenario ID

2) Scenario Description

3) Module Name/ID

4) Version Control

5) Requirement/s Reference

6) Comments
-------------------------------------------------------- VIII) Test Case
  1) Test Case Id: a Unique name/number (Alfa-numeric)

2) Test Case Name: Name of Test Case

3) Test Suite ID: Unique name/number (Alfa-numeric)

4) Pre-Condition: Status before Test Case Execution

5) Steps: Steps for Executing the Test Case

6) Post-Condition: Status After Test Case Execution

7) Expected Result: Expected Result as per Requirements

8) Actual Results:

9) Test Results: Pass / Fail

10) Remarks: Comments (Optional)

-------------------------------------------------------- Note 1: You prepare this Test Case Template in Excel Sheet

Note 2: Test Case Template may vary from one company from another and one project to another.

Note 3: In the above template Actual Results and Test Results fields can be filled in Test Execution phase, Remaining fields in Test Design phase. -------------------------------------------------------- IX) Test Data

X) Test Metrics
-------------------------------------------------------- XI) Defect Report

1) Defect Id: any unique name for Identifying the Defect (Alfa numeric)

2) Defect Description: Details about the Defect

3) Test Case Id: Corresponding Test Case Id for tracking

4) Tester: Tester's name (who found the Defect)

5) Product Version: Version of the Product on which defect was found

6) Build Version: Version of the Build on which defect was found

7) Priority: Importance of the Defect based on Business /Customer

8) Severity: Importance of the Defect based on Functionality

9) Status: Status of Defect

10) Reproducible or not: Yes / No

    If Reproducible:

      Steps:

    If not Reproducible:

      Attachments

11) Reporting to: Corresponding Developer

12) Remarks : Comments (Optional) -------------------------------------------------------- XII) Test Summary Report
  1) Introduction:

2) Test Items:

3) Reference documents

4) Target Audience

5) Test Summary

       5.1) Test Suite Information:

           •    Number of test suites planned.

           •    Number and percentage of test suites implemented.

           •    Number and percentage of test suites executed.

       5.2) Test Case Information:

           •    Number of test cases planned.

           •    Number and percentage of test cases implemented.

           •    Number and percentage of test cases executed.

           •    Number and percentage of test cases passed.

           •    Number and percentage of test cases failed (total and by severity).

     5.3) Defect Report Information

    Number of defects found in comprehensive Testing

    Number of Test Cases selected for Regression Testing Cycle1

    Number of defects found in Regression Testing Cycle1

    Number of Test Cases selected for Regression Testing Cycle 2

    Number of defects found in Regression Testing Cycle 2

    Number of Test Cases selected for Regression Testing Cycle 3

    Number of defects found in Regression Testing Cycle 3

    .

    .

    .

    Number of Test Cases selected for Final Regression.

    Number of opened defects in this release.

6) Approvals

Healthcare Domain Knowledge for Testers:

Health care domain- an Introduction:

The health care industry is one of the largest industries in the world, and it has a direct effect on the quality of life of people in each country. Health care (or healthcare) is the diagnosis, treatment, and prevention of disease, illness, injury, and other physical and mental impairments in humans. Health care is delivered by practitioners in medicine, chiropractic, dentistry, nursing, pharmacy, allied health, and other care providers. The health care industry, or medical industry, is a sector that provides goods and services to treat patients with curative, preventive, rehabilitative or palliative care.

Overview of Healthcare Industry:

The health care industry, or medical industry, is a sector that provides goods and services to treat patients with curative, preventive, rehabilitative or palliative care. The modern health care sector is divided into many sub-sectors, and depends on interdisciplinary teams of trained professionals and paraprofessionals to meet health needs of individuals and populations. This article provides an overview of medical industry.

History of Healthcare Industry:

This article provides a short history of healthcare industry and discusses major world events that impacted and shaped the healthcare industry as it stands today. This article briefly traces global healthcare history from ancient times to colonial era to the modern day.  This article also discusses various ideologies that have dictated the path of global health and set the trend towards globalization of healthcare sector.
Health Care or Health Insurance is similar to general insurance. As you know, in any insurance, insurer (Insurance company) will provide the plans and customer (Subscriber or Policy holder) will buy policy of his desired plan. Insurer will receive the premium amount from the policy holders and the policy Holders will get reimbursements from insurer for the valid claims they have submitted. The same happens in healthcare insurance but in addition to insurer and policy holder there are other major contributors such as provider, TPA (Third Party Administrator), BROKER, etc.

1.) Insurer:
An entity which creates plan, sell policy and reimburses policy holder or provider for the submitted valid claims.

2.) Policy Holder:
Healthcare policy holder
A person or an entity, who buys the policy from the insurer or BROKER, pays premium to the insurer and sometimes submit claim.

3.) Provider:
A person or an entity, which provides the health care service to the policy holder and their dependents, either receives payment for the service from the policy holder or from the insurer by submitting a claim.

4.) TPA:
A person or an entity that manages the claims of policy holder or provider and receives payment for the management from the respective contributor.

5.) BROKER:
Healthcare insurance broker
As you have guessed, he is an agent who sells policy to the customers on behalf of insurer and receives commission in return from the Insurer.

6.) Subscriber - Person who pays the premium and under whom the family is covered

7.) Member - Who receives medical coverage under a subscriber. Dependents of the family.

8.) Claims - “An invoice from the provider to the doctor for the services rendered”.

9.) Coinsurance - A form of medical cost sharing in a health insurance plan that requires an insured person to pay a stated percentage of medical expenses after the deductible amount, if any, was paid.

10.) Copayment - A form of medical cost sharing in a health insurance plan that requires an insured person to pay a fixed dollar amount when a medical service is received. The insurer is responsible for the rest of the reimbursement

11.) Deductible - A fixed dollar amount during the benefit period - usually a year - that an insured person pays before the insurer starts to make payments for covered medical services.

12.) FSA (Flexible spending accounts or arrangements) - Accounts offered and administered by employers that provide a way for employees to set aside, out of their paycheck, pretax dollars. Can pay only medical expenses. Money lost if unused. FSA can cover childcare expenses, if setup separately.

13.) MSA (Medical Savings Account) / HSA (Health Spending Account) - Savings accountsdesignated for out-of-pocket medical expenses. Employers and employees can contributeto this and are pre-taxed. Can carry unused funds into future year. Are normally combined with high-deductible or catastrophic health insurance plans.

14.) Fully Insured Plan - A plan where the employer contracts with another organization to assume financial responsibility for the enrollees’ medical claims and for all incurredadministrative costs.

Commercial Health Care Plans:
•    Preferred provider organization (PPO)
•    Exclusive provider organization (EPO)
•    Health maintenance organization (HMO)
•    Supplemental Insurance
•    MediGap

Government Health Care Plans:

•    Medicaid
•    Eligibility
•    Coverage
•    Medicare
•    Eligibility
•    Coverage

How to test health care application?

Before testing an application, we should be aware of healthcare industry work flow. The previous topic just gives an introduction to managed health care, more details are available here.

An Insurer needs different applications to manage the following:
•    Provider data
•    Member data
•    Premium billing/payment
•    BROKER data
•    Claims entry/validation
•    BROKER commission calculation/payment

Generally a healthcare application will have the following list of systems:

•    Member system – To maintain policy holder data, various plans with their list of benefits and generate premium bills for the policy holder based on their plans
•    Provider system – To maintain provider data
•    Broker system – To maintain BROKER data and calculate commissions
•    Claims system – For claim entry and validation
•    FINANCEsystem – To do the necessary payment to provider/member/broker
•    Member portal – To display the policy holder information, make premium payments and raise request for change information for policy holders
•    Provider portal – To display provider information and raise request for change information for providers
•    Broker portal – to display broker information and raise request for change information for BROKERS

For example, Provider system can be part of Member system in some healthcare application. By healthcare application I mean a set of systems maintained by an Insurer to facilitate their customers and partners.

Health Care Application Testing Work flow:

The unique feature of health care system is that, these applications cannot be tested in any order we like. There is a certain work flow to be followed:
•    For a member/policy holder to be enrolled in a health plan he/she need to be assigned to a provider (Primary Care Physician) or a provider network, so there should be a way for member system to validate the assign provider. Either member system connects to the provider system or a data feed should periodically sent to member system from provider system. Therefore provider system should be tested and ready to use before testing member system.
•    A claim should consist of provider ID and member ID in addition to other details. Claim system should validate both the member and provider in order to validate the claim, so both member and provider system should be tested and ready to use before testing claims system.
•    Finance system need to have data from member, provider, and claim and BROKER system to write checks or make EFT payments to the respective person or entity.
•    Provider and BROKER systems are stand alone.
•    Portals should be tested at last since it needs data from the other applications.

Health Insurance Portability and Accountability Act (HIPAA):
HIPAA is the federal Health Insurance Portability and Accountability Act of 1996. The primary goal of the law is to make it easier for people to keep health insurance, protect the confidentiality and security of healthcare information and help the healthcare industry control administrative costs.

HIPAA Transactions:
•    837 - Claims submission (Professional / Institutional and Dental)
•    834 - Enrollment (Benefit Enrollment and Maintenance)
•    820 – Premium Payments (Payroll Deducted and Other Group Payments)
•    270/271 – Eligibility and Benefits (Health Care Eligibility Inquiry and Response)
•    278 – Authorization (Health Care Services Request for Review and Response)
Challenges Faced by Testers in the Healthcare Domain:
Testing healthcare software is a difficult task for testers as it requires a vast knowledge of the domain. It also poses many challenges because of the complexity of the design, diagnosis, and the day to day development of the patient. Moreover, the product needs to conform to various Safety and Regulatory Standards such as IHE, HL7 and others.
With an increase in the demand for healthcare software, there is also a rise in the complexity of the product. Some of the challenges are

1.    Healthcare Standards:

Testers should be aware of the various standards in the healthcare domain such as DICOM, HIPAA and others while testing the product for various aspects. Testing a healthcare product without having knowledge of the various standards will result in the inadequacy of testing.
 
2.    Domain and System Knowledge:

Testers should be well aware of the various functionality, clinical usage, the environment the software will be used and others while testing healthcare products.

3.    Safety and Hazards:

If the healthcare product is not tested adequately for safety and hazards, it will have a fatal impact not only on the product but also on the patient. Testers must be able to identify the various hazards and their impact.

4.    Process Compliance:

Healthcare products also need to comply with various standards like FDA, ISO and CMMI before they can be used. Testers must be well trained on the various standards so as to ensure that the product meets the requirements of the various standards.

5.    Cross Dependency of Software:

Complex software has different components and layers. Changes in one component or layer can lead to some side effects on the other. Testers must ensure that there will be no side effects on the other layers whenever there are changes.