Types of QA Testing

QA, or Quality Assurance, is the testing we do to ensure the quality and functionality of the Torus Platform. We can normally break QA into 4 pieces, integration testing and regression testing. There are also two other testing cases, smoke tests, and bug reproduction.

Integration Testing

Integration testing focuses on verifying the interfaces and interactions between different modules or components of a software application. For us, this means testing each and every ticket on JIRA that results in a change to the Torus codebase. Integration testing will be ongoing, and all tests should be performed in Argos QA.

The Process for Integration Testing

View this document for detailed information: Integration Testing 101

  1. A ticket will be completed by a developer and moved to the QA column of the MER board.
  2. Mia (or someone) will assign a ticket to a QA tester
    1. If the tester is Paul or Rajeswari, Mia will also create a task in ‣
  3. The tester will look over the ticket, and make sure they understand what is needed to test the ticket. If they don’t understand, they need to reach out to Mia.
  4. Once the ticket is understood, the tester will test the functionality in the ticket.
  5. For now, the tester will then add a comment about whether or not the ticket passes testing, then assign the MER ticket back to Mia.
  6. Mia will review the ticket, and either send it back to the developers, or mark the ticket as complete.
    1. For Paul and Rajeswari, if the ticket is marked complete, then you can close out the task in ‣

Regression Testing

Regression testing is aimed at ensuring that recent code changes have not adversely affected the existing functionality of the software. Whenever new features are added, or modifications are made to the codebase, there is a risk that these changes might introduce new bugs or cause previously working features to fail. Regression testing involves re-running previously executed tests to confirm that the existing functionalities still perform as expected. Basically, regression testing is the large scale testing we do right before a release to test all of the functionality of the platform.

The Process for Regression Testing

For all releases up to and including v28, we use a variation of the ETX QA Punchlist for regression testing. This spreadsheet is the source of truth, and where everything related to testing for releases should be recorded. One round of QA should take just under a week to complete, with multiple people helping. The first 2 or so rounds of regression testing will occur on Argos QA. Once we are confident there are no issues, we move to Argos Stage to perform 1-2 additional rounds of testing.

For v29 and beyond, we will move to a combined Regression Test Script that will be completed by both the CMU and ASU QA teams. More info to come on this.

Smoke Testing

Immediately after a release, we perform a smoke test, which lets us quickly assesses the main functionality of the platform. The goal of smoke testing is to quickly determine if the platform’s most critical functions work as expected, without focusing on finer details.