AgileQA对职业发展的担忧最近和群里的QA聊了聊未来的职业发展，发现一件很有意思的事，有的说想转BA，有的说想转develop，还有的表示想转PM，以后想往咨询方向发展。很少有人说他们想继续在团队里做QA。QA的角色就这么没有吸引力吗？为什么要转型或自己出门？跟群里的几位QA聊天后，发现主要是对QA职业发展的关注，感觉敏捷团队需要专职QA。不大。记得刚开始工作的时候，我还有一个独立的测试团队。那时候分工很明确。我负责WindowsMobile（现在称为WindowsPhone）上应用程序的自动化测试。我的岗位叫SDET，是自动化测试工程师。.我们团队大概有10个人，测试完成后会把结果汇报给测试经理。由于产品的复杂性，需要大量的测试工程师来保证产品的顺利发布。随着更多功能的加入，测试团队的数量也在增加。这个时期是QA最宝贵的时间。产品的发布最终由您检查。大家可以根据自己的兴趣选择做性能测试或者测试。安全测试工程师等，发展路线清晰。但现在越来越多的企业选择敏捷转型，适应变化、??快速交付可工作的软件成为团队关注的重点。从开发者和用户的角度来看，他们会很乐意接受这种变化。客户可以不断看到新的功能，开发可以从繁琐的文档和流程中释放能量，发挥想象力和创造力提供更好的解决方案。但是对于QA来说，敏捷能带来什么好处呢？之前定期有一个可测稳定的版本，详细的需求文档是我们参考的对象。现在要验证一个不断变化的对象，设计自动化框架也不是很久。我们如何保证质量？敏捷QA测试职责在敏捷团队中，质量由团队负责人保证。我刚听到这句话就像听到敏捷宣言一样。我知道这是有道理的，但是具体怎么做呢？如果质量是团队的责任，那么全职QA做什么？首先我们来看一下敏捷团队为了保证测试用例达到平衡状态而经常使用的测试金字塔。简单地说，我们可以进行更多的测试。在单元和服务层面，因为这些用例更容易维护和执行，运行效率更高，可以参考MartinFowler的TestPyramid。在这个框架下，人们很容易产生这样的误解：1.Development负责单元测试，不需要QA参与。我在群里和开发讨论过“是否需要QA参与review单元测试覆盖率”，而开发通常我觉得用处不大，因为有专门的工具如：Cobertura,Jacoco,Istanbul等.这些工具的检查范围通常包括：行覆盖率（linecoverage）：是否每一行都执行了？函数覆盖率（functioncoverage）：是不是每个函数都被调用了？分支覆盖率（branchcoverage）：是不是每个If代码块都被执行了？语句覆盖率（statementcoverage）：是否每条语句都执行了？QA检查可以弥补纯代码级的覆盖。比如在异常处理和边界值的情况下，代码级覆盖会检查语句是否已经执行，但无法检查逻辑是否已经编写。下面列出几种常见的检查方法：等价类：将程序的输入域（所有可能的输入数据）分成几个部分，然后从每个部分中选取少量有代表性的数据作为测试用例。每个类别的代表数据在测试中相当于该类别中的其他值。边界值：边界值分析是对等价类划分的补充，是一种检验输入或输出边界值的测试方法。我们这里所说的“边界值”是指一些比“输入等价类”和“输出等价类”的边界稍高或稍低的特殊情况。决策表：在一些数据处理问题中，某些操作的执行依赖于多个逻辑条件的组合，即对不同逻辑条件的组合值进行不同的操作。决策表非常适合处理此类问题。因果图：是用图形化的方法分析输入的各种组合，设计测试用例的方法。适用于程序输入条件的各种组合检查。一些QA会发现这些方法通常用于黑盒测试。事实上，尽可能在单元或服务层面实现这些覆盖是一种既高效又结果反馈快的方法，可以直接作为回归测试。一个好方法。在项目实践中，我们可以看到QA参与单元测试评审有以下好处：QA可以评审单元测试的覆盖率，从而调整单元测试和后续接口测试、回归测试的覆盖率。之前的项目都是一个人开发写单元测试和接口测试，QA也是一个人写自动化回归测试。后来发现重复覆盖很多，也是一种浪费。如果能成对进行单元测试，是一种更高效的方式。QA可以更好的了解代码对各个模块的影响，从而有针对性的设计回归测试。比如之前的项目有个小改动，QA没能在短时间内进行回归测试，导致产品发布后出现问题。有人会说，自动化所有的回归测试就够了吗？理论上是这样，但现实中有很多局限性，回归测试只能通过人工验证来完成。在这种情况下，精确定位回归测试的范围就显得尤为重要。QA可以对系统架构和开发语言有一个学习过程，有利于自动化回归测试的构建。2、开发更适合设计自动化测试框架和接口测试，因为它们编写代码的效率更高。如果自动化测试和接口测试的目的是为了比谁写代码更高效，那么这些事情确实应该由开发来完成，但是作为QA，参与的作用是从需求分析需求和设计用例。客户的观点。敏捷团队越来越多地应用行为驱动开发(BDD)来涵盖基于服务和UI的测试。QA会与PO、BA、DEV、UX一起分析软件的需求，然后将这些需求写入用户故事。开发人员负责填写这些故事的内容，测试人员负责检查这些故事的结果。通常，故事模板用于描述故事。Storytemplate:作为一个角色，我想要的是特性，这样的好处例如：作为一个手机App用户，我想用信用卡给手机号充值，这样我打电话就有费用了每个故事可能会有不同的场景，如下模板可以用来描述在什么情况下发生了什么，结果是什么。给定[上下文]和[更多上下文]当[事件]然后[结果]并且例如：场景：信用卡充值成功假设我登录了移动应用程序当我转到充值页面时然后我可以看到列出的充值选项我可以看到手机号输入框列出当我输入电话号码并选择充值选项为“信用卡”并输入信用卡号并点击充值按钮然后我可以看到“充值成功”消息显示QA将与DEV合作常用用于自动测试这些故事的工具：Cucumber（Ruby框架）SpecFlow（.NET框架）Behave（Python框架）JBehave（Java框架）JBehaveWeb（与Selenium集成的Java框架）Lettuce（Python框架）Concordion（Java框架）3。基于UI的测试足以进行开发交互，测试不需要专门的QA。其中大部分是通过探索性测试完成的。如何设计好的探索性测试用例是全职QA的价值所在。有人说探索性测试是手工测试，有人说是随机测试，还有人说是测试你作为用户使用软件。什么是探索性测试？以下是维基百科的定义：探索性测试是一种软件测试方法，简明扼要地描述为同步学习、测试设计和测试执行。CemKaner在1984年创造了这个术语，[1]将探索性测试定义为“一种软件测试风格，它强调个人测试人员的个人自由和责任，通过处理与测试相关的学习来不断优化他/她的工作质量，测试设计，测试执行，测试结果解释作为相互支持的活动，在整个项目中并行运行。看完这个解释，我更加困惑了。到底什么是探索性测试？举个简单的例子，当我们吃晚饭的时候，我们有时会玩一个猜数字的游戏，主持人会记下一个数字，大家轮流猜，主持人会提示是太大还是太小，然后下一个人就根据这个继续猜prompt，直到有人猜到数字。这其实就是探索和测试的原理，每次都会根据前面的结果设计下一个，猜到的数字就是缺陷，并且每个猜测都是一个测试用例。要想用最少的次数猜出数字，就需要一种高效的方法，探索性测试也是如此。敏捷QA的价值不仅仅是QA在敏捷团队中的测试职责的简要描述：审查单元测试覆盖率和开发对以构建基于服务和UI的测试探索性测试事实上，QA也有许多客户-面向职责，如需求澄清和产品演示将在后续文章中讨论。随着敏捷项目越来越多，对QA的需求不是越来越少，而是越来越高。QA需要像一个好家庭主妇，能内外兼修，团队内部更好的平衡测试设计才能对外更好的体现产品价值。在瞬息万变的时代，在持续快速交付的情况下保证质量是非常困难的。解决这个问题就是QA的价值所在。【本文为专栏作者“ThoughtWorks”原创稿件，微信公众号：Thinkworker，转载请联系原作者】点此查看该作者更多好文
