近一段时间，我尝试将探索式测试应用到日常的工作中。下面是我的一些体会。

      首先我会找出一张纸和一支笔，将要测试的功能点一一列出。然后我会从近一段时间内的bug fix，例如说两周，找出影响这些功能点的bug fix。从dev给出的bug fix的comment中或release note中尽可能从代码层上去理解dev如何修这个bug，以及修正这个bug可能会带来的影响。根据以上的信息，去丰富和完善每个功能点具体要测试的内容，形成一份test outline。接下来根据这份test outline进行测试。测试过程中会得到一些反馈，例如根据反馈，你可能会知道test outline中的哪些内容需要进一步扩展，哪些内容不需要花更多时间进行测试。利用这些反馈对之前的test outline进行修正，然后根据修改后的test outline进行更进一步的测试。

      探索式测试给我的感觉是QA在测试过程中要不断的根据当前测试过程中所掌握的信息去修正测试用例或test outline，然后根据新的测试用例或test outline进行更进一步的测试。在探索式测试的过程中，每一次迭代都会使得QA更接近所要找寻的bug。我通常会将整个探索式测试的过程控制在4－6小时之内。

2：从用户报告的问题开始

近产品发布了，随之而来的我接触到了一些用户报告的一些问题，有一些感触：

1. 某些用户对产品的了解程度之深令人印象深刻。有些用户是我们的产品的老用户了，他们之中有些人从我们的第一代产品开始使用，对于产品的了解程度比我都要深刻。

2. 根据用户报告的问题，有时候可以直接复现bug，但是更多时候，用户提供的信息不准确或不完全，也许遗漏了对于复现bug关键的信息，这时候我会尝试将用户提供的信息看作一个测试用例，然后对其测试，试图narrow down出这个bug。并非总能复现用户报告的问题，不过在这过程中也许会发现其他的问题。

3. 这次产品发布后，我看了一些用户的评论，有好评，也有差评。从这些评论中，我了解到了用户喜欢产品中的哪些特性，不喜欢哪些特性。这些信息对于产品质量的改进，以及新产品的开发都有帮助。

4. 近在用户的论坛上潜水，相比用户直接报告上来的问题，论坛上讨论的内容更加广泛，更加真实的反映了用户使用产品的情况。这条有点偏题了，呵呵。