Skip to content

General test plan

Company: Nikted
Document Name: General software test plan
Document Number: HAD-RPT-157-Rev1
Author: Erfan Khebrati
Date (Persian Calendar): 1404/07/01

Revision History

Rev. no. Description Author(s) Reviewers Date (Persian) Authors' Signature Reviewers' Signature
1 Write general testing protocol according to 62304 regulations Erfan Khebrati Ghafar nosrati
Regulatory Reference Description
IEC 62304:2006, 5.1.6 Software VERIFICATION planning Software verification planning
IEC 62304:2006, 5.5 SOFTWARE UNIT implementation and verification Software unit implementation and verification
IEC 62304:2006, 5.6 Software integration and integration testing Software integration and integration testing
IEC 62304:2006, 5.7 SOFTWARE SYSTEM testing Software system testing

1. Introduction and Strategy

This document outlines the software verification strategy for this project. Our verification approach is structured into three distinct levels of testing, each corresponding to a specific stage of the software design and development process as mandated by IEC 62304.

This tiered strategy ensures that:

  1. The smallest components of the software are verified against their detailed design.
  2. Aggregates of these components are verified against the software's architectural design.
  3. The complete, integrated software system is verified against all specified software requirements.

All anomalies discovered during these verification activities shall be documented and managed according to our Software Problem Resolution Process.

2. Software Unit Verification

This level of testing corresponds to IEC 62304:2006, Clause 5.5: SOFTWARE UNIT implementation and verification.

2.1. Definition and Purpose

A SOFTWARE UNIT is the "SOFTWARE ITEM that is not subdivided into other items". Unit verification is the process of testing these individual SOFTWARE UNITS in isolation to confirm that they correctly implement their Software Detailed Design. The standard requires the manufacturer to "establish strategies, methods and procedures for verifying the SOFTWARE UNITS" and "perform the SOFTWARE UNIT VERIFICATION and document the results".

A test is considered a SOFTWARE UNIT test only if the System Under Test (SUT) is completely isolated from external dependencies that cannot be controlled by the test itself. Dependencies that must be stubbed or mocked include:

  • File system, database, or network calls.
  • Operating system calls that are not deterministic (e.g., system time/date, thread/process creation).
  • Hardware interfaces (e.g., system ports, Bluetooth, Location APIs).

2.2. Location and Naming Convention

  • Location: Per team convention, all unit tests are written in the unit folder within the test source sets.

  • Naming Convention: Tests shall be named following the systemUnderTest_scenario_expectedResult pattern.

@Test
fun sumFunction_given3and5_returns8() {
    // ...
}

2.3. How to run

To run unit tests:

  • run ./gradlew testDebugUnitTest --rerun-tasks --tests "com.nikted.had.*.unit.*"
  • find report at composeApp/build/reports/tests/testDebugUnitTest/index.html

3. Software Integration Testing

This level of testing corresponds to IEC 62304:2006, Clause 5.6: Software integration and integration testing.

3.1. Definition and Purpose

Software integration testing is the process of verifying the correct functioning of aggregated SOFTWARE UNITS, referred to as SOFTWARE ITEMS. The primary purpose is to verify the interfaces and interactions between SOFTWARE UNITS as defined in the Software Architecture Description. The standard mandates that the manufacturer shall "integrate the SOFTWARE UNITS in accordance with the integration plan" and "test the integrated SOFTWARE ITEMS in accordance with the integration plan...and document the results".

Unlike unit tests, integration tests may involve real external dependencies that are not stubbed (e.g., real database access, real Bluetooth commands). These tests are not fully "black-box," as they require knowledge of the internal SOFTWARE ITEMS and their interfaces.

3.2. Location

  • Location: Per team convention, integration tests are written in the integration folder in each test source set.

3.3. How to run

To run end to end tests :

  • connect your android device
  • ./gradlew composeApp:connectedDebugAndroidTest -Pandroid.testInstrumentationRunnerArguments.package=com.nikted.had.client.integration
  • find the report in composeApp/build/reports/androidTests/connected/debug/index.html

4. Software System Testing

This level of testing corresponds to IEC 62304:2006, Clause 5.7: SOFTWARE SYSTEM testing.

4.1. Definition and Purpose

Software system testing is the final verification activity performed on the fully integrated MEDICAL DEVICE SOFTWARE. Its purpose is to demonstrate, with objective evidence, that the software meets all requirements specified in the Software Requirements List. The standard requires the manufacturer to "establish and perform a set of tests...for conducting SOFTWARE SYSTEM testing, such that all software requirements are covered".

These tests are performed in a black-box manner, simulating real-world user scenarios. The tester interacts only with the user interface, and assertions are made against the UI or observable states of connected hardware, without knowledge of the internal code implementation. This process is critical for verifying that all functional requirements and, crucially, software-based risk control measures have been implemented correctly.

4.2. Test Methods

4.2.1. Manual Testing

Manual test protocols will be written to guide a human operator. Each protocol will describe a test scenario and must clearly define:

  • Steps: The actions to be performed on the user interface.
  • Expected Results: The expected system state or UI display after each step.

This corresponds to the software-system-testing-plan.md.

4.2.2. Automated Testing

Automated system tests will be implemented using the established framework for Compose Multiplatform.

4.2.2.1 Location and Execution
  • Location: Per team convention, automated system tests are located in the endToEnd folder in the test source sets of each Gradle module.
  • Execution: To run the automated system tests, execute the following Gradle task: 
    ./gradlew composeApp:connectedDebugAndroidTest -Pandroid.testInstrumentationRunnerArguments.package=com.nikted.had.client.endToEnd
  • Test Report: After execution, the test report can be found at composeApp/build/reports/androidTests/connected/debug/index.html. This report serves as part of the objective evidence required by the standard, as per Clause 5.7.5 SOFTWARE SYSTEM test record contents.