在探索性测试中发现有效问题的良好做法？

#1 楼

30种改进探索性测试的良好实践


使用错误跟踪系统

使用值的边界测试
考虑使用测试角色

使用快乐，悲伤和可选的路径
熟练阅读服务器日志

了解可用性和可访问性

学习使用仿真器和模拟器

了解有关客户需求的更多信息
出现在业务流程会议中
维护易于使用的设备库
亲自询问直接的产品问题
了解公司质量指标
与产品经理建立良好的关系
了解业务领域和关键因素
了解视觉，听觉和触觉障碍
了解数据库的设计和实现
/>
了解内部和外部业务流程
使用价值主张确定要报告哪些错误
获取应用程序工作流程和功能的文档y
学习使用本地虚拟化，例如Parallels，VirtualBox等。
以与业务相关的方式对错误严重性进行分类
了解有关本地化和国际化的相关知识

学习和使用远程服务，例如浏览器堆栈和saucelabs
熟练使用控制台和检查器之类的浏览器工具
将自动化用于重复性任务，并由人员发现其他变化
复制真实的用户环境以实现网络速度，阳光，热量等
确保用于探索性测试的系统紧密模拟生产
使用公司数据来确定客户使用哪些设备和浏览器
使用集成良好的“即插即用”系统*来截取屏幕截图和链接
获得各种生活经验，帮助思考不同的方法

对于敏捷民俗人士：


* Mac的CloudApp是一个很好的例子

#2 楼

就个人而言，我真的很喜欢基于以下三种成分进行探索性测试：

时间盒


测试人员获得的时间
可以进行计划
团队决定每个sprint /周/天等。
也允许对其他人（例如开发人员或领域专家）进行精益的手动测试
测试人员非常专注（发现错误的机会更高）
>
示例：通常在30到60分钟之间。

协议


所以我们知道已经测试过的内容
有助于持续改进手动测试技能
过去有用，什么没用？
回到过去，看看为什么我们没有找到特定的错误
重用功能强大的测试用例或使它们自动化
帮助加入新的团队成员

示例：

Scope: XYZ creation wizard
Tour: landmark
Timebox: 60 minutes

Test cases:

1) open wizard - object selection dialog opens - C
2) go through all steps in order (1, 2, 3, 4) - arrived at final step - C
3) jump around on navigation bar: 3, 5, 2 - crash - B

Opportunities: (C)orrect, (B)ug, (?) open question

测试之旅


描述如何SUT应该经过测试
由Microsoft开发，并被许多其他公司所使用
独特且易记的名称可以改善沟通方式
允许测试人员即时提供新的测试用例
太开放而没有游览（没有重点，控制更少）
迅速成为团队词汇的一部分

示例：


地标：不同顺序中最重要的特征
反社会：总是做相反的事情
垃圾收集器：一条街一条街，一个房子一个路走
超模：仅限用户界面


请注意，这只是宽松的准则。例如，有些团队可能喜欢Git版本的Markdown文件作为其协议，而另一些团队可能更喜欢私有云中的Excel工作表。请随时根据团队/部门/公司的需要调整整个过程，同时牢记基本思想。

要进一步阅读，我可以推荐以下文献：


James A. Whittaker：探索性软件测试：指导测试设计的技巧，窍门，导览和技术
Cem Kaner，Jack Falk和Hung Q. Nguyen：测试计算机软件
Cem Kaner，James Bach，Bret Pettichord：从软件测试中学到的经验：一种上下文相关的方法

#3 楼

定期组织讲习班，演示在先前的探索性测试会议中如何发现一些错误，是什么导致这些错误被发现？


是的，绝对是个好主意。我碰巧一直在想类似的事情。请阅读以下要点：
建立一个讲习班/演示如何以变量显示对象的研讨会将特别有用。概括而言，测试就是一次更改一个变量并观察结果。如果我们可以将被测对象可视化为其组成变量，那么我们甚至可以一次调整一个变量。这种做法将接近系统的探索性测试。我之所以说“接近”，是因为我们将永远无法以所有可能的方式系统地测试每个变量。

维护潜在探索性测试思想的共享页面/笔记本


我个人认为这不是一个好主意。根据我的个人经验，IT公司尝试保留测试想法的纸质副本，但没人会阅读它们。原因如下：
手写/语法不好，令人惊讶的是，并非每个人都认真地写下自己的想法，以便将来其他人可以阅读。多数情况下，人们的笔记过于混乱，以至于他们甚至在两周之内都无法阅读自己的笔记。
人们有不同的构建逻辑的方式。很难从阅读笔记中复制/粘贴某人的逻辑。
当然，可以对想法笔记进行审核，以确保他们清楚地传达了想法，但是再次，要有人进行评论/编辑笔记会浪费资源。这不是每个IT公司都想付出的代价。
我推测，简短地讲一下如何发现有趣的错误/如何通过意外方式发现错误，然后将这些故事发布到办公室并定期替换它们可能是个好主意。当人们沿着走廊走时，故事会引起他们的注意，并且灯泡可能会点亮。

以“自由”方式进行配对测试


是的，这绝对是个好主意。它不仅限于配对测试，还可以参与整个团队。

将人员安排在需要不同知识库的不同项目中



知识库，不同背景提供不同观点。

使测试人员与客户坐在一起


测试人员可能不会像客户那样使用某个软件。

#4 楼

了解技术。

如果他们测试Web应用程序，请确保他们了解JS，HTMl和CSS的工作方式。也许让他们做一些项目。如果他们不知道如何注入JS，就不能指望他们测试XSS漏洞。如果您对底层技术的工作原理有所了解，则可以选择输入内容尽可能邪恶，如果您知道后端在用户名中的表情符号中使用了过多的python抛出，并确保已将其设置为正确的编码，如果它使用Java及其本地utf-8支持，则可能不是需要测试的问题。

在我的团队中，我想让他们扩展我们的Intranet质量检查服务，以定期安排测试，组织列表等。这样，他们就可以感觉到可能出了什么问题，并将他们的问题转移到我们产品可能存在的问题中。

#5 楼

为了更好地进行探索性测试，测试人员必须知道他们正在工作的系统，他们应该对系统有广泛的了解。并有一定的智商水平。同样，经验是事实，就像一个测试人员的经验一样，也会发现很多好的错误。