Test engineer How to shake the pot!

When it comes to some of the biggest problems that plague software testing engineers, the first thing we can think of is the following:

Demand with sister-in-the-run, no need I test ...

Development of Cowhide coax, he hit me, also said that I reported not a bug ...

Test time is not enough, the quality of the project is so bad how to go online, people do not face it ...

Also, today, someone asked me, ' how come you didn't test this bug? ' ...

Yes, I believe every Test engineer has experienced this kind of distress, that is the back pot !

How other small elder brother Miss elder sister All is C position debut, we but he meow is back pot position debut ...

As a test engineer, back pot you afraid of it. Today we are going to pull up the banner, put up character posters: say no to the back pot!

Don't want to back pot how to do oh, hide under the table also can not hide the appearance. What's going to happen? Very simple, shake the pot!

Now let's teach you how to throw a pot:

First of all, our premise is that your job test should be done with high quality.

If the test coverage is inadequate, carelessness causes us to miss important questions, and is brought into the later stage or even after the launch. Then the first thing we should think about is not to shake the pot and shirk responsibility .

So the first thing to do is to review the problem and analyze whether the omission of such a problem is caused by our personal negligence of duty.

If it is true that we do have problems during the testing process due to our own mistakes, then we should be bold enough to acknowledge our shortcomings and express our sincere apologies to the relevant stakeholders.

Admitting that the problem is not the most important, more importantly, we should take the initiative to summarize in the event of the process of our mistakes, and put forward ideas and methods of improvement. It is not too late to mend, so a sincere and responsible attitude will help you to alleviate the blame and lack of confidence that comes with working mistakes. In general, if not a major failure, our team will not be too much to pursue this problem.

Secondly, we can go back to the process of the occurrence of the event.

Our testing is not an independent existence, our testing team is not an independent team, our testing activities are also linked to a chain-type project. Testing is the most dependent work in the research and development team, and the output of our final work is closely related to the completeness of our upstream process.

So in the event of the incident, if we are looking back on our own testing work, really did not find the obvious negligence of our work, then we have to backtrack to the upstream of our work, to see if it is not what link eventually led to the problem.

What is the upstream work of test execution, from near to far, is: test design, test analysis, test plan, coding development, product design, product analysis, project requirements.

If there is any problem in any of these links, even small flaws may be small waves, it is possible to develop into flooding downstream.

For example, a requirement of ambiguity can lead to a completely different understanding of a feature point in development and testing. Then eventually this deviation of understanding will be reflected in the implementation of the test, resulting in the final link problem.

Also, for example, in the test planning phase, there may be insufficient estimates of coverage aspects of the test-such as the loss of usability testing content-and ultimately the lack of control over the quality of the product in one aspect of the test execution phase.

So, we can go back to the upstream process of our test execution to find out the root cause of the problem. Further, we need to put our findings, reasonable to explain to our management team directly under the leadership, as long as our basis is true, I believe that can alleviate our responsibility for the incident, a better situation is also can promote the improvement of the project process, to prevent similar problems in the future.

Of course, in the process of elaboration, a sincere and neutral attitude is helpful, after all, you may be in addition to your accusations, directed at another link or individual work up.

again, we have to put facts and make sense .

We need to know that the test itself is not omnipotent , not perfect. The seven core principles of our testing also emphasize that we should not pursue a complete test (that is, to find all the problems).

Our testing process itself is a systematic project, which itself is limited. For example, our test execution, each execution of the round is a certain time gap. In today's software development environment, the concept of continuous integration is widely used, and the iteration and increment of the system occur every day. Each of these iterations and increments has the potential to impact or even cause damage to the functionality we have already measured, and our tests cannot be overwritten with code updates that are followed every day, even if we use very high levels of automated testing to cover regression testing, and it is impossible to prevent the system function from being destroyed after our tests have been completed.

In this case, we have to elaborate, even with stakeholders to go popular with our testing concepts, testing the limitations. We put the facts-take out our test process records and defect records, to tell the relevant parties: Our test is not a problem, is to provide adequate coverage, but after our test implementation, the code again because of the new iteration introduced the problem, this is not we can control at any time.

And our system tests are performed in a test environment, and while we try to make the test environment as close as possible to the production environment, it is generally impossible to achieve full reproducibility. For example, the magnitude of the servers we use, our intranet test environment, the magnitude of our test data, and the unexpected situations that may occur in some real-world environments, we cannot fully simulate. And this difference eventually led to our system testing phase can not find some production environment problems, then of course, can not be attributed to our work mistakes. In this case, we need to clarify where the problem lies, and we can demonstrate the limitations of our test environment (such as the recurrence process of repeating the bug in a test environment, which is not reproducible in the test environment).

Again, we need to make a reasonable filing of the testing process.

The output we test is not just a test plan document, a bug report, a test summary report these things. In fact, the implementation of the test process and records is also a very important archive, testing the implementation of the process of recording, as our testing work of the complete degree of support is very effective.

In the daily work, we can also use a small period of time, our testing work to more archiving. For example, we can record the daily test work log, we can go through the mail and discussion groups to test the report summary of the process, for some of the lightweight work of the document, such as exploratory testing, random testing, we also have to list the test program and recording process; Test cases have time to write, you have to write the choreography, Even if you don't have the time to write test outlines and articles.

With these documents, we can come up with these documents and review our work at that time and use them to support the argument that we have no problem with our work.

=============================================================================================================== =========================================

All right, so much to say, I'm sure it will help you as a software test engineer, and that's what we're going to talk about.

In the future encounter such a situation, do not panic don't worry, if it is the problem we admit it is a problem, but if it is not our problem, then this pot we do not answer!

Test engineer How to shake the pot!