SQA and SQC in the Commercial Workplace
First a caveat, the danger in environments where SQA\SQC is not formally implemented is that the 'Quality Group' becomes a kind of 'Engineering Services' group and do what ever the main development team does not currently (or does not want to) do. In many environments the SQA\SQC team reports to an application development manager and the 'Engineering Services' approach is very attractive to this manager. For example, let's say performance is an 'after thought' that is not specified as a non-functional requirement, not designed into the system but noticed when things go wrong. Under the 'Engineering Services' scenario it is tempting for the manager to send the QA person on a LoadRunner (or other load testing tool course) install the tool and declare the QA person 'our performance expert'. This type of approach will not work, the QA team member should be able to perform load testing (as part of SQC) but the performance requirements (that are tested for) should be part of the requirements and the Designer\Programmer should 'own' the performance objective.
So, accepting that SQA\SQC have to be separate from development activities and certain (mainly Requirement and Design) activities always need to take place, let's look at a hybrid, or generalized, approach to SQA. SQA and SQC will be referred to as Software QA and the activities of this person(s) represent a good ROI for achieving the goals of SQA\SQC with a limited resource.
Note: This is only a sample of SDLC activities but role of Software QA against these activities should illustrate the kind of roles that a general Software QA person should undertake.
Software QA roles against a generic SDLC
The role of Software QA in Requirements development and Requirements Management: Software QA verifies that the Requirements conform to the basic standard (Templates) and the requirements are free of any ambiguities. In terms of completeness, Software QA would also review the risks of not completing the Non-functional section. The Software QA would also review the Traceability Matrix in order to make sure all requirements were referenced in other specifications.
At this stage, some test cases that refer to the requirements could be written by Software QA and cross referenced in the Traceability Matrix. In many cases this exercise will further verify the Requirements, as test cases (with data) are being built.
If the system is component based then an Interface Specification should be produced. Again templates should exist for this. This document should be subjected to Verification by Software QA.
Lower level specifications (for commercial applications) should only be subjected to Software QA if they are critical (i.e. main loan rate calculations) modules. In general paying attention to Interfaces and the Requirements (Functional and Non-Functional) will provide a good ROI for limited Software QA resources.
This should be done by the developers themselves.
If a harness (Web Services or HTTP) is available, then Software QA should get involved with this 'grey box' testing. The test cases can be written ahead of time, by the Software QA team. For this reason the Interface Specification is an important deliverable.
The actual staging and verification of the basic 'hand shake' should be done by the technical development team. If the systems 'don't talk' then the Software QA team should not be involved. Once a component is integrated then Software QA can execute the Integration Testing.
System Testing against the Requirements
Following a complete system being built, Software QA should execute the main System test cases that validate the system against the requirements, this phase of the SDLC is what most people associate with the term software testing.
Software QA should have a documented set of test cases that can verify if any component or function, not already tested as part of a release, has been negatively impacted by the new change.
Software QA should run some performance tests to verify performance parameters (response times etc.) are within the requirements. If performance issues are found then the development team needs to be involved in diagnosing and resolution
This should be owned and executed by representatives of the 'sign off' team. For small changes this could be Software QA.
Move to Production
This should be verified by Software QA but the actual process should be carried out by someone else.
Defect Tracking and Resolution
Software QA should track all defects, retest until testing is complete. During this process Software QA should determine the 'origin' of the defect. If the defect was introduced as a result a misunderstanding of the Requirements then this information should feed into the Requirements Development process improvement initiative.
No guarantee (or claim) is made regarding the accuracy of this information. Any questions or comments should be sent to:-