忽然看到很久没来这里写过博客了。
到底是工作太忙，或者还是太懒，失去了坚持，这些，现在都已经不那么重要了。对于已经发生的事实，过度的追究谁的责任其实是在浪费时间的。就像是上线的产品，忽然爆出了几个bug，这个时候首要的问题是该如何去将这种bug带来的影响降到最低，或者弥补带来的损失，而不是先去讨论这是谁的责任。
but，事实上，在大部分公司，一般出了这种事，总会有个角色被推出来，不管是不是他的责任，首先便是一大堆为什么会这样的问题抛过去；之后发泄完了才去想该怎样解决。怕承担过失和担心受到责罚，总是人的天性，很难避免，但是在一起做事的时候，这种东西还是少点的好。若是都是刺猬，那能指望谁和谁又在一起紧密团结亲密无间？
一起共同做项目，总是要想办法把项目做的更好一点，因为只有这样，我们才能在共同的事情中找到契合点，才能更默契的一起团结共事。
而要做的好，离不开三个过程：设计，实现，验证。这三个阶段看起来似乎是线性的，在执行的时候，几乎也是线性的。but，这样真的好么？
也许你没听过盲人摸象的故事，那你也总该知道人的视角无论如何也达不到360度吧。同理，每个人自己的想法总是会带有一定的主观色彩和独立视角的，就像设计和产品只关注期望的是个什么东西，开发只关注这个功能怎样实现才最简单省事，测试只关心经过我手的东西还有没有已知的问题；人人都像刺猬，只对自己的部分柔软，对其他的人部分不闻不问，甚至针锋相对，这样的地方会产出一个好的团队和产品么？就算会有，过程中真正快乐的又有几个？
我们不能期望设计人员的技术多么了解，也不能期望技术人员都有一个完美无瑕的心态去为自己的作品保驾护航，更不能要求测试验收人员可以在短时间内把所有的需求和点和技术中的问题都照顾到。因为我们只是一个最多只有180度视角的生物，只能看到自己前面的东西。但是，我们可以通过另一种方式来让我们产出的东西尽可能的有着360度的完美，那就是合作。
至于怎么合作，先暂时卖个关子，作为一个测试人员，还是先从我的角度说点其他东西，也许你看完后自己就懂得了。
我所理解的测试角色划分，大致分为三种：一种是跟着产品和开发后面不能的验证着别人的猜测，也就是典型的helper；第二种是在产品和开发中间起一种桥梁的作用，来平衡两个角色之间的差异，同时也通过自己的方式来促进两者的融合，这种可以称呼为linker；第三种是直接介入或者融入产品设计和代码设计中去，让整个过程从一开始就缩小差异化，这种，可以称呼为enginer。
上面的划分，与传统按照比较模糊的初中高等级的划分并不相同，但是其中也有一些相同的东西，那就是不同等级需要具备的东西。
首先，一个测试人员的作用是什么？保证产品质量？offcause！提高生产效率？maybe！保证产品质量？Oh no！这个就是我们所听到的绝大部分回答，也是目前我们所面临的最大困境。
保证产品质量，这个比较简单了，黑盒测试，自动化测试，验收测试等等，都具备这个前提和作用，也是我们在进入行业初时前辈们说的测试的工作意义；并且，几乎所有课本上也都是这么告诉我们的。这就是测试！That's truth！
我们费劲千辛万苦，总在别人的猜测和行为方式上找别人的疏漏，就算我们尽可能的把别人的一句话具体到每一个字，也还是会有产品和开发在理解上的不同而导致的结果。测试无尽期，奈何海枯石烂bug仍无穷！所以，我们只能勤勤恳恳的做着一个修补匠，去各种地方抹黑找坑。也许你觉得很苦逼，但是苦逼有何用，我们就是干这个的，不是么？到了线上，出了问题，也总得有人为这个负责，不是么？这时候会是谁呢？还用想么？我们就是干这个的，不是么？
也许日子久了，你会发现，人生何其苦，工作和整个流程一堆冗余，你也无可奈何。因为你不是干这个的，不是么？
或许，我们可以换个角度想一想，或许我们的作用不止于我们干的那些呢？
开发技术上的东西，我们也许不懂，但是首先我们可以优化一下我们自己的工作方式和工作效率啊。也许你会又一脸苦逼，how can I do it？但是你苦逼又有什么用呢，老大们不可能为了一件在他们看来很简单的又不是很重要的事情就给你加工资，就给你各种你想着都眼红的福利和待遇。所以，为了自己还是优化一点点吧，没办法，我们就是干的这个的。学学自动化，学学代码基础，学学性能测试，学学那些利于你工作的东西，你总能在自己的地方促进整个工作的优化，甚至让你认为高高在上的开发和产品对你各种佩服，从而有时间去考虑你之前没想过的事情。什么？你在怀疑自己能不能做到？我们就是干这个的，不是么？
退一万步讲，你认为工作的够久了，也没精力去学那些了，但是呢，你就只能去做一个苦逼的helper么？首先你要知道，基本上，你能遇到的产品和设计都不知道hello world是怎么回事，而你却知道这些东西该怎么写，这就是你的优势，不是么？当开发和产品设计还在一个纠结于对方到底他喵的知不知道这个有多么复杂，一个纠结于为什么对方总像是个二次元世界的人一样难以沟通的时候，你可以用自己通俗的话把你能理解的高深的开发人员的话翻译给产品听，在两者中间形成一个真正的linker，在一开始就达成共识；并且在后期验证的时候让开发，产品和设计也一起对这些提一些可能的问题点，这样，很多你觉得很莫名其妙的bug和问题就能在这里被kill了。对比一下以前苦逼的日子，你是不是觉得人生还是可以有点起色的。不用怀疑，我们就是干这个的，不是么？
也许有一天，当你觉得你比开发都要牛逼了，或者你真的能看得懂开发的代码了，但是你还在自己的一亩三分地上不停耕耘，并且还总是遇到各种你觉得都不可思议的奇葩问题的时候，你或者可以参与到开发的代码设计和code review中去。尽早的把以后会坑自己的bug都在早一点的时间跟开发一起搞定，这样，到你的时候你就会发现原来人生真的可以再悠闲一点。但是，悠闲是悠闲了，我们参与的部分，如果不能覆盖全部code的时候，还总是会遇到一些奇葩问题的，尤其是在我们做用户产品的时候。如果你觉得奇葩问题是因为一些在code过程中养成一种习惯或者遵照一定规则就可以搞定的时候，那何不去想办法推进一些优化开发流程的事情来给自己的人生减减负担。这样到我们这里的时候，我们才能真的去想一些用来提高自己的东西和自己感兴趣的东西。说起来，我们就是干这个的，不是么？
梦想很美好，但是现实很残酷。就像很多人都知道马丁的I have a dream，但是马丁却没有活着看到那一天的到来。code和技术流的美好，不是每一个人都能有心情去享受的，不是么？但是，像我们知道的那样，我们毕竟比产品更了解技术，比技术更了解产品。只有这样了么？你想想，我们比他们所有人都更了解现在的项目作品有哪些问题，不是么？既然我们知道产品这么设计会有这样的问题，那么在以后产品设计的时候，我们能不能一起过去跟他们说说他们那样设计的话可能会有什么问题，再把最后尽可能完善和perfect的产品设计给开发，并且告诉他们这个设计有哪些需要注意的点。这样一来，你不就从一开始又避免了因为产品不靠谱，没想明白就造成的问题了么？而且因为一些问题在前期产品设计层面也避免了，整个产品的质量不是已经提高了么？这样想想是不是有点小激动啊。但是真的说起来，我们就是干这个的，不是么？
现在，回到原来的主题。
合作，其实就是我们中的各个角色在自己的工作范围内，根据当前存在的问题共同去不断针对性的了解这些问题的根源，并且一起想办法解决的过程。这中间，可能会有冲突，可能会有分歧，但是只要我们的目的是一致的，最后我们总能一种更优化的方式来前进。就跟刺猬一样，当刺猬都向前跑的时候，又有谁会被彼此刻意伤到呢？
说回来，因为我们的工作可以接触到各个阶段的东西，所以，我们就更应该主动去了解一些，以便于最后成为整个团队的enginer。
你想啊，我们本来就是干这个的，不是吗？