没有需求文档，没有功能详细设计，造成的测试纰漏
一个系统的开发需求，仅仅2-3页，一页讲的是背景，另外的讲的是有几个模块。
然后就开始开发，开发凭借自己的经验做出界面与功能，测试也同样凭借经验，列出对应的测试用例，根据界面再进行补充。
造成的问题：在有些功能上，是否这样做，开发不清楚，开发不清楚导致根据开发开发的功能测试用例同样具备了是否可行的模棱两可。解决办法：找产品问清楚是否这么做，最怕的是产品也不知道是否这样做。
非常影响用例质量的地方：有些特殊的输入框或者特殊功能点，因为没有对应的详细文档，不清楚是否做限定，有些比较通用的，测试用例是能够覆盖到的，有些是需要需求文档或功能设计上提出来的，用例上才会覆盖这方面。因为作为测试无法决定这个功能点是否这么做或那么做，而且你觉得得可能是正确的，但是上面人不同意，到时又说不清了。因此用例一般就是根据需求、设计文档来的。所以没有这些文档，用例很难保证质量。导致测试完了，仍然难以让人满意。
这些其实都还好，关键看领导层是否意识到，用例的完整性与产出的前提。然后就是当没有这些前提的时候，工作氛围很重要，如果是在一个工作氛围好，经常谈论本次要开发功能上的细节，然后敲定的，其实做好对应记录，然后你细节不清楚的继续讨论，最后能够得到确定的结果的。这些问题都是能够解决的。
比较糟糕的是一种情况，对应的需求、设计文档没有，完了工作气氛不够活跃，各干各的，基本都不讨论软件本身设计上合理性与是否确认有些功能的确定性。而且有些奇葩要求测试看看这个功能应该怎么设计或者你认为应该是什么样的就怎么设计用例（当然如果你话语权高的话，能敲定还好，否则真的白费功夫），这样就很容易造成后期大量的修改，以及重复的修改。造成的质量后果，懂的都懂。
没有需求文档，功能设计文档，写好的用例上传，也不进行评审，然后出了问题就找测试，如果问题是用例上有测试疏忽了，或者是浅显的问题，测试用例没有覆盖，那么责无旁贷。但是用例都不评审就算了，有些时候，没有定好的功能调整过的、有的是需要改进的、有的是演示人员不了解系统而造成的问题（你演示前不过一遍，演示的时候发现这个功能应该改过了，不知道刷下缓存吗），他妈的都说是bug，那就是丧尽天良的说法了。最关键在这样的前提下还要求100%覆盖，脑子真是个好东西。
如果你是一个测试，当没有需求、功能设计等文档导致你用例产出无法保证质量的，应该尽早提出来，否则后面你提出来了，大概率会认为你能力问题，本身就是你此刻的公司就不清楚这样一个流程，用例产出的根据。然后测试用例设计好了，一定要上传要求评审，如果你根据用例测试完了，出现了，你才有不背锅的可能，但是又时候不管有没有评审，你根据用例测完了，出了问题还是找你，没办法你的处境是你的测试其实不需要依据，系统没问题，你就没事，系统有问题，你就算24小时都在找问题，你还是有事。
无论在什么情况，我们做好问题的记录是很重要的，把你认为是错误，认为该改进（看公司是否有着方面要求，可以尝试，如果公司认为是多余的后续可不做）的点记录下来，拿出来给团队讨论，至于讨论与否，看公司了。无论讨论与否问题记录上传还是要做。至于说觉得不值得留下了，至少该做的我们要做，要走就坚决的。
有些时候积极性是会被团队同化，好的团队，好的气氛，是非常不错的，加上好的流程，合作沟通起来就比较流程，上班自然就觉得充实开心。