其实，我一度想，这个标题是不是改为叫“我为什么无法成功”，更贴切一些。各位朋友，你们说呢？
每次测试前都要问开发逻辑和数据，总感觉没有掌控感，越来越感觉工作没有意思
——小红书帖子
今天我看到上边的帖子，挺有感触的，之前我在一个做工业产品的创业团队呆过3个月，试用期一过，我就离开了。
我们的产品是卖给企业的，企业采购要招标，招标现场会对产品有一个验收测试。老板的要求很简单，就是通过验收测试。
如何实现？老板的想法也很简单，找一个测试，产品生产出来了，招标之前先自己做一下验收测试。妥活儿了。
但实际上，如果质量工作不穿插在产品的整个研发周期里，不从需求阶段就介入的话，等产品生产出来了做一个黑盒验收，能不能通过呢？只能是撞大运，如果运气不好碰上底层错误，硬件要不要改？能不能改？不好说。
后来在分析成功竞标的竞品数据时，我发现果然几家竞品的售后情况都很频繁（每一次售后都是钱，记得这个，下边会考），我不确定竞品的情况，但也许这些老板的想法其实都是一样的。
好了，回到开头这个小红书的帖子，我在评论区留下了我的建议，我在评论区里说“这很难”，并不是嘴上说说，是因为我自己遇到此种情况的时候，也无法做到，还是选择的尽快离开。
其实也并不是无法做到，频繁的售后是很大的一块成本，这就是一个很好用的抓手。最简单的，我只要告诉老板，按照我的想法去做，就可以减少售后，就能省钱，至少这件事儿是有的谈的。但我并没有。
对于一个普通人来说，大部人和我一样在遇到这种情况的时候，与其说无法做到，不如说是没有心情去做，没有勇气去做，没有欲望去做，反正就是这个意思吧。
选择离开可能是最快最省事儿的，所以大部分人其实是没法成功的。成功的人身上真的需要有种“我相信，我看见”的特质的。
看代码学代码是必要的，但是不是你这里的关键问题，你这里关键问题还是要建立完善的评审机制，需求先评需求，开发再评技术实现方案，然后你评测试方案/用例，评审会上提问题，光明正大，可以解决不回复的问题。你们团队里现在没有这套机制，应该是老板并不重视测试或者说都不重视技术，你做为测试工程师可以尝试说服老板建立这套机制，告诉老板，这对提高产品质量非常有帮助，提高了产品质量就能省钱，这个事情很难，但是做成了，你就会有很大的收益，做不成，你也可以把这套牛逼写进简历里，告诉下家，你做了什么，到哪里功败垂成了。
————————我在评论区的留言