单元测试之组织保障

这几天一直都在思考新项目中,如何促使公司能够最终真正使用上单元测试。前几天发的一篇《单元测试之关键问题解答 》主要写的是我在实践过程中,针对我遇到的一些非技术问题的思考。后来我看到一篇和我博文一样标题的文章《单元测试之关键问题解答》。拜读了之后,发现他对我的思考方向有些误解。虽然这样,因为这些导致他的失望,我还是表示十分的道歉。补充一下,这篇文章不错,推荐大家阅读一下。

前几天和我的微软同学聊起微软的自动化测试的时候,他向我提到了几个概念BVT(Build Verification Test)和Smoke Test,这让我注意到一个问题,TDD中并没有解决好复杂系统的全面测试问题。要知道大多数人的单元测试概念,是有KENT BECK的测试驱动开发中带来的。但是,要让单元测试完整应用起来,是需要相当的组织结构保障的。

在聊天的过程中,有一点非常值得关注,那就是微软的Software Design Engineer in Test (SDET)角色。据他讲,在微软,SDET和开发的待遇是一样的。显然,微软是非常重视测试的。

在开篇提到的另一篇同名称的文章中,也对单元测试做了诠释,而且从文章来看,他应该是一位咨询师。我这里不说其他,但从单元测试需要咨询,就说明了一个问题,单元测试不是只靠技术和理念的认识就能简单做起来的。

从很多公司的尝试未果,就可以看出,我们相对于微软这类成功应用了自动化测试的公司相比,我们并没有很好的组织保障。让公司里的开发来做测试,一来会感觉实在浪费,二来重复性工作和创造性工作的不一样,会让很多人止步。

这两年,我一直被领导困扰着。他们在思考问题的时候,总是说什么组织结构。而我却更重视技术解决问题。想想看,如果能完全靠技术解决问题,那么就不需要管理那么麻烦了。我相信很多人也会和我有同样的观点。

可是,不要忘了,单元测试的主体是人。大凡是人,就必须有管理。我这里所说的管理,不是领导的管理,而是组织结构的保障。在最近的工作过程中,我逐步意识到了保障的力量。忽视组织保障,团队的工作会变得松散而无方向;反之,大家会知道做什么会得到鼓励,做什么会得到批评。

因此,相对于大讲那些测试理论,最先要解决的是组织结构。这才是保障单元测试成功实施的重要措施。我这里主要是从推动单元测试的工作入手的。因此考虑其组织结构,可以由公司的技术高手成立,辅助项目开发。这个组织在项目相对独立,直接对项目经理负责,而不对项目进度负责。

在组织结构问题中,我重点说明一下进度和质量的问题。大家很容易明白,项目中对进度的反应是如何的强烈。事实上,由于质量的衡量标准相对比较复杂和不明确,导致质量在进度面前,经常容易被牺牲。反过来,我们现在的单元测试就是要从质量入手,因此其组织机构一定要相对独立于保障进度的组织。这样,我们的工作才容易进行下去。

以前单元测试往往是开发的Leader提出来的,但是,Leader往往需要对进度负责,单单从这点来看,单元测试往往会以失败告终是不足为怪的。

在建立了单元测试机构之后,就是建立测试流程规范。在推广初期,并不一定需要建立完备的流程。只需要考虑好几个关键点,让单元测试工作起来。好多机制就是越转越好!否则,再完备的机制也容易因为磨合不好而最终失败。

重要的是,建立单元测试报告的优先处理机制。对于单元测试的失败,应该有考核机制来保障必须在第一时间得到处理。在初期,细节的处理,并没有那些测试理论中讲得那么重要。关键要与你的现有组织磨合顺利。

等到你的项目中的单元测试成功运作之后,再重新考虑如何优化流程。流程和组织一般来说是相辅相成的。可能在优化流程的时候,再修改组织结构。

关于微软如何进行自动化测试,推荐大家阅读我整理转载的《微软的软件测试方法》。 

你可能感兴趣的:(单元测试,职场,思考,休闲,组织保障)