How do testers avoid blame?

As a "quality assurance" role, this problem will certainly meet, then I would like to talk about their own views.

Speaking of this topic, many people may subconsciously think of how to "shake the pot", thinking about how to clear the responsibility. In fact, as far as my personal experience is concerned, although this method is necessary, it should be used with caution and must not be used.

Because once there is a quality accident, no matter how much the explanation of the hype, it does not help, but it is easy to let people feel that you are not credible, not to pay. Said the more, the more let the leader disgusted, think you are looking for excuses, no sense of responsibility!

If it did, it might be wrong.

I personally feel that we can consider the following seven aspects:

2. Full communication, testing scope and risk before testing
   1. With the development of detailed confirmation requirements, the confirmation of the time to pay attention to the method, such as the other side after the end of the meaning to repeat the other side to confirm, back can also be used by mail to confirm the other side.
   2. Send the test scope to the project stakeholders in a mail-only manner. On the one hand, let the recipient confirm that their understanding is correct, on the one hand, the recipient will be found when the information error correction.
   3. Inform the Test Manager (or project manager) of the risk, including quality risk and schedule risk.
4. Smoke test after version is released
   1. It is important to verify that the version is measurable.
   2. Avoid test delays due to version problems-This pot cannot be backed up.
   3. If the version quality drops, the impact test should be reported immediately and the version dismissed to allow development to repackage.
6. Immediate escalation of issues that affect progress during test execution
   1. A general bug is irrelevant, but once a fatal or serious bug occurs, and it can (or might) lead to a problem that the test is not able to do, it should be escalated immediately to avoid asymmetric information.
   2. If the problem is not reported, and finally even if you "excellent" to complete the test task, in the leadership of the heart, your work is not a bit.
8. Convincing data in the test report
   1. The test report avoids being flashy. Have enough convincing data to support your test conclusions. For example, think that this version can not be online, it is possible to enumerate the O/C map, list the defect status-severity perspective, and sometimes add some of their own analysis, such as this version of the bug blowout, what is the reason, whether these reasons may also lead to other risks and so on.
10. Keep a record of all the problems you find.
    1. Most of the time, we feel that we have found the problem and told the research and development, and rightly think that they will change it. ----This approach is not not possible, but the branch office, but also the timing of the score. For example, when the project needs urgent on-line to do so, to avoid the waste of time to take the process. But we can not too believe in human memory---especially our line, long-term overtime, then the efficiency and mental state is relatively poor, may cause him to forget, or change the bug is not complete, or the bug this time changed, after some time found, or after a while we want to find this bug can not find ....
    2. In short, if the day after the online exposed the problems we have found, we need to have evidence, to have words.
12. Don't be too stubborn to be the goalkeeper.
    1. In many companies, testers cling to the "right to speak", which seems to reflect the value of testers. --I don't think that's advisable.
    2. Frankly speaking, we are a group of people looking for information, a group of people who provide information for the project. We are the service, not the controller, if the concept of confusion, development and testing of the relationship must not be harmonious, a bad team, I can hardly believe that it will produce high-quality products. ----Of course, I do not mean that the team is a group of friendly people, no quarrel.
14. Be careful to be a process improvement team
    1. Many people want to improve their quality through some process improvement. The idea is correct, but often there are problems.
    2. The biggest problem is that the idea is right, even good, but not going forward.
    3. When you push, you may even be dragged down by some disgusting means to make you look stupid x.
    4. In this case, either the project manager or the product manager is in a position to push for reform or get high-level support. Otherwise...

(0 0)
+------OOO---(_)------------+
| |
| "Welcome attention" |
| Miss Zhang's Little black House |
+--------------------OOO-----+
|__|__|
|| ||
Ooo ooo

How do testers avoid blame?