本帖最后由 51testing-wn 于 2014-9-21 15:48 编辑
这里提出的测试资源,主要指的是测试人员的分布及测试人员掌握的资源分布。提出的原因是主线 分支上,在不同阶段开发和集成了不同的feature,而测试资源分布在这些“分支”上无法系统的整 合和调配,导致工作效率低下,产品质量不高,甚至在同事之间产生隔阂。
测试人员仅仅负责自己所属项目的测试,缺少项目交流,容易造成比较局限的思维和视野。结果可能 是发现的问题迟迟不能确定,不但引起测试资源的消耗(设备和时间),组员对测试人员的信任感低, 测试人员之间的认可度低,从而造成产品质量不高甚至低劣。
其次,测试设备不能及时释放,也会造成测试资源紧张。测试人员分布于不同的feature组,往往先入 为主认为自己的任务优先级高,独占设备。在另外一方面,这种情况也反应了测试人员的不自信。殊不 知项目的考评不是看某一个feature运行的情况或者一段时间内的累积的缺陷数目,而是客户对产品运 行情况的年度考评(长时间的生产线的运营情况)。说得更明白一点,客户看到的永远是整个产品质量 的好坏,从而评价一个软件公司(或者一个团队)的好坏,而不会追究某一个人的错误。 再次,项目后期阶段的回归测试,因为不了解项目的整体概况(比如新功能之间的影响,新代码对主业 务的影响,新代码对主流程的影响,从维护分支合并过来的代码等的影响),从而在做回归测试计划时 候无法制定正确的测试策略,导致回归测试的效率和质量很低。 需要强调的是,这里仅仅讨论测试人员的职责和作用。
目前项目分为两个部分,MWN维护组和新feature组。 MWN维护组,负责项目的日常维护,主要工作是修复生产线提出的功能和性能方面的问题,并在一定 周期后对项目进行回归测试,参与人员全部为MWN内部开发人员。
新feature组,负责新项目的开发和测试。开发周期约为一年到一年半左右。期间会发布子feature给 客户进行测试,并在回归测试达到质量标准后客户才会接受软件产品,并且发放给最终用户使用。我们 的测试人员主要分布于各个子项目组,相互独立。这个组的管理结构为,项目经理负责子项目的运转, 而直线经理仅仅协同项目经理做好本地人员的调配不直接干预项目上的事情(本公司属于外包型的公司, 主要做从国外的分公司分包过来的项目,所以同一个项目组的人一部分为在国外,一部分在国内)。直 线经理不擅长技术,属于职能型的经理。这样的管理结构和技术背景,势必造成项目经理只了解项目的 运行情况,而不了解本地员工申请和占用的资源。同时直线经理只了解本地员工的资源分配,而不了解 项目的运行情况和实际需要的资源。
这种关系导致了无法对资源进行控制和合理分配。比如在这些方面:业务知识分享,技术知识分享,测 试技术分享(技巧和经验)。我们可以用游击队来形容测试人员的角色和地位。开发项目的时候,项目 经理带领成员冲锋陷阵。非项目周期的时候,直线经理说得最多的时候就是“休息、打酱油、喝茶”。 除了上面表述过的“无法有效控制资源和分享项目资源”这样的弊端,作为本地(中国区)最高长官的 直线经理没有团队建设的构想和意愿,导致项目成员缺少人文关怀,更谈不上如何让项目成员成长,严 重影响了团队的建设和发展。再者项目成员的职位级别没有公开(只有高级级别和普通级别之分),大 家不能知道对方的职位级别和资历,个人认为无法进行技术沟通和交流。 不能公开除了级别跟工资体系有关之外,还有原因是直线经理可以在年度考评的时候奖励成员,以到达 个人目的。其实高级和普通级别,工资水平的差距大家是心知肚明,可是我们的管理者却说“非直接关 联”。鄙人也做过公司面试官这种“非直接管理”其实是“国王的新衣”,工资级别在一方面就是体现 个人能力和相应的工资水平。我们的管理者往往保守秘密,没有公开信息,没有为员工的竞争和发展创 造良好的,公平的,透明的环境。试问,高级工程师和工程师就是职位等级可以公开。工程师的的级别 为何不能公开。 有资历的成员(指除高级级别外)不能以合适的身份(或者授权的项目身份)带头,沟通交流信息,整 合资源(设备资源,项目资源),也不能带头教授和分享业务知识和技术知识。 业务知识和技术的分享对团队(团队协作、团队文化)的建设十分重要,因为我个人觉得员工的出走, 在这个开放和竞争的社会十分普遍。如果有一个好的团队建设和“年龄”结果,对个人发展、对项目、 对部门亦或是对公司存亡都是有直接的关系。 |