Background: The project specification requirements at work: For projects with a test schedule greater than 3D, a test plan must be written. After investigating the situation of some students, on the basis of the requirements of this process specification, a test plan will also be prepared for situations such as complex logic of requirements or complex technical implementation.
I (the author) am mainly responsible for the OMS system testing. It is an important node in the entire contract fulfillment flow. The positioning of the system is to manage the order data in the contract fulfillment. The core of the flow between contracts. Since the system has a great impact on the overall business process, the process structure of the system must be very clear and the quality must be strictly guaranteed. I want to briefly share my little habit of writing test plans based on my personal perspective and the situation of the system.
0 1 How to write
Everyone's method of writing test plans is different. After some personnel statistics, most of the students' test plans started after the technical plan review was completed. Due to system characteristics, system understanding, and personal writing habits, etc., the time node for me to write the test plan is after the requirements review is completed, and then in the technical design, technical review and other stages of continuous optimization and improvement.
Phase 1: Before the requirements review begins
What is the preliminary understanding of this demand?
The product will send out the requirements in advance, and it is necessary to check the requirements background, goals, and requirements design in advance. Check whether there is any unclear place according to the demand, for example: Is there a second phase? Is it a temporary solution? Versatility? Are there business processes missing? Are the requirements boundaries clear? Does the function conform to the system positioning? Is the process perfect and reasonable? etc. Carrying out requirements review with these questions helps to assist in analyzing requirements and pre-empts some vague business details. Try to confirm everything that can be confirmed in one review.
The second stage: after the demand review begins, the technical solution is being designed
After requirements review:
1. Fill in the test plan : fill in the clear information on the demand level such as the project background and goals in the test plan.
2. Preliminary communication : clarify whether this demand change involves multiple business systems, and pre-communicate to clarify the demand boundary and the person in charge of the related system. Related issues can quickly locate the person in charge.
3. Clear the demand process and draw the first version of the flow chart : use the QA perspective to draw the demand flow chart. It is best to draw it again when it involves the process. The development of this node starts to design the technical solution. You can first draw the flow chart from the perspective of demand and the thinking of pure business process, and record any doubts.
There is still something to say about the flow chart: Generally speaking, the product will have a flow chart in the demand. What I thought at the beginning was that if there is a product, just use the product. Until there was a test plan review, the product said: "This flow chart 'copied me'". It's also a temporary "good face", maybe it's just a picture! I draw it myself. When I drew it for the first time, I found that the flow chart of the original product had some "blind spots" for QA, such as: the flow of status was not clear enough, and the logic processing was not detailed enough. In the process of drawing the flow chart, use the perspective of QA testing to understand the business flow process, logical processing, and results in different scenarios in detail.
In technical scheme design:
1. Improve the flow chart for the first time:
After the preliminary flow chart drawing is completed, there is a high probability that there will be some process problems, such as differences in understanding of state flow implementation methods, logic processing, etc., or implementation discrepancies. We need to discuss with development and continue to improve. This is the process of combining demand and development, and also the process of linkage supervision. Affect technology implementation from a business perspective to prevent blind design of development, resulting in "rework" caused by lack of demand logic or understanding deviations.
2. Further communication and preliminary clarification of information:
(1) Confirmation of requirements boundaries, milestones, etc.: In the requirements process involving multi-system integration, clear requirements boundaries must have a sense of ownership. If the person in charge of requirements testing is not himself, he should also take the initiative to understand the rhythm of the associated system, the person in charge of multi-system testing, splitting of requirements functions, etc. Clear information such as the boundaries of each system. There will be no "headless flies" during the test.
(2) Simultaneous confirmation of demands and preliminary analysis. Whether it relies on other systems to provide cooperation or whether it needs to provide some capabilities to other systems, such as: data preparation, data structure, information configuration, etc.
(3) Rhythm communication: Preliminary understanding of the testing rhythm of other systems can better plan test plans and test strategies.
for example:
-
The dependent service is launched later, and the test tasks related to this function will be queued later;
-
If the upper layer relies on this service function, if the rhythm is unified, the upper layer can initiate scene coverage; if the upper layer is late to test, it can test the interface by itself;
-
If it is relied on by multiple systems, internal testing should be done in advance so as not to affect the rhythm of other systems, etc. Knowing these can raise risk preconditions such as strong dependence and excessive rhythm differences.
The third stage: after the design of technical solutions
It is necessary to clarify the involved configuration, library table design, and process implementation. The secondary correction of the function implementation plan, update the corresponding content of the test plan.
1. Confirmation of process logic:
-
Check whether the flow chart is consistent with the implementation after the technical solution review;
-
Functional dependency of multi-party interaction, sequential dependency
2. Configuration confirmation:
For example, Apollo, page configuration, and some online processes must be confirmed with the product and development of online data configuration, and sandbox checks must be done.
3. Library table design:
-
The library table design focuses on whether it affects the online process and data;
-
Whether there are field changes in large-scale data tables, such SQL can only be executed at night. Before the sandbox, it is necessary to remind the developer to execute the SQL statement the day before, so as to prevent the verification progress from being affected due to non-execution;
-
Whether the state machine changes, if the OMS state machine changes, the online cannot be restarted after the sandbox is deployed, otherwise the service cannot be started, and the O&M front-end must be communicated. Simultaneous demands cannot be merged online.
4. Interface changes:
Whether there is an increase or decrease field processing for the original interface, and if there is a need to clarify the caller of the interface, whether the jar package will be upgraded accordingly. Take adding a field as an example. When the field is added and there is verification logic, the caller has not upgraded the jar. If the field is null and there is logic, a null pointer will appear. In this case, compatible regression should be done.
The fourth stage: before the test plan review
For this node, if there are other related systems, each direction should have clearly defined the requirements design and technical design. At this time, it is necessary to make a final determination with the QA person in charge of each system, and improve the vague content in the first draft of the test plan.
1. Whether there is data structure dependence
2. The scene of system function interaction, the lead party and the concerned party of synchronously related scene use cases;
3. For the situation of relying on other systems, according to the test rhythm of other systems, evaluate the impact, and analyze whether it is necessary to adjust its own test plan and test strategy;
4. What do I need to provide for other systems, the expected time node, etc.
Stage Five: Test Plan Review
I usually complete the review of the test plan on the same day as the technical plan. While the "hotness" of demand is still there, it is better to align the perspectives, unify the rhythm and differences. Everyone is clearer about what to do next, and the project rhythm is clearer.
02 Changes in Focus
After really understanding the content of the test plan, we found that the test plan template used by our company includes the characteristics of each system. The content that needs to be paid attention to in the test of the project is like a detailed outline, reminding us to pay attention to some content that has not been considered. Conscientiously completing each item can help us refine the method and rhythm of the test. There is also a certain process for individuals to change their mentality from when they first came into contact with the test plan to when they understood the test plan.
Act according to the regulations:
At the beginning, according to the requirements of the project specification, the test plan was written for the project larger than 3D. The process of writing a test plan is also a "fill in the blank" of "not knowing why". In the process of writing several test plans, I found that the test plan module in the test plan can refine the schedule and facilitate the clear rhythm of requirements. Clear rhythm milestones are in the test plan, which helps to plan the test rhythm reasonably.
Focus on : project milestones, project plan
Multi-party research, knowing yourself and the enemy:
After a period of time, OMS began to gather business access during this period. With the continuous access of multiple businesses such as snacks and stores, the accumulation of the process itself began to pay attention to the test boundary of the system, the connection function nodes in multi-system delivery, and the system In the process of multi-system cooperation, these information are very important. It is possible to more quickly locate the problem and its system and system contacts, and troubleshoot problems faster. Clarify your own business, reduce the blind spots of other systems, and improve your business thinking.
Key points of attention : demand boundaries, demand splitting, multi-party system docking personnel, preliminary preparations, etc.
Tactics are clear:
The arrangement of test means is as important as the formulation of tactics on the battlefield. Increase the importance of this module in a demand for OMS internal technology optimization. After the business was involved in the OMS system on a large scale, the internal optimization of the system began within the OMS, and the biggest core change was the adjustment of the inventory model. This requirement is not aware of the external business, but the internal structure changes greatly. The content of this test plan was also optimized many times during the process requested by the person in charge. It is necessary to have an in-depth understanding of the technical solution, and improve the content of the test plan, such as: grayscale strategy, configuration related, test strategy and test methods, etc. Also confirm and pre-communicate the scope of the return, the affected system, and the person in charge of assisting the return. Minimize the risk, continue to correct the direction that needs to be confirmed, and ensure the quality.
Key points of attention : technical solution process, test strategy, test means, configuration and inspection items, etc.
Close to business:
With the accumulation of working hours, I realized that if I want to really understand the system, I have to get close to the business. It is very important to understand the positioning of the system, the direction of development and the next plan. In this way, in some large requirements, the design of the requirements can be analyzed according to the business direction, long-term goals, system positioning, and whether it is long-term development, and whether the technical design direction is suitable for long-term iterations. Only by paying attention to the goals, background, and realization of requirements can we better control the quality. The premise of the project must be business.
Focus on : project background, project goals, etc.
0 3 Summary
I hope that I am not only a QA, but also a linker who can link products and technologies, making technology and myself closer to business, and I hope that products can understand the system in multiple dimensions. I hope that while protecting the quality of the system, it is also a qualified project rhythm guard.
The above are some of my own little habits, a little sharing!
Finally: The complete software testing video learning tutorial below has been sorted out and uploaded, and friends can get it for free if they need it【保证100%免费】
These materials should be the most comprehensive and complete preparation warehouse for [software testing] friends. This warehouse has also accompanied tens of thousands of test engineers through the most difficult journey. I hope it can help you too!
