Here are some of the standards that are useful during Software testing which a testing professional should be aware of:
IEEE: Institute of Electrical and
Electronics Engineers
A transnational organization founded in 1884, IEEE consists of dozens of specialized societies within geographical regions throughout the world. Software testing standards are developed within the technical committees of the IEEE Societies and the Standards Coordinating Committees of the IEEE Standards Board.
These standards are created through a process of obtaining the consensus of practicing professionals. This consensus process, which includes careful discussion and debate among members of the various committees who serve voluntarily, is one of the fundamental themes of the standards process. Another key theme is to provide standards in a timely manner, from project approval to standard approval is approximately 3 years.
610.12-1990: IEEE Standard Glossary of Software Engineering Terminology
Topics covered include addressing; assembling, compiling, linking, loading, computer performance evaluation, configuration management, data types; errors, faults, and failures; evaluation techniques; instruction types; language types; libraries; microprogramming; operating systems; quality attributes; software documentation; software and system testing; software architectures; software development process; software development techniques; and software tools. This standard promotes clarity and consistency in the vocabulary of software engineering and associated fields.
730-1998: IEEE Standard for Software Quality Assurance Plans
The purpose of this standard is to provide uniform, minimum acceptable requirements for preparation and content of SQAPs (Software Quality Assurance Plans).
The plan includes the following sections:
Purpose
Defines purpose and scope
Reference Documents
Complete list of documents referenced within SQAP
Management
Describes organization, tasks, responsibilities
Documentation
Identifies the documentation governing development, verification and validation, use, and maintenance of the software.
Documents include: Software Requirements Specification (SRS), Software Design Description (SDD), Software Verification and Validation Plan (SVVP), Software Verification and Validation Report (SVVR), User documentation, Software Configuration Management Plan (SCMP), Software Development Plan, Standards and procedures manual, software project management plan, software maintenance manual.
Standards, practices, conventions, and metrics
Identifies the standards, practices, conventions and metrics to be applied, and states how compliance with these items is to be monitored and assured.
Reviews and audits
Defines the technical and managerial reviews and audits to be conducted, states how the reviews and audits are to be accomplished, and states what further actions are required and how they are to be implemented and verified.
Test
Identifies all the tests not included in the SVVP for the software covered by the SQAP and states what methods are to be used.
Problem reporting and corrective action
Describes the practices and procedures to be followed for reporting, tracking, and resolving problems identified in both software items and the software development and maintenance process
Tools, techniques, and methodologies
Identifies the special software tools, techniques, and methodologies that support SQA, state their purposes, and describe their use.
Code control
Defines the methods and facilities used to maintain, store, secure, and document controlled versions of the identified software during all phases of the software life cycle.
Media control
Identifies the media for each computer product and the documentation required to store the media, including the copy and restore process, and protects the computer program physical media from unauthorized access or inadvertent damage or degradation during all phases of the software life cycle.
Supplier control
States the provisions for assuring that software provided by suppliers meets established requirements. Also states the methods that will be used to assure that the software supplier receives adequate and complete requirements. This section also states the methods to be employed to assure that the developers comply with the requirements of this standard.
Records collection, maintenance, and retention
Identifies the SQA documentation to be retained; states the methods and facilities to be used to assemble, safeguard, and maintain this documentation, and designates the retention period.
Training
Identifies the training activities necessary to meet the needs of the SQAP
Risk management
Specifies the methods and procedures employed to identify, assess, monitor, and control areas of risk arising during the portion of the software life cycle covered by the SQAP.
828-1998: IEEE Standard for Software Configuration Management Plans
This standard establishes the minimum required contents of a software configuration (SCM) plan. It is supplemented by 1042-1987 (which provides approaches to good software configuration management planning). This standard applies to the entire life cycle of critical software. The plan documents what SCM activities are to be done, how they are to be done, who is responsible for doing specific activities, when they are to happen, and what resources are required.
829-1998: IEEE Standard for Software Test Documentation
This standard describes a set of basic test documents that are associated with the dynamic aspects of software testing. The standard defines the purpose, outline, and content of each basic document. Documents included:
§ Test Plan
§ Test Design Specification
§ Test Case Specification
§ Test Procedure Specification
§ Test Item Transmittal Report (a document identifying test items)
§ Test Log
§ Test Incident Report
§ Test Summary Report
830-1998: IEEE Recommended Practice for Software Requirements Specifications
This standard describes the recommended approaches for the specification of software requirements. It describes the content and qualities of a good software requirements specification (SRS), and includes several sample SRS outlines.
1008-1987 (R1993): IEEE Standard for Software Unit Testing (ANSI)
This standard defines an integrated approach to systematic and documented unit testing. The approach uses unit design and unit implementation information, in addition to unit requirements, to determine the completeness of the testing. The standard describes a testing process composed of a hierarchy of phases, activities, and tasks. Further, it defines a minimum set of tasks for each activity, although additional tasks may be added to any activity.
1012-1998: IEEE Standard for Software Verification and Validation
The purpose of this standard is to:
1. Establish a common framework for V&V processes, activities, and tasks in support of all software life cycle processes, including acquisition, supply, development, operation, and maintenance processes.
2. Define the V&V tasks, required inputs, and required outputs
3. Identify the minimum V&V tasks corresponding to software integrity levels using a four-level scheme
4. Define the content of a software V&V Plan (SVVP)
1012a-1998: IEEE Standard for Software Verification and Validation (Supplement to 1012-1998 – Content Map to IEEE 12207.1)
The 2 requirements (1012 and 12207.1) place requirements on plans for verification of software and validation of software. The purpose of this annex is to explain the relationship between the two sets of requirements, so that users producing documents intended to comply with both standards may do so.
1016-1998: IEEE Recommended Practice for Software Design Descriptions
This is a recommended practice for describing software designs. It specifies the necessary information content, and recommended organization for a Software Design Description (SDD). An SDD is a representation of a software system that is used as a medium for communicating software design information.
1028-1997: IEEE Standard for Software Reviews
The purpose of this standard is to define systematic reviews applicable to software acquisition, supply, development, operation, and maintenance. This standard describes how to carry out a review. Other standards or local management define the context within which a review is performed, and the use made of the results of the review. Software reviews can be used in support of the objectives of project management, system engineering, verification and validation, configuration management, and QA. Different types of reviews reflect differences in the goals of each review type. Systematic reviews are described by their defined procedures, scope, and objectives.
1044-1993: IEEE Standard Classification for Software Anomalies (ANSI)
(Anomaly: any condition that departs from the expected. The expectation can come from documentation or someone’s perceptions or experiences). The methodology of this standard is based on a process (sequence of steps) that pursues a logical progression from the initial recognition of an anomaly to its final disposition. Each step interrelates with and supports the other steps.
1045-1992: IEEE Standard for Software Productivity Metrics (ANSI)
This standard describes the data collection process and calculations for measuring software productivity.
1058-1998: IEEE Standard for Software Project Management Plans
This standard prescribes the format and content of Software Project Management Plans (SPMPs). An SPMP is the controlling document for managing a software project; it defines the technical and managerial processes necessary to develop software work products that satisfy the product requirements.
1058.1-1987(R1993): IEEE Standard for Software Project Management Plans (ANSI)
Explains the relationship between 1058 standard and 12207.1 standard, so that users producing documents intended to comply with both standards may do so.
1061-1998: IEEE Standard for Software Quality Metrics Methodology
Scope: Provides a methodology for establishing quality requirements and identifying, implementing, analyzing, and validating process and product software quality metrics. This methodology applies to all software at all phases of any software life cycle.
Framework: Software Quality is the degree to which Software possesses a desired combination of quality attributes. The purpose of Software Metrics is to make assessments throughout the Software Life cycle as to whether the Software Quality requirements are being met. The use of software metrics reduces subjectivity in the assessment and control of software quality by providing a quantitative basis for making decisions about software quality. However the use of Software Metrics does not eliminate the need for human judgment in Software assessments. The use of software metrics within an organization or project is expected to have a beneficial effect by making software quality more visible.

 
 




happijyo
senkumari

Very Good Sharing,
It Can be prepared and attached as a Document fromat, So we can use it as reference resourse .