4、刚入项目组，对以往的需求不了解的编码人员
因为敏捷开发模式的需求更新很快，有的功能和过去的需求相比，可能变得面目全非。如果这个项目组在需求的管理上又有些缺欠，这样就会造成新进项目组的成员，在了解需求、熟悉系统的时候遇到很多问题。因为开发进度快，这类员工有可能必须很快就参与编码。在测试这样的功能、代码时，模块间的接口、数据承接就是一个重点。除去他签入或修改的模块本身，和这个模块有关的重要的模块都必须要做一定程度的覆盖走查的。除此之外，在项目进展过程中，项目组对系统的一些约定俗成、潜在标准，如UI的统一规格；数据类型的显示格式之类的问题也是我们要关注的。因为这些问题，有可能没有在文档或其他地方显性的标记出来，所以这些新加入者根本就不知道。
在此我要申明的是，这些测试技巧是在实施测试（跑Case时）的策略技巧。它可能帮助我们在有限的时间内，有针对性地尽早找到更多的问题，以期能在版本发布时提高系统的质量。在制定测试计划和设计测试用例时，我们要尽量全面地思考要测试的所有功能点或性能点，切忌因为这些个性化的测试执行策略，而使我们的整体测试思维狭隘化，那样就真成了投机取巧，甚至会给项目组和客户造成很多的问题或损失。
在长期的实践中我发现，这些有针对性的测试，不仅可提高测试人员的测试效率，甚至在不知不觉中，能促使一些不同性格的编码人员，在一定程度上改正自己的“毛病”。平时比较粗心的人，慢慢在编码时开始注意细节；那些自我思维较强的人，开始注重对需求的理解，逐渐减少自己在开发中的主观臆断；新员工在测试人员的不断提醒下，可以更快地加深对系统的了解，尽量减少那些因牵一发而动全身的问题。这不仅仅是对系统、功能或代码这些没有生命的东西的测试，也是对人、对开发流程的测试。这样，能更好地提高软件质量。
发现问题需要方法，解决问题更是需要方法的。测试人员参与解决问题的最重要的方法就是缺陷报告。在紧张的开发过程中，尤其是在发版之前的测试，对当前发现的问题或缺陷，直接把它们上报到缺陷管理系统上似乎不太适宜。而这些问题又必须要及时通知相关开发人员，让他们尽早处理，那就要用更快、更高效、更恰当的沟通方式。就是说，这些通知方式在选择时，也是可以根据不同的开发人员性格，使用不同的方法，“看人下菜碟儿”的：
1、针对性格开朗、为人和善，便于沟通的开发人员
对于一些急需解决的问题，我们可以减少文字的东西报告，适宜当面指出或直接给他演示出发现缺陷的步骤。如果是那些对系统有一定了解的项目组老员工，一个简单的提示就能告诉他们，系统哪儿哪儿有了问题。如果在他们比较忙手上还有其他工作的时候，给他们一个简单的问题描述信息（如：用MSN、Skype、QQ或飞鸽之类的即时通信工具）即可。
2、针对性格比较自我、固执，不易言语沟通的开发人员
对待一些不太喜欢只是用言语或简单操作来接受问题的开发人员，我们就必须用一个文档的形式。这个文档可以比较简单，但一定要清晰。在发现Bug的步骤中最好能配上相应的截图，这样就可以在积累多个问题（Issue）后直接发送给相关开发员。这样他可以通过文档了解到出了什么问题，然后再更新文档中问题的状态来通知你问题解决与否。这样，方便测试人员及时验证问题是否已经修正或是否引出新的问题。
最后我想说，在软件测试领域，不论是什么样的理论或技巧，终极目的都是想在有限资源、有限时间的情况下，尽量多、尽量早地发现缺陷，然后协助程序员尽快解决问题，以此完善项目组所承接的客户需求的系统、软件，为客户提供高效、高质量、满意的产品或服务，为公司提高经济效益。同时，提升自己的效能，享受工作所带来的乐趣和成就感。
版权声明：本文出自 shan0310223 的51Testing软件测试博客：http://www.51testing.com/?624630
原创作品，转载时请务必以超链接形式标明本文原始出处、作者信息和本声明，否则将追究法律责任。
