Testing process involves plenty of documentation. How to organize it, so that it is easy to get an information that is needed?
-
This is a bit generic - what documentation are you keeping, and why? Who needs to access it? What are they using it for?– testerabMay 4, 2011 at 19:55
-
Test documentation for testers/QA managers– Nikita BarsukovMay 4, 2011 at 19:56
-
What relevance does this have to testing specifically? It seems to be a generic knowledge management question.– testerabMay 4, 2011 at 20:54
-
I would disagree. For just one example, it's pretty rare that a person will want to read a test plan without also reading the functional spec, and that kind of cross-referencing needs to be easy to do.– Ethel EvansMay 6, 2011 at 23:38
-
Short answer - Get a test management tool and make your company learn to use it "well". IMO, avoid HP ALM or HP Quality Center for test management. It runs on internet explorer only and its hard to find tests in it. You could use third party plugins to make it run on chrome, ff though.– JohnSinkJul 14, 2017 at 17:35
6 Answers
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.
-
+1 for team wiki. I love, love, love this solution. I've seen every one of these solutions, but like the wiki best (followed by source control). May 6, 2011 at 23:39
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.
-
While I agree One Note works, it does to a point. Once you get to a certain size in your documents it becomes unworkable and I've seen it crash and lose pages with work often. Maybe there are better ways to structure it I've just found using SharePoint as a document repository works better.– MichaelFMay 6, 2011 at 12:51
Well, you can try placing all important information on a company wiki/document repository, there are applications that will OCR pdf, doc etc files so you can search for content
-
A search engine capable of efficiently searching documents is a great plus, for example a corporate version of Google search– RsfMay 4, 2011 at 14:58
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.
Documentation is very important in all projects and organisation. Follow TMMi standards. It provides a skeleton on how to store documentation across all the phases of SDLC, templates that one should use and structure them on your sharepoint sites for easy access