If you have done well in the previous stages, you will not find a bug when you are in the exploratory testing phase.

First, ask a question:

If a lot of bugs were found during the exploratory testing phase, was the AC written in the previous card not exhaustive? Or is the card when the QA, development, BA and other people discussed not in depth?

Well, I'm going to change the question, if it's done well in the previous phase, will it not be found in the exploratory testing phase?

For this question, my idea is:

There are more than 10 people in a development team who are using the same research and development process, and the AC in each card is as detailed as possible, but you can see that the number of people who have been developing for about 10 years and 2 or 3 years of development experience has a very large difference. My question is, why the same process, the AC description of similar cards, the level of detail, for the development of different years, there will be different number of bugs?

In fact, from a human point of view, for the same paragraph different people will have different understanding, 10 years of experience and 3 years of experience will be different, these differences may include the development of years of understanding of the software architecture, code best practices and so on. If we want to help people with 3 years of experience in AC to notice all these points, it is not impossible, but there are too many comments to be written on the card, this is a lot more difficult to do in real work, for example, a login scene of the test brain map, where there are forty or fifty coverage points. Even if we write these forty or fifty test points to the card, how much time does the test take to write the card, and how much time does development take to remember? In addition, as a QA to get a new feature, it may not be able to think of all the scenes, this is because of the second problem below.

Second question, we qa ourselves in the card kick off is not necessarily want to all kinds of scenes, because this time there is no software system, lack of system feedback. QA also needs to contact the system, through various inputs, observe the output of the system, and then predict those points may be defective, and then continue to drill down to give a specific input, see if there is a bug.

So my conclusion is that we try to make the output of QA work before testing, to avoid some bugs, but we need to do a detailed exploratory test to verify that the system is not a bug.

(Finally, there is a digression, in fact, if we can help the entire development team to improve self-test ability, is a very effective way to reduce the bug.) My practice is to write some test blog, at the session and we discuss together, and then develop a pair test, you will find that the development and your pair test test ability is also very high. Now I have some other ideas, and I'm not going to start talking about it. ）

If you have done well in the previous stages, you will not find a bug when you are in the exploratory testing phase.