When I'm working to get new processes published, or writing informal tests that need to be accessed by other team members, I sometimes feel restricted by corporate intranet and share point services. These tools are great for publishing formal information, or storing common access templates, but they limit your ability to express ideas and communicate effectively within smaller teams.
Using a hosted wiki service such as Google Sites within test or development environments can give you the freedom to develop processes, applications, and test documentation without formally committing information to clients or end users. You can freely communicate with each other using these very professional tools.
If you are creating processes for a test environment, it is far more productive to get practices that are being designed out to your team as soon as possible. This allows your process implementation to be a continuous movement, taking away the pain of implementing a multitude of practices in one go.
Wiki's provides the ability to publish work and forward relevant links or information to the team as and when you feel. Often, with an intranet, the content has to be managed and controlled and adhere to standards. With your internal team wiki, you can remove yourself from these restrictions and have a open shared information portal.
At some point some of the information that we draft out within the wiki needs to be formalised and perhaps published to a Sharepoint serves or intranet. When you finally do publish you at least know that the information is refined and in common use.
A Wiki is also a great tool for constructing adhoc test documentation that can be shared freely between team users. If I have to develop tests in an agile environment, I set up a page within a wiki and create tables that allow the input of values. I can share these tests with all team members very easily without having to formally publish them. This methodology can be used to construct tests within other test process environments.
Using a hosted wiki service such as Google Sites within test or development environments can give you the freedom to develop processes, applications, and test documentation without formally committing information to clients or end users. You can freely communicate with each other using these very professional tools.
If you are creating processes for a test environment, it is far more productive to get practices that are being designed out to your team as soon as possible. This allows your process implementation to be a continuous movement, taking away the pain of implementing a multitude of practices in one go.
Wiki's provides the ability to publish work and forward relevant links or information to the team as and when you feel. Often, with an intranet, the content has to be managed and controlled and adhere to standards. With your internal team wiki, you can remove yourself from these restrictions and have a open shared information portal.
At some point some of the information that we draft out within the wiki needs to be formalised and perhaps published to a Sharepoint serves or intranet. When you finally do publish you at least know that the information is refined and in common use.
A Wiki is also a great tool for constructing adhoc test documentation that can be shared freely between team users. If I have to develop tests in an agile environment, I set up a page within a wiki and create tables that allow the input of values. I can share these tests with all team members very easily without having to formally publish them. This methodology can be used to construct tests within other test process environments.
