这一段时间工作中，测试一些任务变更，总能测到其他同事测过的任务，或是对以前任务功能的修改补充，或是要用到以前任务实现的功能。经历了几个，总是能发现一些问题，引发了我一些想法。

　　最开始是发现一些以前功能逻辑上的一些问题，比如程序缺陷，功能完善性，可用易用性，提示友好性以及系统通用功能等方面的问题。虽然测试本身是不可能做到完全没问题的，但是有些问题还是应该发现的，尤其是真正的程序缺陷。其他一些问题尽管大家可能会认为可改可不改，但是如果从软件质量，用户感受和系统功能一致性的角度来说，我仍然认为程序修正是绝对有必要的。确实有的地方没有人明确要求怎样弹出提示语，但是我们就不会对比一下不同的提示语所能带给用户的感受吗？确实有的地方没有人明确要求系统通用功能一定要实现，但是我们天天测这个系统就没有一点儿积累的测试经验吗？确实有的地方没有人明确要求要做选择条件限制，但是我们根据业务逻辑就不能发现这是应当的吗？甚至可以认为这就是个遗漏的设计缺陷呢？

　　做测试工作就不是只能按照设计文档来做，文档上没有写的，或者描述不够清晰的，我们就自然而然的过去了，没有一点儿自己的测试思想，这让我觉得做事情做的太没意思了。可能会认为我是太认真，其实我倒觉得这是一名合格的测试人员应该做到的，我们不应该是设计和开发的跟随者，我们应该是跟他们平行的，独立的，经过我们手的软件我们应该在保证软件质量的同时，力求让它成为一个优秀的软件。

　　当然，在当时测试时也都已经发现了不少bug，所以之前的努力和成果是不可磨灭的，然而这些问题的提出，只是想让大家做的更好，经验不足的继续积累经验，经验充足的提高测试水平，所以也曾总结出来与同事进行一些分享。

　　即使测试人员是新人，测试过的功能我发现了问题，若是由于对系统功能不够熟悉这种经验原因遗漏的，暂且可以有谅解的理由，就像上面提到的某些问题，但若是根本就没测，或者简单了事的原因遗漏的，我认为这是绝不能轻易忽视的。不是随便说说，确实有这样情况发生的，置了测试通过的任务我们就会认为通过，若不检查或者使用，真是不会发现的。软件质量没有严格的标准，但是我们总能知道哪些软件好用哪些软件不好用，所以软件实际上是有标准的。测试过的功能，当有人在用的时候，不管是测试同事，还是设计人员，还是最终用户，就会知道它的质量怎样。

　　做测试工作要有一种责任感，更多时候做的认真做的投入，我觉得都是责任在使然，但责任并不是一种负担，我认为它是做任何事情最基本的要求。

　　对于这些发现的遗留问题，大家可以认可，也可以不认可，但是对于问题的提出是不应质疑的。因为问题的提出，一定是有它的立场和道理的，如果我们能认真的理解或者学习一下，能消化的东西总能帮助和提高自己的，这不也是一种收获吗？这里能否消化吸收最重要的是要看个人有没有认可这种工作意识和测试思想，能否做到自己本职该做的事情就是要看个人有没有认可这种工作责任感了。