- 清新的眼光会发现问题
- 对产品越熟悉，越容易对产品的问题理所当然，而忽略其不合理性
- 第一次接触功能时，留意让自己困惑的地方
- 与新成员一起测试时，观察他们了解产品的反应
- 警惕陷入测试惯例（对特定功能太熟悉而忽略测试，注意增加测试多样性或者让其他人员测试）
- bug的相关经验
-
小缺陷值得报告和修改
-
极端用例要关注（包含程序员常说的：用户不会这么用）
-
看似极端的缺陷是系统潜在的漏洞
-
设计缺陷要关注
-
提高提交缺陷报告的质量
-
bug管理系统不能作为程序员和测试员的评估系统
-
明确严重等级和优先级之间的差别
-
发现小缺陷后，进行后续测试，确定是否会引起严重问题
- 改变操作方式，改变条件，继续测试
- 改变程序选项或设置
- 改变软硬件环境
-
永远都要报告不可重现bug，这些可能是定时炸弹
-
考虑缺陷报告的处理成本
- 缺陷报告要耗费测试员、程序员、产品经理等很多人的时间
- 对小缺陷尽量简洁明了或者打包处理等
- 不可重现缺陷一定要努力重现，实在重现不了，要标明不可重现，且标明定位工作及程序表现
-
慎重处理个人版本或原型版本的测试缺陷
-
重复的bug内部处理
- 达成共识
- 提交bug报告时自己判断是否重复
- 程序员快速修复
-
每个bug都需要单独报告
- 原则上是一个bug一份报告
- 将bug现象分类
- 避免重复bug
- 避免bug被掩盖而得不到修改
- 验证bug时，确保每个bug都得到修复
-
bug标题要简要且包含足够重要信息
-
- 测试实践中发现的问题：
- 提交bug，研发不予修改，认为是客户不会这么用
- 测试范围，内部说送测范围之外的缺陷不予处理，但是客户现场会测试，会反馈bug
- 难以重现的bug处理
- 沟通问题：在非送测版本中发现的问题，不被程序员认可，或者说已经在新版修改，从而不同意将问题记录在bug管理系统中。
- bug数量用于评估测试员的绩效，导致大量重复bug及无效bug
- 验证bug时，不能有效扩展
- 工作任务繁重，工作时间紧张
- 验证bug的工作不被重视，不如发现bug的工作有吸引力
- 测试工作和个人技能提升之间的平衡
- 测试自动化
- 测试自动化实践中的问题
- 自动化覆盖率低
- 回归测试（冒烟测试）
- 单元测试
- 自动化用例有效性低（不能发现程序缺陷）
- 测试设计不科学，为了自动化而自动化
- 自动化覆盖率低
- 测试自动化实践中的问题
- 如何评估测试员的工作质量
- 阅读缺陷报告（报告质量、发现bug是靠运气还是能力、测试执行的力度、缺陷挖掘的深度）
- 阅读编写的代码
- 阅读测试文档
- 收集程序员或其他相关人员的意见
- 如何指导新员工开展工作
- 熟悉工作环境
- 熟悉产品（产品手册、安装使用产品）
- 熟悉测试方法（阅读bug、修改bug、验证bug）
- 熟悉基本工作技能
- 参与新项目的测试
- 要预留培训新员工的时间
- 如何管理项目
- 要有话语权，先树立自己的权威或者走上领导岗位
- 说话注意分寸，尽职尽责，但要注意沟通方式
- 建立实际有效的测试流程，并遵守
- 要客观对待项目经理等人的决策，不能仅在测试角度
- 做好分内工作（测试环境整理、测试工作准备等）
- 好的测试计划便于后期变更
- 不要编写维护成本很高的测试文档，文档要简洁
- 手工测试或自动化测试要充分考虑扩展性
- 构建可重复使用的通用测试
- “足够测试”意味着“有足够的信息供用户做出决策”
- 何时停止测试
- 有理由相信程序仍然有未被发现的严重问题的可能性很小时
- 判断测试是否充分的因素
- 测试员知道产品的不同模块如何表现出严重问题
- 测试员知道要发现的重要问题的种类
- 测试员对产品做了与这些风险相应的检查
- 测试策略具有合理的多样化，以避免视野太窄
- 测试员使用了所有可用的资源进行测试
- 测试员尽可能的清晰表达测试策略、测试结果和质量评估
- 何时停止测试
- 承担工作的人应该告诉项目经理执行任务需要的时间
- 防止项目经理低估委派的任务
- 测试计划更合理、可行
- 调整任务和不能胜任的人员
- 测试组内的人员技能背景不一样，要人尽其用
- 转换测试员的测试对象
- 避免测试员的工作厌烦
- 避免测试员工作内容太专，降低人员价值，注意培养多面手
- 减弱测试员的不可替代性，提高团队抗风险能力
- 不同测试员的测试思路和思维方式不同，对测试内容形成互补
- 成对测试
- 为项目指派一名查找问题高手
- 确定测试的阶段计划，特别是探索性测试的阶段计划
- 分阶段测试
- 定期状态报告（测试报告）
- 关键问题（所需的决策、需修改的bug、意外问题等）
- 测试小组完成计划任务的进度
- 提供bug报告统计数字
- 本周被延误的bug
- 测试报告重点描述测试工作和结果