这几天又翻了几页这本书,觉得妙语连珠,关键语录摘抄如下,并补充自己的一些思考:
“如果你想要求一个团队去尝试新的事物或者做某些改进,给他们提供一个联系人会更好一些,这个联系人来源于更大的社区,并可以从他那里得到帮助”;
“不要陷入尝试去创建一个包含独立指标的完美系统的陷阱中。对所有人都完美的事情是不存在的。在没有可替代的方案时,在合理的地方达成一致并勇往直前是很重要的。需要灵活的时候就灵活一些,但一定要坚持你的原则底线”。
当考虑团队建设方面时,在以前总是收获理想很丰满,现实很骨感的局面,最后总是不了了之的结局。这比没开展还坏,因为会打击团队的积极性,忙乱一顿,却看不到明显的产出,而且有很强的受挫感。这里提到要有一个指导者,而且最好有一个这样的联盟,大家一起来做这件事情,形成一种社区的氛围,那事情的成功性会较大。而且,做事情,不要太过死板,既然是尝试,就没有板上钉钉的事情,一直强调考核和目标,这样的行政指标会让人反感和排斥。适当的转弯,可以让团队走的更远。
“专注于你的用户,理解他们的需求并解决他们的问题。”
“缺陷驱动开发,一旦用户发现了一个bug,我就立刻去修复它,然后再宣布它没有问题了,更加完美无瑕”。
产品的最终目标,是满足用户的需求,无论是真实功能上的需求,还是用户无法提出来的隐形需求。要做到缺陷驱动开发,当然不能把缺陷都放到市场上等待用户发现,而是在实验室内多次迭代,多次从用户角度去试用,通过快速的迭代,持续的集成来实现。这是敏捷的思想,我想到了今天,世界上测试技术那样多,但有一点是不变的,那就是要快。只有测试足够的快,能快速执行,快速出结果,快速评估,才能提高生产力和效率。
“试验性工作、尚无明确目标或用户故事的早期产品,TE很少参与,甚至不参与。”
“过度早期地投入测试意味着资源上的浪费,尤其是在SET已经深度介入的时候”
“以策略上将,给一个项目配备多少测试人员,取决于项目风险和投资回报率”
”TE擅长发现需求中的模糊之处,分析沟通不明确的问题“
”一旦找到薄弱点,TE就会通过测试使软件出错,然后与开发、产品、SET一起推动解决这些bug“
”如果做测试计划已经来不及了,那就干脆不做了。如果一个项目最需要的是测试,那就做一个简单够用的指导性计划,一些测试教条所倡导的从头就介入的模式,在google并不适用。“
google一直在强调,传统的测试模式在快速迭代的今天已经有些跟不上了,至少从我工作的经验来看,确实是这样。测试跟不上研发的进度,研发抱怨测试拖了项目的后腿。测试什么时候介入,也无需一味按照传统的开发模型来生搬硬套。但是这里提到的测试指的是系统测试,而其他的测试,例如单元测试、集成测试,以及测试脚本的开发和维护,则是在项目之初就开始了。测试的角色是更加全方位的,测试是真正意义上的测试开发工程师,产生的测试代码和产品功能代码一样属于产品功能完整性的一部分。这其实给测试提出了更大的要求和期待,既要熟悉测试方法,兼具用户视角,又要有很强的编程能力,是真正意义上的开发工程师。google内部对测试工程师的角色划分也非常细致,可以看出是真正重视人员培养的。越发觉得,别人是真正讲求效率和实效性的,和自己当下的处境相比,现实差距太大啦。。。
”测试人员不应该对测试文档过于珍爱。糟糕的测试用例不会受到足够的关注和改善,他们只会被抛弃,而最后留下来的是更好的测试用例。“
”作为一种测试文档,测试计划的生命周期是所有测试产物中最短的“
”测试计划是最早出现,最先被遗忘的测试产物“
”伴随着计划内或计划外的变更,维护一份测试计划是要花费大量精力的,除非多数项目的成员会定期查看,否则测试计划并没有什么价值“
这里道出了现实中测试计划的尴尬局面。有时候甚至会产生要测试计划何用的叹息,测试计划执行完后,我们对于测试的程度和产品质量的好坏仍然不能评估,不知道还有哪些没测,哪些是风险点,哪些对于产品来说是至关重要的。每次的测试计划不能相互关联,一次测试计划完成后,就永久性的搁置。而且最大的尴尬是,测试计划似乎无人在乎,开发不在乎,连测试人员也不太在乎,测试中随时可能会更改测试用例(有些步骤被证明是失效的,维护测试用例需要花费很大的精力),测试主管又不能根据测试计划做出合理评估!google提出的ACC方法确实有见地,在测试中一直在追问产品的核心价值,一切活动溯源都是产品的定位与价值。这其实给我们现在的测试管理敲了个警钟,要不忘初心!作为测试管理人员,是否能在10分钟内准确说出产品的特质?如果不能,说明对产品不够熟悉,还不能有效地测试它。一切都是为了提高效率,那就要时刻牢记最终的目标,这是测试的愿景,否则,在浩瀚的测试海洋中,是会迷失方向的。
愿在工作中,能尽快实践书中的一些理念,对于测试,实在要有长远的信心和行动才行!