Author|Zhang Yuan
background
As QA's quality control of the whole process has gradually become a trend, QA's focus in the project is not only in the testing phase, but at every stage of the project, it can be seen that QA is actively promoting project progress and controlling project quality .
This article will mainly introduce where QA can start in the technical design review stage, so as to participate in it effectively and play a role.
Why participate in technical design review?
Before introducing participating in technical design review, we must first clarify why we need to participate in technical design review? What can we get from participating in the technical design review? Only when we are clear about the benefits of participating in technical design reviews can we be more motivated to do this. I believe that QA's participation in technical design review has the following four advantages:
1. Correct the misunderstanding of requirements of project members. When participating in the technical design review, through the understanding of the development design ideas, understanding the development’s understanding of the requirements, and discovering the incorrect understanding of the requirements of the development; at the same time, while understanding the design ideas, you may find that you have a good understanding of the requirements. The place of deviation. By correcting these points in time, certain bugs can be avoided as early as possible.
2. Provide a basis for the test plan. Through participating in the technical design review, understand the specific implementation plan, and select the corresponding test plan for the developed design plan, such as the core interface, whether the core service needs to be interface tested, important logic coverage, test scenario data structure, The tools required for testing, etc., can be thought and produced in conjunction with the developed technical design at this stage.
3. Effectively assess the scope of influence. Some scenarios are not mentioned in the requirements document, but because the corresponding code has been changed, related functions may be affected. Participating in the technical design review can help us find these impact points, add test cases in time, and avoid omissions.
4. Effectively assess risk points. By understanding the technical design of the development, understanding the scope of changes, assessing the workload and corresponding risk points. Even in the technical review stage, the development will provide a variety of design solutions. Through the understanding of each solution, QA can effectively assess the scope of influence and risk points of each solution, thereby choosing solutions with less risk.
How does QA efficiently participate in technical design review?
The design review meeting is generally not too long. If you want to keep up with the ideas of the development students in a design review meeting, understand the design plan, and achieve your own goals, it is very important to make preparations in advance. I roughly divide the design review into three stages: before the design review, during the design review, and after the design review. In each stage, the main things we need to do are:
1. Before design review: notify in place and prepare in advance.
(1) Ensure that relevant personnel are notified in place. Ensure that all relevant people are present at the review meeting and notify them in advance;
(2) Familiar with the requirements documents and read the technical design documents in advance. Combine requirements documents, understand technical design documents, and make comments in advance if there are problems.
2. Design review: focus on whether the technical design meets the requirements, the interfaces involved, and the scope of testing.
(1) Flow chart. Can clearly show the business process of this demand;
(2) Interactive diagram between systems. Provided in the form of sequence diagram or collaboration diagram, which can clearly reflect the information transfer between systems;
(3) Configuration functions. Which ones in the design are realized by configuration. Apollo configuration, cache, mq, timing tasks, etc.;
(4) Database design. The database table structure of the database, the description of the key fields;
(5) Whether the design is complete. Whether the functions required in the product requirement document are covered to avoid omissions;
(6) Multiplexing or modification of existing interfaces. If it is the ability to reuse the existing interface, see if the interface can really meet the new requirements. If it is modified on the basis of the original interface, it is necessary to know what has been changed and whether it will affect the existing logic;
(7) The definition of the new interface. If it is a new interface, see whether the implemented function meets the requirements and whether the interface definition is clear;
(8) Interface provided by a third party is required. Clarify which interfaces need to be provided by a third party, clarify the docking person, and facilitate subsequent communication;
(9) Externally provided interface. Provide the role of the external interface, make a corresponding test plan, and communicate with the user;
(10) Assessment of the scope of influence. Clarify what is the scope of the impact of this demand change and what scenarios need to be returned; if the scope of impact is relatively large, whether there is a better design plan;
(11) Be measurable. In the face of the need for testing in batches, whether the modules are testable after splitting; for special scenarios, do you need to provide tools for development or testing to facilitate testing; when untestable, divide the boundaries of the division of labor and clearly inform RD that we can test Point, clarify the quality control plan for untestable places;
(12) New and old data are compatible. Whether it involves testing and verification of compatibility between new and old data;
(13) Core interface performance indicators. Whether it is necessary to perform performance testing on the core interface;
In short, during the review process, you must actively follow the ideas of the development students, understand the reasons for the RD design, and bravely put forward your own ideas and suggestions when holding different views.
3. After the design review, follow up the things to be done and complete the design of the test plan.
(1) Synchronize things to be followed up in related groups. Clarify the connection person and the time to solve the problem, and do a continuous follow-up;
(2) Design a test plan. According to the project guidelines, select test methods, write test cases, provide data structure or script tools, etc., combine with technical design schemes, and do a good job of risk assessment.
QA is deeply involved in the project practice of technical design review
Below I will take a project as an example to specifically introduce how to promote the project to be completed efficiently and with high quality through technical review.
Project Name: Third-party suppliers can switch to advertising
Project background: The "I want to promote" portal was added to the backstage of third-party suppliers to match third-party suppliers to use commercial advertising, improve the efficiency of advertisers' order completion, and increase advertising revenue
During the entire design review stage, the following work was done:
1. Familiar with the requirements document, deepen the understanding of the requirements, explore the important and difficult points of the requirements, and pay attention to the corresponding design schemes;
2. Look at the technical design documents in advance, try to understand the development design ideas, and ask in advance if you have any questions;
3. At the technical review site, check whether all front-end and back-end development students and product students participating in the project development are present, so as to avoid the need to change points during the review process and not synchronize with all relevant people.
4. Check whether the flowchart provided by RD is correct and consistent with the requirements;
5. Since the project involves a third party, it is necessary to pay attention to the system interaction diagram involving the third party, understand the scope of functions that each party is responsible for, and evaluate the risks that the third party may bring;
6. Pay attention to the implementation plan of the key logic in the demand, database table design, and evaluate the test range corresponding to the design plan;
7. According to the design document, specify the test plan, including data preparation, interface test, case design, and data construction tool preparation.
Design review effect:
1. Based on the understanding of requirements and the inspection of the flow chart provided by RD, it was found that the RD flow chart was inconsistent with the requirements, and the occurrence of bugs was prevented from the source.
2. It is recommended to choose a development plan that has less impact on the test scope, which reduces the test scope. Which involves 2 demand points:
One point of demand: How to identify third-party users and record the third-party user information (telephone, address)?
Possible solution 1: Add fields to the original business user table?
(1) Disadvantage 1: If a field is added to the original business user table to identify a third-party user, and the new field stores the third-party user’s phone separately, it needs to return to the original business user creation function;
(2) Disadvantage 2: The newly handed over business, the RD that is now taking over does not know much about the original business, and is not daring to directly take risks to change the original function;
Possible solution 2: Add a new table to separately record third-party users and related information?
(1) Advantage: avoid returning to the new functions of commercial users;
Demand point 2: How to allow third-party users to bypass business user identity and qualification verification, and then use various business functions?
Possible solution 1: In each verification, judge the third-party user and make special treatment.
(1) Disadvantage 1: Commercial user identity and qualification verification is a prerequisite for the use of various functions of commercial marketing management. Too many verification places involve multiple clusters, which are easy to omit when sorted out, and return to a wide range.
(2) Disadvantage 2: Subsequent new commercial functions need to identify whether they are third-party users and perform special treatment, which is costly for compatibility.
Possible solution 2: Insert data into the new login interface to ensure that the subsequent process can pass the verification.
(1) Advantage: Adding functions to the new interface only needs to ensure the process functions involved in this project, and the scope of influence is small.
as the picture shows:
Conclusion: From the perspective of QA, based on the assessment of the scope of influence, the second option is recommended
3. Based on the interaction diagram between systems provided in the RD design document, the division of functions involving third parties is clarified.
The following is the interaction diagram:
It can be seen that the third-party supplier only needs to ensure that the user can jump to the commercial side correctly and the correctness of the user information carried, and the subsequent process is guaranteed by the commercial side. From the interaction diagram, you can also know the proportion of the other party's workload in the entire project, and you can roughly evaluate the risk that the third party may bring.
4. Based on the second solution 2 of the demand point in point 2, we can know what additional processing is done from the third-party supplier side to log in to the business side interface, which is not known from the demand document alone. After the design review, the processing of each interface was clarified, and based on this, the test plan was formulated, including:
(1) How to prepare the data;
(2) The key test of the interface test is that the input parameters are 2 interfaces provided by a third party, especially when the input parameters are empty;
(3) Case design;
(4) Preparation of data construction tools, etc.
The overall effect of the project: the responsibilities of all parties are clear, the scope of test influence is reduced (less cases), and the quality of the project is high (only 1 front-end bug during the test period, and wireless bugs).
Write at the end
Each project has its own unique characteristics. This article lists large and comprehensive checkpoints, which can help remind us where we can consider in the design review process.
By participating in the design review, QA can deeply understand the implementation plan of the technology, which helps to formulate a reasonable test plan. At the same time, through continuous practice, QA can also put forward some reasonable suggestions during the design review to help the project be completed more efficiently and with higher quality, and enhance the influence of QA in the entire project.
Come on, test man! The road is underfoot, and success is tomorrow!
You in the future will definitely thank yourself for your hard work now!
Recommend a software testing technology exchange group to everyone: 1079636098 group friends receive free of charge
May you and I meet and you will find something! Welcome to follow WeChat public account: programmer Yifan
1. Receive a 216-page software test engineer interview book for free.
2. Software testing learning route and corresponding video learning tutorials are free to share!