Testing process involves plenty of documentation. How to organize it, so that it is easy to get an information that is needed?
This varies from organization to organization and team to team and application to application. It all depends on what works best for your situation.
1) Test documentation attached to requirements. This works well with HP's Quality Center. All test data is in the same application and tests are individually linked to a master test plan and a specific requirement.
2) Test documentation is stored independantly. In these cases, all test data is stored in a central location accessable to the entire test team. Test scripts/notes are typically stored with the test plan and organized by release.
3) Team wiki. Test data is stored on a wiki of some sorts. This can work well when development and business analysts also use the same wiki as it leads to collaboration.
4) Test documentation is stored with code. In the cases of an integrated environment, I've seen cases where test data is stored in the same source control as the code, and tests are linked to pieces of code but left out of the build process.
These are just some ways, but again, it depends on the situation.
I have found OneNote to be an excellent tool for storing this kind of data. It has a very hierarchical organization which also is friendly to reorganization. Also, you can put a notebook on a network drive and have the whole team work on the same documents.
My team used to keep everything in word documents on Sharepoint. By keeping everything in a single "notebook" we can now search within every document and don't have to worry about checking things in and out.
Where I work we are not quite as progressive. We simply store the documents categorized by product feature (i.e., modules of the application) on the network.
Installation testing is slightly different. We store per the version release; also the installation testing documents are stored located with the repository of tasks (anomalies). There is nothing special about this; it is just easier for the developers to go to that location.
In terms of straight documentation, I have found Confluence to be widely used. If documents are more informal and provide system usage guidelines, wikis, a shared server drive, or a tool like Dropbox work well with teams. Dropbox may be quick to setup, but file version issues come at a cost to this.
On the other side, documentation can integrate with tools, so test case executions can be recorded in software, etc. A Test Plan may be stored separately, but test suites, test procedures, anomaly reports, test logs, etc have many tools tailored to these needs. They are accessible over a network, so other supporting documentation could be placed nearby. If the tool route is adopted later, many tools can import or export existing data.