The process which we generally follow for quality is:
Everytime we receive a Requirement document, we study the same, analyse it, discuss it and then after multiple rounds of the same process it is finally kicked-off i.e. Business Requirement Document (BRD) is reviewed and approved and can be referred both by developers and QAs. So as a part of QA team we are assigned with the task of creating test cases as per the BRD, sometimes we have mock-ups to refer and most of the times we don't have any mock-ups.
Now, the issue being faced is we are able to create test cases as per BRD, but they are always not enough because BRD covers only the Happy paths or you can say the positive sides of the product i.e. How product is expected to work., it doesn't contain anything about the real world interference of the product or the negative cases. Due to all this, many issues are reported during the dynamic testing phase, when system is actually being used or tested. Such bugs/issues are reported which are not documented at all during the test case creation phase.
Because of all this, test report many a times says test cases are passed (not 100%) but still there are lot of bugs or in easy way many bugs exists at tracker which do not have any Test case ID (ideally every bug should have a test case ID, may not be 100% but at least 80-90%), to overcome this situation many a times QAs have to create or update test cases according to the bugs (which I know is not a good practice). This problem becomes more severe when we don't have any mock-ups.
How such bugs can be captured, using the Proactive approach i.e. create test cases first and during their execution report the bugs (if any) or the approach we are following is fine?
How one can be sure that, only the execution of created (reviewed and approved) test cases will lead to good quality?
As many issues are related to -ve scenarios which are missed in documentation. Either we need to change/update Testing Approach or we need to update the mind set (resource training etc.) for creating test cases. I hope many other manual testers have faced the same issue.