随着软件市场和客户需求的变化，敏捷开发模式逐渐成为重要的角色，而客户响应频繁、需求更新快、开发周期短、迭代次数多等特点，给软件设计、开发人员以及测试人员都带来了很大的压力。在这些压力之下，如何为客户提供满意、高质量的产品，已然成为我们必须不断思考、不断改进、不断完善的重大课题。
在多年的敏捷测试实践中，我逐渐摸索出一套实用而高效的测试技巧，即“心理学在敏捷测试中的应用”，通俗一点讲，就是“‘看人下菜碟儿’测试法”。
在测试每一个项目时，因每次迭代过程中的测试时间有限，测试人员不得不考虑如何制定出严密的测试计划和策略，以便在有限的时间内完成覆盖更多、更重要的测试点，为项目组和客户提供高效、高质量的服务，同时体现测试人员的价值。
在起初的工作中，我经常因为需要测试的功能点很多，而测试的时间又远远不足而烦恼（因为项目组人员较少，测试人员比例又非常低，每个测试人员需要负责的范围很大，甚至在曾经的一段时期内只有我一个测试员，同时“伺候”四个开发程序员）。为了解决这个烦恼，我就千方百计地想找到一个“讨巧”的办法来提高测试效率。
心随意动，从缺陷报告中我渐渐发现，造成缺陷的原因有很多种，而以下几点则为导致绝大多数缺陷的主要原因：（1）需求本身就存在问题，而客户和我们都没有发现；（2）需求设计人员对需求的理解和客户不一致；（3）编码人员没有充分理解需求就开始编码；（4）由于编码人员的粗心大意。而（3）和（4）则为主要原因之重点原因。
我决定，就从这两点入手，想方设法提高测试效率。经归纳可以看出，原因（3）和（4）是人为的因素占主导。再仔细揣摩，之所以在开发编码过程中出现这类问题，跟编码人员的性格和经历有着很大的关系。因此，我便根据所要测试模块的编码人员的个性特点，制定出一套具有针对性的个性化的测试执行策略。换句话就是说，对待不同的编码人员，我便持不同的测试重点，对症下药，“看人下菜碟儿”，去测试他们的代码：
1. 对待粗心的编码人员
在执行测试这类编码人员的代码时，除了功能的大流程以外，测试重点应该放在功能的一些细节上，如：取值、赋值的数据类型；计算的边界值；参数的默认值；UI显示上的错别字，等等。
2. 对待喜欢“投机取巧”的编码人员
代码复用是很正常的，也是很提倡的。合理地提高代码的复用性，会提高很多开发、维护效率。但是，不合理的复用就会造成系统缺陷。有些程序员在发现要开发的模块和某个已有的模块很相似的时候，会主观地想直接挪用已有代码，而看似相同的功能在不同的前提环境下，可能有不小的内在变化。如果这时这个程序员只是直接把已有的代码简单复制过来，忽略了那些细小的差异，比如：参数的默认值，取值范围，输出格式等等，这就会造成缺陷，有时甚至是一些隐藏的缺陷。对待这样的“懒人”，我们就得像对待“粗心的朋友”一样，格外注重细节。
3. 对待有主见的编码人员
对待此类编码人员，测试人员就要十分注意他对需求的理解问题，因为这类编码人员可能经历过很多项目，在这个过程中难免就会形成一些思维定式，而这类人员又十分有主见（有时是固执）。所以，其很有可能会对当前的需求有更多自己的臆想，而这些臆想往往极有可能偏离客户的需求。测试这样的代码，尤其是涉及系统的新功能时，就要重点查看功能主线流程是否符合客户需求。因为有时他们在开发过程中，从需求出发点就跟客户有偏差。可以想象，从一个不正确的点出发，就可能在后续的开发中造成“差之毫厘，谬以千里”的谬误。此时，即使代码的算法再精妙，关键点处理得再完美，而它本身已经不是客户原来想要的那个东西了。
4. 刚入项目组，对以往的需求不了解的编码人员
因为敏捷开发模式的需求更新很快，有的功能和过去的需求相比，可能变得面目全非。如果这个项目组在需求的管理上又有些缺欠，这样就会造成新进项目组的成员，在了解需求、熟悉系统的时候遇到很多问题。因为开发进度快，这类员工有可能必须很快就参与编码。在测试这样的功能、代码时，模块间的接口、数据承接就是一个重点。除去他签入或修改的模块本身，和这个模块有关的重要的模块都必须要做一定程度的覆盖走查的。除此之外，在项目进展过程中，项目组对系统的一些约定俗成、潜在标准，如UI的统一规格；数据类型的显示格式之类的问题也是我们要关注的。因为这些问题，有可能没有在文档或其他地方显性的标记出来，所以这些新加入者根本就不知道。
在此我要申明的是，这些测试技巧是在实施测试（跑Case时）的策略技巧。它可能帮助我们在有限的时间内，有针对性地尽早找到更多的问题，以期能在版本发布时提高系统的质量。在制定测试计划和设计测试用例时，我们要尽量全面地思考要测试的所有功能点或性能点，切忌因为这些个性化的测试执行策略，而使我们的整体测试思维狭隘化，那样就真成了投机取巧，甚至会给项目组和客户造成很多的问题或损失。
在长期的实践中我发现，这些有针对性的测试，不仅可提高测试人员的测试效率，甚至在不知不觉中，能促使一些不同性格的编码人员，在一定程度上改正自己的“毛病”。平时比较粗心的人，慢慢在编码时开始注意细节；那些自我思维较强的人，开始注重对需求的理解，逐渐减少自己在开发中的主观臆断；新员工在测试人员的不断提醒下，可以更快地加深对系统的了解，尽量减少那些因牵一发而动全身的问题。这不仅仅是对系统、功能或代码这些没有生命的东西的测试，也是对人、对开发流程的测试。这样，能更好地提高软件质量。
发现问题需要方法，解决问题更是需要方法的。测试人员参与解决问题的最重要的方法就是缺陷报告。在紧张的开发过程中，尤其是在发版之前的测试，对当前发现的问题或缺陷，直接把它们上报到缺陷管理系统上似乎不太适宜。而这些问题又必须要及时通知相关开发人员，让他们尽早处理，那就要用更快、更高效、更恰当的沟通方式。就是说，这些通知方式在选择时，也是可以根据不同的开发人员性格，使用不同的方法，“看人下菜碟儿”的：
1. 针对性格开朗、为人和善，便于沟通的开发人员
对于一些急需解决的问题，我们可以减少文字的东西报告，适宜当面指出或直接给他演示出发现缺陷的步骤。如果是那些对系统有一定了解的项目组老员工，一个简单的提示就能告诉他们，系统哪儿哪儿有了问题。如果在他们比较忙手上还有其他工作的时候，给他们一个简单的问题描述信息（如：用MSN、Skype、QQ或飞鸽之类的即时通信工具）即可。
2. 针对性格比较自我、固执，不易言语沟通的开发人员
对待一些不太喜欢只是用言语或简单操作来接受问题的开发人员，我们就必须用一个文档的形式。这个文档可以比较简单，但一定要清晰。在发现Bug的步骤中最好能配上相应的截图，这样就可以在积累多个问题（Issue）后直接发送给相关开发员。这样他可以通过文档了解到出了什么问题，然后再更新文档中问题的状态来通知你问题解决与否。这样，方便测试人员及时验证问题是否已经修正或是否引出新的问题。
最后我想说，在软件测试领域，不论是什么样的理论或技巧，终极目的都是想在有限资源、有限时间的情况下，尽量多、尽量早地发现缺陷，然后协助程序员尽快解决问题，以此完善项目组所承接的客户需求的系统、软件，为客户提供高效、高质量、满意的产品或服务，为公司提高经济效益。同时，提升自己的效能，享受工作所带来的乐趣和成就感。
