软件质量保证的决策分析法.docx
《软件质量保证的决策分析法.docx》由会员分享，可在线阅读，更多相关《软件质量保证的决策分析法.docx（29页珍藏版）》请在冰豆网上搜索。
软件质量保证的决策分析法
软件质量保证的决策分析法
我们持续演化，对于将软件QA浓缩到所有开发任务完成后的测试阶段的方法，它们的问题在于：
会给团队带来巨大成本并将整个项目置于高风险之中。
在测试阶段，开发人员竭尽全力确保他们的代码具有极少的缺陷。
然后测试人员努力揭示软件中每个可能的缺陷，而经理和客户希望他们拥有适合向市场发布的软件。
仓促的开发可能会为团队节省片刻的时间，但是，如果有一些重大开发问题没有从一开始就考虑到，最终可能导致需要投入更多的时间。
结果是浪费了大量团队资源来修复和重新设计代码，而不是将这些资源投入到更有用的事情上。
软件团队人员内心里对整个始末一目了然，但面对着唠叨的客户、严格的销售团队，以及一些自我感觉编写了无缺陷的软件的开发人员，软件团队确实很难将QA撇在一边而只顾着完成代码。
有几种实践方法，包括需求审核、代码审核和演练、基于会议测试、基于风险的测试等.
在开始每个新开发阶段之前审核软件需求，这样做能够最大限度地减少缺陷并满足客户的需求。
在实现之前审核需求，这样做有助于考虑潜在的变化，克服在项目的整个寿命中可能发生的误解。
团队必须与客户一起反复检查所有应实现的业务领域细节。
需求审核也可以使用原型和领域模型来完成。
当开发团队在开始实际实现之前完成这个小任务时，他们的项目或开发迭代会获得良好的开局。
通过确保在实现之前所有利益相关者都达成共识，并且每位团队成员都意见一致，客户和管理人员可确信开发人员将在开发周期结束时交付正确的成果。
而“代码审核和演练”听起来像很简单，但代码审核是软件开发中最有效的实践之一。
它对减少缺陷数量以及增强代码和软件设计的质量具有直接影响。
这消除了在未来的版本中执行重大的代码重构和清理的需求。
依据项目需求和实现细节，团队可能认同简单的编码和设计原则。
团队成员应共同遵守这些原则，而且只要开发一项新功能，一个或多个团队成员（除了作者）应审核新代码，并搜索所有编码或设计错误。
这种做法可在许多方面为团队带来帮助，包括提高代码质量和设计，最大限度地减少缺陷，并预防它们。
另外，它还使得整个团队能够深入了解彼此的工作，轻松移交工作，并提高团队对不同软件组件和功能的认知。
团队协作验证和证明代码的质量和设计的实现方法。
它们从同事那里获得直接反馈。
这么做可谓一举两得：
代码质量增加了，团队的认知和项目责任也增加了。
第三个实践是“基于会议的测试”，表示将测试负载分解为会议，每个会议有一个任务（一种希望从测试会议获得的明确规定的结果）。
每个会议有一个既定的时间范围（从20到40分钟），测试人员在执行测试会议期间不应中断。
这就像将测试人员放在一个测试房间一段时间，让测试人员专注于查找特定软件特性或功能的缺陷。
在会议期间，测试由一组测试案例引导执行，测试人员也可以执行探索性测试。
因此，基于会议的测试是正式测试方法与测试创新的一种组合，因为它提供了测试人员房间来进行探索和获得直觉思维，留出了时间和自由空间来发现不常见的缺陷，或者通过折腾软件来进一步了解它。
会议期间，测试人员应将软件的行为记录在案，获取快照，以及写下软件在特定输入和设置下的行为。
会议结束时，将与团队领导或技术经理讨论会议脚本。
从他们的讨论中，他们找出所认为的正常行为和不正常行为，然后基于讨论创建缺陷报告。
另一种则是“基于风险的测试”，因为在开发流程中进行了一些更改，开发团队通常拥有同一个软件的许多常用版本。
一种重要的QA实践是在每个主要版本之后彻底测试软件。
另一方面，在每个版本中都对整个软件运行全面的回归测试既耗时又很难实现。
但是，仅测试更改的功能或笨拙地删减测试案例套件是不安全的。
一段代码可能解决了一个缺陷，但也可能破坏了代码中的其他内容。
基于风险的测试方法采用了折中方式。
它的基本理念是按降序对软件功能和失败模式排序，从最重要或风险最高到值得拥有的功能和简单的风险（一个类似工具是FMEA：
失败模式和影响分析）。
如果测试人员在严格的时间限制下测试某个新版本时手头有这个列表，他就可以集中精力确保新引入的更改不会破坏其他任何内容。
然后就可以轻松地确保更改不会破坏软件中的任何最重要的功能，因而不会发生任何最严重的风险。
我们期望是
测试和开发同时进行。
编写一些代码，马上进行测试和构建。
接着，编写更多的代码，继续测试。
更好的是，在你编码的时候或者编码之前，就计划好你的测试。
测试不是一个独立分开的过程，它是开发的一部分。
质量不等同于测试；要想有高质量的产品，就要把开发和测试紧密捆绑在一起，直到不分彼此。
保证质量，预防胜于检查：
质量来自开发，而不是测试。
为了拓宽开发环节，我们可以把测试融入到开发中去。
我们已经建立了一个超高效的增量流程，只要有一个增量被证明缺陷太多，我们就可以回滚这些错误。
我们不仅预防了很多产品级问题，还大大地减少了那些为确保消除“召回级别”缺陷而安排的测试人员的人数。
衡量软件质量的常用指标
软件开发实践过程中常用的几个衡量软件质量的指标，包括源代码行数、代码段/模块/时间段内的平均Bug数、代码覆盖率、设计/开发约束等
源代码行数（SLOC）
计算源代码行数也许是最简单的办法。
它主要体现了软件的规模，并为项目的发展和规划提供了有用的信息。
比如，如果我们每月计算一次源代码行数，那么就可以绘制一个项目成长图。
当然，这种方式并太不可靠，原因是重构和设计阶段等因素会对此产生影响，但是至少可以为项目描绘一个趋势。
首先，使用代码行数之和无法有效评估一个项目的实际进度，因为它更注重行为而不是结果。
最终产品在多大程度上依赖于代码的性能和质量，这也是代码行数无法说明的。
因此，聚焦于此实际上是非常有限的工作效率测量方式。
SLOC无法表明要解决的问题的复杂性，也不能以可维护性、灵活性、扩展性等等因素来说明最终产品的质量。
说到质量，它反而可能起到负面作用。
通过重构、使用设计模式会减少代码行数，同时提升代码质量。
代码量大，可能意味着有更多不必要的代码、更高不必要的复杂性、更加僵化难懂。
代码段/模块/时间段内的Bug数
缺陷跟踪对于更好的测试和维护是必不可少的。
通过缺陷跟踪，我们可以利用报告工具（如Mantis）计算出每个代码段、模块或者特定时间段内的bug数量。
凭借这些数据，我们可以尽早的查出和解决缺陷起因。
Bug数量可能会作为衡量开发人员效率的指标之一，但是必须非常谨慎。
如果把这项指标看得太重，那么开发人员和测试人员可能会成为敌人。
在一个高效率的公司，所有的员工必须团结协作。
为了更好地实现评估，bug可以被分为低、中、高等，因为这些缺陷的重要性和解决成本不是相同的。
代码覆盖率
代码覆盖率反映了程序当中源代码被测试的程度。
有许多自动化工具可以完成该功能，比如Cobertura。
代码覆盖率不能完全代表单元测试的整体质量，但是可以反映出测试覆盖率的问题。
它可以和其他测试指标一起作为软件质量的指标。
同时，单元测试代码、集成测试场景和结果应该经常地被审查。
有效的代码度量模型应具备以下特征：
∙与组织的目标一致：
代码度量模型的底线要与组织的要求一致，和业务相关的东西会体现在规范里。
在支付宝，代码安全规范、敏感信息处理规范被作为代码质量最基本的要求。
∙有针对性：
要做针对性分析，比如对线上故障的研发原因进行分析，分析的规则会有周期性变动的，但不要太频繁，而且规则会随着组织的成熟度而改变。
∙可操作性：
要对度量维度做进一步分解，比如测试要有明确的检查点，覆盖要完整，可重复运行。
支付宝就制定了具体的度量维度，从多个维度对系统加以度量。
∙有工具支持：
这不是必要条件，工具不能解决所有问题！
能用工具最好，不行的话就人工检查。
工具检测维度要按照优先级和操作性，逐步增加精细化维度。
这一点上，支付宝将一些编码规则的检查放入了持续集成工具之中，以求尽早检查、频繁检查。
设计/开发约束
在软件开发过程中，存在许多设计约束和准则，其中包括：
∙类和方法的长度
∙单个类里方法和属性的个数
∙方法或者构造函数的参数个数
∙代码中的魔数、字符串用法等等
∙注释行比例等
研发流程
整个研发做到了类似于火车发车的发布过程：
1.各个bundle在有着自己的需求、开发、测试计划，相互独立。
2.主项目制定发布计划，确定集成窗口和发布时间点。
3.在集成窗口时间bundle可以自主提交集成。
4.集成提交需要走流程，包括填写checklist、代码检查、bug统计、提前编译预集成包进行测试等。
这就避免了明显的集成问题遗漏到集成环境中。
5.集成期间的集成包每天出一个或者两个，避免了测试人员不断拿包回归的情况。
6.集成窗口对于时间要求严格，赶不上计划或者质量不达标的bundle不予集成。
这就是火车不等人的原则。
7.以上机制保证了手机淘宝每天都有一个候选包，可以随时进行灰度发布，并且灰度发布单独拉取一个依赖配置分支，不影响集成窗口。
8.bundle的独立，依赖配置的独立保证了手机淘宝可以并行多个发布计划，各个bundle可以按照需求自主决定搭乘哪个发布计划进行发布。
9.目前项目节奏为两个星期发布一个版本。
如果需要还可以更快的进行发版。
最短只需要1个小时就可以发一个新版。
所有的项目生命周期都有相应的平台工具支持，如下图：
质量保证手段
有了高效稳定的流程，剩下的事情就是如何保证产品在快节奏的持续交付下的保持很高的质量。
质量保障上面手机淘宝研发团队做了几方面事情：
1.流程方面
1）创建了提测单、集成单、发布单等流程。
建立了标准，并依托平台自动检查，提高了交付的质量。
2）建立持续集成体系，不但能提早发现更多的问题，而且提升了测试人员拿到的包的质量。
3）建立线上线下监控分析体系。
2.包稳定性方面：
1）bundle阶段根据项目进度自己控制提测包的频率，集成阶段每日验证DailyBuild即可，所以解决了之前测试同学不断安装新版本的包的问题。
2）研发阶段的包内部支持环境切换，这实现了只构建一次，环境根据配置切换的梦想。
测试时手机上只需要安装一次包即可完成多种环境下的测试。
3.自动化测试与测试工具方面
1）引入多种静态扫描引擎，并定制多种规则：
适配规则、Crash规则、框架约定规则、安全规则等，并且不断地将测试阶段、线上问题等总结抽象成新的扫描规则补充进入扫描引擎。
2）在测试阶段包种插入相应的测试SDK，并且这种SDK不会侵入应用代码，所以只需要在发布的时候去掉测试SDK即可。
测试SDK可以在测试人员（包括外包适配测试人员）正常使用过程中自动检测并上报问题，这样就可以在同一的平台上看到研发过程中的质量情况并进行修复。
3）自动化平台方面也在根据测试经验不断的进化，在整个研发过程中自动化测试一直在执行，不仅可以提高产品稳定性，也可以发现性能、电量等非功能问题。
4）mock工具、验证平台等辅助测试工具也提升了测试人员的效率。
4.线上线下监控分析
1）线下质量数据、线上业务问题、舆情反馈等信息统一汇集到平台上进行统一的分析告警，不仅能快速的发现问题，而且能通过数据分析能够帮助快速定位和解决问题。
2）根据平台中的数据，可以用经验推动流程的优化、补充测试用例、添加扫描规则、增加自动化场景、催生新的测试工具等，这样可以使经验形成闭环，使质量保障工作更加高效。
在敏捷开发过程下质量保证：
对于目前的开发架构来说，一个用户故事，涉及这四个点，可以从这四个点入手来进行质量保证。
如何做呢？
单元测试就开发人员处理了；代码审查，测试人员可以参与和监督，其实就是要保证：
将开发任务与提交到Git的代码进行关联。
这样一来，当测试人员检查开发任务的时候，就可以找到改变过的代码。
我曾经试过从这些代码里面查看逻辑，找到分支场景，补充到测试用例里面。
Scrum中测试人员价值应当体现在：
1.
预防缺陷的手段，提高洞察力，增强业务知识。
缺陷在需求、开发前期就已经存在了，关键是用什么手段去挖掘出来预防。
在sprint前获取到的需求，测试人员可以站在客户角度上来阐述自己的观点，与开发人员进行充分交流和讨论，使自己在用户体验、业务逻辑等等方面的经验充分体现出来。
2.
3.
在开发过程中，测试人员除了站在客户的角度进行测试，还应当提供更全面的质量反馈，包括代码质量的检查，这个可以通过redmine与git双向关联来做检查依据。
目前整个过程测试人员尚未参与代码编写，应当参与并推进代码评审，将代码问题及时反馈出来；并且参与或者推进单元测试，检查单元测试状态（确保单元测试达到80%以上覆盖率，帮助开发人员开发出具有良好可测试性的代码），自始至终将质量问题及时反馈出来，保证在sprint的整个过程中质量受到足够的关注，提高质量改进的持续性和可视性。
4.
5.
随着版本任务的增加，每个版本回归测试的成本增加，可以适当考虑部分稳定功能进行自动化测试。
当然，这是远景。
6.
7.
持续改进、反馈，充分发挥每个版本统计报告的作用，对缺陷进行分析，总结出一些规律，帮助开发人员建立良好的习惯，改进代码的质量。
8.
敏捷中的QA日常活动
从迭代到发布，敏捷测试的生命周期各个阶段QA的活动主要有：
测试分析，测试自动化策略分析、框架构建等，故事测试，迭代计划会议和客户演示，测试自动化的维护和执行等。
如下图示：
QA通常不是仅仅工作在某个迭代，而是并行的同时工作在多个迭代：
要对当前迭代的故事进行验收测试、探索性测试，和开发人员结对实现测试自动化；还要和业务人员结对分析下一个迭代的故事，编写验收标准和测试用例。
在单个迭代内部，伴随着故事生命周期，QA的活动有哪些呢？
用户故事生命周期包括以下几个阶段：
故事分析、故事计划、故事开发、故事验收、故事测试／探索性测试、系统测试和客户演示。
QA参与故事的整个生命周期，在每个阶段都会发挥作用。
∙故事分析阶段：
需求澄清，业务场景和验收测试的确认
∙故事计划阶段：
拆分测试任务，在每个故事开发估算基础上考虑测试的时间和估算
∙故事开发阶段：
和开发人员结对实现自动化测试，和团队沟通发现的问题和缺陷
∙故事验收阶段：
开发人员开发完故事后，QA和业务分析人员要在开发机器上进行验收，以提供快速的反馈；同时还要对测试覆盖率（单元测试、组件集成测试、功能测试）进行确认和提出反馈
∙故事测试／探索性测试阶段：
执行自动化验收测试，执行探索性测试，强调会阻碍故事发布的因素，和团队就测试覆盖率进行沟通，为发现的缺陷添加自动化测试
∙系统测试和客户演示阶段：
执行端到端的系统测试，执行业务或集成的用户测试场景，和团队及客户就功能特性的质量和稳定性进行沟通，参与给客户演示功能和特性
正如前面提到的，在每个阶段，QA除了要独立进行测试，通常还需要跟不同的角色结对，包括业务分析人员、开发人员、以及客户。
∙QA与业务分析人员结对：
通常在业务分析师分析用户故事的时候，QA要与业务分析人员结对编写验收标准。
通过与业务分析人员结对，QA能够更好的理解领域知识，从而有利于定义合适的测试用例；QA从测试角度添加的验收测试用例可以帮助整个团队对产品功能性有更好的理解。
∙QA与开发人员结对：
QA和开发人员分别能给团队带来不同的技能集，认识到这一点很重要。
作为一个团队，最好通过平衡不同的技能集来获得共同的目标。
这对于传统的瀑布式团队来说是一个很重要的心态改变。
通常在实现测试自动化的时候，QA与开发人员结对是比较理想的方式。
这样结对实现的自动化测试质量相对较高，有测试意识较强的QA参与能够保证自动化测试测得是真正需要测试的部分，而开发人员的编码能力有利于写出简洁可维护的自动化测试代码。
另一方面，QA通过与开发人员结对，编码能力也会相应有所提高，而开发人员通过与QA结对，测试意识也会增强，更有利于编写质量较高的产品代码，更有利于形成全功能团队。
∙QA与客户结对：
客户是业务领域专家，通过与客户结对，QA能够更好的从终端用户的角度理解系统，从而定义或者增加更多的端到端的测试用例；一旦QA理解了领域知识和终端用户的观点，其业务价值分析能力会有所提高，在团队需要的时候可以承担业务分析角色；在用户验收测试（UAT）阶段，QA通过与客户结对，帮助客户熟悉使用系统，在必要时可以帮助客户解决一些系统问题。
敏捷QA的这些日常活动，的确反映出敏捷QA的日常工作内容和方式都跟传统开发模式下的测试人员有很多不同。
敏捷QA与传统测试人员有何不同。
我们分别从团队构成、测试阶段、工作方式、关注点、业务知识来源以及发布计划制定几个方面，来看看敏捷QA与传统测试人员有哪些不同：
从上表的对比可以看到，敏捷QA是特殊的，主要体现在：
∙敏捷QA是提出建议者而非看门人，需要在参与的每个阶段提出自己的建议，而不是等到开发流程最后来对系统进行验证；不仅要验证开发设计是否满足需求，还要发现需求是否能真正体现业务价值，分析是否有不恰当或缺失的需求。
比如说，敏捷QA在跟业务人员结对编写验收标准的时候发现故事分析过程中漏掉的需求，在跟开发人员结对过程中跟开发人员讨论某个测试放在哪层实现比较合理等。
∙发现风险，并将风险与团队及客户沟通。
QA参与整个开发流程，对系统整体的认识和把握可以说是团队里边最全面的，因此也更容易看到系统存在的风险。
∙及时向团队提供关于产品质量的反馈，便于调整。
在每个迭代结束时候，QA需要分析统计该迭代的缺陷，并结合自己通过测试对系统质量的了解，及时跟团队反馈，讨论分析质量下降的原因以尽快作出改进，或总结质量上升的经验，鼓励团队再接再厉。
∙在制定产品和版本的发布计划的时候，QA可以根据自己对产品质量的了解，从测试人员独有的视角提出一些关键的建议。
∙QA通过参与开发流程的每个阶段，能够协助团队从内部提升质量，让质量融入到产品开发中来。
比如：
在故事验收阶段对测试覆盖率的确认。
这些特殊性对敏捷QA也提出了更高的要求，需要做到：
∙具有丰富的产品知识和对用户业务目标的准确了解
∙对不同系统和数据库所用到的技术知识的了解
∙和不同角色以及客户进行有效沟通
∙主动验证质量目标并及时说出自己的想法
∙编写测试计划，列出需要执行的活动并进行估算
∙自动化测试的能力和对测试工具的基本了解
∙在团队内部进行知识分享，协助整个团队参与到测试活动中来
∙持续提供并获取反馈
敏捷软件测试的七个关键成功要素
包括使用团队整体参与的方法、采用敏捷测试思维、自动化回归测试、提供并获取反馈、构建核心实践的基础、与客户合作、保持大局观等。
1.使用团队整体参与的方法
当整个开发团队负责测试和质量问题，你会拥有很多不同的技能集合和经验等级来处理测试可能发生的问题。
测试自动化对于技能高超的开发人员来说不是大问题。
当测试置于团队的优先权，任何人都参与测试任务，团队才会设计可测试的代码。
使测试人员真正成为开发团队的一部分意味着向他们提供支持和训练他们适应敏捷开发的快节奏。
他们需要时间掌握新技能以便与开发和客户团队紧密协作。
如果你管理一个敏捷团队，帮助团队使用团队整体参与的方法。
记住质量，而不是速度，才是敏捷开发的目的。
团队需要测试人员帮助客户理清需求，转化为指导开发的测试，提供发布优秀产品的唯一观点。
确保测试人员能够把技能和长处转移到团队其他成员身上。
确保他们不是局限于一种角色，如只做手动测试。
确保当他们需要帮助时（可能需要极大的勇气），团队成员能够提供。
反过来也是如此。
测试人员应该随时准备帮助那些需要他们帮助的队友。
如果你是敏捷团队中的测试人员，并且计划会议和设计讨论没有邀请你，或者业务用户正在独自定义故事和需求，那你应该站出来和团队的其他成员交流。
和开发人员一起参与会议，并提议尝试“三方协作”，即测试人员、开发人员和业务专家。
谨慎地提供反馈并帮助客户提供例子。
让你的问题成为团队的问题，让他们的问题成为你的问题。
请你的同事采用团队整体参与的方法。
2.采用敏捷测试思维
我们提醒敏捷测试人员丢掉一直以来的“质量警察”思维。
现在你在敏捷团队中，开发人员参与测试，测试人员可以做任何事情以帮助团队生产最优秀的产品。
敏捷测试态度是前瞻性的、创造性的、欢迎新思想、乐于承担任何任务。
敏捷测试人员不断磨练自己的技能，随时准备协作，相信直觉，希望帮助团队和业务成功。
我们并不是说你应该披上超级测试王的斗篷，去保护世界免受缺陷的危害。
在敏捷团队中不存在狂妄自大。
团队成员分享你对质量的追求。
关注团队目标，帮助每一个更好地工作。
使用敏捷准则和价值观指导你。
不断尝试最简单的方法来满足测试需要。
勇敢地寻求帮助和实验新想法。
关注于产生价值。
尽可能多的直接交流。
灵活地应对变化。
记住敏捷开发以人为中心，我们应该享受工作。
当对此怀疑时，回顾敏捷价值和准则来决定该怎么做。
敏捷测试思维的一个重要部分是不断想办法改进工作。
成功的敏捷测试人员持续地磨练技能。
读好书、博客和文章以获得新想法和技能。
参加本地的用户组会议。
加入邮件列表讨论以获得问题或者新想法的反馈。
如果你的公司没有付钱让你参加一个很好的会议，那么把你的经验写成报告在免费的会上作交换。
对测试和敏捷开发社区进行反馈也会对你有益。
实验新的实践、工具和技术。
鼓励团队尝试新方法。
短期迭代非常适合这种实验。
你可能会失败，但是很快你可以尝试其他的。
如果你管理敏捷测试人员或者敏捷团队，给他们时间去学习并提供所需的培训支持。
移除障碍使他们更好地工作。
当你面对影响测试的问题时，让团队都知道这些问题。
通过头脑风暴的方式克服这些障碍。
回顾会议可以讨论这些问题并想办法解决。
维护一个阻碍事项列表，并在每个迭代中解决一到两个。
使用可视化的大图片或者虚拟方式，确保所有人都知道发生的问题并可以跟踪编码和测试的进度。
3.自动化回归测试
敏捷团队没有测试自动化会成功吗？
可能吧，但是我们所知道的成功团队都依赖自动化回归测试。
如果你花费全部时间用在手动回归测试上，绝没有时间用于重要的探索性测试（会发现隐藏在代码中的危险行为）。
敏捷开发利用测试来指导开发。
为了编写代码使测试通过，你需要快速、简单地运行测试。
没有短期反馈周期和安全的回归测试，团队将很快陷入技术债务，缺陷不断增加，速度越来越慢。
自动化回归测试是团队的工作。
整个团队应该选择每种测试适合的工具。
提前考虑测试将帮助开发人员为了便于测试自动化来设计代码。
使用敏捷测试象限和测试自动化金字塔来帮助你自动化各种类型的测试。
记住从简单入手。
你会惊讶地发现一些基本的自动化冒烟测试或者自动化单元测试会发生很大作用。
测试自动化是团队的工作。
开始时很艰苦，需要克服很大的痛苦。
如果你管理开发或者测试团队，确保在时间、培训和激励上提供了足够的支持。
如果你是没有自动化测试的团队的测试人员，开发人员疯狂地编写代码以至于不会停下来考虑测试，那么你会面临很大的挑战。
尝试从管理层和团队成员中获取支持以开始小规模的自动化工作。
4.提供并获取反馈
反馈是敏捷的核心价值。
敏捷的短期迭代可以提供持续的反馈以帮助团队运转正常。
测试人员通过自动化测试结果、探索性测试的发现和系统实际用户的观察结果的形式帮助提供反馈。
敏捷方法允许团队获取有关构建中软件的反馈。
这是关键。
故事代表了测试人员和分析人员向开发人员提供反馈的工作单元。
迭代发布有助于团队外部的反馈。
大多数敏捷实践都创建了反馈循环使团队应用。
测试人员也需要反馈。
你怎么知道从客户手里拿到了预期行为的正确例子？
你怎么知道编写的测试用例正确地反映了这些例子？
开发人员通过查看你收集的例子和你创建的测试能够理解应该编写什么代码吗？
一个最有价值的技能是学习如何寻求自己工作的反馈。
询问开发人员是否得到了足够的信息以理解需求并且是否能够指导编码。
询问客户是否理解质量标准。
花时间参与迭代计划会议和回顾会议以讨论这些问题并提出改进方案。
5.构建核心实践的基础
∙持续集成
每一个开发团队都需要代码管理和持续集成。
如果不知道自己在测什么，就无法
升级会员 