While most of us agree that how hard it is to cope with the nagging of the documentation stuff required while the ordinary system team (i.e. the developers along with their PM) is working off to resolve the baselines of the code. In the testing world, certain things don’t work right. What written up there in that document might not have the effect while its up there on the screen or is running behind the code.
There are certain aspects sometimes on a project which is run conventionally. You can’t have all the information available to all parties at one time and have satisfied as well. In my previous project experience, I came across the scenario where the users were comparatively weren’t satisfied with what was tested and what was left out of the scope for testing. Involving them, in our daily 30 min test scrum with the developers as well helped sort out getting the answers straight and clear.
Although, if a project is managed through the agile methods things are little different and following any agile method for status meetings and testing becomes easier for all of the team to follow but in a scenario where there is an element of conventional project running – certain parties might not agree (partial or completely) with this approach. Hence, for those parties there should be a one-on-one approach to make things better.