Testing Process

How a feature moves from “implemented” to “released”, and where the testing team fits.

Process

  1. Once the feature request is approved, the testing team will create a set of test cases for various scenarios. All corner cases should be covered.

  2. Once completed, the testing team should notify TAC (Testing Approval Committee). The TAC should verify and proceed for approval.

  3. Once the developers have implemented/fixed the necessary features/optimizations/bugs and the code is merged, Teson will spin up a staging instance for the test team to execute manual and automated test cases.

    Note: if critical bugs or performance issues are identified in steps 5 and 6, they need to be resolved by developers at this stage.

  4. Teson will create the incremental release notes for the set of features and bug fixes going into the coming release.

  5. The testers should verify and report bugs on GitHub. Go back to step 3 if there are critical bugs that need to be fixed. If no critical bugs are found, proceed to step 6.

  6. Testers should proceed to do a performance test and report any performance issues on GitHub.

    Note: manual interaction with the system also needs to be performed to see how the system under test (SUT) behaves. Go back to step 3 if there is highly unoptimized code that needs to be fixed. Proceed to step 7 if the performance results are as expected.

  7. Deploy on production.

Future: enhancements (using metrics for quality software)

Metric

Formula

Requirement Coverage (%)

(Requirements with at least one test case ÷ Total requirements) × 100

Test Case Execution Status (%)

(Passed test cases ÷ Total executed test cases) × 100

Defect Leakage Ratio (%)

(Defects found post-test cycle ÷ Total defects) × 100

See also