Test Architect Training: 5 Test Strategy Practical Introduction

Test Architect Training: 5 Test Strategy Practical Introduction

2016-09-06

Directory

1 start
2 first-time use of the "four-step Test strategy Formulation Act"
2.1 Product Quality Grade
2.2 Determine the quality level of each feature in the project
2.3 Risk analysis of the project as a whole
2.4 Determining the structure of the test strategy
2.5 Preliminary determination of test layering
2.6 Reviews
3 Developing the overall test strategy
3.1 Decomposition of product quality objectives
1. Decomposition of product quality objectives according to quality level
2. Determine test objectives for each test hierarchy
3.2 Using the old functional analysis method to classify the characteristics
3.3 Determine test depth and test breadth based on quality and risk
1. Use the product quality assessment model to determine the test depth initially
2. Consider updating the test depth with old functional analysis
3. Based on the old function analysis to determine the test breadth preliminarily
3.4 Determining the test priority
3.5 Determining the overall framework for testing
3.6 Reviews
4 Developing a Phase test strategy
4.1 Test Design Strategy
1. Use the test Analysis Design table to ensure that the test design conforms to the test strategy
2. Four-Step test design method and test breadth
3. Test Case Level
4.2 Integrated Test Strategy
1. Integrated development of the "Tetris Heart" project
2. Objects and test targets for integration testing
3. Entry criteria-when you can start the integration test
4. Test Case Selection
5. Export guidelines
4.3 System test Strategy
1. Objects and test targets for system testing
2. Entry criteria-when a system test can be carried out
3. Test Case Selection
4. Test Execution order
5. Export guidelines
4.4 Acceptance Testing Strategy
1. Alpha Test
2. Beta testing
3. Entry criteria-When to begin acceptance testing
4. Export guidelines-When you can exit the test, release the product
4.5 Reviews

Let's say we have a research and development project a started, and our software test architects are going to be involved in the project. At this point the package requirements of the project products have been basically completed, the product concept has been initially molded, 1 shows.

Figure 1 Development Project A

However, the software Test architect's knowledge of the project is very limited at this point:

• Know what the project name is.
• What the project is going to do roughly.
• What time does the leader expect the project to end.

1 start

Return

At this point, the software Test architect has very limited knowledge of the project, and it is important to gather more information about the project before developing a test strategy:

• The scope of the project.
• Human input.
• Historical situation.
• ......

2 first-time use of the "four-step Test strategy Formulation Act"

Return

Once we have collected some project information and have a certain understanding of the project, we are ready to develop a test strategy. This is also the first time we have used the "four Step Test strategy formulation" method in the project, 2 shows.

Figure 2 Using the "Four Step Test strategy formulation method" for the project

2.1 Product Quality Grade

Product quality assessment model, can only tell us from which angle to evaluate the quality of products, and did not tell us, how the evaluation results can be considered to be good quality, how the results are bad quality. In other words, we also lack a "scale" of evaluation quality, that is, product quality level.

From the perspective of end-user use, we divide the product quality into the following 4 levels.

• Level 1th Fully commercial: Features fully meet the needs of users, there are a small number of (or no) legacy problems, users without any restrictions.
• 2nd-Class Limited commercial: The characteristics can not meet the user's specific scenarios, there are more than ordinary legacy problems, but there are circumvention measures.
• 3rd level test, demo or small scope trial: Features can only meet the user part of the requirements, there are serious problems left over, and no effective circumvention measures, the problem will affect the use of users, can only be used for testing (such as beta) or demonstration, or a small range of trial.
• 4th level can not be used: the characteristics can not meet the needs of users, there are serious legacy problems, will lead to user basic function failure, and no circumvention measures, the product can not be used at all.

Note: Although the product quality level is determined at the beginning of the project, it defines the quality of the product at the time of release, not the quality of the product during the testing process, as shown in 3

Figure 3 Defining quality at the time of product release

2.2 Determine the quality level of each feature in the project

In accordance with the four-step test strategy formulation method, we first focus on defining product quality objectives to conduct analysis

At this point, the software Test architect needs to determine their "product quality level" (table 1) for the features contained in this project.

What needs to be specifically stated are:

• The premise that the activity can be carried out smoothly is that the characteristics of the product have been basically finalized.
• This activity should not be performed by software test architects alone, but will require the development of a core team of engineers, research and development managers, to agree on the quality level of the products of different characteristics.

2.3 Risk analysis of the project as a whole

In accordance with the four-step test strategy formulation, at this stage, the software test architect needs to conduct risk analysis from the overall perspective of the project.

At this point, we can follow the "Risk assessment Checklist" described in section 7.1 to conduct a risk assessment of the project as a whole, and refer to the "risk response" to consider the response and add some quality assurance activities.

When determining the risk response, it is necessary to distinguish whether these activities are targeted at the project as a whole or specific to the particular characteristics. Can be recorded directly in the Product Quality Rating table Memo (table 1).

Table 1 Product Quality Rating table

2.4 Determining the structure of the test strategy

Following the four-step test strategy formulation, we will analyze the product development process around.

Figure 4 The test strategy structure of the total score

• Overall test strategy: Determine product quality objectives, the overall project risk identification, from the product level to determine the test focus and testing difficulties, testing depth and testing breadth, is the general principles of the Test strategy.
• Phase Test strategy: Determine the quality objectives that the test design strategy and test execution strategy need to achieve (decomposition of the product quality objectives) and the entry criteria that are capable of conducting these test activities.
• Test execution strategy: Determine the test target, test content, and entry criteria for each version of each release.

The overall test strategy begins at the conceptual stage and is more appropriate in the early stages of the planning phase. Because the requirements, quality objectives and overall shape of the product have been determined, there are conditions for developing an overall test strategy, and such a document is required to lead the Test team to the next testing activity.

The phase test strategy is expanded after the overall test strategy is complete and is guaranteed to be completed early in the development phase. This is because the most important goal of the phase test strategy is to identify the input and output standards for each stage. Before the development of coding (or in the early) to clarify the requirements, can make the development goals more clear, more conducive to product quality improvement. Tests can also be prepared to receive test cases, automated test environments, and so on, based on the standards reached by both parties. If the phase test strategy is output too late, these activities may not work or achieve the desired results.

The test execution strategy is output before each version goes to test during the test execution phase. In addition to the granularity of the test execution strategy, which is further decomposed into each version, the test strategy needs to be adjusted based on the test execution of the previous release.

Figure 5 The relationship between various test strategies

2.5 Preliminary determination of test layering

Following the four-step test strategy formulation, we will proceed with the analysis related to the test layering .

For software Test Architects, we can initially identify a test hierarchy by combining the development process. Let's say we take the test layering in the classic V model, and then put the test layering and development process, and the structure of the test strategy on a graph, to sort out the correspondence between the three.

Figure 6 The correspondence between the test hierarchy, the development process, and the test strategy structure

2.6 Reviews

Let's summarize what progress has been made by the software testing architect so far:

• Define the quality level of the feature and agree on quality objectives with members of each research and development core team.
• From the overall perspective of the project risk analysis, with the need to do what quality assurance activities of the preliminary plan.
• Determine the structure of the test strategy for the overall test strategy-phase test strategy-Test execution strategy.
• The test layering is preliminarily determined, and the corresponding relationship between the test layering, the development process and the test strategy structure is identified, and a test framework is established.

Through this practice, we find that only a four-step test strategy is used, and the final Test strategy is not available.

First, this relates to the stage in which the project is located. Some of the necessary and important information related to the development of test strategies will be clear only at certain stages of the project, so we need to use the four-step test strategy formulation method at different stages of the project to develop a test strategy, as shown in 7, according to the structure of the test strategy.

Figure 7 Making a test strategy using four-step test strategy development method multiple times

Secondly, the 4 steps in the four-step test strategy-making method are not a one-way cascade relationship, but a full-mesh bidirectional relationship. Figure 8 is a more accurate representation of the relationship between these 4 nodes.

Fig. 8 Relationship between 4 nodes

For example, product quality objectives have become higher, and we may have added some test tiers, which has led to changes in the development process and introduces new risks.

So when we were using the four-step test strategy, we found that we couldn't go any further, we could stop this step, take the next step, and then go back to the unfinished steps, and there will always be new gains.

3 Developing the overall test strategy

Return

We will then use the four-step test strategy formulation method to develop the overall test strategy, as shown in 9, on the basis of the previous analysis.

Figure 9 Developing the overall test strategy

3.1 Decomposition of product quality objectives

We can then decompose the quality level, as shown in the overall idea 10.

Figure 10 Decomposition Quality level

1. Decomposition of product quality objectives according to quality level

We can establish different quality standards for the projects in the product quality evaluation model according to the product quality level previously determined, so as to achieve the purpose of decomposing the product quality objectives.

According to the actual situation of the project, historical situation and the company's overall baseline, to determine a grading criteria, as the product quality objectives of the decomposition, see table 2.

Table 2 Classification criteria for quantitative indicators

Note:

• "Not involved" means that the item can be disregarded;
• Some analysis items can be selected according to the actual situation of the project and product.

Table 3 characteristics-Quality Rating table

Instead of outputting a quality target decomposition table for each feature, the software Test architect adds a hyperlink to the attribute-quality level table.

2. Determine test objectives for each test hierarchy

Next we need to determine the quality objectives to be met for each test layering, based on the quality objectives of each quality level. Take "full commercial" as an example, see table 4.

Table 4 full Commercial sample tables

3.2 Using the old functional analysis method to classify the characteristics

At this stage, development has not yet begun to design features, so we cannot use the old functional analysis method to analyze each feature in detail, but we have basically been able to know:

• Which features are newly developed.
• Which is inherited from the old version.
• The changes to which features are estimated to be relatively large.
• Historical testing of features inherited from older versions.

At this point, the software Test architect can consider the above aspects according to the actual situation of the project, to classify the objects under test and to determine a testing strategy for each class. Table 5 is an example for everyone to refer to.

Table 5 Examples

3.3 Based on quality and risk to determine test depth and test breadth 1. Use the product quality assessment model to determine the test depth initially

We use the test process in the product quality assessment model-the test method item-to determine the test depth based on the different quality requirements, as shown in table 6.

Table 6 determining the test depth

2. Consider updating the test depth with old functional analysis

We will then update the test depth in the old function according to the test strategy in the previous old function analysis (consider marking the place to be adjusted first), see table 7.

Table 7 update the test depth in the old function

3. Based on the old function analysis to determine the test breadth preliminarily

From the perspective of product quality assessment model, whether the quality requirements of the product is high or low, we want to be able to test the requirements of 100% coverage, the corresponding test breadth should be 100% coverage.

But in fact, for some of the old features, especially those that have not changed in the new version, and the historical test situation is also a good feature, we can consider narrowing the scope of the test, less testing or contingency. But after all, we are still at the beginning of the concept or planning phase of the project, and we have not done a detailed analysis of the old function, but we can still analyze some features that can narrow down the test scope.

3.4 Determining the test priority

The software Test architect can then determine the test priority based on the quality objectives and classification. The basic principle is that the higher the quality level, the higher the priority, and the higher priority of the new features in the same quality class than the old one, and the more old the changes, the higher the priority.

An easy way to determine the test priority is to use the scoring table. We first set a certain score for quality objectives and classifications, as shown in table 8 and table 9.

Table 8 Quality Goal score table

Table 9 Quality Goal score table

Then prepare a Priority score range table (table 10).

The identified test priorities will be used primarily for the scheduling of test inputs. We can develop a strategy for testing inputs based on the priority level, as shown in table 11.

3.5 Determining the overall framework for testing

The test framework can be understood as how to build a test.

We build the test framework into three layers: the strategy layer, the activity layer, and the assurance layer.

If the test as a whole as a "person":

• The strategy layer is like the human brain, which is responsible for directing the test to make sure the test is doing the right thing;
• The activity layer is like the human body, responsible for the specific implementation;
• The guarantee layer is like the facial features of the person, ensuring the body can carry out the task smoothly.

We draw the test strategy and test activity according to the test framework, and organize the sequencing of these test activities according to the development process and the test hierarchy as the overall framework for testing, as shown in 11.

Figure 11 Testing the overall framework

3.6 Reviews

Let us recall the progress we have made so far:

• Decomposition of product quality objectives.
• The characteristics are categorized based on risk.
• The test input strategy was determined by determining the depth and breadth of testing and the priority of the test.
• The overall framework for testing was determined.

In fact, for now, we can assume that the software test architect has completed the overall test strategy formulation.

What is the final output of the overall test strategy? is actually two tables and a picture.

The first table is the one that we have been blurring in the text as a "feature-quality grade" table and constantly adding content to it. Now we can finally justify it-in fact its real name is "The overall Test strategy analysis table."

Table 12 overall test strategy analysis table

The second table is the test Input strategy table, see table 13.

The final figure is the overall framework of our test, as shown in Figure 12.

Figure 12 Testing the overall framework

4 Developing a Phase test strategy

Return

Figure 13 Developing a phase test strategy

Software Test architects are basically "single-player" when formulating their overall testing strategy, and perhaps only software test architects are involved in the entire Test team. By the time the test strategy is developed, other members of the Test team will begin to invest in the test analysis and design. Therefore, the phase test strategy needs to be able to undertake the overall test strategy, immediately guide the test analysis and design, down to guide the subsequent test execution.

4.1 Test Design Strategy

In formulating the overall test strategy, the software Test architect has determined the test depth for the product features. However, the test depth is described from the point of view of the test method, we do not follow the test method to test the test execution, but follow the test case to test. That is, we need to test the design according to the depth of the test, and then we execute the test cases to achieve the purpose of testing execution with a specific depth of test.

1. Use the test Analysis Design table to ensure that the test design conforms to the test strategy

The Test Analysis Design table is an aid to the test design of each function or feature, and the benefits of using the test analysis table are:

• The software Test architect can control the depth of the test design by configuring the Test Analysis Readiness table.
• The Test designer is able to record the test analysis process very conveniently in the table.
• It is easy for the reviewer to see where the designer is considering what to consider and whether the depth of consideration is appropriate.

The Test Analysis design table consists of 3 tables: The Test Analysis Preparation table, the Test Type Analysis table, and the Functional Interaction Analysis table.

1) Test Analysis Preparation Table

The primary role of the Test analysis Readiness table is to configure what "Test Types" (which can be understood as test methods, including functional and non-functional aspects) and "functional interactions" to be considered in the test design (which can be understood as what features need to be considered together, whether they require "multi-run interactions" and " Multiple run Order Execution "test).

Figure 14 Example

Figure 14 is an example. For example, this configuration means:

• The subjects need to consider test points from features, configuration, consistency, security, performance, pressure, stability, compatibility, upgrades, backup, ease of use.
• The tested objects need to be combined with security features, VLANs and other functions to consider test points.

The software Test architect can control the depth of the test by configuring the Test Analysis Readiness table.

2) Test Type analysis Table

The Test Type Analysis table is shown in 15.

Figure 15 Test Type Analysis table

The "columns" are the requirements to be analyzed, and "row" is the test type. As for the type of test in the row header, this is related to the configuration of the test Type table in the Test Analysis preparation table-we only test type analysis for the configured test type.

Figure 16 Reference example

Figure 17 Summary Table of analysis results

3) Function Interaction Analysis Table

The functional Interaction Analysis table and the test Type Analysis table are similar, as shown in 18.

The functionality that is displayed in the rows header that requires functional interaction analysis remains consistent with the development characteristics table in the Test Analysis preparation table. The "column" content is not "original requirements", but the test type after the end of the analysis, we identified the need for functional interaction analysis of the test point.

Figure 18 Functional Interaction Analysis Table

Figure 19 Reference example

2. Four-Step test design method and test breadth

Test Analysis Design Table output test points, after the completion of the test analysis activities, testing designers can use the four-step test design method to test the experimental design, output test cases.

At this point, a software test architect is required to develop a path coverage strategy in a test design

The basic method of path coverage assessment is described earlier, and we can refer to steps 1 and 2 to define different path coverage strategies with the priority of the overall test strategy, as shown in Table 14.

Table 14 defining path override policies with precedence

3. Test Case Level

After designing the test case, it is recommended that the software Test architect let the test designer sub-subordinate the test case. I am used to dividing test cases into four levels, each level of definition, corresponding test depth and corresponding test analysis design table, see table 15.

Table 15 test Case ratings

The test case grading will provide a great convenience for the subsequent layering, regression, acceptance, and automated testing in how to choose use cases.

4.2 Integrated Test Strategy

Integration testing is in the development phase of the product development process. The so-called "integration", can be understood as the continuous development of functions and integration of functions into the system, the final completion of the entire system development process.

1. Integrated development of the "Tetris Heart" project

Suppose the user wants us to develop a product called "Tetris Heart", as shown in 20.

Figure 20 Tetris Heart

Through analysis, development quickly divides the product into the following basic functions, shown in 21.

Figure 21 Basic functions

and developed through 4 build to the function of the development of 22 is shown.

Figure 22 Feature development and system integration plan

This way, after each build, the product's integration pattern is shown in 23.

Figure 23 Integrated form of the product

Once the 4 build is complete, our system is fully integrated.

Although the "Tetris Heart" is a virtual project, it can help us understand the integrated development process of the product and determine the testing strategy in the integrated development phase.

2. Objects and test targets for integration testing

Let's take a closer look at the integrated development process of the Tetris Heart:

Developers follow the plan to complete the build plan to integrate into the system's functional development, the need for unit testing to test the correctness of the function, after the test, the developer will integrate the function, construction system (this process is sometimes called "the"). The test after the completion is our "Integration test".

The integrated development process of Figure build2

The unit tests are designed to test whether "newly developed features and modules conform to design", "White-box testing", and testing using an internal interface.

The integration test is equivalent to testing to verify that the "New integration function can be correctly assembled in the system", is "black box test", is also a system-level test, should use the system provided to the user's input interface to test, using the output interface provided to the user to determine the correctness of the interface.

"Functionality can be properly assembled in the system" implies a premise that "functionality is the function we want". Unit testing can only confirm that the implementation of the function is in accordance with the design, but does not guarantee that the function is exactly what we want. As a result, the integration test needs to be tested for several things including the following

• Use the Black box test method to verify that the newly-entered functionality is correct.
• Verify that the function of the system is correct after integration.
• Verify that the original system functionality was not compromised by the newly-entered functionality.

3. Entry criteria-when you can start the integration test

The ingress guidelines for integration testing are equivalent to "whether the functionality submitted in the first integration plan can be tested for integration".

• Condition 1: Feature development is completed in the first integration plan, and unit tests are completed.
• Condition 2: Functionality integration in the first integration plan is complete and measurable. The focus of Condition 2 is "measurable", that is, development needs to provide a user-based input and output interface, rather than an internal function interface, to ensure that testing can be done at the system-level black box test.
• Condition 3: The Test team is ready for testing.
  • The test case has been output and passed the review.
  • The test resources are in place.
  • The test environment is ready.

4. Test Case Selection

Clear the test content, the choice of test cases becomes easy

• For functional validation testing, you can select a test case for the relevant function level 1.
• For tests that test for new feature integration, you can select test cases for the relevant feature level 2 and some level 3 test cases.
• For "confirm the original system" test, you can select the relevant features in the Level 1 test cases.

The "partial Level 3 test case" means that in the late integration test, the system is relatively mature and stable, but also appropriate to select some performance, stability and stress test cases to test, to avoid these "non-functional" aspects of the system testing phase intensive outbreak.

5. Export guidelines

When we reach the goal of the integration testing phase, we can exit the integration test.

Export guidelines include:

• The functions that the system needs to integrate are all open and integrated.
• The test cases that you plan to execute are complete.
• The results of the defect analysis are in line with expectations.
• Achieve product quality objectives in the integration testing phase.

4.3 System test Strategy

Starting with system testing, the product development process enters the testing phase.

1. Objects and test targets for system testing

We may have this question: at the end of the integration test, the heart pattern is finished, and we have tested it, why do we have to do the system test again? Or is this question from a test point of view, which is the test case that has been executed in the integration test, and does it need to be executed again in the system test? What are the main differences between integration testing and system testing?

When doing the integration test:

• The gaze is staring at the newly developed features. And with the continuous integration of functionality, the complexity of the system begins to swell rapidly, and it is difficult (or not enough testing time, or the system is not stable enough) to validate all the combinations that relate to functionality.
• More importantly, integration testing is primarily about functional integration, where we cannot (or do not have enough testing time, or the system is not stable enough) to test the quality of other non-functional aspects of the subject being tested. 、

The main things to test in system testing include:

• Verify the correctness of the test function from a system perspective.
• Verify the correctness of various non-functional qualities from a system perspective.

2. Entry criteria-when a system test can be carried out

The entry criteria for system testing is the export guidelines for integration testing, plus one: The Test team is ready to test, including test cases, test resources, and test environments.

3. Test Case Selection

Now let's answer the question at the beginning of this section: the test cases that we executed in the integration test, do we need to do it again in the system test?
The answer is that the test cases for system tests and integration tests will certainly have the same parts, but not simply repeating them, but with a certain selection strategy.

• Functional testing for System perspective: You can select test cases for Level1 and partial Level2.
• For "The correctness of non-functional quality": You can select LEVEL3 test Cases and level4 test cases.

4. Test Execution order

We did not discuss the order of test execution in the integration test because the test object of the integration test was a single, "feature". Although we mentioned later in the integration test, you may consider adding some "non-functional aspects" of the test, but in general this will not give the test to do what to do before the trouble.

The software Test architect, when considering the test execution sequence, can be based on the following points:

• Some test methods need to meet some conditions before they can be done. For example, full-spec testing needs to be done in a normal way, otherwise it will be difficult to tell whether the problem is in specification or function. This requires that we arrange the test execution order according to the conditions of the test method itself. For example, a stability test, a stress test, and a recovery test are performed first.
• If there are two kinds of test methods, test objects can be tested, first complex, then simple. In other words, try to perform complex and difficult test cases first, and then make simple test cases. This is due to the hope that defects can be found in the early stages of the test, and that the test cases that are difficult to perform are also guaranteed to have sufficient testing time.
• Consider combining a variety of test methods, or let testers try to put some test cases together to execute them. For example, you can put test cases for functional tests together with full-size test cases, and test the functionality in full specifications. This kind of test execution order is especially suitable for the test cases that need to be repeated in the system test and those that have been performed in the integration test, and many new problems can be found.

5. Export guidelines

When we reach the goal of the system testing phase, we can exit the system test.

Export guidelines include:

• The use cases for the tests that you plan to perform are complete.
• The results of the defect analysis are in line with expectations.
• Achieve the product quality goal in the system testing stage.

4.4 Acceptance Testing Strategy

Acceptance testing is a product before the release of a test, it is to confirm the needs of users in fact, our acceptance testing is no longer to identify the problem of the product, but for the product to build confidence in the normal release.

The object of the acceptance test is the requirement, which needs to be tested based on the user scenario.

The acceptance test consists of both alpha and beta tests.

1. Alpha Test

An alpha test is a test performed by a tester that simulates a user.

1) who will perform the alpha test?

An ideal alpha tester should be someone who knows little about the implementation details of the product, but is very knowledgeable about the user. According to this standard, market personnel, system engineers or technical support personnel can be the ideal alpha testers, they can stand in the user's perspective, the quality of the product again review.

It seems to be a good choice to have the test crew cross-check each other-it does eliminate the "aesthetic fatigue" and find some problems, but cross-acceptance is difficult to achieve from the user's point of view again to look at the effect of the product. Compared with the cross-test, the more effective method is that the test department specifically set up a "acceptance Test team" by the test Department of Comparative experience, testing ability, and the industry, the user has a certain understanding of the testers to serve as the final line of defense before the product release, This is undoubtedly the best way to ensure the alpha test results.

2) Alpha test strategy

Alpha testing is not a continuation of system testing, it is a prelude to product delivery, its test focus should be "to confirm in the user's real environment, the user's business, the user's usage habits can meet" demand. Simulating the user's real environment, hypnosis himself as a user, can take the user's thinking to look at the product, is the alpha test is the difficult point.

The following checklist may help us to perform alpha test analysis to find out what the product needs to focus on in alpha testing:

• How will the user learn the product?
• Does the information provided by the product (such as manuals, guides, Videos) provide practical assistance to the user?
• The user will deploy the product installation in what environment (including hardware, operating system, database, browser, etc.) that the user will use.
• Can I upgrade correctly in the user's environment? Does the impact of the upgrade on the business be within the scope of user tolerance? Is the impact of an upgrade on an existing feature consistent with user requirements (such as the ability to lose attributes after an upgrade)?
• Can the product be removed correctly in the user's environment?
• What is the upstream and downstream equipment for the product in the user environment? In such an environment, can the product be used normally?
• What business is possible in a user environment? Which business is our products need to pay attention to, which business is our products do not need to pay attention to? What will our products do with our business that we don't need to focus on?
• What are the possible failures in the user's environment? What will our products do with these faults?
• How will the user manage and configure the product?
• How will users use the product's logs, alarms, audits, reports, and operations-related functions?

2. Beta testing

A beta test is a test that is attended by the user. There are two common ways to do this:

• Before the product is officially released, the product is sent to the user in advance to collect feedback from users.
• After the product development is completed, the product is submitted to the user for acceptance.

The difficulty with beta testing in the first way is to determine the time and the participants for the test. For testers, there is no need to make a decision on the above two issues, but rather to analyze, reproduce the problem identified by the participant, and organize the issue into a bug report until the bug is confirmed to be resolved.
The second way of beta testing, the need to ensure that the product can pass the user's acceptance test, can be delivered to the user, then the test needs around the user's acceptance plan, and combined with the user's usage habits and the characteristics of the industry users are fully prepared.

3. Entry criteria-When to begin acceptance testing

The entry criteria for acceptance testing are the export guidelines for system testing plus:

• The alpha test has been selected for the person and program.
• The user of the beta test has been identified.

4. Export guidelines-When you can exit the test, release the product

When we confirm that the product has reached the product quality goal in the overall test strategy, we can exit the test according to the product quality evaluation model.

4.5 Reviews

Now the software Test architect has gone to the location shown in Figure 25

Figure 25 Development of the completion phase test strategy

Let's start with a summary of what the software Test architect has identified so far:

• The test design strategy is determined, and the test design table is adopted to ensure that the Test team can conform to the test strategy and determine the grade of the test case.
• The test strategies for each test phase are determined.

Starting with section 2, we did not show that the current activity corresponds to which step in the four-step test strategy formulation, but rather to organize the content of the article as much as possible in accordance with the idea of a four-step test strategy formulation.
So far, no product testing has been done, which makes our testing strategy somewhat "on the paper". After entering the product testing phase, the effectiveness of the test strategy can be presented immediately through defect analysis, when the software Test architect's working mode will be shown in Figure 7-42.

Figure 26 Software Test Architect's working mode

Test Architect Training: 5 Test Strategy Practical Introduction