此文谨记为10月20号贝塔咖啡的测试活动

周六, 晚上有同学聚会, 上午睡觉, 下午就计划去参加一下 sun 他们组织的测试活动, 事实上, 挺有收获, 在这里做一个总结, 分享一下我的见解.

BDD到底如何?

作为公司推动技术改革的 MIC 同学, 为我们分享了公司的实践.

用一种新的方式肯定是发现了原有模式的问题, 我听到的 MIC 同学讲的是, 看到测试用例与需求, 与自动化之间的脱钩, 导致重复的工作, 自动化的难于实施. 而BDD是解决这一问题的方法.

BDD 以 cucumber为基础, 完成相关特性(用例)的编写, 利用二次编码进行自动化测试, 根据 MIC 的分享, 效果较为突出, 这也为我们尝试改进提供了很好的借鉴意义和相关思路.

这个过程关键环节我认为有:

1. 如何保证 BDD 的基础上, 又让用例更为灵活.

   显然, MIC 采用了后者, 通过 Excel的整合, 与二次编码(想尽办法让需求人员或测试人员避免写复杂的正则) 简化这个过程, 让更懂自动化的人去完成编码细节.

2. 如何推动测试人员在原有的习惯上完成这一转变?(其实对他们是变得稍不灵活了)

   目前的办法是强推, 习惯3-4天就好了.

3. 不关开发们的事么?

MIC 分享说还没有去推动, 我认为这点会导致效果较大的打折扣. 不过就整个情况来看, 虽然没做这个, 效果还是达成的.

我的个人建议:

如果你也存在这样的问题,需要注意:

1. 你必须能有很强的话语权, 否则难于推动.
2. 流程规范远远比你的想法更重要, 也就是落实度要强.
3. BDD自动化框架要经过充足的预研和改进, 以更灵活的方式让所有人员接收这个观点.
4. 推进到各个环节, 仅仅是测试是不够的.

QA的下一步发展?

思寒 给我们的观点确实蛮新颖, 不过仔细想想以前也有过类似的思路点, 不过不够系统.

其主要观点是建立于bug容忍度高的基础上, 我们可以将更多的测试内容交给直接用户真实使用和测试. 而QA则向前和向后各努力一把, 将单元测试, 接口测试, 静态测试做的更出色; 向前建立有效的监控,反馈系统,甚至于自动报表系统, 让我们的工作重点更多放在容错,发散,性能等更需要思考的环节.

我的建议:

1. 不是所有的公司都是这种方式, 尤其是B2B模式的公司, 我们的重点仍然在功能测试.
2. 这个过程对QA开发能力要求很高, 又需要调度各种资源来实施前端的用户反馈收集, 不适用于目前大多数的QA团队.
3. 如果你们的bug容忍度也较高, 不妨更多利用敏捷改善. 如何敏捷,这是接下来的话题.

敏捷项目的实施?

对这个话题是非常感兴趣, Tom 讲的也非常出色, 活跃了整个气氛, 讲的很带感:)

实施一个成功敏捷项目, 需要几个必备条件:

1. 真正的持续集成自动化运转
2. 需求可控
3. RD质量意识到位

所以, Tom 一开始项目的悲剧不可避免地上演了, 没有自动化的敏捷可以说是一个笑话.

没有准确的需求也就是像一个大楼从来不知道要盖成什么? 要是一不小心又成为 苏州的"裤叉", 难免被用户们批死…

我的个人建议:

1. 这个工作不是QA一个人能搞定的, 想开始的时候要看好第3点, 选择优秀的RD
2. QA的工作依然是"保姆", 不过更加主动, 控制需求(偏测试), 实现持续集成的系统建设,推动团队的自动化建设.
3. 你的编码能力要足够, 我更希望你会一些动态语言,比如 Ruby. 开展会快很多很多.

自动化的质量管理

SUN 今天准备的不多, 干货是较少的, 不过还是足以回想起我的公司进展, 我也有点想吐嘈两点:

1. 总是看效果的领导不是好领导
2. 不敢于承担风险的领导也不是好领导

这两点说起来简单做起来难. 自动化的推进是同样的道理, 过于关注ROI会适得其反, 浪费无谓的工作. 在自动化建设初期, 这一点更加明显. 与其关注这些, 不如:

1. 培养合适的人才在合适的位置上
2. 建立更加合理的激励机制, 并且根据不同时期进行调整

自底向上自发的推进, 走的弯路会更少.

其他

后来的 selenium 封装我就没有听了, 实在是时间有限, 相信这个是纯干货.

大家给我的感觉是十分的自在, 感觉是自己在这个组织很久了, 谢谢 sun, tom 等人的组织. 无以为报, 写一些听后感想留给大家回想一下吧.

对活动的建议是: 1. 频率可以高一点点, 讲slideshow时间可以少安排一点 2. 让大家多自由交流 3. 地点其实不错, 就是不实惠, 建议固定一些, 没有水不要紧, 大家可以自备, 其他吃的也可以让大家准备. 4. 论坛让大家用起来, 多解决一些实际问题更好

因为个人思维有限, 记忆也按自己理解了, 欢迎你路过踩踩评论.