软件测试活动中有些时候在所难免被开发等抱怨不懂变通，抵死坚持，甚至可能搞得大家形成对抗。今天笔者针对软件测试所应坚持和变通话题，谈谈自己的认识和看法。
坚持不等于顽固。提到坚持，经常与底线联系起来，那软件测试有哪些底线呢？
软件需求是第一条底线
我认为不管是采用口述，原型设计还是文档描述，只要能阐明测试内容，具有可测性，就可以。不要过分去强调必须符合什么文档规范，特别在进行敏捷开发时。当然，如果我们是在做一个规范性要求很高的产品，就需要严格按照规范进行。这是很容易造成冲突的地方，需要测试人员根据项目实际情况，去进行坚持和变通，不要忘记底线即可。
测试请求规范是第二条底线
每次开发提交测试版本，应该标明测试的内容，可能对哪些模块或功能造成的影响，以及特殊功能的测试建议。可以不要求具体按照什么模板编写，但一定要有。
测试用例可以没有，但必须列出每一条测试需求点
包括需求中提到的，行业通用的，以及其它的一些隐形需求，如安全、性能等。没有坚持这条底线，会造成各种漏测，导致最后大家对测试人员失去信心。这也是体现一个测试人员水平的基本点，所以必须坚持。
bug规范
这是很多经验丰富的测试人员也容易忽视的地方。我认为新建bug，除摘要，所属项目，等级，模块，经办人等基本信息之外，bug还必须标明所测环境，测试数据，具体问题描述，能截图的必须截图。只有这样的bug，开发人员才能快速的复现与解决。避免只有一个摘要的bug，这样会跟开发复现定位问题造成困扰，首先理解bug就是困难的第一关。其次，关闭，重新打开bug等必须注释说明。
测试报告必须以客观得态度，真实的测试数据为依据进行编写
避免推测主观意识的东西加注在里面。在面对内部的报告，一定要坚持该底线，这样上面才能了解产品的真实情况，对产品是否进入验收或发布做出正确权衡。当然，如果有老板授权，只是为应付投标、申报等，那就变通处理吧。
最后，谨记，测试是为了尽可能得发现bug而执行程序的过程。如果确实是bug，就果断的提吧，至于是否本次更改，由CCB类似小组决定。相信这些能给你在后续的坚持和变通提供帮助。