我要告诉测试新手的
前言因为已经带领和训练测试团队多年，所以按惯例我总有些东西确定需要传达给测试新手。不管你是一个测试新手还是一个经验丰富的测试专家，都有不少有益的东西需要牢记在心。1、你是一个检查者，你不需要为质量负责很多测试人员误入歧途，不明白他们是评测产品的而不是控制产品的。这两者之间有着天壤之别。例如，一个测试团队花费好几周时间测试并发现很多缺陷，只是为了看着管理层决定发布一个有已知严重缺陷的产品。测试团队经常会感到士气受挫，置疑他们测试的目的。我询问团队中的成员他们是否被支付薪水了，通常得到的回答都是“是”。我又询问他们是否尽力去做工作了，再一次，通常得到的回答都是“是”。我于是告诉他们，“你们做了你们的工作。你们尽力测试，发现了缺陷并进行了上报。那么现在可以回家休息了。实际上，作为一名测试人员唯一失败的地方是不上报一个已知的缺陷。”这不会提高士气，但却有助于事情向正确的方向发展，特别是能让人不用每天晚上都在家接着办公。很多测试人员，包括我，当我们刚开始测试工作时，似乎会觉得自己对我们所测试的系统应用的质量负责。尽管这个工作的出发点是让人钦佩的，可实际上我们测试人员对于产品的质量基本没有控制能力。也是由于这个原因，测试人员不为质量负责。现在问题是管理层并不总是能看到这种区别。所以经常看见管理层提出类似于“我们付钱给这些人不是为了获得高质量的软件吗？”的问题。2、缺陷都是有价值的每一个缺陷都是深入了解和提高的机会。我们可能只有一次机会观察到一个缺陷，所以我总是告诉测试人员始终保持高度注意力，不要为测试的乏味所折磨。缺陷信息可能是可获取的项目数据中最有效的资源之一。但是这都取决于我们能多好的捕捉和传达我们所发现的缺陷的相关信息。每个缺陷都会花费整个组织的金钱。如果我们不能从中更进一步了解产品，我们会浪费大量时间和金钱。当我们把一个错误转换成一次深入了解的机会时杠杆作用就出现了。让我们面对它――有些教训只能通过经历来学习的。由于一个缺陷而责备谁不会有任何好的作用。责备只会让士气低落、沟通中断。这就像不断鞭打一匹死马希望它能活过来一样。3、你报告第一个问题之前一切都是美好的这就是一个测试人员所面对的现实。你可以计划测试，获取所需要的资源，看起来所有人都站在你这边。可当你报告第一个问题之后，事情就开始变得紧张了。出现这种态度上的突然变化的原因是现在你在批评某些人的工作了。自尊心使得自我收到伤害，关系变得紧张。有些情况下自尊心是值得期盼的，只要知道当你开始发现问题的时候态度有可能变化就可以了。我经常建议测试人员做的一件事是读一读一些你过去写的缺陷报告，假设自己是接收缺陷报告的人。你会发现自己需要更老练一些。写一个没有任何挖苦语句的缺陷报告可能没什么乐趣，但它的确有助于和开发人员之间保持一个好的关系。4、 只能测试你能观察的你可能总想测试一些真正有创造性的用例，但如果你没有办法观察到结果，那有什么意义？尽管有些应用让你能观察到很多，但仍然有你没办法接近的，例如结构、隐藏的对象、后台进程等。5、 别忘记你是怎样到一个地方的我不是在谈论知道为什么你走进一个房间，而是在测试时执行的步骤。对于测试新手常见的是发现了一个重大的缺陷，但却无法复现它以便定位解决。这样你只会觉得不舒服，不知道自己到底是真发现了一个缺陷，还是说仅仅是错误的使用了应用。你能用来跟踪你的测试步骤的方法有测试脚本、测试记录、敲键记录器如Spector和屏幕视频捕捉工具如Hypercam。6、 标准和流程是你的朋友尽管标准和流程让一些人觉得受限，但它们为你的工作提供了有价值的指导。不要拒绝标准因为它们是详细的、具体的。因此用它们指导自己更快、更一致的完成自己的工作。7、 没有足够的时间用于测试几乎每一个测试人员都抱怨没有足够的时间用于测试，但实际情况是测试任何东西到完整的程度都是不可能有充足时间的。当你充分考虑软件的特性如可用性、安全性、兼容性、互操作性等时这一点尤其正确。不要再抱怨缺少时间，学会根据风险来进行优先级排序，把注意力都放在对管理层很重要的应用目标上。有时候我们测试的内容超出了我们需要测试的，因为我们的目标偏离了产品的价值。8、 你不可能发现所有的缺陷如果你测试的东西后来有缺陷被发现，不要变得气馁。你可能已经做了非常全面的工作，获得了高水平的缺陷移除，但100%都是不可能的目标。9、 保持幽默感和对前景充满信心经常微笑、保持健康可能是你最好的生存方式。如果你正处在困难条件下，请相信，这一切都将过去。10、 争取做到最好而不是完美测试新手经常会陷入追求完美的过程中，认为100%的正确才是标准。我曾经也是受害者之一，但要为自己辩护的是，我以前深受80年代后期类似于“99.9%还不够好”的TQM帖子和文章的影响。追求完美的问题在于它会让测试进程变慢，将担心引入你所做的一切，使得你对别人更挑剔，而且通常会让你的朋友和家人感到失望。当然，没人愿意犯错误，但他们稍不注意就出现了。想不犯错误就是否认现实。争取做到最好是一种好的习惯，表明你对工作的态度和投入程度。如果你想努力做到最好，你就会往前再多走一点。根据我的观察，大多数人看到错误或者经历失误时都是很宽容的。人们最关心的是你对待问题的反应。11、 开发人员不是敌人需要整个项目团队的努力才能递交高质量的产品。有时候似乎开发人员不太关心质量，这个时候事情背后可能存在隐情。这时候你需要更好的和开发人员合作而不是反对他们。要始终牢记良好的交流是一个项目成功的关键因素。当你和开发人员站到对立面时，交流就停止了，你测试所需的很多信息也无法获取了。12、 建立和维护一个私人的交际网你的私人和工作关系是一个很重要的资产。无论时当你有工作时还是当你没工作时他们都是一个很好的支持系统。找一个好的指导者，而当你学到足够的东西时成为别人的指导者。13、 持续锻炼自己的技能你的技能把你和别人区分开。始终通过参加专业会议、获取认证、阅读专业资料等来不断学习。我给自己制定的目标是每周至少读一本和个人发展以及职业发展相关的书（测试、领导艺术、商业、IT等）。一个个人发展方面的专家说过如果你每天在任何特定的主题上花费30分钟进行阅读，五年之内你肯定能成为这个主题方面的专家。这一点对我是起作用的――你也可以试试。另一种让自己始终内行并建立网络的好的方式是活跃在一些QA或者测试论坛上。14、 当前进变得困难，懒惰就需要创造力了当我第一次成为一个测试团队负责人时，我用这句话做了一个字条挂在我的桌上。它不断提醒我把创造力作为我解决问题的一个杠杆。学着从一个新的有创造性的方式来看待问题。你可能有一个好的测试计划，但你如何应付各种变化呢？弹性是一个优秀的问题解决负责人的关键特性。15、 简单并不总是很容易我们测试中做的很多工作看起来都很简单。但是，挑战在于保持努力的连贯性。有些解决问题的方式刚开始看起来很简单，但不要由于它简单和明显就丢弃任何一种想法。同样，不要低估实现一个简单想法所需要付出的努力。一些看过我和William E.Perry合著的书“Surviving the Top Ten Challenges of Software Testing”评论说这些挑战都很简单且很容易解决。这就让我奇怪为什么人们还在年复一年的提出“人的问题”。我认为在大脑中产生想法比实际实现出来要简单的多。结论智慧比知识更重要。你可能已经学习了大量测试技术，但如果你没有足够的智慧判断什么时候采用它们，没有从整体上理解它们，你应用它们的能力将受到很大限制。对任何都有涉猎的你存在的一个问题是“你不知道什么你不知道”。智慧帮助你明白你需要知道哪些东西才能成功。上面罗列的这些都是我希望我刚开始测试时都已经完全认识到的。我希望它们对你有帮助。先mark，再看看 对第六条“标准和流程是你的朋友”这个，感觉很心酸。当前所在的股投顾问公司，开发人员不太瞧得起产品人员和测试人员。现在还没有一个bug管理工具。只能写bug总结文档。开发人员无视需求文档、无视bug总结文档，就拿着自己做出来的产品让验收，但是怎么可能验收通过。上级领导一直想让测试转开发……这实在是…… 海海豚 发表于 2016-10-9 13:13
对第六条“标准和流程是你的朋友”这个，感觉很心酸。当前所在的股投顾问公司，开发人员不太瞧得起产品人员 ...
BUG管理工具是需要的，你丢一个文档或者口头告知
程序猿内心是崩溃的，可能会忘记，或者手头上事情太多没功夫搭理你
你要选一个固定时间去和程序猿沟通，如果确认是BUG，要和程序猿说明bug产生的原因及到用户手中照成的后果，而不是争吵
测试一方面需要和程序猿处理好关系，才能把工作做下去，另一方面测试用例要写出简洁精炼，具有指导性，一目了然，测试要尽可能的站在用户的角度考虑问题 勇敢的小白鼠 发表于 2016-10-9 14:26
BUG管理工具是需要的，你丢一个文档或者口头告知
程序猿内心是崩溃的，可能会忘记，或者手头上事情太多 ...
不知道您有没有仔细看我的回复，虽然我确实只是来发泄一下的。
我也想如你所说的一样。但是和经理提了无数次需要一个bug管理工具，但是都被“暂时不需要”的理由拒绝了。丢一个文档会让程序员崩溃，可是我除了换着花样写的简单明了的bug总结文档，别无他法。毕竟经理、程序员并不登录“禅道”查看以及修改我提交的bug。我并没有与程序员争吵，事实上，无论以什么方式向程序员说明bug，都不会被理睬。 海海豚 发表于 2016-10-9 15:41
不知道您有没有仔细看我的回复，虽然我确实只是来发泄一下的。
我也想如你所说的一样。但是和经理提了无 ...
你这工作也是相当难做
程序猿拒绝你的理由可以有很多种
事情分轻重缓急
如果是报错死循环A类错误，这个必须抓程序猿立刻解决
c类 D类 不影响主要功能的BUG 程序猿会选择不解决，你也不需要强制要求他解决
可以反馈给经理，在下一个版本统一解决 一个小BUG对程序员来说可能就是加班，或者花很多时间。自己忙的什么样你还来烦我。当然是保证大的流程为先
页:
[1]
