Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Testing Standards List


Published on

This is a list of Testing Standards.

Published in: Technology
  • Be the first to comment

Testing Standards List

  1. 1. WWW.UNIVERSALEXAMS.COM Software Testing Standards Overview This document provides an overview of standards referenced from the ISEB Intermediate Certificate in Software Testing Syllabus. IEEE 1028 generic process for formal reviews IEEE Std 1028 defines a common set of activities for "formal" reviews (with some variations, especially for software audit). The sequence of activities is largely based on the software inspection process originally developed at IBM by Michael Fagan. Differing types of review may apply this structure with varying degrees of rigour, but all activities are mandatory for inspection: • 0. [Entry evaluation]: The Review Leader uses a standard checklist of entry criteria to ensure that optimum conditions exist for a successful review. • 1. Management preparation: Responsible management ensure that the review will be appropriately resourced with staff, time, materials, and tools, and will be conducted according to policies, standards, or other relevant criteria. • 2. Planning the review: The Review Leader identifies or confirms the objectives of the review, organises a team of Reviewers, and ensures that the team is equipped with all necessary resources for conducting the review. • 3. Overview of review procedures: The Review Leader, or some other qualified person, ensures (at a meeting if necessary) that all Reviewers understand the review goals, the review procedures, the materials available to them, and the procedures for conducting the review. • 4. [Individual] Preparation: The Reviewers individually prepare for group examination of the work under review, by examining it carefully for anomalies (potential defects), the nature of which will vary with the type of review and its goals. • 5. [Group] Examination: The Reviewers meet at a planned time to pool the results of their preparation activity and arrive at a consensus regarding the status of the document (or activity) being reviewed. • 6. Rework/follow-up: The Author of the work product (or other assigned person) undertakes whatever actions are necessary to repair defects or otherwise satisfy the requirements agreed to at the Examination meeting. The Review Leader verifies that all action items are closed. • 7. [Exit evaluation]: The Review Leader verifies that all activities necessary for successful review have been accomplished, and that all outputs appropriate to the type of review have been finalised. Copyright © 2007
  2. 2. WWW.UNIVERSALEXAMS.COM ISO/IEC 12207 Software lifecycle processes are methods and standards for improving and mastering development processes, supporting processes and management processes throughout the software lifecycle. The quest for the optimized mix of processes has resulted in different standards throughout the history of software development. One of the latest which was published is the ISO/IEC 12207 standard. This standard was proposed in 1988 and published in August 1995. It was created to establish a common international framework to acquire, supply, develop, operate, and maintain software. ISO/IEC 12207 consists of three types of processes: • • • Primary lifecycle processes; Supporting lifecycle processes; Organizational lifecycle processes. Because the complete ISO/IEC 12207 standard is very elaborate this entry will only explain some, more interesting, parts of the primary lifecycle processes. In this entry the word “product” will be used instead of system, software product or software service. Primary lifecycle processes The primary lifecycle processes contain the core processes involved in creating a software product. These processes are divided into five different main processes: • • • • • Acquisition Supply Development Operation Maintenance In the next chapters the activities and deliverables of the primary lifecycle processes are presented. Because the primary lifecycle processes cover a very large area a scope was defined. This entry explains all the primary lifecycle processes but will explain the processes ‘Acquisition’ and ‘Development’ more extensively. Copyright © 2007
  3. 3. WWW.UNIVERSALEXAMS.COM IEEE 829 IEEE 829-1998, also known as the 829 Standard for Software Test Documentation, is an IEEE standard that specifies the form of a set of documents for use in eight defined stages of software testing, each stage potentially producing its own separate type of document. The standard specifies the format of these documents but does not stipulate whether they all must be produced, nor does it include any criteria regarding adequate content for these documents. These are a matter of judgment outside the purview of the standard. The documents are: Test Plan: a management planning document that shows: How the testing will be done (including SUT configurations). Who will do it What will be tested How long it will take (although this may vary, depending upon resource availability). What the test coverage will be, i.e. what quality level is required Test Design Specification: detailing test conditions and the expected results as well as test pass criteria. Test Case Specification: specifying the test data for use in running the test conditions identified in the Test Design Specification Test Procedure Specification: detailing how to run each test, including any set-up preconditions and the steps that need to be followed Test Item Transmittal Report: reporting on when tested software components have progressed from one stage of testing to the next Test Log: recording which tests cases were run, who ran them, in what order, and whether each test passed or failed Test Incident Report: detailing, for any test that failed, the actual versus expected result, and other information intended to throw light on why a test has failed. This document is deliberately named as an incident report, and not a fault report. The reason is that a discrepancy between expected and actual results can occur for a number of reasons other than a fault in the system. These include the expected results being wrong, the test being run wrongly, or inconsistency in the requirements meaning that more than one interpretation could be made. The report consists of all details of the incident such as actual and expected results, when it failed, and any supporting evidence that will help in its resolution. The report will also include, if possible, an assessment of the impact upon testing of an incident. Test Summary Report: A management report providing any important information uncovered by the tests accomplished, and including assessments of the quality of the testing effort, the quality of the software system under test, and statistics derived from Incident Reports. The report also records what testing was done and how long it took, in order to improve any future test planning. This final document is used to indicate whether the software system under test is fit for purpose according to whether or not it has met acceptance criteria defined by project stakeholders. Copyright © 2007
  4. 4. WWW.UNIVERSALEXAMS.COM ISO 9126 ISO 9126 is an international standard for the evaluation of software. It will be overseen by the project SQuaRE, ISO 25000:2005, which follows the same general concepts. The standard is divided into four parts which addresses, respectively, the following subjects: quality model; external metrics; internal metrics; and quality in use metrics. The quality model established in the first part of the standard, ISO 9126-1, classifies software quality in a structured set of characteristics and sub-characteristics as follows: • Functionality - A set of attributes that bear on the existence of a set of functions and their specified properties. The functions are those that satisfy stated or implied needs. o Suitability o Accuracy o Interoperability o Compliance o Security • Reliability - A set of attributes that bear on the capability of software to maintain its level of performance under stated conditions for a stated period of time. o Maturity o Recoverability o Fault Tolerance • Usability - A set of attributes that bear on the effort needed for use, and on the individual assessment of such use, by a stated or implied set of users. o Learnability o Understandability o Operability • Efficiency - A set of attributes that bear on the relationship between the level of performance of the software and the amount of resources used, under stated conditions. o Time Behaviour o Resource Behaviour • Maintainability - A set of attributes that bear on the effort needed to make specified modifications. o Stability o Analyzability o Changeability o Testability • Portability - A set of attributes that bear on the ability of software to be transferred from one environment to another. o Installability o Replaceability o Adaptability Copyright © 2007
  5. 5. WWW.UNIVERSALEXAMS.COM The sub-characteristic Conformance is not listed above and applies to all characteristics. Examples are conformance to legislation concerning Usability or Reliability. Each quality sub-characteristic (as adaptability) is further divided into attributes. An attribute is an entity which can be verified or measured in the software product. Attributes are not defined in the standard, as they vary between different software products. Software product is defined in a broad sense: it encompasses executables, source code, architecture descriptions, and so on. As a result, the notion of user extends to operators as well as to programmers, which are users of components as software libraries. The standard provides a framework for organizations to define a quality model for a software product. On doing so, however, it leaves up to each organization the task of specifying precisely its own model. This may be done, for example, by specifying target values for quality metrics which evaluates the degree of presence of quality attributes. Internal metrics are those which do not rely on software execution (static measures). External metrics are applicable to running software. Quality in use metrics are only available when the final product is used in real conditions. Ideally, the internal quality determines the external quality and external quality determines quality in use. This standard stems from the model established in 1977 by McCall and his colleagues, who proposed a model to specify software quality. The McCall quality model is organized around three types of Quality Characteristics: • • • Factors (To specify): They describe the external view of the software, as viewed by the users. Criteria (To build): They describe the internal view of the software, as seen by the developer. Metrics (To control): They are defined and used to provide a scale and method for measurement. ISO 9126 distinguishes between a defect and a nonconformity, a defect being The nonfulfilment of intended usage requirements, whereas a nonconformity is The nonfulfilment of specified requirements. A similar distinction is made between validation and verification, known as V&V in the testing trade. Copyright © 2007
  6. 6. WWW.UNIVERSALEXAMS.COM BS 7925-1 BS 7925-1 is a Glossary of Software Testing Terms, along with its partner BS 7925-2 Software component testing. The standard was developed by the Testing Standards Working Party and published in August 1998. This is a volunteer group devoted to the development of new software testing standards and sponsored by the BCS SIGiST (British Computer Society Specialist Interest Group in Software Testing). The standard may be ordered from BSI but it is not cheap. Alternatively, free copies of the latest draft SIGIST standard and an up-to-date 'living' Glossary can be downloaded from the Testing Standards website. BS 7925-2 BS 7925-2 is the Software Component Testing Standard, along with its partner BS 7925-1 which is a Glossary of Software Testing Terms. The standard was developed by the Testing Standards Working Party and published in August 1998. This is a volunteer group devoted to the development of new software testing standards and sponsored by the BCS SIGiST (British Computer Society Specialist Interest Group in Software Testing). The standard may be ordered from BSI but it is not cheap. Alternatively, free copies of the latest draft SIGIST standard and an up-to-date 'living' Glossary can be downloaded from the Testing Standards website. Other standards that may be of interest are: • • • • • • • • • • IEEE 1008, a standard for unit testing IEEE 1012, a standard for Software Verification and Validation IEEE 1028, a standard for software inspections IEEE 1044, a standard for the classification of software anomalies IEEE 1044-1, a guide to the classification of software anomalies IEEE 1233, a guide for developing system requirements specifications IEEE 730, a standard for software quality assurance plans IEEE 1061, a standard for software quality metrics and methodology BSS 7925-1, a vocabulary of terms used in software testing BSS 7925-2, a standard for software component testing Copyright © 2007