如何体现测试的质量/价值----新人之路系列
测试质量--------新人之路系列牢骚：
呵呵，新人之路系列已经是第四篇了，前三篇的效果很不错，得到很多人的认可，小小的高兴了下，同时也希望更多的人参与讨论，其实博文只是引子，目的是想吸引大家发表自己的看法和观点，相信从大家的评论里吸取经验吸取知识能帮助我们找到最适合自己的测试方向和方法。
正文：
我们先假设这样一个场景，注意要假设场景哦，这样你才能更好的明白我在说什么。
首先你和另一个人负责一个项目的测试，这个项目即将上线，而你们是临时调遣过来的测试人员，项目要经过你们测试后才能上线，也就是你需要对这个项目负责。
好了，问题来了，
问题1：你测试完过后，敢保证这个项目上线后不会出现严重的问题吗？
问题2：如果你能保证，那么你的底气源自哪里呢？
问题3：你怎么才能让项目经理同意的和你一样有底气呢？
这三个问题有答案了吗？继续看下去吧。
如何保证测试的质量，或者说如何来表现我们的测试质量呢？
对于一个新人，刚接触一个项目，其实项目经理并不能放心我们测试的东西，所以会经常对我们说，“你要好好测哦”，“你帮我们测一下三”“你怎么闲着呢”。对于这些问题我们其实很想回答，“我测完了””没东西测了”呵呵你敢说吗？无凭无据的你，凭什么敢说这些话。
刚开始工作时，我们部门经理对我们说了一句话“作为一个测试人员，特别是项目中唯一的测试人员，你应该做到对项目的了解仅次于项目经理，甚至比项目经理还要了解”我自信我现在做到了，怎么来判断？这里有一个很简单的方法，所谓对项目的了解实际上是指对项目中所包含的业务流程的了解，对功能点分布的了解，后面的一点，可以通过需求文档来对比，而前一点，我建议大家运用UML的技术来做判断，在UML中有9种图，其中用例图和时序图对于业务流程十分有用，如果你能够凭借自己对项目的了解绘制出时序图，并且这个时序图得到项目经理的认可，那么你后面的话语权就要大许多。这个时候你对项目的了解已经是仅次于项目经理了，在这个阶段，开发人员在遇到一些不能判断的问题时就会来询问你的意见（前提是项目经理不在的情况）。
这是准备工作，紧接着你要让自己的工作变得有价值，你要在团队中沟通，测试人员和开发人员之间本身就存在矛盾，当然理想状态两个角色都是为了项目的质量，并不存在阶级矛盾呵呵，然而实际工作中常常不如人愿，要知道你发现的Bug越多，开发人员的工作量越大，暂且不提对开发人员技术的否认让其心里不愉快，单说加班，开发人员加班通常为两个原因，1，赶进度，2，修改缺陷。在这种情况下，如何融入团队尤为重要，那么我们这样思考一下，开发人员对测试人员的不满，如果是从工作量出发，那我们就从工作量开始思考，我们先简要梳理下流程，测试人员发现缺陷，告诉开发人员。那么开发人员的工作量是不是可以拆成两个部分，一个是修复缺陷，另一个就是大家经常忽视的重现缺陷，修复缺陷我们无能为力，那重现缺陷，对缺陷进行定位这一点我们确实是可以帮助开发人员的。
首先在测试工作中有一份缺陷报告，记录了你发现的缺陷，其中包括定位信息，重现信息。请认真对待这份报告，假使开发人员或者经理对你说“你找到Bug截个图发给开发人员描述下”或者“你找到Bug就直接说，”再次强调，在这个时候，作为测试人员必须坚定自己的立场，必须要按照缺陷报告来执行测试，如果公司没有模板，那就自己设计一个，缺陷报告作为测试的中间环节，一来是为开发人员节省工作量，提高工作效率的保证，二来是回归测试的重要凭证，一份信息详细的缺陷报告绝对是一个人测试价值的最佳体现之一。
在我们的测试过程中，通常会一天提交一份却下报告，时间多为下午4点---下班这段时间。那么缺陷报告提交后是否我们就没事可做了，不然，每个人对文字的掌控不一样，每个人对文字的理解也有偏差，这个时候，我们最好的办法就是辅助开发人员理解缺陷报告，条件允许，时机合适的情况下甚至有必要帮助开发人员分析Bug的产生地，也就是对Bug进行定位，尤其是跨模块的Bug，比如从B模块取a模块的数据，这个时候就要根据我们对业务的了解，来分析这个Bug是在a模块存数据的时候就产生了，还是在B模块才产生的。不要将测试人员的工作只局限于找BUG上。
做到这一步，你基本可以赢得开发人员对你的认可，那么你和开发人员之间就不存在过多的矛盾了，你替他们省下得工作量一次两次或许不会觉得，但次数多了，他们自己心里还是明白的。
在赢得开发人员的认可后，你的工作基本已经有了一定的价值了，接下来你要获得的是项目经理的认可，怎么让项目经理认可你的工作，怎么让你的工作，让你测试的价值被项目经理认可呢。
经理关心的东西，和开发人员关心的又不一样了，所谓投其所好，那么我们来看看一个项目经理关心的东西有哪些，首先，项目的进度是无可厚非的，其次项目缺陷的修复情况也会关心下，然后，和我们相关的来了，测试的力度，项目的质量，是不是能够正常使用等一系列只有我们测试人员才能回答的问题才是项目经理本质上最关心的问题，原因很简单，如果用户使用中发现了Bug，那么很有可能会到公司来投诉，承担责任的就是项目经理本人。
假如项目经理来问我们这些问题，我们该怎么回答，切忌，不要用苍白的口述来回答。大家都知道，平时我们测试人员的工作是很清闲的，没有东西测试的时候，我们基本都在闲着，这一切项目经理都看在眼里，试问，你会相信一个一天到晚都在耍的人口头描述吗？
“这两天发现了一些Bug，有的在A模块，有的在B模块”
“这两天发现了28个BUG，其中12个在A模块，16个在B模块”这两种答案，你愿意选择那种呢？
这个列子告诉我们，数字化的作用并不是口上说说，在我们的工作中是完全可以运用到得。并且项目经理能够从我们数字化的回答中得到更多信息，以方便他对全局的掌控，而这里就衍生了一个问题，要知道我们在测试的各个阶段甚至每一天都有新的数字信息，是不可能一一记住的，这个时候一份文档就是你测试质量的体现了，学会统计文档学会分析文档学会设计文档，虽然很多人认为文档是team leader的任务，但我却不这么认为，在没有Leader的情况下，我们还是需要有这些能力，你要相信这点，项目经理不可能会讨厌一个能够替他减少不必要的工作量的员工的。
最后，总结一下，测试人员不要将自己定义成一个找BUG的机器，测试是什么？我的理解，测试就好比一根绳子，从客户到开发再到项目经理，甚至项目有可能牵连到的其他人员，我们都要将他们联系起来，也许他们彼此之间没有什么联系，但是我们却要和他们建立一种联系，我们工作时思考的角色是在不断变换着的。不能够一直守着用户的角色去找Bug。
测试人员和开发人员之间的矛盾，理想状况是不存在的，关键是看我们怎么处理，
测试人员不被项目经理重视，被项目经理认为只是找BUG，关键是在我们怎么表现出自己测试的质量，表现出自己在项目中的价值。
--------------MR.曾 很好的帖子！赞！ 写得不错 情况类似。。。 测试人员不被项目经理重视是否也因为沟通不够好呢？ 写得 不错 学习了
页:
[1]
