测试经验谈-当CS遇到BS，技术不行慌不慌？

以前听说每一个测试经理或者产品经理都是被很多个项目给喂出来的，最近发现普通测试人员和开发人员一样是被项目喂出来的。

具体表现为以下几点：

1、不懂技术，ok，边做边学。（开发也一样呀，自己做不出来的时候拿别人的代码用）

2、不懂业务，ok，参加开发例会，开会过程中总是问测试有什么意见。

3、用例设计拿出来show show ，ok，show 完一遍show二遍，每次show的时候大家都能发现新问题，有开发的，有测试没有覆盖到的，甚至在设计用例的时候还会发现测试的困难，提早把风险报出来。

这种情况下，我感觉测试人员尽早参与测试的价值并不在于最终用例设计多么完美，考虑多么充分，而是在于用例设计的过程中发现问题，帮助开发人员修正开发方案，这就把测试价值真正落实在产品开发质量上面。

那么，这种情况下，测试的技术能力重要吗？对个人来说，重要。但是对于团队来说，未必。为什么呢？因为团队整体水平都处于一个起步阶段，所有的开发和测试都是转型一个新的领域。

通常一个项目在转型的时候留下的人都是可靠的人，以前做CS 架构，现在转BS架构。CS架构测试的是客户端，BS架构测试的是Web网页。测试关注点是不一样的。在开发转型做技术储备的时候，测试也在做技术储备。这就是产品团队的常态。所以不要再担心从来没有做过的模块，不要担心从来没接触过的技术。有项目有团队给你玩，就是机会。

对于自我要求比较高的同学来说，往往希望自己拿出去的东西能尽善尽美，这种同学有一个梗，就是妄图在工作中能完美落地学到的测试理论，自我感觉能让人引以为傲的测试技能就是基本测试理论和专业的用例设计方法，这是不科学的，是低效的。

我们项目中有各种身份的成员，能力各不相同，也有各种各样的牛人。工作中要学会合作，为了达到不拖后腿的目的，要敢于show出不完美的方案，在不完美中不断迭代，快速完善，这种效率是一个人埋头苦干远远达不到的。而且一个人埋头苦思投入的精力倍增，对个人成长非常不利。越计较越难出成果，越计较越低效，越计较越头脑发昏越不开心。为什么不把工作快点“解决”，可以腾出来时间和精力做更容易给你带来成就感的事情？

不断达成工作目标，用比别人更快速的方式，这种体验是不是光想想都能让人热血沸腾？而且现实情况是，测试人员可以不懂技术，甚至可以因为技术欠缺导致在前期不投入测试困难的用例。但是测试人员一定要懂这个东西应该怎么测，要知道现在做不到的，实现不了的测试方案是个风险，然后要整个团队的人知道，越早知道越好。忌一个人埋头苦干。

最后，知道自己不懂的太多，要学习的东西太多的时候，好慌，所以还是要定定神。确定做事方针如下：粮食要一点一点吃，书要一点一点看。现在做不到的事情，记录下难点，看看别人能不能做，如果别人也不能做又非做不可，那就自己定个计划攻克那些难点。

看完这篇文章有没有什么感想，欢迎评论。