敏捷实践Showcase的七宗罪
本文首发于「BY林子」，转载请参考版权声明。 01 Showcase介绍Showcase就是开发团队把开发好的功能给客户的Product Owner（以下简称PO）等业务相关人员演示，以获取他们对所开发系统的反馈，是敏捷开发流程中的一个实践，一般频率是一个迭代一次，也可以根据项目具体情况做调整。Showcase是做功能演示，同时也是展示开发团队面貌的时刻，其重要性不言而喻，但据我经历的项目，总能看到一些不是很理想的地方。 02 Showcase之七宗罪 1. 准备工作没做好所有人就位，准备开始showcase的时候，突然发现环境没有ready，连不上了！ 好不容易把环境弄好了，开始showcase，可是数据又没有ready，还要临时创建，花了大半天时间（创建、准备数据）才终于show到了真正要演示的功能…… 主讲人手忙脚乱，而其他人都要在这种忙乱中等待，浪费了很多宝贵的时间，尤其是对于PO那些重要人物来说。 正确做法：充分做好准备工作 确定要做showcase的功能后，需要提前把以下事情提前做好： 从业务的角度把整个要演示的功能尽可能的串起来，准备好showcase演示的步...
测试右移——生产环境下的QA
本文首发于「BY林子」，转载请参考版权声明。 2015年11月ThoughtWorks发布的技术雷达提到一个新的主题——生产环境下的QA（QA in Production），2016年4月再次提到。这个主题第一次出现在技术雷达，就深深的吸引了我，当时我就给测试团队成员转发了这个内容，但同时脑子里却产生这样一系列的疑问： 生产环境下的QA可以做什么呢？有什么挑战，又有哪些好处？ 它跟预生产环境的QA有何区别，是否就是预生产环境QA方法的延伸？ 生产环境有运维支持团队（Ops），生产环境下的QA跟Ops所做的事情又有什么区别与联系？ 带着这些疑问，结合项目上的一系列实践，于是有了本文。 01 一个生产环境Bug的解决办法先来跟大家分享一个生产环境下的Bug： 一个在线订购葡萄酒的系统，订购流程相对复杂，下单过程中后台会有随机的失败，系统采取的措施是重试，就是说顾客下单后，后台如果有错误就会不停的重试，直到成功，这个过程对顾客是不可见的。这听起来没什么问题，用户体验似乎也不错。 后来有个新版本上线了，顾客下单后还是会有随机失败，系统依然不停的重试，但这次不一样的是有的随机失败，...
从《技术雷达》看软件测试新趋势
本文首发于「BY林子」，转载请参考版权声明。 2015年11月，ThoughtWorks发布了新一期的技术雷达。技术雷达是以独特的形式记录ThoughtWorks技术顾问委员会对行业产生重大影响的技术趋势 讨论的结果，为从CIO到开发人员在内的各方利益相关者提供价值。这期雷达的技术趋势主要体现在：受到热捧的微服务相关技术，逐步成熟的以Docker为典型的容器化生态系统，备受企业和用户关注的信息安全问题。本文就从这几个新趋势来分析一下给软件测试带来了哪些影响。 01 自动化测试是王道在这个快速变化发展的时代，任何一款产品想要在市场具备竞争力，必须能够快速适应和应对变化，要求产品开发过程具备快速持续的高质量交付能力。而要做到快速持续的高质量交付，自动化测试将必不可少。同时，自动化测试也不是用代码或者工具替代手工测试那么简单，有了新的特点和趋势：针对不同的产品开发技术框架有着不同的自动化技术支持，针对不同的业务模式需要不同的自动化测试方案，从而使得自动化测试有着更好的可读性、更低的实现成本、更高的运行效率和更有效的覆盖率。来自技术雷达的下列主题分别体现了自动化测试的这些特点： 针对...
软件缺陷的有效管理
本文首发于「BY林子」，转载请参考版权声明。 “这次发布之前怎么这么多的缺陷，是不是需要分析一下啊？” 答案是肯定的，可是这个时候才想起要分析已经有点晚了，有可能这些缺陷很难分析了。这是发生过的一个真实场景，所记录的缺陷包含信息很有限，很难有效的做好分析！ 本文就来聊聊如何有效的管理和分析缺陷。 缺陷是一项非常有价值的资产，软件缺陷的管理分为两个部分：缺陷信息收集和缺陷分析。 01 恰到好处的缺陷信息收集1. 无效的缺陷记录 信息繁冗 有的项目团队要求详细记录缺陷的多个维度信息，而且大部分都是必填字段，比如详细的重现步骤，对于有些特别简单的缺陷来讲是没必要的，关键是信息能够说明缺陷即可，过分详细的要求会带来更大的浪费。 曾经有个项目是在QC(Quality Center)里记录缺陷，需要填写很多必填属性字段，没有办法灵活根据具体缺陷调整，加上QC服务器在国外，访问速度非常的慢，每次记录缺陷成为了大家极其痛苦的一件事情。 信息缺失 也有的项目对缺陷的格式和属性没有严格要求，记录的时候很简单也很自由，这样记录的缺陷由于很多必要信息的缺失，对后续的跟踪和分析也是极为不利。 ...
说起BDD，你会想到什么？
本文首发于「BY林子」，转载请参考版权声明。 在刚接触BDD（Behavior Driven Development，行为驱动开发）的时候，我以为就是用Cucumber这样的工具来编写场景用例，从而实现自动化测试，甚至很长时间分不清BDD和ATDD(Acceptance test driven development)到底有什么区别。 那么，BDD真的就是用来做自动化测试的吗？本文就来跟大家分享一下我理解的BDD。 01 为什么要BDD？“开发软件系统最困难的部分就是准确说明开发什么” (“The hardest single part of building a software system is deciding precisely what to build” — No Silver Bullet, Fred Brooks) 。 场景一：业务分析人员觉得自己分析的需求BDD已经写的很清晰了，并且跟技术人员进行了足够的沟通，可是开发完做Desk check的时候，发现所开发的功能还是跟期望有差距。 场景二：开发团队辛辛苦苦开发完一个功能，满怀信心的去给产品经理/...
敏捷中的QA
说到QA，通常指的是质量保证（Quality Assurance）工程师，但我更喜欢定义敏捷中的QA为质量分析师（Quality Analyst），主要基于以下几个方面的原因： 质量保证更偏向于工业说法，称参与软件测试的人员为质量分析师感觉更恰当； 质量保证师更多的还是把测试当作软件质量的最后把关着、看门人，而敏捷中的QA更多的是建议提供者而非看门人，把QA称为质量分析师更能体现敏捷中团队对质量负责的原则； 质量分析师更重视业务价值，关注业务价值的分析。 QA，质量分析师，显然与测试有关。敏捷中的QA，也就是与敏捷测试有关。敏捷测试就是在敏捷开发模式下对软件进行的测试，要求尽早测试、频繁测试，以及时提供反馈。敏捷测试要求团队对软件产品的质量负责，而不是某个带有QA头衔的特殊人员。敏捷中的QA可以是参与敏捷测试的所有团队人员，而并不一定是特定的专职的测试人员。 这听起来是不是有点特别？跟传统开发模式下的测试人员是不是有些不一样？别急，我们先来看看敏捷中的QA是如何进行日常工作的。 01 敏捷QA的日常活动 从迭代到发布，敏捷测试的生命周期各个阶段QA的活动主要有：测试分析，测试...
