Test Architect: 2 What a software test architect should and shouldn't do

Test Architect: 2 What a software test architect should and shouldn't do

2016-08-12

The test architect should consider the following issues:

• What is the goal of the test?
• What is the scope of the test?
• What is the depth and breadth of the test?
• What are the key and difficult points of the test?
• How do I schedule a test?
• How are test results evaluated?

Directory

1 Test architect in demand analysis
1.1 Understanding the business objectives of the product
1.2 Combing users ' usage scenarios
1.3. Output product overall test strategy
2 Test architect in test analysis and design
2.1 Developing a Phase test strategy
2.2 Implement test design strategy to ensure the quality of test design
3 Test architect in test execution
3.1 Developing a version test strategy
3.2 Tracking Test Execution
3.3 Version quality assessment and build version quality profile
4 Test architect in test quality assessment

1 Test architect in demand analysis

Return

The source of the test is demand. The tasks that the software testing architect needs to focus on during the requirements phase are:

• Understanding Requirements
• Develop an overall test strategy to define test scope, test objectives, test focus and difficulties, test depth and breadth.

At this point the test architect should not fall into the implementation details of the product, when the right direction and clear goals are more important than the details.

How do you calculate "understanding demand"? Participate in each requirement discussion and familiarize yourself with each requirement specification is that enough? It takes some time to understand the business objectives of the product and to comb the user's usage scenarios, often resulting in a multiplier effect for the work behind it.

1.1 Understanding the business objectives of the product

The business goal of a product is to test the first questions that architects need to understand.

Dave Hendrichson in his book Essential Skills for Software Architects ("12 disciplines of software Architect" Zhang Fei translation, press release of the mechanical Industry publishing house) "When system architects consider the true value of a software architecture , not just to focus on the technical aspects of system construction, but also on customer value and business value-can you help customers really solve the problem? How do you help the company make money? --Have a deep understanding of ". This is also true for software test architects.

In this book, Dave Hendrichson uses a bubble chart to visually summarize the intersection of business knowledge and software architecture, as shown in 1.

Figure 1 A bubble chart of Dave Hendrichson

Like system architects, software test architects also need to understand the following issues:

• How do marketing and sales people in the company segment customers?
• What are the key value propositions for each market segment?
• What market segments is the company trying to grow? How does it grow?
• Who makes a purchase decision for each market?
• Who are the main competitors in each market segment?
• What is the company's policy proposition for this product? How does the product fit into this strategy?

And be able to carry out testing activities around the following content:

• How to verify that the products under test reflect the market value correctly?
• Is the test strategy consistent with the company's financial, sales, and marketing objectives?

1.2 Combing users ' usage scenarios

The so-called "user Scenarios", simply speaking, refers to how users will use the product. User scenarios will directly reflect the value of the product. Therefore, before testing, it is important to know your users:

• How many types of users are there, what are their businesses, and how do they derive value from your products (such as making money from your product and getting some kind of resources)?
• What valuable solutions does the competitor of the product offer to the user? What is the difference between you?
• What are the basic specifications and requirements of the product area, what are the industry backgrounds, what are the user's habits (such as the sequence of activities completed, the criteria for judging the completion of activities, and possible important decisions)?

The software Test architect then needs to summarize the user-usage scenarios into test scenarios:

• For different types of users, determine the behavior habits and concerns of these users respectively.
• Each analysis of how these users will use the product, based on the results of the analysis of the product topology model, configuration model and traffic model, and abstract the typical scenario.
• Determine the inputs and outputs in each typical scenario (including normal input and exception input, attacks, and how long the simulation test takes, and so on).

1.3 Output product overall test strategy

The output product overall test strategy is an important output of the software testing architect at this stage. It acts like a test master, helping the entire Test team to define the scope of the test, the goals, the focus and the difficulty of the test, the depth and breadth of the test, and how to schedule various test activities (and test tiering).

The test focus and test difficulty are two completely different concepts:

• Test focus is determined by the product value, quality objectives, product implementation (new write code, open source code or inheritance code) and historical testing situation (mainly for inheriting products) and many other factors synthetically.
• "Test difficulty" is from the point of view of testing technology, is the analysis of the difficulty degree of product testing verification.

Test depth and test breadth are also different:

• Testing breadth is to describe the product test from the angle of coverage;
• The test depth is described by testing methods such as single-run tests, multi-run tests, boundary values, or incorrect inputs.

When we determine the test focus and test difficulty, depth of test and breadth of testing for each feature, the overall idea of the test is clear. The strategy behind the automation strategy, exploratory testing strategy, test analysis, and design has also become clear.

The test layering helps us break down a large test target into several small test targets. This allows us to test the test results layer by layer, and to continually revise the test strategy based on the test results, not only to make the test target attainable, but also to make the entire test process manageable.

The above content constitutes the overall framework for testing. We can continue to refine this framework, and then output the phase test strategy and version testing strategy. If the test requirements analysis, test analysis design, test execution, test quality evaluation and other testing activities compared to pearls, testing strategy is that the line of pearls, through the always.

2 Test architect in test analysis and design

Return

2.1. Develop phase test strategy

A phase test strategy is a test strategy that determines each test level according to the test hierarchy, and the phase test strategy is also a further decomposition of the overall test strategy.

Figure 2 Example of test layering under "V model"

What you need to focus on for phase testing include:

• Test objects, targets for each phase.
• Exit criteria for each stage.
• How to select a test case.

The entry and exit criteria are in fact the quality objectives and acceptance criteria for determining this phase. Sometimes, the testing phase is also interlocking, for example, if we want to perform performance testing, we need to stabilize the function as a prerequisite, then the functional stability is an entry condition of performance testing.

The exit criterion is not a restriction test, but is a contract for testing and development.

2.2 Implement test design strategy to ensure the quality of test design

method, the software test architect can use the test Analysis Design table to ensure that the test design conforms to the test strategy. For the contents of this section, see Section 7.4.1.

3 Test architect in test execution

Return

Figure 3 The main work of the software Test architect in the test execution

3.1 Developing a version test strategy

The main contents include:

• The deviation between the test scope and the plan.
• The test target for this release.
• What you need to focus on.
• The selection of the test case.
• Test execution order.
• A tentative test strategy.
• Receive a test policy.
• Regression testing strategy.
• Explore Test strategies.
• Automated test strategy.

We will be in 8.1~8.2 and section 8.4.

3.2 Tracking Test Execution

Specific content includes:

• Track the performance of test cases.
• Daily defect tracking.
• Adjust the test strategy

3.3 Version quality assessment and build version quality profile

The version quality assessment is a summary of the quality of each test release. method, we can use the SOFTWARE PRODUCT quality evaluation model for quality evaluation. For a description of the SOFTWARE PRODUCT quality assessment model, see section 6.3, and how to perform a version quality evaluation, see section 8.4.

Table 1 Quality Profile templates for feature versions

4 Test architect in test quality assessment

Return

and version quality assessment, the quality assessment at this time refers to the quality assessment or release of the assessment, need to give "can go to the next stage of testing" or "release" conclusion.

method, the phase quality assessment is still evaluated using the SOFTWARE PRODUCT quality assessment model, and the key concerns include:

• Verify that the important quality objectives in the overall test strategy are met.
• To determine the general quality objectives of the nonconformance in the overall test strategy, and to identify the response measures.
• Perform legacy defect analysis.

Test Architect: 2 What a software test architect should and shouldn't do