在公司，测试属于一直被挑战的-个人感觉，无论出了什么问题，最先问责的肯定是测试同学：为什么我们自己测试的时候没有发现？
其实，我也有思考过这个问题，为什么测试的时候没有发现呢？是没有发现还是发现了一个源头没有重视最后导致问题爆发？
我发现，在测试时，每一次报侥幸心理或者想偷懒的时候，都会出问题，比如在某个bug修复后，不想重新构造新的数据，就自己改改数据库用旧数据验证，这个时候流程对新数据就会有bug了； 又比如，测试时发现某个问题，但是多试一次又可以了（这种一般就是那种首次有问题的bug）就想着先不管了，等后面再看，不用说肯定又会被客户发现了。
这个的确是有测试的责任在的，也不是说为测试开脱或者逃避责任。但我觉得这个责任不能只是一味的由测试来承担吧，对于这种情况应该是开发、测试都需要担责，测试没测到是一方面，那开发时没有注意也是问题的一方面，怎么就只有测试同学来承担呢？
上次开会，大佬还说感觉测试是一直在为别人考虑，一直照顾大家的情绪，没有真正的爆发没有发出测试的声音，我想说大概是测试在流程的最底层声音传不上去吧。
又说到要测试左移，测试对产品进行质疑， 我想说，测试凭什么对产品提出质疑呢？ 用户体验或者操作问题，或许还可以；但是业务逻辑根据什么去质疑呢？除非是沉浸在某个行业的大佬，对这个业务领域非常熟悉可以对通用的内容进行质疑，那对客户定制的功能怎么质疑呢？在不了解客户诉求的情况下如何知道产品设计的方案是否符合客户需求呢？
还有测试左移，这里仅仅是测试需要左移吗？ 不应该项目整体都需要左移么？
对于项目质量，是一个开发后就定格的东西，测试进行验证只是尽可能发现问题，为什么不从源头开始重视减少问题的发生呢？
产品需求不闭环要测试补位，开发功能质量低要测试发现问题，那测试怎么能做好呢？
之前看过一篇文章，就是将测试左移的问题，那里提到测试左移不仅仅是测试提前介入项目，更是整体团队的思想左移，从最开始就要有把项目做好的想法。
比如产品的需求是否闭环、每次迭代内容的拆分是否合理，是不是符合拆分原则；开发在进行开发前是不是已经理解需求、是不是已经知道要如何开发、以及功能应该实现到哪种程度才是完成。
我觉得测试左移，可以对这些进行监督，但前提条件是大家都要认可这种做事方式并会按照这个方式进行去做，并且需要和个人考核相关不然这种被约束被束缚的事情，可能坚持不了两天就不了了之了。
现在在项目中，大多数的情况是，产品评完需求就认为自己的事情完成了，开发提测了就认为功能完成了，剩下的就都是测试的事情了，这个时候测试发现开发做的怎么和产品讲的不一样，然后就又要拉齐产品和开发一起对细节。。。浪费时间！
所以最最重要的用例评审环节，开发、产品需要都在，避免开发和测试理解一致但和产品理解有出入！
而且一个项目中的成员要对完成任务有一个统一的认知，只要这个任务没有关闭就都不算是完成，就需要对这件事持续性负责，产品完成了需要监督开发和测试有没有理解到位，开发完成了需要监督测试有没有测试，测试完成并且产品验收通过才算大家的任务都完成了。
最讨厌的话：
测试怎么测的
怎样都行，无所谓
随便吧
我没改啊
