当软件开发组织采用敏捷开发时，测试团队通常需要花很长时间来完成转变。在很多公司中，独立的质量保证团队已经根深蒂固。当它们开始适应新的敏捷组织时，会遇到难以接受的文化差异。敏
捷测试专家Lisa和J.net对此进行了详细分析，对文化因素在敏捷测试中的影响提出了自己的建议，InfoQ中文站对相关内容做了整理。
组织文化通过其价值、标准和设想来定义。组织文化支配着人们如何沟通、交互和做决定，这可以通过观察员工的行为很容易地看出来。组织文化可以影响敏捷团队的成功。敏捷团队最适合于允许独立思考的组织。例如，如果一个公司是等级结构的，所有的项目都鼓励指令式管理风格，敏捷团队可能会很吃力。组织以往的经历也可能会影响新的敏捷团队的成功。如果公司尝试敏捷，但是结果糟糕，人们会怀疑再次尝试的必要性，举例证明为什么敏捷不起作用。他们甚至可能积极地反对它。
当尝试采用敏捷过程时，组织文化经常被遗忘，人们怀疑敏捷为什么不像承诺的那样有用。改变已有的过程是困难的，尤其是当人们觉得习惯于现状时。每个任务组形成了满足自己需求的文化和过程。他们习惯于自己的工作方式。恐惧的情绪非常强大，如果不能妥善解决，可能破坏向敏捷的转变。如果团队成员觉得新的敏捷过程威胁他们的工作，那么会抵制这种变化。
以如何定义软件质量的可接受水平的角度思考组织的质量哲学。是否容忍劣质的质量?是否考虑客户的质量需求，还是只关心是否可以尽快地将产品交付给客户?当一个组织缺乏全面的质量哲学和团队没有生产高质量产品的压力时，测试人员会感觉到无助。在这种环境中尝试使用敏捷开发的团队会面临更大的障碍。
如果一个现有的质量团队自封为“质量警察”的角色，它的成员通常通过确保 完成代码审查和缺陷严谨地记录到缺陷跟踪系统来保证质量。他们跟踪发现的缺陷数，然后负责最终决定是否发布产品。我们曾经接触过一些测试人员吹嘘他们的成就，例如越过开发经理直接强制程序员遵循代码标准。甚至听说有测试人员浪费时间编写不符合标准的需求的缺陷。这种态度并不符合协作的敏捷团队，将引起敌对行为。“质量警察”角色的另一个风险是团队不认同构建质量的概念，程序员将测试人员视为安全防护网。团队通过缺陷跟踪系统沟通，但这并不是一种高效的交
流，所以团队并不“凝聚成一团”。
技能和适应能力
很多程序员不能适应敏捷实践——但是对于习惯于根据需求文档编写测试脚本的测试人员，情况如何呢?他们学会在编写代码的
时候提出问题了吗?不能改变测试方式的测试人员与开发团队的其他人密切工作的时候会很艰难。习惯于通过用户界面手动测试的测试人员可能无法理解敏捷开发的本质——自动化方式。这些测试人员需要很大勇气来面对变化的角色，因为变化意味着需要发展其熟悉范围之外的新技能。
辅助因素
即使有许多需要考虑的文化因素，但是大部分质量保证团队关注过程改进，并且敏捷项目通过使用例如回顾总结等工具来鼓励不断改进和适应。大多数质量保证专家希望使用他们学到的知识并改进它。这些人
适应性强，不仅能适应，并且能在敏捷项目中获得发展。如果你的组织专注于学习，它将鼓励持续的过程改进。它将比把更多的精力放在如何应对危险而不是改进过程的组织更快地适应敏捷。
如果你是有效的质量哲学的组织中的一个测试人员，你可能努力使质量实践获得接受。敏捷方式将提供引入优秀的面向质量的实践的机制。像其他学习如何在敏捷项目中工作的每个人一样，测试人员需要时间和培训。如果管理一个有测试人员的团队，确保给他们足够的支持。新项目通常不在一开始就引入测试人员，一般让他们适应一个已经在一起工作了几个月的团队。为了帮助测试人员适应，
可能需要引入一名有经验的敏捷测试老师。聘用一名以前在敏捷团队工作过的员工作为老师和教练可以帮助测试人员融入到新的敏捷文化中，不管是进入一个现有的团队还是加入一个新的敏捷开发团队。
合适的节奏
传统的测试团队习惯于在项目结束时快速、激烈地测试，这会导致周末和夜间的加班。在项目结尾的测试阶段，一些组织通常会让团队每
周工作五十、六十或者更多小时来应付最终期限。组织经常将加班作为个人贡献的度量标准。这与敏捷价值冲突，敏捷价值的中心思想是让大家时刻以最好的状态工
作。
在敏捷项目中，鼓励人们以一个合适的节奏工作。这意味着团队以一致的速度工作，团队可以保持在这个保持高质量标准的速度。新的敏捷团队往往对其能够完成的工作过分地乐观，而承诺太多的工作。在一个或两个迭代之后，会学会承担不需要加班完成
的足够工作。每周四十小时是极限编程团队通常的合适速度，这是保证人们连续几周完成大部分工作并创造优质产品所能承受的工作强度。
团队可能偶尔需要高强度地工作，但是这是特例，不是一般情况。如果需要短期加班，那么整个团队都应该加班。如果sprint的最后一天某些测试没有完成，那么整个团队不仅仅是测试人员都应该加班完成测试。在团队更好地管理负载和节奏之后，加班才会消失。
客户关系
在传统的软件开发中，开发团队和他们的客户之间的关系更像是买卖关系。即使客户是内部的，但是感觉更像是两个独立的公司，而不是为了生产业务这一目标而共同奋斗的两个团队。敏捷开发依赖于客户或者至少是客户代表的紧密参与。敏捷团队邀请客户协作，如果可能，
在同一地点工作，并且密切地参与开发过程。双方都了解对方的强项和弱点。
不管客户是内部的还是外部的，这种关系的改变需要双方的认同。开放的关系对敏捷项目的成功至关重要，在敏捷项目中，客户团队和开发团队之间的关系更像是合作关系，而不是买卖关系。拥有一些领域专家代表，并且持续地向所有相关人员报告状态，是实现开发人员和客户成功协作的办法。客户对敏捷项目的成功是至关重要的。他们对将要实现的功能确定优先级，并对项目的质量有最终的评判权。测试人员与客户紧密合作来理解需求，并定义证明满足条件已经达到的验收
测试。测试活动对于开发团队与客户团队关系是很重要的。因此，测试专家是敏捷团队的关键。
组织规模
组织的规模对项目如何运转及公司如何完善结构有重要的影响。组织越大，结构中的层次可能会越多。当形成自顶向下的交流渠道时，报告结构变得指令化，不适合技术和业务的沟通。
沟通挑战
一些敏捷过程提供了便于团队交流的方法。例如，Scrum有Scrum会议，来自多个团队的代表每天交流。如果工作的测试团队或其他部门与编码团队分离，那么需要找到保持不断交流的方式。例如，如果数据库团队是完全分离的，那么需要寻找一种与数据库专家密切合作的方式来及时获得需要的信息。大公司容易存在的另一个问题是客户可能不像小公司那样容易接近。这是当你试图获取需求和实例并牡蛎在开发周期中让客户参与的巨大障碍。一个解决方案是让测试人员或分析人员及领域专家作为客户代理。交流工具也可以帮助处理这种情况。需要寻找创造性的方式来克服大公司固有的这些问题。
组织内的文化冲突
在大的软件开发公司，敏捷开发通常先在一个或几个团队中使用。如果敏捷团队需要与使用其他方式例如阶段开发的团队合作，那么会有更多的挑战。如果有些外部团队运转不良，那么情况将会更加困难。即使整个公司采用敏捷，有些团队的转变也会比其他的更成功。
团队可能也会收到专家团队的抵制，他们会觉得需要保护自己特定的利益。Lisa曾遇到过一个团队的成员不能从公司的配置管理团队中获取任何帮助，这是一个巨大的障碍。一些开发团队遇到的障碍是不能直接与客户团队交流。
如果有第三方和团队一起开发系统，彼此的文化也可能引起冲突。可能你的团队是第三方，正为客户开发软件。你需要思考如何减轻文化差异。
提前计划
如果与其他团队合作，可能需要在版本规划时或迭代开始前与他们一起协商。需要时间使自己的过程适应与其他团队的过程协同工作，他们可能需要改变自己的过程来满足你的需求。考虑安排某些资源共享，例如性能测试人员或压力测试环境，并依据其他团队的进度计划你的工作。你的利益相关者可能需要一些自己的敏捷过程无法提供的资料，例如正式的测试计划。额外的计划可以帮助你克服这些文化差异。
先行动后道歉
我们不愿意提出可能会引起麻烦的建议，但通常在大的组织中，官僚政治的节奏太慢，团队可能需要找到并执行自己的解决方案。例如，不能从配置管理团队得到协作的团队可以简单地使用他们自己内部的构建过程，并不断地改进使之整合到官方认可的过程中。
当没有官方途径得到你所需的东西时，想办法创新。测试人员可能以前没有直接与客户交谈过。自己尝试安排一个会议或者找到可以扮演客户代理或者中间人的人。
授权团队
在敏捷项目中，让每个开发团队感觉到有做决定的权力是很重要的。如果你是经理，并且希望敏捷团队成功，让他们自由地行动并积极地响
应。为了敏捷项目的成功，公司文化必须适应这种变化。
建议
在做出任何变化之前考虑组织文化。
当整个组织重视质量的时候，测试人员可以容易地融入敏捷团队，但是具有“质量警察”思想的测试人员存在困难。
有些测试人员可能会在适应“整体团队”对质量负责的时候有困难，但是团队方式可以帮助克服文化差异。
| 
