SQA Definition

A comprehensive definition of Software Quality Assurance SQA is presented here, in the form of a short history of the Software Quality Movement, an example of a theoretical CMMi SQA\SQC implementation and an example of what a typical Software Application QA engineer does day to day.

Updated Wednesday October 10th, 2007 with a new article discussing the essence of business systems requirements.


Formal SQA Definition

The correct definition of Software Quality Assurance goes something like:-

The function of software quality that assures that the standards, processes, and procedures are appropriate for the project and are correctly implemented.

This definition is taken from Software Definitions at NASA

The problem with this, and similar, definitions for commercial SQA practitioners are:-

  • It tells us little about what SQA is other than repeating the definition. That is, it uses the defined terms “assures” and “software”.
  • It doesn’t provide a scope for someone responsible for Software Quality Assurance.
  • It doesn’t address the role, or relationship, with Software Testing.
  • In its pure form under which a separate ‘audit’ style group needs to be established it is difficult to apply to a small development environment.

    • What is QA?



    The so called Quality Movement which was first established in Japan in 1946 by the U.S. Occupation Force's,
    was based on W. Edwards Deming (USA) research and papers on Statistical Quality Control (SQC).
    The various definitions and approaches to Quality Assurance come from Deming and other so called Quality Gurus.

    The important point, for this discussion, is that these methods were applied to industrial production.
    That is the production of something tangible. Fujitsu’s slogan Quality built-in, with cost and performance as prime consideration,
    typifies this approach. Under this approach the production process was broken down and specified.
    Each process would have an output (or component) that would have a required specification (measurement, weight etc.)
    and these would be verified as the main product was being built.

    It would be a separate group Quality Control (QC) that would measure the components, at various manufacturing stages.
    QC would make sure the components were within acceptable “tolerances”, i.e. they did not vary from agreed specifications.
    It is worth noting here that in manufacturing QC (or test and inspection) is easy to distinguish from Quality Assurance QA which is process compliance.
    In Software development, however, Quality Control itself presents significant challenges due to the intangible nature of Software.
    In Software development the distinction between QC (SQC) and QA (SQA) is not as clear and these terms are often mixed. A further definition of these terms, by way of example, can be found here.

    These QA methods, in manufacturing, proved themselves to work (in Sales, Customer satisfaction and the right cost of production, i.e. PROFIT) and were adopted all over the world. QA groups (for manufacturing) became the norm.

    These QA groups would not take any part in the manufacture process itself but would measure and audit the process to make sure the established guidelines and standards where being followed.
    The QA group would then give input (metrics or measuress) into a process of continuous improvement.

    In this way we could have a QC department that measures certain components at various manufacturing stages and have a QA department that makes sure that every process (including QC) is following the agreed and documented procedures.

    In short we had someone (QA) assuring that processes were conforming to document standards and procedures,
    hence these terms showing up in SQA and QA definitions, and this group were distinct from QC (i.e. testing).

    So far we are in great shape in the QA and QC world of manufacturing, then someone came up with the bright idea

    Why don't we apply these proven Quality Management processes to Software?

    The move to SQA and SQC



    Hence SQA (and SQC) were born and with it came problems of definition and implementation.

    The definition still refers back to the traditional manufacturing QA world.
    There are, however, some notable differences between software and a manufactured product.
    These differences all stem from the fact that the manufactured product is physical and can be seen whereas the software product is not visible. Therefore its function, benefit and costs are not as easily measured.

    The following differences highlight some of the issues in taking the manufacturing QA\QC model and applying it to software development.

  • The manufactured product is a physical realization of the customer requirements.
  • The function of the product can be verified against this physical realization.
  • The costs of manufacture, including rework, repairs, recalls etc., are readily categorized and visible.
  • The benefit of the product to its user\customer are readily categorized and visible.

    In order to overcome these types of issues, and reap the benefit of QA\QC applied to software, other terms, models and paradigms needed to be (and were) developed.

    In order to identify the Software Costs and Benefits, remembering Fujitsu’s term with cost and performance as prime consideration,
    a number of Software Characteristics where defined.
    These characteristics are sometimes referred to as Quality Attributes, Software Metrics or Functional and Non-Functional Requirements.

    The intention here is to breakdown the Software product into attributes that can be measured (in terms of cost benefit).
    Examples of these attributes are Supportability, Adaptability, Usability and Functionality.

    There are many definitions of these Software Quality Attributes but a common one is the FURPS+ model which was developed by Robert Grady at Hewlett Packard.
    Under the FURPS, the following characteristics are identified:-

    Functionality
    The F in the FURPS+ acronym represents all the system-wide functional requirements that we would expect to see described.
    These usually represent the main product features that are familiar within the business domain of the solution being developed.
    For example, order processing is very natural for someone to describe if you are developing an order processing system.
    The functional requirements can also be very technically oriented.
    Functional requirements that you may consider to be also architecturally significant system-wide functional requirements may include auditing, licensing, localization, mail, online help, printing, reporting, security, system management, or workflow.
    Each of these may represent functionality of the system being developed and they are each a system-wide functional requirement.

    Usability
    Usability includes looking at, capturing, and stating requirements based around user interface issues, things such as accessibility, interface aesthetics, and consistency within the user interface.

    Reliability
    Reliability includes aspects such as availability, accuracy, and recoverability, for example, computations, or recoverability of the system from shut-down failure.

    Performance
    Performance involves things such as throughput of information through the system, system response time (which also relates to usability), recovery time, and startup time.

    Supportability
    Finally, we tend to include a section called Supportability, where we specify a number of other requirements such as testability, adaptability, maintainability, compatibility, configurability, installability, scalability, localizability, and so on.

    +
    The "+" of the FURPS+ acronym allow us to specify constraints, including design, implementation, interface, and physical constraints.

    The specification of the FURPS+ characteristics needs to go into the Systems Requirements.

    The testing of these characteristics should be done by the SQC (testing team).
    Some of the FURPS+ characteristics, i.e. Functionality and Usability can be tested by executing the actual software.
    Some, however, like Supportability and Adaptability can only be verified by code inspection or dry running What if? scenarios.

    It is important to note that neither the SQA nor SQC group should have the responsibility of putting the desired FURPS+ characteristic into the product.
    They (SQC) should only test the presence or absence of the FURPS+ characteristics.

    With an established practice of defining and measuring the FURPS+ (or similar model) characteristics it is possible to implement Software QA\QC along similar lines to manufacturing QA\QC.


    This should, in theory, overcome the difficulties caused by the intangible nature of software, allowing each Characteristic of the Software to be measured (by SQC) and subject all the processes of Software production to SQA and continuous improvement.

    By way of example, consider the Supportability FURPS+ characteristic. This can be measured by the length of time in takes to fix a defect.
    In order to improve this measure coding standards could be implemented. In this scenario the SQC department would inspect the code to make sure that the coding standard was being implemented and the SQA department would make sure the SQC and the development group followed the process.
    The SQA department would also collect and analyze the time needed to repair the defect (Supportability measure) in order to give input to the usefulness of the standards as well as to the continuous process improvement initiative.

    • Conclusion

    The definitions for SQA and SQC originate from their manufacturing QA and QC counterparts.
    SQA and SQC can be implemented in Software production as their QA and QC counterparts are in manufacturing.
    In order to implement SQA and SQC (as their manufacturing counterparts) a method of characterizing the intangible software product is needed.
    The FURPS+ model defines a system of characterization, under which software attributes can be used by SQC to Test and Measure.
    Anything that is tested and measured (by SQC) needs to be defined as a requirement, this includes the FURPS+ characteristics.
    SQA in Theory provides further pure SQA concepts, including the SQA role within the CMMi framework. SQA in Practice provides a jump start practical approach to establishing Software Quality Assurance (including SQC) within a small development team.

    No guarantee (or claim) is made regarding the accuracy of this information. Any questions or comments should be sent to:-

    Programmers Heaven - Where programmers go!
    Most Popular Websites