|
US$999.00 · In stock
Delivery: <= 7 days. True-PDF full-copy in English will be manually translated and delivered via email.
GB/T 38634.2-2020: Systems and software engineering - Software testing - Part 2: Test processes
Status: Valid
| Standard ID | Contents [version] | USD | STEP2 | [PDF] delivered in | Standard Title (Description) | Status | PDF |
| GB/T 38634.2-2020 | English | 999 |
Add to Cart
|
7 days [Need to translate]
|
Systems and software engineering - Software testing - Part 2: Test processes
| Valid |
GB/T 38634.2-2020
|
PDF similar to GB/T 38634.2-2020
Basic data | Standard ID | GB/T 38634.2-2020 (GB/T38634.2-2020) | | Description (Translated English) | Systems and software engineering - Software testing - Part 2: Test processes | | Sector / Industry | National Standard (Recommended) | | Classification of Chinese Standard | L77 | | Classification of International Standard | 35.080 | | Word Count Estimation | 54,578 | | Date of Issue | 2020-04-28 | | Date of Implementation | 2020-11-01 | | Quoted Standard | GB/T 38634.1; GB/T 38634.4; ISO/IEC/IEEE 12207-2017 | | Adopted Standard | ISO/IEC/IEEE 29119-2-2013, MOD | | Issuing agency(ies) | State Administration for Market Regulation, China National Standardization Administration | | Summary | This International Standard specifies a testing process for the governance, management and implementation of software testing of any organization, project or smaller scale testing activity, specifies a general process for software testing, and specifies supporting infographics describing the process. This standard applies to testing in all software life cycle models. This standard applies to, but is not limited to, testers, test managers, developers and project managers, especially those responsible for the governance, management and implementation of software testing. | GB/T 38634.2-2020: Systems and software engineering - Software testing - Part 2: Test processes---This is a DRAFT version for illustration, not a final translation. Full copy of true-PDF in English version (including equations, symbols, images, flow-chart, tables, and figures etc.) will be manually/carefully translated upon your order.
Systems and software engineering - Software testing - Part 2.Test processes
ICS 35.080
L77
National Standards of People's Republic of China
System and software engineering software testing
Part 2.testing process
2020-04-28 released
2020-11-01 implementation
State Administration for Market Regulation
Issued by the National Standardization Management Committee
Table of contents
Foreword Ⅰ
Introduction Ⅲ
1 Scope 1
2 Compliance 1
2.1 Intended use 1
2.2 Full compliance 1
2.3 Tailoring compliance 1
3 Normative references 1
4 Terms and definitions, abbreviations 2
4.1 Terms and definitions 2
4.2 Abbreviations 8
5 Multi-layer test process model 8
6 Organizational testing process 10
6.1 Overview 10
6.2 Organizational testing process 11
7 Test management process 13
7.1 Overview 13
7.2 Test planning process 14
7.3 Test monitoring and control process 18
7.4 Test completion process 20
8 Dynamic test process 22
8.1 Overview 22
8.2 Test Design and Implementation Process 23
8.3 Test environment construction and maintenance process 27
8.4 Test execution process 28
8.5 Test event reporting process 30
Appendix A (informative appendix) Some examples of test design process 32
Appendix B (Normative Appendix) Process mapping between this part and ISO /IEC /IEEE12207.2017 34
Appendix C (informative appendix) Process mapping between this part and ISO /IEC /IEEE15288.2015 40
Appendix D (informative appendix) Process mapping between this part and ISO /IEC 17025.2017 41
Appendix E (informative appendix) Process mapping between this part and GB/T 25000.51-2016 42
Appendix F (informative appendix) Process mapping between this part and GB/T 15532-2008 43
Appendix G (informative appendix) Process mapping between this part and IEEE1008-2008 45
Appendix H (informative appendix) Structural changes in this part compared with ISO /IEC /IEEE29119-2.2013 47
Reference 49
System and software engineering software testing
Part 2.testing process
1 Scope
This part of GB/T 38634 specifies the software testing for governance, management and implementation of any organization, project or smaller-scale testing activities.
The testing process of the test defines the general process of software testing, and gives a supporting information chart describing the process.
This section applies to all tests in the software life cycle model.
This section applies to but not limited to testers, test managers, developers and project managers, especially those responsible for governance, management and implementation of software testing personnel.
2 Compliance
2.1 Intended use
The requirements of this section are contained in Chapter 6 ~ Chapter 8.This section provides requirements applicable to many testing processes throughout the software life cycle.
A specific project or organization may not need to use all the processes defined in this section, so the implementation of this section usually involves choosing one
Groups apply to the process of an organization or project. Organizations can declare compliance with this section in two ways.
The organization shall declare whether it is completely or tailored in accordance with this section.
2.2 Full compliance
Full compliance is achieved by proving that all requirements of the entire process defined in this section (ie. should be declared) are achieved.
2.3 Tailoring compliance
When this section is used to establish a set of process foundations that do not meet full compliance, record a subset of the process of tailoring compliance. Pass the proof
All the requirements of the recorded process subset (ie. should be declared) have been met to achieve tailoring compliance.
When tailoring, as long as the process specified in Chapter 6, Chapter 7, and Chapter 8 of this part is not followed, justifications should be provided (directly or through
Reference). All tailoring decisions should document their reasons, including consideration of any applicable risks. Tailoring decisions should be approved by stakeholders.
Example. If the organization follows the information item management process in standards such as ISO 15489 or GB/T 19001 or uses similar internal organizational processes, they can
It was decided to use these processes instead of the information item management tasks defined in this section.
3 Normative references
The following documents are indispensable for the application of this document. For dated reference documents, only the dated version applies to this article
Pieces. For undated references, the latest version (including all amendments) applies to this document.
GB/T 38634.1 System and Software Engineering Software Testing Part 1.Concepts and Definitions (GB/T 38634.1-2020, ISO /IEC /IEEE29119-1.2013, MOD)
GB/T 38634.4 System and Software Engineering Software Testing Part 4.Testing Technology (GB/T 38634.4-2020, ISO /IEC /IEEE29119-4.2015, MOD)
ISO /IEC /IEEE12207.2017 System and Software Engineering Software Life Cycle Process
4 Terms and definitions, abbreviations
4.1 Terms and definitions
The following terms and definitions apply to this document.
4.1.1
results of testing
The behavior and state set of the test item, or related data, and the state set of the test environment can be obtained as the result of test execution.
Examples. output to hardware, changes to data, generation and display of reports, and sending of communication messages.
4.1.2
Completion criteria
The conditions for the completion of the test activity.
4.1.3
Coverage item
See test coverage item (4.1.33).
4.1.4
Dynamic Testing
Need to run the test of the test item.
4.1.5
Equivalence class
A subset of the range of a variable or variable set. In the test item or its interface, it is expected that the test item will handle all in the subset in the same way.
Some values (that is, considered "equivalent").
4.1.6
Equivalence category coverage
The test set covers the proportion of identified equivalence classes in the test items.
Note. In many cases, the equivalence class identification is subjective (especially in the "invalid" equivalence class), so it is not possible to explicitly count the equivalence class of the test item
can.
4.1.7
Equivalence class division
A type of test design technique. Use one or more representative members of each equivalence class to design test cases.
4.1.8
expected results
According to specifications or other sources, the expected behavior of the test item that can be obtained under specific conditions.
4.1.9
Exploratory test
An experience-based test. Testers based on their existing relevant knowledge and preliminary exploration of test items (including previous test results)
As well as heuristic "rules of thumb" about common software behavior and failure types, tests are designed and executed spontaneously.
Note. Exploratory testing looks for hidden attributes (including hidden behaviors).Although the possibility of its own harm is very small, it may interfere with other aspects of the software under test.
Other attributes, and therefore the risk of software failure.
5 Multi-layer test process model
This part divides the test activities that may be performed in the system and software life cycle into three process groups, as shown in Figure 1.In these groups
Each process is described in accordance with its purpose and expected results, and lists the activities and tasks that need to be performed. Tests in this section
See Appendix B for the process mapping of ISO /IEC /IEEE12207.2017.
6.2.3 Results
The results of the successful implementation of the organizational testing process include.
a) Determine the requirements for organization-level test specifications;
b) Develop organization-level test specifications;
c) Stakeholders agree to organization-level test specifications;
d) Organizational test specifications can be obtained;
e) Supervise compliance with organization-level test specifications;
f) Stakeholders agree to the update of organization-level test specifications;
g) Update organization-level test specifications.
6.2.4 Activities and tasks
6.2.4.1 Overview
The personnel responsible for organization-level test specifications shall perform the following activities and tasks in accordance with the organization-level policies and corresponding procedures applicable in the organization-level test process.
6.2.4.2 Development organization level test specification (OT1)
This activity includes the following tasks.
a) The requirements of organization-level test specifications should be identified from the current test practices and stakeholders in the organization, and/or developed through other means;
Note. It can be achieved by analyzing relevant source documents, through seminars, interviews or other suitable methods.
b) The requirements of organization-level test specifications should be used in the formulation of organization-level test specifications;
c) The content of organization-level test specifications should be agreed by stakeholders;
d) Communicate available organization-level test specifications to stakeholders in the organization.
6.2.4.3 Monitoring and controlling the use of organization-level test specifications (OT2)
This activity includes the following tasks.
a) The use of organization-level test specifications should be monitored to determine whether they are effectively used within the organization;
b) Appropriate measures should be taken to encourage the behavior of stakeholders to be consistent with the requirements of the organization-level test specifications.
6.2.4.4 Update organization-level test specifications (OT3)
This activity includes the following tasks.
a) The use feedback of the organization-level test specification should be reviewed;
b) The effectiveness of the use and management of organization-level test specifications should be considered, and any feedback and changes that improve their effectiveness should be determined and approved;
Note. This can be achieved through review feedback, seminars, interviews and other appropriate methods.
c) If changes to the organization-level test specifications have been identified and approved, these changes should be implemented;
d) All changes to organization-level test specifications should be communicated throughout the organization, including all stakeholders.
6.2.5 Information items
By performing this process, the following information items will be generated.
a) Organization-level test specifications.
Examples. Organizational testing policy, organizational testing strategy.
7.2.2 Purpose
The purpose of the test planning process is to determine the scope and methods of the test, and to reach a consensus with stakeholders in order to identify test resources,
Test environment and other requirements.
7.2.3 Results
The results of the successful implementation of the test planning process include.
a) Analyze and understand the scope of testing;
b) Identify and notify the stakeholders participating in the test plan;
c) According to the specified risk exposure level, risks can be identified, analyzed and classified through testing;
d) Determine the test strategy, test environment, test tools and test data requirements;
Example 1.Tools, special equipment, test environment, office space.
e) Determine staffing and training needs;
f) Arrange every activity;
g) Calculate the estimate and record the evidence supporting the estimate;
Example 2.Estimated cost, personnel and timetable.
h) The test plan is agreed and distributed to stakeholders.
7.2.4 Activities and tasks
7.2.4.1 Overview
The person in charge of the test planning shall execute the corresponding activities and tasks in accordance with the organization-level policies and procedures.
7.2.4.2 Understanding the context (TP1)
This activity includes the following tasks.
a) Understand the context and software testing requirements to support the preparation of test plans;
Note 1.Software testing requirements include the identification of test items.
Note 2.The following documents can be used.
1) Organization-level test specifications, such as organization-level test policies and organization-level test strategies;
2) The information in the project management plan that affects the test, such as the allocated test budget and resources;
3) A higher-level test plan (for example, if you manage lower-level tests, such as system testing, then the project test plan) to meet
The requirements and constraints of this level of testing, such as test estimates, staffing, expected deliverables and their timing;
4) Regulatory standards applicable to regulatory information that may affect testing;
5) Applicable product documents, such as system requirements specifications, quality objectives for system quality characteristics descriptions, and test item specifications to obtain
Take information about possible test requirements related to this stage or test type;
6) The quality characteristics are defined in GB/T 25000.10-2016;
7) The software development plan is used for information that may affect the test schedule or cycle, such as expected development deliverables and their timing;
8) Project risk registration to obtain information on identified project and product risks;
9) Verify and confirm the plan.
b) Understand the context and software testing requirements, which should be obtained through identification and communication with stakeholders;
c) A communication plan should be developed and the communication method should be recorded.
Note 3.Understanding context activities will run through the entire project life cycle. In principle, the tasks in this activity can be performed in any order.
7.2.4.3 Organize test plan development (TP2)
This activity includes the following tasks.
a) According to the test requirements determined in the understanding context (TP1) activity, the activities required to complete the test plan should be identified and arranged;
b) The stakeholders needed to participate in these activities should be determined;
c) Stakeholders should obtain agreement on activities, progress and participants;
Example 1.Project manager and/or project test manager.
Note. This may require repeated execution of task a) and task b).
d) Stakeholder participation should be organized.
Example 2.Ask the project manager to arrange a meeting to review the test strategy.
7.2.4.4 Identify and analyze risks (TP3)
This activity includes the following tasks.
a) The previously determined risks should be reviewed to determine the risks related to software testing and/or the risks that can be handled by software testing;
Example 1.Risks in the project risk register.
b) Other risks related to software testing and/or that can be handled through software testing should be determined;
Note 1.Any identified risks not related to software testing should be communicated to stakeholders.
Note 2.The product specifications and other appropriate documents can be reviewed through seminars, interviews or other appropriate methods.
c) Risks should be classified using an appropriate classification scheme, which at least distinguishes project and product risks;
d) The exposure level of each risk should be determined (e.g. by considering its impact and likelihood);
e) The results of the risk assessment should be approved by stakeholders;
f) The results of this risk assessment should be recorded.
Example 2.Recorded in the test plan or project risk register.
7.2.4.5 Determine risk mitigation methods (TP4)
This activity includes the following tasks.
a) Determine the appropriate risk treatment method according to the risk type, risk level and risk exposure level;
Note. Appropriate methods can include test phases, test types, test design techniques, test completion criteria, etc. Practitioners can consider ISO /IEC 15206
Or the concept of software risk degree contained in IEEE1012.2012.When the constraints of the test (such as time and cost) are known,
The risk mitigation of the low risk exposure level that is expected to be unmanageable under the constraints will be considered beyond the scope of the cause.
b) The results of risk mitigation should be recorded.
Example. Recorded in the test plan or project risk register.
7.2.4.6 Design test strategy (TP5)
This activity includes the following tasks.
a) Resources should be provided for the requirements defined in the organization-level test specifications (e.g., organization-level test strategy and organization-level test policy)
Preliminary estimate. The constraints imposed on the project by higher-level testing strategies should be considered.
Note 1.Focus on the estimation of workload and time required.
b) A preliminary estimate should be made of the resources required to determine the various mitigation measures identified in the risk mitigation method (TP4) activity, and the
The risk with the highest risk level identified in the risk analysis (TP3) activity begins.
Note 2.Focus on the estimation of workload and time required.
c) Test strategies should be designed (including test phases, test types, features to be tested, test design techniques, test completion criteria, suspension and resume
Review criteria), and consider the test basis, risks, organization, project and product restrictions.
Note 3.This takes into account the level of risk exposure to prioritize testing activities, initial test estimates, and resources required to perform operations (e.g. skills, tool support, etc.)
Support and environmental requirements) and organizational, project and product restrictions, such as.
1) Regulatory standards;
2) Organization-level test policy, organization-level test strategy, and project test plan requirements (such as designing test strategies for lower-level tests);
3) Contract requirements;
4) Project time and cost constraints;
5) Testers with appropriate skills;
6) Availability of tools and environment;
7) Technology, system or product limitations.
If it is impossible to design and implement the test strategy required by the organization-level test strategy, and deal with all the existing
Recommendations to identify risks require judgment to reach the best strategy to meet these conflicting requirements. How to achieve this compromise will be
Depends on the project and organization, and may need to relax constraints, repeat the determination of risk mitigation methods (TP4) activities and tasks a) ~ c) until it is achieved
Acceptable testing strategy. If you decide to deviate from the organization-level test strategy, it should be recorded in the test strategy.
Note 4.Test strategies usually involve static testing (such as review, review, static analysis) and dynamic testing.
d) The indicators for test monitoring and control should be determined (see activities TMC1~TMC4).
e) The test data should be determined.
Example. When determining test data, you need to consider data privacy regulations (such as data shielding or encryption), the amount of data required, and the data cleanup after completion.
f) The test environment requirements and test tool requirements should be determined.
g) The test deliverables should be determined, and the degree of formality and frequency of communication should be recorded.
h) A preliminary estimate should be made of the resources required to execute the complete set of operations described in the test strategy.
Note 5.The preliminary test estimates generated in this step will be finalized in the preparation of the test plan (TP7) activity.
i) The test strategy should be documented.
Note 6.The test strategy is usually part of the test plan, but in some cases, it can be recorded as a separate document.
j) Agree on the testing strategy should be obtained from stakeholders.
Note 7.This may require repeating earlier tasks in this activity.
7.2.4.7 Determine staffing and scheduling (TP6)
This activity includes the following tasks.
a) The roles and skills of the staff performing the test described in the test strategy should be determined;
Note 1.It may be necessary to determine personnel recruitment and/or training needs.
b) Each required test activity in the test strategy should be arranged according to estimates, dependencies and availability of personnel;
c) The staffing and scheduling agreement should be obtained from stakeholders.
Note 2.This may require repeated tasks a) and b), if the test strategy needs to be revised, you need to re-design the test strategy (TP5) activities.
7.2.4.8 Write test plan (TP7)
This activity includes the following tasks.
a) The final estimate of the test should be based on the test strategy designed in the design test strategy (TP5) activity, and the staffing and adjustment
Calculate the staffing and time arrangement agreed in the degree (TP6) activities;
Note. If these are inconsistent with the previous preliminary estimates, you may need to reconsider determining staffing and scheduling (TP6) and/or design test strategies.
(TP5) activities.
b) The test strategy determined in the design test strategy (TP5) activity should be agreed upon in the staffing and scheduling (TP6) activity
The personnel profile and schedule, and the final estimate calculated in the previous task are included in the test plan.
7.2.4.9 Obtain the conformance test plan (TP8)
This activity includes the following tasks.
a) The opinions of stakeholders on the test plan should be collected;
Note 1.This can be achieved through seminars, interviews or other appropriate means.
b) Disagreements between the test plan and the opinions of stakeholders should be resolved;
c) The test plan should be updated based on feedback from stakeholders;
Note 2.This may require repetition of early activities in the test planning process.
d) Approval of the test plan should be obtained from stakeholders.
Note 3.This may require repeating tasks a)~c).
7.3.2 Purpose
The purpose of the test monitoring and control process is to determine whether the test progress can be in accordance with the test plan and organization-level test specifications
Organization level testing policy, organization level testing strategy). It also initiates control operations as needed and determines necessary updates to the test plan (e.g.
Modify the completion criteria or take new measures to make up for the deviation of the test plan).
This process can also be used to determine whether the test schedule is in line with a higher-level test plan, and to manage the
Test) or a specific type of test (for example, performance test).
7.3.3 Results
The results of the successful implementation of the test monitoring and control process include.
a) Establish collection methods for monitoring test progress and appropriate measures of risk changes;
b) Monitor the progress of the test plan;
c) Identify and analyze new and changed risks related to testing, and take necessary measures;
d) Determine the necessary control measures;
e) Communicate necessary control measures to stakeholders;
f) Approve the decision to stop testing;
g) Report test progress and risk changes to stakeholders.
7.3.4 Activities and tasks
7.3.4.1 Overview
The person in charge of test monitoring and control shall perform the following activities and procedures in accordance with applicable organizational policies and procedures related to the test monitoring and control process.
task.
7.3.4.2 Preparation (TMC1)
This activity includes the following tasks.
a) If the test plan or organization-level test strategy has not yet defined test measures, appropriate test measures should be determined to monitor the test plan
The progress;
b) If the test plan or organization-level test strategy has not yet defined these methods, appropriate methods for new and changed risks should be determined;
c) Monitoring activities such as test status report and test measurement collection should be established to collect the above tasks a)~b) as well as test plans and
The test measures determined in the organization-level test strategy.
7.3.4.3 Monitoring (TMC2)
This activity includes the following tasks.
a) Test measures should be collected and recorded;
b) The collected test measures should be used to monitor the progress of the test plan;
Example 1.By reviewing the test status report, analyzing the test measurement and holding meetings with stakeholders.
c) The differences from the planned test activities should be identified, and any factors that hinder the progress of the test should be recorded;
d) New risks should be identified and analyzed to determine the risks that need to be mitigated through testing, and those that need to be communicated with stakeholders.
risk;
e) Changes in known risks should be monitored to determine the risks ...
Tips & Frequently Asked Questions:Question 1: How long will the true-PDF of GB/T 38634.2-2020_English be delivered?Answer: Upon your order, we will start to translate GB/T 38634.2-2020_English as soon as possible, and keep you informed of the progress. The lead time is typically 4 ~ 7 working days. The lengthier the document the longer the lead time. Question 2: Can I share the purchased PDF of GB/T 38634.2-2020_English with my colleagues?Answer: Yes. The purchased PDF of GB/T 38634.2-2020_English will be deemed to be sold to your employer/organization who actually pays for it, including your colleagues and your employer's intranet. Question 3: Does the price include tax/VAT?Answer: Yes. Our tax invoice, downloaded/delivered in 9 seconds, includes all tax/VAT and complies with 100+ countries' tax regulations (tax exempted in 100+ countries) -- See Avoidance of Double Taxation Agreements (DTAs): List of DTAs signed between Singapore and 100+ countriesQuestion 4: Do you accept my currency other than USD?Answer: Yes. If you need your currency to be printed on the invoice, please write an email to [email protected]. In 2 working-hours, we will create a special link for you to pay in any currencies. Otherwise, follow the normal steps: Add to Cart -- Checkout -- Select your currency to pay.
|