周六, 晚上有同学聚会, 上午睡觉, 下午就计划去参加一下 sun 他们组织的测试活动, 事实上, 挺有收获, 在这里做一个总结, 分享一下我的见解.
作为公司推动技术改革的 MIC 同学, 为我们分享了公司的实践.
用一种新的方式肯定是发现了原有模式的问题, 我听到的 MIC 同学讲的是, 看到测试用例与需求, 与自动化之间的脱钩, 导致重复的工作, 自动化的难于实施. 而 BDD 是解决这一问题的方法.
BDD 以 cucumber为基础, 完成相关特性 (用例) 的编写, 利用二次编码进行自动化测试, 根据 MIC 的分享, 效果较为突出, 这也为我们尝试改进提供了很好的借鉴意义和相关思路.
这个过程关键环节我认为有:
如何保证 BDD 的基础上, 又让用例更为灵活.
显然, MIC 采用了后者, 通过 Excel 的整合, 与二次编码 (想尽办法让需求人员或测试人员避免写复杂的正则) 简化这个过程, 让更懂自动化的人去完成编码细节.
如何推动测试人员在原有的习惯上完成这一转变?(其实对他们是变得稍不灵活了)
目前的办法是强推, 习惯 3-4 天就好了.
不关开发们的事么?
MIC 分享说还没有去推动, 我认为这点会导致效果较大的打折扣. 不过就整个情况来看, 虽然没做这个, 效果还是达成的.
我的个人建议:
如果你也存在这样的问题,需要注意:
思寒 给我们的观点确实蛮新颖, 不过仔细想想以前也有过类似的思路点, 不过不够系统.
其主要观点是建立于 bug 容忍度高的基础上, 我们可以将更多的测试内容交给直接用户真实使用和测试. 而 QA 则向前和向后各努力一把, 将单元测试, 接口测试, 静态测试做的更出色; 向前建立有效的监控,反馈系统,甚至于自动报表系统, 让我们的工作重点更多放在容错,发散,性能等更需要思考的环节.
我的建议:
对这个话题是非常感兴趣, Tom 讲的也非常出色, 活跃了整个气氛, 讲的很带感:)
实施一个成功敏捷项目, 需要几个必备条件:
所以, Tom 一开始项目的悲剧不可避免地上演了, 没有自动化的敏捷可以说是一个笑话.
没有准确的需求也就是像一个大楼从来不知道要盖成什么? 要是一不小心又成为 苏州的"裤叉", 难免被用户们批死…
我的个人建议:
SUN 今天准备的不多, 干货是较少的, 不过还是足以回想起我的公司进展, 我也有点想吐嘈两点:
这两点说起来简单做起来难. 自动化的推进是同样的道理, 过于关注 ROI 会适得其反, 浪费无谓的工作. 在自动化建设初期, 这一点更加明显. 与其关注这些, 不如:
自底向上自发的推进, 走的弯路会更少.
后来的 selenium 封装我就没有听了, 实在是时间有限, 相信这个是纯干货.
大家给我的感觉是十分的自在, 感觉是自己在这个组织很久了, 谢谢 sun, tom 等人的组织. 无以为报, 写一些听后感想留给大家回想一下吧.
对活动的建议是:
因为个人思维有限, 记忆也按自己理解了, 欢迎你路过踩踩评论.
最后也广告下我的博客吧: http://yafeilee.me, 偏技术些, 对 Ruby 有兴趣的可以多看下.
如果你是个极客, 应该从博客上可以找到我的相关信息:) 欢迎交流.