摘要：作为软件测试人员不再仅仅是发现bug。还应关注持续改进，定义明确的测试策略，并且为提高质量而加倍努力。遵循一致的，结构化的质量保证方法将帮助你获得更多关于所测的产品知识，问一些你可能没有想到的问题，并成为质量的真正拥有者。
测试人员的角色随着行业技术的变化以及向敏捷方法的转变而不断发展。这种转变为测试人员打开了未知的、激动人心的、挑战性的测试机会。通过我个人的经历，我们来看看这种转变对测试人员的职业生涯意味着什么。
旧的方式：只需找到bug
我作为测试员的最初几年缺乏批判性思维。每天早上，测试小组都会收到一份审查申请表。分配资源安装应用并试图破坏功能。
我们的绩效评估很简单：发现的bug越多，就越漂亮！没有思想，没有战略，没有动力。我们的休息时间里讨论的是每个人发现的bug数量，而不是那些bug的质量。
这让我思考。我们带来了什么价值？我们应该漫无目的地测试以发现bug吗？我有太多的问题没有答案。
开发QA过程
我的下一份工作改变了生活。作为测试功能的一部分，QA团队还将调试，分析堆栈跟踪（Stacktrace），并向开发人员提供问题的根本原因。每个人作为有共同目标的团队一员而合作，令人耳目一新。
我意识到测试人员不仅仅是一个试图破坏工具的人，而是一个团队成员为整体努力做出贡献的人。随着测试人员轮换到不同的团队，我们优先考虑不断改进自动化和深入了解每个组件。我对QA有了一个完全不同的观点，并对这个角色带来了多少附加价值表示了新的尊重。
在我的下一个职位上，当我开始时，我立即与QA架构师配对。那时我不知道这种指导会对我产生深远而持久的影响。我意识到遵循更加结构化的质量保证方法的重要性。在QA架构师的帮助下，我磨练并完善了改进QA流程的四种策略。
1、评审设计和架构文档
如果有设计和架构文档，请阅读它们，尽可能多地了解测试中的产品这是一个好主意。你会惊奇地发现，对产品的体系结构、集成组件和数据流的理解比单独测试要多得多。记笔记并画出你正在测试的内容和系统交互的方式。
2、研究过去的缺陷
以过去了解现在。了解风险区域和最易受影响的功能是非常重要的，这些功能可能会在每次更改时破坏应用。这些数据可能来自缺陷的历史。
对缺陷工具进行一些研究并分析过去的缺陷报告。从这种分析中得出的任何可预测的模式将有助于在这些区域开发更多的自动化。如果有客户报告的缺陷，也请分析它们。这个练习将帮助您决定各种版本的测试策略。
3、分类缺陷
QA发现一个问题，并报告它。但是工作还没有完成，你可以通过提出一些额外的重要问题来超越。还有什么可以做吗？你知道为什么发生这个问题，是什么引起了这个问题，哪个提交可能是问题所在？
这不仅仅是开发人员的工作。你可以访问日志文件、提交和代码，因此你可以进行一些挖掘以帮助解决问题。取决于你的技术水平，你可以尽可能深入。但在高层次上，请查看日志中的异常情况。它是空指针异常吗？这与特定的数据或步骤有关吗？
缩小问题范围，并与开发人员进行交谈。他们将感谢这详细的信息和研究。
4、超出报告的问题
不要只关注测试功能。还考虑应用的后端和前端交互。
例如，当你测试监视日志时，应用程序可能按预期工作，但在后端会出现一些错误。日志是否足够详细？是否处理了异常情况？对于浏览器交互，请在浏览器中打开开发者工具并监控网络组件。响应是否比预期的要长？在访问应用的某些部分时是否有任何不需要的请求？
所有这些问题都可以让测试人员超越他们所指定的测试范围。并鼓励与产品负责人和开发人员进行讨论，他们可能没有想过其中的一些场景。
在寻求产品差距和解决方案的时候，保持敏捷思维至关重要。测试中的一个重要教训是积极主动，而不是被动反应。你所发现的bug可能是问题或技术问题，但是通过得到答案，避免了那些可能没有被注意到的错误，或者是以后出现更严重的问题。
由ruink翻译自 Praveena Ramakrishnan 的《4 Strategies for a Structured QA Process》一文。