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