继续对《炮轰“测试左移”，向软件测试领域的“歪理邪说”宣战》的评论进行整理，评论的第一部分请看
评论内容请见下文：
评论7：奇云
我觉的得看具体项目，项目迭代快，时间紧凑的，开发经常996的，测试压力轻的可以适当给开发分担点压力，项目迭代慢，时间充裕的，开发写单元测试，也是ok的，开发自己也会测试自己的代码，忙不过来的时候，就得大家共同去分工合作，目标都是保证产品质量进度，是一致的，领导把人员合理用起来就行，别出现一部分人忙的要猝死，一部分人闲的蛋疼，需要领导，开发测试人员共同去评估协调的
领测老贺回复：
是的，老贺也认同你的处理。但这里我想强调一下，当一个项目时间非常紧迫的时候，也就意味着不会生产出一个高质量的产品。因为质量里面有个三角：质量，成本，进度。
质量三角
我们什么时候都逃不脱客观规律，只能在这里面进行取舍。
这里我想重申一下，不同的产品对质量要求是不同的，我们不能拿航天软件的品质，对标互联网产品，反之也不行。当我们在讨论质量，讨论之下的软件测试的时候，必须明确周境。
通常意义上的互联网产品不是靠高强度的软件测试保证质量的，所以只进行单功能点验证很难说对还是不对。但是你是不是应该学习他们的方法，要自己考虑！
评论8：安慕风尘笑为茜
领测老贺回复：
特别喜欢这样的观点！活在当下！不管你现在从事的是什么岗位，既然已经开始工作了，就把手头的事情做好，努力的学习，努力的解决问题。
不过，当工作一段时间后，还是要看看体系，方法。所有公司，所有人都必须是共同合作，才能解决问题，这样也就必然需要流程，体系，分工。这样才能解决更大，更困难的问题。
一定要记得：“复杂的事情简单化，简单的事情标准化，标准的事情流程化，流程的事情自动化。”这是做复杂事情的心法！
文章评论