周六, 晚上有同学聚会, 上午睡觉, 下午就计划去参加一下 sun 他们组织的测试活动, 事实上, 挺有收获, 在这里做一个总结, 分享一下我的见解.
一、BDD到底如何?
作为公司推动技术改革的 MIC 同学, 为我们分享了公司的实践.
用一种新的方式肯定是发现了原有模式的问题, 我听到的 MIC 同学讲的是, 看到测试用例与需求, 与自动化之间的脱钩, 导致重复的工作, 自动化的难于实施. 而BDD是解决这一问题的方法.
BDD 以 cucumber为基础, 完成相关特性(用例)的编写, 利用二次编码进行自动化测试, 根据 MIC 的分享, 效果较为突出, 这也为我们尝试改进提供了很好的借鉴意义和相关思路.
这个过程关键环节我认为有:
如何保证 BDD 的基础上, 又让用例更为灵活.
显然, MIC 采用了后者, 通过 Excel的整合, 与二次编码(想尽办法让需求人员或测试人员避免写复杂的正则) 简化这个过程, 让更懂自动化的人去完成编码细节.
如何推动测试人员在原有的习惯上完成这一转变?(其实对他们是变得稍不灵活了)
目前的办法是强推, 习惯3-4天就好了.
不关开发们的事么?
MIC 分享说还没有去推动, 我认为这点会导致效果较大的打折扣. 不过就整个情况来看, 虽然没做这个, 效果还是达成的.
我的个人建议:
如果你也存在这样的问题,需要注意:
- 你必须能有很强的话语权, 否则难于推动.
- 流程规范远远比你的想法更重要, 也就是落实度要强.
- BDD自动化框架要经过充足的预研和改进, 以更灵活的方式让所有人员接收这个观点.
- 推进到各个环节, 仅仅是测试是不够的.
QA的下一步发展?
二、思寒 给我们的观点确实蛮新颖, 不过仔细想想以前也有过类似的思路点, 不过不够系统.
其主要观点是建立于bug容忍度高的基础上, 我们可以将更多的测试内容交给直接用户真实使用和测试. 而QA则向前和向后各努力一把, 将单元测试, 接口测试, 静态测试做的更出色; 向前建立有效的监控,反馈系统,甚至于自动报表系统, 让我们的工作重点更多放在容错,发散,性能等更需要思考的环节.
我的建议:
- 不是所有的公司都是这种方式, 尤其是B2B模式的公司, 我们的重点仍然在功能测试.
- 这个过程对QA开发能力要求很高, 又需要调度各种资源来实施前端的用户反馈收集, 不适用于目前大多数的QA团队.
- 如果你们的bug容忍度也较高, 不妨更多利用敏捷改善. 如何敏捷,这是接下来的话题.
三、敏捷项目的实施?
对这个话题是非常感兴趣, Tom 讲的也非常出色, 活跃了整个气氛, 讲的很带感:)
实施一个成功敏捷项目, 需要几个必备条件:
- 真正的持续集成自动化运转
- 需求可控
- RD质量意识到位
所以, Tom 一开始项目的悲剧不可避免地上演了, 没有自动化的敏捷可以说是一个笑话.
没有准确的需求也就是像一个大楼从来不知道要盖成什么? 要是一不小心又成为 苏州的"裤叉", 难免被用户们批死…
我的个人建议:
- 这个工作不是QA一个人能搞定的, 想开始的时候要看好第3点, 选择优秀的RD
- QA的工作依然是"保姆", 不过更加主动, 控制需求(偏测试), 实现持续集成的系统建设,推动团队的自动化建设.
- 你的编码能力要足够, 我更希望你会一些动态语言,比如 Ruby. 开展会快很多很多.
四、自动化的度量管理
SUN 今天准备的不多, 干货是较少的, 不过还是足以回想起我的公司进展, 我也有点想吐嘈两点:
- 总是看效果的领导不是好领导
- 不敢于承担风险的领导也不是好领导
这两点说起来简单做起来难. 自动化的推进是同样的道理, 过于关注ROI会适得其反, 浪费无谓的工作. 在自动化建设初期, 这一点更加明显. 与其关注这些, 不如:
- 培养合适的人才在合适的位置上
- 建立更加合理的激励机制, 并且根据不同时期进行调整
自底向上自发的推进, 走的弯路会更少.
其他
后来的 selenium 封装我就没有听了, 实在是时间有限, 相信这个是纯干货.
大家给我的感觉是十分的自在, 感觉是自己在这个组织很久了, 谢谢 sun,sihan、tom 等人的组织. 无以为报, 写一些听后感想留给大家回想一下吧.
对活动的建议是:
1. 频率可以高一点点, 讲slideshow时间可以少安排一点
2. 让大家多自由交流
3. 地点其实不错, 就是不实惠, 建议固定一些, 没有水不要紧, 大家可以自备, 其他吃的也可以让大家准备.
转自：http://yafeilee.me/blogs/5082ea921563880ac000000a#disqus_thread(亚飞的博客，偏技术些, 对 Ruby 有兴趣的可以多看下.)
我们的一些评论：
@思寒：写的太好了。太赞了。
Mic已经放我们好几次鸽子了，本来以为他很不靠谱，但是今天下午，他为了给大家补上测试用例。特地又折返了一次，真是敬业啊。让我彻底改变了看法，分享的内容非常的有价值。这也是业界少数能够成功而踏实的应用BDD并且取得不俗成绩的实践。
Tom的讲解，激情四射，神采飞扬，勇于剖析自己曾经遇到挫折的项目，并能在后续积极的改进测试方法和测试手段，让公司的测试发展飞上一个新的台阶。tom充满感情的分享，给我留下了深刻的印象。
John的分享是最实在，最实用的，他介绍的selenium封装方法和问题场景，是现在大多数公司都遇到过的，sogou成功的解决了这些难题，并打造成了出色的独居产品特色的selenium解决方案。从技术上，实践上，产品上，sogou对测试的打磨真的是匠心独具。
这次我和sun的分享，只是给大家穿插一些测试发展的介绍。还有好几个非常好的资料和话题要跟大家交流，可惜时间有限，无法都展示了。
@散步的SUN
我同意那说的两点，我说的那五个自动化测试过程：
1、初试
2、应用
3、定义
4、度量
5、管理
每个阶段有每个阶段的自动化测试策略，而我分享的度量分析，则是到了第4个阶段，在自动化初期就是先把事做好，初有成效，之后摊子大了，再回过头来关注度量和效果分析，刚开始由手工统计，后续建设一个大的管理平台去自动统计。对于BDD：由于之前接人，一直没有听得全面，但是我觉得跟我一个想法很想，就是帮助测试人员做合适的事情，他们懂业务、懂场景，就开发出一套框架和体系去帮助他们自由组装场景，而不是让他们去关注底层的语言之类。我们要做的工作也包括基于每个人擅长的事情不同，分析如何让不同的人做自己适合的事情吧。Tom的分享让我对敏捷开发中的测试的实践有了更深的认识，敏捷开发不单纯的指快，更需要的是如何用有效的手段保证快，例如：自动化部署、构建和测试。在前期就需要计划好环节。John的分享确实是干货，展现了他对selenium的灵活的应用，让我对开源的应用上的认识上升到到了另一个高度，原来开源真的是不一定就比商业的差，而是你如何将他运用的更加灵活。
@simple
我觉得tom的那个敏捷方式跟公司项目和人员素质有极大关系，不可一味模仿，高难度动作
