This page is maintained for older versions of Spira only. The latest documentation can be found at: https://spiradoc.inflectra.com

Spira 4.2 User Manual Help Viewer

1. Introduction
2. Functionality Overview
3. User/Project Management
4. Requirements Management
5. Test Case Management
6. Incident Tracking
7. Release Management
8. Task Tracking
9. Resource Tracking
10. Document Management
11. Reports Center
12. Source Code
13. Planning Board
14. Mobile Access
Search:
1. Introduction
2. Functionality Overview
3. User/Project Management
4. Requirements Management
5. Test Case Management
6. Incident Tracking
7. Release Management
8. Task Tracking
9. Resource Tracking
10. Document Management
11. Reports Center
12. Source Code
13. Planning Board
14. Mobile Access

1.1. Quality Assurance

Quality Assurance is a key component of the Software Development Life-Cycle (SDLC), which needs to be integrated into the planning and management of a program or project from its inception. Too often though, QA is implemented as Quality Control - whereby testing that the required functionality works as expected, is performed at the end, when it is most costly to make corrections and changes.

To manage QA across a project from day one, it is imperative that the original requirements are documented together with the use-cases that validate the desired functionality. These use-cases then form the basis of the test scripts that can be executed to validate that the functionality has been correctly built, and that the requirements have been satisfied. During the execution of these test scripts, failures may occur, which are recorded as incidents - either to be fixed or documented depending on the severity.

Typically, these activities require people to use at least three different types of software:

  • Requirements Management
  • Test Script Management
  • Defect / Issue / Bug Tracking

However, this stove-piped approach has many limitations and drawbacks, most importantly the fact that there is no traceability between the different artifacts. How can the project manager know that all the requirements have been tested? Conversely, how can the developer know which test script was responsible for a recorded bug – needed to accurately reproduce the issue?