见怪不怪的测试

   团队组建有了大半年了，人员也稳定了下来，总以为这样可以达到一个很好的合作效果，效率啦，合作啦，通通开始升级啦。

   没想到，今天检查了一个功能，发现大家做的都很规范，但是效果很让人觉得诡异，例如“给我的推荐”这样的菜单也被定为一个应用程序连接。这是一个逻辑错误，就像黑衣人1里面，恐龙与那爱因斯坦书籍的小女孩谁是威胁的问题。

   为此晚饭都没有吃好，之后我又和不同的开发人员与测试人员分别谈话，发现大家原来对这样的问题见怪不怪，从意识深处根本没有意识到这是一个逻辑错误。

   我相信如果是客户看得话，一眼就看出问题，因为他觉得很奇怪。

   气过之后，有觉得这也许是因为项目时间长了，大家对项目的逻辑错误失去了判别能力？？？

   请问各位如何才能使开发人员/测试人员保持一个清醒的头脑呢？？


   

我是测试人员，测试过一段时间后，很容易软件疲劳的，比如一些显而易见的问题，根本注意不到，或者受开发人员的影响，信任了他们的解释。
感觉解决方法有两个，第一就是细化需求，一切都写到明面上，对错一目了然，没有含糊的地方，而且写细了，在需求评审的时候，大家也可以对不确定的地方集思广益，否则到后期设计编码阶段，很多情况下，开发人员直接按照自己理解的做了，而且一下想法还可能影响到测试人员；第二就是专家或用户审核，无论如何，最后用软件的还是用户，不是开发和测试，开发和测试受需求等影响，认为正确的，但是到客户那里可能就有其他的说法了。
测试人员不是万能的啊，都需要有参照（业务、需求、设计或其他文档，或参与开发会议等等），而且开发人员可能只做一个项目，测试人员很多时候同时测试很多的项目的。

需求评审、设计评审都去哪了，上游的输入输出没控制好，到头来怪罪到下游的编码人员身上，楼主认为合适吗？在责备编码人员没有意识之前，为什么不先好好地重审和整顿一下上游需求管理和设计人员的意识呢……
如果说没有上游的这些人员，那我认为这个问题最大的责任人是楼主你，这些看上去不像是编码或者实现级别上的错误，更像是全局上的把握有问题，而有资格找各开发、测试人员谈话的你，似乎正是这个把握全局的人吧？
当然如果需求输出是正确的，视觉设计的界面也是正确的，设计方案也是正确的，只是编码实施的时候和上游的输入有误差，那自然是编码人员的问题，直接按管理规章给予处罚是完全不需要任何纠结的。

有没有可能是你项目中高级别错误太多，让测试人员都麻木了，对于bug的敏感度下降？

那是因为你没有把一个项目仅仅当作是一个外包看待。

而测试人员和开发人员把它仅仅当作是一个外包项目罢了。

这么认真，没吃好饭 ， 好员工

是一个菜单还是链接 完全是业务和产品设计人员定义的.定义完成出静态页面.程序员负责将静态页面做成动态功能.这问题明显是出在产品设计上面 怎么能怪开发和测试人员呢.

我非常同意这个观点。这并非是为开发或测试推卸责任。

页面如何布局，如何交互，这是一件很严肃的事情，是需要UI设计师去做设计，业务去确认的。对其正确与否的判定规则也是要由UI设计师来规定的。

考虑以下场景，你觉得应该是个菜单，而不是链接，并且从基本常识来看就应该是个菜单。但是从UI设计师那就是要求是链接，那我认为你就应该接受是个链接的事实。这是大家共事的基础，不要越界。

如果说，你们没有UI设计师这个角色呢？ 这很常见，很多公司都是需求与开发组长设计页面，美工仅作效果。没有一个专业的角色来控制界面交互设计原则。但是就算在这种情况下，也不能把界面与交互的设计原则控制工作分散给开发和测试。一个瓜被很多人切只能是大小不一，体无完肤。所以归根在这种情况下，整个项目组到底是谁在事实上掌控这界面交互的设计权？在整个项目周期中，到底有没有为界面交互的设计留出一个评审点？ 如果这一切都没有，那么就像你现在这种情况：这个地方我认为出问题了，但是我突然发现现有的机制无法避免这个问题。所以只好归结到人不敏感了。

公司里面，各个职位并不是很明确的。尤其是UI设计师，这个对于Boss来说更是可有可无的。甚至有些是设置了这个岗位，但是却由对js稍微熟悉的JAVA开发人员兼任；
更经常的问题是，需求做完之后，全部都一股脑的砸给了开发人员，开发人员先被砸晕，过了一个星期才恢复过来，而后被时间逼迫着加班加点完成任务；之后一股脑的砸给测试；
测试前面正嘻嘻哈哈的看着开发的忙碌，而后也被开发给砸的头晕，之后进入发狂的测试；
可惜由于测试对于需求不熟悉（需求未宣讲，或者有调整），测试问开发这个是啥功能，更有一些公司，让开发在功能结束之后写个所谓的单元测试报告，而测试就按照开发写的单元测试报告重新验证开发人员提交的功能；
之后。。。。再之后，，杯具就是这样子来的。。

各种杯具放在程序员与测试之间，
你只看到了桌面上 的。
被收到茶几底下的你看到几个？