说起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的活动主要有：测试分析，测试...
