Best practices of scripted testing
One “QA” reads a document how the application is going to be. To say better, it’s a writing of someone’s beliefs how certain, those explicitly described, aspects of an application should be according to that someone, at some point of time.
Then the “QA” creates another writing how the application is going to be, is going to be tested. To say better, what procedures should be executed in what order, what to look for, and what to expect. Oh, by the way, there’s no need to check the application itself or other sources. And there’s no time allotted for that.
Then another “QA” reads the document about how the application is going to be, is going to be tested, and “provides comments” on how the document about how the application is going to be, is going to be tested, is going to be improved, for better testing.
Then a “BA” reads the document about how the application is going to be, is going to be tested with comments how the document is going to be improved, and either “approves” or “provides comments” on how the document that is going to be improved, for better testing, of the application that is going to be, was supposed to be tested, should be improved, for better testing.
This cycle repeats until “testing phase” kicks in.
Of course, during “testing phase”, all test cases must be urgently “executed” regardless of their review/approval status, and if there wasn’t enough time or delivery was incomplete, they will be executed partially.
Luckily, nobody asks to review the actual test execution results.
No, seriously. Why would they?