最近在测试一个系统，在这系统开发完成进入测试阶段时，作为一个开发人员惯性思维就是”直接上手测试“，但现在因制度的要求，在测试前必须先编写测试文档，于是就尝试着以测试人员的眼光来看这个系统，编写相应的测试用例和脚本；现在看来在这个过程没有白费，并且还有了三个方面的收获：
1> 思考永远先于动作：开发人员应该都有过这样的感觉，就是在拿到需求的那一刻，大脑已经能想到10步之外的代码是长什么样子的了，然后就有一种”赶紧让我去敲代码吧“的冲动。在我们完成一个具体动作时，即使直接上手去做，那也是在动手的那前几分钟在头脑中有了简单的、如何做的思路。即使我们可以做到不写文档、不写设计也能完成；就像这次测试一下，我心里清楚这个系统的重点、难点、以及可能翻车的地方在哪，所以也就有了直接测试不写用例的冲动。
2> 思路应当落于纸上：我们的思路，往往是有漏洞的、是不够严谨的，尤其是在开发人员，接到需求就打算上手就去做的时候，漏洞可能更大，即使你能想到10步开外的代码。由于思路没有落于纸上，我们就很难及时发现其中的遗漏，往往会做着做着发现不对头了，此时掉头修正代价就比较大了。而这次在编写测试用例时，就出现了这种情况，在编写用例过程中，写着写着，突然想起前面有的地方测试点或方法不太对，然后立马再回头修改，好在这是在将思路落于纸上过程，而非真实测试，否则过了测试点，测试数据可能早被后续的测试步骤破坏，又需要重头开始。本以为前面可以节省的时间，在此时可能又被找补了回来，可能倒贴的更多。
3> 非重点区域原来也是死角：通过本次测试发现了另外一个现象，本以为重点难点的地方，BUG反而更少，而非重点区域出现BUG则较多。这可能是源于开发人员习惯性的在解决了重点难点之后，会小看一眼那些边边角角的功能心理吧。
需求分析师眼中的重点、开发人员开发上的难点，和使用者体验点是不同的。
需求分析师认为的重点更多的是基本的业务需求，也就是系统能不能上线、能不能完成交付的必要条件。
开发人员开发上的难点在于所需要用到的技术、复杂的业务逻辑，以及要花费较长时间去开发的功能。开发人员认为的难点在业务人员眼中，有时会觉得这是很自然普通的事情。
使用者体验点是：主要的业务逻辑必须是正确的，这是对研发团队能力的基本要求；而边边角角的功能出了问题，反倒有可能影响使用者对研发团队的看法。除非系统上有锦上添花的功能，能够做到“逸美遮百丑”的能力。
所以我们在测试和评价一个系统的好坏时，要更多的从使用者的眼光出发，直到自己先满意为止。