The software tester works with test case documents everyday, default scenarios that are based on system requirements sent by the product management team or the clients themselves. They are valuable source of information because they are the tests that outline how the system should work in general based on how the client sees it. The software tester uses these tests to decide whether a feature in the system is working properly or not, marks each case in success or fail flags, and reports the documentation to the authority.
Test case documents, however, are (more often than not) limited to only several flows of operation. Edges in the system processes are usually overlooked. Trouble then arises when the software tester becomes a slave of the grind work, when she just walks in the office and checks system updates based on the list, and not thinking of the other hidden tests that are possible.
Test case documents can only guide the remarkable software tester. Product quality checks remain the result of a busy thinking mind trying to break the software. Go beyond the documents.