content
1. Standardized requirements analysis stage
(2) Roles and responsibilities
Second, the standard unit testing phase
2), the implementation of unit testing needs to pay attention to the following points:
3. Testers pay attention to the use of 5 Why
(4) Use 5 "whys" to pursue the root cause
1. Standardized requirements analysis stage
For requirements designers, how to conduct requirements analysis; for quality assurance, testing activities should start from the requirements analysis stage and participate in the requirements review meeting. How to standardize the review activities, it is necessary to establish the review process.
(1) Access conditions
Specifications, review checklists, software processes and guidelines involving reviews.
(2) Roles and responsibilities
(3) Review steps
Step 1 : Develop a review plan. The project leader formulates the review plan during the project planning stage
Step 2 : Review Preparation
① According to the project plan, the project leader determines that the reviewers must participate in the review, and designates the recorder of the review meeting, and then informs the relevant stakeholders.
② The person in charge of the project assigns reviewers, the input conditions required for the review must be determined, and the standards must be prepared in advance and confirmed.
③ On the eve of the review meeting, each reviewer can receive the review notice, the materials to be reviewed, and other related materials by email, so as to ensure that the review meeting can be held.
④ According to the check items in the review checklist, each reviewer will pre-review the review materials. Defects detected during this period are filled in the comment column after the corresponding check item on the review checklist.
Step 3 : Review Meeting
① The business person or requirements analyst is responsible for introducing the project product and explaining the questions raised by any review participant.
② There must be a clear conclusion for each question raised in the review.
③ Identify the reviser and verifier of the problem. Modifiers need to give time to investigate the issue.
④ Review participants discuss the problems found until a consensus is reached; the recorder is responsible for recording the review results (including problems found, measures taken and suggestions), and record
⑤ The evaluation of the work product is summarized according to the evaluation criteria. In the case of serious defects, the review fails; in the case of no serious defects, if the number of defects in the ordinary level exceeds 4, the review fails; in the case of no serious defects and the number of defects in the ordinary level is less than 4 , the review passed.
⑥ When the review meeting draws to a close, the recorder will restate the problems found in the meeting, and then
Reviewers categorize questions.
⑦ If the review conclusion of the review meeting is not passed, then it is necessary to re-evaluate and reserve the time of the second review meeting for re-review.
⑧ The project leader assigns relevant participants to collect all relevant review materials.
Step 4 : Take Action on Review Findings
① The recorder will record the defects raised and the conclusions discussed in detail, integrate the minutes of the meeting, and complete the review of the manuscript.
② The project leader assigns a requirement designer to analyze the final draft of the review meeting, formulate a defect resolution plan, and release the work product.
③ The person in charge of the project assigns a recorder to supplement the missing content in the Review Report to the Meeting Minutes.
④ The person in charge of the project assigns a recorder to supplement the missing content in the "Review Report" to the "Meeting Minutes".
Step 5 : Track the review results to completion
Step 6 : Submit and File
The project leader assigns a staff member to submit the review record to the configuration administrator.
(4) Output
The output includes the requirements specification that has passed the review, the review checklist, the defect management list, and the review summary.
Second, the standard unit testing phase
Unit tests can be tested by testers with programming skills or self-tested by developers. Due to the lack of such highly skilled testers in the current testing team, unit testing is temporarily replaced by developers.
1), unit testing process:
- To do test analysis, put forward the corresponding test points;
- Second, write test cases according to the test points, select appropriate inputs, and get the expected output results;
- Develop test codes that conform to functional modules, and add comments to the right side of the block program;
- Execute the test code to check that the actual result is not the same as the expected result;
- Execute test cases, mark test results, and record in defect tools if problems are found;
- Find the source of code errors based on defects, repair code defects, and re-test until the test passes.
- Write a unit test report and archive it after the review is passed.
2), the implementation of unit testing needs to pay attention to the following points:
(1) The test code can be used as a part of the program module, and it is beneficial to install and remove the test code in the module by debugging the interface switch.
(2) Unit testing should achieve 100% execution rate for program statement testing.
(3) Code that is removed, integrated, or tuned must be reviewed and verified.
(4) Strict unit testing must be done when the code version is upgraded to ensure that the code will not cause errors in the implementation of other modules due to the addition or migration of modules.
(5) For the scenarios where the program is expected to report errors, efforts should be made to reproduce in unit tests.
(6) Unit testing can also use system testing methods to verify code, such as path analysis, program instrumentation, etc.
After half a year of requirements analysis and unit testing in strict accordance with the specifications, the products delivered to the test environment are found after system testing. The magnitude is reduced, and the total number of defects is also reduced. Product quality has steadily improved.
3. Testers pay attention to the use of 5 Why
(1) Identify the problem
what happened? For example, an anomalous control point is found in the C-plot of the number of production problem escapes.
(2) Clarify the problem
what is the problem? The relevant data corresponding to the abnormal point is stripped from the abstract data table, and then the data is deduced and located to the specific problem description. For example, the problem description is: "In version FP2.0, the user found in the publishing environment that the registered user still could not log in to the APP even after entering the correct user name and password."
(3) Decomposition problem
Break the problem into small units. Question 1: "Can all registered users not be able to log in?" Answer 1: "No, only users registered with WeChat cannot log in." Question 2: "Can unregistered users be guaranteed not to log in?" Answer 2: "Yes Yes." Through problem decomposition, the scope of the problem can be narrowed down, and the production problem can be determined as: users who only register through WeChat and do not register through the APP cannot log in.
(4) Use 5 "whys" to pursue the root cause
"Why is this problem happening?"
"Because the test did not take into account the login of users who only use WeChat to register."
"Why wasn't this situation taken into account?"
"Because the test case doesn't cover this scenario."
"Why is this scenario not covered?"
"Because the needs analysis was not done well."
"Why didn't you do a needs analysis?"
"Because the testing time is tight, there is no time to do a careful requirements analysis."
"Why do you think the test time is tight?"
"Because there are not enough testers to support the testing mission."