Communication is a very important soft skill for testers. This article uses two cases encountered in recent work to talk about the topic of how to communicate.
Project A is nearing the end stage, development leader Xiao Zhang (pseudonym) asked me: Is the quality of project A not good? Because he saw in a recent test report that the overall bug resolution rate was 27%. I am concerned that the regression bug resolution rate in the report is 100%, and there are some new bugs, but no serious fatal bugs. Later, I found the responsible tester to understand that project A focused on fixing bugs at a later stage, so a low overall bug resolution rate does not mean poor quality. In this case, there was a problem with the communication. Simply put, the development leader did not know the meaning of the data in the test report. Testers often follow a certain template to send test reports, but this does not mean that other project personnel can correctly understand the information the test report hopes to convey.
As an extension of this incident, when a project enters the late stage, one of the most concerned issues for everyone is when it can be released. An excellent tester, after completing the test task and issuing the test report, will synchronize the current overall quality situation with the project members in time, and emphasize which work has not been completed and which indicators have not met the release standards. In the above case, when the project enters the later stage, all requirements should be frozen, and the development focus will start to fix bugs; when the bug resolution rate reaches a standard (determined within each project), the full test can be carried out, and 1 more test is required after the full test is completed. - 2 regression versions of the test, can be released after reaching the release standard (for example, 100% of high orders are solved, and 90% of middle orders are solved).
Correctly and objectively assessing product quality, clearly conveying quality information throughout the project, and helping the team make corresponding decisions to ensure that the project is released on schedule is the purpose of communication among testers . If the tester does not realize the purpose of this communication, then no matter how much he communicates, the effectiveness of the communication will be compromised.
Project B has 3 formal testers and 2 outsourced testers. Recently, 1 formal person has left, and the testing resources are even more tense. I used to work overtime until 7 or 8 o'clock, but now I often have to work overtime until 9 or 10 o'clock. Everyone can't hold it anymore. At present, the most important thing is to solve the contradiction between fewer people and more people. In addition to adding people, the long-standing problems in the project also need to be solved. Had a small meeting with the outsourcers and learned that there is such a problem in the project. When the requirements change, no one informs the testers in advance, nor updates them to the requirements list. The testers discover the development implementation and requirements during testing. If the list does not match, some unnecessary communication and confirmation work will be generated, which will affect the work efficiency. The tester has spoken to the product and development of this problem many times, but there is no improvement. This case also suffers from a lack of effective communication. The way of communication is not only verbal notification, but also the construction of process, and in some cases the latter is often more effective .
For the above case, I made a small change in the process. The original process is that after testing a requirement, the tester will perform an operation to close the requirement order. The changed process is that when the requirement changes and the content of the requirement order is not updated, the order closing operation cannot be performed. At the same time, when the tester finds that the implementation does not meet the requirements during the testing process, they can directly submit the bill without interrupting the test to confirm the requirements. The advantage of this is that the test work will not be interrupted frequently, which improves work efficiency. If there are many cases that do not match the requirements, you can concentrate on time to confirm, and raise this issue in the project morning meeting the next day to urge the project team to improve.